Tài liệu Nghiên cứu kiểm thử bao phủ phần mềm và ứng dụng

Đại học quốc gia hà nội Trường đại học công nghệ --------------------------- Ngô Thuỳ Linh Nghiên cứu kiểm thử bao phủ phần Mềm và ứng dụng Luận văn thạc sĩ Hà Nội – 2010 Đại học Quốc gia Hà nội Trường đại học công nghệ --------------------------- Ngô Thuỳ Linh Nghiên cứu kiểm thử bao phủ phần Mềm và ứng dụng Luận văn thạc sĩ Ngành: CÔNG NGHỆ THÔNG TIN Chuyên ngành: CÔNG NGHỆ PHẦN MỀM Mã số: 60 48 10 Người hướng dẫn khoa học PGS.TS. NGUYỄN VĂN VỴ Hà Nội – 2010 LỜI CẢM ƠN Trước tiên tôi xin được bày tỏ sự trân trọng và lòng biết ơn đối với PGS.TS. Nguyễn Văn Vỵ, giảng viên Bộ môn Công nghệ phần mềm – Khoa Công nghệ thông tin – Trường Đại học Công nghệ - ĐHQGHN. Trong thời gian học và làm luận văn tốt nghiệp, thầy đã dành nhiều thời gian quí báu và tận tình chỉ bảo, hướng dẫn tôi trong việc nghiên cứu, thực hiện luận văn. Tôi xin được cảm ơn các GS, TS đã giảng dạy tôi trong quá trình học tập và làm luận văn. Các thầy đã giúp tôi hiểu thấu đáo hơn lĩnh vực mà mình nghiên cứu để có thể vận dụng các kiến thức đó vào trong công tác của mình. Xin cảm ơn các bạn bè, đồng nghiệp và nhất là các thành viên trong gia đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ tôi trong suốt quá trình học tập và nghiên cứu để hoàn thành tốt bản luận văn tốt nghiệp này. Tác giả Ngô Thùy Linh LỜI CAM ĐOAN Tôi xin cam đoan rằng, đây là công trình nghiên cứu của tôi trong đó có sự giúp đỡ rất lớn của thầy hướng dẫn và các đồng nghiệp ở cơ quan. Các nội dung nghiên cứu và kết quả trong đề tài này là hoàn toàn trung thực. Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt kê tại phần Tài liệu tham khảo ở cuối luận văn. Hà Nội, tháng 10 năm 2010 Tác giả Ngô Thùy Linh BẢNG CÁC CHỮ VIẾT TẮT VÀ THUẬT NGỮ Viết tắt Tên đầy đủ ATM BBD CNTT CRC FSM MBT Automated Teller Machine Branch Block Diagram Công nghệ thông tin class- responsilility- collaboration Finite state machine Model Base Testing OOA Object Oriented Analysis OOD OOIT ORD SQA STD SUT Object Oriente Design Object Oriented Integration Testing Object Relation Diagram Software Quality Assurance State transition diagram System Under Test BẢNG DANH SÁCH CÁC HÌNH VẼ Số Tên hình Hình 1.1 Hình 1.2 Hình 1.3 Hình 1.4 Hình 2.1 Mô hình chữ V của quá trình kiểm thử Các chiến lươc tích hợp dần Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần Mô hình mô tả kiểm thử hộp đen Lớp ấn phẩm và các lớp dẫn xuất của nó Sơ đồ tương tác của phần mềm hướng đối tượng và truyền thống Cụm các lớp đối tượng cần để thực hiện công việc chung Công thức tính phần trăm bao phủ dòng lệnh Mô hình Đồ thị luồng điều khiển Công thức tính phần trăm nhánh được bao phủ Lược đồ chuyển trạng thái cho “ngăn xếp bị chặn” Máy trạng thái hữu hạn biểu diễn bộ khóa an toàn tổ hợp Bảng chuyển trạng thái đối với một máy trạng thái hữu hạn Sơ đồ trạng thái cho nút của thang máy Sơ đồ trạng thái cho nút của tầng Hình 2.2 Hình 2.3 Hình 3.1 Hình 3.2 Hình 3.3 Hình 3.4 Hình 4.1 Hình 4.2 Hình 4.3 Hình.4.4 Hình 4.5 Sơ đồ chuyển trạng thái của thang máy Hình 4.6 Hình 4.7 Hình 4.8 Hình 4.9 Một đường đi bao phủ tất cả các trạng thái Sơ đồ chuyển trạng thái của cầu thang 4 tầng Sơ đồ tiến trình cho kiểm thử phủ trạng thái Sơ đồ tìm chu trình Ơle cho kiểm thử phủ chuyển trạng thái Trang 6 8 9 14 24 27 31 34 34 35 40 43 44 47 49 50 53 55 56 57 11 MỞ ĐẦU 1. Lý do chọn đề tài Với sự phát triển như vũ bão của Công nghệ thông tin (CNTT) nói chung và Công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ phát triển tiên tiến, làm cho việc xây dựng phần mềm đỡ mệt nhọc, nhanh hơn và hiệu quả hơn. Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian, các nguồn lực, nên các hoạt động đảm bảo chất lượng phần mềm và kiểm thử phần mềm ngày càng chặt chẽ, song vẫn không đảm bảo rằng các sản phẩm phần mềm được tạo ra không còn lỗi. Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm và có thể gây ra những thiệt hại khôn lường. Đặc biệt, do nguồn lực có hạn, việc kiểm thử phần mềm có thể phải ngừng lại khi cạn kiệt nguồn lực hay thời gian cho phép đã hết. Vấn đề đặt ra là, có thể dừng qúa trình kiểm thử được không hay bắt buộc phải kiếm thêm nguồn lực để tiếp tục. Ngay trong trường hợp còn nguồn lực, khi kiểm thử không phát hiện thấy lỗi, một câu hỏi tương tự đặt ra: có cần thiết phải tiếp tục kiểm thử nữa hay không. Để trả lời những câu hỏi trên đây, có một số cách cho phép đánh giá chất lượng đạt được của phần mềm để đưa ra quyết định: − Cách thứ nhất là xây dựng mô hình đo độ tin cậy để đánh giá chương trình. Khi chương trình đạt được một mức độ tin cậy nào đó thì có thể dừng lại. − Cách thử hai là đánh giá độ bao phủ chương trình của mục tiêu kiểm thử đặt ra đã thực hiện được. Khi độ bao phủ đạt được số phần trăm nào đó, đây cũng là một tiêu chí đánh giá cho phép có thể dừng quá trình kiểm thử. Vì những lý do trên, đề tài ”nghiên cứu kiểm thử bao phủ phần mềm và ứng dụng” được chọn làm đề tài cho luận văn cao học của tôi. Sau khi trình bày tổng quan về kiểm thử phần mềm, luận văn đi sâu vào quá trình kiểm thử phần mềm hướng đối tượng, đặc biệt cho trường hợp máy trạng thái. Trên cơ sở các phương pháp kiểm thử hướng đối tượng, nghiên cứu các phương pháp đánh giá độ bao phủ của kiểm thử nói chung, đặc biệt kiểm thử cho phần mềm hướng đối tượng. Tiếp đó tiến hành xây dựng một chương trình thử nghiệm về kiểm thử phủ theo các phương pháp đã biết để đánh giá mức độ bao phủ của các ca kiểm thử được tiến hành cho một chương trình được phát 2 triển sử dụng phương pháp máy trạng thái – một trường hợp riêng của phát triển phần mềm hướng đối tượng. 2. Đối tƣợng nghiên cứu  Lý thuyết về kiểm thử phần mềm nói chung và kiểm thử phần mềm hướng đối tượng nói riêng  Khái niệm về kiểm thử phủ và một vài phương pháp được sử dụng  Một vài công cụ dùng để đánh giá độ bao phủ của kiểm thử  Lý thuyết máy trạng thái và thử nghiệm về kiểm thử phủ 3. Mục đích và phƣơng pháp nghiên cứu Mục đích của nghiên cứu là góp phần hoàn thiện các công cụ đánh giá độ bao phủ của kiểm thử trợ giúp cho trình tiến hành kiểm thử phần mềm có thể thực hiện một cách hiệu quả hơn. 4. Ý nghĩa lý luận và thực tiễn của đề tài Kết quả nghiên cứu góp phần hoàn thiện các phương pháp kiểm thử phủ đã được nghiên cứu từ trước đến nay. Kết quả nghiên cứu cũng sẽ trang bị thêm một công cụ cho việc đánh giá kết quả của việc kiểm thử phần mềm. Với nội dung như trên, luận văn bao gồm: Chương I: Tổng quan về kiểm thử phần mềm: Chương này cho một cái nhìn tổng quan về kiểm thử phần mềm: các khái niệm cơ bản về kiểm thử phần mềm, các chiến lược và quy tắc trong kiểm thử, các phương pháp kiểm thử phần mềm tiêu biểu. Chương II: Kiểm thử phần mềm hướng đối tượng: Chương này trình bày khái quát về lập trình hướng đối tượng, khái niệm kiểm thử hướng đối tượng và tiến trình kiểm thử hướng đối tượng. Chương III: Kiểm thử bao phủ phần mềm: Trong chương này, đi tìm trình bày về kiểm thử bao phủ phần mềm, các phương pháp bao phủ phần mềm và các công cụ phân tích mức độ bao phủ phần mềm. Chương IV: Máy trạng thái và kiểm thử bao phủ máy trạng thái: Trong chương này trình bày khái lược về máy trạng thái và kiểm thử bao phủ máy trạng thái, xây dựng một chương trình thử nghiệm tiến hành kiểm thử phủ các trạng thái và các chuyển trạng thái cho bài toán cầu thang máy. Cuối cùng là kết luận và tài liệu tham khảo. 3 CHƢƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM Như chúng ta biết, mục tiêu của đảm bào chất lượng phần mềm (SQA) là sản xuất ra các phần mềm có chất lượng cao, đáp ứng được nhu cầu từ phía khách hàng, nhà sản xuất, và cả những người phát triển. Một trong các hoạt động quan trọng của SQA là kiểm thử phần mềm (software testing). Kiểm thử phần mềm là yếu tố quyết định của SQA và khâu điển hình của rà soát đặc tả thiết kế và lập mã. Việc phát triển hệ thống phần mềm bao gồm hàng loạt các hoạt động sản xuất, mà ở đó cơ hội để con người đưa vào phần mềm những sai lầm là rất lớn. Lỗi có thế bắt đầu xuất hiện từ lúc khởi đầu xác định mục tiêu cho phần mềm: có thể được xác định sai hay không hoàn chỉnh, cũng như các giai đoạn thiết kế và phát triển về sau. Phần mềm được kiểm thử sẽ hạn chế chi phí chi trả cho các thất bại do lỗi gây ra và đồng thời có kế hoạch nâng cao chất lượng của phần mềm cho suốt quá trình phát triển. 1.1. Khái niệm về lỗi phần mềm Có rất nhiều định nghĩa khác nhau, tựu chung, nói một cách tổng quát là: “ Lỗi phần mềm là sự không phù hợp giữa chương trình và đặc tả của nó” [Cem&90]. Một cách định nghĩa khác về lỗi phần mềm đó là: − Phần mềm không làm những gì đã được đặc tả cho nó. − Phần mềm làm những thứ mà đặc tả chỉ ra không nên làm − Phần mềm làm những thứ mà đặc tả sản phẩm không đề cập đến − Phần mềm khó hiểu, khó sử dụng, chậm, hoặc là người dùng cuối cùng đánh giá là không đúng điều mong muốn. “Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến mức nào, thì ngay cả những lập trình viên xuất sắc nhất cũng không có thể viết được ngay những đoạn mã không có lỗi. Tính trung bình, một lập trình viên loại tốt thì cũng mắc từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng, việc kiểm thử để tìm ra các lỗi này chiếm phần nửa khối lượng công việc phải làm để có được một phần mềm hoạt động được” [Beiz90] . 4 1.2. Nguyên nhân có lỗi phần mềm Khác với cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình. Nhiều nghiên cứu đã được thực hiện trong các dựa án nhỏ đến các dự án lớn và kết quả luôn giống nhau. Số lỗi do đặc tả gây ra là nhiều nhất. Trong nhiều trường hợp, đặc tả không được viết ra. Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, dễ bị thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển. Sự thay đổi của khách hàng cũng là nguyên nhân dễ gây lỗi. Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu: phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành. Nguồn lỗi gây ra lớn thứ hai là do thiết kế. Đó là nền tảng mà lập trình viên dựa vào để triển khai mã nguồn. Lỗi do lập trình gây ra là nguyên nhân thứ ba, và cũng là điều dễ hiểu, vì ai cũng có thể mắc lỗi. Thời kỳ đầu, phát triển phần mềm có nghĩa là lập trình, đó là công việc rất nặng nhọc, lỗi do lập trình gây ra là chủ yếu. Ngày nay công việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm. Mặc dù dược sự hỗ trợ của nhiều công cụ lập trình tiên tiến, việc lập trình đã trở nên nhẹ nhàng hơn, nhưng độ phức tạp của phần mềm ngày nay lớn. Do đó, lỗi do lập trình vẫn còn, tuy có ít hơn so với đặc tả hay thiết kế, nhưng nguyên nhân để lập trình tạo ra lỗi thì nhiều hơn. 1.3. Chi phí cho việc sửa lỗi Theo thống kê của IBM, GTE, TRW -1976 thì giá của mỗi sai lầm là:  Trong giai đoạn phân tích: 200 $  Trong giai đoạn thiết kế: 500 $  Trong khi kiểm tra chương trình: 1 200 $  Trong giai đoạn kiểm thử và bảo trì: 5 000 $  Khi đã đưa vào hoạt động: 15 000 $ Có thể thấy rằng, kiểm thử phần mềm là hoạt động có chi phí đắt thứ hai, ước tính chiếm khoảng 40% tổng chi phí của toàn bộ quá trình phát triển một sản phẩm phần mềm lần đầu. Kiểm thử và sửa lỗi được thực hiện tại bất kỳ giai 5 đoạn nào của vòng đời phát triển. Tuy nhiên, chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo quá trình phát triển. 1.4. Khái niệm về kiểm thử phần mềm Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện. Kiểm thử phần mềm là quá trình thực hiện một hệ thống phần mềm để xác định xem nó có đúng với đặc tả hay yêu cầu của người dùng không trong một môi trường mong đợi. 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 một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa; nhưng bản thân kiểm thử không làm công việc chuẩn đoán nguyên nhân gây ra lỗi và sửa lỗi. Để kiểm thử cần lập kế hoạch cho mỗi lần (một ca) kiểm thử Một ca kiểm thử thường bao gồm:  tên của mô đun kiểm thử  dữ liệu vào  các bước thực hiện  dữ liệu ra mong muốn (đúng)  dữ liệu ra thực tế (khi đã tiến hành kiểm thử ) Các ca kiểm thử nên được thiết kế ngay khi tạo ra các tài liệu phân tích và thiết kế, không phải chờ đến khi đã viết xong mã nguồn. Một ca kiểm thử được gọi là thành công nếu nó phát hiện ra một khiếm khuyết của phần mềm. Tuy nhiên, các ca kiểm thử chỉ chứng minh được sự tồn tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi. Theo Glen Mayers [Myer79], kiểm thử phần mềm là quá trình vận hành chương trình để tìm ra lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác suất cao tìm ra một lỗi chưa được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện. Bài toán kiểm thử luôn được đặt ra là: tổ chức việc kiểm thử như thế nào để tìm ra lỗi nhiều nhất có thể và với chi phí bỏ ra là ít nhất. Giải quyết bài toán này quả là không đơn giản, do bản chất phức tạp của các hệ thống phần mềm. Trước hết việc kiểm thử được tổ chức theo nhiều mức 6 tăng dần theo quy mô được phát triển của phần mềm và tương ứng với tiến trình phát triển. Với chiến lược này, người ta hy vọng rằng những mức sau là bổ sung cho mức trước trong việc tìm lỗi còn sót và những loại lỗi khác mà mức trước chưa có. Trên mỗi mức, cần áp dụng các chiến lược, phương pháp và kỹ thuật khác nhau để có thể thực hiện số lần (ca) kiểm thử ít nhất mà vẫn bao quát được các phạm vi của phần mềm mà kiểm thử đặt ra. Những nôi dung này đã được phản ánh đầy đủ trong tài liệu[Vy&Ha08]. Tuy nhiên, do vẫn còn tồn lại các lỗi trong nhiều phần mềm đã kiểm thử; thêm nữa, cùng với sự tăng lên về quy mô và độ phức tạp của phần mềm, phần mềm còn được phát triển theo những cách thức mới, vì thế các phương pháp và công cụ kiểm thử tiếp tục được phát triển để nâng cao chất lượng phần mềm và giảm thiểu công sức bỏ ra cho kiểm thử. 1.5. Các mức của kiểm thử phần mềm Thực tế, công việc kiểm thử phần mềm có nhiều mức khác nhau và có mối quan hệ chặt chẽ với các giai đoạn phát triển trong của một dự án phát triển phần mềm. Hình 1.1 là 4 mức độ cơ bản của kiểm thử phần mềm. Bốn mức kiểm thử đó là:  Kiểm thử đơn vị  Kiểm thử tích hợp  Kiểm thử hệ thống  Kiểm thử chấp nhận test chấp nhận xác đinh yêu cầu kế hoạch kiểm thử chấp đặc tả hệ nhận thống thiết kế kiến trúc kế hoạch kiểm thử hệ thống thiết kế chi tiết lập trình test hệ thống kế hoạch kiểm thử tích hợp test tích hợp test đơn vị rà soát, phân tích mã Hình 1.1. Mô hình chữ V của quá trình kiểm thử 7 Mô hình chữ V cho thấy, ngay trong quá trình phát triển, các yêu cầu và đặc tả kiểm thử đã được xây dựng làm cơ sở cho việc lập kế hoạch chi tiết để thực hiện các bước kiểm thử sau này. 1.5.1. Kiểm thử mức đơn vị Để hiểu rõ về kiểm thử đơn vị, trước tiên ta cần làm rõ: thế nào là một đơn vị phần mềm? Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Theo định nghĩa này, các hàm (Function), các thủ tục (Procedure), các lớp (Class), hoặc các phương thức (Method) đều có thể được xem là đơn vị. Vì đơn vị được chọn để kiểm thử thường có kích thước nhỏ và chức năng hoạt động đơn giản, nên dễ tổ chức, kiểm tra, ghi nhận và phân tích kết quả nhận được. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục lỗi đối với một đơn vị là tương đối đối dễ dàng. Một nguyên lý đúc kết từ thực tiễn là: thời gian tốn cho kiểm thử đơn vị sẽ được bù đắp bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó. Kiểm thử đơn vị thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt. Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và hiểu được mã của chương trình. Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất ra là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của đơn vị. Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm thử để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh. Việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa. Phương pháp được sử dụng để kiểm thử đơn vị là phương pháp hộp trắng. Ngoài ra có thể còn cấn đến các kỹ thuật bộ cuống và bộ lái 1.5.2. Kiểm thử tích hợp Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như một chức năng ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị, chúng 8 được kiểm thử riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau tạo thành một chức năng lớn hơn để kiểm thử. Kiểm thử tích hợp có hai mục tiêu chính:  Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị .  Tích hợp các đơn vị đơn lẻ để có được các hệ thống nhỏ (subsystem) và cuối cùng là toàn bộ hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở mức hệ thống. Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của đơn vị chương trình. Có một số phép kiểm thử đơn giản trên giao diện giữa đơn vị với các thành phần liên quan khác được tiến hành trong kiểm thử đơn vị; tuy nhiên mọi giao tiếp liên quan đến đơn vị thật sự được kiểm thử đầy đủ khi các đơn vị tích hợp với nhau trong khi thực hiện kiểm thử tích hợp. Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm thử cẩn thận trước đó, và tất cả các lỗi mức đơn vị đã được sửa chữa. Một số người hiểu sai rằng, một mô đun chương trình khi đã qua giai đoạn kiểm thử đơn vị với các giao tiếp giả lập thì không cần phải thực hiện kiểm thử tích hợp nữa. Thực tế việc tích hợp các đơn vị dẫn đến những tình huống hoàn toàn khác. A B F A K C D B C E Theo chiều sâu a. Chiến lược từ trên xuống D E cụm chức năng 1 K F G H I cụm chức năng 2 b. Chiến lược từ dưới lên Hình 1.2. Các chiến lươc tích hợp dần 9 Để tích hợp, người ta có thể sử dụng một số chiến lược tích hợp: − Tích hợp đồng thời (với các chương trình nhỏ) - chiến lược Big-Bang − Tích hợp dần từng bước (khi chương trình có nhiều mô đun). Trong chiến lược tích hợp dần này lại có thể tiến hành tích hợp từ trên xuống hay từ dưới lên. Khi tích hợp từ trên xuống lại có thể thực hiện chiến lược theo chiều sâu hay theo chiều rộng (xem hình 1.2), tức là có nhiều chiến lược để tiến hành kiểm thử tích hợp. Hai phương pháp được sử dụng trong kiểm thử tích hợp là phương pháp hộp trắng (để kiểm thử cấu trúc) và phương pháp hộp đen (kiểm thử chức năng). Ngoài ra, khi tiến hành hành tích hợp cần phải sử dụng kỹ thuật bộ cuống và bộ lái để thay thế cho những mô đun còn thiếu mà cần thiết cho phần hệ thống được kiểm thử (xem hình 1.3) Bộ lái Bộ cuống Hình 1.3. Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần Một yêu cầu đặt ra không thể bỏ qua khi kiểm thử tích hợp là phải tiến hành kiểm thử hồi quy mỗi khi tích hợp thêm mô đun mới hay sửa đổi một mô đun trong số các mô đun đã kiểm thử. 1.5.3. Kiểm thử mức hệ thống Mục đích kiểm thử hệ thống là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không. Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần 10 mềm hoặc phần cứng đặc thù, đặc biệt là đối với các ứng dụng thời gian thực, hệ thống phân tán, hoặc hệ thống nhúng… Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi mà trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng ở mức độ của toàn hệ thống. Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi ở mức toàn hệ thống, còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Kiểm thử hệ thống là kiểm tra tất cả các hành vi chức năng của phần mềm cùng các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm khác hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ. Do cần nhiều công sức, thời gian và độ chính xác cao, tính khách quan, kiểm thử hệ thống thường được một nhóm kiểm thử viên có trình độ cao hoàn toàn độc lập với nhóm phát triển dự án thực hiện. Bản thân Kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau (xem hình 3), phổ biến nhất gồm: − Kiểm thử chức năng: bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. − Kiểm thử khả năng vận hành: bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn... − Kiểm thử khả năng chịu tải: bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Kiểm thử khả năng chịu tải tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường... − Kiểm thử cấu hình: Kiểm tra sự cấu thành của hệ thống từ các thành phần dự kiến. 11 − Kiểm thử khả năng an toàn và bảo mật: bảo đảm tính toàn vẹn, bảo mật của dữ liệu và chương trình của hệ thống khi có sự xâm nhập và tấn công từ bên ngoài − Kiểm thử khả năng phục hồi: bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến. Nhìn từ quan điểm người dùng, các kiểm thử trên rất quan trọng, bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực. Trên thực tế không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm thử nào. 1.5.4. Kiểm thử chấp nhận Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng). Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các kiểm thử của Kiểm thử hệ thống và Kiểm thử chấp nhận gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt. Đối với những sản phẩm để bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là Kiểm thử Alpha và Kiểm thử Beta. Với Kiểm thử Alpha, người sử dụng tiềm năng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Kiểm thử Beta, phần mềm sẽ được gửi tới cho người sử dụng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa. Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Kiểm thử chấp nhận sẽ sai lệch rất lớn, 12 mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Gắn liền với giai đoạn Kiểm thử chấp nhận thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ. 1.5.5. Kiểm thử hồi quy Kiểm thử hồi quy không phải là một mức kiểm thử, như các mức khác đã nói ở trên. Nó đơn thuần là kiểm thử lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt. Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra, đặc biệt trong kiểm thử tích hợp. Ví dụ 1.1: một phần mềm đang phát triển khi kiểm thử cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi mã của chức năng C, nếu chỉ kiểm thử chức năng C thì chưa đủ, cần phải kiểm thử lại tất cả các chức năng khác liên quan đến chức năng C. Mặc dù không phải là một mức kiểm thử, Kiểm thử hồi quy là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất. Do đó việc bỏ qua Kiểm thử hồi quy là "không được phép" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được kiểm thử và sửa chữa. 1.6. Các chiến lƣợc kiểm thử Một chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế các phép thử tạo thành một dãy các bước để hướng dẫn quá trình kiểm thử phần mềm thành công. Nó đưa ra một bản đồ đường đi mô tả các bước trong quá trình kiểm thử. Vì thế chiến lược kiểm thử nào cũng phải tích hợp được việc lập kế hoạch kiểm thử, thiết kế các ca kiểm thử, tiến hành kiểm thử, thu thập và đánh giá các thông tin kết quả. 13 Chiến lược kiểm thử phần mềm phải đủ mềm dẻo để cổ vũ các cách tiếp cận sáng tạo của người thực hiện. Nhưng với tư cách là một tiến trình trong dự án, nó cũng phải vừa đủ chặt chẽ để hỗ trợ các kế hoạch và phương thức quản lý. Một chiến lược kiểm thử phần mềm phải thích ứng với từng mức kiểm thử: Các kiểm thử mức thấp (xác minh từng khúc mã nguồn xem có thực thi đúng đắn không), và các kiểm thử mức cao (thẩm định các chức năng hệ thống có đáp ứng yêu cầu khách hàng hay không). Có nhiều chiến lược kiểm thử phần mềm khác nhau như đã nêu ở trên. Các chiến lược kiểm thử khác nhau có thể tìm ra các loại lỗi khác nhau. Vì thế không thể tập trung vào một chiến lược kiểm thử mà bỏ qua các loại khác. Các mức của quá trình kiểm thử cần được thực hiện tuần tự và bổ sung cho nhau nhằm tìm ra từng loại lỗi với các phương pháp thích hợp. 1.7. Các phƣơng pháp kiểm thử 1.7.1. Kiểm thử hộp trắng Kiểm thử hộp trắng là việc kiểm tra các đoạn mã chương trình xem nó có vận hành đúng như thiết kế hay không. Kiểm thử hộp trắng dựa trên việc xem xét cấu trúc bên trong của chương trình theo cấu trúc điều khiển và sự hoạt động của chúng. Vì thế, nó còn có các tên gọi khác (như: glass testing, tructural testing, open box testing hay clear box testing[Beize95]). Để kiểm thử tốt, người kiểm thử phải có hiểu biết về lập trình, về mã lệnh của ngôn ngữ lập trình, về logic bên trong của chúng và sự vận hành của chương trình. Đối tượng của kiểm thử hộp trắng là môđun mã lệnh. Để đảm bảo tính đầy đủ thì kiểm thử hộp trắng cần phải làm sao để: Mọi lệnh phải được thực hiện, mọi điều kiện phải được kiểm tra, mọi chu trình được duyệt qua, mọi cấu trúc dữ liệu cục bộ được sử dụng, mọi tiến trình được lần vết. Từ đó đặt ra yêu cầu cho các ca kiểm thử hộp trắng ít nhất phải đảm bảo: − Mọi con đường độc lập trong một mođun cần được thực hiện ít nhất một lần − Mọi ràng buộc logic được thực hiện cả hai phía đúng (true) và sai (false). 14 − Tất cả các vòng lặp ở biên của nó và cả các biên vận hành phải được thực hiện. − Mọi cấu trúc dữ liệu cục bộ được sử dụng để đảm bảo tính hiệu lực của chúng. Tương ứng với các yêu cầu đặt ra ở trên, một số kỹ thuật sau đây đã được sử dụng khi xây dựng các ca kiểm thử theo phương pháp hộp trắng: − Đồ thị luồng (flow graph) − Ma trận kiểm thử (testing matrices) − Kiểm thử vòng lặp (loop testing) − Kiểm thử luồng dữ liệu (data flow testing). − Kiểm thử điều kiện. Kiểm thử hộp trắng được sử dụng ở ba loại kiểm thử là: Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hồi quy. 1.7.2. Kiểm thử hộp đen Kiểm thử hộp đen (blackbox testing) xem phần mềm như một “ hộp đen” thuần túy, người kiểm thử không cần quan tâm đến cấu trúc và hoạt động bên trong của nó. Bằng cách nhập các dữ liệu đầu vào qua giao diện, thực thi chương trình và xem xét kết quả đầu ra qua giao diện để nhận biết việc thực hiện chức năng có phù hợp với sự mong đợi hay không. Kiểm thử hộp đen vì thế còn được gọi là kiểm thử chức năng (functional testing) hay kiểm thử hành vi (behavioral testing). Như vậy, cơ sở cho việc kiểm thử hộp đen chính là đặc tả chức năng của phần mềm và các dữ liệu mà nó sử dụng hình 1.4: Cái vào Hộp đen (Một hay nhiều mô đun) Chi tiết bên trong không được tính tới Hình 1.4 : Mô hình mô tả kiểm thử hộp đen Cái ra