Bài giảng Kiểm thử phần mềm Bài

BÀI GIẢNG KIỂM THỬ PHẦN MỀM BÀI 1: I Các khái niệm, định nghĩa Software Testing II Các quy trình Sản xuất Phần mềm SOFTWARE TESTING ?      What is Software Testing? Why is Testing important? What is the objective of Software Testing? Who testing? Responsibilities of software tester? SOFTWARE TESTING gì?      Kiểm thử phần mềm (software testing) hoạt động nhằm tìm kiếm, phát lỗi phần mềm Kiểm thử phần mềm hướng đến mục tiêu xa gọi “phịng bệnh chữa bệnh” Tức nâng cao khả kiểm soát hạn chế lỗi xảy phát triển phần mềm từ ban đầu, không đơn việc tìm lỗi sẵn có nhóm phát triển đưa phiên cụ thể phần mềm Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng xác, đầy đủ theo yêu cầu khách hàng, yêu cầu sản phẩm đề đặt Software testing cung cấp mục tiêu, nhìn độc lập phần mềm, điều cho phép việc đánh giá hiểu rõ rủi ro thực thi phần mềm Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư đánh giá sáng tạo để bạn phát điểm mà người khác chưa nhìn thấy “It is also said to be an art to improve the quality of the software made.” Tại SOFTWARE TESTING quan trọng?    Kiểm thử phần mềm hoạt động giữ vai trò quan trọng để bảo đảm chất lượng phần mềm hoạt động mang tính sống cịn dự án sản xuất gia cơng phần mềm Vì vậy, kiểm thử phần mềm trở thành qui trình bắt buộc dự án phát triển phần mềm giới Làm cần kiểm tra, đánh giá biết liệu có đạt mong đợi, có sai sót khơng Kiểm thử phần mềm để tránh rủi ro, lỗi phát sinh suốt trình tạo sản phẩm Lỗi phát sớm giúp tránh rủi ro chi phí “Testing is important because software bugs could be expensive or even dangerous.” Mục tiêu SOFTWARE TESTING ?  Để kiểm tra xem phần mềm đáp ứng nhu cầu khách hàng phù hợp với đặc tả đảm bảo chất lượng tính xác ứng dụng  Nó thật có làm việc mong muốn?  Nó làm mà người sử dụng mong đợi?  Tiết kiệm thời gian chi phí xác định/ tìm kiếm thiếu sót/ lỗi sớm  Biết thỏa mãn yêu cầu khách hàng “The main objective of software testing is to maintain and deliver a quality product to the client.” Who SOFTWARE TESTING ?  Có nhiều đối tượng tham gia vào kiểm thử:      Software tester Software developer Project Leader/ Manager End User Điều xảy việc kiểm thử khơng tìm lỗi phần mềm phát lỗi  Phần mềm có chất lượng q tốt  Quy trình/Đội ngũ kiểm thử hoạt động không hiệu Trách nhiệm tester?         Phân tích tìm hiểu tài liệu Đặc tả u cầu phần mềm Tham gia vào chuẩn bị/ lập Test plans Thực viết test design, test cases (kịch kiểm thử) Thực test ( test execution) Theo dõi kết test Báo cáo kiểm thử ( test report) Giao tiếp với đội phát triển, khách hàng Các học rút để cải thiện chất lượng ứng dụng Các Mơ hình phát triển Phần mềm ( Software Life Cycle - SLC ) Một số mơ hình SLC phổ biến giới:       Waterfall model (thác nước) V model Iterative and Incremental model (mơ hình lặp tăng dần) RAD model (mơ hình phát triển ứng dụng nhanh) Spiral model ( mơ hình xoắn) Agile model (scrum process) Software Life Cycle gì?   Một kiến thức cần thiết kỹ sư kiểm thử phần mềm chuyên nghiệp hiểu biết nắm rõ SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm), kiểm thử phần mềm (software testing) phần liên quan chặt chẽ, mật thiết đến SDLC Quy trình yếu tố quan trọng đem lại thành công cho nhà sản xuất phần mềm, giúp cho thành viên dự án từ người cũ đến người mới, hay ngồi cơng ty xử lý đồng cơng việc tương ứng vị trí thơng qua cách thức chung cơng ty, hay cấp độ dự án Software Life Cycle gì?  Vai trị kiểm thử suốt quy trình 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 Mơ hình thác nước – Waterfall Mơ hình thác nước – Waterfall Mơ hình bao gồm giai đoạn xử lý nối tiếp sau:   Phân tích yêu cầu tài liệu đặc tả (Requirements and Specifications): giai đoạn xác định Yêu cầu liên quan đến chức phi chức mà hệ thống phần mềm cần có Giai đoạn cần tham gia tích cực khách hàng kết thúc tài liệu gọi “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification) Tài liệu Đặc tả yêu cầu tảng cho hoạt động cuối dự án Phân tích hệ thống thiết kế (System Analysis and Design): giai đoạn định làm để hệ thống phần mềm đáp ứng yêu cầu mà khách hàng yêu cầu tài liệu SRS Mơ hình thác nước – Waterfall    Lập trình (Coding and Unit Test): giai đoạn thực làm giai đoạn “Phân tích hệ thống thiết kế” Kiểm thử (Test): bao gồm kiểm thử tích hợp cho nhóm thành phần kiểm thử toàn hệ thống (system test) Một khâu kiểm thử cuối thường thực nghiệm thu (acceptance test), với tham gia khách hàng vai trị để xác định hệ thống phần mềm có đáp ứng yêu cầu họ hay khơng Cài đặt bảo trì (Deployment and Maintenance): giai đoạn cài đặt, cấu hình đào tạo cho khách hàng Giai đoạn sửa chữa lỗi phần mềm (nếu có) phát triển thay đổi khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm hệ thống) => Nhược điểm mơ hình waterfall: Thực tế cho thấy đến giai đoạn cuối dự án có khả nhận sai sót giai đoạn trước phải quay lại để sửa chữa Mơ hình chữ V – V model   Trong mơ hình Waterfall, kiểm thử thực giai đoạn riêng biệt Cịn với mơ hình chữ V, 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 kết hợp với giai đoạn kiểm thử tương ứng 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ử tồn hệ thống thực song song với hoạt động phân tích thiết kế hệ thống Mơ hình Xoắn ốc – Spiral model Mơ hình Xoắn ốc – Spiral model   Trong mơ hình xoắn ốc, quy trình phát triển phần mềm thực vịng xốy ốc Mỗi vòng xoắn ốc biểu diễn hoạt động tiến trình phát triển phần mềm Nó dựa ý tưởng tối thiểu hóa rủi ro, viêc phân tích yếu tố rủi ro bước lặp sử dụng phương pháp làm mẫu Quá trình phát triển chia thành nhiều bước lặp lại, bước bắt đầu việc lập kế hoạch, phân tích rủi ro, tạo mẫu, hoàn thiện phát triển hệ thống, duyệt lại, tiếp tục Nội dung gồm hoạt động chính: Lập kế hoạch: xác định mục tiêu, giải pháp ràng buộc; Phân tích rủi ro: phân tích phương án, xác định giải rủi ro; Mơ hình Xoắn ốc – Spiral model  Phát triển kiểm định: phát triển sản phẩm “mức tiếp theo” Xây dựng hay số biểu diễn ứng dụng Lên kế hoạch cho chu kỳ lặp tiếp theo: kiểm duyệt tất kết giai đoạn xảy trước lập kế hoạch cho chu kỳ lặp  Với lần lặp vòng xoắn ốc (bắt đầu từ tâm), phiên hồn thiện dần Tại vịng xoắn ốc, phân tích rủi ro phải đến định “ tiến hành tiếp hay dừng “ Nếu rủi ro lớn, đình dự án hay thay đổi u cầu đặt cho thích hợp Mơ hình thích hợp để phát triển hệ thống quy mô lớn Mơ hình Agile: quy trình Scrum   Scrum quy trình phát triển phần mềm theo mơ hình linh hoạt (agile) Cơng nghệ Agile cung cấp nhiều phương pháp luận, quy trình thực nghiệm việc phát triển phần mềm trở nên nhanh chóng dễ dàng Hiện Việt Nam, quy trình thực thi đội phát triển phần mềm số công ty lớn Product Owner tạo Product Backlog chứa yêu cầu dự án với hạng mục theo thứ tự ưu tiên Đội sản xuất thực việc thực hóa dần yêu cầu Product Owner với lặp lặp lại giai đoạn từ đến tuần làm việc (gọi Sprint) với đầu vào hạng mục Product Backlog, đầu gói phần mềm hồn chỉnh chuyển giao (Potentially Shippable Product Increment) Mơ hình Agile: quy trình Scrum Mơ hình Agile: quy trình Scrum ( Định nghĩa sprint: vòng lặp phát triển gọi sprint Sprint chu kỳ nhỏ để phát triển sản phẩm Trong Sprint, nhóm tập trung phát triển chức cụ thể hồn vào cuối Sprint Mỗi Sprint có thời gian cố định thống nhất, thường tuần thường không tuần)   Trước nhóm thực làm sprint, đội sản xuất họp với Product Owner để lập kế hoạch cho Sprint (gọi Scrum Meeting) Kết buổi lập kế hoạch (theo cách làm Scrum) Sprint Backlog chứa công việc cần làm suốt Sprint Trong suốt trình phát triển, nhóm phải cập nhật Sprint Backlog thực công việc họp ngày (Daily Scrum) để chia sẻ tiến độ công việc vướng mắc q trình làm việc Nhóm trao quyền để tự quản lí tổ chức lấy cơng việc để hồn thành cơng việc Sprint Mơ hình Agile: quy trình Scrum   Buổi họp Sơ kết Sprint (Sprint Review) cuối Sprint giúp khách hàng thấy nhóm chuyển giao gì, cịn phải làm cịn phải thay đổi hay cải tiến Sau kết thúc việc đánh giá Sprint, Scrum Master nhóm tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm cải tiến trước Sprint bắt đầu, điều giúp nhóm liên tục học hỏi trưởng thành qua Sprint Các Sprint lặp lặp lại hạng mục Product Backlog hoàn tất Product Owner định dừng dự án tình hình thực tế Do quy trình ln ln cải tiến, nhóm Scrum thường có suất lao động cao Đây hai lợi ích to lớn mà Scrum mang lại cho tổ chức Quy trình Scrum: họp  Scrum định nghĩa quy tắc cho bốn kiện chủ chốt (các họp) nhằm tạo môi trường quy cách hoạt động cộng tác cho thành viên dự án Các lễ nghi diễn trước Sprint bắt đầu (Sprint Planning), Sprint diễn (Daily Scrum) sau Sprint kết thúc (Sprint Review Sprint Retrospective): Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển họp với Product Owner để lên kế hoạch làm việc cho Sprint Công việc lập kế hoạch bao gồm việc chọn lựa yêu cầu cần phải phát triển, phân tích nhận biết cơng việc phải làm kèm theo ước lượng thời gian cần thiết để hoàn tất tác vụ Scrum sử dụng cách thức lập kế hoạch phần tăng dần theo thời gian, theo đó, việc lập kế hoạch khơng diễn lần vòng đời dự án mà lặp lặp lại, có thích nghi với tình hình thực tiễn tiến trình đến sản phẩm Quy trình Scrum: họp  Daily Scrum (Họp Scrum ngày):Scrum Master tổ chức cho Đội sản xuất họp ngày khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ cơng việc Trong họp này, người nhóm phát triển trình bày để trả lời câu hỏi sau:  Hơm qua làm gì?  Hơm làm gì?  Có khó khăn trở ngại khơng? Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển với Product Owner rà sốt lại cơng việc hồn tất (DONE) Sprint vừa qua đề xuất chỉnh sửa thay đổi cần thiết cho sản phẩm Sprint Retrospective (Họp Cải tiến Sprint): Dưới trợ giúp Scrum Master, nhóm phát triển rà sốt lại tồn diện Sprint vừa kết thúc tìm cách cải tiến quy trình làm việc thân sản phẩm Quy trình Scrum: vai trị  Trong Scrum, đội ngũ tham gia phát triển phần mềm phân chia ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa cơng việc đặc thù Ba vai trò bao gồm: Product Owner (chủ sản phẩm), Scrum Master Development Team (Đội sản xuất hay Nhóm Phát triển)  Product Owner: Là người chịu trách nhiệm thành công dự án, người định nghĩa yêu cầu đánh giá cuối đầu nhà phát triển phần mềm  Scrum Master: họ phải đảm bảo sprint hoàn thành mục đích, bảo vệ đội làm việc loại bỏ trở ngại  Development Team: thường từ 5-9 người, tùy theo quy mơ dự án có nhiều đội, nhiều người tham gia Bài 2: Nội dung buổi học tuần sau: HỌC PHẦN NỘI DUNG White-box testing Phân vùng tương đương (Equivalence partitioning) Phương pháp kiểm thử ( Testing Methods) Black-box testing Phân tích giá trị biên (Boundary value analysis) Vẽ Đồ Thị Nguyên Nhân Kết Quả (Cause-effect Graphing) Đoán lỗi – Error Guessing Các giai đoạn kiểm thử (Testing Levels) Quy trình kiểm thử (Testing Process) Unit testing Integration testing System testing Acceptance testing Quy trình kiểm thử phần mềm ... trọng?    Kiểm thử phần mềm hoạt động giữ vai trò quan trọng để bảo đảm chất lượng phần mềm hoạt động mang tính sống cịn dự án sản xuất gia cơng phần mềm Vì vậy, kiểm thử phần mềm trở thành... Cycle gì?  Vai trị kiểm thử suốt quy trình 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... thức cần thiết kỹ sư kiểm thử phần mềm chuyên nghiệp hiểu biết nắm rõ SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm) , kiểm thử phần mềm (software testing) phần liên quan chặt