Đang tải... (xem toàn văn)
Bài giảng Đảm bảo chất lượng phần mềm: Phần 1 có nội dung trình bày về giới thiệu đảm bảo chất lượng phần mềm; các nguyên nhân gây ra lỗi phần mềm; các tiêu chí chất lượng ảnh hưởng tới hoạt động đảm bảo chất lượng phần mềm như nào; tích hợp các hoạt động đảm bảo chất lượng phần mềm vào vòng đời phát triển phần mềm; các hoạt động rà soát; kiểm thử phần mềm;... Mời các bạn cùng tham khảo!
ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Bài giảng cho sinh viên ngành Cơng nghệ thơng tin Đỗ Thị Bích Ngọc Hà Nội - 2020 MỞ ĐẦU Trước thách thức trình phát triển phần mềm, việc đảm bảo chất lượng phần mềm (Software Quality Assurance-SQA) quan trọng, đòi hỏi phải nghiên cứu cách nghiêm túc để thực thi hiệu Tài liệu cung cấp kiến thức chất lượng phần mềm, đảm bảo chất lượng dự án phát triển phần mềm Qui trình xây dựng hệ thống đảm bảo chất lượng phần mềm trình bày nội dung giảng Qua đó, sinh viên hiểu cách thức xây dựng hệ thống đảm bảo chất lượng phần mềm vai trò thành viên hệ thống Một số chuẩn đảm bảo chất lượng giới thiệu chương cuối Thông qua nội dung giảng sinh viên nắm kỹ rà soát kiểm thử phần mềm Nội dung giảng xây dựng bảy chương: Chương Giới thiệu đảm bảo chất lượng phần mềm Những khái niệm mở đầu tài liệu giới thiệu Chương Bắt đầu với khái niệm phần mềm, chất lượng phần mềm đảm bảo chất lượng phần mềm, phần phân tích tiêu chí chất lượng phần mềm Chương Tích hợp hoạt động đảm bảo chất lượng phần mềm vào vòng đời phát triển phần mềm Chương đề cập đến thành phần đảm bảo chất lượng phần mềm vòng đời dự án phần mềm Những nội dung trình bày chương bao gồm : phân tích số mơ hình phát triển phần mềm phổ biến Sau đó, chương đề cập đến mức độ kiểm thử phần mềm Chương Các hoạt động rà soát Chương trình bày hoạt động rà sốt cho loại tài liệu tạo trình phát triển phần mềm Chương trình bày nguyên tắc phương pháp thực rà soát số checklist rà soát mẫu Chương Kiểm thử phần mềm Chương đề cập đến khái niệm kiểm thử phần mềm Những nội dung trình bày chương bao gồm : khái niệm bản, mức kiểm thử, trình kiểm thử, ca kiểm thử Chương 5: Kỹ thuật kiểm thử hộp đen hộp trắng Chương trình bày kỹ thuật dùng thiết kế ca kiểm thử Các kỹ thuật kiểm thử hộp đen để kiểm thử chức năng, nghiệp vụ hệ thống Các kỹ thuật kiểm thử hộp trắng để kiểm thử code, kiểm thử đơn vị Chương Các công cụ hỗ trợ đảm bảo chất lượng phần mềm Chương đề cập đến loại công cụ dùng kiểm thử phần mềm Những nội dung trình bày chương bao gồm : phần mềm phục vụ quản lý kiểm thử, công cụ hỗ trợ kiểm thử, công cụ hỗ trợ kiểm thử tự động cho kiểm thử chức kiểm thử phi chức Chương Các chuẩn, chứng hoạt động đánh giá Chương đề cập tới chuẩn quản lý chất lượng ISO, CMM/CMMI, sâu vào CMM/CMMI Phụ lục Gồm phụ lục : - Trình bày lỗi thường gặp viết chương trình Trình bày số hướng dẫn cho loại kiểm thử - Một test plan mẫu CHƯƠNG 1: GIỚI THIỆU ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 1.1 Khái niệm phần mềm 1.2 Các nguyên nhân gây lỗi phần mềm 1.2.1 Một số ví dụ điển hình lỗi phần mềm 1.2.2 Lỗi phần mềm 13 1.2.3 Nguyên nhân gây lỗi phần mềm 14 1.3 Đảm bảo chất lượng phần mềm 17 1.3.1 Khái niệm 17 1.3.2 Mục tiêu đảm bảo chất lượng phần mềm 18 1.3.3 Xác minh, thẩm định đánh giá chất lượng 18 1.4 Các tiêu chí chất lượng 19 1.5 Các tiêu chí chất lượng ảnh hưởng tới hoạt động đảm bảo chất lượng phần mềm 23 CHƯƠNG 2: TÍCH HỢP CÁC HOẠT ĐỘNG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VÀO VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM 25 2.1 Các phương pháp phát triển phần mềm 25 2.2 Các hoạt động đảm bảo chất lượng phần mềm 29 2.2.1 Đảm bảo chất lượng hợp đồng 29 2.2.2 Đảm bảo chất lượng đặc tả 30 2.2.3 Đảm bảo chất lượng phân tích, thiết kế 32 2.2.4 Đảm bảo chất lượng phát triển phần mềm (lập trình) 33 2.3 Các mức độ kiểm thử 34 2.3.1 Giới thiệu 34 2.3.2 Kiểm thử đơn vị 34 2.3.3 Kiểm thử tích hợp 35 2.3.4 Kiểm thử hệ thống 40 2.3.5 Kiểm thử chấp nhận 43 CHƯƠNG 3: CÁC HOẠT ĐỘNG RÀ SOÁT 44 3.1 Mục tiêu rà soát 44 3.1.1 Định nghĩa 44 3.1.2 Mục tiêu 44 3.2 Các hình thức rà sốt 44 3.2.1 Rà sốt thức 44 3.2.2 Rà soát ngang hàng 47 3.2.3 Ý kiến chuyên gia 48 3.2.4 So sánh rà sốt thức rà sốt ngang hàng 49 3.3 Thực hoạt động rà soát dự án 50 3.3.1 Rà soát hợp đồng 50 3.3.2 Rà sốt phân tích thiết kế 53 3.3.3 Các hoạt động rà soát khác 56 3.4 Đảm bảo chất lượng thành phần bảo trì phần mềm 63 3.4.1 Giới thiệu 63 3.4.2 3.4.3 3.4.4 3.5 Cơ sở cho chất lượng bảo trì cao 64 Các thành phần chất lượng phần mềm tiền bảo trì 66 Hỗ trợ đảm bảo chất lượng bảo trì phần mềm 70 Đảm bảo chất lượng phần mềm yếu tố bên tham gia 78 3.5.1 Những thành phần bên ngồi đóng góp vào dự án phần mềm 78 3.5.2 Rủi ro lợi ích giới thiệu người tham dự 79 3.5.3 Những mục tiêu đảm bảo chất lượng đóng góp người tham gia bên ngồi 80 3.5.4 Các cơng cụ đảm bảo chất lượng đóng góp thành viên đóng góp bên ngồi 81 CHƯƠNG 4: KIỂM THỬ PHẦN MỀM 83 4.1 Định nghĩa mục tiêu 83 4.1.1 Định nghĩa 83 4.1.2 Các mức độ kiểm thử 84 4.2 Quy trình kiểm thử 85 4.2.1 Quy trình 85 4.2.2 Input/Output cho test 87 4.2.3 Quản lý lỗi 88 4.3 Kế hoạch kiểm thử 90 4.4 Thiết kế test (test design) 92 CHƯƠNG 5: KỸ THUẬT KIỂM THỬ HỘP ĐEN VÀ HỘP TRẮNG 95 5.1 Các kỹ thuật kiểm thử hộp đen 95 5.1.1 Phân lớp tương đương 95 5.1.2 Kiểm thử biên 99 5.1.3 Bảng định 100 5.1.4 Lược đồ chuyển trạng thái 101 5.1.5 Kiểm thử theo cặp 103 5.2 Các kỹ thuật kiểm thử hộp trắng 106 5.2.1 Kiểm thử luồng điều khiển 106 5.2.2 Kiểm thử luồng liệu 113 5.3 Kiểm thử đơn vị tự động 117 5.3.1 Giới thiệu chung 117 5.3.2 Tổng quan thư viện Junit 119 5.4 Bảng tóm tắt Testing Levels/ Techniques 122 CHƯƠNG 6: CÁC CÔNG CỤ HỖ TRỢ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 123 6.1 Các công cụ quản lý thông tin Đảm bảo chất lượng phần mềm 123 6.1.1 Phần mềm hỗ trợ viết tài liệu 123 6.1.2 Phần mềm quản lý lỗi 123 6.2 Cơng cụ kiểm thử tự động ? 125 6.2.1 Khái niệm 125 6.2.2 Quy trình kiểm thử tự động 125 6.3 Công cụ hỗ trợ kiểm thử đơn vị 126 6.4 Công cụ hỗ trợ kiểm thử chức tự động 126 6.4.1 Selenium WebDriver 129 6.4.2 Các câu lệnh sử dụng Selenium WebDriver 130 6.5 Công cụ hỗ trợ kiểm thử API 132 Giới thiệu công cụ kiểm thử API Postman 134 6.6 Công cụ hỗ trợ kiểm thử hiệu 135 6.7 Công cụ hỗ trợ kiểm thử bảo mật 135 CHƯƠNG 7: CÁC TIÊU CHUẨN TRONG QUẢN LÝ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 139 7.1 Giới thiệu 139 7.2 Đảm bảo chất lượng phần mềm chuẩn ISO 139 7.3 Đảm bảo chất lượng phần mềm chuẩn CMM, CMMI 140 7.4 Cấu trúc level CMMI : 144 7.4.1 Cấu trúc CMMI : 144 7.4.2 Các level CMMI: 144 7.4.3 Việt Nam áp dụng CMM/CMMI lĩnh vực phần mềm 152 TÀI LIỆU THAM KHẢO 153 PHỤ LỤC 154 Phụ lục 1: Một số lỗi thường gặp phát triển phần mềm 154 Phụ lục 2: Một số hướng dẫn cho loại kiểm thử 163 Phụ lục 3: Test plan mẫu 176 Chương 1: Giới thiệu đảm bảo chất lượng phần mềm 1.1 Khái niệm phần mềm Trước tìm hiểu đảm bảo chất lượng phần mềm, mục giới thiệu khái niệm phần mềm Định nghĩa: Phần mềm bao gồm thành phần sau đây: • Chương trình máy tính • Các thủ tục • Tài liệu liên quan • Dữ liệu cần thiết cho vận hành hệ thống Mỗi thành phần phần mềm có chức riêng chất lượng chúng đóng góp vào chất lượng chung phần mềm bảo trì phần mềm sau: • Chương trình máy tính cần thiết hiển nhiên chúng giúp máy tính vận hành thực thi yêu cầu ứng dụng • Những thủ tục yêu cầu để định nghĩa theo thứ tự lịch biểu chương trình thực thi, phương thức triển khai người chịu trách nghiệm cho thực thi hoạt động cần thiết cho việc tác động vào phần mềm • Nhiều kiểu tài liệu cần thiết cho người phát triển, người sử dụng người có nhiệm vụ trì Tài liệu phát triển (báo cáo yêu cầu, báo cáo thiết kế, mơ tả chương trình, v.v) cho phép phối hợp cộng tác hiệu thành viên đội ngũ phát triển hiệu việc xem lại rà soát cá sản phẩm lập trình thiết kế Tài liệu sử dụng(thường hướng dẫn sử dụng) cung cấp miêu tả cho ứng dụng sẵn sàng phương pháp thích hợp cho họ sử dụng Tài liệu bảo trì (tài liệu cho người phát triển) cung cấp cho đội bảo trì tất thơng tin u cầu mã nguồn công việc cấu trúc cho module Thơng tin sử dụng để tìm ngun nhân lỗi (bugs) thay đổi bổ sung thêm vào phần mềm có sẵn • Dữ liệu bao gồm tham số đầu vào, mã nguồn danh sách tên thích hợp với phần mềm để đặc tả cần thiết cho người sử dụng thao tác với hệ thống Một kiểu khác liệu cần thiết chuẩn liệu test, sử dụng để sách định rõ thứ thay đổi không mong muốn mã nguồn liệu phần mềm xảy loại cố phần mềm lường trước 1.2 Các nguyên nhân gây lỗi phần mềm 1.2.1 Một số ví dụ điển hình lỗi phần mềm Có nhiều trường hợp lỗi phần mềm gây thiệt hại hàng triệu đô la thiệt hai người Để thấy mức độ nghiệm trọng đa dạng lỗi phần mềm, mục giới thiệu 10 lỗi tiếng ngành phần mềm Ariane Crash Hình 1-0-1: Vụ nổ Ariane lỗi tràn số tính tốn Arian thứ năm loạt tàu vũ trụ dân dụng Ariane châu Âu dùng để phóng vệ tinh vào khơng gian Vào ngày tháng năm 1996 Kourou, Guiana Pháp, Ariane không người lái phát nổ khoảng 40 giây sau phóng Chiếc tên lửa trị giá 500 triệu đô la phát nổ lỗi phần mềm phổ biến biết đến tên gọi Integer Overflow Lỗi xảy trình thực chuyển đổi liệu từ số floating point 64-bit sang giá trị số integer16-bit Số floating point chuyển đổi có giá trị lớn số biểu diễn số integer16-bit Lỗi phần mềm tên lửa Patriot Hình 1-0-2: Hệ thống chắn tên lửa phán đốn sai vị trí lỗi làm tròn số Ngày 25 tháng năm 1991 Chiến tranh vùng Vịnh, hệ thống tên lửa Patriot dưng không theo dõi đánh chặn tên lửa Scud công doanh trại Mỹ Theo Cơ quan Trách nhiệm Giải trình Chính phủ Hoa Kỳ, phần mềm bị trễ khơng theo dõi việc phóng tên lửa thời gian thực, để tên lửa Iraq có hội vượt qua phát nổ trước làm điều để ngăn chặn Mỹ có 28 người thiệt mạng 100 người bị thương sau cố Lỗi Y2K Y2K viết tắt Year 2000 gọi “lỗi thiên niên kỷ” Vào cuối năm 90, lỗi Y2K lỗi đề cập nhiều giới chờ đợi máy bay va chạm, tàu vũ trụ biến mất, thị trường chứng khoán sụp đổ dự đốn nhiều chun gia cơng nghệ Lỗi sai lầm đơn giản hệ thống quản lý thời gian máy tính sử dụng hai chữ số để biểu thị năm Theo đó, 1970 biểu diễn 70 năm 1999 biểu diễn 99 Lý việc để tiết kiệm nhớ Khi gần đến năm 2000, lập trình viên máy tính nhận máy tính khơng thể biểu diễn xác năm 2000, 00 dùng để biểu diễn năm 1900 Các hoạt động lập trình hàng ngày hàng năm bị hư hỏng thiếu sót Vào ngày 31 tháng 12 năm 1999, chuyển sang ngày tháng năm 2000, máy tính hiểu từ ngày 31 tháng 12 năm 1999, chuyển sang ngày tháng năm 1900 Các ngân hàng, tính lãi suất hàng ngày, phải đối mặt với vấn đề thực Lãi suất số tiền mà người cho vay, ví dụ ngân hàng, tính phí khách hàng, chẳng hạn cá nhân doanh nghiệp họ vay tiền Thay tỷ lệ lãi suất cho ngày, máy tính tính tỷ lệ lãi suất cho gần 100 năm ! Các trung tâm công nghệ, nhà máy điện, bị đe dọa lỗi Y2K Nhà máy điện phụ thuộc máy tính để kiểm tra an tồn bảo trì, chẳng hạn áp lực nước mức độ xạ Khơng có ngày xác làm tính tốn đưa cư dân gần đối mặt với nguy hiểm Giao thơng vận tải phụ thuộc vào thời gian ngày tháng xác Các hãng hàng khơng đặc biệt bị đe doạ máy tính lưu thơng tin tất chuyến bay theo lịch trình bị đảo lộn hết Cuối cùng, có Y2K khơng gây hậu nghiêm trọng phải thời gian để nhà phát triển phần mềm khắc phục triệt để lỗi Khoản tiền gửi 92 nghìn triệu triệu la PayPal Vào ngày tháng năm 2013, Chris Reynolds cảm thấy giật hoảng hốt trước khoản tiền có tài khoản PayPal Số dư tài khoản nhân viên PR Pennsylvania tăng lên thành 92.233.720.368.547.800 USD Số tiền ghi có vào tài khoản PayPal Reynolds lỗi phần mềm làm anh trở thành người giàu giới PayPal thừa nhận việc lỗi phần mềm họ PayPal đề nghị tặng khoản tiền (không công bố) cho Reynolds YouTube phải nâng cấp đếm Gangnam Style Năm 2014, YouTube bị lỗi video âm nhạc gọi Gangnam Style Psy Các nhà phát triển xây dựng YouTube tảng 32-bit, có nghĩa YouTube lưu hiển thị số lượt xem video số nằm dải từ 2,147,483,648 đến 2,147,483,647 Tức số lượt xem lớn biểu diễn Youtube khoảng 2.15 tỷ Youtube nghĩ khó có video đạt lượt xem kinh khủng Tuy nhiên video video Gangnam Style phá vỡ đếm lượt xem YouTube vượt qua số 2.147.483.647 (có lẽ bố, mẹ, bà liên tục cho con, cho cháu xem để dụ chúng ăn cháo, ăn cơm nên số lượt xem khủng vậy) “Chúng không nghĩ có video xem với số lượng lớn số nguyên 32-bit” YouTube cho biết đăng Google + 10 (b) Coding tài liệu không chuẩn : vi phạm phong cách cấu trúc việc xây dựng thủ tục( theo giả thuyết ấn định bât hợp đồng nào) Phần mềm chất lượng thấp không chuẩn gây khó khăn giai đoạn kiểm thử sau giai đoạn bảo trì Việc yêu cầu thêm thời gian để kiểm tra chỉnh sửa chất lượng phần mềm chất lượng thấp gầy chậm trễ dự án đặc biệt trường hợp thành viên bên hoàn thành nhiệm vụ họ thời hạn - Khó khăn bảo trì tương lai Thực tế số tổ chức tham gia việc phát triển số họ, nhà thầu, người trực tiếp gây nên khó khăn việc bảo trì: • Nhà thầu đối mặt với việc coding tài liệu khơng hồn thành và/hoặc khơng tiêu chuẩn từ thành viên bên ngoài, gây chất lượng dịch vụ bảo trì nhóm bảo trì nhà thầu tốn chi phí cao • Các dịch vụ bảo trì cung cấp nhiều tổ chức, nhà thầu phụ, nhà cung cấp phần mềm có sẵn COTS phận phát triển khách hang.Khi mổi phần bị hạn chế khả đáp ứng, khách hàng buộc phải tìm kiếm người chịu trách nhiệm cho lỗi cụ thể phần mềm lỗi phát - Mất kiểm soát phận dự án Dù cố ý hay không cố ý,sự kiểm soát việc phát triển phần mềm thành viên bên ngồi tạo bưc tranh lạc quan khơng thực tế tình trạng dự án Sự trao đổi với nhóm thành viên bên ngồi làm gián đoạn tới vài tuần,gây cản trở việc đánh giá tiến độ dự án Kết là,cảnh báo khó khăn phát triển, thiếu đội ngũ nhân viên nhiều vấn đề khác đến muộn với nhà thầu Nhận thức trước khó khăn này, nhà thầu phải xem xét kết hợp lợi ích rủi ro đưa thành viên bên dự án 3.5.3 Những mục tiêu đảm bảo chất lượng đóng góp người tham gia bên ngồi Những mục tiêu thu việc áp dụng công cụ SQA cung cấp thành viên bên ngoài? Những mục tiêu thu trực tiếp từ việc liệt kê rủi ro đề cập trên: • Để tránh trì hỗn hồn thành nhiệm vụ để đảm bảo cảnh báo sớm để tính trước trì hỗn • Để đảm bảo mưc độ chất lượng chấp nhận phận triễn khai đón nhận cảnh báo sớm phạm vi chất lượng yêu cầu • Để đảm bảo đủ tài liệu phục vụ cho nhóm bảo trì 80 • Để đảm bảo liên tục, toàn diện đáng tin cậy kiểm soát việc thực người tham gia bên ngồi 3.5.4 Các cơng cụ đảm bảo chất lượng đóng góp thành viên đóng góp bên ngồi Chúng ta mong muốn thành viên đóng góp bên ngồi thực các phương thức SQA họ, bao gồm công cụ cần thiết để sản phẩm phần mềm dịch vụ họ đạt tới mức chất lượng chấp nhận Các công cụ đề cập tới thứ mà nhà thầu áp dụng cho thành viên đóng góp bên ngồi Trong mục đích này, vấn đề chất lượng thời gian quan trọng xác định Các công cụ áp dụng trước suốt trình kết hợp thành viên đóng góp bên ngồi dự án phát triển phần mềm liệt kê bên • xem xét lại tài liệu yêu cầu • Đánh giá tiêu chuẩn chọn lựa liên quan đến thành viên đóng góp bên ngồi • Thành lập ủy ban điều khiển gia nhập kết hợp dự án • Sự đóng góp xem xét thiết kế • Sự đóng góp kiểm tra phần mềm • Cách trình bày thủ tục đặc biệt • Xác định team leader nhà cung cấp thành viên • Chuẩn bị báo cáo tiến trình phát triển hoạt động phát triển dự án • Xem xét lại giao phẩm (các tài liệu) acceptance tests 81 82 Chương 4: Kiểm thử phần mềm 4.1 Định nghĩa mục tiêu 4.1.1 Định nghĩa Kiểm thử phần mềm có nhiều định nghĩa khác đề xuất nhiều tổ chức hay cá nhân khác Một số định nghĩa bật: Kiểm thử phần mềm trình khảo sát hệ thống hay thành phần điều kiện xác định, quan sát ghi lại kết quả, đánh giá khía cạnh hệ thống hay thành phần (Theo Bảng giải thuật ngữ chuẩn IEEE Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology) Kiểm thử phần mềm trình thực thi chương trình với mục đích tìm lỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm) Kiểm thử phần mềm hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm môi trường chúng dự định triển khai nhằm cung cấp cho người có lợi ích liên quan thơng tin chất lượng sản phẩm hay dịch vụ phần mềm Mục đích kiểm thử phần mềm tìm lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu hoạt động tối ưu phần mềm nhiều ngành khác (Theo Bách khoa toàn thư mở Wikipedia) Có thể định nghĩa cách dễ hiểu sau: Kiểm thử phần mềm trình thực thi hệ thống phần mềm để xác định xem phần mềm có với đặc tả khơng mơi trường hoạt động có u cầu khơng Mục tiêu kiểm thử: Các mục tiêu trực tiếp - Xác định phát nhiều lỗi phần mềm kiểm thử Sau sửa chữa lỗi xác định kiểm tra lại, làm cho phần mềm kiểm thử đến mức độ chấp nhận chất lượng Thực yêu cầu kiểm thử cần thiết cách hiệu có hiệu quả, phạm vi ngân sách thời gian cho phép Các mục tiêu gián tiếp Biên dịch ghi lỗi phần mềm để sử dụng cơng tác phịng chống lỗi (bằng hành động khắc phục ngăn ngừa) 83 4.1.2 Các mức độ kiểm thử Tuỳ thuộc vào mục tiêu kiểm thử, ta chia thành mức sau: Mức 0: testing debuging giống Mức 1: Mục tiêu kiểm thử để phần mềm hoạt động Mức 2: Mục tiêu kiểm thử để phần mềm không hoạt động Mức 3: Mục tiêu kiểm thử để giảm rủi ro sử dụng phần mềm Mức 4: Nhằm trợ giúp chuyên gia CNTT phát triển phần mềm có chất lượng cao a Mức Testing debuging Mức thường thực sinh viên mơn học lập trình Sinh viên viết chương trình, chạy với vài đầu vào, debug lỗi có Mức khơng phân biệt hành vi không lỗi bên chương trình Mức giúp ích đơi chút việc phát triển phần mềm xác b Mức Nhằm để chứng minh tính đắn Một cách phát triển tự nhiên từ mức 0, nhiên ta chứng minh tính đắn phần mềm Giả sử ta chạy tập test không phát lỗi Vậy, kết luận gì? Liệu ta giả thiết phần mềm chạy tốt hay tập test kém? Vì khơng thể chứng minh tính đắn, việc kiểm thử khơng có giới hạn dừng cố định, khơng có kỹ thuật test hình thức (formal) Nếu người quản lý hỏi: phải thực thi test nữa? Ta khơng có cách trả lời xác câu hỏi c Mức Nhằm để lỗi Tìm lỗi mục tiêu rõ ràng, mang tính tiêu cực Tester vui vẻ tìm lỗi, developers không muốn - họ muốn phần mềm chạy (mức suy nghĩ tự nhiên developers) Do đó, mức đặt tester developers vào quan hệ đối đầu Điều ảnh hưởng xấu tới nhóm Ngồi ra, câu hỏi đặt khơng tìm thấy lỗi sao? Ta kết luận phần mềm chạy tốt? việc kiểm thử yếu? d Mức Kiểm thử lỗi xuất hiện, khơng thể chứng tỏ phần mềm khơng có lỗi Nghĩa là, ta phải chấp nhận sử dụng phần mềm, ta có nguy gặp lỗi Nguy nhỏ, khơng gây hậu gì, nguy lớn gây 84 thảm hoạ Điều rằng, tồn đội phát triển phần mềm có chung mục tiêu - giảm nguy gặp lỗi sử dụng phần mềm Ở mức 3, tester developer làm việc để giảm nguy gặp lỗi e Mức Khi tester developers có chung mục tiêu (mức 3), tổ chức chuyển sang mức Kiểm thử nhằm mục tiêu tăng chất lượng Có nhiều cách để tăng chất lượng, tạo test dẫn tới lỗi Ở mức này, kỹ sư kiểm thử trở thành trưởng nhóm kỹ thuật dự án Họ có nhiệm vụ đánh giá, cải thiện chất lượng phần mềm, thẩm định họ trợ giúp cho developers Ví dụ ta có chương trình spell checker Ta thường nghĩ nhiệm vụ để tìm từ sai tả (đánh vần sai), thực tế, mục tiêu cao để tăng khả viết tả Mỗi spell checker tìm từ sai tả, ta có hội để học cách viết Do vậy, spell checker “chuyên gia” chất lượng viết tả Một cách tương tự, mức hướng tới mục tiêu kiểm thử để tăng khả developers việc phát triển phần mềm chất lượng cao Testers đào tạo developers 4.2 Quy trình kiểm thử 4.2.1 Quy trình Tùy vào tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro phần mềm mà quy trình kiểm thử phần mềm gồm nhiều bước khác Nhưng nhìn chung quy trình kiểm thử có bước đây: 85 Hình 4-1: Quy trình kiểm thử theo ISO/IEC 29119 86 Hình 4-2: Quy trình kiểm thử chung Theo quy trình kiểm thử phần mềm gồm giai đoạn: • Lập kế hoạch kiểm thử: Nhiệm vụ quan trọng phần lập kế hoạch kiểm thử xác định thành phần sau: • Chuẩn bị kiểm thử: Nhiệm vụ giai đoạn là: o Tìm hiểu nghiệp vụ hệ thống phải kiểm thử o Xây dựng kịch kiểm thử o Chuẩn bị liệu kiểm thử o Xem xét phê duyệt tài liệu kiểm thử • Thực thi kiểm thử: o Thực kiểm thử dựa kịch kiểm thử, test case, thủ tục, liệu có sẵn từ bước chuẩn bị kiểm thử o Thực q trình quản lí lỗi: báo lỗi, sửa lỗi • Báo cáo phân tích liệu kiểm thử: o Lập báo cáo kiểm thử o Phân tích nguyên nhân đề xuất hành động khắc phục 4.2.2 Input/Output cho test Input: o Yêu cầu khách hàng tiêu chí chấp nhận 87 o o o o Yêu cầu thay đổi Đặc tả yêu cầu phần mềm (Software Requirement Specification SRS) Tài liệu thiết kế Chương trình (Modules) Output: o Tài liệu test: kế hoạch test, test cases procedures, Test script, liệu Test o Danh sách lỗi o Mô tả thực test o Báo cáo phân tích lỗi 4.2.3 Quản lý lỗi Thơng thường, lỗi phát quản lý hệ thống quản lý lỗi (ví dụ RedMine, Jira,…) Một số lưu ý thực ghi nhận lỗi: o Lưu ý dự án có nhiều pha phát triển khác nhau, có nhiều chức hệ thống khác => lúc log lỗi phải nói rõ lỗi gì, thuộc chức nào? o Mục đích viết lỗi Developer/Leader đọc hiểu Một ngày dev nhận nhiều bugs, phải thực nhiều việc => cần viết ngắn gọn, rõ ràng, dễ dàng theo dõi từ subjects o Phải dùng từ ngữ thống tránh gây hiểu lầm dễ tìm kiếm cần Subject: cần rõ chức có lỗi, nội dung cụ thể lỗi, Description: Mô tả rõ lỗi đường tới lỗi Ví dụ 1: lỗi đơn giản 88 Ví dụ 2: lỗi điển hình có liên quan tới liệu o Cần nhập rõ trình tự thực liệu dẫn tới kết sai o Viết rõ kết thực chương trình o Viết rõ kết mong muốn theo đặc tả Ví dụ 3: cách log lỗi chưa tốt Subject: không rõ điểm gây lỗi, mô tả lỗi chung chung Description: không mô tả rõ ràng vị trí gây lỗi Hậu quả: o developer không xác định lỗi đâu (nhất họ phải làm nhiều việc lúc) o mơ tả lỗi có subject giống giống (trong có hàng trăm, hàng nghìn lỗi hệ thống) nên dễ bị hiểu lầm log trùng Vòng đời lỗi Sau tester tạo lỗi, thành viên đội dự án thực chỉnh sửa/từ chối đổi trạng thái lỗi Một vịng trạng thái lỗi điển hình cho hình dưới, lập trình viên gán lỗi chấp nhận sửa lỗi từ chối thấy khơng phải lỗi; kiểm thử viên kiểm tra lại lỗi sau sửa chấp nhận để đóng lỗi yêu cầu sửa lại việc sửa lỗi lập trình viên khơng đáp ứng u cầu 89 o Hình 4-3: Vịng đời quản lý lỗi 4.3 Kế hoạch kiểm thử Một số câu hỏi cần trả lời q trình lập kế hoạch: • Test ? • Ai thực test? • Thực test chỗ ? • Khi kết thúc test? -Test gì? Quá trình kiểm thử giới thiệu đầy đủ kế hoạch kiểm thử, từ test đơn vị (unit test) đến test tích hợp (integration test) test hệ thống (system test) Các yếu tố định liên quan đến: Các module unit test Cách tích hợp cần test Xác định rõ mức độ ưu tiên để phân bố tài nguyên test tới ứng dụng hệ thống phần mềm riêng rẽ + Đánh giá unit, integration application Các phương thức đánh giá cho unit(module), integration ứng dụng để xác định rõ mức độ ưu tiên chúng kế hoạch testing dựa yếu tố : 90 Yếu tố A: Mức thiệt hại ngiêm trọng Độ nghiêm trọng trường hợp module ứng dụng thất bại Yếu tố B: Mức rủi ro phần mềm Mức độ rủi ro xác suất xuất thất bại Để xác định mức rủi ro module, unit, integration ứng dụng, vấn đề ảnh hưởng rủi ro cần thẩm tra kĩ Các vấn đề phân loại vấn đề module/application vấn đề người lập trình Các vấn đề ảnh hưởng tới mức rủi ro phần mềm Các vấn đề module/application • Độ lớn • Độ phức tạp độ khó • Tỉ lệ phần mềm gốc( với tỉ lệ phần mềm dùng lại) Vấn đề người lập trình • Tính chun nghiệp • Kinh nghiệm với vấn đề module cụ thể • Tính khả dụng hỗ trợ chun nghiệp ( việc lưu kiến thức kinh nghiệp) • Sự hiểu biết người lập trình lực khả đánh giá - Test thực ? Những người thực thi kiểm thử xác định giai đoạn lập kế hoạch • Integration tests, đặc biệt unit tests, thường thực nhóm phát triển phần mềm • Sytem test thường xuyên thực nhóm test độc lập (trong nội nhóm test cố vấn bên ngồi nhóm test) • Trong trường hợp hệ thống phần mềm lớn, nhiều nhóm testing dùng để thực test hệ thống • Testing nhóm phát triển khác Mỗi nhóm phát triển coi nhóm testing dự án phát triển cho nhóm khác - Test thực đâu ? Test đơn vị test tích hợp thực phía người phát triển phần mềm Khi test hệ thống: chúng nên thực phía người phát triển hay phía khác hàng? Nếu test hệ thống để thực tư vấn test bên ngoài, lựa chọn thứ phát sinh: phía người tư vấn Lựa chọn phụ thuộc vào môi trường test hay môi trường hệ thống 91 Tuy nhiên, mơi trường máy tính phía khác hàng khác khác với phía nhà phát triển Trong trường hợp này, để giảm lo ngại khách hàng, hệ thống cài đặt kiểm thử phía khách hàng khơng cần test chấp nhận -Khi dừng test? Quyết định trình kiểm thử kết thúc có ý nghĩa quan trọng với test hệ thống Có nhiều hướng lựa chọn để dừng test, lựa chọn dựa tiêu chí khác nhau, ví dụ như: - Hướng hồn tất thực thi Theo hướng này, testing hoàn thành toàn kế hoạch test thực xong lỗi, kết đạt cho tất yêu cầu test Đây hướng lý tưởng, mà ta không bị giới hạn ngân sách thời gian - Hướng áp dụng mơ hình tốn học Ở hướng này, mơ hình tốn học áp dụng để ước lượng tỉ lệ lỗi không bị phát tỉ lệ lỗi phát Testing hoàn thành tỉ lệ phát lỗi giảm mức chấp nhận theo chuẩn Những bất lợi hướng mơ hình tính tốn lựa chọn khơng đại diện hồn toàn cho đặc trưng dự án - Hướng đội test độc lập Hai đội test thực test cách độc lập Bằng cách so sánh danh sách lỗi phát đội đưa định dừng trình test - Dừng hết tài nguyên Với kiểu việc dừng test xảy ngân sách thời gian phân bố cho testing hết 4.4 Thiết kế test (test design) Các sản phẩm giai đoạn thiết kế test : • Thiết kế chi tiết Thủ tục cho việc test • Các tệp sở liệu test case Quá trình thiết kế test tiến hành sở kế hoạch test phần mềm, lập tài liệu STP (software test procedure) Các thủ tục test sở liệu hay tệp test case có lập tài liệu tài liệu “thủ tục test phần mềm” “ test case file” tài liệu đơn gọi “mô tả test phần mềm” (STD) Một mẫu (template) STD trình bày sau: Mẫu mơ tả test phần mềm (STD) • Phạm vi test 92 1.1 Các gói phần mềm test ( name, version, revision) 1.2 Các tài liệu cung cấp cho việc thiết kế test (tên phiên tài liệu) • Mơi trường test ( test) 2.1 Định danh test ( chi tiết test viết tài liệu STP) 2.2 Mô tả chi tiết hoạt động hệ thống cấu hình phần cứng yêu cầu chuyển đổi thiết lập test 2.3 Hướng dẫn tải phần mềm • Tiến trình test 3.1 Hướng dẫn cho đầu vào, mô tả chi tiết bước tiến trình đầu vào 3.2 Dữ liệu ghi chép suốt q trình test • Test cases (với case) 4.1 Chi tiết định danh test case 4.2 Dữ liệu Đầu vào thiết lập hệ thống 4.3 Kết trung gian mong đợi (nếu có) 4.4 Các kết mong đợi ( Số, thơng điệp, kích hoạt thiết bị, ) Hành động trường hợp chương trình lỗi / kết thúc Thủ tục áp dụng theo tóm tắt kết test Ví dụ test cases: Mã module Yêu cầu kiểm thử Người kiểm thử Pass Fail 19 Mã Mô tả QLTTKH Kiểm thử chức hình quản lý thơng tin khách hàng Untested Quy trình ca kiểm thử Giao diện người dùng Kiểm thử giao Chạy ứng dụng diện hình Nhấp chuột vào mục "Quản Lý quản lý danh Khách Hàng" Kiểm thử di chuyển nút chức Kiểm thử di chuyển nút chức Kiểm thử di chuyển nút chức Dữ liệu kiểm thử Kết mong muốn Kết thực tế Kết luận Người kiểm thử Ngày kiểm thử ''- Hiển thị hình "QUẢN LÝ Fail THÔNG TIN KHÁCH HÀNG" với thành phần sau: + Bảng danh mục thông tin gồm trường thông tin: tích chọn, Số lưu ký,Họ tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email,Trạng thái + nút chức năng: Thêm, Sửa, Tra cứu,Phong tỏa/Giải tỏa - Thứ tự tab: datagridview danh mục - Thứ tự tab: nút "Thêm" → "Sửa" thông tin khách hàng→ nút "Thêm" → →Tra cứu → Phong tỏa/Giải tỏa → "Sửa" →Tra cứu → Phong tỏa/Giải datagridview danh mục thông tin khách tỏa.Sai Hãy sửa lại cho hàng Hiển thị hình "Thêm tài Hiển thị hình "Thêm tài Pass khoản" khoản" xuandt 17/04/2016 xuandt 17/04/2016 Tại hình "Thêm tài khoản", nhấp chuột vào nút "Hủy" - Đóng hình "Thêm tài khoản" '- Đóng hình "Thêm tài - Trở hình "Quản lý thông tin khoản" khách hàng" - Trở hình "Quản lý thơng tin khách hàng" Pass xuandt 17/04/2016 Tại hình "Quản lý thơng tin khách hàng", tích chọn dịng danh mục quản lý thơng tin khách hàng 2.Nhấp chuột vào nút "Sửa" Các trường thơng tin:Họ tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email sửa Pass xuandt 17/04/2016 mục cho vay Số ca kiểm thử 26 Tại hình "Quản lý thông tin khách hàng", nhấp chuột vào nút "Thêm" '- Hiển thị hình "QUẢN LÝ THƠNG TIN KHÁCH HÀNG" với thành phần sau: + Bảng danh mục thơng tin gồm trường thơng tin: tích chọn, Số lưu ký,Họ tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email,Trạng thái + nút chức năng: Thêm, Sửa, Tra cứu,Phong tỏa/Giải tỏa Các trường thông tin:Họ tên,Giới tính,Ngày sinh,Số CMND,Địa chỉ,Số điện thoại,Email sửa Chú thích 93 94 ... 13 1. 2.3 Nguyên nhân gây lỗi phần mềm 14 1. 3 Đảm bảo chất lượng phần mềm 17 1. 3 .1 Khái niệm 17 1. 3.2 Mục tiêu đảm bảo chất lượng phần mềm ... QUẢN LÝ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 13 9 7 .1 Giới thiệu 13 9 7.2 Đảm bảo chất lượng phần mềm chuẩn ISO 13 9 7.3 Đảm bảo chất lượng phần mềm chuẩn CMM, CMMI 14 0 7.4... 12 2 CHƯƠNG 6: CÁC CÔNG CỤ HỖ TRỢ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 12 3 6 .1 Các công cụ quản lý thông tin Đảm bảo chất lượng phần mềm 12 3 6 .1. 1 Phần mềm hỗ trợ viết tài liệu 12 3