1. Chương 5: Kiểm thử (Testing)

2. Nội dung Khái niệm kiểm thử phần mềm
Một số đặc điểm của kiểm thử phần mềm
Tại sao kiểm thử lại cần thiết?
Quy trình kiểm thử
Các mức độ test
Kỹ thuật thiết kế test
Vai trò của Tester
Công việc Tester
Tài liệu tham khảo

3. Khái niệm kiểm thử phần mềm
Kiểm thử là gì?
A person makes
an error ...
… that creates a fault (bug, defect) in the software ...
… that can cause a failure in operation

4. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi phần mềm với mục tiêu tìm ra lỗi
Glen Myers, 1979
 Khẳng định được chất lượng của phần mềm đang xây dựng
Hetzel, 1988

5. Một số đặc điểm kiểm thử PM
Kiểm thử phần mềm giúp tìm ra được sự hiện diện của lỗi nhưng không thể chỉ ra sự vắng mặt của lỗi
Dijkstra
Mọi phương pháp được dùng để ngăn ngừa hoặc tìm ra lỗi đều sót lại những lỗi khó phát hiện hơn
Beizer
Điều gì xảy ra nếu việc kiểm thử không tìm được lỗi trong phần mềm hoặc phát hiện quá ít lỗi
Phần mềm có chất lượng quá tốt
Quy trình/Đội ngũ kiểm thử hoạt động không hiệu quả

6. Tại sao kiểm thử lại cần thiết?
Thông thường thì phần mềm không hoạt động như mong muốn  lãng phí tiền bạc, thời gian, uy tín của doanh nghiệp, thậm chí có thể gây nên thương tích hay cái chết.
Ví dụ:
Website công ty có nhiều lỗi chính tả trong câu chữ Khách hàng có thể lãng tránh công ty với lý do công ty trông có vẻ không chuyên nghiệp.
Một phần mềm tính toán lượng thuốc trừ sâu dùng cho cây trồng, vì lý do tính sai số lượng lên gấp 10 lần Nông dân phải bỏ nhiều tiền mua, cây trồng hư hại, môi trường sống, nguồn nước bị ảnh hưởng,….

7. Tại sao kiểm thử lại cần thiết?
Kiểm thử phần mềm  chất lượng phần mềm được nâng cao.
Chúng ta có thể đánh giá chất lượng phần mềm dựa vào số lượng lỗi tìm thấy và các đặc tính như: tính đúng đắn, tính dễ sử dụng, tính dễ bảo trì,…
Kiểm thử có thể đem lại sự tin tưởng đối với chất lượng phần mềm nếu có ít lỗi hoặc không có lỗi nào được tìm thấy. Nếu lỗi tìm thấy và được sửa thì chất lượng phần mềm càng được tăng  Giảm chi phí trong quá trình phát triển, nâng cấp, bảo trì phần mềm

8. Lỗi tăng lên khi nào?
Hình trên cho thấy ảnh hưởng của việc khi nào thì tìm thấy lỗi trong phần mềm. Chi phí cho việc tìm thấy và sửa lỗi tăng dần trong suốt chu kỳ sống của phần mềm. Lỗi tìm thấy càng sớm thì chi phí để sửa càng thấp và ngược lại.
Note: Các hoạt động test nên bắt đầu càng sớm càng tốt trong chu kỳ phát triển của phần mềm.

9. Lỗi tăng lên khi nào?
Chi phí cho việc tìm thấy và sửa lỗi tăng dần trong suốt chu kỳ sống của phần mềm. Lỗi tìm thấy càng sớm thì chi phí để sửa càng thấp và ngược lại.

10. Các hoạt động của kiểm thử
Các hoạt động của kiểm thử tồn tại cả trước và sau khi thực thi phần mềm như:
Lập kế hoạch test (test plan)
Chọn các điều kiện test (test conditions)
Thiết kế các trường hợp test (test cases)
Kiểm tra kết quả, ước lượng khi nào thì dừng test.
Báo cáo kết quả test.

11. Vai trò kiểm thử
Vai trò kiểm thử trong suốt quy trình sống của phần mềm
Kiểm thử không tồn tại độc lập.
Các hoạt động của kiểm thử luôn gắn liền với các hoạt động phát triển phần mềm.
Các mô hình phát triển phần mềm khác nhau cần các cách tiếp cận test khác nhau.

12. Mô hình thác nước Các hoạt động trong thế giới thực Khảo sát
Hiện trạng
Các yêu cầu
Xác định
Yêu cầu
Mô hình Thế giới thực
Phân tích
Mô hình phần mềm
Test bắt đầu khi phần mềm sắp kết thúc vì thế các lỗi được tìm thấy rất gần với ngày thực thi phần mềm -> không còn thời gian để quay lại với các phase trên.
Thiết kế
Phần mềm
Cài đặt
Phần mềm
“chất lượng”
Kiểm thử
Triển khai
Waterfall

13. Mô hình chữ V
V-model xuất hiện đã cải thiện rất nhiều vấn đề của Waterfall model. Với V-model cho thấy test đã xuất hiện rất sớm trong chu kỳ phần mềm. V-model cho thấy test không chỉ là hoạt động thực thi phần mềm. Rất nhiều các hoạt động test xảy ra trước giai đoạn code. Các hoạt động này được thực hiện song song với các hoạt động phát triển phần mềm (development activities)

14. Mô hình phát triển lặp
Chúng ta có thể chia nhỏ phần mềm ra làm nhiều giai đoạn thay vì làm một lần từ đầu đến cuối. Mô hình này cần các hoạt động test như: test chức năng mới, test lặp lại cho những chức năng cũ, và integration test cho cả phần cũ và phần mới.

15. Qui trình kiểm thử phần mềm

16. Các mức độ test (Test levels)
Component testing (unit testing):
Tìm lỗi trong các component của phần mềm như: modules, programs, objects, classes,…
Ai thực hiện?
Integration testing:
Test sự kết hợp của các component, sự tác động của các phần khác nhau trong một hệ thống, sự kết hợp của các hệ thống với nhau,…
System testing là công việc chính của người tester
Acceptance testing thường được thực thi bởi khách hàng hoặc người sử dụng phần mềm.
Mục đích của acceptance testing là thiết lập sự tin tưởng đối với phần mềm hoặc một phần, một chức năng của phần mềm. Tìm kiếm lỗi không phải là mục tiêu của acceptance testing.
Một số dạng của acceptance testing là alpha testing và beta testing. Cả hai đều được thực thi bởi khách hàng của phần mềm, không phải là người phát triển phần mềm.
- Alpha testing được thực hiện tại nơi phát triển phần mềm.
- Beta testing được thực hiện tại nơi của khách hàng.

17. Các mức độ test (Test levels)
System testing: Test hệ thống.
Đảm bảo rằng hệ thống (sau khi tích hợp) thỏa mãn tất cả các yêu cầu của người sử dụng
Tập trung vào việc phát hiện các lỗi xảy ra trên toàn hệ thống
Acceptance testing: Test phần mềm đứng theo góc độ người dùng để xác định phần mềm có được chấp nhận hay không.
System testing là công việc chính của người tester
Acceptance testing thường được thực thi bởi khách hàng hoặc người sử dụng phần mềm.
Mục đích của acceptance testing là thiết lập sự tin tưởng đối với phần mềm hoặc một phần, một chức năng của phần mềm. Tìm kiếm lỗi không phải là mục tiêu của acceptance testing.
Một số dạng của acceptance testing là alpha testing và beta testing. Cả hai đều được thực thi bởi khách hàng của phần mềm, không phải là người phát triển phần mềm.
- Alpha testing được thực hiện tại nơi phát triển phần mềm.
- Beta testing được thực hiện tại nơi của khách hàng.

18. Một số kỹ thuật test Test tĩnh:
Dựa vào việc kiểm tra tài liệu, source code,… mà không cần phải thực thi phần mềm.
Các lỗi được tìm thấy trong quá trình kiểm tra có thể dễ dàng được loại bỏ và chi phí rẻ hơn nhiều so với khi tìm thấy trong test động. Một số lợi ích khi thực hiện việc kiểm tra (reviews):
Lỗi sớm được tìm thấy và sửa chữa
Giảm thời gian lập trình
Giảm thời gian và chi phí test
Không giống như test động (dynamic testing) là phải thực thi phần mềm, test tĩnh dựa vào việc kiểm tra tài liệu, code,… mà không cần phải thực thi phần mềm. Các lỗi được tìm thấy trong quá trình kiểm tra có thể dễ dàng được loại bỏ và chi phí rẻ hơn nhiều so với khi tìm thấy trong test động. Do đó việc kiểm tra (reviews) nên được thực hiện trước khi thực thi test động.
Một số lợi ích khi thực hiện việc kiểm tra (reviews):
-Lỗi sớm được tìm thấy và sửa chữa
-Giảm thời gian lập trình
-Giảm thời gian và chi phí test

19. Một số kỹ thuật test Test tĩnh (tt): Các tài liệu được kiểm thử:
Tài liệu đặc tả yêu cầu
Tài liệu đặc tả thiết kế
Sơ đồ luồng dữ liệu
Mô hình ER
Source code
Test case …
Không giống như test động (dynamic testing) là phải thực thi phần mềm, test tĩnh dựa vào việc kiểm tra tài liệu, code,… mà không cần phải thực thi phần mềm. Các lỗi được tìm thấy trong quá trình kiểm tra có thể dễ dàng được loại bỏ và chi phí rẻ hơn nhiều so với khi tìm thấy trong test động. Do đó việc kiểm tra (reviews) nên được thực hiện trước khi thực thi test động.
Một số lợi ích khi thực hiện việc kiểm tra (reviews):
-Lỗi sớm được tìm thấy và sửa chữa
-Giảm thời gian lập trình
-Giảm thời gian và chi phí test

20. Một số kỹ thuật test Test động: Dynamic Specification-based
Structure-based
Equivalence
Partitioning
Experience-based
Statement
Có rất nhiều kỹ thuật test, mỗi kỹ thuật có điểm mạnh và điểm yếu riêng. Một kỹ thuật có thể rất tốt để tìm kiếm một số lỗi nhất định nhưng lại yếu trong việc tìm kiếm các loại lỗi khác. Về cơ bản có 2 loại đó là test tĩnh và test động. Test tĩnh đã được đề cập đến trong chương 3. Test động lại được chia thành nhiều loại: specification-based (test dựa trên mô tả), structure-based (test dựa trên cấu trúc) và experience-based (test dựa trên kinh nghiệm).
Boundary Value
Analysis
Error
Guessing
Decision
Decision Tables
Condition
State Transition
Exploratory
Testing
Multiple condition
Use Case Testing

21. Một số kỹ thuật test Test động:
Test dựa trên mô tả (specification-based) hay còn gọi test chức năng (functional testing): Test những gì mà phần mềm phải làm, không cần biết phần mềm làm như thế nào (kỹ thuật black box)
Test dựa trên cấu trúc (structure-based) hay còn gọi test phi chức năng (non-functional testing): Test phần mềm hoạt động như thế nào (kỹ thuật white box)
Test dựa trên kinh nghiệm (experience-based): đòi hỏi sự hiểu biết, kỹ năng và kinh nghiệm của người test
Test dựa trên mô tả còn được gọi là black-box bởi vì chúng ta xem xét phần mềm với các dữ liệu đầu vào và đầu ra mà không cần biết cấu trúc của phần mềm ra sao. Nghĩa là tester (nhân viên kiểm thử) sẽ tập trung vào những gì mà phần mềm làm, không cần biết phần mềm làm như thế nào. Do tester đảm nhiệm
Test dựa trên mô tả còn được gọi là white-box hay glass-box bởi vì nó đòi hỏi sự hiểu biết về cấu trúc của phần mềm, nghĩa là phần mềm hoạt động như thế nào. Thường do lập trình viên đảm nhiệm
Test dựa trên kinh nghiệm đỏi hỏi sự hiểu biết, kỹ năng và kinh nghiệm của người test. Dựa vào những kinh nghiệm thu thập được từ những hệ thống trước đó,
tester có thể dễ dàng nhìn thấy được những điểm sai trong chương trình.

22. Kỹ thuật specification-based
Kỹ thuật phân vùng tương đương – EP (Equivalence Partitioning)
Ví dụ: một textbox chỉ cho phép nhập số nguyên từ 1 đến 100
 Ta không thể nhập tất cả các giá trị từ 1 đến 100
Ý tưởng của kỹ thuật này: chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence). Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại.
Test phi chức năng bao gồm performance testing (phần mềm chạy nhanh hay chậm), load testing (khả năng chịu đựng của phần mềm khi có nhiều transaction xảy ra cùng lúc), usability testing (test tính dễ sử dụng), maintainability testing (test tính dễ bảo trì),… Phi chức năng là test phần mềm hoạt động như thế nào (how the system works)
Confirmation testing (retesting): Sau khi một lỗi được tìm thấy và được sửa, phần mềm cần phải được test lại (retest) để chắc chắn là lỗi cũ đã bị loại bỏ.
Regression testing : Sau khi chương trình thay đổi, những phần khác của phần mềm cũng cần được test lại để chắc chắn không có lỗi mới nào phát sinh do sự thay đổi đó.

23. Kỹ thuật specification-based
Kỹ thuật phân vùng tương đương – EP (tt)
Trong ví dụ trên dùng kỹ thuật phân vùng tương đương, chia làm 3 phân vùng như sau:
Như vậy chỉ cần chọn 3 test case để test trường hợp này: -5, 55, 102 hoặc 0, 10, 1000, …
invalid
valid
Test phi chức năng bao gồm performance testing (phần mềm chạy nhanh hay chậm), load testing (khả năng chịu đựng của phần mềm khi có nhiều transaction xảy ra cùng lúc), usability testing (test tính dễ sử dụng), maintainability testing (test tính dễ bảo trì),… Phi chức năng là test phần mềm hoạt động như thế nào (how the system works)
Confirmation testing (retesting): Sau khi một lỗi được tìm thấy và được sửa, phần mềm cần phải được test lại (retest) để chắc chắn là lỗi cũ đã bị loại bỏ.
Regression testing : Sau khi chương trình thay đổi, những phần khác của phần mềm cũng cần được test lại để chắc chắn không có lỗi mới nào phát sinh do sự thay đổi đó. 1
100
101

24. Kỹ thuật specification-based
Kỹ thuật phân vùng tương đương – EP (tt)
Tuy nhiên nếu ta nhập vào số thập phân (55.5) hay một ký tự không phải là số (abc)?
Trong trường hợp trên có thể chia làm 5 phân vùng như sau:
Các số nguyên từ 1 đến 100
Các số nguyên nhỏ hơn 1
Các số nguyên lớn hơn 100
Không phải số
Số thập phân
Như vậy, việc phân vùng có đúng và đủ hay không là tùy thuộc vào kinh nghiệm của tester.
Test phi chức năng bao gồm performance testing (phần mềm chạy nhanh hay chậm), load testing (khả năng chịu đựng của phần mềm khi có nhiều transaction xảy ra cùng lúc), usability testing (test tính dễ sử dụng), maintainability testing (test tính dễ bảo trì),… Phi chức năng là test phần mềm hoạt động như thế nào (how the system works)
Confirmation testing (retesting): Sau khi một lỗi được tìm thấy và được sửa, phần mềm cần phải được test lại (retest) để chắc chắn là lỗi cũ đã bị loại bỏ.
Regression testing : Sau khi chương trình thay đổi, những phần khác của phần mềm cũng cần được test lại để chắc chắn không có lỗi mới nào phát sinh do sự thay đổi đó.

25. Kỹ thuật Boundary Value Analysis
Kỹ thuật phân tích giá trị giới hạn - BVA (Boundary Value Analysis)
Kỹ thuật BVA sẽ chọn các giá trị nằm tại các điểm giới hạn của phân vùng.
Áp dụng kỹ thuật BVA cần 4 test case để test trường hợp này: 0,1,10,101
Test phi chức năng bao gồm performance testing (phần mềm chạy nhanh hay chậm), load testing (khả năng chịu đựng của phần mềm khi có nhiều transaction xảy ra cùng lúc), usability testing (test tính dễ sử dụng), maintainability testing (test tính dễ bảo trì),… Phi chức năng là test phần mềm hoạt động như thế nào (how the system works)
Confirmation testing (retesting): Sau khi một lỗi được tìm thấy và được sửa, phần mềm cần phải được test lại (retest) để chắc chắn là lỗi cũ đã bị loại bỏ.
Regression testing : Sau khi chương trình thay đổi, những phần khác của phần mềm cũng cần được test lại để chắc chắn không có lỗi mới nào phát sinh do sự thay đổi đó.
invalid
valid 1
100
101

26. Kỹ thuật EP & BVA
Xét ví dụ: Một ngân hàng trả lãi cho khách hàng dựa vào số tiền còn lại trong tài khoản. Nếu số tiền từ 0 đến 100$ thì trả 3% lãi, từ lớn hơn 100 $ đến nhỏ hơn 1000$ trả 5% lãi, từ 1000$ trở lên trả 7% lãi.
Dùng kỹ thuật EP:
Kỹ thuật EP: -0.44, 55.00, ,
Kỹ thuật BVA: -0.01, 0.00, , , ,

27. Tại sao phải kết hợp BVA và EP
Mỗi giá trị giới hạn đều nằm trong một phân vùng nào đó. Nếu chỉ sử dụng giá trị giới hạn thì ta cũng có thể test luôn phân vùng đó.
Tuy nhiên vấn đề đặt ra là nếu như giá trị đó sai thì nghĩa là giá trị giới hạn bị sai hay là cả phân vùng bị sai. Hơn nữa, nếu chỉ sử dụng giá trị giới hạn thì không đem lại sự tin tưởng cho người dùng vì chúng ta chỉ sử dụng những giá trị đặc biệt thay vì sử dụng giá trị thông thường.
Vì vậy, cần phải kết hợp cả BVA và EP
Như ta thấy mỗi giá trị giới hạn đều nằm trong một phân vùng nào đó. Nếu chỉ sử dụng giá trị giới hạn thì ta cũng có thể test luôn phân vùng đó. Tuy nhiên vấn đề đặt ra là nếu như giá trị đó sai thì nghĩa là giá trị giới hạn bị sai hay là cả phân vùng bị sai. Hơn nữa, nếu chỉ sử dụng giá trị giới hạn thì không đem lại sự tin tưởng cho người dùng vì chúng ta chỉ sử dụng những giá trị đặc biệt thay vì sử dụng giá trị thông thường. => Nên kết hợp cả BVA và EP

28. Ví dụ Customer Name Account number Loan amount requested Term of loan
2-64 chars.
Customer Name
Account number
Loan amount requested
Term of loan
Monthly repayment
Term:
Repayment:
Interest rate:
Total paid back:
6 digits, 1st
non-zero
£500 to £9000
1 to 30 years
Minimum £10

29. Customer name Number of characters: 2 64 65 invalid valid 1
Valid characters:
Any other
A-Z
a-z -’
space
Conditions
Valid
Partitions
Invalid
Boundaries
Customer
name
2 to 64 chars
valid chars
< 2 chars
> 64 chars
invalid chars
2 chars
64 chars
1 chars
65 chars
0 chars

30. Account number first character: invalid: zero valid: non-zero 5 6 7
number of digits:
Conditions
Valid
Partitions
Invalid
Boundaries
Account
number
6 digits 1 st
non-zero
< 6 digits
> 6 digits
digit = 0
non-digit
100000
999999
5 digits
7 digits
0 digits

31. Loan amount 500 9000 9001 invalid valid 499 Conditions Valid
Partitions
Invalid
Boundaries
Loan
amount
< 500
>9000
non-numeric
null
500
9000
499
9001

32. Condition template Customer name 2 - 64 chars valid chars < 2 chars
Conditions
Valid
Partitions
Tag
Invalid
Boundaries
Customer
name
chars
valid chars V1 V2
< 2 chars
> 64 chars
invalid char X1 X2 X3
2 chars
64 chars B1 B2
1 char
65 chars
0 chars D1 D2 D3
Account
number
6 digits 1 st
non-zero V3 V4
< 6 digits
> 6 digits
digit = 0
non-digit X4 X5 X6 X7
100000
999999 B3 B4
5 digits
7 digits
0 digits D4 D5 D6
Loan
amount V5
< 500
>9000
non-integer
null X8 X9
X10
X11
X12
500
9000 B5 B6
499
9001 D7 D8

33. Design test cases Test Case Description Expected Outcome New Tags
Covered 1 2
Name: John Smith
Acc no:
Loan: 2500
Term: 3 years
Name: AB
Acc no:
Loan: 500
Term: 1 year
Term: 3 years
Repayment: 79.86
Interest rate: 10%
Total paid:
Term: 1 year
Repayment: 44.80
Interest rate: 7.5%
Total paid:
V1, V2,
V3, V4, V
B1, B3,
B5, .....

34. Vai trò Tester Kiểm lỗi phần mềm Kiểm lỗi bản đóng gói
Kiểm lỗi tài liệu
User guide
Installation Guide
Release Notes
Troubleshooting

35. Công việc Tester Chuẩn bị môi trường test Windows XP, 2000, 2003 Linux
IE, FireFox, Netscape, Mozilla
Test Database, Test data
Thiết kế Test case
Thực hiện test các Test case trong từng môi trường khác nhau
Mô tả Bug và chi tiết các bước để tạo ra bug
Theo dõi quá trình Fix Bug
Báo cáo kết quả test

36. Tài liệu tham khảo Testing Tools http://www.aptest.com/resources.html
Testing Course