1.6Phương pháp kiểm thử và kiểm điểm -
Kiểm thử và kiểm điểm là cốt yếu để nâng cao chất lượng phần mềm
1.6.1Phương pháp kiểm thử -
Phương pháp kiểm thử bao gồm kiểm thử hộp trắng và kiểm thử hộp đen.
(1) Kiểm thử hộp trắng
-
Với kiểm thử hộp trắng, các trường hợp kiểm thử được thiết kế bằng việc chú ý đặc biệt tới cấu trúc bên trong của mô đun, cùng logic và luồng điều khiển. Trong kiểm thử, người ta mong muốn kiểm điểm tất cả các lệnh (câu lệnh) có trong chương trình chi tiết. Tuy nhiên, điều đó là khó bởi vì khối lượng công việc cần làm. Do đó, thiết kế phải tính tới sự cân xứng giữa "mức độ bao phủ" và "năng suất."
-
Mức độ bao phủ được dùng trong thiết kế các trường hợp kiểm thử được mô tả như sau:
-
Bao phủ lệnh
-
Bao phủ lệnh (câu lệnh) nói tới việc thiết kế các trường hợp kiểm thử tạo khả năng cho mọi lệnh (câu lệnh) trong chương trình đều được thực hiện ít nhất một lần. Bao phủ lệnh không tính tới hiệu quả của quyết định (đường đi).
-
Hình 1-5-1
|
Bao phủ lệnh
|
 
| -
-
Trong ví dụ nêu ở Hình 1-5-1, tất cả các lệnh được thực hiện đều được bao trong một đường đi. Việc kiểm thử đường đi bao gồm tất cả các lệnh này. Do đó, việc cung cấp chỉ một phép kiểm tra là đủ cho kiểm thử này.
-
-
Bao phủ quyết định
-
Bao phủ quyết định nói tới thiết kế các trường hợp kiểm thử có bao hàm việc thực hiện điều kiện "đúng" và việc thực hiện điều kiện "sai" ít nhất một lần cho mỗi quyết định (xem Hình 1-5-2).
-
-
Trong ví dụ được vẽ trong Hình 1-5-2, quyết định (nhánh) được bao phủ nếu hai đường nhánh đều được kiểm thử. Tuy nhiên quyết định được thực hiện theo những điều kiện hợp thành, có thể có điều kiện sẽ không được thử.
-
-
Bao phủ điều kiện
-
Bao phủ điều kiện nói tới thiết kế các trường hợp kiểm thử có khả năng kiểm thử tổ hợp các điều kiện trong đó các trạng thái "đúng" và "sai" của từng điều kiện đều được thực hiện ít nhất một lần.
-
Hình 1-5-3
B ao phủ điều kiện
|
| -
-
Chẳng hạn, nếu điều kiện quyết định trong Hình 1-5-3 là "Nếu A = đúng Hoặc B = đúng," thì tất cả các đường đi được lấy khi hoặc A hoặc B đúng phải được bao phủ bởi các trường hợp kiểm thử. Cho nên, dữ liệu gây ra việc thực hiện của hai đường được vẽ trong Hình 1-5-4 thiết lập nên các trường hợp kiểm thử.
-
Hình 1-5-4
Trường hợp kiểm thử của bao phủ điều kiện
|
|
|
|
|
|
|
A
|
Đúng
|
Sai
|
|
B
|
Sai
|
Đúng
| -
-
Bao phủ quyết định/điều kiện
-
Trong trường hợp bao phủ điều kiện, các trạng thái "đúng" và "sai" của từng điều kiện A và B của đa điều kiện đều được kiểm thử. Tuy nhiên, đường đi cho "A = "đúng" và B = "đúng"" và đường đi cho "A = "sai" và B = "sai" không được kiểm thử. Mặt khác, bao phủ quyết định/điều kiện được áp dụng cho bao phủ điều kiện được tổ hợp thêm (xem Hình 1-5-5).
-
-
Hình 1-5-5
|
Ví dụ về bao phủ quyết định/điều kiện
| -
-
-
-
Trong ví dụ được vẽ trong Hình 1-5-5, đường đi được thực hiện khi điều kiện là "sai" được bao phủ bởi trường hợp kiểm thử. Do đó, ba đường đi được vẽ trong Hình 1-5-6 được trường hợp kiểm thử này bao quát.
-
Hình 1-5-6
Các trường hợp kiểm thử cho bao quát quyết định/điều kiện
|
|
|
|
|
|
|
|
|
A
|
Đúng
|
Sai
|
Sai
|
|
B
|
Sai
|
Đúng
|
Sai
| -
-
Bao phủ đa điều kiện
-
Bao phủ đa điều kiện sử dụng các trường hợp kiểm thử bao quát tất cả các đường đi được thực hiện tuỳ thuộc vào tất cả các tổ hợp điều kiện "đúng" và "sai" và làm cho mọi lệnh được bao hàm đều được thực hiện ít nhất là một lần.
-
Hình 1-5-7
|
Bao phủ đa điều kiện
| -
-
-
Trong ví dụ được vẽ trong Hình 1-5-7 nơi điều kiện quyết định là "Nếu A = đúng hoặc B = sai, " các đường đi được chọn giữa tất cả các giá trị của A và B đều được xét để chuẩn bị cho các trường hợp kiểm thử. Kết quả là bốn đường đi sau đây trong Hình 1-5-8 tạo nên các tổ hợp được thực hiện bởi các trường hợp kiểm thử.
-
-
Hình 1-5-8
Trường hợp kiểm thử cho bao phủ đa điều kiện
|
|
|
|
|
|
|
|
|
|
|
A
|
Đúng
|
Đúng
|
Sai
|
Sai
|
|
B
|
Đúng
|
Sai
|
Đúng
|
Sai
|
(2) Kiểm thử hộp đen
-
Trong kiểm thử hộp đen, không xem xét tới cấu trúc bên trong và cấu trúc logic của mô đun. Nói cách khác, mô đun được coi như hộp đen. Sau đó, dữ liệu kiểm thử được thiết kế bằng cách chỉ chú ý tới giao diện (cái vào và cái ra) của từng mô đun.
-
Hình 1-5-9
Kiểm thử hộp đen
| | -
Các trường hợp kiểm thử được thiết kế theo cách sau:
-
Phân hoạch tương đương
-
Trong phân hoạch tương đương, dữ liệu được phân hoạch thành nhiều nhóm khác nhau (các lớp tương đương), mỗi phần tử có cùng tính chất. Sau đó một mảnh dữ liệu trong mỗi nhóm được dùng như giá trị đại diện cho từng nhóm. Trong phân hoạch tương đương, dữ liệu được phân hoạch thành một trong hai lớp sau:
-
| | | -
Lớp dữ liệu nằm trong miền hợp lệ.
| -
Lớp tương đương không hợp lệ
| | -
Lớp dữ liệu nằm trong miền không hợp lệ (lỗi).
| -
Sau đó dữ liệu điển hình cho từng lớp được lựa ra cho trường hợp kiểm thử.
-
Hình 1-5-10 Phân hoạch tương đương
-
…, 2, 1, 0
|
1, 2, 3, 4
|
5, 6, 7, 8, …
|
|
|
|
L ớp tương đương
không hợp lệ
|
Lớp tương đương hợp lệ
|
Lớp tương đương
không hợp lệ
|
|
|
|
|
Dữ liệu kiểm thử: 1, 3, 8
|
| -
-
Trong Hình 1-5-10, nếu lớp tương đương hợp lệ bao gồm 1 tới 4, thì tập dữ liệu biểu diễn cho từng lớp, chẳng hạn, "-1, 3, 8" có thể được dùng làm dữ liệu kiểm thử.
-
-
Phân tích giá trị biên
-
Phân tích giá trị biên là phương pháp phân tích dùng các giá trị biên của lớp tương đương hợp lệ làm dữ liệu kiểm thử.
Hình 1-5-11 Phân tích giá trị biên
-
…, 2, 1, 0
|
1, 2, 3, 4
|
5, 6, 7, 8, …
|
|
|
|
Lớp tương đương
không hợp lệ
|
Lớp tương đương hợp lệ
|
Lớp tương đương
không hợp lệ
|
Dữ liệu kiểm thử: 0, 1, 4, 5
| -
Trong Hình 1-5-11, nếu lớp tương đương hợp lệ bao gồm dữ liệu của 1 tới 4, thì tập các giá trị biên của từng lớp, chẳng hạn, "0, 1, 4, 5" có thể được dùng làm dữ liệu kiểm thử.
-
Đồ thị nhân-quả
-
Trong phân hoạch tương đương và phân tích giá trị biên, dữ liệu được phân loại để phân tích. Tuy nhiên, đồ thị nhân-quả cung cấp một phương pháp để thiết kế các trường hợp kiểm thử có hiệu quả cho các mô đun mà việc phân hoạch thành lớp có khó khăn.
-
-
1. Tất cả các nguyên nhân (cái vào) và kết quả (cái ra) đều được lấy dựa trên đặc tả.
-
2. Mối quan hệ giữa nguyên nhân (cái vào) và kết quả (cái ra) được diễn đạt để làm cho mối quan hệ logic được rõ ràng.
-
3. Bảng quyết định được chuẩn bị dựa trên các đồ thị. Dữ liệu kiểm thử được tạo ra dựa trên các bảng này.
-
Ví dụ
-
(Mô tả về đặc tả)
-
- Số các chủ thể kiểm tra là 5.
-
- "Pass" là cái ra, nếu kết quả của bốn hay nhiều chủ thể là thành công.
-
- "Temporary pass" là cái ra, nếu kết quả trong hai hay ba chủ thể là không thành công.
-
- "Failure" là cái ra, nếu kết quả trong chỉ một chủ thể là thành công.
-
(Thủ tục 1) Lấy ra tất cả các quan hệ giữa nguyên nhân (cái vào) và kết quả (cái ra) dựa trên đặc tả.
Hình 1-5-12
|
|
|
|
Quan hệ giữa nguyên nhân
(cái vào) và kết quả (cái ra)
|
Nguyên nhân (cái vào)
|
|
Kết quả (cái ra)
|
|
|
|
Kết quả trong bốn hay nhiều chủ thể là thành công
|
|
Pass
Temporary pass
Failure
|
|
Kết quả trong hai hay nhiều chủ thể là thành công
|
|
|
|
|
| -
(Thủ tục 2) Diễn dạt mối quan hệ giữa nguyên nhân (cái vào) và hậu quả (cái ra) trong đồ thị để làm cho mối quan hệ logic được rõ ràng.
-
(Thủ tục 3) Bảng quyết định được chuẩn bị dựa trên các đồ thị.
-
-
-
-
-
Phương pháp thiết kế thực nghiệm
-
Lí tưởng là thiết kế mọi trường hợp kiểm thử có thể quan niệm được và tiến hành các kiểm thử bằng việc dùng chúng. Tuy nhiên, điều này yêu cầu khối lượng lớn công việc kiểm thử. Do đó, phương pháp thiết kế thực nghiệm, một dạng của phân tích thống kê, được dùng cho các kiểm thử có yêu cầu số lượng lớn dữ liệu. Việc phân tích dữ liệu kiểm thử bằng phương pháp này và dùng các kết quả như các trường hợp kiểm thử tạo khả năng tiến hành kiểm thử hiệu quả.
-
Ví dụ Kiểm tra dữ liệu về sinh viên -- việc kiểm tra hợp lệ về số hiệu đăng kí sinh viên và mã các trường phổ thông họ tốt nghiệp ra, và kiểm tra về bậc -- được tiến hành.
-
(Thủ tục 1) Tám trường hợp kiểm thử được hình dung ra, nếu tất cả các trường hợp kiểm thử đều được giả thiết cho tất cả các tổ hợp của ba khoản mục này: kiểm tra tính hợp lệ của số đăng kí sinh viên và kiểm tra tính hợp lệ của mã trường phổ thông họ tốt nghiệp và kiểm tra về bậc tốt nghiệp.
-
Hình 1-5-15
Dữ liệu sinh viên
| -
Khoản mục
-
-
-
Số hiệu kiểm thử
| | | | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | -
-
(Thủ tục 2) Như với ba khoản mục này, bảng sau (ma trận) chỉ ra mối quan hệ giữa chúng được tạo ra:
-
Hình 1-5-16 Bảng chỉ ra mối quan hệ
-
-
S ố hiệu đăng kí sinh viên
-
-
Mã trường phổ thông
được tốt nghiệp từ
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | -
Mã của trường phổ thông được tốt nghiệp từ
| | | | | | | | | | | | | | | | | | | | | | | -
(Thủ tục 3) Khi được so sánh với dữ liệu về sinh viên trong Hình 1-5-15, người ta thấy rằng bốn trong chúng được lấy ra. Có thể kết luận rằng, nếu tất cả bốn phép kiểm thử này đều cho kết quả thành công, thì bốn phép kiểm thử kia cũng phải cho kết quả thành công.
1.6.2Phương pháp kiểm điểm -
Để thực hiện phát triển hệ thống theo cách từ trên xuống, cần phải phát hiện lỗi sớm nhất có thể được. Điều này là vì các lỗi bị ẩn kín sẽ ảnh hưởng rất lớn tới công việc ở những giai đoạn sau. Các lỗi được sinh ra trong thiết kế hệ thống đại thể ảnh hưởng còn lớn hơn, như trong pha lập kế hoạch cơ sở và thiết kế ngoài gây ảnh hưởng rất lớn, làm tốn kém rất nhiều để sửa lỗi. Công việc sửa lỗi trong bảo trì nghe nói còn gấp vài chục lần việc sửa lỗi trong viết mã.
-
Cho dù kiểm thử có được tiến hành bằng việc bao quát về mặt lí thuyết mọi trường hợp kiểm thử có thể quan niệm được, thì việc khử bỏ đi mọi lỗi vẫn cứ là khó khăn theo quan điểm cả những ràng buộc về thời gian cần thiết và các nhân tố khác. Tuy nhiên, việc làm giảm lỗi nhiều nhất có thể được vẫn có tác động lớn lên chất lượng và chí phí sửa lỗi.
-
Do đó, phải tiến hành hết mức những nỗ lực để họp kiểm điểm đưa ra các biện pháp có hiệu quả tìm ra lỗi.
-
Họp kiểm điểm nêu ra thảo luận và đánh giá điều được thực hiện, trong từng pha từ việc lập kế hoạch cơ sở cho tới lập trình, để rút ra những mơ hồ hay điểm có vấn đề nằm trong cái ra (các tài liệu thiết kế khác nhau và mã nguồn) của từng pha. Nói riêng, cuộc họp kiểm điểm được tiến hành trong pha thiết kế được gọi là "kiểm điểm thiết kế," trong khi họp kiểm điểm cho pha phát triển mã chương trình được gọi là "kiểm điểm mã."
-
Các tác động sau đây được trông đợi từ việc tiến hành các cuộc họp kiểm điểm.
-
-
Cơ hội để xem xét lại các điểm còn mơ hồ đã nêu, cho phép những người tham dự chia sẻ cùng hiểu biết.
-
Vấn đề (lỗi), mà người chịu trách nhiệm phát triển thực tế không thể tìm ra nổi, lại có thể được người khác phát hiện ra.
-
Các chức năng, hiệu năng và chất lượng (kể cả độ tin cậy, tính vận hành và tính bảo trì) đều có thể được cải thiện.
-
Trong những khoản mục được mô tả trên đây, họp kiểm điểm đặc biệt mạnh trong việc phát hiện ra vấn đề (lỗi).
-
Ta hãy so sánh, với ví dụ được cho trong Hình 1-15-17 xem như mô hình, các khía cạnh kinh tế cho trường hợp kiểm điểm được tiến hành và trường hợp khác mà kiểm điểm không được thực hiện.
-
Hình 1-5-17
Mô hình so sánh theo khía cạnh kinh tế
| | -
< Khi không thực hiện kiểm điểm>
-
-
-
-
-
-
-
< Khi thực hiện kiểm điểm>
-
-
-
-
-
-
-
-
-
(Lập kế hoạch cơ sở)
-
Sáu lỗi được len vào và được truyền qua thiết kế ngoài tiếp theo.
-
(Thiết kế ngoài)
-
Chín lỗi mới được len vào, và 15 lỗi tổng cộng được truyền qua thiết kế trong tiếp theo.
-
(Thiết kế trong)
-
Trong số 15 lỗi, 7 lỗi được truyền qua thiết kế trong. Ta giả thiết ở đây là 8 lỗi còn lại ảnh hưởng tới các lỗi khác, làm len thêm trung bình 3.5 lỗi cho mỗi lỗi nhận được. Bên cạnh đó, 20 lỗi mới được len vào trong pha này, đem tổng số lỗi bị truyền sang pha thiết kế chương trình và viết mã là 55.
-
(Thiết kế chương trình và viết mã)
-
Trong số 55 lỗi tổng cộng, 40 lỗi truyền qua pha thiết kế chương trình và viết mã. Tuy nhiên, ta lại giả thiết ở đây rằng 15 lỗi còn lại ảnh hưởng tới các lỗi khác, làn len trung bình năm lỗi cho mỗi lỗi nhận được. Bên cạnh đó, 30 lỗi mới được tạo ra, đem số lỗi bị truyền vào pha tiếp là 145.
-
(Kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống)
-
Ta giả sử rằng tỉ lệ phát hiện lỗi là 50% cho từng kiểm thử.
-
(Kết quả)
-
Hệ thống hoàn chỉnh chứa 18 lỗi.
-
-
-
(Lập kế hoạch cơ sở)
-
Sáu lỗi được len vào. Giả thiết rằng họp kiểm điểm ở đây tạo khả năng lỗi được phát hiện quãng 50%, số lỗi bị truyền qua pha thiết kế ngoài trở thành ba.
-
(Thiết kế ngoài)
-
Chín lỗi mới được len vào. Giả sử rằng họp kiểm điểm ở đây tạo khả năng lỗi được phát hiện quãng 50%, số lỗi bị truyền qua pha thiết kế ngoài trở thành sáu.
-
(Thiết kế trong)
-
Trong số sáu lỗi, ba lỗi được truyền qua thiết kế trong. Ta giả thiết ở đây là ba lỗi còn lại ảnh hưởng tới các lỗi khác, làm len thêm trung bình 3.5 lỗi cho mỗi lỗi nhận được. Bên cạnh đó, giả sử rằng 20 lỗi mới được tạo ra và rằng họp kiểm điểm tạo khả năng lỗi được phát hiện với tỉ lệ 60%, số lỗi bị truyền sang pha thiết kế chương trình và viết mã trở thành 14.
-
(Thiết kế chương trình và viết mã)
-
Trong số 14 lỗi tổng cộng, 10 lỗi truyền qua pha thiết kế chương trình và viết mã. Ta lại giả thiết ở đây rằng bốn lỗi còn lại ảnh hưởng tới các lỗi khác, làm len trung bình năm lỗi cho mỗi lỗi nhận được. Bên cạnh đó, giả sử rằng 30 lỗi mới được tạo ra và rằng họp kiểm điểm tạo khả năng lỗi được phát hiện với tỉ lệ 70%, số lỗi bị truyền vào pha kiểm thử trở thành 18.
-
(Kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống)
-
Ta giả sử rằng tỉ lệ phát hiện lỗi là 50% cho từng kiểm thử.
-
(Kết quả)
-
Hệ thống đã phát triển chứa 2 lỗi.
-
Các trường hợp khác nhau được xem xét. Tuy nhiên, như được mô tả ở trên, tổng số lỗi còn lại trong trường hợp kiểm điểm được thực hiện là hoàn toàn khác. Do đó, kiểm điểm hiệu quả nên được tiến hành.
-
Các phương pháp họp kiểm điểm điển hình bao gồm giải trình (walkthroughs) và giám định (inspection).
(1) Giải trình
-
Giải trình được tiến hành bởi người tạo ra vật phẩm, và những người có liên quan (ngang quyền) nhằm phát hiện lỗi trong thiết kế và mã hoá sớm nhất có thể được để cải thiện chất lượng.
(2) Giám định
-
Giám định, một phương pháp chính thức hoá việc giải trình, nhằm phát hiện lỗi trong thiết kế và mã hoá sớm nhất có thể được để làm tăng chất lượng. Cuộc họp giám định, do một người chủ toạ, còn gọi là "người dẫn chương trình", chịu trách nhiệm tổ chức họp, sẽ kiểm điểm lại các tiến trình kể cả việc sửa lỗi và kiểm tra kết quả sửa chữa, và vai trò của từng người tham dự cũng được xác định chi tiết.
(3) Những điểm cần được xem xét trong khi tiến hành họp kiểm điểm
-
Khi tiến hành họp kiểm điểm, thì những điểm sau nên được tính tới:
-
-
Tài liệu sử dụng trong cuộc họp nên được phân phát hai hay ba ngày trước đó, và mọi người tham dự cần phải đọc chúng trước khi vào thảo luận với những người tham dự khác.
-
Tập trung vào việc phát hiện lỗi và làm cuộc họp ngắn nhất có thể được. Tổ chức các cuộc họp như vậy thường xuyên sẽ làm giảm khối lượng công việc phải làm lại.
-
Nhiều người, nhưng chỉ người phát triển mới nên tham gia vào cuộc họp này.
-
Người quản lí nên tránh tham dự vào cuộc họp này. Cuộc họp này được tổ chức để phát hiện lỗi. Nếu người quản lí tham dự vào cuộc họp, thì những người tham dự sẽ ngần ngại đưa ra ý kiến riêng của mình một cách tự do, làm giảm tiềm năng phát hiện lỗi mà cuộc họp đáng có.
1.6.3Thiết kế kiểm thử và phương pháp quản lí
(1) Đường cong lỗi
-
Đường cong lỗi đưa ra một mô hình dùng một số các lỗi để ước lượng về mặt định lượng độ tin cậy của chương trình. Đường cong này, cũng còn được gọi là "đường cong tăng trưởng độ tin cậy" và "mô hình cận toán học," được chuẩn bị bằng việc đặt số lỗi tích luỹ vào trục đứng và thời gian vào trục ngang. Một điểm uốn được định vị ở giữa đường cong này và độ hội tụ cuối cùng được đạt tới. Đường cong hậu cần và đường cong Gompertz thường được dùng cho mục đích này.
-
-
-
Hình 1-5-18
-
Ví dụ về đường cong lỗi ARC (đường cong tăng trưởng độ tin cậy)
| -
Thời gian
|
(2) Biểu đồ quản lí lỗi
-
Biểu đồ quản lí lỗi quản lí các lỗi bằng việc dùng đường cong lỗi (xem Hình 1-5-19).
-
-
Hình 1-5-19
-
Ví dụ về biểu đồ quản lí lỗi
| -
Thời gian
| -
-
Dữ liệu thực tế được so sánh với đường cong lỗi, và có thể tiến hành các đánh giá sau.
-
- Việc xây dựng bị chậm (A)
| | -
Dùng các trường hợp kiểm thử phát hiện và môi trường kiểm thử không thoả đáng cần được xem xét.
| -
- Sự hội tụ không đạt tới (A)
| | -
Chương trình phải được xem xét lại.
| -
- Số các lỗi tích luỹ được phát hiện vẫn còn thấp hơn đường cong lỗi (A)
| | -
Chất lượng có thể cao hay các trường hợp kiểm thử được dùng có thể không tốt.
| -
- Số các lỗi tích luỹ được phát hiện vượt hơn đường cong lỗi (B)
| | -
Các trường hợp kiểm thử được dùng có thể tốt hay phẩm chất của chương trình có thể không tốt.
| -
Tính tới những dữ liệu thu được thực tế và mức độ kĩ năng của người phát triển, có thể đưa ra đánh giá về trạng thái của các tiến trình kiểm thử và chất lượng của chương trình.
(3) Bao phủ
-
"Bao phủ" cũng còn được gọi là "bao phủ kiểm thử." Việc bao phủ một chương trình nghĩa là số phần trăm các con đường được bao phủ tính theo tất cả các đường đi có trong chương trình, và cụm từ này chỉ ra cách diễn đạt định lượng cho phương pháp bao phủ đã được mô tả về kiểm thử hộp trắng.
(4) Thiết kế kiểm thử
-
Người ta đã biết rằng phương pháp kiểm thử bao gồm kiểm thử hộp trắng và kiểm thử hộp đen và có vài phương pháp để thiết kế các trường hợp kiểm thử. Việc dùng các trường hợp thiết kế được sinh ra chỉ với một trong hai phương pháp này là không đủ. Nói chung, tiến hành kiểm thử dựa trên kiểm thử hộp đen là hiệu quả cho kiểm thử chức năng, và bổ sung vào chúng với kiểm thử hộp trắng.
-
Các điều kiện biên cho cái vào và cái ra và các điều kiện chuyển đổi được kiểm tra dựa trên tài liệu thiết kế ngoài cho chương trình. Sau đó các trường hợp kiểm thử được sinh ra. Các trường hợp kiểm thử bao giờ cũng nên được giới hạn vào những trường hợp kiểm tra liệu chức năng cần thiết (cái gì) có được đạt tới không.
-
Dựa trên danh sách nguồn chương trình và các đặc tả chi tiết (liên quan tới các thuật toán được mô tả trên cơ sở câu lệnh, như đặc tả chương trình và đặc tả mô đun), các hình mẫu phân nhánh của chương trình được kiểm tra. Sau đó các trường hợp kiểm thử tạo khả năng cho các điều kiện "đúng" và "sai" của mỗi chỗ có kiểm tra điều kiện được thực hiện và tạo ra.
-
Kiểm tra rằng các trường hợp kiểm thử và được mô tả ở trên có thể thực hiện mọi lệnh được bao hàm. Với các chu trình, các trường hợp kiểm thử điều kiện ra khỏi chu trình 0, 1, và số lần tối đa sẽ được tạo ra.
-
Sau khi tạo ra các trường hợp kiểm thử cho , và , kết quả kiểm thử cho từng trường hợp kiểm thử về mặt lí thuyết được giả thiết làm sinh ra tài liệu điều kiện kiểm thử.
(5) Len lỗi
-
Không thể nào khử bỏ hết mọi lỗi trong phần mềm. Điều này là vì không thể nào kiểm chứng được rằng không có lỗi còn lại. Dijkstra, người đề nghị lập trình có cấu trúc, đã nói:
-
"Kiểm thử chỉ ra rằng lỗi tồn tại, nhưng không thể chứng minh được rằng không còn lỗi nữa."
-
Myers, người đề nghị thiết kế có cấu trúc, phải nói điều này về kiểm thử:
-
"Kiểm thử là tiến trình kiểm tra rằng chương trình là đúng, hay nói cách khác, là không chỉ ra rằng chương trình không có lỗi."
-
"Kiểm thử là tiến trình thực hiện chương trình để phát hiện ra lỗi."
-
Rút cục, không ai có thể nói rằng, "chương trình là không có lỗi" ngay cả sau khi đã tiến hành các phép kiểm thử. Tuy nhiên, thời hạn chuyển giao được xác định cho việc phát triển hệ thống. Do đó, cần phải hoàn thành việc phát triển hệ thống và bắt đầu vận hành thực tế. Hậu quả là, sẽ đến lúc người thiết kế bị buộc phải tuyên bố rằng hoạt động kiểm thử đã được hoàn tất.
-
Việc len lỗi là một phương pháp để đánh giá ngày hoàn thành hoạt động kiểm thử về mặt con số; các lỗi đã biết được len vào một cách có chủ ý, và số lỗi cố hữu vẫn còn sẽ được ước lượng dựa trên tỉ số của lỗi cố hữu đã được phát hiện với số lỗi đã biết được phát hiện.
-
 Hình 1-5-20
Len lỗi
| | -
Chia sẻ với bạn bè của bạn: |
đúng, 
đúng.
đúng.
rường hợp kiểm thử
guyên nhân và kết quả
Qua 2 hay nhiều chủ thể
“Pass” được đưa ra
“Temporary” được đưa ra
