CHƯƠNG 4 : CÁC KỸ THUẬT THIẾT KẾ KIỂM THỬ
4.3 Kỹ thuật kiểm thử Hộp đen hoặc Kiểm thử dựa trên đặc tả
4.3.4 Kiểm thử chuyển trạng thái
Một hệ thống có thể thể hiện một đáp ứng khác nhau tùy thuộc vào điều kiện hiện tại hoặc trước đó.
Kiểm thử chuyển đổi trạng thái được sử dụng nhiều trong ngành công nghiệp phần mềm nhúng và kỹ thuật tự động hóa nói chung. Tuy nhiên, kỹ thuật này cũng phù hợp để mơ hình hóa và kiểm thử các chức năng có các trạng thái cụ thể hoặc kiểm thử các luồng màn hình trên các chức năng hoặc ứng dụng.
Ví dụ: Chức năng rút tiền trong máy ATM sẽ có các trạng thái như: bắt đầu, chờ nhập
pin, kiểm tra pin lần 1, kiểm tra mã pin lần 2, kiểm tra mã pin lần 3, trạng thái nuốt thẻ nếu nhập sai mã pin 3 lần, trạng thái truy cập vào tài khoản nếu nhập đúng mã pin. Để
49
động gây ra trạng thái để viết các Test Cases, trong đó các hành động gây ra trạng thái là các bước trong Test Cases, cịn các trạng thái chính là điều kiện đầu vào hoặc kết quả mong đợi của các Test Cases đó.
Hình 4.5: Kiểm thử chuyển trạng thái
4.3.5 Kiểm thử theo mơ hình Use Case.
Kiểm thử theo mơ hình Use Case là một kỹ thuật kiểm thử bằng cách kiểm tra các chức năng của hệ thống và sự tương tác giữa các chức năng đó với nhau. Chúng ta có thể dựa trên mơ hình Use Case được thiết kế ở giai đoạn đặc tả phần mềm để viết các Test Cases kiểm thử từng chức năng, sự tương tác giữa các chức năng, mức độ đáp ứng và độ chính xác của dữ liệu khi các chức năng tương tác với nhau.
Ví dụ như khi kiểm thử một Use Case ATM, ta có thể kiểm thử một số trường hợp sau: - Khách hàng thực hiện chức năng rút tiền.
- Khách hàng thực hiện chức năng kiểm tra số dư.
- Khách hàng thực hiện chức năng gửi tiền vào tài khoản. - Khách hàng thực hiện chức năng chuyển khoản.
- Khách hàng thực hiện tổng hợp nhiều thao tác: gửi tiền vào tài khoản rồi kiểm tra số dư; rút tiền rồi kiểm tra số dư; chuyển tiền rồi kiểm tra số dư; rút tiền, nạp tiền rồi kiểm tra số dư,.....
4.4 Kỹ thuật kiểm thử hộp trắng hoặc kiểm thử dựa trên cấu trúc 4.4.1 Kiểm thử bao phủ câu lệnh (Statement Coverage). 4.4.1 Kiểm thử bao phủ câu lệnh (Statement Coverage).
Bao phủ Câu lệnh là việc đánh giá tỷ lệ phần trăm của các câu lệnh được thực thi được thực hiện bởi một bộ test suite.
50
Kỹ thuật kiểm thử bao phủ câu lệnh giúp tạo ra được những test cases để thực thi những câu lệnh cụ thể, mục đích để kiểm tra độ bao phủ câu lệnh, theo công thức sau:
Độ 𝑏𝑎𝑜 𝑝ℎủ 𝑐â𝑢 𝑙ệ𝑛ℎ =Số câu lệnh được thực thi
Tổng số câu lệnh × 100%
Theo cơng thức trên ta có thể thấy nếu độ bao phủ câu lệnh càng cao thì số câu lệnh được thực thi hoặc được kiểm tra qua càng nhiều, và để có nhiều câu lệnh được thực thi thì chúng ta phải thiết kế các test case với dữ liệu đầu vào sao cho nó đi qua được tất cả các câu lệnh, khơng bỏ sót câu lệnh nào.
- Một câu lệnh có thể nằm trên một dòng đơn hoặc trải dài qua nhiều dịng.
- Một dịng có thể chứa nhiều hơn một câu lệnh, chỉ một câu lệnh hoặc chỉ một phần của câu lệnh.
Ví dụ: Hãy nhìn vào đoạn code mẫu sau
Nếu chúng ta có các test cases với những giá trị đầu vào như sau: Test Case 1: A=2, B=3
Test Case 2: A=0, B=25 Test Case 3: A = 47, B=1
Với 3 bộ Test Case này chúng ta chỉ đi qua được 5 câu lệnh (vì khơng có test case nào cho giá trị C>50 để chạy được câu lệnh PRINT “Large C“), do đó ta chỉ có thể kiểm tra được 5 trên 6 câu lệnh, và độ bao phủ câu lệnh chỉ được 85%.
Để tăng độ bao phủ câu lệnh lên 100% (tức kiểm tra được 6/6 câu lệnh) thì bắt buộc ta phải thiết kế thêm test case với giá trị đầu vào sao cho chạy được câu lệnh PRINT “Large C“, ví dụ:
51
4.4.2 Kiểm thử bao phủ quyết định
Bao phủ Quyết định là việc đánh giá tỷ lệ phần trăm của các kết quả quyết định (ví dụ như các tùy chọn True hoặc False của một mệnh đề IF) được thực hiện bởi một bộ test suite. Ví dụ, nếu mệnh đề IF có 3 nhánh kết quả (3 quyết định) thì chúng ta phải thiết kế Test Cases với các bộ dữ liệu phù hợp để kiểm tra được hết 3 nhánh đó, đây chính là kiểm thử bao phủ quyết định.
Kỹ thuật bao phủ quyết định giúp chúng ta thiết kế được những Test Case có ý nghĩa để kiểm thử hết tất cả các quyết định (các nhánh kết quả) có thể có của một mệnh đề If, một vòng lặp Do-While, Repeat-Until, Case,... nhằm mục đích gia tăng độ bao phủ quyết định.
Ta có cơng thức sau:
Độ 𝑏𝑎𝑜 𝑝ℎủ 𝑞𝑢𝑦ế𝑡 đị𝑛ℎ =Số lượng các kết quả quyết định được thực thi
Tổng số các kết quả quyết định × 100% Bao phủ quyết định mạnh hơn bao phủ câu lệnh: 100% bao phủ quyết định đảm bảo 100% bao phủ câu lệnh, nhưng ngược lại thì khơng. Điều này có nghĩa là nếu ta thiết kế được các Test Case với những dữ liệu đầu vào đảm bảo kiểm thử được hết tất cả các nhánh quyết định (độ bao phủ câu lệnh = 100%) thì những Test Cases đó cũng đảm bảo chạy qua được hết các câu lệnh (độ bao phủ câu lệnh cũng bằng 100%) nhưng nếu chúng ta thiết kế được những Test Cases mà đảm bảo độ bao phủ câu lệnh bằng 100% thì chưa chắc đã kiểm tra được hết tất cả các nhánh quyết định (độ bao phủ quyết định chưa chắc được 100%).
52 Ví dụ: Xét đoạn Code sau:
Nếu chúng ta có Test Case: A=20, B=15 thì có thể đi qua được hết 6 câu lệnh (tức độ bao phủ câu lệnh = 100%) nhưng nếu xét về độ bao phủ quyết định thì Test Case này chỉ kiểm tra được ½ quyết định (tức độ bao phủ quyết định chỉ bằng 50%). Do đó, để tăng độ bao phủ quyết định lên 100% thì chúng ta phải bổ sung thêm Test Case để kiểm thử được hết các kết quả quyết định, ví dụ: Test Case: A=10, B=2
4.5 Kỹ thuật kiểm thử dựa trên kinh nghiệm
Kiểm thử dựa trên kinh nghiệm là kỹ thuật kiểm thử được phát triển dựa trên kỹ năng và trực giác của các tester cũng như kinh nghiệm của họ với các dự án hoặc công nghệ tương tự. Điều này có nghĩa là nếu tester kiểm thử càng nhiều dự án thì kinh nghiệm kiểm thử cũng như khả năng phán đoán lỗi của họ cũng cao hơn.
Kỹ thuật kiểm thử dựa trên kinh nghiệm được dùng để bổ sung cho kỹ thuật kiểm thử hộp đen hoặc hộp trắng, đồng thời cũng được sử dụng khi đặc tả yêu cầu không rõ ràng hoặc thiếu sót.
53
4.5.1 Đốn lỗi
Đốn lỗi là một kỹ thuật kiểm thử mà trong đó kinh nghiệm của tester được dùng để: - Dự đốn các lỗi có thể có trong hệ thống đang được kiểm tra mà có thể được phát
sinh ra trong quá trình lập trình.
- Thiết kế ra những bộ test đặc biệt để phát hiện được những lỗi tiềm ẩn trong hệ thống.
Danh sách lỗi có thể được xây dựng dựa trên:
- Các lỗi tìm được trên giao diện chức năng của phần mềm. - Các lỗi tiềm ẩn được phát hiện dựa trên kinh nghiệm của Tester.
- Kiến thức phổ biến về lý do tại sao phần mềm bị lỗi. Tester càng có kiến thức nhiều về các dạng phần mềm, các quy trình nghiệp vụ mà phần mềm đáp ứng thì khả năng tìm lỗi càng cao.
Một số mẫu tình huống lỗi có thể gặp như sau: - Khởi tạo dữ liệu.
- Sai loại dữ liệu. - Xử lý dữ liệu thực. - Lỗi phân quyền.
- Chức năng sao lưu, phục hồi.
- Xử lý đúng cách các thủ tục đồng thời.
4.5.2 Kiểm thử thăm dò
Kiểm thử thăm dò là một kỹ thuật kiểm thử mà trong đó tester:
- Chủ động kiểm soát thiết kế của các bộ test cũng như khi các bộ test này được thực thi.
- Sử dụng thơng tin thu được trong q trình kiểm thử để thiết kế ra những bộ test mới và tốt hơn.
- Theo nguyên lý kiểm thử “nghịch lý thuốc trừ sâu“ thì các Test Cases phải thường xuyên được cập nhật để phát hiện ra được những lỗi mới trong phần mềm. Kỹ thuật kiểm thử thăm dò sẽ giúp người kiểm thử (tester) thực hiện tốt nguyên lý này. Đây là một cách tiếp cận hữu ích khi:
- Đặc tả phần mềm không đầy đủ hoặc mơ hồ. - Áp lực thời gian của dự án.
54
4.6 Lựa chọn các kỹ thuật kiểm thử
Việc lựa chọn sử dụng các kỹ thuật kiểm thử nào phụ thuộc vào một số yếu tố như sau: - Loại hệ thống.
- Các tiêu chuẩn quy định.
- Yêu cầu của khách hàng hoặc hợp đồng. - Mức độ của rủi ro; Loại rủi ro.
- Mục tiêu kiểm thử.
- Những tài liệu, tài nguyên có sẵn. - Kiến thức của người kiểm thử. - Thời gian và ngân sách.
55
BÀI TẬP
Bài tập 1:
Trong phần mềm mua vé xe điện online có quy luật như sau: Nếu bạn đi xe điện chuyến trước 9:30 sáng hoặc từ sau 4:00 chiều đến 7:30 tối (giờ cao điểm), thì bạn phải mua vé thường. Vé tiết kiệm (giá thấp hơn vé thường) có hiệu lực cho các chuyến xe từ 9:30 sáng đến 4:00 chiều và sau 7:30 tối.
Dựa vào quy luật trên, các bạn hãy:
1, Liệt kê ra các vùng và các giá trị biên để kiểm thử thời gian của tàu đối với các loại vé.
2, Liệt kê các vùng hợp lệ và không hợp lệ. Cho biết đâu là giá trị biên (Dùng bảng để dễ liệt kê các vùng tương đương và các giá trị biên).
Đáp án:
Chúng ta giả sử tàu hoạt động từ 4h sáng (4:00) đến 11h đêm (23:00). Ta có bảng
liệt kê các vùng tương đương và các giá trị biên:
56
Bài tập 2: Tạo file Q&A List để làm rõ yêu cầu phần mềm
Sinh viên thực hiện đọc hiểu tài liệu đặc tả yêu cầu phần mềm (File DMS1_SRS_DefectManagement_v1.0 được đính kèm trong PHỤ LỤC 1) và đặt câu hỏi để làm rõ yêu cầu phần mềm đó (đặt tối thiểu 30 câu hỏi để làm rõ yêu cầu phần mềm, file Hướng dẫn cách đặt câu hỏi được đính kèm trong PHỤ LỤC 2).
Bài tập 3: Viết Test Cases để kiểm thử các chức năng trong phần mềm
Sinh viên tiến hành viết Test Case để kiểm thử các chức năng sau trong phần mềm DMS:
- Chức năng Add Defect (viết ít nhất 100 Test Cases) - Chức năng Attachment Screen (viết ít nhất 30 Test Cases)
57
CHƯƠNG 5: QUẢN LÝ KIỂM THỬ
MỤC TIÊU THỰC HIỆN: Sau khi học xong chương này, sinh viên có khả năng:
- Trình bày được quy trình tổng quát cũng như các cơng việc trong q trình quản lý kiểm thử.
- Tự tổ chức và quản lý được hoạt động kiểm thử một dự án nhỏ theo quy định. - Viết báo cáo và trình bày kết quả kiểm thử đã thực hiện được của nhóm theo
hướng dẫn.
- Tham gia một cách chủ động và tích cực vào các cơng việc được giao.
5.1 Tổ chức kiểm thử
5.1.1 Tổ chức kiểm thử độc lập
Hiệu quả của việc tìm lỗi có thể được cải thiện nâng cao nhờ có những Tester độc lập.
Có thể có những loại hình kiểm thử độc lập như sau:
- Khơng có các đội ngũ kiểm thử độc lập. Các lập trình viên tự kiểm thử Code của chính họ. Các lập trình viên vừa lập trình vừa viết Unit Test để kiểm thử những chức năng mình viết.
- Tester độc lập bên trong nhóm phát triển phần mềm. Trong một dự án phần mềm sẽ có các lập trình viên và có một hoặc vài nhân viên kiểm thử theo xuyên xuốt dự án để kiểm thử dự án phần mềm đó. Loại hình này có thuận lợi là nhân viên kiểm thử và lập trình viên trao đổi cơng việc với nhau thuận lợi, hiểu rõ yêu cầu phần mềm, hạn chế việc hiểu sai yêu cầu vì kiểm thử và lập trình viên nằm chung nhóm phát triển nên việc truyền thông cũng hiệu quả hơn. Tuy nhiên, vấn đề khách quan trong kiểm thử cũng cần phải được quan tâm trong trường hợp này. - Nhóm kiểm thử độc lập trong tổ chức hoặc công ty. Trong trường hợp này, bên
trong tổ chức hoặc cơng ty sẽ có một đội kiểm thử riêng làm nhiệm vụ kiểm thử cho các dự án và nghiên cứu phát triển kiểm thử để mang lại hiệu quả kiểm thử cao nhất. Khi có dự án phần mềm, trưởng dự án có thể nhờ đội kiểm thử hỗ trợ kiểm thử dự án, khi đó trưởng nhóm kiểm thử có thể cử nhân viên qua hỗ trợ, một nhân viên kiểm thử có thể kiểm thử một hoặc nhiều dự án một lúc. Loại hình
58
này hiện nay được các tổ chức và cơng ty áp dụng nhiều vì tính chun nghiệp và khách quan của nó.
- Những đội ngũ kiểm thử độc lập được thuê từ bên ngồi cơng ty. Có những cơng ty chuyên làm nhiệm vụ kiểm thử thuê cho các công ty khác hoặc cung cấp giải pháp kiểm thử phần mềm cho các cơng ty khác. Loại hình này đem lại tính chun nghiệp và khách quan cao, tuy nhiên vấn đề cần quan tâm là việc truyền thông giữa đội ngũ phát triển phần mềm trong công ty và đội ngũ kiểm thử bên ngoài cần phải như thế nào để các đặc tả yêu cầu phần mềm được hiểu rõ và thống nhất cao.
Ngồi ra cịn có những tùy chọn kiểm thử độc lập khác như:
- Các đội ngũ kiểm thử từ công ty của khách hàng hoặc từ cộng đồng người sử dụng phần mềm.
- Các chuyên gia hoặc các tổ chức kiểm thử độc lập như các tổ chức kiểm thử bảo mật, kiểm thử tính khả dụng của phần mềm, hoặc các tổ chức kiểm tra chứng nhận.
Lợi ích của kiểm thử độc lập bao gồm:
- Các Tester độc lập có thể nhìn thấy được nhiều loại lỗi khác nhau ở mọi ngóc ngách của phần mềm một cách khách quan và không thiên vị.
- Một Tester độc lập có thể xác minh các giả định mà mọi người đưa ra trong quá trình đặc tả và triển khai hệ thống. Các Tester có thể đóng vai trị là người dùng trong suốt quá trình kiểm thử phần mềm để hiểu người dùng mong muốn gì từ đó sẽ có hướng kiểm thử phù hợp hơn, đáp ứng đầy đủ các yêu cầu của người dùng hơn.
Ngồi những lợi ích khi có đội ngũ kiểm thử độc lập, chúng ta cần phải quan tâm đến những vấn đề sau:
- Một vấn đề vừa là điểm mạnh và cũng là khó khăn đối với đội ngũ kiểm thử độc lập đó là sự cơ lập với nhóm phát triển phần mềm. Các tester độc lập có ưu điểm là kiểm thử khách quan, không thiên vị, tuy nhiên một vấn đề gặp phải là vấn đề truyền thông giữa Tester độc lập và các lập trình viên, đội ngũ thiết kế,..để hiểu rõ yêu cầu phần mềm cũng như những thay đổi yêu cầu từ phía khách hàng, nếu truyền thơng khơng tốt có thể dẫn đến hiểu sai yêu cầu, yêu cầu chưa kịp cập
59
nhật,... Do đó cần có các buổi review và các buổi daily scrum thường xuyên để cập nhật tiến độ cũng như những thay đổi yêu cầu từ phía khách hàng.
- Các tester độc lập có thể là nút cổ chai như là điểm kiểm tra cuối cùng. Dự án trước khi bàn giao cho khách hàng thì phải qua đội ngũ kiểm thử để đảm bảo chất lượng phần mềm, tuy nhiên nếu các developer lập trình khơng tốt dẫn đến phần mềm kém chất lượng, có nhiều lỗi sẽ dẫn đến quá trình kiểm thử và sửa lỗi sẽ tốn