Tài liệu Các phương pháp đánh giá chất lượng phần mềm

i LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, số liệu và kết quả nghiên cứu trong luận văn này là trung thực và không trùng lặp với các đề tài khác. Tôi cũng xin cam đoan rằng mọi sự giúp đỡ cho việc thực hiện luận văn này đã được cảm ơn và các thông tin trích dẫn trong luận văn đã được chỉ rõ nguồn gốc. Học viên Nguyễn Thị Tính ii MỤC LỤC LỜI CAM ĐOAN .....................................................................................................i MỤC LỤC ..............................................................................................................ii MỤC LỤC HÌNH ẢNH ......................................................................................... iv DANH MỤC BẢNG BIỂU ..................................................................................... v ĐẶT VẤN ĐỀ........................................................................................................ vi I.TÍNH CẤP THIẾT CỦA ĐỀ TÀI ..................................................................... vi II.MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN .........................................................vii III.ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU ...............................................vii IV.PHƯƠNG PHÁP NGHIÊN CỨU .................................................................vii V.KẾT QUẢ DỰ KIẾN ĐẠT ĐƯỢC ................................................................vii VI.CẤU TRÚC LUẬN VĂN ............................................................................viii CHƯƠNG 1 QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM ................................. 1 1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM............................................. 1 1.1.1 Khái niệm về sản phẩm phần mềm ........................................................... 1 1.1.2 Khái niệm lỗi phần mềm .......................................................................... 3 1.1.3 Chi phí sửa lỗi .......................................................................................... 5 1.1.4 Khái niệm kiểm thử phần mềm................................................................. 6 1.1.5 Những khó khăn của kiểm thử phần mềm ................................................ 7 1.1.6 Kiểm thử trong quy trình phát triển phần mềm ......................................... 7 1.2 CHẤT LƯỢNG VÀ CÁC TIÊU CHÍ ĐÁNH GIÁ PHẦN MỀM ................. 11 1.2.1 Chất lượng phần mềm ............................................................................ 11 1.2.2 Các tiêu chí đánh giá .............................................................................. 12 1.3 QUY TRÌNH KIỂM THỬ PHẦN MỀM ...................................................... 13 1.4 TỰ ĐỘNG HÓA KIỂM THỬ ...................................................................... 14 CHƯƠNG 2 CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM ................................... 16 2.1.NGUYÊN TẮC CƠ BẢN CỦA KIỂM THỬ PHẦN MỀM.......................... 16 2.1.1.Các nguyên tắc kiểm thử phần mềm ....................................................... 16 2.1.2. Luồng thông tin kiểm thử ...................................................................... 19 iii 2.1.3. Thiết kế trường hợp kiểm thử ................................................................ 20 2.2.KIỂM THỬ HỘP ĐEN ................................................................................ 20 2.2.1. Phân hoạch tương đương ....................................................................... 21 2.2.2. Phân tích giá trị biên.............................................................................. 26 2.2.3. Kiểm thử giá trị đặc biệt ........................................................................ 28 2.2.4. Kỹ thuật đồ thị nhân quả ....................................................................... 29 2.3.KIỂM THỬ HỘP TRẮNG ........................................................................... 33 2.3.1. Kiểm thử dựa trên đồ thị luồng điều khiển............................................. 33 2.3.2.Kiểm thử dựa trên đồ thị luồng dữ liệu ................................................... 41 2.3.3.Kiểm thử điều kiện ................................................................................. 43 2.4.SO SÁNH KIỂM THỬ HỘP ĐEN VÀ KIỂM THỬ HỘP TRẮNG ............. 44 CHƯƠNG 3MỘT SỐ ỨNG DỤNG CỦA QUY TRÌNH KIỂM THỬ ................... 45 3.1. BÀI TOÁN NAME CORRECTING............................................................ 46 3.1.1 Giới thiệu bài toán .................................................................................. 46 3.1.2 Phạm vi giải quyết.................................................................................. 49 3.1.3 Thiết kế trường hợp kiểm thử ................................................................. 49 3.2. BÀI TOÁN SORT ...................................................................................... 52 3.2.1 Phát biểu bài toán ...................................................................................... 52 3.2.2 Phạm vi giải quyết.................................................................................. 52 3.2.3 Thiết kế trường hợp kiểm thử. ................................................................ 52 3.2.4 Kết quả kiểm thử .................................................................................... 60 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN.............................................................. 61 TÀI LIỆU THAM KHẢO ..................................................................................... 62 iv MỤC LỤC HÌNH ẢNH Hình 1. 1 - Sản phẩm phần mềm. Nguồn: [13] ......................................................... 3 Hình 1. 2 – Các nguyên nhân gây ra lỗi phần mềm [5] ............................................ 4 Hình 1. 3 - Chi phí cho việc sửa lỗi. Nguồn: [6], [8] ................................................ 6 Hình 1. 4 - Quy trình kiểm thử............................................................................... 13 Hình 1. 5 -Quy trình chi tiết quá trình kiểm thử ..................................................... 14 Hình 2. 1 - Mô hình luồng thông tin kiểm thử........................................................ 19 Hình 2. 2 - Ví dụ đồ thị nhân quả........................................................................... 32 Hình 2. 3 – Quy trình tạo ca kiểm thử dựa trên đồ thị luồng điều khiển ................. 34 Hình 2. 4 – Đồ thị luồng điều khiển biểu diễn chương trình sum ........................... 35 Hình 2. 5 - Ví dụ tiêu chí bao phủ cung ................................................................. 35 Hình 2. 6 - Đồ thị biểu diễn chương trình tính tổng nghịch đảo ............................. 37 Hình 2. 7 - Đồ thị luồng điều khiển biểu diễn hàm abc .......................................... 39 Hình 2. 8 - Đồ thị luồng điều khiển biểu diễn hàm foo .......................................... 42 Hình 3. 1 - Giao diện kiểm thử bài toán NC........................................................... 51 Hình 3. 2 - Minh họa thuật toán sắp xếp MergeSort ............................................... 53 Hình 3. 3 - Đồ thị lưu trình cho hàm Merge ........................................................... 54 Hình 3. 4 - Kết quả được ghi ra file log ................................................................. 60 Hình 3. 5 - Giao diện điều khiển kiểm thử các thuật toán sắp xếp .......................... 60 v DANH MỤC BẢNG BIỂU Bảng 1. 1 - Tỷ lệ công việc của các giai đoạn phát triển phần mềm ......................... 1 Bảng 2. 1 - Bảng liệt kê các lớp tương đương ........................................................ 22 Bảng 2. 3 – Các lớp tương đương cho chương trình tính hoa hồng ........................ 24 Bảng 2. 4 – Các ca kiểm thử lớp tương đương yếu ................................................ 24 cho chương trình tính hoa hồng ............................................................................. 24 Bảng 2. 5 – Kiểm thử lớp tương đương cho chương trình tính hoa hồng ................ 25 Bảng 2. 6 – Các lớp tương đương cho chương trình tam giác dựa vào dữ liệu vào ..... 25 Bảng 2. 7 – Các ca kiểm thử cho chương trình tam giác dựa trên dữ liệu vào ........ 26 Bảng 2. 8 – Các ký hiệu trong đồ thị nhân quả....................................................... 30 Bảng 2. 9 - Bảng quyết định tính thuế thu nhập ..................................................... 32 Bảng 3. 1 - Minh họa các testcase chương trình NC............................................... 50 Bảng 3. 2 - Bảng các trường hợp kiểm thử cho module Merge .............................. 56 Bảng 3. 3 - Các trường hợp kiểm thử cho module Split ......................................... 57 vi ĐẶT VẤN ĐỀ I. TÍNH CẤP THIẾT CỦA ĐỀ TÀI Với sự phát triển ngày càng mạnh mẽ của công nghiệp công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc xây dựng và phát triển phần mềm đã thực ngày càng tỏ ra hiệu quả hơn nhờ sự hỗ trợ của nhiều công cụ tiện ích và tiên tiến. Cùng với đà phát triển đó, hoạt động quản lí chất lượng phần mềm ngày càng gánh trách nhiệm thêm nặng nề và chuyên nghiệp. Tuy nhiên thực tế đã cho thấy rằng, các vấn đề về quản lý chất lượng phần mềm vẫn chưa thực sự đáp ứng được những đòi hỏi khắt khe của phần mềm về chất lượng cũng như tốc độ triển khai ứng dụng. Các hoạt động đánh giá chất lượng phần mềm vẫn không đảm bảo được các sản phẩm phần mềm là không có lỗi. Quản lý chất lượng phần mềm là một lĩnh vực của công nghệ phần mềm, có nhiệm vụ kiểm tra và xác minh các tiêu chí phần mềm: tính đúng, tính khoa học, tính tin cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và hoàn thiện. Đây là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm nhằm đảm bảo phần mềm đáp ứng các yêu cầu thiết kế và nhu cầu của người dùng. Các kỹ thuật đánh giá chất lượng phần mềm đã và đang được nghiên cứu cả về chiều rộng lẫn chiều sâu, và việc đánh giá này đã trở thành quy trình bắt buộc trong các dự án phát triển phần mềm [1]. Trong qui trình này, kiểm thử phần mềm là giai đoạn quan trọng nhằm đảm bảo chất lượng phần mềm, là quá trình chạy thử một ứng dụng để phát hiện lỗi và xem nó đã thỏa mãn yêu cầu đặt ra trong giai đoạn phát triển phần mềm [3]. Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng của khách hàng [4], [2]. Quy trình phát triển phần mềm bao gồm nhiều giai đoạn và nhiều hoạt động nhằm tạo ra sản phẩm phần mềm. Trong đó, kiểm thử là một trong những hoạt động đóng vai trò quan trọng nhằm phát hiện lỗi của phần mềm [5]. Đánh giá chất lượng phần mềm ngày càng khó khăn hơn, bởi vì các ngôn ngữ lập trình, các hệ điều hành và các phương pháp, công cụ phát triển phần mềm cũng như các thiết bị phần cứng vii ngày càng phong phú và đa dạng.Vì vậy, học viên chọn đề tài “Các phương pháp đánh giá chất lượng phần mềm” làm hướng nghiên cứu cho luận văn. II. MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN Mục đích chính của luận văn là:  Nghiên cứu, tìm hiểu về nguyên lý, phương pháp và các kỹ thuật quản lý và đánh giá chất lượng phần mềm.  Thiết kế các trường hợp kiểm thử và xây dựng vài kịch bản kiểm thử cụ thể. III. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU  Luận tập trung tìm hiểu, phân tích và khảo sát các đổi tượng sau đây:  Quy trình và bản chất của các kỹ thuật đánh giá chất lượng phần mềm.  Tìm hiểu và phát triển các kĩ thuật kiểm thửhộp đen và kiểm thử hộp trắng.  Thiết kế các trường hợp kiểm thử với bộ dữ liệu lớn. IV.PHƯƠNG PHÁP NGHIÊN CỨU Phương pháp nghiên cứu được sử dụng trong luận văn chủ yếu bao gồm:  Phương pháp luận: Nghiên cứu, tìm hiểu các khái niệm, chiến lược và kỹ thuật đánh giá chất lượng phần mềm.  Phương pháp thực nghiệm: thiết kế các trường hợp kiểm thử áp dụng cho kịch bản kiểm thử cụ thể. V. KẾT QUẢ DỰ KIẾN ĐẠT ĐƯỢC Luận văn tập trung chủ yếu vào các kĩ thuật kiểm thử phần mềm là khâu quan trọng trong quản lí chất lượng phần mềm.  Thiết kế các trường hợp kiểm thử cho một số kịch bản kiểm thử cụ thể.  Đặc tả trường hợp kiểm thử và kết quả kiểm thử.  Xây dựng kịch bản kiểm thử. Các kịch bản kiểm thử được chia làm hai loại chính: kiểm thử chức năng và kiểm thử phi chức năng.Hai bài toán 3.1 và 3.2 được đề xuất trong chương 3 nhằm minh họa cho các kĩ thuật được vận dụng trong hai loại kiểm thử nói trên. viii VI.CẤU TRÚC LUẬN VĂN Luận văn gồm Phần mở đầu, ba chương nội dung, Phần kết luận và Tài liệu tham khảo. Chương 1: Tổng quan về qui trình quản lí chất lượng phần mềm Tìm hiểu khái niệm chung về sản phẩm phần mềm, vấn đề chất lượng phần mềm, tầm quan trọng, khó khăn của việc kiểm thử phần mềm và các hoạt động đánh giá chất lượng trong quy trình phát triển phần mềm. Chương 2: Các kỹ thuật kiểm thử phần mềm. Nội dung của chương này phân tích các kỹ thuật cơ bản trong kiểm thử phần mềm:  Kiểm thử hộp đen: xây dựng lớp phân hoạch tương đương, phân tích giá trị biên, kỹ thuật đồ thị nhân quả, kiểm thử giá trị đặc biệt.  Kiểm thử hộp trắng: kiểm thử dựa trên đồ thị luồng điều khiển, kiểm thử dựa trên luồng dữ liệu, kiểm thử điều kiện. Trên cơ sở các nội dung nói trên, luận văn phân tích, làm nổi bật những yếu tố quan trọng trong đảm bảo chất lượng phần mềm. Chương 3: Một số ứng dụng cụ thể của quy trình kiểm thử. Để minh hoạ cho phần lý thuyết ở trên, chương 3 sẽ trình bày một vài kịch bản kiểm thử áp dụng kỹ thuật hộp đen và kỹ thuật hộp trắng để kiểm thử. Xây dựng các trường hợp kiểm thử (test cases) cho từng kịch bản kiểm thử. Xây dựng chương trình và giao diện: thực hiện với các trường hợp kiểm thử đã đề xuất, đối sánh kết quả của chương trình và kết quả dự kiến của các trường hợp kiểm thử. Kết luận và hướng phát triển Tài liệu tham khảo 1 CHƯƠNG 1 QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM 1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM 1.1.1 Khái niệm về sản phẩm phần mềm Phần mềm là một (bộ) chương trình đươc cài đặt trên máy tính thực hiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một hoặc nhiều ứng dụng cụ thể: quản lý hoạt động của máy tính hoặc áp dụng máy tính trong các hoạt động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí…[4], [5] Ví dụ: S1. Hệ điều hành Ubutu; S2. Môi trường lập trình C++ Devcpp; S3. Hệ thống quản lý: CN2; S4. Game: Lines… … Việc tạo ra một sản phẩm phải trải qua nhiều giai đoạn, người ta gọi là quy trình phát triển phần mềm. Quy trình này được khởi động từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm phần mềm thực thi. Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian. Bảng 1.1 minh họa cụ thể hơn về tỷ lệ công việc của các giai đoạn phát triển phần mềm [9] Bảng 1. 1 - Tỷ lệ công việc của các giai đoạn phát triển phần mềm Giai đoạn Phân Thiết tích yêu kế sơ cầu bộ Thiết kế chi tiết Lập trình Tích hợp và Kiểm và kiểm kiểm thử thử hệ thử đơn vị tích hợp thống Thập kỉ 19601970 10% Thập kỉ 1980 20% Thập kỉ 1990 40% 80% 60% 30% 10% 20% 30% 2 Theo một tài liệu khác [7], chi phí liên quan từng giai đoạn của vòng đời phần mềm được thể hiện trong biểu đồ hình quạt như đưới đây: Nguồn [7] Như vậy, một sản phẩm phần mềm được xem là một hệ thống bao gồm một hoặc nhiều phân hệ. Mỗi phân hệ lại được xây dựng từ những cấu phần. Mỗi cấu phần bao gồm các đơn vị nhỏ. Các thành phần của phần mềm được liên kết với nhau thông qua các mối quan hệ và các tương tác [8]. Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của quy trình phát triển một sản phẩm phần mềm. Việc kiểm thử cũng vì thế phải được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm. 3 Hình 1. 1 - Sản phẩm phần mềm. Nguồn: [13] 1.1.2 Khái niệm ệm lỗi phần mềm Chúng ta đã thấy y khi phần mềm hoạt động ng không như mong mu muốn thì ta nói rằng phần mềm đó có lỗi. i. Tuy nhiên, cũng có thể dùng nhiều thuậtt ngữ ng khác để mô tả hiện tượng này như: thất th bại, sai sót, có vấn đề, bất thường ng không hhợp lý, không tương thích,… Định nghĩa lỗii phần ph mềm dưới đây dựa trên khái niệm đặcc ttả: một đặc tảlà một sự thống nhất về đặặc tính, quan hệ, chức năng và hành vi củaa sản s phẩm giữa những người phát triển n ph phần mềm hoặc giữa người phát triển phần nm mềm và người đặt hàng hoặc sử dụng ng phần ph mềmthông qua một ngôn ngữ nào đó [5], [8], [10]. Lỗi phần mềm xuấất hiện khi xảy ra một hay nhiều điều kiện n sau [13] [13], [14], [15]:  Phần ần mềm không thực hiện đúng những g gì mà đặc ặc tả định nghĩa.  Phần ần mềm thực hiện những gì g mà đặc ặc tả khuyến cáo không nnên thực hiện.  Phần ần mềm thực hiện những gì g mà đặc tả không đề cập đến. 4  Phần mềm không thực hiện những gì mà đặc tả không đề cập đến nhưng lẽ ra nên thực hiện.  Phần mềm là khó hiểu hay khó sử dụng. Theo các kết quả nghiên cứu được thực hiện trong các dự án khác nhau, số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80% [12]. Các nguyên nhân sinh lỗi tại pha đặc tả:  Đặc tả không hình thức: Ngôn ngữ tự nhiên dễ hiểu nhưng rườm rà, nhập nhằng.  Đặc tả hình thức (ngôn ngữ toán học và logic): đơn giản, chính xác nhưng khó hiểu, khó cài đặt.  Quên đặc tả một yêu cầu nào đó.  Đặc tả không hết.  Yêu cầu đã thay đổi nhưng đặc tả không thay đổi.  Đặc tả khác nhau cho cùng một yêu cầu xuất hiện trong các cấu phần khác nhau của hệ thống. Hình 1. 2– Các nguyên nhân gây ra lỗi phần mềm [5] Nguồn gây ra lỗi lớn thứ hai là thiết kế. Đó là nền tảng mà lập trình viên dựa vào để nỗ lực thực hiện kế hoạch cho phần mềm. Thời kỳ đầu, phát triển phần mềm thường đồng nhất với lập trình, công việc lập trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu [4]. Ngày nay, công việc lập trình chỉ là một phần việc của quá trình lao động chất xám, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần mềm lớn hơn rất nhiều. Do đó, lỗi do lập trình gây ra cũng ít hơn. Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại 5 nhiều hơn. Đó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được” [11]. Một điều cũng khá hiển nhiên là nhiều lỗi xuất hiện trên văn bản chương trình, nhưng khi tìm hiểu kỹ thì thực ra lại do lỗi của đặc tả hoặc thiết kế [10]. Một nguyên nhân khác tạo ra lỗi là do bản thân của công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch, các mẫu thường được thiết kế theo xu hướng tổng quát hóa quá cao … 1.1.3 Chi phí sửa lỗi Người ta ước tính, bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt động có chi phí đắt thứ hai, ước tính khoảng 40% của chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm. Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu của người dùng [1], [6] Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm. Tuy nhiên, chi phí cho việc tìm và sửa lỗi sẽ tăng đáng kể theo thời gian trong quá trình phát triển [8]. Sự thay đổi một tài liệu hoặc yêu cầu (thí dụ, của khách hàng) khi đang trong pha thiết kế là không đắt nếu không nói là không đáng kể. Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay đổi được đưa ra sau khi đã lập trình. Thay đổi lúc này đồng nghĩa với việc phải viết lại chương trình [9]. Việc sửa lỗi sẽ không đáng kể nếu người lập trình tự phát hiện lỗi của mình, và không có sự liên quan đến chi phí khác. Họ không phải giải thích lỗi cho bất kỳ người nào trong nhóm. Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và lưu vết lỗi. Người kiểm thử và người quản lý không phải duyệt lại tình trạng lỗi. Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án. Nói chung, sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với việc khắc phục nó sau khi đã phát hành [14], [15]. 6 Theo các nghiên cứu của IBM, GTE cho biết, lỗi được phát hiện càng muộn thì chi phí cho việc sửa lỗi càng lớn. Chi phí tăng theo hàm mũ như sau: Hình 1.3 - Chi phí cho việc sửa lỗi. Nguồn: [6], [8] Chúng ta từng chứng kiến sự cố máy tính Y2K năm 2000. Nguyên nhân là do việc tiết kiệm bộ nhớ bằng cách biểu diễn năm có 4 chữ số bằng 2 chữ số cuối của năm mà không dự tính được lỗi tiềm ẩn có thể xảy ra mà mấy chục năm sau, thế giới đã phải lo sợ và tốn nhiều tỉ đô la để khắc phục do dữ liệu ngày tháng có thể bị thay đổi khi máy tính coi năm 1900 như năm 2000 [1], [5]. 1.1.4 Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thỏa mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiểm thử phần mềm đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành quy trình bắt buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm thử phần mềm là khâu mấu chốt để đảm bảo chất lượng phần mềm, là đánh giá cuối cùng về đặc tả thiết kế và mã hóa [7]. Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện ở thời điểm sớm nhất có thể và đảm bảo rằng lỗi đó đã được sửa. Những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc để phát hiện lỗi và đảm bảo chất 7 lượng sản phẩm. Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng của khách hàng. 1.1.5 Những khó khăn của kiểm thử phần mềm Để kiểm thử tốt hơn, cần phải quan tâm đến các yếu tố làm cho việc kiểm thử khó khăn hơn.  Khó khăn liên quan đến quy trình phát triển phần mềm Quá trình phát triển phần mềm là một tập hợp các hoạt động từ giai đoạn tìm hiểu, khảo sát, phân tích, thiết kế và cài đặt cho đến sử dụng và bảo trì. Mỗi giai đoạn này thực ra là một sự chuyển đổi một tập hợp thông tin này sang một tập hợp thông tin khác. Quá trình chuyển đổi này sẽ dẫn đến sự mất mát thông tin khó tránh khỏi, nghĩa là các lỗi sẽ xuất hiện. Hơn nữa, các giai đoạn chuyển đổi có thể tạo nên một thất bại ở giai đoạn cuối cùng mà khi phát hiện lập trình viên khó có thể biết được nguyên nhân do giai đoạn nào trước đó [10].  Khó khăn về nhân sự Thông thường, kiểm thử thường chỉ được coi là giai đoạn đơn giản cuối cùng được dùng để hợp thức hóa sản phẩm. Vì thế, nhiều lỗi nghiêm trọng mắc phải ngay từ các giai đoạn đầu của quy trình phát triển (đặc tả và thiết kế). Trong khi đó, nhiều thống kê cho thấy: các lỗi mắc phải càng sớm trong quy trình phát triển, thì các lỗi đó càng khó phát hiện và khó khắc phục. Vì vậy, việc nghiên cứu các phương pháp và công cụ phát triển thích ứng sẽ góp phần rất lớn vào việc giảm bớt các lỗi ngay từ các giai đoạn đầu của quy trình phát triển [9]. 1.1.6 Kiểm thử trong quy trình phát triển phần mềm Để kiểm thử một sản phẩm phần mềm, chúng ta không chỉ kiểm thử một lần, khi mà nó đã được hoàn thành. Các thành phần của phần mềm đều phải được kiểm thử trước, sau đó trong suốt quá trình tích hợp các thành phần cũng phải được kiểm thử cho đến khi đạt được sản phẩm cuối cùng. Có nhiều quy trình phát triển phần mềm được sử dụng. Chúng khác nhau về bản chất, cách tiến hành, số giai đoạn phát triển, tuy nhiên chúng có những điểm chung sau trong hoạt động kiểm thử. 8  Kiểm thử đơn vị: tập trung trên mỗi module riêng biệt, đảm bảo rằng các chức năng của nó tương ứng với một đơn vị.  Kiểm thử tích hợp: tập trung vào việc thiết kế và xây dựng kiến trúc phần mềm.  Kiểm thử hệ thống: hợp thức hóa yêu cầu của người sử dụng sau khi tất cả các module đã được tích hợp.  Kiểm thử hồi quy: đảm bảo các sửa đổi không ảnh hưởng đến các phần còn lại của phần mềm.  Kiểm thử chấp nhận: đánh giá phần mềm so với mong đợi và mục tiêu của người sử dụng.  Kiểm thử đơn vị Kiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết kế phần mềm. Sử dụng các mô tả thiết kế thủ tục để hướng dẫn, theo dõi các đuờng dẫn điều khiển quan trọng và kiểm thử để phát hiện lỗi trong phạm vi module. Độ phức tạp liên quan của các ca kiểm thử và lỗi đã phát hiện được giới hạn bởi ràng buộc phạm vi thiết lập cho kiểm thử đơn vị. Kiểm thử đơn vị thường hướng hộp trắng và các bước có thể được thực hiện song song trên nhiều module. Các kiểm thử nhằm phát hiện các lỗi trong các phạm vi của module bao gồm:  Giao diện module.  Cấu trúc dữ liệu cục bộ.  Điều kiện biên.  Đường dẫn độc lập.  Đường dẫn xử lý lỗi. Kiểm thử đơn vị thường được xem như một phần phụ cho bước mã hóa sau khi mã nguồn phát triển, được duyệt lại và được kiểm tra đúng cú pháp, thì bắt đầu thiết kế các trường hợp kiểm thử đơn vị. Kiểm thử đơn vị được đơn giản hóa khi module có sự liên kết cao được thiết kế. Khi chỉ một chức năng được gọi bởi một module, số các trường hợp kiểm thử được giảm xuống và các lỗi có thể dự đoán và phát hiện sớm hơn. 9 Kiểm thử đơn vị thường do lập trình viên thực hiện. Kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của kiểm thử đơn vị là đảm bảo thông tin được xử lý và xuất là chính xác, trong mối quan hệ với dữ liệu nhập và chức năng của đơn vị [3], [4].  Kiểm thử tích hợp Mục tiêu của kiểm thử tích hợp nhằm thực hiện các lỗi tương tác giữa các đơn vị, tích hợp các đơn vị thành các hệ thống con vận hành tốt và cuối cùng hệ thống hoàn toàn sẵn sàng cho kiểm thử hệ thống. Trong quá trình tích hợp, có thể có khả năng không chỉ tích hợp các đơn vị được phát triển trong dự án phần mềm, mà còn tích hợp các đơn vị hoặc thành phần được cung cấp bởi các thư viện hay thậm chí là các thành phần được cung cấp bởi hệ điều hành. Kiểm thử tích hợp nên chỉ thực hiện với các đơn vị đã được thẩm định và đã được kiểm thử đơn vị thành công. Sự tương tác và chức năng của đơn vị mới được tích hợp và tập các đơn vị đã được tích hợp trước đó sẽ được kiểm thử. Hai chiến lược kiểm thử tích hợp cơ bản thường được áp dụng gồm:  Tích hợp từ trên xuống : thực hiện kiểm thử các module chính trước, sau đó tích hợp thêm vào các module được gọi trực tiếp bởi các module vừa được kiểm thử.  Tích hợp từ dưới lên: tích hợp các thành phần cơ sở cung cấp các dịch vụ chung như mạng, truy cập cơ sở dữ liệu, sau đó các thành phần chức năng được thêm vào. Trong thực tế, với rất nhiều hệ thống, chiến lược tích hợp là sự pha trộn các phương pháp trên [11].  Kiểm thử hệ thống Kiểm thử hệ thống có thể bắt đầu ngay sau khi kiểm thử tích hợp kết thúc. Mục tiêu của kiểm thử hệ thống là cần chỉ ra rằng phần mềm thực hiện đúng những gì mà người sử dụng mong đợi. Vì thế, ở giai đoạn này, kiểm thử được thực hiện dưới góc nhìn của người sử dụng, nên chỉ sử dụng các kĩ thuật kiểm thử chức năng. 10 Kiểm thử hệ thống không chỉ nhằm đánh giá chức năng của hệ thống mà còn đánh giá các tính chất về chất lượng khác, như khả năng sử dụng, khả năng tin cậy, hiệu năng hay tính bảo mật…Tùy theo mỗi loại phần mềm và yêu cầu của phần mềm, các loại kiểm thử hệ thống khác nhau được áp dụng: kiểm thử giao diện, kiểm thử hiệu năng, kiểm thử độ tin cậy, kiểm thử cấu hình, kiểm thử bảo mật… Kiểm thử hệ thống nên được thực hiện trong môi trường như là môi trường mà phần mềm sẽ hoạt động, vì đây là giai đoạn kiểm thử trước khi chuyển giao phần mềm cho người sử dụng để thực hiện kiểm thử chấp nhận. Tuy nhiên điều này không phải lúc nào cũng thực hiện được, bởi vì chúng ta không thể có được môi trường sử dụng thực đối với một số phần mềm như phần mềm điều khiển hay phần mềm giao dịch tài chính…Trong trường hợp đó, thông thường chúng ta cần phải mô phỏng môi trường thực để thực hiện kiểm thử.  Kiểm thử hồi quy Quy trình phát triển phần mềm, mà trong đó bao gồm kiểm thử, không dừng lại một khi phần mềm đươc chuyển giao cho người sử dụng. Bởi vì phần mềm là một trong những loại sản phẩm thay đổi rất nhanh. Người sử dụng luôn có yêu cầu cải tiến phần mềm và bổ sung các chức năng mới hoặc sự không tương thích của phần mềm được tìm thấy khi đưa vào sử dụng. Như thế, sự chỉnh sửa phần mềm sau khi đưa vào sử dụng là cần thiết. Bất kì sự sửa đổi nào cũng có thể dẫn đến các lỗi mới. Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn này gọi là kiểm thử hồi quy. Sau khi phân tích sự ảnh hưởng, chúng ta có thể thực hiện lại một số kiểm thử như kiểm thử đơn vị các thành phần bị sửa đổi, kiểm thử tích hợp có kích hoạt các thành phần bị sửa đổi, kiểm thử hệ thống có kích hoạt các chức năng bị sửa đổi… Như vậy, kiểm thử hồi quy có thể áp dụng ở kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống. Để dễ dàng kiểm thử hồi quy chúng ta nên lưu trữ lại môi trường kiểm thử, các trình điều khiển và các bộ dữ liệu thử…để tái sử dụng. 11  Kiểm thử chấp nhận Kiểm thử chấp nhận không nhằm mục đích phát hiện lỗi mà nhằm giúp cho người sử dụng đánh giá phần mềm so với mong đợi và mục tiêu của họ. Khi phát triển phần mềm cho một khách hàng cụ thể, kiểm thử chấp nhận cần phải được thực hiện sau kiểm thử hệ thống. Phần mềm phải được thực thi trong môi trường thực. Kiểm thử chấp nhận là một mốc quan trọng đối với người phát triển. Tại thời điểm này, khách hàng sẽ quyết định phần mềm có đạt yêu cầu không. Nếu khách hàng hài lòng về phần mềm, họ sẽ chấp nhận sản phẩm và bước tiếp theo là cài đặt phần mềm tại môi trường của khách hàng. Nếu phần mềm được phát triển cho thị trường rộng lớn, thì kiểm thử cho mỗi khách hàng là không thực tế. Trong trường hợp này, kiểm thử chấp nhận thường được chia làm hai giai đoạn:  Kiểm thử alpha Kiểm thử alphađược thực hiện trong môi trường phát triển. Một nhóm những người sử dụng tiềm năng và thành viên nhóm phát triển được mời sử dụng phần mềm. Các lập trình viên sẽ quan sát và ghi nhận các vấn đề xảy ra.  Kiểm thử beta Kiểm thử beta gửi phần mềm đến những người sử dụng, họ cài đặt và sử dụng phần mềm trong môi trường làm việc thực tế. Người sử dụng sẽ gửi các vấn đề cho tổ chức phát triển và nhóm phát triển chịu trách nhiệm sửa các lỗi. 1.2 CHẤT LƯỢNG VÀ CÁC TIÊU CHÍ ĐÁNH GIÁ PHẦN MỀM 1.2.1 Chất lượng phần mềm Chất lượng trong phần mềm máy tính hiện vẫn còn là một vấn đề còn nhiều tranh luận. Trong một số trường hợp, nói tới chất lượng phần mềm là nói tới tính thực tiễn và tính thẩm mỹ của phần mềm. Ở đây, khái niệm này trả lời cho câu hỏi một chương trình máy tính thực thi một nhiệm vụ nào đó hiệu quả và có tính thẩm mỹ tới mức nào. Trong một ngữ cảnh khác, chất lượng phần mềm được hiểu là sự đáp ứng đến mức tối đa các yêu cầu đặt ra và không chứa lỗi. Trong cả hai trường 12 hợp trên, có một loạt các vấn đề đặt ra cần giải quyết để đi đến một kết quả cuối cùng là phần mềm có chất lượng. 1.2.2 Các tiêu chí đánh giá Một số tiêu chí xác định chất lượng của một sản phẩm phần mềm [5]:  Tính đúng: sản phẩm phần mềm đó thực thi đầy đủ và chính xác những yêu cầu đặc tả trong bản thiết kế.  Tính khoa học: giao diện được thiết kế hợp lý, gần với tư duy và kỳ vọng tự nhiên của người sử dụng; các chức năng được sắp đặt khoa học, thể hiện logic của hệ thống; có thể di chuyển vị trí, thay đổi kích thước, màu sắc của các giao diện, kiểu văn bản, hình vẽ, đồ thị, bảng biểu,…  Tính dễ sử dụng: Sau một vài lần thực thi phần mềm, người sử dụng có thể nhớ được một cách logic trình tự làm việc. Phần mềm có tính năng trợ giúp người sử dụng đúng lúc và đúng chỗ. Các thao tác nhanh chóng, rõ ràng, dễ theo dõi. Làm việc lâu với phần mềm không gây cảm giác khó chịu.  Tính tương tác: Phần mềm có thể tương tác với các hệ thống khác, ví dụ:  Có thể đọc các file định dạng khác.  Có thể chuyển, nhận và hiểu được các thông điệp, dữ liệu trao đổi qua lại với các hệ thống khác hiện đang tồn tại trên thị trường.  Tính độc lập: Phần mềm có thể làm việc bình thường trong các môi trường khác nhau, với các hệ điều hành và chủng loại máy khác nhau.  Tính vững vàng: Khi xảy ra các sự cố khách quan hoặc chủ quan phần mềm nhận biết và xử lý, không bị treo, bị liệt hoặc gây ra các hiệu quả nghiêm trọng.  Tính dễ phát triển và hoàn thiện: Khi công nghệ phát triển, nhiều phần mềm phải thiết kế lại từ đầu, kể cả việc phải chọn môi trường và công cụ phát triển mới. Một phần mềm được coi là dễ phát triển và hoàn thiện nếu nó thích ứng được với những thay đổi trong yêu cầu của khách hàng cũng như nền tảng kĩ thuật.