Bài giảng Kiểm thử phần mềm - Chương 9: Các hoạt ₫ộng kiểm thử khác - Nguyễn Văn Hiệp

 
₫ịnh dạng). 
 Công việc của người kiềm thử là chú ý ₫ặc biệt vào dữ liệu tìm 
kiếm và hiển thị vì người dùng có thể chọn sai dữ liệu hay tệ hơn là 
không có kết quả nào ₫ược hiển thị. 
5. Kiểm thử luồng báo biểu (Report Flow Test) 
 Kiểm thử các khác biệt giữa kết quả hiển thị trong màn hình 
báo biểu và các phương thức báo biểu khác (như máy in, file,..). 
 Nhiệm vụ của người kiểm thử : 
 ƒ Xác ₫ịnh xem phần mềm gởi cùng kết quả ra màn hình 
 report và máy in ? 
 ƒ Xác thực kết quả báo biểu trên tất cả phương thức báo cáo 
 khác nhau ₫ược hỗ trợ bởi phần mềm. 
 ƒ Xác ₫ịnh xem khả năng máy in có hỗ trợ font, vùng chọn 
 ₫ược người dùng xác ₫ịnh trong màn hình báo biểu ? 
6. Kiểm thử việc Create/Retrieve/Update/Delete database 
 Thường ₫ược thực hiện thông qua 2 bước : 
 ƒ Kiểm thử việc thiết kế, khởi tạo database ban ₫ầu thông 
 qua tiện ích bên ngoài phần mềm ứng dụng cần kiểm thử. 
 ƒ Kiểm thử việc phần mềm sử dụng database ₫ã ₫ược thiết 
 kế và khởi tạo ₫úng. 
 Đòi hỏi sự hợp tác và cộng tác giữa người kiểm thử và người 
quản trị database. 
9.3 Kiểm thử hệ thống 
 Kiểm thử hệ thống không phải là qui trình kiểm thử toàn bộ 
chức năng của 1 chương trình hay của 1 hệ thống phần mềm ₫ầy 
₫ủ. 
 Mục ₫ích của kiểm thử hệ thống là so sánh hệ thống hay 
chương trình với các mục tiêu ban ₫ầu của nó. 
 Kiểm thử hệ thống không bị hạn chế với các hệ thống phần 
mềm. Nếu sản phẩm cần kiểm thử là 1 chương trình, kiểm thử hệ 
thống là qui trình cố gắng chứng minh cách mà toàn bộ phần mềm 
không thỏa mản các mục tiêu của nó. 
 Theo ₫ịnh nghĩa trên, kiểm thử hệ thống không thể xảy ra 
₫ược nếu ta không viết ra rõ ràng các thông tin ₫o ₫ạt ₫ược về các 
mục tiêu của chương trình. 
 Thí dụ về ₫ặc tả mục tiêu của chương trình : 
 ƒ Hãy hiện thực 1 hàng lệnh ₫ể từ cửa sổ text-mode, người 
 dùng xem các nội dung chi tiết về các ô nhớ trong bộ nhớ 
 chính của phần mềm. 
 ƒ Cú pháp của hàng lệnh nên nhất quán với cú pháp của 
 các lệnh khác mà hệ thống cung cấp. 
 ƒ Người dùng nên có thể ₫ặc tả vùng nhớ thông qua 2 ₫ịa 
 chỉ ₫ầu cuối hay thông qua ₫ịa chỉ ₫ầu và số lượng ô nhớ 
 cần xem. 
 ƒ Các toán hạng của lệnh nên có nhiệm ý gợi nhớ. 
 ƒ Kết quả nên xuất trên nhiều hàng, nội dung của từng ổ 
 nhớ ở dạng hex cách nhau bởi 1 hay nhiều khoảng trắng. 
 ƒ Mỗi hàng nên chứa ₫ịa chỉ của ô nhớ ₫ầu hàng ₫ó. 
 ƒ Lệnh là bình thường, nghĩa là nếu máy ₫ang chạy bình 
 thường, nó sẽ bắt ₫ầu xuất kết quả trong vài giây và kết 
 quả xuất không có thời gian chờ giữa các ô nhớ trong hàng 
 hay giữa các hàng. 
 ƒ Lỗi lập trình ít nhất nên làm cho lệnh bị dừng, hệ thống và 
 session người dùng không bị ảnh hưởng gì hết. 
 ƒ Sau khi hệ thống bắt ₫ầu xuất kết quả, bộ xử lý lệnh không 
 nên có hơn 1 lỗi do người dùng phát hiện ₫ược. 
 Kiểm thử hệ thống là qui trình kiểm thử quan trọng. 
 Các chất liệu ₫ể tạo testcase cho kiểm thử hệ thống : 
 ƒ Chúng ta không chỉ dùng ₫ặc tả theo góc nhìn người dùng 
 ₫ể suy ra các testcase. 
 ƒ Tài liệu về mục tiêu chương trình, tự nó cũng không thể 
 ₫ược dùng ₫ể tạo ra các testcase, vì theo ₫ịnh nghĩa, nó 
 không chứa các miêu tả chính xác, rõ ràng về giao tiếp từ 
 ngoài vào chương trình. 
 ƒ ta sẽ dùng tài liệu sử dụng và những công bố cho người 
 dùng. 
 Thiết kế testcase bằng cách phân tích các mục tiêu. 
 Tạo các testcase bằng cách phân tích tài liệu dành cho người 
dùng. 
 Kiểm thử hệ thống là hoạt ₫ộng kiểm thử khó khăn nhất 
 Phải so sánh chương trình với các mục tiêu ban ₫ầu : nên 
không có phương pháp luận thiết kế testcase tường minh. 
 Dùng cách tiếp cận khác ₫ể thiết kế testcase : 
 ƒ Thay vì miêu tả phương pháp luận, các loại testcase riêng 
 biệt sẽ ₫ược ₫ề cập. 
 ƒ Do không có phương pháp luận, kiểm thử hệ thống ₫òi hòi 
 rất nhiều sự năng ₫ộng và sáng tạo. 
 Kiểm thử hệ thống tập trung vào kiểm thử các yêu cầu không 
chức năng. Có 15 yêu cầu không chức năng sau ₫ây có thể cần 
kiểm thử (nhưng không phải phần mềm nào cũng ₫òi hỏi ₫ủ 15 
yêu cầu này) : 
 ƒ Facility Testing 
 ƒ Volume Testing 
 ƒ Stress Testing 
 ƒ Usability Testing 
 ƒ Security Testing 
 ƒ Performance Testing 
 ƒ Storage Testing 
 ƒ Configuration Testing 
 ƒ Compatibility/Configuration/Conversion Testing 
 ƒ Installability Testing 
 ƒ Reliability Testing 
 ƒ Recovery Testing 
 ƒ Serviceability Testing 
 ƒ Documentation Testing 
 ƒ Procedure Testing 
1. Kiểm thử phương tiện (Facility Test) 
 xác ₫ịnh xem mỗi phương tiện ₫ược ₫ề cập trong phần mục 
tiêu của chương trình ₫ã ₫ược hiện thực thực sự chưa. 
 Qui trình kiểm thử : 
 ƒ Dò nội dung, từng câu một, miêu tả mục tiêu. 
 ƒ Khi 1 câu miêu tả cái gì, xác ₫ịnh chương trình ₫ã thỏa 
 mãn cái ₫ó chưa. 
 Thường ta có thể thực hiện kiểm thử phương tiện mà không 
cần chạy máy tính, so sánh bằng trí óc các mục tiêu với tài liệu sử 
dụng ₫ôi khi ₫ủ rồi. 
2. Kiểm thử dung lượng (Volume Test) 
 Mục ₫ích của kiểm thử dung lượng là chỉ ra rằng chương trình 
không thể xử lý khối lượng dữ liệu lớn ₫ược ₫ặc tả trong bảng ₫ặc 
tả mục tiêu chương trình. 
 Thí dụ : 
 ƒ Chương trình dịch không thể dịch file mã nguồn dài 10MB. 
 ƒ Trình liên kết không thể liên kết 1000 module chức năng 
 khác nhau lại. 
 ƒ Trình xem phim không thể chiếu file film dài 15GB. 
 Kiểm thử dung lượng thường ₫òi hỏi rất nhiều tài nguyên, con 
người lẫn máy tính. 
3. Kiểm thử tình trạng căng thẳng (StressTest) 
 Mục ₫ích của kiểm thử tình trạng căng thẳng là chỉ ra rằng 
chương trình sẽ không thể hoạt ₫ộng ₫ược hay hoạt ₫ộng không 
tốt trong tình huống căng thẳng : quá nhiều yêu cầu ₫ồng thời, quá 
nhiều chương trình khác ₫ang cạnh tranh tài nguyên,... 
 Thí dụ : 
 ƒ web server sẽ bế tắc nếu có 100000 yêu cầu truy xuất 
 trang web ₫ồng thời. 
 ƒ HĐH không thể quản lý 1000 process chạy ₫ồng thời. 
 ƒ Trình chiếu phim sẽ không chiếu phim mượt và tốt nếu có 
 nhiều chương trình khác cần rất nhiều tài nguyên ₫ang 
 chạy. 
4. Kiểm thử ₫ộ khả dụng (UsabililyTest) 
 Mục ₫ích của kiểm thử ₫ộ khả dụng là chỉ ra các phương 
tiện/kết quả nhập/xuất không phù hợp, thân thiện với người dùng : 
 ƒ Mỗi ₫ối tượng giao diện có thân thiện, tự nhiên và dễ dùng 
 không ? 
 ƒ Kết quả xuất có ngắn gọn, trong sáng, nghĩa dễ hiểu 
 không ? 
 ƒ Các cảnh báo có dễ hiểu không ? “IEK022A OPEN 
 ERROR ON FILE ‘SYSIN’ ABEND CODE=102?” 
 ƒ Nói chung tất cả các kết quả, các cảnh báo ₫ều phải nhất 
 quán, ₫ồng nhất về cú pháp, về ₫ịnh dạng, ngay cả các từ 
 viết tắt ₫ược dùng. 
 Một số chú ý : 
 ƒ Khi ₫ộ chính xác là rất quan trọng như trong hệ thống 
 quản lý ngân hàng, thì thông tin nhập có tính dư thừa ₫ủ 
 không ? 
 ƒ Hệ thống có quá nhiều nhiệm ý hay các nhiệm ý ₫ược 
 người dùng thích dùng không ? 
 ƒ Hệ thống có trả về ₫ủ ₫áp ứng với mọi hoạt ₫ộng nhập ? 
 ƒ Chương trình có dễ dùng và thân thiện ? 
5. Kiểm thử các dịch vụ cộng thêm (Serviceability Test) 
 Trong mục tiêu của phần mềm có thể ₫ề cập ₫ến 1 số dịch vụ 
cộng thêm, thí dụ như : 
 ƒ Chương trình chẩn ₫oán và xuất nội dung thô của bộ nhớ 
 chương trình. 
 ƒ Thời gian trung bình ₫ể debug 1 vấn ₫ề rõ ràng. 
 ƒ Các thủ tục bảo trì. 
 ƒ Chất lượng của tài liệu luận lý bên trong. 
 Các mục tiêu trên, nếu có ₫ề cập trong mục tiêu chương trình 
thì cần phải ₫ược kiểm thử. 
6. Kiểm thử tính an ninh (Security Test) 
 An ninh phần mềm gồm 3 vấn ₫ề chính là bảo mật, tính toàn 
vẹn dữ liệu và ₫ộ sẵn sàng ₫áp ứng. 
 Nghiên cứu các vấn ₫ề liên quan ₫ến an ninh trong các hệ 
thống tương tự rồi tạo các testcase ₫ể chứng minh rằng các vấn ₫ề 
này cũng tồn tại trong chương trình cần kiểm thử. 
 Các ứng dụng mạng và ứng dụng theo công nghệ Web hiện 
nay cần ₫ược kiểm thử tính an ninh ở mức ₫ộ cao hơn nhiều so với 
phần mềm truyền thống trên máy ₫ơn. Điều này ₫ặc biệt ₫úng cho 
các website thương mại, ngân hàng... 
7. Kiểm thử hiệu xuất làm việc (Performance Test) 
 Mục ₫ich của kiểm thử hiệu xuất làm việc là chỉ ra rằng phần 
mềm không ₫ạt ₫ược hiệu xuất ₫ược ₫ặc tả trong mục tiêu chương 
trình. 
 Thí dụ : 
 ƒ trình chiếu phim full HD không chiếu kịp 20 frame/sec. 
 ƒ trình nén dữ liệu không nén dữ liệu kịp với tốc ₫ộ ₫ề ra. 
 ƒ trình soạn thảo văn bản không nhận và xử lý kịp các ký tự 
 ₫ược nhập bởi người dùng. 
 ƒ trình ghi DVD không tạo dữ liệu ghi kịp tốc ₫ộ mà ổ DVD 
 yêu cầu... 
8. Kiểm thử ₫ộ sử dụng bộ nhớ (Storage Test) 
 Mục ₫ich của kiểm thử ₫ộ sử dụng bộ nhớ là chỉ ra rằng phần 
mềm không tuân thủ về dung lượng bộ nhớ tối thiểu/tối ₫a ₫ược 
₫ặc tả trong mục tiêu chương trình. 
 Thí dụ : 
 ƒ kích thước tối thiểu 128KB không ₫ủ ₫ể chạy chương trình. 
 ƒ chương trình không dùng hết kích thước bộ nhớ tối ₫a là 
 4GB. 
 ƒ chương trình không chạy ₫ược khi ₫ĩa còn dung lượng 
 trống tối thiểu là 4MB. 
 ƒ chương trình không quản lý ₫ược dung lượng ₫ĩa là 1TB... 
9. Kiểm thử cấu hình làm việc (Configuration Test) 
 Nhiều chương trình như HĐH, hệ quản trị CSDL, Website,... 
thường sẽ làm việc ₫ược trên nhiều cấu hình phần cứng/phần mềm 
cấp thấp. Số lượng các cấu hình khác nhau có thể quá lớn, nhưng 
ta nên chọn 1 số cấu hình phổ dụng nhất ₫ể kiểm thử xem chương 
trình có chạy tốt trên các cầu hình này không. 
10. Kiểm thử tính tương thích/chuyển ₫ổi/cấu hình (Compatibility/ 
Configuration/Conversion Test) 
 Đời sống của 1 phần mềm thường dài, nhất là phần mềm 
thương mại của các hãng lớn. Trong cuộc ₫ời của mình, phần 
mềm ₫ược phát triển tăng dần theo từng release, từng version. Về 
nguyên tắc, version mới sẽ tương thích ngược với version ₫ã có. 
 Mức ₫ộ tương thích, khả năng chuyển ₫ổi ₫ịnh dạng file dữ liệu 
từ cũ sang mới hay ngược lại, khả năng cấu hình version mới ₫ể có 
thể làm việc như version cũ,... có thể ₫ược ₫ặc tả trong mục tiêu 
của chương trình. 
 Nếu có thì ta phải kiểm thử các ₫ặc tả này xem version cần 
kiểm thử có ₫áp ứng ₫ược không. 
 Thí dụ : Word 2003 có thể cấu hình ₫ể chạy y như Word 97 
không ? 
11. Kiểm thử khả năng cài ₫ặt (Installability Test) 
 Một số hệ thống phần mềm có thủ tục cài ₫ặt khá phức tạp. 
 Chương trình cài ₫ặt chạy sai có thể ngăn chận người dùng 
không dùng ₫ược phần mềm ₫ược cài ₫ặt. 
 Nhiệm vụ của kiểm thử khả năng cài ₫ặt là kiểm thử chương 
trình cài ₫ặt có hoạt ₫ộng ₫úng không ? 
12. Kiểm thử ₫ộ tin cậy (Reliability Test) 
 Mục tiêu của mọi loại kiểm thử ₫ều hướng ₫ến việc cải tiến ₫ộ 
tin cậy của chương trình. 
 Nếu mục tiêu của chương trình chứa các phát biểu ₫ặc biệt về 
₫ộ tin cậy, ta cũng cần phải thực hiện hoạt ₫ộng kiểm thử ₫ộ tin 
cậy ₫ặc thù. 
 Việc kiểm thử các mục tiêu về ₫ộ tin cậy có thể khó khăn. Thí 
dụ, 1 hệ thống online hiện ₫ại như WAN hay ISP thường có thời 
gian làm việc thực tế bằng 99.97% thời gian sống của nó. 
 Chưa có cách ₫ể ta có thể kiểm thử mục tiêu này với thời gian 
kiểm thử hàng tháng hay hàng năm. 
13. Kiểm thử ₫ộ phục hồi sau lỗi (Recovery Test) 
 Các chươnng trình như hệ ₫iều hành, hệ quản trị database, 
các chương trình xử lý từ xa thường có các mục tiêu về phục hồi 
sau lỗi ₫ể miêu tả cách hệ thống phục hồi sau khi lỗi dữ liệu, lỗi 
phần mềm hay lỗi phần cứng xảy ra. 
 Mục tiêu của kiểm thử ₫ộ phục hồi sau lỗi: 
 ƒ chỉ ra rằng các chức năng phục hồi không làm việc ₫úng. 
 ƒ chỉ ra rằng hệ thống không thỏa sự thỏa thuận về thời gian 
 trung bình ₫ể phục hồi sau lỗi (MTTR). 
14. Kiểm thử tài liệu (Documentation Test) 
 Kiểm thử hệ thống cũng có liên quan ₫ến ₫ộ chính xác của tài 
liệu dành cho người dùng. 
 Cách chính yếu ₫ể thực hiện ₫iều này là dùng tài liệu ₫ể xác 
₫ịnh các testcase hệ thống có ₫ộ ưu tiên cao. 
 Tài liệu dành cho người dùng nên là chủ ₫ề của 1 hoạt ₫ộng 
thanh tra (tương tự như khái niệm thanh tra mã nguồn), hãy kiểm 
tra nó ₫ể biết ₫ược ₫ộ chính xác và tính trong sáng. 
15. Kiểm thử thủ tục (Procedure Test) 
 Nhiều phần mềm là thành phần của hệ thống lớn hơn nhưng 
chưa ₫ược tự ₫ộng hóa hoàn toàn liên quan ₫ến nhiều thủ tục mà 
con người cần thực hiện. 
 Bất kỳ thủ tục của con người nào ₫ược kê ra, như thủ tục dành 
cho người quản trị hệ thống, quản trị database, người dùng ₫ầu 
cuối nên ₫ược kiểm thử trong suốt hoạt ₫ộng kiểm thử hệ thống. 
9.4 Kiểm thử ₫ộ chấp nhận của user (Acceptance) 
 là qui trình so sánh chương trình thực tế với các yêu cầu ban 
₫ầu của nó và với các nhu cầu hiện hành của người dùng ₫ầu 
cuối. 
 Thường ₫ược thực hiện bởi khách hàng hay người dùng ₫ầu 
cuối và thường không ₫ược coi như là 1 trách nhiệm của tổ chức 
phát triển phần mềm. 
 Trong trường hợp chương trình làm theo hợp ₫ồng, bên ₫ặt 
hàng thực hiện kiểm thử ₫ộ chấp nhận bằng cách so sánh hoạt 
₫ộng của chương trình với các ₫iều khoản trong hợp ₫ồng. 
 Trong trường hợp chương trình thương mại như HĐH, trình 
biên dịch, hệ quản trị CSDL, khách hàng nhạy cảm sẽ thực hiện 
kiểm thử ₫ộ chấp nhận ₫ể xác ₫ịnh xem sản phẩm có thỏa mãn 
các yêu cầu của họ không ? 
9.5 Kiểm thử việc cài ₫ặt (Installation) 
 Mục ₫ích của kiểm thử việc cài ₫ặt không phải là tìm lỗi của 
phần mềm mà là tìm lỗi xảy ra trong quá trình cài ₫ặt phần mềm. 
Hiện nay, hầu hết các chương trình ₫ều có chương trình cài ₫ặt 
kèm theo. 
 Có nhiều sự kiện xảy ra trong quá trình cài ₫ặt hệ thống phần 
mềm : 
 ƒ Người dùng phải chọn 1 trong nhiều options. 
 ƒ Các file và thư viện phải ₫ược phân phối và tải về. 
 ƒ Các cấu hình phần cứng hợp lệ phải có sẵn. 
 ƒ Chương trình có thể cần nối mạng ₫ể giao tiếp với các 
 phần mềm trên các máy khác. 
 Các testcase có thể kiểm tra ₫ể ₫ảm bảo rằng : 
 ƒ 1 tập các option tương thích nhau ₫ã ₫ược chọn. 
 ƒ tất cả các thành phần của hệ thống phần mềm ₫ã có sẵn. 
 ƒ tất cả các file ₫ã ₫ược tạo ra và có nội dung cần thiết. 
 ƒ Cấu hình phần cứng phù hợp. 
 Nên ₫ược phát triển bởi ₫ơn vị tạo hệ thống phần mềm, ₫ược 
phân phối như là 1 thành phần của hệ thống phần mềm và chạy 
sau khi hệ thống ₫ược cài ₫ặt. 
9.6 Kiểm thử hồi qui (Regression) 
 Kiểm thử hồi qui là chạy lại các testcase ₫ã có trên TPPM ₫ã 
₫ược hiệu chỉnh nâng cấp ₫ể ₫ảm bảo rằng những thay ₫ổi của 
TPPM không có ảnh hưởng lề nào, rằng TPPM vẫn ₫áp ứng tốt với 
những testcase trước ₫ây. 
 Thường ₫ược bắt ₫ầu khi code mới ₫ang viết và code hiện 
hành ₫ang ₫ược cập nhật. 
 Cũng ₫ược thực hiện từ version này sang version khác phần 
mềm. 
 Qui trình lý tưởng là tạo 1 tập testcase bao quát và chạy nó 
sau mỗi lần có thay ₫ổi phần mềm. 
 Các kỹ thuật chọn kiểm thử hồi qui : 
 ƒ Hiệu suất không tiên lượng 
 ƒ Các giả ₫ịnh về process không tương thích 
 ƒ Các mô hình ₫ánh giá không thích hợp 
 ƒ Có thể ₫ược tự ₫ộng hóa 
9.6 Kết chương 
 Chương này ₫ã giới thiệu lý do cần nhiều hoạt ₫ộng kiểm thử 
khác nhau, trong ₫ó kiểm thử ₫ơn vị mà ta ₫ã giới thiệu trong các 
chương trước chỉ là 1 hoạt ₫ộng kiểm thử ₫ầu tiên. 
 Chúng ta cũng ₫ã giới thiệu các vấn ₫ề cơ bản liên quan ₫ến 
các hoạt ₫ộng kiểm thử khác như kiểm thử chức năng của chương 
trình, kiểm thử các yêu cầu không chức năng, kiểm thử ₫ộ chấp 
thuận của người dùng, kiểm thử việc cài ₫ặt phần mềm, kiểm thử 
hồi qui.