CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ 1. Các khái niệm về kiểm thử và một số khái niệm liên quan 1. Kiểm thử là gì? Kiểm thử hay còn gọi là testing, là quá trình đánh giá một hệ thống hay các thành phần của nó với mục đích tìm xem liệu hệ thống có đáp ứng các yêu cầu được đã được chỉ định hay không. Nói một cách đơn giản, kiểm thử được thực hiện trên một hệ thống để xác định bất kỳ lỗ hổng, các lỗi hoặc các yêu cầu đang bị thiếu hay trái ngược với các yêu cầu thực tế đã được đề ra.
Theo tiêu chuẩn ANSI / IEEE 1059, kiểm thử có thể được định nghĩa là quá trình phân tích các thành phần của phần mềm để phát hiện sự khác biệt giữa những điều kiện của phần mềm đang tồn tại thực tế và những điều kiện được yêu cầu (đó là defects/ errors/ bugs) và từ đó có thể đánh giá được chất lượng của chất lượng của phần mềm. Một số khái niêm liên quan - Bug (Lỗi): là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng. - Testcase (Kịch bản kiểm thử) có nghĩa là: test là kiểm tra, cases là các tình huống. Tức là các tình huống, các trường hợp cần kiểm tra, kiểm tra các chức năng của phần mềm hoạt động đúng hay sai.
Được viết dựa trên tài liệu giải pháp hay còn gọi là tài liệu SRS + Mô tả dữ liệu đầu vài định test cái gì + Hành động hay mô tả các bước để test (Step) + Và một kết quả mong đợi để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không. - Re-test: Đồng nghĩa với confirmation testing (kiểm tra xác nhận), Là thực hiện test để kiểm tra xem bug mình đã post có được fixed hay chưa (kiểm tra lại xem đã hết 11 Báo cáo thực tập tốt nghiệp bị lỗi mà mình đã gặp chưa). Nếu đã được sửa xong thì mình báo cáo Close bug. Ngược lại, nếu vẫn còn lỗi thì báo cáo re-open để DEV sửa lại.
Yêu cầu khách hàng Hệ thống được phát triển dựa trên nhu cầu của khách hàng. Chính vì lẽ đó, các chức năng của hệ thống được xây dựng dựa trên việc thu nhập, phân tích, khảo sát nhu cầu khách hàng thông qua những yêu cầu cụ thể. Đối với hệ thống, yêu cầu thường được tổng hợp từ phí khách hàng, các tổ chức có mức độ chuyên môn 1. Tài liệu Đặc tả yêu cầu (SRS document) Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện của đội phát triển phần mềm.
Tài liệu đặc tả yêu cầu nên bao gồm tất cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu của hệ thống. Các khái niệm về lỗi đã nói ở trên cũng chính là đề cập đến việc phần mềm sau khi xây dựng hoạt động không đúng với bản đặc tả yêu cầu phần mềm. Tài liệu đặc tả yêu cầu cũng cần cung cấp đầy đủ các thông tin về chi phí, rủi ro và lịch trình cho quá trình phát triển sản phẩm. Đặc tả yêu cầu được viết ra phục vụ rất nhiều đối tượng từ người dùng hệ thống, khách hàng đến các nhà phát triển và bảo trì phần mềm.
Do đó, tài liệu đặc tả nên được viết bằng ngôn ngữ tự nhiên, sử dụng biểu đồ, bảng biểu để đảm bảo tính dễ hiểu, dễ sử dụng cho tất cả các đối tượng trên. 12 Báo cáo thực tập tốt nghiệp 1. Quy trình kiểm thử Hình : TỔNG QUAN VỀ KIỂM THỬ. Quy trình kiểm thử Lập kế hoạch test (Test Plan): Test Plan chính là tài liệu tổng quan về việc kiểm thử 1 project: phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test cần có, các chức năng, module cần được test, các công cụ và môi trường test cần có.
Bao gồm cả kế hoạch ai test chức năng nào, khi nào bắt đầu thực hiện viết và hoàn thành testcase; khi nào bắt đầu thực hiện test và khi nào hoàn thành test. Dựa vào kế hoạc chung của dự án để lên kế hoạch cho bên kiểm thử. Trong trường hợp khi làm thực tế thấy có khả năng không đúng như kế hoạch đã lên thì phải báo lại cho Test Lead hoặc người Quản trị dự án sớm. Thực hiện viết Testcase: Test case mô tả một dữ liệu đầu vào (input), hành động (action) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.
Biểu mẫu Testcase gồm có 4 nội dung chính: 13 Báo cáo thực tập tốt nghiệp - Mục đích kiểm thử - Các bước thực hiện - Kết quả mong muốn (Hệ thống phải chạy đúng như kết quả mong muốn) - Kết quả thực thế (điền Pass/Fail) Thực hiện Test (Testing Execution): Thực hiện test trực tiếp trên hệ thống sau khi lập trình viên bàn giao. Dựa trên các test cases đã được viết trước đó để thực hiện test trên hệ thống. Thực hiện ghi nhận kết quả kiểm thử vào cột kết quả của tài liệu kịch bản kiểm thử. Nếu kết quả kiểm thử là thất bại thì nhóm kiểm thử ghi nhận lỗi lên hệ thống quản lý lỗi.
Nhóm kiểm thử, QTDA, nhóm lập trình, nhóm giải pháp tham gia vào quá trình quản lý/xử lý lỗi (bug/ defect) Lập báo cáo Kiểm thử (Test Report): Test Report có thể hiểu đơn giản là một bản tóm tắt, trong đó chứa mục tiêu kiểm thử, hoạt động kiểm thử và kết quả. Mục đích của test report là giúp những bộ phận liên quan như bộ phận dev, test, phân tích, v.v… đánh giá được chất lượng sản phẩm và liệu sản phẩm hay giải pháp đó đã có thể đưa vào vận hành được chưa. Tuy nhiên, test report không chỉ dùng để đánh giá chất lượng, mà còn được sử dụng để những nhà phát triển hiểu rõ hơn về quy trình của bài test. Test Report thường chứa các nội dung như: -Số lương test cases đã viết/ số lượng testcase đã test -Số lượng test cases passed/failed -Số lượng defects tìm ra và status, severity của defects -Số lượng defects trên từng module -Các vấn đề liên quan đến testing, bản build, tiến độ sửa lỗi… 14 Báo cáo thực tập tốt nghiệp 1.
Các kỹ thuật kiểm thử 1. Phương pháp kiểm thử hộp trắng (White Box Testing) Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cả giải thuật, cấu trúc code bên trong phần mềm. Là phương pháp kiểm thử mà các chuyên gia tester tập trung vào các dữ liệu đầu vào và ra, truy cập thẳng vào bên trong source code. Hình : TỔNG QUAN VỀ KIỂM THỬ.
White Box Testing Các loại white box testing: - API testing (application programming interface) – Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private. - Code coverage – Là việc tạo các trường hợp test để thỏa mãn một số điều kiện bao phủ code – code coverage (ví dụ như, người thiết kế test có thể tạo ra các trường hợp test sao cho tất cả các câu lệnh của chương trình đều được thực thi ít nhất 1 lần). - Fault injection methods – cải tiến bao phủ một trường hợp bằng cách đưa một số lỗi vào để test các đường dẫn code. - Mutation testing methods.
- Static testing – White box testing bao gồm tất cả các phương pháp kiểm thử tĩnh (ví dụ review code). 15 Báo cáo thực tập tốt nghiệp Với phương pháp kiểm thử này, kiểm thử viên không cần hiểu biết về mã lệnh để xử lý chức năng đó thế nào. Các kiểm thử viên sẽ căn cứ vào tài liệu đặc tả, bản prototype của phần mềm cũng như dựa trên các testcase đã viết để kiểm tra chức năng. Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo lường được tính bằng phần trăm %.
Ưu điểm: Dễ dàng tự động hóa Cung cấp các quy tắc dựa trên kỹ thuật rõ ràng cho thời điểm ngừng thử nghiệm. Buộc các chuyên gia thử nghiệm phải suy luận cẩn thận về việc test lỗi vì vậy lỗi sẽ được triệt để. Nhược điểm: Khá tốn thời gian và công sức. Vẫn sẽ tồn tại lỗi.
Để kiểm tra được bằng phương pháp này cần có kinh nghiệm và trình độ chuyên sâu về kiểm thử. Phương pháp kiểm thử hộp đen (Black Box Testing) Kiểm thử hộp đen là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong. Chỉ test chức năng và giao diện dựa trên nghiệp vụ của hệ thống mà không cần quan tâm đến code bên trong 16 Báo cáo thực tập tốt nghiệp Hình : TỔNG QUAN VỀ KIỂM THỬ. Black Box Testing Ưu điểm: Rất phù hợp và hiệu quả khi mà số lượng các dòng lệnh của hệ thống là lớn.
Không cần truy cập vào các dòng lệnh. - Phân biệt được rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển. Không cần đòi hỏi những kiến thức về ngôn ngữ lập trình ở các kiểm thử viên để có thể kiểm thử hệ thống. Nhược điểm: Bị giới hạn ở độ bao phủ của các trường hợp kiểm thử.
Sẽ không hiệu quả bởi thực tế các kiểm thử viên bị giới hạn kiến thức về hệ thống. Độ bao phủ sẽ bị thiếu vì kiểm thử viên không kiểm tra được các đoạn lệnh của hệ thống hoặc tập trung vào các dòng lệnh dễ xảy ra lỗi. Sẽ khó để có thể thiết kế đầy đủ các trường hợp kiểm thử. Phương pháp kiểm thử hộp xám (Gray Box Testing) Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp kiểm thử Black Box (Hộp đen) và White Box (Hộp trắng).
Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, tester có thể truy 17 Báo cáo thực tập tốt nghiệp cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế testcase, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen. Hình : TỔNG QUAN VỀ KIỂM THỬ. Gray Box Testing Ưu điểm: Là sự kết hợp của kiểm thử hộp đen và hộp trắng nên sẽ tối ưu hơn. Kiểm tra bằng phương pháp hộp màu xám có thể thiết kế kịch bản thử nghiệm phức tạp một cách thông minh hơn.
Nhược điểm: Rất khó để liên kết lỗi khi thực hiện kiểm tra hộp xám cho một ứng dụng có hệ thống phân tán. Phương pháp kiểm thử hộp đen Đây là 4 phương pháp phổ biến nhất trong kỹ thuật kiểm thử hộp đen 1.