Professional Documents
Culture Documents
0. Bài 2. Khảo Sát Và Đặc Tả Mã Nguồn
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 2
KHẢO SÁT ĐẶC TẢ VÀ MÃ NGUỒN
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 3
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ả
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 4
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
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 5
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ủ.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 6
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 7
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?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 8
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ả
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 9
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?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 10
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ử?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 12
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 đó.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 13
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 14
Danh sách các hạng mục cần thẩm định về các thuật ngữ của đặc tả
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 15
KHẢO SÁT ĐẶC TẢ VÀ MÃ NGUỒN
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 16
Khảo sát mã nguồn…
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 17
Khảo sát mã nguồn…
Ư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ả.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 18
Khảo sát mã nguồn…
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 21
Phản biện chéo
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 22
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
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 23
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
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 24
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ả.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 25
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 26
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
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 27
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 28
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 29
...
Cấu trúc của chuẩn và hướng dẫ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.
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 30
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
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 31
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 32
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?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 33
DS các hạng mục chung cho việc khảo sát mã nguồn …
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 34
DS các hạng mục chung cho việc khảo sát mã nguồn …
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 38
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.
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 39
Bài tập cuối chương…
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?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 40
Bài tập cuối chương…
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ộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 41
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?
Bộ môn An toàn phần mềm – Khoa An Toàn Thông Tin 22:58 | Page 42