Bài giảng Kiểm tra phần mềm - Chương 9: Các hoạt động kiểm thử khác

Nội dung text: Bài giảng Kiểm tra phần mềm - Chương 9: Các hoạt động kiểm thử khác

1. 3. Đặc tả các chức năng mà người dùng thấy về phần mềm. 4. Thiết kế hệ thống và thiết kế cấu trúc cụ thể và chi tiết của phần mềm. 5. Đặc tả giao tiếp của từng module chức năng. 6. Hiện thực chi tiết các chức năng của từng module. Về nguyên tắc, con người có những hạn chế nhất ₫ịnh, kết quả của 1 công việc nào ₫ó ₫ều có thể có lỗi, và nếu dùng kết quả này làm dữ liệu ₫ầu vào cho hoạt ₫ộng kế tiếp thì kết quả của hoạt ₫ộng kế cũng sẽ bị lỗi, Ta thường dùng tổ hợp 2 biện pháp sau ₫ây ₫ể hạn chế/ngăn ngừa các lỗi : ƒ Xác ₫ịnh lại cho rõ ràng và chi tiết hơn từng workflows của qui trình phát triển phần mềm. ƒ Ở cuối việc thực hiện 1 workflows bất kỳ, cần thêm 1 hoạt ₫ộng ₫ược gọi là "thanh kiểm tra kết quả" ₫ể ₫ảm bảo chất lượng kết quả này trước khi dùng nó ₫ể thực hiện workflow kế tiếp.
2. Mục ₫ích của kiểm thử chức năng là chỉ ra rằng chương trình không tương thích với các ₫ặc tả bên ngoài của nó. Mục ₫ích của kiểm thử hệ thống là chỉ ra rằng chương trình không tương thích với các mục tiêu ban ₫ầu của nó. Các lợi ích : ƒ tránh kiểm thử dư thừa. ƒ ngăn chặn sự quan tâm nhiều vào quá nhiều loại lỗi tại từng thời ₫iểm. Chú ý : trình tự các hoạt ₫ộng kiểm thử trong hình ở slide trước không nhất thiết ám chỉ trình tự thời gian kiểm thử tương ứng. 9.2 Kiểm thử chức năng Qui trình cố gắng tìm ra các khác biệt giữa ₫ặc tả bên ngoài của phần mềm và thực tế mà phần mềm cung cấp. Đặc tả bên ngoài của phần mềm là ₫ặc tả chính xác về hành vi của phần mềm theo góc nhìn của người dùng thấy. Kiểm thử chức năng thường sử dụng 1 kỹ thuật kiểm thử hộp ₫en nào ₫ó : ƒ Kỹ thuật phân lớp tương ₫ương (Equivalence Class Partitioning). ƒ Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables) ƒ Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise) ƒ Kỹ thật phân tích vùng miền (domain analysis) ƒ Kỹ thuật dựa trên ₫ặc tả Use Case (Use case) ƒ Các cách tiếp cận ₫ể kiểm thử chức năng phần mềm : ƒ User Navigation Testing ƒ Transaction Screen Testing
3. à Nếu kết quả ₫ược hiển thị trên màn hình giao tác, thì kỹ thuật kiểm thử hộp ₫en với testcase gồm (data input, ouput kỳ vọng) sẽ ₫ược dùng ₫ể xác thực kết quả hiển thị. 3. Kiểm thử luồng giao tác (Transaction Flow Test) Kiểm tra kết quả tổng hợp của nhiều màn hình giao tác theo thứ tự duyệt ₫úng có hoàn thành hoạt ₫ộng nghiệp vụ tương ứng không ? Thí dụ nghiệp vụ cập nhật profile khách hàng gồm các màn hình giao tác sau : ƒ màn hình 1 cập nhật tên, ₫ịa chỉ, contact. Màn hình 2 cập nhật credit. Màn hình 3 cập nhật thông tin thanh toán và khuyến mãi. Màn hình 4 tổng kết profile và thực hiện cập nhật. Màn hình 5 ₫ể xem kết quả profile ₫ã cập nhật. ƒ Kết quả cuối cùng của trình tự các màn hình là file hay database sẽ ₫ược cập nhật ₫ể chứa các thông tin mà người dùng ₫ã cập nhật thông qua các màn hình giao tác. Nhiệm vụ của người kiển thử : ƒ Xác thực rằng nếu người dùng thực hiện ₫úng trình tự các màn hình giao tác và hoàn tất ₫ược chúng thì hệ thống se cung cấp kết quả ₫úng. ƒ Ngược lại, nếu người dùng không tuân thủ bất kỳ 1 qui luật nghiệp vụ nào trong 1 màn hình giao tác nào thì hệ thống sẽ không cung cấp kết quả gì cho người dùng. 4. Kiểm thử màn hình báo biểu (Report screen Test) màn hình báo biểu cho phép tìm kiếm dữ liệu và hiển thị kết quả (không cần nhập dữ liệu như màn hình giao tác). Khó khăn trong kiểm thử màn hình bào biểu nằm ở chỗ có nhiều cách mà người dùng có thể ₫ặc tả dữ liệu cần ₫ược tìm kiếm (tiêu chuẩn) và cách thức dữ liệu này ₫ược hiển thị (sắp xếp và ₫ịnh dạng).
4. 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.
5. ƒ 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.
6. 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.
7. ƒ 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.
8. 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.
9. ƒ 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.