0. Bài 2. Khảo Sát Và Đặc Tả Mã Nguồn

Bộ môn An Toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 1
Chương 02 - MỤC TIÊU
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 2
KHẢO SÁT ĐẶC TẢ VÀ MÃ NGUỒN
 Các kỹ thuật tiến hành duyệt đặc tả mức cao
 Đóng vai trò là khách hàng của sản phẩm
 Nghiên cứu các chuẩn và hướng dẫn hiện hành
 Xem xét và kiểm thử các phần mềm tương tự
 Các kỹ thuật kiểm thử đặc tả ở mức thấp
 Danh sách các hạng mục cần thẩm định về các thuộc tính của
đặc tả
 Danh sách các hạng mục cần thẩm định về các thuật ngữ của
đặc tả
 Ai sẽ là khách hàng của sản phẩm
 Hiểu xem họ thực sự cần gì
 Không được giả thiết bất cứ cái gì khi tìm hiểu về đặc tả
 Xem xét đặc tả theo quan điểm người dùng giúp phát hiện
những lỗi bỏ sót hoặc sai với yêu cầu của họ
 không được bỏ qua yêu cầu là tính an toàn
 Một số chuẩn và hướng dẫn…:
 Hợp thức các thuật ngữ và quy ước: Nếu PM được làm riêng cho
một công ty nào đó hãy sử dụng các thuật ngữ và quy ước của họ.
 Yêu cầu công nghiệp: mỗi lĩnh ứng dụng như y tế, dược phẩm, tài
chính, ..., đều có các chuẩn riêng và nghiêm ngặt mà PM phải tuân
thủ.
 Chuẩn quy định bởi chính phủ: Chính phủ có những quy dịnh, đặc
biệt trong lĩnh vực quốc phòng và quản lý mà PM phải tuân thủ.
 Một số chuẩn và hướng dẫn:
 Giao diện đồ họa với người sử dụng (GUI): Các PM chạy trong
Windows hoặc Macintosh phải tuân thủ các quy định về giao diện đồ
họa của các HĐH này.
 Chuẩn bảo mật: PM có thể phải thỏa mãn một số quy định về bảo mật
mà cần phải được chứng nhận và cấp phép.
=> cần nắm được các chuẩn để kiểm thử xem PM có thỏa mãn hay
không, có gì bị bỏ qua hay không. Các chuẩn này được coi là một phần
của đặc tả khi thẩm định PM.
 bao gồm:
 Kích cỡ: Các đặc trưng sẽ nhiều hơn hay ít hơn? Chương trình sẽ ít hay
nhiều lệnh hơn, việc kiểm thử có bị ảnh hưởng bởi kích cỡ không?
 Độ phức tạp: độ phức tạp sẽ cao hơn hay thấp hơn, điều đó ảnh hưởng
thế nào đến kiểm thử?
 Tính khả kiểm thử. Liệu có đủ tài nguyên, thời gian và trình độ để kiểm
thử PM như vậy?
 Chất lượng và độ tin cậy. Liệu PM này đại diện cho chất lượng của PM
đang xây dựng, độ tin cậy sẽ cao hơn hay thấp hơn?
 Tính bảo mật. PM cạnh tranh này có tính bảo mật so với sản phẩm đang
phát triển thế nào?
Các kỹ thuật tiến hành duyệt đặc tả mức cao
Đóng vai trò là khách hàng của sản phẩm
Nghiên cứu các chuẩn và hướng dẫn hiện hành
Xem xét và kiểm thử các phần mềm tương tự
Các kỹ thuật kiểm thử đặc tả ở mức thấp
Danh sách các hạng mục cần thẩm định về các thuộc tính của
đặc tả
Danh sách các hạng mục cần thẩm định về các thuật ngữ của
đặc tả
DS các hạng mục cần thẩm định về các thuộc tính của đặc tả…
1. Đầy đủ. Liệu đặc tả còn thiếu cái gì không? Đã đủ chi tiết chưa?
Liệu nó đã bao gồm mọi điều cần thiết để không phụ thuộc vào
tài liệu khác?
2. Trúng đích. Liệu nó đã cung cấp lời giải đúng đắn cho bài toán,
liệu nó đã xác định đầy đủ các mục tiêu và không có lỗi.
3. Chính xác, không nhập nhằng và rõ ràng. Mô tả có chính xác
không, có rõ ràng và dễ hiểu không, liệu còn có gì là nhập nhằng
với ý nghĩa không xác định?
DS các hạng mục cần thẩm định về các thuộc tính của đặc tả…
4. Tương thích. Các đặc trưng và chức năng được mô tả có bị xung

đột với nhau không?
5. Hợp lệ. Các khẳng định có thực sự cần thiết để mô tả đặc trưng
sản phẩm không? Có gì thừa không? Có thể truy ngược về yêu
cầu của người dùng không?
6. Khả thi. Liệu đặc tả có thể được cài đặt trong khuôn khổ nhân
lực, công cụ, tài nguyên, thời gian và kinh phí cho phép hay
không?
DS các hạng mục cần thẩm định về các thuộc tính của đặc tả
7. Phi mã lệnh. Trong đặc tả không được dùng các câu lệnh
hoặc thuật ngữ cho người lập trình. Ngôn ngữ dùng trong
đặc tả phải là phổ biến với người dùng.
8. Khả kiểm thử. Liệu các đặc trưng có thể kiểm thử được? Liệu
đã cung cấp đủ thông tin để có thể kiểm thử và xây dựng các
ca kiểm thử?
DS các hạng mục cần thẩm định về các thuật ngữ của đặc tả…
 Luôn luôn, mỗi một, tất cả, không có, không bao giờ: mô tả sự
tuyệt đối và chắc chắn. Hãy xét xem tình trạng có đúng như vậy
không, có trường hợp nào vi phạm các khẳng định đó hay
không
 Tất nhiên, do đó, rõ ràng là, hiển nhiên là: được dùng để
thuyết phục người khác chấp nhận cái gì đó. Đừng có rơi vào
các bẫy đó.
DS các hạng mục cần thẩm định về các thuật ngữ của đặc tả…
 Nào đó, đôi khi, thông thường, thường gặp, hầu hết: nhập
nhằng, không có nghĩa rõ ràng và không thể kiểm thử, chẳng
hạn phải kiểm thử tính “đôi khi” thế nào?
 Vân vân, chẳng hạn, như vậy: mô tả thứ không thể kiểm thử
được
 Tốt, nhanh, rẻ, hiệu quả, ổn định: không định lượng => sẽ mô
tả các hạng mục không thể kiểm thử được nếu không được
làm chi tiết hóa sau này.
Danh sách các hạng mục cần thẩm định về các thuật ngữ của đặc tả
 Xử lý, từ chối, bỏ qua, bị khử: thường dấu trong nó những

chức năng cần phải đặc tả đầy đủ.
 Nếu ... thì (thiếu trái lại). Trường hợp “trái lại” có thể bị bỏ
quên. Hãy tránh các khẳng định như vậy.
KHẢO SÁT ĐẶC TẢ VÀ MÃ NGUỒN
Khảo sát mã nguồn…
 Khảo sát thiết kế và mã nguồn hay là việc KT hộp trắng tĩnh
 Phân tích cấu trúc: bao gồm một quy trình để khảo sát một cách
cẩn thận và có phương pháp đối với thiết kế, kiến trúc và mã
nguồn của PM để tìm lỗi mà không cần thực thi PM.
 Ưu điểm:
 phát hiện lỗi sớm
 phát hiện những lỗi mà khó có thể được phát hiện và định vị
bằng các kỹ thuật kiểm thử hộp đen động
 cung cấp cho cho người KT hộp đen động những thông tin quan
trọng để xác định những đặc trưng dễ bị mắc lỗi để tìm các ca
kiểm thử thích hợp và hiệu quả.
Các loại kiểm thử hộp trắng tĩnh phổ biến:

1. Phản biện hình thức
2. Phản biện chéo
3. Thông qua
4. Thanh tra
5. Các chuẩn và hướng dẫn trong lập trình
6. Danh sách các hạng mục chung cho việc khảo sát mã nguồn
Phản biện hình thức…
 có thể áp dụng ở nhiều mức độ khác nhau, từ một cuộc họp
đơn giản giữa hai lập trình viên cho đến cuộc thanh tra chi tiết
và nghiêm túc đối với thiết kế và mã nguồn.
 Có bốn hạng mục cơ bản cho một lần phản biện hình thức:
 Xác định vấn đề
 Tuân thủ các quy tắc: Cần xác định một tập các quy tắc để tuân thủ.
 Chuẩn bị
 Viết báo cáo: bao nhiêu vấn đề được phát hiện, được phát hiện ở chỗ
nào, ....
Phản biện hình thức
 Kết quả gián tiếp:
 Truyền tải thông tin: Những thông tin không gồm trong báo cáo hình thức
cũng được truyền tải.
 Chất lượng: Người lập trình sẽ cẩn thận hơn trong việc viết chương trình.
 Tính đồng đội: người lập trình và người kiểm thử gặp gỡ và phát triển
lòng kính trọng lẫn nhau về kỹ năng công việc và hiểu biết về công việc của
nhau cũng như tầm quan trọng của họ
 Lời giải: Lời giải cho các vấn đề được phát hiện có thể được tìm thấy
thông qua việc thảo luận ngoài cuộc họp.
Phản biện chéo
 Cách phản biện dễ nhất và ít hình thức nhất

 Thường được tổ chức giữa lập trình viên thiết kế kiến trúc hoặc
viết mã nguồn và người lập trình khác hoặc người kiểm thử trong
vai trò người phản biện.
 Sẽ khảo sát mã nguồn cùng nhau để tìm lỗi hoặc các vấn đề tồn tại
 Mỗi người cần đảm bảo bốn hạng mục nêu trong phản biện hình
thức
Thông qua
 Bước kế tiếp hình thức sau phản biện chéo
 Nhóm gồm 05 người (những người lập trình khác và người kiểm
thử) nhận, xem xét trước mã nguồn và chuẩn bị nhận xét, câu hỏi
hoặc thắc mắc cho buổi thông qua
 Buổi thông qua:
 Người lập trình: trình bày hình thức về mã nguồn theo từng dòng hoặc
từng hàm, giải thích chúng làm gì và tại sao lại được xây dựng như vậy
 Người nghe sẽ hỏi khi có điều gì thắc mắc
 Sau phản biện, người trình bày phải viết báo cáo về các vấn đề được
phát hiện và kế hoạch khắc phục
Thanh tra…
 là loại hình hình thức nhất của việc khảo sát mã nguồn
 có tổ chức cao và đòi hỏi người tham gia được đào tạo
 kỹ thuật phát hiện lỗi hiệu quả trong các sản phẩm PM, đặc biệt
trong các tài liệu thiết kế, mã nguồn và đang trở thành phổ
dụng vì những lợi ích to lớn mà nó mang lại
Thanh tra..
 Buổi họp thanh tra:
 Người trình bày hoặc độc giả không phải là người viết ra mã nguồn
 Người tham gia khác (thanh tra viên -TTV): phản biện mã nguồn từ
các khía cạnh và góc độ khác nhau (người dùng đầu cuối, người
kiểm thử, hoặc người bảo trì sản phẩm)
 01 TTV duyệt mã từ cuối đến đầu (theo kiểu hồi quy) để đảm bảo
mã nguồn được duyệt đầy đủ
 Một vài TTV làm điều hành viên và thư ký để đảm bảo các quy tắc
được tuân thủ và buổi họp thanh tra được tiến hành hiệu quả.
Thanh tra
 Sau buổi họp thanh tra:
 Các TTV có thể cần gặp nhau lần nữa để thảo luận về các lỗi được phát
hiện và làm việc với điều hành viên để chuẩn bị báo cáo và xác định
điều cần làm để khắc phục lỗi
 Người lập trình sau đó sẽ thay đổi mã nguồn để đưa ra bản đã được
sửa lỗi và điều hành viên sẽ kiểm tra xem việc sửa đã được làm thực sự
hay chưa
 Phụ thuộc và phạm vi, kích thước và tầm quan trọng của PM mà các
buổi thanh tra tiếp theo có nên tổ chức hay không để phát hiện các lỗi
còn lại.
Các chuẩn và hướng dẫn lập trình…
 Các chuẩn khi đã được thiết lập thì cần phải được tuân thủ.
 Các hướng dẫn là những kinh nghiệm thực hành được đề nghị là
cách làm tiện lợi hơn cho công việc.
 Chuẩn là nghiêm ngặt, hướng dẫn có thể ít nghiêm ngặt hơn.
 Có ba lý do nên tuân theo chuẩn và hướng dẫn:
 Độ tin cậy
 Tính dễ hiểu và dễ bảo trì
 Tính dễ chuyển đổi
Các chuẩn và hướng dẫn lập trình…
 Các dự án khác nhau có thể đòi hỏi các chuẩn khác nhau
(nội bộ, quốc gia hoặc quốc tế). Điều quan trọng là đội ngũ
dự án phải có chuẩn, có hướng dẫn cho lập trình và phải
được kiểm chứng xem chúng có được tuân thủ không trong
khi phản biện.
Ví dụ về chuẩn và hướng dẫn trong lập trình
Nếu lệnh if-then-else có thể thay thế continue
CHỦ ĐỀ: 3.05 thì phải dùng if-then-else.
Hạn chế về điều khiển đối với các cấu trúc điều THUYẾT MINH
khiển Lệnh go to bị cấm vì dễ gây lỗi và khó đọc, khó
CHUẨN theo dõi dòng điều khiển của chương trình.
Không được dùng lệnh go to (và do đó cả nhãn Thuật toán cần được trình bày theo cách có cấu
lệnh). trúc.
Dùng chu trình while thay cho do-while trừ khi Lệnh do-while không nên dùng vì chu trình cần
lôgic của bài toán đòi hỏi tường minh là phải được viết dưới dạng thống nhất là điều kiện chu
tiến hành thân chu trình ít nhất một lần không trình phải được kiểm tra trước khi tiến hành
phụ thuộc vào điều kiện chu trình. thân chu trình.
...
Cấu trúc của chuẩn và hướng dẫn
 Chuẩn thường có bốn phần chính như sau:

 Tiêu đề mô tả chủ đề mà chuẩn đó nói đến.
 Chuẩn (hoặc hướng dẫn) mô tả chính xác cái gì cho phép và cái gì
không cho phép.
 Thuyết minh nêu lý do tại sao phải có chuẩn đó.
 Ví dụ chỉ ra vài mẫu về việc sử dụng chuẩn. Phần này không luôn là
cần thiết.
Một số nguồn chuẩn và hướng dẫn
 Một số nguồn chuẩn và hướng dẫn:  Các tổ chức và hiệp hội
chuyên môn cũng cung
 Viện tiêu chuẩn quốc gia Hoa Kỳ (ANSI),
cấp các tài liệu hướng dẫn
www.ansi.org
và thực hành về lập trình
 Tập đoàn công nghệ quốc tế (IEC),
như:
www.iec.org
 Hiệp hội máy tính Mỹ
 Tổ chức quốc tế về chuẩn (ISO), www.iso.ch
(ACM), www.acm.org
 Ủy ban quốc gia về chuẩn trong công nghệ
 Viện kỹ nghệ điện và điện
thông tin của Hoa Kỳ (NCITS), www.ncits.org
tử (IEEE), www.ieee.org
DS các hạng mục chung cho việc khảo sát mã nguồn…
 Lỗi tham chiếu dữ liệu: do việc dùng các biến, hằng, xâu hoặc bản ghi
mà chưa được mô tả hoặc khởi tạo.
 Liệu có trong CT việc tham chiếu đến biến chưa khởi tạo giá trị?
 Giá trị của chỉ số mảng hoặc xâu có là nguyên và có nằm trong cận và số chiều
cho phép?
 Các phép tính trên chỉ số mảng có vượt ra ngoài cận cho phép?
 Lựa chọn giữa biến và hằng có hợp lý?
 Có vi phạm về kiểu trong khi gán giá trị cho biến?
 Giá trị tham chiếu của con trỏ có nằm trong vùng nhớ được phân phối?
 Tương ứng giữa tham số hình thức và thực sự trong các lời gọi hàm và
chương trình con.
DS các hạng mục chung cho việc khảo sát mã nguồn …
 Lỗi mô tả dữ liệu: bởi việc mô tả không đầy đủ hoặc do việc dùng
bất cẩn các biến và hằng số.
 Liệu các biến có được gán độ dài, kiểu, lớp đúng đắn? Chẳng hạn dùng
kiểu xâu thay cho kiểu mảng.
 Liệu các biến có được khởi tạo và khởi tạo hợp kiểu khi mô tả?
 Các biến với tên tương tự nên tránh vì dễ dùng nhầm.
 Có biến không được tham chiếu hoặc tham chiếu chỉ một lần?
 Phạm vi của mô tả biến có bị vi phạm?
 Lỗi tính toán: gây ra kết quả tính toán không như mong đợi.
 Có hay không việc tính toán số học với các kiểu khác nhau?
 Tính toán với các biến cùng kiểu nhưng khác độ dài.
 Các quy tắc biến đổi kiểu của chương trình dịch có được hiểu và dùng đúng?
 Giá trị của biểu thức vế phải của phép gán vượt ra ngoài miền giá trị của biến
vế trái.
 Lỗi tràn ô nhớ trong khi ước luợng giá trị của biểu thức, lỗi chia cho không.
 Lỗi về sai số làm tròn.
 Có nhầm lẫn về thứ tự ước lượng các phép toán trong biểu thức.
 Lỗi so sánh: Các lỗi về so sánh và quyết định chính là

các vấn đề hay gặp về điều kiện biên.
 Quan hệ trong so sánh có đúng đắn, chẳng hạn ≤ thay
cho <.
 Ảnh hưởng của sai số làm tròn trong so sánh.
 Các biểu thức Boolean có được viết đúng không? Các
toán hạng có được dùng đúng kiểu và nghĩa (kiểu
boolean và kiểu nguyên)?
 Lỗi điều khiển: các lỗi gây ra, trực tiếp hay gián tiếp, do dùng không
đúng các cấu trúc điều khiển như lệnh chu trình và rẽ nhánh.
 Các từ khóa mở và đóng nhóm các lệnh có sánh được với nhau?
 Đơn thể, chu trình có kết thúc như mong muốn?
 Có chu trình đan xen?
 Có nhánh chương trình không bao giờ được tiến hành? Nếu có thì liệu có là hợp
lệ?
 Liệu các nhánh của lệnh case có tương thích với điều kiện của nó.
 Liệu có chu trình với việc lặp thân chu trình không mong đợi do chỉ số vượt cận.
DS các hạng mục chung cho việc khảo sát mã nguồn
 Lỗi truyền tham số trong chương trình con: các lỗi về sự không tương
thích giữa tham số thực sự với tham số hình thức, lỗi về truyền theo
tham chiếu hay theo giá trị,....
 Lỗi về đầu vào và đầu ra: các lỗi về đọc tệp đầu vào, khuôn dạng không
tương thích khi vào dữ liệu từ bàn phím, lỗi đọc từ thiết bị không sẵn
sàng cho trao đổi dữ liệu,....
 Các lỗi khác: các lỗi chưa được liệt kê trên đây, chẳng hạn lỗi về ngôn
ngữ, mã ký tự (UNICODE or ASCII), lỗi hiển thị, lỗi về chuyển đổi giữa các
hệ điều hành, lỗi về tương thích với phần cứng khác nhau, ....
KHẢO SÁT VÀ ĐẶC TẢ MÃ NGUỒN
Bài tập cuối chương…
1. Liệu người kiểm thử có thể tiến hành kiểm thử hộp trắng trên
đặc tả?
2. Hãy trích dẫn một vài chuẩn và hướng dẫn của Windows và
Macintosh.
3. Khẳng định sau đây trong đặc tả sai ở điểm nào, tại sao: khi
người dùng chọn tùy chọn rút gọn bộ nhớ, chương trình sẽ nén
danh sách các địa chỉ e-mail nhỏ nhất có thể dùng cách tiếp cận
ma trận thưa Huffman.
4. Cái gì làm cho người kiểm thử băn khoăn trong đặc tả sau đây:
phần mềm sẽ cho phép tới 100 triệu kết nối đồng thời, dù rằng
thông thường không có quá một triệu người dùng.
5. Hãy liệt kê các lợi ích của việc kiểm thử hộp trắng tĩnh.
6. Kiểm thử hộp trắng tĩnh có thể phát hiện cả các vấn đề tồn tại
của mã lẫn những thứ còn thiếu. Nói thế đúng hay sai?
7. Phản biện hình thức gồm những hạng mục nào?
8. Ngoài việc là hình thức hơn, sự khác nhau lớn nhất giữa thanh
tra và các loại phản biện khác là gì?
9. Nếu một lập trình viên được thông báo là có thể dùng tên biến
với 8 ký tự với ký tự đầu viết hoa (chữ in). Điều đó là chuẩn hay
hướng dẫn?
Bài tập cuối chương
10. Bạn có định áp dụng danh sách các hạng mục chung cho việc
khảo sát mã nguồn trong chương này để phản biện mã trong dự
án phần mềm tương lai?
11. Lỗi về bảo mật gây ra bởi việc tràn bộ đệm thuộc loại nào
trong danh sách nói trên?

0. Bài 2. Khảo Sát Và Đặc Tả Mã Nguồn

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0. Bài 2. Khảo Sát Và Đặc Tả Mã Nguồn

Uploaded by

Copyright:

Available Formats

Bộ môn An Toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 1

Chương 02 - MỤC TIÊU

4. Tương thích. Các đặc trưng và chức năng được mô tả có bị xung

 Xử lý, từ chối, bỏ qua, bị khử: thường dấu trong nó những

 Khảo sát thiết kế và mã nguồn hay là việc KT hộp trắng tĩnh

Các loại kiểm thử hộp trắng tĩnh phổ biến:

 Cách phản biện dễ nhất và ít hình thức nhất

 Chuẩn thường có bốn phần chính như sau:

 Thuyết minh nêu lý do tại sao phải có chuẩn đó.

 Lỗi so sánh: Các lỗi về so sánh và quyết định chính là

You might also like