Luận văn Thạc sĩ Khoa học: Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C

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

Thêm vào BST

Báo xấu

87
lượt xem 12
download

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

Kiểm thử phần mềm luôn là một trong những hoạt động quan trọng nhằm đánh giá chất lượng phần mềm. Kiểm thử đột biến đã được áp dụng cho nhiều ngôn ngữ lập trình như là một kỹ thuật kiểm thử hộp trắng. Bên cạnh việc sử dụng kiểm thử đột biến ở mức thực thi phần mềm, kiểm thử đột biến còn được sử dụng ở mức thiết kế để kiểm thử các đặc tả hoặc các mô hình của chương trình. Ý thức được đây là một lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng trong phát triển phần mềm, tác giả chọn đề tài "Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C”.

Chủ đề:

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

Lưu

Nội dung Text: Luận văn Thạc sĩ Khoa học: Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C

LỜI CẢM ƠN Trong suốt quá trình học tập và làm luận văn, tôi đã nhận được sự hướng dẫn, giúp đỡ quý báu của quý thầy cô, các anh chị và các bạn. Với lòng kính trọng và biết ơn sâu sắc tôi xin được bày tỏ lời cảm ơn chân thành tới:  Ban giám hiệu, Phòng đào tạo sau đại học trường Đại Học Khoa Học Tự Nhiên;  Phó giáo sư - Tiến sĩ Đoàn Văn Ban - người thầy đã hết lòng giúp đỡ, dạy bảo, động viên và tạo mọi điều kiện thuận lợi cho tôi trong suốt quá trình học tập và hoàn thành luận văn tốt nghiệp.  Cùng tất cả các thầy cô trong khoa, trong trường, các anh chị trong lớp.  Xin chân thành cảm ơn các thầy cô trong hội đồng đã cho tôi những đóng góp quý báu để hoàn chỉnh luận văn này. Tác giả Phạm Thị Miên
MỤC LỤC LỜI CẢM ƠN ................................................................................................................... 1 MỤC LỤC ........................................................................................................................ 2 I) DANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ........................................................ 5 II) DANH MỤC CÁC BẢNG BIỂU ................................................................................. 5 III) DANH MỤC CÁC HÌNH VẼ ..................................................................................... 5 LỜI MỞ ĐẦU ................................................................................................................... 6 CHƯƠNG 1 – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM............................................. 9 1.1. Khái niệm ............................................................................................................... 9 1.2. Các cấp độ kiểm thử phần mềm .............................................................................. 9 1.2.1. Kiểm thử đơn vị (Unit Test) ........................................................................... 10 1.2.2. Kiểm thử tích hợp (Integration Test) .............................................................. 10 1.2.3. Kiểm thử hệ thống (System Test) ................................................................... 11 1.2.4. Kiểm thử chấp nhận sản phẩm (Acceptance Test)........................................... 13 1.3. Kỹ thuật kiểm thử phần mềm ................................................................................ 13 1.3.1. Kỹ thuật kiểm thử hộp đen (Black – box Testing)........................................... 13 1.3.1.1. Phân hoạch tương đương ......................................................................... 15 1.3.1.2. Phân tích giá trị biên................................................................................ 17 1.3.2. Kỹ thuật kiểm thử hộp trắng (White – box Testing) ........................................ 18 1.3.2.1. Kiểm thử đường dẫn cơ sở....................................................................... 18 1.3.2.2. Kiểm thử cấu trúc điều khiển ................................................................... 23 1.4. Kết luận ............................................................................................................ 26 CHƯƠNG 2 – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ...................................................... 27 2.1. Một số khái niệm .................................................................................................. 27 2.1.1. Kiểm thử đột biến .......................................................................................... 27 2.1.2. Đột biến ......................................................................................................... 27 2.1.3. Toán tử đột biến ............................................................................................. 30 2.2. Cơ sở của kiểm thử đột biến.................................................................................. 30 2.3. Toán tử đột biến.................................................................................................... 30 2.4. Quy trình kiểm thử đột biến .................................................................................. 32 2.5. Hạn chế của kiểm thử đột biến .............................................................................. 34 2.6. Kết luận ................................................................................................................ 35 2
CHƯƠNG 3 - MỘT SỐ CẢI TIẾN KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ...................... 36 3.1. Giảm chi phí tính toán........................................................................................... 36 3.1.1. Phương pháp làm ít hơn (A “do fewer” approach) .......................................... 36 3.1.1.1. Lấy mẫu đột biến (Mutant Sampling) ..................................................... 37 3.1.1.2. Đột biến ràng buộc (Constrained Mutation) ............................................. 39 3.1.1.3. N - đột biến lựa chọn (N - Selective Mutation) ....................................... 40 3.1.2. Phương pháp làm nhanh hơn (A “do smarter” approach) ................................ 42 3.1.2.1. Phương pháp tạo lược đồ đột biến ........................................................... 43 3.1.2.2. Đột biến yếu (Weak Mutation) ................................................................ 45 3.2. Tăng tự động hóa .................................................................................................. 48 3.2.1. Tạo dữ liệu thử tự động .................................................................................. 48 3.2.2. Xác định các đột biến tương đương tự động ................................................... 50 3.3. Kết luận ............................................................................................................ 53 CHƯƠNG 4 - ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH C (C – Sharp) .................................................................................... 54 4.1. Tìm hiểu về NUnit ................................................................................................ 55 4.1.1. Định nghĩa ..................................................................................................... 55 4.1.2. Đặc điểm của NUnit ....................................................................................... 55 4.1.3. Thuộc tính hay dùng trong thư viện NUnit.Framework................................... 55 4.1.4. Phương thức tĩnh hay dùng trong NUnit.Framework.Assert ........................... 57 4.1.5. Cài đặt NUnit ................................................................................................. 59 4.1.6. Cách sử dụng NUnit ....................................................................................... 61 4.2. Công cụ Nester ..................................................................................................... 69 4.2.1. Điều kiện tiên quyết ....................................................................................... 69 4.2.2. Giải pháp cho đột biến ................................................................................... 69 4.2.3. Chạy Nester ................................................................................................... 70 4.2.4. Lựa chọn Nester.exe.config ........................................................................... 72 4.3. Quy trình ứng dụng kiểm thử đột biến để kiểm thử các chương trình C - Sharp ..... 72 4.3.1. Kiểm thử ........................................................................................................ 73 4.3.2. Tạo đột biến ................................................................................................... 74 4.4. Kết luận ................................................................................................................ 76 KẾT LUẬN..................................................................................................................... 77 TÀI LIỆU THAM KHẢO ............................................................................................... 79 3
PHỤ LỤC 1 .................................................................................................................... 82 PHỤ LỤC 2 .................................................................................................................... 84 PHỤ LỤC 3 .................................................................................................................... 90 PHỤ LỤC 4 .................................................................................................................... 94 PHỤ LỤC 5 .................................................................................................................... 95 4
I) DANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ - CBT (Constraint Based Testing): Kiểm thử dựa trên ràng buộc - MSG (Mutation Analysis Using Mutant Schemata): Phương pháp tạo lược đồ đột biến - PUT (Program Unit Test): Chương trình gốc II) DANH MỤC CÁC BẢNG BIỂU Bảng 1.1. Ví dụ các lớp tương đương Bảng 2.1. 22 toán tử chuẩn được sử dụng trong Mothra Bảng 4.1. Lựa chọn Nester.exe.config Bảng 4.2. Kết quả chạy NUnit Bảng 4.3. Chất lượng các trường hợp kiểm thử chương trình cs – money sau khi thực hiện Nester III) DANH MỤC CÁC HÌNH VẼ Hình 1.1. Bốn cấp độ cơ bản của kiểm thử phần mềm Hình 1.2. Đồ thị luồng điều khiển Hình 1.3. Ví dụ minh hoạ phát sinh các trường hợp kiểm thử theo đường dẫn cơ sở Hình 1.4. Các kiểu vòng lặp Hình 2.1. Ví dụ về đột biến tương đương Hình 2.2. Ví dụ về đột biến Hình 3.1. Ba kịch bản có thể có cho quan hệ giữa các tập dữ liệu thử diệt đột biến yếu và mạnh Hình 3.2. Phân bố đột biến bằng toán tử đột biến cho Mothra Hình 3.3. Ví dụ phương thức gốc (PUT) Hình 3.4. Phiên bản đột biến của PUT gốc hình 3.3 Hình 4.1. Quy trình ứng dụng kiểm thử đột biến trong C# 5
LỜI MỞ ĐẦU Kiểm thử phần mềm là một hoạt động giữ vai trò rất quan trọng để bảo đảm chất lượng phần mềm và là hoạt động mang tính sống còn trong các dự án sản xuất hoặc gia công phần mềm. Vì vậy, kiểm thử phần mềm đã trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới. Ở Việt Nam, ngành công nghiệp phần mềm đang phát triển thì không thể xem nhẹ việc kiểm thử phần mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử đi kèm thì sẽ không được chấp nhận. Tuy nhiên, hoạt động kiểm thử thường gặp nhiều khó khăn:  Thứ nhất, kiểm thử các hệ thống phức tạp đòi hỏi rất nhiều nguồn tài nguyên và chi phí cao.  Thứ hai, tiến trình phát triển phần mềm luôn trải qua nhiều hoạt động biến đổi thông tin, sự mất mát thông tin trong quá trình biến đổi là yếu tố chính làm cho hoạt động kiểm thử khó khăn.  Thứ ba, kiểm thử chưa được chú trọng trong đào tạo con người.  Cuối cùng, không tồn tại kỹ thuật kiểm thử cho phép khẳng định một phần mềm hoàn toàn đúng đắn hay không chứa lỗi. Với mục đích phát hiện lỗi, kiểm thử phần mềm thường phải trải qua các bước: tạo dữ liệu thử, thực thi phần mềm trên dữ liệu thử và quan sát kết quả nhận được. Trong các bước này, bước tạo dữ liệu đóng vai trò quan trọng nhất, bởi vì chúng ta không thể tạo ra mọi dữ liệu từ miền vào của chương trình, mà chúng ta chỉ có thể tạo ra các dữ liệu thử có khả năng phát hiện lỗi cao nhất. Vấn đề đặt ra là làm thế nào để đánh giá được khả năng phát hiện lỗi của một bộ dữ liệu thử? Một kinh nghiệm để giúp giải quyết vấn đề này, đó là sử dụng khái niệm chất lượng bộ dữ liệu thử như là một phương tiện để đánh giá bộ dữ liệu thử như thế nào là “tốt” khi kiểm thử chương trình. Ở đây, “tốt” được đánh giá 6
liên quan đến tiêu chuẩn chất lượng được định trước, thường là một số dấu hiệu bao phủ chương trình. Ví dụ, tiêu chuẩn bao phủ dòng lệnh đòi hỏi bộ dữ liệu thử thực hiện mọi dòng lệnh trong chương trình ít nhất một lần. Nếu bộ dữ liệu thử được tìm thấy không chất lượng liên quan đến tiêu chuẩn (tức là không phải tất cả các câu lệnh đều được thực hiện ít nhất một lần), thì kiểm thử nữa là bắt buộc. Do đó, mục tiêu là tạo ra một tập các kiểm thử thực hiện đầy đủ tiêu chuẩn chất lượng. Tiêu chuẩn chất lượng tiêu biểu như bao phủ câu lệnh và kiểm thử quyết định (thực hiện tất cả các đường dẫn đúng và sai qua chương trình) dựa vào việc thực hiện chương trình với số lượng kiểm thử tăng dần để nâng cao độ tin cậy của chương trình đó. Tuy nhiên, chúng không tập trung vào nguyên nhân thất bại của chương trình - được gọi là lỗi. Kiểm thử đột biến là một tiêu chuẩn như vậy. Tiêu chuẩn này tạo ra các phiên bản của chương trình có chứa các lỗi đơn giản và sau đó tìm ra các kiểm thử để chỉ ra các dấu hiệu của lỗi. Nếu có thể tìm thấy một bộ dữ liệu thử chất lượng làm lộ ra các dấu hiệu này ở tất cả các phiên bản bị lỗi, thì sự tin tưởng vào tính đúng đắn của chương trình sẽ tăng. Kiểm thử đột biến đã được áp dụng cho nhiều ngôn ngữ lập trình như là một kỹ thuật kiểm thử hộp trắng. Ý thức được đây là một lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng trong phát triển phần mềm, tôi đã chọn hướng nghiên cứu “ Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C” cho đề tài luận văn của mình. Luận văn được tổ chức thành 4 chương như sau:  Chương 1 – Trình bày khái quát về kiểm thử phần mềm như khái niệm kiểm thử phần mềm, mục đích, mục tiêu và các mức kiểm thử phần mềm. Chương này cũng đề cập đến việc sử dụng các kỹ thuật kiểm thử hộp trắng và hộp đen để thiết kế dữ liệu thử. 7
 Chương 2 - Mô tả chi tiết các thành phần chính của kỹ thuật kiểm thử đột biến, giới thiệu các giả thuyết cơ bản cần thiết để thực hiện phương pháp này. Chương này còn cung cấp quy trình để phân tích đột biến, từ đó rút ra được những vấn đề còn hạn chế đối với kỹ thuật kiểm thử đột biến, được cải tiến ở chương 3.  Chương 3 – Giới thiệu một số phương pháp cải tiến kỹ thuật kiểm thử đột biến nhằm giảm chi phí tính toán và tăng tự động hóa.  Chương 4 – Tập trung vào ứng dụng kỹ thuật kiểm thử đột biến. Phần đầu giới thiệu hai công cụ mã nguồn mở miễn phí là NUnit dùng để kiểm thử đơn vị của chương trình C#, và Nester với chức năng phân tích và tạo đột biến. Tiếp đó là ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử các chương trình C# sử dụng hai công cụ trên. 8
CHƯƠNG 1 – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 1.1. Khái niệm Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không. 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, tìm một cách sớm nhất và bảo đảm rằng lỗi sẽ được sửa. Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức và chi phí. 1.2. Các cấp độ kiểm thử phần mềm Cấp độ kiểm thử phần mềm được thể hiện ở hình 1.1 [25]: Kiểm thử mức đơn vị lập trình Các bộ phận (Unit test) đơn lẻ Kiểm thử mức tích hợp các đơn vị Các nhóm (Integration test) bộ phận Kiểm thử mức hệ Toàn bộ thống, sau khi tích hợp hệ thống (System test) Kiểm thử để chấp nhận sản phẩm Toàn bộ hệ thống (Acceptance test) nhìn từ khách hàng Hình 1.1- Bốn cấp độ cơ bản của kiểm thử phần mềm 9
1.2.1. Kiểm thử đơn vị (Unit Test) Một đơn vị (Unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được, ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method). 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 trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và kết xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng xử lý của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Cũng như các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử (hay trường hợp kiểm thử) (test case) hoặc kịch bản (test script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong muốn sẽ xuất ra. Các test case và test script được giữ lại để sử dụng sau này. 1.2.2. Kiểm thử tích hợp (Integration Test) 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 ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị kiểm tra các thành phần và Unit riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Kiểm thử tích hợp có hai mục tiêu chính là:  Phát hiện lỗi giao tiếp xảy ra giữa các Unit  Tích hợp các Unit đơn lẻ thành các hệ thống con (gọi là subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống (system test). Có 4 loại kiểm thử trong kiểm thử tích hợp như sau: 10
 Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình, chẳng hạn các lệnh và nhánh bên trong.  Kiểm thử chức năng (Functional test): Kiểm thử chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.  Kiểm thử hiệu năng (Performance test): Kiểm thử việc vận hành của hệ thống.  Kiểm thử khả năng chịu tải (Stress test): Kiểm thử các giới hạn của hệ thống. 1.2.3. Kiểm thử hệ thống (System Test) Mục đích của kiểm thử hệ thống là kiểm thử xem 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 kiểm tra cả các hành vi chức năng của phần mềm lẫn 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. 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. Thông thườ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 mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, 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, nhưng 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 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 trên 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. Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm 11
thử tích hợp để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử hệ thống. Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên (Tester) bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, kiểm thử hệ thống được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án để đảm bảo tính chính xác và khách quan. Kiểm thử hệ thống thường có các loại kiểm thử sau:  Kiểm thử chức năng (Functional test): 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 (Performance test): 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 (Stress test hay Load test): 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). Stress test 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 như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong test thiết bị như POS, ATM),....  Kiểm thử cấu hình (Configuration test): Đảm bảo hệ thống hoạt động tương thích với các loại phần cứng khác nhau.  Kiểm thử khả năng bảo mật (Security test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.  Kiểm thử khả năng phục hồi (Recovery test): 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 12
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. 1.2.4. Kiểm thử chấp nhận sản phẩm (Acceptance Test) Mục đích của kiểm thử chấp nhận là kiểm thử khả năng chấp nhận cuối cùng để chắc chắn rằng sản phẩm là phù hợp và thỏa mãn các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm. Trong giai đoạn kiểm thử chấp nhận thì người kiểm tra là khách hàng. Khách hàng sẽ đánh giá phần mềm với mong đợi theo những thao tác sử dụng quen thuộc của họ. Việc kiểm tra ở giai đoạn này có ý nghĩa hết sức quan trọng tránh cho việc hiểu sai yêu cầu cũng như sự mong đợi 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 tra chặt chẽ. 1.3. Kỹ thuật kiểm thử phần mềm Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử có khả năng cao nhất trong việc phát hiện nhiều lỗi với thời gian và công sức tối thiểu. Do đó có thể chia các kỹ thuật kiểm thử thành hai loại:  Kỹ thuật kiểm thử hộp đen (Black – box Testing) hay còn gọi là kỹ thuật kiểm thử chức năng (Functional Testing).  Kỹ thuật kiểm thử hộp trắng (White – box Testing) hay còn gọi là kỹ thuật kiểm thử cấu trúc (Structural Testing). 1.3.1. Kỹ thuật kiểm thử hộp đen (Black – box Testing) Kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data - driven) hay là kiểm thử hướng vào/ra (input/output driven). Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen. Người kiểm thử hoàn toàn không quan tâm đến cấu trúc và hành vi bên trong 13
của chương trình. Người kiểm thử chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó. Do đó, dữ liệu kiểm thử sẽ xuất phát từ đặc tả. Như vậy, cách tiếp cận kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm. Kiểm thử hộp đen cho phép người kiểm thử xây dựng các nhóm giá trị đầu vào sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình. Kiểm thử hộp đen không thay thế kỹ thuật kiểm thử hộp trắng, nhưng nó bổ sung khả năng phát hiện các lớp lỗi khác với các phương pháp hộp trắng. Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:  Các chức năng thiếu hoặc không đúng.  Các lỗi giao diện.  Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài.  Các lỗi thực hiện.  Các lỗi khởi tạo hoặc kết thúc.  Và các lỗi khác ... Không giống với kiểm thử hộp trắng được thực hiện sớm trong quá trình kiểm thử, kiểm thử hộp đen được áp dụng trong các giai đoạn sau của kiểm thử. Vì kiểm thử hộp đen không để ý có chủ đích cấu trúc điều khiển, sự quan tâm tập trung trên miền thông tin. Nếu người kiểm thử muốn sử dụng phương pháp này để tìm tất cả các lỗi trong chương trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử. Bởi vì nếu chỉ kiểm thử một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi. Vì thế, để đạt được mục tiêu kiểm thử, người ta đã áp dụng một số phương pháp kiểm thử hộp đen như: phân hoạch tương đương, phân tích giá trị biên. 14
1.3.1.1. Phân hoạch tương đương Do việc kiểm thử tất cả các đầu vào của chương trình là không thể. Vì thế, khi kiểm thử chương trình nên giới hạn một tập con tất cả các trường hợp đầu vào có thể có, sao cho có xác suất tìm ra được nhiều lỗi nhất. Một tập con như vậy cần có hai tính chất sau:  Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết.  Cố gắng phân hoạch các miền đầu vào của một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử với một giá trị bất kỳ trong cùng lớp. Thiết kế các trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theo hai bước: Phân hoạch các miền đầu vào/ra thành các lớp tương đương, và thiết kế các trường hợp kiểm thử đại diện cho mỗi lớp. a) Xác định các lớp tương đương Các lớp tương đương được nhận dạng bằng cách lấy mỗi điều kiện đầu vào (thông thường là một câu lệnh hoặc một cụm từ trong đặc tả) và phân hoạch nó thành hai hay nhiều nhóm. Các lớp tương đương bao gồm một tập các trạng thái hợp lệ hoặc không hợp lệ cho điều kiện đầu vào. Điều kiện đầu vào là giá trị số xác định, hoặc là miền giá trị, tập giá trị có liên quan, hoặc điều kiện logic. Để làm điều này, chúng ta sử dụng bảng liệt kê các lớp tương đương. Các lớp tương đương có thể được định nghĩa theo nguyên tắc sau: 1. Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân hoạch thành một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ. Chẳng hạn, nếu đầu vào x nằm trong khoảng [1,999], lớp hợp lệ là: 1 999. 15
2. Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ. Chẳng hạn, nếu đầu vào x = 3, thì lớp hợp lệ là x = 3, các lớp không hợp lệ là x < 3 và x > 3. 3. Nếu điều kiện đầu vào xác định một phần tử của tập hợp, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ. 4. Nếu điều kiện đầu vào là Boolean, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ tương ứng với hai trạng thái true và false. Ngoài ra, một nguyên tắc thứ năm được bổ sung là sử dụng khả năng phán đoán, kinh nghiệm và trực giác của người kiểm thử. Điều kiện vào/ra Các lớp tương đương Các lớp tương đương hợp lệ không hợp lệ Số ID của sinh viên Các thuộc tính khóa Không phải thuộc tính khóa Ký tự chữ cái Không phải chữ cái Tên sinh viên Không rỗng Rỗng Không phải chữ cái Giới tính sinh viên Ký tự chữ cái, “M’ hoặc “F” Không phải “M” hoặc “F” Không phải số Số Điểm của sinh viên Số nhỏ hơn 0 Từ 0 đến 100 Số lớn hơn 100 Bảng 1.1 – Ví dụ các lớp tương đương b) Xác định các trường hợp kiểm thử Kế tiếp trong phân hoạch tương đương là thiết kế các trường hợp kiểm thử dựa trên sự ước lượng của các lớp tương đương cho miền đầu vào. Tiến trình này được thực hiện như sau: 1. Gán một giá trị duy nhất cho mỗi lớp tương đương 16
2. Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường hợp kiểm thử thì viết một trường hợp kiểm thử mới phủ nhiều nhất có thể các lớp tương đương hợp lệ chưa được phủ. 3. Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho mỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương không hợp lệ chưa được phủ. 1.3.1.2. Phân tích giá trị biên Khi thực hiện kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý chính xác hay không. Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của lớp tương đương đầu vào và lớp đương đương đầu ra. Việc phân tích các giá trị biên khác với phân hoạch tương đương theo hai điểm:  Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử. Như vậy, mỗi biên của lớp tương đương chính là đích kiểm thử.  Không chỉ chú ý tập trung những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức là các lớp tương đương đầu ra). Có một số nguyên tắc phân tích giá trị biên như sau: 1. Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường hợp kiểm thử sẽ được thiết kế với giá trị a và b, các giá trị sát trên và sát dưới a và b. 2. Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực 17
tiểu. Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng được kiểm thử. 3. Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra. 4. Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó. Ngoài ra, người kiểm thử có thể sử dụng sự suy đoán và sáng tạo của mình để tìm các điều kiện biên. Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía. Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua các kiểm thử khác từ lớp đó. 1.3.2. Kỹ thuật kiểm thử hộp trắng (White – box Testing) Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục đích bảo đảm rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần. Người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử. 1.3.2.1. Kiểm thử đường dẫn cơ sở Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất. Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện. Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở. Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử. a) Đồ thị luồng điều khiển 18
Trong thực tế, phương pháp đường dẫn cơ sở có thể được dùng không cần sử dụng đồ thị luồng điều khiển. Tuy nhiên, đồ thị luồng điều khiển (minh họa ở hình 1.2) là một công cụ hữu ích để hiểu các luồng điều khiển và minh họa cho phương pháp này. Cấu trúc của đồ thị luồng điều khiển bao gồm:  Mỗi đỉnh (hình tròn) biểu thị một đoạn các câu lệnh thực hiện một cách tuần tự, có thể kết thúc bằng một lệnh rẽ nhánh.  Mỗi cạnh (cung) biểu diễn dòng điều khiển nối hai nút với nhau.  Phần được bao bởi các cung và các đỉnh gọi là miền. Đỉnh điều kiện Miền Cung Hình 1.2 - Đồ thị luồng điều khiển b) Độ phức tạp chu trình Độ phức tạp chu trình là một thước đo phần mềm, cung cấp các phép đo định lượng độ phức tạp của chương trình. Khi được sử dụng trong ngữ cảnh của phương pháp đường dẫn cơ sở, giá trị được xác định cho độ phức tạp chu trình cho biết số lượng đường dẫn độc lập trong một tập cơ sở của chương trình và cung cấp cho chúng ta một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo rằng tất cả các câu lệnh được thực hiện ít nhất một lần. 19
Việc tính toán độ phức tạp chu trình sẽ cho chúng ta biết có bao nhiêu đường dẫn cần tìm. Cho đồ thị luồng điều khiển G, độ phức tạp chu trình V(G) được tính theo một trong 3 công thức sau: 1. V(G) = R, trong đó R là số miền của đồ thị G. 2. V(G) = P + 1, trong đó P là số đỉnh điều kiện có trong đồ thị G. 3. V(G) = E – N + 2, trong đó E là số cung và N là số đỉnh của đồ thị G. Đối chiếu với đồ thị luồng điều khiển trong hình 1.2, độ phức tạp chu trình V(G) được tính như sau: 1. Công thức 1: V(G) = R = 6 2. Công thức 2: V(G) = P + 1 = 5 + 1 = 6 3. Công thức 3: V(G) = E – N + 2 = 15 – 11 + 2 = 6 Như vậy, độ phức tạp chu trình của đồ thị luồng điều khiển ở hình 1.2 là 6. c) Phát sinh các trường hợp kiểm thử theo đường dẫn cơ sở Phương pháp kiểm thử đường dẫn cơ sở có thể áp dụng để kiểm thử thủ tục chi tiết hoặc cho mã nguồn bao gồm các bước sau:  Bước 1: Sử dụng mã nguồn hoặc thiết kế để xây dựng đồ thị luồng điều khiển tương ứng.  Bước 2: Tính toán độ phức tạp chu trình V(G) .  Bước 3: Xác định tập cơ sở của các đường dẫn độc lập (một đường dẫn được gọi là độc lập với các đường dẫn khác nếu nó có ít nhất một cạnh không xuất hiện trong các đường dẫn khác).  Bước 4: Chuẩn bị các trường hợp kiểm thử có khả năng thực hiện mỗi đường dẫn trong tập cơ sở. Chúng ta dùng hàm tính giá trị trung bình cộng của các số, average trong C như hình 1.3 để làm ví dụ minh họa cho mỗi bước thiết kế các trường hợp kiểm thử. Hàm average là một thuật toán đơn giản có chứa các tổ hợp và vòng lặp, trong đó chương trình tính giá trị trung bình của 100 hoặc một vài 20