Bài giảng Kiểm thử phần mềm - Trường ĐH Thương mại

Bài giảng Kiểm thử phần mềm có nội dung gồm 4 chương cung cấp cho học viên những kiến thức về: tổng quan kiểm thử phần mềm; quy trình kiểm thử phần mềm; các công cụ kiểm thử phần mềm; thiết kế ca kiểm thử;... Mời các bạn cùng tham khảo chi tiết nội dung bài giảng!

21/07/2020 Chương Tổng quan kiểm thử phần mềm 1.1 Khái niệm phát triển phần mềm 1.1.1 Khái niệm phần mềm 1.1.2 Vòng đời phát triển phần mềm 1.1.3 Các mơ hình phát triển phần mềm 1.2 Khái niệm kiểm thử phần mềm 1.2.1 Khái niệm kiểm thử 1.2.2 Đảm bảo chất lượng 1.2.3 Kiểm soát chất lượng sản phẩm Bộ môn Công nghệ thông tin Trường Đại học Thương mại 1.3 Các nguyên tắc kiểm thử 1.4 Vai trò kiểm thử phần mềm 1.1.1 Khái niệm phần mềm Tài liệu tham khảo 10th Ian Sommerville, Software Engineering, Edition, 2016 Glenford J Myers, Tom Badgett, Todd M Thomas, Corey Sandler, The Art of Software Testing, 2011 Ron Patton, Software Testing, Second Edition, Sam Publishing, 2009 http://www.seleniumframework.com/ http://www.tester.vn/ http://www.testingvn.com/ Khái niệm phần mềm Một phần mềm gồm thành phần:    Chương trình máy tính: mã nguồn, mã máy Cấu trúc liệu: cấu trúc làm việc (bộ nhớ trong) cấu trúc lưu trữ (bộ nhớ ngoài) Các tài liệu liên quan: tài liệu hướng dẫn sử dụng (dành cho người dùng), tài liệu phát triển (dành cho người phát triển hệ thống), tài liệu tham khảo kỹ thuật (dành cho người bảo trì) Phần mềm coi tất kỹ thuật ứng dụng để thực dịch vụ chức cho mục đích phần cứng, làm cho sử dụng phần cứng máy tính đạt hiệu cao 1.1.1 Khái niệm phần mềm Nội dung Chương Tổng quan kiểm thử phần mềm Chương Quy trình kiểm thử phần mềm Chương Các công cụ kiểm thử phần mềm Chương Thiết kế ca kiểm thử 21/07/2020 Nhóm kỹ thuật, phương pháp luận Các khái niệm trình tự cụ thể hóa hệ thống 1.1.2 Vòng đời phát triển PM Các phương pháp tiếp cận giải vấn đề Là khoảng thời gian tính từ phần mềm đề xuất bỏ đi: cụ thể từ đặt hàng, phát triển, sử dụng đến bị loại bỏ Các trình tự thiết kế phát triển chuẩn hóa Các phương pháp đặc tả yêu cầu, thiết kế hệ thống, thiết kế chương trình, kiểm thử, tồn quy trình quản lý phát triển phần mềm Vòng đời phần mềm phân chia thành pha xác định yêu cầu, triển khai, kiểm thử, bảo trì (vận hành) Phạm vi, thứ tự pha khác tùy theo mơ hình, dự án cụ thể 10 Nhóm chương trình 1.1.2 Vịng đời phát triển PM  Là phần giao diện với phần cứng, tạo thành từ nhóm lệnh thị cho máy tính biết trình tự thao tác xử lý liệu  Phần mềm bản: với chức cung cấp môi trường thao tác dễ dàng cho người sử dụng nhằm tăng hiệu xử lý phần cứng (ví dụ OS chương trình hệ thống)  Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp (quản lý, kế tốn, ), phần mềm đóng gói, phần mềm người dùng, Tùy mơ hình áp dụng mà việc phân chia pha, bước có khác nhau: từ đến 20 pha Xác định yêu cầu Triển khai Kiểm thử (VËn hµnh) Bảo trì Vịng đời phần mềm 11 1.1.2 Vòng đời phát triển PM Nhóm tư liệu Những tư liệu hữu ích, có giá trị cao cần thiết để phát triển, vận hành bảo trì phần mềm Để xây dựng phần mềm với độ tin cậy cao cần tạo tư liệu chất lượng cao: đặc tả yêu cầu, mô tả thiết kế loại, điều kiện kiểm thử, thủ tục vận hành, hướng dẫn thao tác, …  Các giai đoạn phát triển phần mềm Phân tích tính khả thi đặc tả yêu cầu Phân tích Thiết kế Mã hóa Kiểm thử Cài đặt Bảo trì 12 21/07/2020 Phân tích tính khả thi Đặc tả yêu cầu: Pha tư liệu hố thơng tin thu thập Có hai loại yêu cầu cần xác định: Phân tích tính khả thi Xác định vấn đề cần giải Xem xét giải pháp kỹ thuật khác (đánh giá ưu nhược điểm giải pháp) Đánh giá thời gian, giá thành, nguồn tài nguyên cần thiết Sản phẩm: tài liệu phân tích * Yêu cầu người sử dụng: yêu cầu ngôn ngữ tự nhiên bổ sung thêm cho biểu đồ dịch vụ mà hệ thống cung cấp ràng buộc vận hành Kiểu yêu cầu viết người sử dụng * Yêu cầu hệ thống: tài liệu có cấu trúc mô tả chi tiết chức năng, dịch vụ ràng buộc vận hành hệ thống Yêu cầu hệ thống định nghĩa cần phải xây dựng, trở thành hợp đồng khách hàng nhà thầu Đánh giá yêu cầu: pha kiểm tra lại yêu cầu xem chúng có thực tế hay khơng, có thống khơng, có đầy đủ khơng Nếu phát lỗi ta phải chỉnh sửa lỗi 13 16 Đặc tả yêu cầu Đặc tả yêu cầu  Phân tích đặc tả yêu cầu Xác định nhu cầu khách hàng/người sử dụng  Xác định tốn, khơng phải giải pháp Khó khăn   Khách hàng khơng biết rõ họ cần Khách hàng khơng trình bày rõ họ muốn thay đổi Sản phẩm: tài liệu đặc tả yêu cầu 14 17 Đặc tả yêu cầu Thiết kế phần mềm  Đặc tả yêu cầu (hay gọi kỹ thuật xác định yêu cầu) quy  Thiết kế phần mềm trình thiết kế cấu trúc phần mềm dựa trình tìm hiểu định nghĩa dịch vụ yêu cầu ràng buộc trình vận hành xây dựng hệ thống  Quy trình xác định yêu cầu bao gồm bốn pha chính: Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định yêu cầu người sử dụng có thoả mãn cơng nghệ hay khơng Về góc độ kinh doanh, nghiên cứu khả thi nhằm xác định hệ thống đưa có mang lại lợi nhuận không Việc nghiên cứu khả thi nên thực cách nhanh chóng khơng tốn Kết việc nghiên cứu khả thi xác định có nên tiếp tục xây dựng hệ thống hay khơng Phân tích rút yêu cầu: quy trình đưa yêu cầu hệ thống thông qua số phương pháp như: quan sát hệ thống tại, vấn thảo luận với người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hệ thống cũ … Trong pha này, phải xây dựng nhiều mơ hình hệ thống mẫu thử 15 tài liệu đặc tả Hoạt động thiết kế bao gồm cơng việc sau:  Thiết kế kiến trúc: Các hệ thống cấu thành lên hệ thống cần xây dựng mối quan hệ chúng xác định tư liệu hoá  Đặc tả trừu tượng: với hệ thống con, phải có đặc tả dịch vụ ràng buộc vận hành  Thiết kế giao diện: với hệ thống con, giao diện với hệ thống khác phải thiết kế tư liệu hoá  Thiết kế thành phần: dịch vụ cung cấp cho thành phần khác giao diện tương tác với chúng phải thiết kế  Thiết kế cấu trúc liệu: cấu trúc liệu sử dụng để cài đặt hệ thống phải thiết kế cách chi tiết cụ thể  Thiết kế thuật toán: Các thuật toán sử dụng để cung cấp dịch vụ phải thiết kế chi tiết xác 18 21/07/2020 Phân tích Mã hóa gỡ rối Mã hóa gỡ rối Mã hóa: cài đặt thiết kế ngơn ngữ lập trình khơng đơn lập trình      Viết tài liệu Chuẩn lập trình Lập trình theo cấp Cơng cụ Quản lý phiên Gỡ rối: phát lỗi trình lập trình Sản phẩm: chương trình 22 19 Thiết kế phần mềm Kiểm thử Các công việc thiết kế phần mềm Kiểm thử - Đánh giá phần mềm hay gọi thẩm tra đánh giá (V&V Verification and validation) sử dụng để hệ thống thực theo đặc tả thoả mãn yêu cầu khách hàng Kiểm thử bao gồm công đoạn: kiểm tra, xem xét lại, kiểm thử hệ thống Kiểm thử hệ thống tức cho hệ thống thực trường hợp có liệu thật lấy từ tài liệu23 đặc tả hệ thống Quy trình kiểm thử 20 Thiết kế phần mềm Bảo trì hệ thống Các phương pháp thiết kế   Bảo trì hệ thống: Hướng chức Hướng đối tượng Bảo đảm chương trình vận hành tốt Cài đặt thay đổi Cài đặt yêu cầu Xử lý lỗi vận hành Sản phẩm: chương trình 21 24 21/07/2020 1.1.3 Các mơ hình phát triển PM Bảo trì hệ thống Cải tiến phần mềm Khi yêu cầu hệ thống thay đổi theo thay đổi yêu cầu nghiệp vụ phần mềm phải cải tiến thay đổi để hỗ trợ khách hàng Thông thường chi phí để bảo trì cải tiến thường đắt nhiều so với chi phí xây dựng phần mềm Hiện có nhiều mơ hình phát triển phần mềm, thường phân thành loại: mơ hình tuyến tính mơ hình lặp Mơ hình tuyến tính: bước thực tuần tự, không lặp lại   Mơ hình thác nước Mơ hình V… Mơ hình lặp: bước thực song song, lặp lại số bước   25 1.1.2 Vịng đời phát triển phần mềm  Mơ hình tiến hóa Mơ hình xoắn ốc Mơ hình hợp nhất… 28 a Mơ hình Thác nước Mơ hình thác nước (Water Fall Model) 29 26 1.1.2 Vòng đời phát triển phần mềm  Kiểm thử cần thực suốt vòng đời phần mềm Kiểm thử không tồn độc lập Các hoạt động kiểm thử gắn liền với 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 cần cách tiếp cận test khác 27 a Mơ hình Thác nước Các pha mơ hình thác nước bao gồm: Phân tích xác định yêu cầu Thiết kế hệ thống phần mềm Cài đặt kiểm thử đơn vị Tích hợp kiểm thử hệ thống Vận hành bảo trì 30 21/07/2020 b Mơ hình V a Mơ hình Thác nước Bảo trì Là mơ hình cổ điển Phân tích u cầu Phương pháp áp dụng lần Điều khiển hiệu Kiểm thử chấp nhận Thiết kế hệ thống Phạm vi giới hạn vịng lặp Vịng đời dài Khơng thích hợp với hệ thống không rõ ràng Kiểm thử hệ thống Kiểm thử đơn vị tích hợp Thiết kế chương trình Lập trình 34 31 b Mơ hình V Ứng dụng Trong mơ hình thác nước, năm pha phải thực cách tuần tự; kết thúc pha trước, thực pha Do đó, nhược điểm mơ hình thác nước khó khăn việc thay đổi pha thực Giả sử, pha phân tích xác định yêu cầu hoàn tất chuyển sang pha kế tiếp, lúc lại có thay đổi yêu cầu người sử dụng; cịn cách phải thực lại từ đầu Mơ hình thích hợp u cầu tìm hiểu rõ ràng thay đổi giới hạn cách rõ ràng suốt trình thiết kế Tuy nhiên, thực tế có hệ thống nghiệp vụ có yêu cầu ổn định Trong mơ hình V: Các tiến trình kiểm thử thêm vào Kết nối kiểm thử với phân tích thiết kế Thích hợp với trường hợp tốn khơng qn 32 35 b Mơ hình V Nhận xét Ưu điểm: Tồn qui trình chia thành hai nhóm giai đoạn tươngứng nhau: phát triển kiểm thử.Mỗi giai đoạn phát triển tiến hành song song với giai kiểm thử tương ứng => lỗi phát sớm từ đầu Chỉ phù hợp với dự án nhỏ Yêu cầu xác định Nhược điểm: Tinh thần chủ đạo V-model hoạt động kiểm thử phải tiến hành song song (theo khả có thể) từ đầu chu trình với hoạt động phát triển Ví dụ, hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống thực song song với hoạt động phân tích thiết kế hệ thống Khơng phù hợp với dự án lớn Thời gian thực lâu 33 36 21/07/2020 b Mơ hình V c Mơ hình mẫu  Giai đoạn phát triển:  Xác định yêu cầu đặc tả (Requirement & Specification): Xác định yêu cầu cần thiết mà hệ thống đòi hỏi, đưa đặc tả  Phân tích hệ thống (System Analysis): Phân tích yêu cầu mà hệ thống cần có đưa giải pháp tích hợp yêu cầu vào hệ thống  Thiết kế chi tiết (Detailed Design): Chi tiết hóa bước thực xây dựng hệ thống (Về giao diện nội dung)  Phát triển (Development ): Thực việc viết code  Giai đoạn kiểm thử:  Kiểm tra thành phần tích hợp (Unit & Intergration Test): Kiểm tra module hệ thống tương ứng với pha thiết kế chi tiết  Kiểm thử toàn hệ thống (System Test): kiểm thử hoạt động hệ thống (về chức năng, giao diện)  Nghiệm thu (Accepted Test): Kiểm tra lần cuối nghiệm thu sản phẩm đưa vào sử dụng 37 b Mơ hình V Mục đích Xem xét yêu cầu người sử dụng giai đoạn ban đầu Giảm bớt rủi ro không chắn Kiểm chứng thiết kế thực thi Nên thường xuyên trả lời câu hỏi chuyên biệt; mục đích phải xác định 40 Lợi ích mẫu  Với V model cơng việc test tham gia từ đầu, từ lúc lấy yêu cầu "test" cách review tài liệu yêu cầu, review đặc ta chi tiết, thiết kế, review code cuối test mức thấp - module, chức năng, hình, đến test tích hợp kiểm thử hệ thống  So với mơ hình khác mơ hình này, cơng việc test sát từ đầu bắt đầu phát triển Chắc chắn chất lượng dự án tốt Nhưng người ta tiếp tục đưa mơ hình phát triển khác? Vì mơ hình chữ V người ta phát triển lúc hệ thống (nhiều yêu cầu, chức lúc) mà rủi ro (risk) thay đổi u cầu lớn Nên mơ hình gặp rắc rối khách hàng thường xuyên thay đổi yêu cầu Học cách làm việc Tăng cường giao tiếp Tăng tham gia người dùng vào dự án Làm rõ yêu cầu biết phần 41 38 c Mơ hình mẫu Tuần tự làm mẫu Tập hợp yêu cầu Nghe Khách trình bày Thiết kế nhanh Tạo / sửa mẫu Xây dựng mẫu Đánh giá khách hàng Làm mịn Khách kiểm tra mẫu Quay lại thiết kế nhanh để điều chỉnh Xây dựng sản phẩm Mơ hình mẫu (Prototyping model) 39 42 21/07/2020 Đánh giá d Mơ hình xoắn ốc Ưu điểm: phù hợp với Hệ thống rủi ro cao Lập kế hoạch u cầu khơng chắn Phân tích rủi ro Giao tiếp Giao diện chưa rõ ràng khách hàng Khái niệm Chiến lược cài đặt chưa rõ ràng Thiết kế Làm Nâng cấp Khách hàng Hạn chế: Khách hàng cho nguyên mẫu hệ thống thực Mong đợi không thực tế tiến triển dự án Chi phí tăng thêm Xác định mục đích, lựa chọn ràng buộc Đánh giá lựa chọn; xác định giải rủi ro Phân tích rủi ro Phân tích rủi ro Phân tích rủi ro Người phát triển có chọn lựa không tốt Phù hợp cho nguyên mẫu, không phù hợp cho hệ thống thực Lập kế hoạch u cầu Ngun mẫu khơng giống hồn tồn hệ Lập kế hoạch phát triển thống cuối  46 d Mơ hình xoắn ốc (Boehm 1987) Đánh giá  Xuất xưởng Mơ hình xoắn ốc (spiral) 43  Xây dựng & đánh giá Bảo trì Bản mẫu Kế hoạch kiểm thử tích hợp Khách hàng có phản ứng khác Kế hoạch cho giai đoạn tiếp 44 Chức Yêu cầu phần mềm Kiểm thử yêu cầu Thiết kế hệ thống Thiết kế chi tiết Lập trình Kiểm thử thiết kế Kiểm thử chấp nhận Bản mẫu Bản mẫu Tích hợp kiểm thử Kiểm thử đơn vị Phát triển kiểm chứng sản phẩm mức 47 Ứng dụng d Mơ hình xoắn ốc Mơ hình mẫu thường sử dụng khi:  Trong mơ hình xoắn ốc, quy trình phát triển phần mềm Khi rõ mục đích chung chung phần mềm, chưa rõ chi tiết đầu vào hay xử lý chưa rõ yêu cầu đầu Dùng “Hệ sơ khai” để thu thập yêu cầu người dùng qua thiết kế nhanh Các giải thuật, kỹ thuật dùng làm mẫu chưa nhanh, chưa tốt, miễn có mẫu để thảo luận gợi yêu cầu người dùng 45 biểu diễn vịng xoắn ốc Các pha quy trình phát triển xoắn ốc bao gồm:  Thiết lập mục tiêu: xác định mục tiêu cho pha dự án  Đánh giá giảm thiểu rủi ro: rủi ro đánh giá thực hành động để giảm thiểu rủi ro  Phát triển đánh giá: sau đánh giá rủi ro, mơ hình xây dựng hệ thống lựa chọn từ mơ hình chung  Lập kế hoạch: đánh giá dự án pha mơ hình xoắn ốc lập kế hoạch 48 21/07/2020 d Mơ hình xoắn ốc Đánh giá Nhấn mạnh việc đánh giá rủi ro Ưu điểm Phần mềm xây dựng theo nhiều chu kỳ Mỗi chu kỳ tương ứng với sản phẩm giai đọan phát triển Xác định mục tiêu, giải pháp, ràng buộc Đánh giá giải pháp, xác định nguy tìm cách giải chúng Phát triển kiểm thử sản phẩm chu kỳ Lập kế hoạch cho chu kỳ 49 Hạn chế rủi ro sớm Nhận phản hồi ( feedbacks) từ khách hàng sớm Dễ kiểm soát mạo hiểm mức tiến hóa Hạn chế Khó thuyết phục khách hàng phương pháp tiến hóa xoắn ốc kiểm sốt Chưa dùng rộng rãi mơ hình tuyến tính chế thử 52 d Mơ hình xoắn ốc (tiếp) Ứng dụng Mơ hình xoắn ốc phù hợp với  Giao tiếp khách hàng: người phát triển khách Các hệ phần mềm quy mô lớn, dự án lớn, hàng để tìm hiểu yêu cầu, ý kiến  Lập kế hoạch: Xác lập tài nguyên, thời hạn thông tin khác  Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật mạo hiểm quản lý  Thiết kế: Xây dựng hay số biểu diễn ứng dụng phức tạp Hệ thống cần phát triển nhiều phiên Các hệ thống có yêu cầu chưa xác định rõ ràng 50 d Mơ hình xoắn ốc (tiếp) 53 e Mơ hình hợp  Mơ hình hợp sử dụng Các kỹ thuật hệ Xây dựng xuất xưởng: xây dựng, kiểm thử, cài đặt cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, ) Đánh giá khách hàng: Nhận phản hồi người sử dụng biểu diễn phần mềm giai đoạn kỹ nghệ cài đặt 51 (Fourth generation techniques): Tập hợp công cụ cho phép xác định đặc tính phần mềm mức cao, sau tự động sinh mã nguồn dựa theo đặc tả  Các cơng cụ 4GT điển hình: ngơn ngữ phi thủ tục cho truy vấn CSDL, tạo báo cáo, xử lý liệu, tương tác hình, tạo mã nguồn, khả đồ họa bậc cao, khả bảng tính, khả giao diện Web  Từ thu thập yêu cầu sản phẩm: đối thoại khách người phát triển quan trọng  Không nên bỏ qua khâu thiết kế: 4GT áp dụng để triển khai thiết kế qua ngơn ngữ lập trình hệ (4GL- Fourth-generation programming language) 54 21/07/2020 e Mơ hình hợp e Mơ hình hợp Tiến trình hợp nhìn hai góc nhìn khác Góc nhìn kỹ thuật Góc nhìn quản lý: quan tâm đến lĩnh vực kinh tế, chiến thuật, người  Tiến trình gồm giai đoạn Góc nhìn kỹ thuật: quan tâm đến cơng nghệ, kiểm tra chất lượng, phương pháp  Tiến trình gồm nhiều bước lặp 55 58 e Mơ hình hợp e Mơ hình hợp Góc nhìn quản lý Kết hợp hai góc nhìn 56 e Mơ hình hợp 59 e Mơ hình hợp Góc nhìn kỹ thuật: bước lặp Mơ hình hợp UML Mỗi bước lặp gồm hoạt động       Đặc tả Phân tích Thiết kế Mã hóa Kiểm thử Cài đặt Mỗi bước lặp tiến trình thác đổ 57 60 10 21/07/2020 Hướng dẫn kiểm thử ứng dụng Mobile Khi kiểm thử thiết bị di động, cần lưu ý:  Kiểm thử tràn nhớ:  Ứng dụng mobile có hạn chế nhớ nên thường văng lỗi sử dụng nhớ nhiều  Cách test lỗi memory: Hướng dẫn kiểm tra Giao diện Mobile/Responsive Làm kiểm Responsive trang web ?  Không cần phần mềm, không cần phải có điện thoại, khơng phải kéo co giản hình  Thực sau trình duyệt Firefox Chrome:  Trên trang web bạn, right-click chuột phải chọn: + Scroll lên xuống ứng dụng nhiều, scroll nhanh + Các chức load liệu tạo liệu load nhiều lên ví dụ tạo danh sách nhiều hình ảnh hình ảnh có size lớn chút + Thực nhiều chức lúc + Khi loading thực thao tác ứng dụng 235 Hướng dẫn kiểm tra Giao diện Mobile/Responsive Thiết kế Responsive/ Responsive gì? xây dựng giao diện  Responsive phong cách thiết kế web phù hợp tất thiết bị, độ phân giải hình 238 BÀI TẬP CHƯƠNG 3  Trình bày phương pháp kiểm thử Theo bạn nhóm phát triển phần mềm thường sử dụng phương pháp kiểm thử nay? So sánh ưu nhược điểm hai phương pháp kiểm thử động tĩnh Theo bạn, phương pháp kiểm thử động thường thực dự án có đặc điểm gì? Trình bày kỹ thuật kiểm thử Theo bạn nhóm phát triển phần mềm thường sử dụng phương pháp kiểm thử nay? Trình bày kỹ thuật kiểm thử hộp trắng Theo bạn, kỹ thuật kiểm thử hộp trắng có ưu nhược điểm Kỹ thuật thường sử dụng để kiểm thử hoạt động giai đoạn phát triển phần mềm? Trình bày kỹ thuật kiểm thử hộp đen Theo bạn, kỹ thuật kiểm thử hộp đen có ưu nhược điểm Kỹ thuật thường sử dụng để kiểm thử hoạt động giai đoạn phát triển phần mềm? 236 Hướng dẫn kiểm tra Giao diện Mobile/Responsive Responsive ảnh hưởng đến web bạn ?  Website truy cập dễ dàng tất thiết bị: đáp ứng nhu cầu người thời đại tồn dùng Smartphone máy tính bảng để lướt web  Không phải công thiết nhiều giao diện khác cho thiết bị khác  Trang web thiết kế cụ thể với loại hình 237 239 CHƯƠNG THIẾT KẾ CA KIỂM THỬ 4.1 Lập kế hoạch kiểm thử 4.2 Xây dựng kịch kiểm thử 4.3 Công cụ kiểm thử tự động 4.4 Tạo báo cáo kiểm thử 4.4.1 Tạo Test Case 4.4.2 Tạo Test Execution 4.4.3 Taọ Test report 240 40 21/07/2020 4.2 Xây dựng kịch kiểm thử 4.1.Lập kế hoạch kiểm thử Mục tiêu thiết kế ca kiểm thử nhằm Tìm nhiều lỗi Với nỗ lực thời gian nhỏ Lựa chọn phương pháp kiểm thử phải đảm bảo: Tính đầy đủ (khơng sót u cầu nào) Cung cấp khả thật phát lỗi Ca kiểm thử hiệu ca kiểm thử phát lỗi 241 244 Bài tập thiết kế ca kiểm thử 4.1.Lập kế hoạch kiểm thử  Một kế hoạch kiểm thử dự án phần mềm (test plan) tài liệu mô tả mục tiêu, phạm vi, phương pháp tiếp cận, tập trung vào nỗ lực kiểm thử phần mềm Quá trình chuẩn bị test plan cách hữu ích để suy nghĩ tới nỗ lực cần thiết để xác nhận khả chấp nhận sản phẩm phần mềm  Cấu trúc chung test plan: Lựa chọn phương pháp kiểm thử Kiểm thử tĩnh (thủ công) Kiểm thử máy  Tên project  Danh sách Module cần test  Ngày bắt đầu, ngày kết thúc  Danh sách Test case  Nhân tham gia  Tài nguyên sử dụng (Servers, Workstations, Printers,…)  Kế hoạch thực (sử dụng Ms Project lập kế hoạch)…  Xem biểu mẫu Test Plan 242 245 4.2 Xây dựng kịch kiểm thử Bài tập thiết kế ca kiểm thử Một phép thử gọi thành công phát khiếm khuyết phần mềm Kiểm thử chứng minh tồn lỗi hệ thống không chứng minh hệ thống khơng có lỗi Một phép kiểm thử (ca kiểm thử) bao gồm:  Xây dựng kịch kiểm thử tĩnh (thủ công): kịch tên mô đun kiểm thử dữ liệu vào dữ liệu mong muốn (kết đúng) dữ liệu thực tế (khi tiến hành kiểm thử) kiểm thử chức Đăng nhập hệ thống thường chia thành ba phần chính:  Giao diện: Kiểm thử yếu tố giao diện chung kiểm tra giao diện theo thiết kế, kiểm tra ấn tab, shift-tab, kiểm tra việc bị vỡ giao diện hay không, giá trị mặc định textbox  Các ca kiểm thử nên thiết kế tạo tài liệu phân tích thiết kế, viết xong mã nguồn 243  Kiểm tra item hình có theo thiết kế chưa (kiểm tra nội dung nhãn, màu sắc, link, status, canh lề, item) Kiểm tra validate cho input item, item có nhiều vấn đề để kiểm tra số ký tự tối thiểu, tối đa, cho phép nhập số, chữ hay ngày tháng, cho nhập ký tự đặc biệt không 246 41 21/07/2020 Bài tập thiết kế ca kiểm thử Xây dựng kịch kiểm thử tự động máy: có hai phần cần quan tâm test case liệu kiểm thử Trong đó: Test case: Có thể hàm lớp ghi lại chuỗi kiện mà ta thao tác với ứng dụng cần kiểm thử Khác với khái niệm test case thực kiểm thử thủ công giá trị đầu vào khác tạo thành test case khác Dữ liệu kiểm thử: Là liệu nhập vào để kiểm thử 247 Bài tập thiết kế ca kiểm thử 250 4.3 Công cụ kiểm thử tự động Test case đăng nhập Firefox Quick Test Professional Nunit, Junit Test Architect - (LogiGear)  Visual Studio CodedUI Testing  TestComplete (SmartBear) SOAPUI - Web Services Testing (SmartBear) Load Runner: dùng kiểm thử hiệu Selenium: kiểm thử ứng dụng web 248 251 Công cụ kiểm thử SELENIUM Bài tập thiết kế ca kiểm thử Selenium (thường viết tắt SE) phần mềm mã nguồn mở, phát triển Jason Huggins, sau tiếp tục phát triển nhóm ThoughtWorks vào năm 2004 Hỗ trợ kiểm thử hầu hết trình duyệt web phổ biến Firefox, Internet Explorer, Googlechrome Hỗ trợ nhiều ngơn ngữ lập trình phổ biến C#, Java, Python, PHP Có thể kết hợp với số công cụ kiểm thử khác Junit, Bromien, Nunit 249 252 42 21/07/2020 Công cụ kiểm thử SELENIUM  Selenium công cụ hỗ trợ kiểm thử tự động tính ứng dụng web, bao gồm phần: Selenium IDE, Selenium Remote Control (RC), Selenium Core Selenium Grid  Selenium IDE: mơi trường phát triển tích hợp cho việc xây dựng trường hợp kiểm thử Selenium  Selenium Core: Cơng cụ tích hợp Selenium IDE Selenium Core công cụ chạy test script viết Selenese  Selenium RC (Remote Control): Selenium-RC cho phép nhà phát triển tự động hóa kiểm thử sử dụng ngơn ngữ lập trình cho tính linh hoạt tối đa mở rộng việc phát triển logic thử nghiệm  Selenium Grid: Thực phương pháp kiểm tra phân bố, phối hợp nhiều kết  Selenium RC để thực thi nhiều trình duyệt web khác lúc Công cụ kiểm thử SELENIUM Khi nhập text Selenium IDE ghi lại tương đương với copy nội dung text vào textbox, nhập ký tự  Chính chủ yếu record playback, nhiên lại có nhiều thao tác khơng record lại, playback hay xảy lỗi Timeout nên thực tính ứng dụng thực tiễn vào dự án không cao 253 Công cụ kiểm thử SELENIUM  Tùy vào đặc thù dự án, đặc thù sản phẩm cụ thể mà cần xem xét có nên sử dụng Selenium IDE khơng, sử dụng nên sử dụng giai đoạn test nào, nội dung test nào?  Dễ sử dụng phát triển, cải thiện thời gian cho người thực test, khơng lãng phí thời gian cho cơng việc lặp lặp lại nhiều lần  Selenium IDE cung cấp chức ghi (record) chạy (run) lại nên tester nhanh chóng tạo kịch kiểm tra (test script) cách trực tiếp thu thao tác đối tượng cần kiểm tra Sau chạy lại câu lệnh để kiểm tra Chức hữu dụng giúp tiết kiệm thời gian viết kịch kiểm tra Selenium cho phép lưu kịch thâu nhiều loại ngơn ngữ lập trình khác Java, PHP, C#, Ruby, Perl hay Python 254 Công cụ kiểm thử SELENIUM  Hạn chế Selenium IDE: Không record lại thao tác ấn Enter Nếu không ấn enter mà click button chạy bình thường Khơng record lại thao tác trường hợp mở tab Không record lại thao tác trường hợp click vào button Back, Next website Không record lại thao tác trường hợp click vào button OK popup Nguyên nhân popup HTML object, mà ActiveX object Việc record lại với website sử dụng Javascript hay Ajax hay bị lỗi page load chậm, 255 element trang web thay đổi liên tục 256 Công cụ kiểm thử SELENIUM  Trong trường hợp sau, không nên sử dụng Selenium IDE:  Sản phẩm test thay đổi nhiều tương lai gần Vì sử dụng Selenium IDE sản phẩm cịn thay đổi việc sử dụng Selenium IDE nhiều effort tạo script mà script tạo không sử dụng lại phải viết lại Thời gian test ngắn hạn Vì dự án ngắn hạn khơng đủ thời gian để viết tự động hóa Khi việc kiểm thử tay thích hợp 257 Cơng cụ kiểm thử SELENIUM  Chỉ nên sử dụng Selenium IDE để thực automation test trường hợp sau:  Dự án test dài hạn, cần phải test lặp lặp lại nhiều lần  Cần phải test nhiều trình duyệt khác nhau, ví dụ thực testcase môi trường IE, Chrome, Safari  Chức test gần hoàn thiện, ổn định, không bị thay đổi  Việc tạo testscript chắn thời gian effort test tay Việc chạy lại script chắn thời gian effort test tay  Nội dung test chức mà Selenium IDE record được, không rơi vào trường hợp mà Selenium IDE khơng có khả record Đảm bảo khơng nhiều thời gian cho tester để tạo script hay sửa lại script 258 43 21/07/2020 KIỂM THỬ TỰ ĐỘNG: Cài đặt Selenium IDE  Download Selen IDE, add-on Firefox dùng để record thao tác hình  Vào link http://docs.seleniumhq.org/download/ Firefox  Bước 1: ◦ Chọn Download tab click vào: KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Là phần mềm mã nguồn mở free Có cộng đồng người sử dụng lớn, dễ dàng tra cứu tìm kiếm giúp đỡ Hỗ trợ nhiều trình duyệt (Firefox, chrome, Internet Explorer, Safari…) Tương thích với nhiều platform (Windows, Mac OS, Linux …) Hỗ trợ nhiều loại ngơn ngữ lập trình (Java, C#, Ruby, Python, Pearl…) Được phát triển nâng cấp thường xuyên 259 KIỂM THỬ TỰ ĐỘNG: Cài đặt Selenium IDE 262 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Cách bật Selenium: Chọn cách sau: 260 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 261 263 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 264 44 21/07/2020 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE  Đề bài: Thực ghi script Chức Tìm kiếm có liệu google.com  265 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 268 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE  Bước 1:  Bật selenimum IDE Firefox chọn nút Record để thực ghi thao tác tự động  Gõ google.com trình duyệt Firefox Sau gõ nội dung tìm kiếm là: download Selenium IDE Plugins click chọn Selenium IDE Plugins link 266 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 269 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Selenimum Kết Tắt Record script sau: Add verifications Assert sử dụng context menu - Add thêm verifications asserts từ context menu - Hiển thị thêm câu lệnh cách chọn “Show All 267  270 45 21/07/2020 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Khi thực Tìm kiếm thành cơng Verify Text thơng báo (Right-Click chuột để chọn verify menu) Cần phải có verify text thị để đảm bảo bạn đến trang cần test ( gọi verification point Checkpoint) KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Các câu lệnh Selenium: Actions: lệnh thao tác nói chung trạng thái ứng dụng Chúng việc “click link” hay “lựa chọn tùy chọn” Nếu có Action fail có lỗi, thực kiểm thử dừng lại Nhiều Action gọi với hậu tố “AndWait”, Ví dụ: “clickAndWait” Hậu tố cho biết Selenium thực gọi tới máy chủ Selenium đợi để tải trang Accessors: kiểm tra trạng thái ứng dụng lưu trữ kết biến, ví dụ: “storeTitle” Chúng sử dụng để tự động tạo Assertions 271 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 274 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE  Các câu lệnh Selenium: Assertions Accessors, chúng xác minh trạng thái ứng dụng phù hợp với mong đợi, ví dụ: “chắc chắn tiêu đề trang X” “xác nhận checkbox kiểm tra”  Tất Assertions Selenium sử dụng ba cách thức:    assert verify waitFor  Ví dụ: “assertText”, “verifyText” “waitForText” Khi “assert” fail kịch bạn dừng lại không chạy thêm lệnh khác Khi “verify” fail kiểm thử tiếp tục thực Như vậy, việc tìm kiếm thành công chạy tool tự động mà ko phải thao tác tay 272 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Test case: Một trường hợp kiểm thử Test suite: Bao gồm nhiều test case  Các lệnh chạy test cases: 275 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE  Các lệnh Selenium thường sử dụng:  Open: Mở trang sử dụng URL  click/clickAndWait: Thực thao tác nhấp chuột Run a test case Run a test suite Stop and start Stop in the Middle/Set break point Start from the Middle: Bắt đầu chạy từ command thay command Right click on command, select Set/Clear Start Point  Run Any Single Command: double click      273 chờ đợi để nạp trang  verifyTitle/assertTitle: Xác minh tiêu đề trang dự kiến  verifyTextPresent: Được sử dụng để xác nhận văn cụ thể tồn nơi trang Ví dụ: verifyTextPresent= Selenium IDE  Với lệnh tìm kiếm chuỗi văn “Selenium IDE” có xuất nơi trang thử nghiệm không Sử dụng hàm bạn cần quan tâm văn cần kiểm tra có xuất khơng, khơng kiểm tra xuất 276 vị trí cụ thể 46 21/07/2020 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Một số command thường dùng:  Các lệnh Selenium thường sử dụng:  verifyElementPresent: Kiểm tra diện yếu tố giao diện người dùng cụ thể, nội dung Xác minh khơng kiểm tra văn bản, có tag HTML Thơng thường sử dụng để kiểm tra diện hình ảnh  VerifyText: Sử dụng verifyText cần kiểm tra văn giao diện phần tử verifyText phải sử dụng locator Nếu bạn chọn Xpath DOM locator, bạn verrify văn cụ thể xuất địa điểm cụ thể trang web liên quan đến thành phần UI trang  VerifyTable: Kiểm tra nội dung bảng dự kiến  waitForPageToLoad: Tạm dừng thực trang dự kiến nạp  assertText(locator, pattern): assertText( target: css=a.btn_big, value : Nạp tiền) => asser vào object Nạp tiền có check text hiển thị có text Nạp tiền  store(expression, variableName): store(target: user01@yahoo.com, value:V1_User_Name) =>biết V1_User_Name giữ value : user01@yahoo.com  captureEntirePageScreenshot(filename, kwargs): ví dụ: captureEntirePageScreenshot(Target : d:\\Eclick_Auto_Test\\image_test\\TC_6_image01_DanhSachChi enDich.png) => Capture hình lưu tên đường dẫn trên) 277 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE  Các lệnh Selenium thường sử dụng:  WaitForElementPresent: Tạm dừng thực yếu tố giao diện người dùng mong đợi, định nghĩa thẻ HTML xuất trang  AssertTextPresent: Kiểm tra chuỗi Text có tồn hình  AssertTextNotPresent: Kiểm tra chuỗi Text khơng tồn hình 278 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE 280 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Tự động kiểm tra:  Selenium IDE hỗ trợ kiểm tra tiêu đề trang web cách tự động Để làm điều đó, cần thiết lập chế IDE sau:  B1: Mở Selenium IDE Options menu item Options –> Options  B2: Kích hoạt chức “Record assertTitle automatically” thẻ General.Như vậy, thực thi record với Selenium IDE, trang hiển thị, Selenium IDE tự động thêm dòng lệnh kiểm tra tiêu đề trang web cho 281 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Một số command thường dùng:  open(url): dùng để mở trang (URL) Open (target = /login) => mở trang login  pause(waitTime): Tạm dừng Pause (target : 1500) => Tạm dừng 1.5 s  type(locator, value) : type (target : name=username,value=user01) = > type vào ô User name user01  click(locator): click (locator : link=Đăng nhập) => Click vào link Đăng nhập 279 282 47 21/07/2020 KIỂM THỬ TỰ ĐỘNG: cách dùng Selenium IDE Tự động kiểm tra: Selenium IDE tự động thêm dòng lệnh kiểm tra tiêu đề trang web record xong 4.4.1 Tạo TEST CASE  Nó bao gồm bước bản: - Mơ tả : đặc tả điều kiện cần cố để tiến hành kiểm tra - Nhập : đặc tả đối tượng liệu cần thiết, sử dụng làm đầu vào để thực kiểm tra - Kết mong chờ : kết trả từ đối tượng kiểm tra - Biểu mẫu Test case: - 283 4.4 Tạo báo cáo kiểm thử 286 4.4.1 Tạo TEST CASE Test case mô tả liệu đầu vào (input), hành động (action) kiện (event) kết mong đợi (expected response), để xác định chức ứng dụng phần mềm hoạt động hay không 4.4.1 Tạo Test Case 4.4.2 Tạo Test Execution 4.4.3 Taọ Test report  Một test case có phần đặc thù khác mã test case, tên test case, mục tiêu test, điều kiện test, yêu cầu data input, bước thực kết mong đợi 284  Mức chi tiết định nghĩa khác dựa vào ngữ cảnh dự án quy mô công ty sản xuất phần mềm 287 4.4.1 Tạo TEST CASE 4.4.1 Tạo TEST CASE  Test case mô tả liệu đầu vào (input), hành động Quá trình phát triển test case giúp tìm lỗi u cầu thiết kế ứng dụng, địi hỏi phải tư hồn tồn thơng qua hoạt động ứng dụng Vì lý này, việc chuẩn bị test case sớm qui trình phát triển phần mềm hữu ích Các trường hợp kiểm thử phải bao phủ toàn luồng xử lý chức mô tả tài liệu phân tích thiết kế; yêu cầu bảo mật an tồn thơng tin, u cầu hiệu hệ thống (action) kết mong đợi (expected response), để xác định chức ứng dụng phần mềm hoạt động hay không  Một test case có phần đặc thù khác mã test case, tên test case, mục tiêu test, điều kiện test, yêu cầu data input, bước thực kết mong đợi Mức chi tiết định nghĩa khác dựa vào quy mô dự án hay quy mô công ty sản xuất phần mềm  Quá trình phát triển test case giúp tìm lỗi u cầu thiết kế ứng dụng, địi hỏi phải tư hồn tồn thơng qua hoạt động ứng dụng Vì lý này, việc chuẩn bị test case sớm qui trình phát triển phần mềm hữu ích 285 288 48 21/07/2020 4.4.1 Tạo TEST CASE Hướng dẫn viết TESTCASES Kết mong đợi/ Expected result: + Một test case viết tốt cần phải đề cập cách rõ ràng kết mong đợi ứng dụng hệ thống + Mỗi bước thiết kế test nên rõ ràng bạn mong đợi + Phần mềm phải chạy Kết mong đợi, ko giống Lỗi ( bug/ defect) test case Fail 289 Hướng dẫn viết TESTCASES Testcase gồm bước bản: Mục đích kiểm thử/ Miêu tả testcase/ Testcase description: + Miêu tả test case phần bạn đề cập cách chi tiết mà bạn test cách xử lý riêng biệt kiểm tra test + “Miêu tả” test case nên đưa “Mình test gì”? + Ví dụ: Test nhập max length cho username 292 Hướng dẫn viết TESTCASES Cột Kết test/Test result:  Thông thường pass, fail, pending Đây kết thực tế thực test theo test case môi trường hệ thống 290 293 Hướng dẫn viết TESTCASES Hướng dẫn viết TESTCASES Các bước thực hiện/ Testcase Procedure: + Dữ liệu đầu vào test: định nhập để kết mong muốn + Việc xác định liệu đầu vào test thực hoạt động tốn nhiều thời gian + Dữ liệu test phần Input liệu đầu vào, để hệ thống xử lý trả Kết mong đợi + Ví dụ: tester nhập liệu test: 1.Nhập username = ndthu 2.Nhập password = 123qwe Xác định trường hợp kiểm tra Với giá trị cần kiểm tra ln ln có trường hợp lớn cần kiểm tra xảy 291 Normal case: Các trường hợp kiểm thử thông thường Abnormal case: Các trường hợp kiểm thử bất bình thường Boundary case: Các trường hợp kiểm tra boundary (phân tích giá trị biên) 294 49 21/07/2020 Hướng dẫn viết TESTCASES Testcase ví dụ: textbox Viết testcase cho Hướng dẫn viết TESTCASES Đối với email/ điện thoại textbox:  Normal case gồm: đăng nhập với sdt, địa email đăng ký với hệ thống facebook trước đăng nhập với blank, sai sdt, địa email đăng ký với hệ thống facebook trước  Abnormal case gồm: Đăng nhập với số điện thoại mà thêm mã vùng, mã nước vào trước (ví dụ: +849 ) email mà khơng nhập @ cho Ngồi ra, cịn có cases: offline mode ( ko có internet), đăng nhập mà có điện thoại gọi đến mobile…  Boundary case gồm: Text số lương ký tự tối thiểu tối đa mà ô text cho nhập Có thể tạo email với nhiều ký tự để test, email ngắn để test.( Với trường hợp ko kiểm tra tính đắn follow đăng nhập mà kiểm tra khả cho nhập tối thiểu tối đa ô text.) 295 Hướng dẫn viết TESTCASES Đối với testcase chức năng:  Các bước thực mô tả bước thực đứng từ phía người dùng cuối bao gồm nhập liệu, nhấn button  Việc kiểm tra liệu DB so với thị hình nằm kết mong muốn  Thường dùng cho trường hợp kiểm thử kiểm tra lưu, cập nhật, xóa DB SELECT * FROM … WHERE… Ví dụ: Tạo email đăng ký thành cơng - Test tạo email đăng ký thành công Đã đăng nhập thành công email giao diện - Vào DB check xem email có lưu vào DB hay không? ( nhiên nhiều nơi ko yêu cầu tester vào 296 CSDL để check) Hướng dẫn viết TESTCASES Ví dụ: Thực viết TCs cho chức đăng nhập facebook  Xác định Yêu cầu: Form login bao gồm: text box email/điện thoại mật khẩu, button đăng nhập, link quên mật  298 Hướng dẫn viết TESTCASES Tương tự với ô mật khẩu: Tương tự với ô mật khẩu: thêm vào ô mật cần kiểm tra thêm tính mã hóa password Đối với button đăng nhập: Normal case gồm: Nhập giá trị vào text, click button đăng nhập, bấm phím enter từ bàn phím Abnormal case gồm: Click liên tục or enter liên tục vào button Boundary case gồm: không cần check trường hợp 299 Hướng dẫn viết TESTCASES Lưu ý viết testcases:  File testcase cần có step test đơn giản, minh bạch, dễ hiểu:  Step test phải viết chi tiết rõ ràng để tester khác đọc thực  Mục đích phạm vi testcase mô tả chi tiết  Điều kiện tiền đề, data test phải ghi testcase cần  Xây dựng TCs:  Testcase nên review chéo member team  Xác định case UI: Bao gồm UI chung form: màu sắc, font, size, color label, chiều dài, rộng, cao, loại textbox, button, vị trí form, textbox, button, link trang  Xác định case test chức năng: Ở chức đăng nhập gồm text box email/điện thoại mật khẩu, button đăng nhập, link quên mật Cho nên có case sau 297  Không nên gộp nhiều kết confirm vào case mà nên tách kết confirm case  Khi tạo testcase nên đứng vị trí End user  Testcase nên cover trường hợp kiểm thử như: Phân lớp tương đương, giá trị biên, điều kiện normal abnormal  Cả trường hợp free test khơng có đặc tả u cầu 300 50 21/07/2020 Hướng dẫn viết TESTCASES  Mục đích tạo testcase: Mục tiêu việc tạo tescase để xác nhận độ bao phủ kiểm thử ứng dụng, chứng quan trọng để xác nhận phần mềm có đủ tiêu chuẩn để triển khai hay không?  Testcase tạo tài liệu thức bắt buộc dự án để kiểm sốt chất lượng phần mềm  Tái sử dụng thay đổi, nâng cấp hệ thống  Testcase hiệu Testcase tốt/hiệu testcase có khả tìm lỗi cao 4.4.3 Tạo Test report  Trong giai đoạn testing, số document report tạo ra, ví dụ Test plan, Testcase, Test report tạo sau hoàn thành giai đoạn Testing Ngoài Daily Report, Weekly Report tùy theo yêu cầu đặc thù dự án  Báo cáo test thể tiến độ kiểm thử, tiến độ sửa lỗi số lượng lỗi tìm thấy hay tồn dự án Báo cáo kiểm thử công cụ để phục vụ cho đánh giá hay giám sát dự án có kịp tiến độ hay khơng, bàn giao hay release cho khách hàng hay không vấn đề cần giải mà số lượng lỗi nhiều, gây rủi ro tiến độ hồn thành dự án để có điều chỉnh kịp thời 301 Hướng dẫn viết TESTCASES 304 4.4.3 Tạo Test report Một testcase hiệu cần có đặc điểm sau: Chính xác, đầy đủ nghiệp vụ hệ thống  Độc lập (có thể thực mà không phụ thuộc vào testcase khác, dễ dàng chia cho nhiều người kiểm thử) Nội dung đơn giản, có mục đích rõ ràng đọc hiểu theo cách (đầu vào, đầu ra, bước thực rõ ràng)  Trình bày mạch lạc thống cho tồn tài liệu  Có khả tái sử dụng (có thể dễ dàng cập nhật sửa đổi)  302 4.4.2 Tạo Test Execution Thực test trực tiếp ứng dụng phần mềm sau lập trình viên bàn giao  Dựa test cases viết trước để thực test phần mềm Thực ghi nhận kết kiểm thử vào cột kết tài liệu kịch kiểm thử Nếu kết kiểm thử thất bại 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 q trình quản lý/xử lý lỗi (bug/ defect) 303 305 Defect/ Bug/ Fault Management System  Testing công việc thiếu trình xây dựng sản phẩm phần mềm Cho dù sản phẩm bạn đoạn chương trình, chức hay tồn ứng dụng bạn phải thực testing trước bàn giao Đó lúc kiểm tra lại xem sản phẩm làm có u cầu khách hàng khơng? Có vận hành ổn định nhiều tình giả định khơng? Có lỗi phát sinh khơng, ngun nhân để biết cách khắc phục hoàn thiện sản phẩm  Lỗi phần mềm gọi Defect Bug Fault tiếng anh  Không phải tất Lỗi gây xảy code, lỗi đến từ Đặc tả yêu cầu, thiết kế 306 51 21/07/2020 Defect/ Bug/ Fault Life Cycle (vòng đời Lỗi) Redmine tool: Màn hình Defect Fixed  Tester report bug (trạng thái New) > Xem xét xem có lỗi khơng:  Nếu khơng phải lỗi Reject Closed  Nếu Lỗi chuyển sang trạng thái Open > Developer fix lỗi > Tester thực test lại > Nếu lỗi Pass Close Nếu Lỗi cịn lỗi lại Reopen cho Dev fix lại  Tóm lại: tester phát Bug, ghi Bug lên hệ thống quản lý Lỗi assign cho lập trình viên Lập trình viên fixed lỗi tester thực test lại Nếu OK closed, lỗi chuyển trạng thái bug reopen để lập trình viên xem xét sửa lỗi 307 Redmine tool: Tool quản lý Defect 310 Redmine tool: Màn hình Chi tiết Lỗi 308 Redmine tool: Màn hình viết defect 311 Cách viết Bug/ Defect  Khi viết Bug miêu tả lỗi gồm nội dung quan trọng: + Thực tế: miêu tả chức bị lỗi ( capture ảnh lỗi) +Mong muốn: miêu tả chức chạy xác/ cách hoạt động Ví dụ 1: - Lỗi sau: Khi đăng ký email, ko có ký tự @ mà thành công Cách viết mô tả lỗi lên tool quản lý lỗi: - Thực tế: Đăng ký email không định dạng ko có @ mà đăng ký thành cơng - Mong muốn: Email phải format cho phép đăng ký thành cơng ( có @) Định dạng format chuẩn: abc@xy.aa 309 312 52 21/07/2020 Cách viết Bug/ Defect Độ nghiêm trọng: Severity Bug Ví dụ 2: Lỗi sau: Đăng nhập khơng thành cơng có khoảng trắng đầu cuối username  Cách viết mô tả lỗi lên tool quản lý lỗi: + Thực tế: Đăng nhập không thành cơng có khoảng trắng đầu cuối username + Mong muốn: Đăng nhập thành cơng có khoảng trắng đầu cuối username Trim space đầu tên đăng nhập  Mức độ nghiêm trọng bug thường mức độ tác động 313 bug đến sản phẩm  Mỗi dự án hay sản phẩm có tiêu chí đánh giá độ nghiêm trọng khác thơng thường có mức độ khác từ nghiêm trọng đến nghiêm trọng hơn:  Mức độ (Critical): Rất nghiêm trọng, làm cho PM "chết cứng" không sử dụng  Mức độ (Major): Nghiêm trọng, buộc phải sửa chữa để sử dụng yêu cầu đề  Mức độ (Minor): Nhẹ, không làm PM ngưng chạy, làm cho việc sử dụng PM khó khăn gây bất tiện cho người dùng  Mức độ (Cosmetic): Không ảnh hưởng đến chức hay hiệu PM quy định yêu cầu (như vấn đề thẩm mỹ thơng báo sai tả)  Thực tế việc xác định độ nghiêm trọng bug không hẳn lúc mang tính chất trắng-đen tuyệt đối 316 Cách viết Bug/ Defect Độ ưu tiên: Priority Bug Cách viết bug tiếng anh sau:  Đã bug phải sửa Tuy nhiên, có thực tế đội phát triển khó sửa hết tất bug lượt không đáng để sửa hết tất bug Do đó, đội phát triển phải cần đến độ ưu tiên bug để biết bug cần sửa trước bug sau Độ ưu tiên bug thường chia thành 3-4 cấp độ:  Mức độ (Immediate): Bug phải sửa lập tức, không công việc tiếp tục  Mức độ (High): độ ưu tiên cao; công việc bị ngăn trở nhiều lỗi chưa sửa  Mức độ (Medium): độ ưu tiên trung bình; cơng việc gặp vài khó khăn lỗi chưa sửa  Mức độ (Low): độ ưu tiên thấp nhất; công việc không bị ảnh hưởng lỗi phải sửa 314 Độ Ưu tiên ( Priority) & Độ nghiêm trọng (Severity) quản lý Bug Trong kiểm thử phần mềm hai khái niệm Độ ưu tiên (Priority) Độ nghiêm trọng (Severity) không xa lạ, đặc biệt quản lý bug Phụ thuộc vào độ ưu tiên mà lập trình viên thực fix bug 315 317 Độ ưu tiên: Priority Bug Xác định độ ưu tiên? Bug sửa trước bug sửa sau (hoặc không sửa)? Dựa vào độ nghiêm trọng bug Bug nghiêm trọng nhất, tác động đến người dùng nhiều ưu tiên sửa trước Bug nghiêm trọng sửa sau Xác định độ ưu tiên khuyến khích kỹ sư kiểm thử 318 bắt buộc 53 21/07/2020 BÀI TẬP CHƯƠNG Trình bày nội dung thiết kế ca kiểm thử Lấy ví dụ minh họa Liệt kê bước kịch kiểm thử Trong trình xây dựng kịch kiểm thử cần ý điều gì? Xây dựng Test Case cho chức đăng nhập phần mềm Selenium IDE Xây dựng Test Execution cho chức đăng nhập phần mềm Selenium IDE Xây dựng Test Report cho chức đăng nhập phần mềm Selenium IDE 319 54 ... test case 1-9 1-2 - 3-8 - 1-9 1-2 - 4-6 - 7-8 - 1-9 1-2 - 4-5 - 7-8 - 1-9 HOẠT ĐỘNG – xác định test case Đường mơ đun – Đường độc lập  Có thể tồn nhiều đường độc lập đường đi: 1-2 - 3-8 - 1-9 1-2 - 4-6 - 7-8 - 1-9  Đường... QUY TRÌNH KIỂM THỬ PHẦN MỀM 2.1 Các giai đoạn kiểm thử phần mềm 2.1 Các giai đoạn kiểm thử phần mềm 2.2 Nội dung kiểm thử Bắt đầu 2.2.1 Kiểm thử đơn vị 2.2.2 Kiểm thử tích hợp 2.2.3 Kiểm thử hệ... môi trường đội phát triển dự án – Kiểm thử đơn vị – Kiểm thử tích hợp – Kiểm thử hệ thống phần mềm – Kiểm thử chấp nhận Trong môi trường khách hàng – Kiểm thử alpha – Kiểm thử beta – Kiểm thử