phần mở đầu, phần kết luận và ba chƣơng nội dung đƣợc bố cục nhƣ sau: 2 Chƣơng 1 sẽ trình bày nội dung tổng quan các kiểm thử phần mềm cũng nhƣ phép kiểm thử robustness. Chƣơng 2 sẽ trình bày lý thuyết về nội dung xác định biên phân hoạch dữ liệu kiểm thử đầu vào có tính hợp lệ với dữ liệu kiểm thử đầu vào không hợp lệ trong miền không gian của dữ liệu kiểm thử đầu vào, cụ thể là mô tả về biên phân hoạch có tính hợp lệ, đột biến dữ liệu kiểm thử, các độ đo khoảng cách trên dữ liệu kiểm thử và phƣơng pháp tìm biên phân hoạch. Chƣơng 3 sẽ trình bày cài đặt minh chứng đƣợc những nội dung lý thuyết đã trình bày trong chƣơng 2 đối với một loại dữ liệu kiểm thử đầu vào cụ thể đƣợc lựa chọn. KIỂM THỬ ROBUSTNESS 1.1 GIỚI THIỆU CHUNG VỀ KIỂM THỬ ROBUSTNESS 1.1 Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dƣới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.
Kiểm thử phần mềm là quá trình thực thi một chƣơng trình với mục đích tìm lỗi. Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trƣờng chúng dự định sẽ đƣợc triển khai nhằm cung cấp cho ngƣời có lợi ích liên quan những thông tin về chất lƣợng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ƣu của phần mềm trong nhiều ngành khác nhau. Có thể định nghĩa một cách dễ hiểu nhƣ sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình đƣợc thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã đƣợc thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn.
Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho ngƣời xây dựng hệ thống và khách hàng thấy đƣợc hệ thống mới đã đáp ứng yêu cầu đặt ra hay chƣa? 4 Kiểm thử (Testing) là một quá trình đánh giá một hệ thống hay là các thành phần của nó với mục đích là xác định xem nó có thỏa mãn những yêu cầu đƣợc đƣa ra hay không, có sự khác biệt nào giữa phần mềm thực tế đang tồn tại và những điều kiện đƣợc yêu cầu (requirement). Hiểu một cách đơn giản, kiểm thử – test là chạy một quá trình để xác nhận bất kỳ thiếu sót (defect), lỗi (bug), sai sót (error) hay những yêu cầu bị bỏ quên, những yêu cầu không đúng so với yêu cầu thực tế đề ra.2 Kiểm thử robustness Mục tiêu của kiểm thử robustness là để kích hoạt các lỗi, thƣờng là lỗi thiết kế hoặc lập trình, hoặc các lỗ hổng trong hệ thống dẫn đến phần mềm hoạt động không chính xác, do đó ảnh hƣởng đến khả năng phục hồi của hệ thống. Các lỗi về robustness thƣờng đƣợc phân loại theo tiêu chí CRASH [7]: Catastrophic (toàn bộ hệ thống bị treo hoặc khởi động lại), Restart (ứng dụng phải đƣợc khởi động lại), Abort (ứng dụng kết thúc bất thƣờng), Silent (hoạt động không hợp lệ đƣợc thực hiện mà không tín hiệu lỗi), và Hindering (trả về mã lỗi không chính xác). Thƣớc đo có thể đƣợc đƣa ra dƣới dạng tỷ lệ các trƣờng hợp thử nghiệm có lỗi.
Theo quan điểm của vòng đời của hệ thống, kiểm thử robustness có thể đƣợc sử dụng nhƣ một bƣớc nội bộ trong quá trình phát triển, bổ sung cho các hoạt động xác minh và đánh giá khác. Ngoài ra, việc kiểm thử cũng có thể đƣợc thực hiện từ phía bên ngoài sau khi phát hành hệ thống để có thể đánh giá độ tin cậy của hệ thống hoặc để so sánh với các hệ thống khác. Các lỗi đƣợc phát hiện có thể đƣợc xử lý bằng cách thực hiện các hiệu chỉnh trong thiết kế và mã triển khai hoặc bằng cách áp dụng các cách thức để hạn chế ảnh hƣởng của các lỗi. Giải pháp thứ hai này đặc biệt phù hợp khi hệ thống chứa các thành phần thƣơng mại sẵn có.2 DỮ LIỆU THỬ TRONG KIỂM THỬ ROBUSTNESS 1.1 Dữ liệu ngẫu nhiên Một trong những kỹ thuật kiểm thử robustness đầu tiên là tạo đầu vào ngẫu nhiên cho hệ thống.
Đầu vào ngẫu nhiên rất dễ tạo, có khả năng lỗi đƣợc kích hoạt bởi chúng với tiêu chí chấp nhận đơn giản nhƣ chƣơng trình treo hoặc chết nên không cần tạo đầu ra tham chiếu. Fuzz [8] là một trong những công cụ đầu tiên hỗ trợ kỹ thuật này. Bảng danh mục các hệ thống thử trong [8] Fuzz đã đƣợc sử dụng trong ba loạt thí nghiệm của các ứng dụng khác nhau. Năm 1990, các chƣơng trình tiện ích trên bảy biến thể của hệ điều hành Unix đã đƣợc thử nghiệm.
Vào năm 1995, các thử nghiệm đã đƣợc lặp lại để kiểm thử xem tính mạnh mẽ của các tiện ích này đã đƣợc cải thiện hay chƣa và hỗ trợ thử nghiệm các ứng dụng X Window đã đƣợc thêm vào. Cuối cùng, vào năm 2000, Fuzz đã đƣợc sử dụng để kiểm thử 30 ứng dụng GUI trên Windows NT. Mặc dù phƣơng pháp đƣợc sử dụng thực sự đơn giản, nhƣng 6 nó đã phát hiện ra rất nhiều lỗi robustness, cụ thể là 40% chƣơng trình dòng lệnh Unix và 45% chƣơng trình Windows NT bị kết thúc bất thƣờng hoặc treo, tức là ngừng phản hồi trong một khoảng thời gian dài quá mức khi đƣợc gọi với dữ liệu đầu vào ngẫu nhiên. Mặc dù dữ liệu ngẫu nhiên là một kỹ thuật cơ bản, nó tỏ ra hữu ích ngay cả đối với các hệ thống phần mềm COTS hiện đại.
Các thử nghiệm trong Fuzz đã đƣợc áp dụng lại cho MacOS trong một nghiên cứu đƣợc chuẩn bị vào năm 2007 [9] với các kết quả sau: 10 chƣơng trình chạy trên cửa sổ lệnh bị lỗi trong số 135 chƣơng trình đã đƣợc kiểm thử (tỷ lệ lỗi là 7%), 20 chƣơng trình bị chết và 2 chƣơng trình bị treo trong số 30 chƣơng trình có giao diện ngƣời dùng đƣợc thử nghiệm (tỷ lệ thất bại là 73%). Do đó, sử dụng dữ liệu đầu vào ngẫu nhiên là một kỹ thuật khả thi và hiệu quả.2 Dữ liệu không hợp lệ Các giá trị tham số của dữ liệu thƣờng có các ranh giới và miền cho phép. Ví dụ: nếu các giá trị đƣợc phép của một tham số là số nguyên dƣơng thì có thể kiểm thử với giá trị 0, số âm và giá trị MAXINT. Một công cụ hỗ trợ phƣơng pháp này đƣợc giới thiệu [10].
Công cụ sử dụng mô tả dựa trên văn phạm về đầu vào của hệ thống để tạo ra các bài kiểm thử ngẫu nhiên và không hợp lệ. Theo định nghĩa văn phạm, các đầu vào đƣợc tạo ra với các giá trị ngẫu nhiên, các giá trị lỗi có thể có, nhƣ các ký tự đặc biệt không thể in đƣợc, và các giá trị ranh giới, ví dụ nhƣ số MAXINT + 1. Bằng cách này, các đầu vào chính xác về mặt cú pháp cũng có thể đƣợc tạo và một phần lớn chức năng của hệ thống có thể đƣợc kiểm thử. Kết quả cho thấy khoảng 10% các thử nghiệm trên các chƣơng trình cửa sổ lệnh GNU tạo ra các ngoại lệ không đƣợc xử lý.
Các lỗi đƣợc quan sát thấy chủ yếu là các ngoại lệ vi phạm quyền truy cập bộ nhớ, các ngoại lệ về lệnh đặc quyền và các ngoại lệ về lệnh bất 7 hợp pháp. Nguyên nhân điển hình của những trƣờng hợp ngoại lệ này là do việc xử lý không đúng các ký tự không in đƣợc và các luồng đầu vào dài quá mức. Một lĩnh vực khác mà các dữ liệu đầu vào không hợp lệ có thể đƣợc áp dụng là trong kiểm thử trình điều khiển thiết bị hệ điều hành cấp thấp. Trong [11], các trình điều khiển nhƣ vậy đã đƣợc kiểm thử bằng cách chọn các giá trị cực trị từ các danh mục sau: giá trị bị cấm, giá trị ngoài giới hạn, gán con trỏ không hợp lệ, gán con trỏ NULL, thiếu khởi tạo biến cục bộ và thiếu lệnh gọi của một hàm liên quan.
Thử nghiệm trình điều khiển trong [11] 8 1. MỘT SỐ NGHIÊN CỨU LIÊN QUAN 1.1 Các phƣơng pháp kiểm thử 1.1 Kiểm thử tĩnh Là phƣơng pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chƣơng trình. Kiểu kiểm thử này thƣờng đƣợc sử dụng bởi chuyên viên thiết kế - ngƣời mà viết mã lệnh một mình. Kiểm thử tĩnh cũng có thể đƣợc tự động hóa.
Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chƣơng trình đƣợc phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chƣơng trình.2 Kiểm thử động Là phƣơng pháp thử phần mềm thông qua việc dùng máy chạy chƣơng trình để điều tra trạng thái tác động của chƣơng trình. Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tƣợng kiểm thử hay chạy các chƣơng trình. Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự đƣợc biên dịch và chạy.
Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có nhƣ mong muốn hay không. Các phƣơng pháp kiểm thử động gồm có kiểm thử Unit - Unit Tests, Kiểm thử tích hợp - Intergration Tests, Kiểm thử hệ thống - System Tests, và Kiểm thử chấp nhận sản phẩm - Acceptance Tests.2 Các chiến lƣợc kiểm thử 1.1 Kiểm thử hộp đen Một trong những chiến lƣợc kiểm thử quan trọng là kiểm thử hộp đen, hƣớng dữ liệu, hay hƣớng vào/ra. Kiểm thử hộp đen xem chƣơng trình nhƣ là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cƣ xử và cấu trúc bên trong của chƣơng trình.
Thay vào đó, tập trung vào tìm các trƣờng hợp mà chƣơng trình không thực hiện theo các đặc tả của nó. Theo hƣớng tiếp cận này, dữ liệu kiểm tra đƣợc lấy chỉ từ các đặc tả. Các phƣơng pháp kiểm thử hộp đen: Phân lớp tƣơng đƣơng - Equivalence partitioning [12]. Phân tích giá trị biên - Boundary value analysis [13].
Kiểm thử mọi cặp - All-pairs testing [14]. Kiểm thử fuzz - Fuzz testing [15]. Kiểm thử dựa trên mô hình - Model-based testing [16].