zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Công Nghệ Thông Tin

» Kỹ thuật lập trình

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

Chia sẻ: HidetoshiDekisugi HidetoshiDekisugi | Ngày: | Loại File: PDF | Số trang:54

Báo xấu

67
lượt xem 8
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

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

21/07/2020 Chương 1. Tổng quan về 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ử Bộ môn Công nghệ thông tin 1.2.2. Đảm bảo chất lượng Trường Đại học Thương mại 1.2.3. Kiểm soát chất lượng sản phẩm 1.3. Các nguyên tắc kiểm thử 1.4. Vai trò kiểm thử phần mềm 4 Tài liệu tham khảo 1.1.1. Khái niệm phần mềm Ian Sommerville, Software Engineering, 10th Khái niệm phần mềm Edition, 2016. Một phần mềm gồm 3 thành phần: Glenford J. Myers, Tom Badgett, Todd M.  Chương trình máy tính: mã nguồn, mã máy Thomas, Corey Sandler, The Art of Software  Cấu trúc dữ liệu: cấu trúc làm việc (bộ nhớ trong) và cấu trúc lưu trữ (bộ nhớ ngoài) Testing, 2011.  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 Ron Patton, Software Testing, Second Edition, hệ thống), tài liệu tham khảo kỹ thuật (dành cho người bảo Sam Publishing, 2009. trì) http://www.seleniumframework.com/ Phần mềm được coi là tất cả các kỹ thuật ứng dụng để thực hiện những dịch vụ chức http://www.tester.vn/ năng cho mục đích nào đó bằng phần cứng, http://www.testingvn.com/ làm cho sử dụng phần cứng máy tính đạt hiệu quả cao. 2 5 Nội dung 1.1.1. Khái niệm phần mềm Chương 1. Tổng quan về kiểm thử phần mềm Chương 2. Quy trình kiểm thử phần mềm Chương 3. Các công cụ kiểm thử phần mềm Chương 4. Thiết kế ca kiểm thử 3 6 1
21/07/2020 Nhóm kỹ thuật, phương pháp luận 1.1.2. Vòng đời phát triển PM Các khái niệm và trình tự cụ thể hóa Là khoảng thời gian tính từ khi phần một hệ thống mềm được đề xuất cho đến khi bỏ đi: Các phương pháp tiếp cận giải quyết cụ thể là từ khi được đặt hàng, phát vấn đề triển, sử dụng đến khi bị loại bỏ. Các trình tự thiết kế và phát triển Vòng đời phần mềm được phân chia được chuẩn hóa thành các pha chính như xác định yêu Các phương pháp đặc tả yêu cầu, thiết cầu, triển khai, kiểm thử, bảo trì (vận kế hệ thống, thiết kế chương trình, hành)... Phạm vi, thứ tự các pha khác kiểm thử, toàn bộ quy trình quản lý nhau tùy theo từng mô hình, dự án cụ phát triển phần mềm. 7 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ừ các nhóm Tùy mô hình áp dụng mà việc phân lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ liệu chia các pha, các bước có thể có sự  Phần mềm cơ bản: với chức năng cung cấp môi trường khác nhau: từ 3 đến 20 pha. thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng xử lý của phần cứng (ví dụ như OS là chương trình hệ thống) Xác định yêu cầu Triển khai Kiểm thử  Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp nào đó (quản lý, kế toán, . . .), phần mềm đóng gói, phần (VËn hµnh) Bảo trì mềm của người dùng, . . . Vòng đời phần mềm 8 11 1.1.2. Vòng đời phát triển PM Nhóm các tư liệu Những tư liệu hữu ích, có giá trị cao và  Các giai đoạn phát triển phần mềm rất cần thiết để phát triển, vận hành và 1. Phân tích tính khả thi và đặc tả yêu cầu bảo trì phần mềm 2. Phân tích 3. Thiết kế Để xây dựng phần mềm với độ tin cậy 4. Mã hóa cao cần tạo ra các tư liệu chất lượng 5. Kiểm thử cao: đặc tả yêu cầu, mô tả thiết kế từng 6. Cài đặt loại, điều kiện kiểm thử, thủ tục vận 7. Bảo trì hành, hướng dẫn thao tác, … 9 12 2
21/07/2020 Phân tích tính khả thi 3. Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được. Phân tích tính khả thi Có hai loại yêu cầu cần được xác định: * Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên bổ Xác định vấn đề cần giải quyết sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử Xem xét các giải pháp và kỹ thuật khác nhau dụng. * Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các chức (đánh giá ưu nhược điểm của từng giải năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống pháp) sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành bản hợp đồng giữa khách hàng và nhà thầu. Đánh giá về thời gian, giá thành, nguồn tài 4. Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế hay không, có thống nhất không, có đầy đủ không. Nếu nguyên cần thiết phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này. Sản phẩm: tài liệu phân tích 13 16 Đặc tả yêu cầu Đặc tả yêu cầu  Phân tích và đặc tả yêu cầu Xác định nhu cầu của khách hàng/người sử dụng  Xác định bài toán, chứ không phải là giải pháp Khó khăn  Khách hàng không biết rõ cái họ cần  Khách hàng không trình bày rõ cái 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 còn gọi là kỹ thuật xác định yêu cầu) là quy  Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu những tài liệu đặc tả. Hoạt động thiết kế bao gồm những công việc và các ràng buộc trong quá trình vận hành và xây dựng hệ chính sau: thống.  Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng  Quy trình xác định yêu cầu bao gồm bốn pha chính: và mối quan hệ giữa chúng được xác định và tư liệu hoá. 1. Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định  Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các những yêu cầu của người sử dụng có thoả mãn những công dịch vụ của nó và những ràng buộc khi nó vận hành. nghệ hiện tại hay không. Về góc độ kinh doanh, nghiên cứu  Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những khả thi nhằm xác định hệ thống đưa ra có mang lại lợi hệ thống con khác phải được thiết kế và tư liệu hoá. nhuận không. Việc nghiên cứu khả thi nên được thực hiện  Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các một cách nhanh chóng và không quá tốn kém. Kết quả của giao diện tương tác với chúng phải được thiết kế. việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng  Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ hệ thống nữa hay không. thống phải được thiết kế một cách chi tiết và cụ thể. 2. Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các  Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ yêu cầu hệ thống thông qua một số phương pháp như: quan phải được thiết kế chi tiết và chính xác. sát hệ thống hiện tại, phỏng vấn và 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 hoặc hệ thống cũ … Trong pha này, chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống và các mẫu thử. 15 18 3
21/07/2020 Phân tích Mã hóa và gỡ rối Mã hóa và gỡ rối Mã hóa: cài đặt các thiết kế bằng ngôn ngữ lập trình không đơn thuần chỉ là 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 bản Gỡ rối: phát hiện các lỗi trong quá trình lập trình Sản phẩm: chương trình 19 22 Thiết kế phần mềm Kiểm thử Các công việc trong thiết kế phần mềm Kiểm thử - Đánh giá phần mềm hay còn gọi là thẩm tra và đánh giá (V&V - Verification and validation) được sử dụng để chỉ ra rằng hệ thống đã thực hiện theo đúng các đặc tả và thoả mãn mọi yêu cầu của khách hàng. Kiểm thử bao gồm các công đoạn: kiểm tra, xem xét lại, và kiểm thử hệ thống. Kiểm thử hệ thống tức là cho hệ thống thực hiện trên những trường 20 hợp có dữ liệu thật được lấy từ tài liệu23 đặc tả hệ thống. Quy trình kiểm thử 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 năng  Bảo đảm chương trình vận hành tốt  Hướng đối tượng Cài đặt các thay đổi Cài đặt các yêu cầu mới Xử lý các lỗi khi vận hành Sản phẩm: chương trình 21 24 4
21/07/2020 1.1.3. Các mô hình phát triển PM Bảo trì hệ thống Hiện nay có rất nhiều mô hình phát Cải tiến phần mềm triển phần mềm, và thường được phân Khi các yêu cầu hệ thống thay đổi theo sự thành 2 loại: mô hình tuyến tính và mô thay đổi của các yêu cầu nghiệp vụ thì phần hình lặp. mềm phải cải tiến và thay đổi để hỗ trợ Mô hình tuyến tính: các bước được thực khách hàng. Thông thường chi phí để bảo trì hiện tuần tự, không lặp lại. và cải tiến thường đắt hơn nhiều so với chi  Mô hình thác nước phí xây dựng phần mềm.  Mô hình V… Mô hình lặp: các bước có thể thực hiện song song, có thể lặp lại một số bước.  Mô hình tiến hóa  Mô hình xoắn ốc 25  Mô hình hợp nhất… 28 1.1.2. Vòng đời phát triển phần mềm a. Mô hình Thác nước Mô hình thác nước (Water Fall Model) 26 29 1.1.2. Vòng đời phát triển phần mềm a. Mô hình Thác nước Các pha của mô hình thác nước bao  Kiểm thử cần thực hiện trong suốt gồm: vòng đời của phần mềm Phân tích và xác định các yêu cầu Kiểm thử không tồn tại độc lập. Thiết kế hệ thống và phần mềm Các hoạt động của kiểm thử luôn gắn liền với Cài đặt và kiểm thử đơn vị các hoạt động phát triển phần mềm. Tích hợp và kiểm thử hệ thống Các mô hình phát triển phần mềm khác nhau Vận hành và bảo trì. cần các cách tiếp cận test khác nhau. 27 30 5
21/07/2020 a. Mô hình Thác nước b. Mô hình V Bảo trì Là mô hình cổ điển Phương pháp áp dụng 1 lần Phân tích yêu Kiểm thử chấp cầu nhận Điều khiển hiệu quả Thiết kế hệ Kiểm thử hệ Phạm vi giới hạn của vòng lặp thống thống Vòng đời dài Thiết kế Kiểm thử đơn vị và chương trình tích hợp Không thích hợp với các hệ thống không rõ ràng Lập trình 31 34 Ứng dụng b. Mô hình V Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha Trong mô hình V: trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là Các tiến trình kiểm thử được thêm vào rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng Kết nối kiểm thử với phân tích và thiết kế lúc này lại có sự thay đổi yêu cầu của người sử dụng; thì chỉ còn cách là phải thực hiện lại từ đầu. Thích hợp với những trường hợp bài toán Mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được không nhất quán giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định. 32 35 Nhận xét b. Mô hình V Ưu điểm: 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 Chỉ phù hợp với các dự án nhỏ hoặc giai đoạn phát triển sẽ tiến hành song song với một Yêu cầu xác định giai kiểm thử tương ứng => các lỗi được phát hiện Nhược điểm: sớm ngay từ đầu Tinh thần chủ đạo của V-model là các hoạt động kiểm Không phù hợp với dự án lớn thử phải được tiến hành song song (theo khả năng có Thời gian thực hiện lâu 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. 33 36 6
21/07/2020 b. Mô hình V c. Mô hình bản mẫu  Giai đoạn phát triển:  Xác định yêu cầu và đặc tả (Requirement & Specification): Xác định Mục đích yêu cầu cần thiết mà hệ thống đòi hỏi, đưa ra bản đặc tả. Xem xét yêu cầu người sử dụng ở giai đoạn  Phân tích hệ thống (System Analysis): Phân tích các yêu cầu mà hệ thống cần có và đưa ra giải pháp tích hợp các yêu cầu đó vào hệ thống. ban đầu  Thiết kế chi tiết (Detailed Design): Chi tiết hóa các bước thực hiện xây Giảm bớt rủi ro và không chắc chắn dựng hệ thống (Về cả giao diện và nội dung).  Phát triển (Development ): Thực hiện việc viết code Kiểm chứng thiết kế và thực thi  Giai đoạn kiểm thử: Nên thường xuyên trả lời các câu hỏi  Kiểm tra từng thành phần và tích hợp (Unit & Intergration Test): Kiểm tra các module của hệ thống tương ứng với pha thiết kế chi tiết. chuyên biệt; mục đích phải được xác  Kiểm thử toàn hệ thống (System Test): kiểm thử hoạt động của hệ thống (về chức năng, giao diện). định.  Nghiệm thu (Accepted Test): Kiểm tra lần cuối cùng và nghiệm thu sản phẩm đưa vào sử dụng. 37 40 b. Mô hình V Lợi ích của bản mẫu  Với V model thì công việc test được tham gia ngay từ đầu, từ Học bằng cách làm việc lúc lấy yêu cầu là có thể "test" bằng cách review tài liệu yêu cầu, rồi cho tới review đặc ta chi tiết, các bản thiết kế,... review Tăng cường giao tiếp code rồi cuối cùng là test ở mức thấp nhất - từng module, chức năng, màn hình,... đến test tích hợp rồi kiểm thử hệ thống. Tăng sự tham gia của người dùng vào  So với mô hình khác thì ở mô hình này, công việc test đi sát dự án hơn và ngay từ đầu khi bắt đầu phát triển. Chắc chắn chất lượng dự án sẽ tốt hơn. Nhưng tại sao người ta vẫn tiếp tục đưa Làm rõ các yêu cầu chỉ biết một phần ra mô hình phát triển khác? Vì ở mô hình chữ V này người ta vẫn phát triển cùng lúc cả hệ thống (nhiều yêu cầu, chức năng cùng lúc) mà rủi ro (risk) về thay đổi yêu cầu là rất lớn. Nên mô hình này vẫn có thể gặp rắc rối khi khách hàng thường xuyên thay đổi yêu cầu. 38 41 c. Mô hình bản mẫu Tuần tự làm bản mẫu Tập hợp yêu cầu Thiết kế nhanh Nghe Khách Tạo / sửa trình bày bản mẫu Xây dựng bản mẫu Đánh giá của khách hàng Làm mịn Khách kiểm tra bản mẫu Quay lại thiết kế nhanh để điều chỉnh Mô hình bản mẫu (Prototyping model) Xây dựng sản phẩm 39 42 7
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 Phân tích rủi ro Yêu cầu không chắc chắn 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 mới Nâng cấp Khách hàng Xây dựng & đánh giá Xuất xưởng Bảo trì Mô hình xoắn ốc (spiral) 43 46 Đánh giá d. Mô hình xoắn ốc Hạn chế: (Boehm 1987) Chi phí tăng thêm Khách hàng có thể cho rằng nguyên mẫu là Xác định mục đích, Đánh giá lựa chọn; hệ thống thực lựa chọn và ràng Phân tích xác định và giải buộc rủi ro quyết rủi ro  Mong đợi không thực tế về tiến triển của dự án Phân tích rủi ro Người phát triển có sự chọn lựa không tốt Phân tích rủi ro Bản mẫu Bản mẫu  Phù hợp cho nguyên mẫu, nhưng không phù hợp cho hệ Bản mẫu thống thực Lập kế hoạch yêu cầu Chức năng Yêu cầu phần mềm Thiết kế hệ Thiết kế chi tiết thống Nguyên mẫu không giống hoàn toàn hệ Lập kế hoạch phát triển Kiểm thử yêu cầu thống cuối cùng Lập Kế hoạch kiểm trình thử và tích hợp Kiểm thử  Khách hàng sẽ có các phản ứng khác nhau thiết kế Kiểm thử Phát triển và kiểm Kế hoạch cho giai đoạn tiếp Tích hợp và đơn vị chứng sản phẩm Kiểm thử kiểm thử chấp nhận mức tiếp theo 44 47 Ứng dụng d. Mô hình xoắn ốc  Trong mô hình xoắn ốc, quy trình phát triển phần mềm Mô hình bản mẫu thường được sử dụng được biểu diễn như một vòng xoắn ốc. Các pha trong quy khi: 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 từng pha của dự án. Khi mới rõ mục đích chung chung của phần  Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hành động để giảm thiểu rủi ro. hoặc chưa rõ yêu cầu đầu ra  Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung. Dùng như “Hệ sơ khai” để thu thập yêu cầu  Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc người dùng qua các thiết kế nhanh sẽ được lập kế hoạch. Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng 45 48 8
21/07/2020 d. Mô hình xoắn ốc Đánh giá Nhấn mạnh việc đánh giá các rủi ro Ưu điểm Phần mềm được xây dựng theo nhiều Hạn chế rủi ro sớm chu kỳ. Mỗi chu kỳ tương ứng với một Nhận được phản hồi ( feedbacks) từ khách sản phẩm của 1 giai đọan phát triển hàng sớm Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa Xác định các mục tiêu, giải pháp, ràng buộc Đánh giá các giải pháp, xác định các nguy cơ Hạn chế và tìm cách giải quyết chúng Khó thuyết phục khách hàng là phương pháp tiến hóa xoắn ốc có thể kiểm soát được Phát triển và kiểm thử sản phẩm của chu kỳ Chưa được dùng rộng rãi như các mô hình tuyến tính này hoặc chế thử. Lập kế hoạch cho chu kỳ tiếp theo 49 52 d. Mô hình xoắn ốc (tiếp) Ứng dụng  Giao tiếp khách hàng: giữa người phát triển và khách Mô hình xoắn ốc phù hợp với hàng để tìm hiểu yêu cầu, ý kiến Các hệ phần mềm quy mô lớn, các dự án lớn,  Lập kế hoạch: Xác lập tài nguyên, thời hạn và những phức tạp thông tin khác Hệ thống cần phát triển nhiều phiên bản  Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo Các hệ thống có yêu cầu chưa xác định rõ ràng hiểm quản lý  Thiết kế: Xây dựng một hay một số biểu diễn của ứng dụng 50 53 d. Mô hình xoắn ốc (tiếp) e. Mô hình hợp nhất  Mô hình hợp nhất sử dụng Các kỹ thuật thế hệ 4 (Fourth generation techniques): Tập hợp các công cụ Xây dựng và xuất xưởng: xây dựng, kiểm thử, cho phép xác định đặc tính phần mềm ở mức cao, sau cài đặt và cung cấp hỗ trợ người dùng (tư liệu, đó tự động sinh mã nguồn dựa theo đặc tả đó. huấn luyện, . . .)  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ý dữ liệu, tương tác Đánh giá của khách hàng: Nhận các phản hồi màn hình, tạo mã nguồn, khả năng đồ họa bậc cao, khả của người sử dụng về biểu diễn phần mềm trong năng bảng tính, khả năng giao diện Web.  Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa giai đoạn kỹ nghệ và cài đặt khách và người phát triển là quan trọng.  Không nên bỏ qua khâu thiết kế: 4GT chỉ áp dụng để triển khai thiết kế qua ngôn ngữ lập trình thế hệ 4 (4GL- Fourth-generation programming language). 51 54 9
21/07/2020 e. Mô hình hợp nhất e. Mô hình hợp nhất Tiến trình hợp nhất có thể được nhìn Góc nhìn kỹ thuật dưới hai góc nhìn khác nhau Góc nhìn quản lý: quan tâm đến lĩnh vực kinh tế, chiến thuật, con người.  Tiến trình gồm 4 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 nhất e. Mô hình hợp nhất Góc nhìn quản lý Kết hợp hai góc nhìn 56 59 e. Mô hình hợp nhất e. Mô hình hợp nhất Góc nhìn kỹ thuật: các bước lặp Mô hình hợp nhất và UML Mỗi bước lặp gồm các 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 là một tiến trình thác đổ 57 60 10
21/07/2020 e. Mô hình hợp nhất f. Mô hình Agile: quy trình Scrum Ưu điểm: giảm thời gian phát triển và Scrum là một quy trình phát triển phần mềm theo tăng năng suất lao động. mô hình linh hoạt (agile). Vì thế, nó tuân thủ các nguyên tắc của Agile Nhược điểm: 4GT khó dùng hơn ngôn Scrum rất linh hoạt như các phương pháp Agile ngữ lập trình, mã khó tối ưu và khó khác. Nhờ đó nó mang lại tính thích nghi rất cao. bảo trì cho hệ thống lớn  cần kỹ Dựa trên các thông tin minh bạch hóa từ các quá năng của kỹ sư phần mềm trình thanh tra và làm việc, Scrum có thể phản hồi Trong tương lai: kết hợp 4GT với mô lại các thay đổi một cách tích cực, nhờ đó mang hình hướng thành phần. lại thành công cho dự án. 61 64 f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum  Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt  Các công cụ (artifacts) Scrum càng sớm càng tốt.  Product backlog: Đây là danh sách ưu tiên các tính năng  Đặc trưng Agile: (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner  ◦Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục Sprint) này thường có khung thời gian ngắn (từ 1 – 4 tuần). Trong (Product Backlog Item) trong Product Backlog dựa trên các mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công giá trị do Product Owner định nghĩa việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển  Sprint backlog: Đây là bản kế hoạch cho một Sprint; là kết khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết nhỏ của sản phẩm. hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo  ◦Các phân đoạn (Sprint) lặp đi lặp lại trong Agile: Các phương độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá trong Product Backlog dưới dạng danh sách công việc trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực (TODO list). hiện việc lập kế hoạch dài hạn. 62 65 f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum Product Owner tạo ra Product Backlog chứa các yêu  Đặc trưng Agile:  ◦Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary): Cuối các cầu của dự án với các hạng mục được sắp theo thứ tự phân đoạn (Sprint), nhóm phát triển thường cho ra các phần nhỏ của sản ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa phẩm cuối cùng. Các phần nhỏ này thường là đầy đủ, có khả năng chạy dần các yêu cầu của Product Owner với sự lặp đi lặp tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality). Theo thời gian, phân đoạn lại các giai đoạn từ 1 đến 4 tuần làm việc (gọi là (sprint) này tiếp nối phân đoạn (sprint) kia, các phần chạy được này sẽ Sprint) với đầu vào là các hạng mục trong Product được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Backlog, đầu ra là các gói phần mềm hoàn chỉnh có  ◦Tính thích ứng (hay thích nghi – adaptive): Do các Sprint chỉ kéo dài thể chuyển giao được (Potentially Shippable Product trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều Increment) chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có Đội sản xuất cùng họp với Product Owner để lập kế thể được đáp ứng theo cách thích hợp. Theo đó, các quy trình Agile hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch thường thích ứng rất tốt với các thay đổi. (theo cách làm của Scrum) là Sprint Backlog chứa các 63 công việc cần làm trong suốt một Sprint. 66 11
21/07/2020 f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum Các Sprint sẽ được lặp đi lặp lại cho tới  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 khi nào các hạng mục trong Product 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 Backlog đều được hoàn tất 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. 67 70 f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum  Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint  2. Daily Scrum (Họp Scrum hằng ngày):Scrum Master tổ chức cho Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá 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 trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí triển lần lượt trình bày để trả lời 3 câu hỏi sau: và tổ chức lấy công việc của mình để hoàn thành công việc  Hôm qua đã làm gì?  Hôm nay sẽ làm gì? trong Sprint.  Có khó khăn trở ngại gì không?  Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức  3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi giúp khách hàng thấy được nhóm đã có thể chuyển giao những cần thiết cho sản phẩm. gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải  4. Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum Master và của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) 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 để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều sản phẩm. này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint. 68 71 f. Mô hình Agile: quy trình Scrum f. Mô hình Agile: quy trình Scrum  Trong Scrum, đội ngũ tham gia phát triển phần mềm được Quy trình Scrum được vận hành thế phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo nà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. 69 72 12
21/07/2020 Kiểm thử trong mô hình Agile  Ko thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ của hệ thống vào  Lựa chọn mô hình code và testing cùng 1 lúc ( như quy trình truyền thống) mà sẽ Phụ thuộc vào bài toán, vào môi chia các Yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn chỉ làm 1 số lượng yêu cầu nhất định trường cụ thể  Chia thành nhiều giai đoạn nhỏ để thực hiện hay còn gọi là Sprint  Mỗi 1 sprint thường kéo dài từ 1 tuần đến 4 tuần ( ko dài hơn 1 Yêu cầu rõ ràng: => Mô hình thác nước tháng)  Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ  Yêu cầu chưa rõ ràng, độ phức tạp cao thực hiện code và test. Cuối sprint là 1 sản phẩm hoàn thiện cả  Yêu cầu có khả năng thay đổi code lẫn test có thể demo và chạy được.  Không chắc chắn về tính hiệu quả, tính khả thi  Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint... cho đến khi hoàn thành hết các yêu cầu. => Làm bản mẫu, mô hình xoắn ốc, Agile 73 76 Kiểm thử trong mô hình Agile  Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting. Cả team Một số lưu ý sẽ đứng họp thành 1 vòng tròn, thường chỉ họp ngắn từ 15 – 20 phút. Mỗi thành viên sẽ báo cáo: hôm qua tôi đã làm gì? Hôm nay tôi sẽ làm gì? Có gặp khó khăn gì ko?  Trong mỗi 1 sprint thì các thành viên của dự án phải tạo task cho code và test,1 task code xong là phải có task test liền ngay đó. Do  Tổ hợp các mô hình: thời gian làm ngắn ngày nên hiệu quả làm việc phải cao, đúng tiến Có thể tổ hợp các mô hình để đem lại hiệu quả độ để đảm bảo cuối sprint là hoàn thành được cả test. ( ý này nếu bị hỏi mới kể)  Ưu điểm của quy trình này là phù hợp với những yêu cầu/ nghiệp vụ hay thay đổi, hoặc hệ thống nghiên cứu do làm theo từng giai đoạn ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù hợp để thay đổi ( ý này nếu bị hỏi mới kể)  Điều hành đội dự án sẽ là ông scrum master, còn có product owner là người đánh giá phần mềm làm đã theo đúng nghiệp vụ/ yêu cầu chưa ( ý này nếu bị hỏi mới kể) 74 77 Kết luận Một số lưu ý Trong thực tế, người ta thường kết hợp nhiều mô hình cho một dự án Đối với Hệ thống phức tạp, cần chia dự  Lặp tiến trình: án thành các hệ thống con Mỗi phần của tiến trình được lặp theo 2 cách tiếp cận  Áp dụng mô hình xoắn ốc hay mô hình hợp nhất cho toàn bộ dự án. • Phát triển gia tăng  Mỗi hệ thống con có thể áp dụng một mô hình khác nhau  Áp dụng mô hình nguyên mẫu cho các hệ thống con phức • Phát triển xoắn ốc tạp  Áp dụng mô hình thác nước cho các hệ thống con khác 75 78 13
21/07/2020 1.2. Khái niệm kiểm thử phần mềm Một số lưu ý Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay các thành phần dưới những điều kiện xác định; quan sát, ghi  Chuẩn hóa tiến trình: lại kết quả, và đánh giá một khía cạnh nào Tăng năng lực của tổ chức phát triển phần mềm đó của hệ thống hay thành phần đó. (Theo IEEE Standard Glossary of Software • ISO 9000-03 (International Standards Organization ) Engineering Terminology). • CMM (Software Engineering Institute) Kiểm thử là giai đoạn quan trọng đảm bảo chất lượng phần mềm. 79 82 1.2.1. Khái niệm kiểm thử Một số lưu ý Kiểm thử là tiến trình xem xét, kiểm tra lại đặc tả, phân tích, thiết kế và  Giảm chi phí phát triển: mã hoá nhằm phát hiện lỗi phần Sử dụng các phương pháp, công cụ tiên tiến mềm, xác minh phần mềm có đúng • tái sử dụng: thư viện thương mại,... đặc tả, thiết kế; có đáp ứng nhu cầu • tự sinh mã: công cụ tạo giao diện,... người dùng, có hoạt động hiệu quả không . • hướng đối tượng: kế thừa, bảo trì Kiểm thử thành công khi phát hiện • ngôn ngữ bậc cao: năng lực biểu diễn cao ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Theo Sue A.Conger- The New SE) 80 83 1.2.1. Khái niệm kiểm thử Một số lưu ý  Software Testing là một quá trình thực thi một chương trình với mục đích tìm lỗi.  Thực hiện các pha phát triển:  Quality Testing = Verification + Validation (Xác minh  Pha xác định yêu cầu và thiết kế có vai trò quyết định và Thẩm định) đến chất lượng phần mềm, chiếm phần lớn công sức so  Là hoạt động kiểm tra xem phần mềm có chạy chính xác với mã hóa, kiểm thử. hay không (Verification) và có thoả mãn yêu cầu của  Khi chuyển tiếp giữa các pha phát triển phải thẩm định khách hàng hay không (Validation) nhằm hướng tới mục để đảm bảo lỗi không ảnh hưởng đến pha sau. tiêu chất lượng của phần mềm.  Tài liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế tiếp mà còn dùng để đảm bảo chất lượng của phần mềm và dùng trong khâu bảo trì.  Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tài liệu nhằm đảm bảo chất lượng phần mềm. 81 84 14
21/07/2020 1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng  Kiểm thử là một quá trình đánh giá một hệ thống hay là  QA: Giám sát, quản lý và đảm bảo chất lượng các thành phần của nó với mục đích là xác định xem nó có  QA ( Quality Assurance ), là những công việc đảm bảo chất thỏa mãn những yêu cầu được đưa ra hay không. Hiểu một lượng của việc xây dựng hệ thống, quy trình sản xuất của công cách đơn giản, kiểm thử - test là chạy một chương trình để ty theo một chuẩn mực. Giám sát chặt chẽ và đo lường việc xác nhận bất kì lỗ hổng, lỗi sai hay những yêu cầu bị bỏ thực hiện các chuẩn chất lượng trong các giai đoạn từ nghiên quên, những yêu cầu không đúng so với yêu cầu thực tế đề cứu thị trường, thiết kế… cho đến sản xuất và bán hàng, chăm sóc khách hàng. ra.  QA có nhiệm vụ giám sát để bảo đảm các tiêu chuẩn và quy trình sản  Theo tiêu chuẩn ANSI/IEEE 1059, kiểm thử như một quá xuất PM được định nghĩa và tuân thủ nghiêm túc, hướng đến mục trình của việc phân tích các thành phần của phần mềm để tiêu các sản phẩm (SP) trung gian cũng như SP sau cùng của dự án dò tìm sự khác biệt giữa phần mềm thực tế đang tồn tại và thỏa mãn các tiêu chuẩn và yêu cầu đã định trước đó. Công việc của những điều kiện được yêu cầu – requirement.(đó là thiếu QA liên quan đến quy trình (process). sót – defect, sai sót - error, lỗi - bug). Từ đó đánh giá được chất lượng của sản phẩm phần mềm. 85 88 1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng  Thông thường, trong một dự án PM, khách hàng chỉ trả tiền cho lưc lượng sản xuất trực tiếp như developer và tester, do đó đầu tư vào lực lượng QA là một đầu tư mang tính nội bộ và nền tảng, giúp công ty cải tiến và kiểm soát các quy trình đảm bảo chất lượng Một khi quy trình sản xuất được tuân thủ nghiêm túc, lỗi xuất hiện ở các khâu sản xuất sẽ được nhận diện và ngăn chặn sớm, SP sau cùng (ở chặng kiểm định) sẽ ít lỗi và khả năng thành công của dự án được bảo đảm hơn, do đó tổng chi phí sẽ thấp hơn. 86 89 1.2.1. Khái niệm kiểm thử 1.2.2. Đảm bảo chất lượng 2 mục đích chính của hoạt động  Quy trình bao gồm các biểu mẫu, các bước và hướng dẫn cụ thể giúp thành viên dự án thực hiện một công việc nào đó một cách nhất quán kiểm thử: và có kiểm soát. Có rất nhiều quy trình khác nhau được thiết kế tùy theo nhu cầu của một dự án như Quy trình phát triển yêu cầu SP Kiểm tra xem phần mềm làm ra có đúng (Requirement); Quy trình thiết kế SP (Design); Quy trình triển khai đặc tả (yêu cầu, phân tích, thiết kế) hay và viết code (Coding); Quy trình kiểm định SP (Testing); Quy trình cài đặt và hỗ trợ (Delivery); Quy trình bảo trì SP (Maintenance); Quy không. trình quản trị dự án (Project management); Quy trình quản lý cấu Kiểm tra xem phần mềm có đáp ứng yêu hình (Coonfiguration management); Quy trình đảm bảo chất lượng (Quality Assurance). cầu người dùng hay không. Đây chính là 2 hoạt động cốt yếu để đảm bảo chất lượng phần mềm, diễn ra trong suốt quá trình phát triển phần mềm. 87 90 15
21/07/2020 1.2.2. Đảm bảo chất lượng 1.2.3. Kiểm soát chất lượng phần mềm  QA là người tham gia phát triển quy trình hoạt động ở cấp  QC (Quality Control) là những công việc liên quan công ty và ở cấp dự án, đánh giá các tài liệu. Ngoài ra, họ đến kiểm soát, kiểm tra, đánh giá chất lượng của sản còn phải giám sát và kiểm tra (audit) các hoạt động được phẩm. QC là một trong những khâu trong quy trình thực hiện trong dự án xem chúng có tuân thủ các quy trình sản xuất rất quan trọng, được tiến hành xen kẽ trong (process) đã được định ra; xác định các điểm không tương thích với quy trình (process noncompliance – gọi tắt là những công đoạn sản xuất, tạo ra những sản phẩm có NC) và báo cáo cho những người liên quan và các cấp chất lượng theo yêu cầu. QC thường hoạt động trong quản lý đồng thời giám sát để bảo đảm chúng được giải những nhà máy sản xuất theo quy trình, những quy quyết đến khi hoàn tất. trình công nghệ hiện đại, trong các lĩnh vực về kĩ  Nhân sự QA cũng có thể phản hồi về những bất cập của thuật, lập trình, may mặc. QC kiểm tra chất lượng của quy trình và đề xuất cải tiến quy trình. sản phẩm, đảm bảo chất lượng của sản phẩm trường  QA cũng hay gọi là PQA ( Process Quanlity Assurance – khi đưa ra thị trường sử dụng. Cán bộ quản lý chất lượng quy trình). 91 94 Quy trình đảm bảo chất lượng Quy trình Kiểm soát chất lượng 1. Đề xuất, đưa ra quy trình phát triển (development process) 1. Tìm hiểu hệ thống, phân tích tài liệu mô tả về sản phẩm phù hợp với yêu cầu cụ thể của từng dự án. Các quy trình này có thể được phát triển dựa trên V-model hay Agile hệ thống và thiết kế test case, thực hiện việc (đa số là Scrum hoặc Lean Development) hay thông qua việc test phần mềm trước khi giao cho khách hàng áp dụng những quy trình quản lý sẵn có như ISO hay CMMI. hay đưa ra thị trường. 2. Đưa ra những tài liệu, biểu mẫu, hướng dẫn để đảm bảo chất 2. Lên kế hoạch kiểm thử phần mềm lượng của sản phẩm cho tất cả các bộ phận trong nhóm phát triển sản phẩm. 3. Viết Script cho automation test 3. Kiểm tra, audit việc thực thi quy trình của các bộ phận trong 4. Sử dụng các test tool để tạo và thực hiện các nhóm làm sản phẩm có đúng quy trình QA đã đề ra không. test case/script chi tiết. 4. Nhắc nhở đội ngũ phát triển sản phẩm việc tuân thủ theo quy trình làm việc đã đưa ra. 5. Phối hợp với nhóm lập trình trong việc fix bug 5. Điều chỉnh, thay đổi quy trình phù hợp với từng sản phẩm mà và báo cáo chi tiết cho Project Manager hoặc các team đang thực hiện. các bên liên quan tuỳ từng dự án, sản phẩm. 92 95 1.2.3. Kiểm soát chất lượng phần mềm 1.2.3. Kiểm soát chất lượng phần mềm  QC = Quality Control QA: là người người đặt ra các quy định cho dự QC chính là Tester. Nhiều công ty gọi là QC chứ án như: đề xuất đưa ra quy trình phát triển dự không phải là tester. án, giám sát, quản lý và ban hành chất lượng. Quality Control: Điều khiển chất lượng Mục đích để đảm bảo rằng quy trình phát triển hoặc bảo trì chắc chắn sẽ đáp ứng được các mục  Tập hợp các hoạt động được tạo ra nhằm đánh giá chất lượng sản phẩm, bảo đảm sản phẩm tiêu hệ thống đã đề ra. đúng đặc tả yêu cầu QC: Là người thi thành các quy định, nguyên tắc để đảm bảo sản phẩm cuối cùng thực hiện đúng  Trực tiếp kiểm tra chất lượng của sản phẩm các quy định, nguyên tắc mà QA đặt ra. Cũng là  Có nhiệm vụ khảo sát, chạy thử và báo cáo lỗi người kiểm thử, tìm các trường hợp còn thiếu sót hay lỗi so với yêu cầu được đặt ra bởi khách 93 hàng. 96 16
21/07/2020 QA QC QA bao gồm các hoạt động đảm bảo và thực hiện quy trình, trình tự và tiêu chuẩn trong nội QC/Tester bao gồm các hoạt động để đảm bảo việc kiểm tra một phần mềm đã đáp ứng yêu cầu 1.3. Các nguyên tắc kiểm thử dung kiểm thử phần mềm đã phát triển và những yêu cầu đặt ra trong tài liệu yêu cầu (đảm bảo việc phát hiện lỗi/bug trong phần mềm) (4) Dữ liệu thử cho kết quả bình thường Tập trung vào quy trình và tuần tự hơn là quản Tập trung vào việc test thự tế trên phần mềm thì không có ý nghĩa nhiều, cần có những lý việc test thực tế trên hệ thống nhằm phát hiện lỗi trong quá trình phát triển hệ thống dữ liệu kiểm thử phát hiện ra lỗi phần Đảm bảo chất lượng là quy trình định hướng Kiểm soát chất lượng là định hướng sản phẩm mềm. Mục tiêu của đảm bảo chất lượng phần mềm là phòng tránh lỗi trong ứng dụng phần mềm giúp Mục tiêu của kiểm soát chất lượng phần mềm là xác định, phát hiện các lỗi trong khi phát triển (5) Khi thiết kế trường hợp thử, không chỉ cải thiện quá trình phát triển và kiểm thử ứng dụng phần mềm dữ liệu kiểm thử nhập vào, mà phải thiết kế Không liên quan đến việc thực thi chương Liên quan đến việc thực thi chương trình, code trước cả dữ liệu kết quả sẽ có. chình, code Xác định điểm yếu trong các quy trình phát triển Xác định các lỗi cần sửa (6) Khi phát sinh thêm trường hợp thử thì để cải thiện Đây là tập hợp con của vòng đời phát triển phần Testing là tập hợp con của Quality Control nên thử lại những trường hợp thử trước đó mềm (SDLC) (Quản lý chất lượng) để tránh ảnh hưởng lan truyền sóng khi Được thực hiện trước khi kiểm soát chất lượng Được thực hiện chỉ sau khi hoạt động Đảm bảo Chất lượng được hoàn thành 97 kiểm thử. 100 1.4. Vai trò kiểm thử phần mềm  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 đả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.  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.  Software testing cũng có thể xem như là quá trình thẩm định và thẩm tra (validating and verifying) phần mềm/chương trình/ứng dụng/sản phẩm để:  Đáp ứng được các yêu cầu công việc và kỹ thuật đã được quy định trong thiết kế và trong lúc phát triển  Làm việc như mong đợi 98 101 1.3. Các nguyên tắc kiểm thử BÀI TẬP CHƯƠNG 1 (1) Chất lượng phần mềm do khâu thiết 1. Khái niệm phần mềm, vòng đời phát triển phần mềm. 2. Trình bày các mô hình phát triển phần mềm. Theo anh kế quyết định là chủ yếu, chứ không chị mô hình phát triển nào hiện đang được triển khai phải khâu kiểm thử. phổ biến các công ty phát triển phần mềm. 3. Khái niệm kiểm thử phần mềm, đảm bảo chất lượng (2) Tính dễ kiểm thử phụ thuộc vào cấu phần mềm. 4. So sánh hoạt động kiểm thử phần mềm và kiểm soát trúc chương trình. chất lượng phần mềm. 5. Phân tích các nguyên tắc kiểm thử phần mềm. Theo (3) Người kiểm thử và người xây anh chị, những nguyên tắc nào đảm bảo chất lượng phần mềm. dựng phần mềm nên khác nhau. 6. Phân tích vai trò kiểm thử phần mềm trong quá trình phát triển phần mềm. 99 102 17
21/07/2020 CHƯƠNG 2. QUY TRÌNH KIỂM 2.1. Các giai đoạn kiểm thử phần mềm THỬ PHẦN MỀM 2.1. Các giai đoạn kiểm thử phần mềm Bắt đầu 2.2. Nội dung kiểm thử  Kế hoạch test  Lập kế hoạch Test 2.2.1. Kiểm thử đơn vị Mẫu test Các thủ tục Test Thiết kế Test 2.2.2. Kiểm thử tích hợp Cài đặt và chuẩn bị  Mã nguồn Test Dữ liệu test Test Môi trường 2.2.3. Kiểm thử hệ thống 2.2.4. Kiểm thử chấp nhận Lỗi  Test tích hợp Xem xét và Đánh giá  Báo cáo kết quả test, đề xuất giải 2.3. Các hình thức kiểm thử Biên bản test kết quả test Test hệ thống pháp 2.3.1. Kiểm thử chức năng Tổng hợp, báo cáo  2.3.2. Kiểm thử phi chức năng Hồ sơ báo cáo tổng hợp test 2.4. Công việc của người kiểm thử Kết thúc 103 106 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 Các giai đoạn kiểm thử phần mềm Bắt đầu Initiation (khởi động) Definition (Xác định yêu cầu) Definition Lập kế hoạch Test Xác định yêu cầu Solution Thiết kế kiến trúc Solution (Thiết kế kiến trúc) Thiết kế Test Cài đặt và chuẩn bị Construction (Xây dựng) Construction Lập trình Test Coding (lập trình) Construction Thử nghiệm Test tích hợp Xem xét và Đánh giá Testing (thử nghiệm) kết quả test Test hệ thống Tổng hợp, báo cáo Kết thúc Transition (Triển khai) Termination (Kết thúc) 104 107 2.1. Các giai đoạn kiểm thử phần mềm CÁC HOẠT ĐỘNG - Lập kế hoạch test 1. Xác định yêu cầu cho test Các yêu cầu test TN Test, Bắt đầu • Phương thức thực hiện CBT Lập kế hoạch Lập kế hoạch Test • Tiêu 2. Đánh giá rủi ro và lập mức ưu chuẩnCáchoàn rủi rothành việc test, liên quan đánh đến test TN Test tiên cho các yêu cầu giá chất lượng • Dựa trên sản phẩm cáccầu sảntest phẩm •• Số Các yêu đượcphân xác tích định Thiết kế Test Cácngười, •yếu tố Xácmức kỹ định:năng cần chú cái test ý gì? • Môi• trường độ ưu test: tiên phần Chuẩn bị Xác định: giới hạnmềm, cứng… công việc, thời Cài đặt và chuẩn bị 3. Xác lập chiến lược test • Công cụPhương gian, test lực nguồn thức thực hiện TN Test Test • Dữ liệu test Tiêu chuẩn đánh giá Test tích hợp Các yếu tố cần chú ý Test Xem xét và Đánh Các nguồn lực • Xác định nguồn lực TN Test 4. Xác định nguồn lực và môi Test hệ thống giá kết quả test • Lịch trình test Phân tích kết quả trường • Các mốc chính 5. Lập lịch trình test Lịch trình test TN Test Tổng hợp, báo cáo 6. Tổng hợp thông tin, lập KH test Kế hoạch test TN Test 7. Xem xét và thông qua KH test Kế hoạch test được phê duyệt QTDA Kết thúc 105 108 18
21/07/2020 CÁC HOẠT ĐỘNG - thiết kế test CÁC HOẠT ĐỘNG - test hệ thống •Dựa trên các sản phẩm của: • Phân tích • bước lập KH test 1. Nhận bàn giao với đội lập trình Các sản phẩm cần test được tiếp CBT 1. Lập danh sách các loại test, đảm Danh• sách loại các Xác định test test case TN Test, • Kiểm tra và cập nhật: nhận bảo cho việc xác lập tính đúng đắn & CBT • Mô tả test case: vào, ra, điều kiện Thiết• kế Test test,case 2. Chỉnh sửa thiết kế test test script, dữ liệu test TN Test thỏa mãn yêu cầu của sản phẩm được•cập nhật Test procedure 2. Xây dựng tình huống test (test Thiết kế test, các mẫu mã sử TN Test, 3. Cài đặt • Test Chương trìnhscript được cài đặt CBT case) dụng, yêu cầu về dữ liệu test CBT 4. Thực hiện test và ghi nhận lỗi Biên•bản Testtestdata CBT 3. Xây dựng và tổ chức thủ tục test Các thủ tục test TN Test, (test procedure) CBT Danh sách lỗi phát hiện • Dựa vào: các test case 4. Xem xét tình huống test và thủ tục • Xác định Biên bản xem xét các test procedure QTDA, Cán 5. Xử lý lỗi Biên bản test TN Test, CBT test, đánh giá tỷ lệ yêu cầu của khách • Xác lập mối quan hệ và thứ tự bộgiữa lập trình Danh sách lỗi phát hiện • Khi hệ thống thoả mãn các hàng (hoặc tình huống sử dụng) sẽ • Các test procedure với nhau 6. Xem xét các kết quả test và việc Kếtra quả test được xem xét TN Test,QTDA, • Các test procedure - Test cases tiêu chuẩn đặt được test dựa trên thiết kế test đã lập thực hiện khắc phục lỗi CBT, CBCL (nếu cần) 5. Thông qua thiết kế Test Thiết kế test được thông qua QTDA 7. Kết quả test được xem xét Xác nhân sản phẩm đủ tiêu chuẩn QTDA, CBCL, phát hành TN Test CÁC HOẠT ĐỘNG - xem xét và đánh giá kết quả CÁC HOẠT ĐỘNG - Cài đặt và chuẩn bị test test Test script 1. Phân tích lỗi và đưa ra đề xuất Báo cáo kết quả test TN Test 1.Lập các test script để thực hiện các • Các Test lệnh dùng để tự động hoá TN scipts các Test/ thủ tục test Đề xuất tình huống test/thủ tục test (nếu cần) CBT • Lập trình, sử dụng công cụ test tự động 2. Chuẩn bị dữ liệu test Dữ liệu test CBT 2. Đánh giá tỷ lệ test, đánh giá mức Báo cáo kết quả test TN Test độ đạt được các tiêu chí để hoàn 3. Chuẩn bị môi trường Môi trường sẵn sàng cho CBT thành test việc thực hiện test 3. Xem xét báo cáo kết quả test Báo cáo kết quả test được xem QTDA, 4. Kiểm tra các công cụ test Biên bản kiểm tra công cụ CBT xét CBCL test • Phân tích lỗi dựa: 5. Xem xét môi trường, điều kiện và dữ Môi trường và dữ liệu test TN Test/ • mức độ lặp lại liệu test được kiểm tra CBT • Dựa trên tỷ lệ YCnghiêm • độ được test/tổng trọng số YC cần test• Thời gian sửa lỗi… CÁC HOẠT ĐỘNG - test tích hợp CÁC HOẠT ĐỘNG - tổng hợp, báo cáo • Tài liệu • Gói phần mềm •… 1. Nhận bàn giao với đội lập trình Các sản phẩm cần test được tiếp CBT Dữ liệu, kết quả test CBT • Dựa trên thiết kế test nhận 1. Tập hợp các dữ liệu, kết • Ghi nhận lỗi vào DMS quả test 2. Cài đặt Hệ thống để test sẵn sàng CBT 3. Thực hiện test và ghi nhận lỗi Biên bản test CBT 2. Lập báo cáo tổng hợp test Báo cáo tổng hợp test TN Test 3. Tổ chức lưu trữ tài liệu, hồ Hồ sơ, files CBT 4. Xử lý lỗi Danh sách lỗi phát hiện TN Test, • Phối hợp với đội lập trình CBT sơ • Test lại -> Ghi nhận lỗi mới 5. Xem xét các kết quả test và việc Biên bản test TN Test, thực hiện khắc phục lỗi QTDA, CBT, CBCL (nếu cần) 19
21/07/2020 HOẠT ĐỘNG – xác định test CÁC HOẠT ĐỘNG case Vấn đề của thiết kế test Phân hoạch tương đương - Equivalence partitioning Xác định các test case Ví dụ: Phân hoạch tương đương Input Expected Output Đường đi trong mô đun Hàm tính trị tuyệt đối 100 100 - miền dữ liệu = 0 Mô tả các test case - miền dữ liệu < 0 -20 20 0 0 115 CÁC HOẠT ĐỘNG – mô tả test case HOẠT ĐỘNG – xác định test case  Tên mô đun/chức năng muốn kiểm thử Phân hoạch tương đương - Equivalence partitioning  Dữ liệu vào Mở rộng test case: - dữ liệu thông thường: số, xâu kí tự, file,... - môi trường thử nghiệm: phần cứng, OS,... Tạo test case cho các trường hợp đặc biệt - thứ tự thao tác (khi kiểm thử giao diện) - biên của số trong máy tính (vd. 32767, -32768)  Kết quả mong muốn - số không (0) - số âm, số thập phân - thông thường: số, xâu kí tự, file,... - dữ liệu sai kiểu - màn hình, thời gian phản hồi - dữ liệu ngẫu nhiên  Kết quả thực tế 116 119 HOẠT ĐỘNG – xác định test HOẠT ĐỘNG – xác định test case case Phân hoạch tương đương - Equivalence partitioning Đường đi trong mô đun  Không thể kiểm thử mọi trường hợp  Phân tích mô đun để xác định đường đi  Chia dữ liệu thành các miền có cùng hành vi  Đường đi là thứ tự thực hiện các lệnh từ điểm  Tạo một test case cho từng miền bắt đầu đến điểm kết thúc của mô đun  Tạo test case cho biên của các miền  Thiết kế các test case để kiểm thử mọi đường đi - nhiều lỗi xuất hiện với giá trị biên 117 20

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.