Bài giảng Kiểm thử phần mềm - Bài 1: Software Testing

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