Kỹ thuật kiểm thử đột biến và ứng dụng để kiểm thử các chương trình java

Trong các bước này, bước tạo dữ liệu thử đóng vai trò quan trọngnhấ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

ĐINH THỊ MỸ CẢNH

KỸ THUẬT KIỂM THỬ ĐỘT BIẾN

VÀ ỨNG DỤNG ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH JAVA

MỤC LỤC

CÁC THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT

DANH SÁCH CÁC HÌNH

DANH SÁCH CÁC BẢNG

MỞ ĐẦU

CHƯƠNG 1 - TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1.Kiểm thử phần mềm là gì?

1.2.Các mức kiểm thử phần mềm

1.2.1 Kiểm thử đơn vị

1.2.2 Kiểm thử tích hợp

1.2.3 Kiểm thử hệ thống

1.2.4 Kiểm thử chấp nhận

1.3.Thiết kế trường hợp kiểm thử

1.3.1 Kỹ thuật kiểm thử hộp trắng

1.3.1.1 Kiểm thử đường dẫn cơ sở

1.3.1.2 Kiểm thử cấu trúc điều khiển

1.3.2 Kỹ thuật kiểm thử hộp đen

1.3.2.1 Phân hoạch tương đương

1.3.2.2 Phân tích giá trị biên

1.4.Kết luận

CHƯƠNG 2 – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN

2.1.Giới thiệu

2.2.Khái niệm kiểm thử đột biến

2.3.Cơ sở của kiểm thử đột biến

2.4.Toán tử đột biến

2.5.Quy trình kiểm thử đột biến

2.6.Một số vấn đề của kiểm thử đột biến

2.7.Kết luận

CHƯƠNG 3 - CÁC CẢI TIẾN KỸ THUẬT KIỂM THỬ ĐỘT BIẾN

3.1.Giảm chi phí tính toán

3.1.1 Làm ít hơn

3.1.1.1 Lấy mẫu đột biến

3.1.1.2 Đột biến ràng buộc

3.1.1.3 N - đột biến lựa chọn

3.1.2 Làm nhanh hơn

3.1.2.1 Phương pháp tạo lược đồ đột biến

3.1.3 Làm thông minh hơn

3.1.3.1 Đột biến yếu

3.2 Tăng tự động hóa

3.2.1 Tạo dữ liệu thử tự động

3.2.2 Xác định các đột biến tương đương tự động

3.2.3 Vấn đề Oracle

3.3 Kết luận

CHƯƠNG 4 - ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH JAVA

4.1 Công cụ MuJava

4.1.1 Mô tả công cụ MuJava

4.1.2 Các toán tử đột biến cho MuJava

4.1.2.1 Các toán tử đột biến mức phương thức

4.1.2.2 Các toán tử đột biến mức lớp

4.1.3 Phương pháp thực thi của MuJava

4.2 Công cụ Junit

4.3 Quy trình ứng dụng kiểm thử đột biến để kiểm thử các chương trình Java

4.4 Ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình SXQSort.java

4.4.1 Đặc tả của chương trình sắp xếp dãy số tăng dần

4.2.2 Thuật toán của chương trình SXQSort.java

4.2.3 Thiết kế các trường hợp kiểm thử cho chương trình SXQSort.java

4.2.3.1 Thiết kế các trường hợp kiểm thử cho module FindPivot

4.2.3.2 Thiết kế các trường hợp kiểm thử cho Module Partition

4.2.3.3 Thiết kế các trường hợp kiểm thử cho Module QuickSort

4.4.4 Kiểm thử chương trình SXQSort.java với JUnit

4.4.5 Tạo và phân tích đột biến cho chương trình SXQSort.java bằng MuJava

4.4.5.1 Tạo các đột biến

4.4.5.2 Phân tích đột biến

KẾT LUẬN

TÀI LIỆU THAM KHẢO

CÁC THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT

Viết tắt

ABSACRAORAORBAORSASRBCELCBTCORCSRDUJIDJSIJTILCRMSGPUTRORSCRSRC

UOI

DANH SÁCH CÁC HÌNH

Số

đường dẫn cơ sở

thử diệt đột biến yếu và mạnh

Hình 4.10 Giao diện tạo đột biến cho SXQSort.java

DANH SÁCH CÁC BẢNG

Số

Bảng 1.1Bảng 2.1Bảng 4.1Bảng 4.2Bảng 4.3Bảng 4.4Bảng 4.5

Bảng 4.6

Bảng 4.7

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 đảmchấ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ảnxuấ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ìnhbắ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ànhcô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ệukiể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ểmthử 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ôngtin, 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ạocon 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ộtphầ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ácbướ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 thử đóng vai trò quan trọngnhấ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á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ệubao phủ chương trình Ví dụ, tiêu chuẩn bao phủ dòng lệnh đòi hỏi bộ dữ liệuthử 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ệuthử đượ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ảitấ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ắtbuộ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ẩnchấ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ệcthực hiện chương trình với số lượng kiểm thử tăng dần để nâng cao độ tin cậycủ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 [7] là một tiêu chuẩnnhư 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ácphiê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 [8] như làmột kỹ thuật kiểm thử hộp trắng Chẳng hạn, các chương trình Fortran, Ada, C,Java, C#, SQL, … Bên cạnh việc sử dụng kiểm thử đột biến ở mức thực thiphầ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 Ví dụ, ở mức thiết kế, kiểm thử độtbiến được áp dụng cho các máy trạng thái xác định (FSM), các biểu đồ trạng thái(State Charts), các giao thức mạng (Network Protocols), các chính sách bảo mật(Security Policies), các dịch vụ web (Web Services), …

Ý 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 Kỹ thuật kiểm thử đột biến cho đề tài luận văn của mình Luận văn được xây dựng dựa trên nền các

nghiên cứu đã có trong lĩnh vực kiểm thử phần mềm kể từ năm 1978, mà gầnđây nhất là các nghiên cứu về kỹ thuật kiểm thử đột biến vào năm 2009 củaTS.Nguyễn Thanh Bình – Đại học Bách khoa, Đại học Đà Nẵng [2] Đồng thời,tôi xin đề xuất một “quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thửcác chương trình Java”

Luận văn được tổ chức thành 4 chương như sau:

 Chương 1 – Trình bày tổng quan 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ểmthử hộp trắng và hộp đen để thiết kế dữ liệu thử

 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 độtbiế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 các 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í MuJava với chức

năng phân tích và tạo đột biến, và JUnit dùng để kiểm thử đơn vị củachương trình Java Đồng thời, đề xuất quy trình ứng dụng kỹ thuật kiểm thửđột biến để kiểm thử các chương trình Java sử dụng hai công cụ trên Cụthể, kiểm thử chương trình sắp xếp dãy số tăng dần theo thuật toánQuickSort viết bằng ngôn ngữ Java, từ đó, tập trung phân tích và đánh giáchất lượng của các bộ dữ liệu thử dùng để kiểm thử chương trình này.

có đúng với đặc tả không và thực hiện trong môi trường như mong đợi haykhông [19].

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ìmmột cách sớm nhất và bảo đảm rằng lỗi đã được sửa, kiểm thử phần mềm khônglàm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi.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 mức kiểm thử phần mềm

Chiến lược kiểm thử tổng thể một hệ thống [3] được sử dụng rộng rãi nhấthiện nay là chiến lược từ mức thấp đến mức cao, bao gồm bốn mức như đượcthể hiện ở hình 1.1:

Kiểm thử mức

đơn vị lập trình

(Unit test)

Các bộ phận đơn lẻ

1.2.1 Kiểm thử đơn vị

Một đơn vị (Unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểmthử được.Ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc cácphươ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

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 tình huống (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 testcase và test script được dữ lại để sử dụng sau này

1.2.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 ứng dụng đã hoàn thành Trong khi kiểm thử đơn vị kiểm tra các thànhphầ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ểmtra 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 ragiữa các Unit và 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:

 Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm các thànhphầ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 đếnchứ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

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ệcphâ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ùnglú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áctình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiệnnhiề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 tàinguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịchnhư ngân hàng trực tuyến

1.2.4 Kiểm thử chấp nhận

Mục đích của kiểm thử chấp nhận là kiểm thử khả năng chấp nhận cuốicù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áchhà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 Họ

sẽ đánh giá phần mềm với mong đợi của họ, theo những thao tác sử dụng quenthuộc của họ Việc kiểm tra ở giai đoạn này tránh cho việc hiểu sai yêu cầu cũngnhư 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àiliệu đi kèm phải được cập nhật và kiểm tra chặt chẽ

1.3 Thiết kế trường hợp kiểm thử

Thiết kế kiểm thử phần mềm có thể là một quá trình thu thập, phân tích vàthực hiện yêu cầu Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểmthử có khả năng cao nhất trong việc phát hiện nhiều lỗi nhất với thời gian vàcông sức tối thiểu Như vậy, vấn đề quan trọng nhất trong kiểm thử phần mềm làthiết kế và tạo ra các trường hợp kiểm thử có hiệu quả [19] Lý do về tầm quantrọng của việc thiết kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử

“vét cạn” là điều không thể, và như vậy, kiểm thử một chương trình phải luônxác định là không thể vét cạn Vấn đề quan trọng là cố gắng làm giảm sự “khôngthể vét cạn” nhiều nhất có thể

Kiểm thử phần mềm còn có các ràng buộc về thời gian và chi phí,…Chìa

khóa của kiểm thử là trả lời của câu hỏi: “Tập con của tất cả các trường hợp kiểm thử có thể có xác suất phát hiện lỗi cao nhất là gì? ” Việc nghiên cứu các

phương pháp thiết kế trường hợp kiểm thử sẽ cung cấp câu trả lời cho câu hỏinày

Bất kỳ sản phẩm công nghệ nào cũng có thể được kiểm thử theo hai cách:

 Viết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực hiện

 Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực hiện để đảm bảo rằng “tất cả các thành phần ăn khớp với nhau”.Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cách thứ hai là kiểm thử hộp trắng [19]

1.3.1 Kỹ thuật kiểm thử hộp trắng

Kiểm thử hộp trắng cho phép kiểm tra cấu trúc bên trong của phần mềm vớimụ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ấtmột lần Người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểmtra nó, lấy đó làm cơ sở để hổ trợ việc kiểm thử

1.3.1.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 TomMcCabe [3] đề 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 đườngdẫ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ươngtrình ít nhất một lần trong quá trình kiểm thử

a) Đồ thị luồng điều khiển

Đồ thị luồng điều khiển (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 kiểm thử đường dẫn cơ sở Cấu trúccủ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ạch (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ủaphương pháp đường dẫn cơ sở, giá trị được xác định cho độ phức tạp chu trìnhcho 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ảorằng tất cả các câu lệnh được thực hiện ít nhất một lần

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ìnhV(G) đuwọ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ụcchi 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.

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 số trong mảng

values nằm trong khoảng của biên trên (max) và biên dưới (min) Đầu vào được

6

Hình 1.3 – Ví dụ minh họa phát sinh các trường hợp kiểm thử

theo đường dẫn cơ sở

Bước 1: Vẽ đồ thị luồng điều khiển (như hình 1.3)

Bước 2: Tính độ phức tạp chu trình V(G)

V(G) = P (số đỉnh điều kiện) + 1 = 5 + 1 = 6(Hình 1.3 có 5 đỉnh điều kiện: 2, 3, 4, 5, 8)

Bước 3: Tìm tập cơ sở của các đường dẫn độc lập

 Trường hợp kiểm thử đường dẫn 1

Đầu vào: Values = {3, 5, 11, -999}, min = 0, max = 100

Đầu ra mong muốn: Average = (3 + 5 + 11) / 3

Mục đích: Để kiểm thử việc tính giá trị trung bình chính xác

Lưu ý: Đường dẫn 1 không thể kiểm thử một mình, mà phải được kiểm thử như là một phần của các kiểm thử đường dẫn 4, 5, và 6

 Trường hợp kiểm thử đường dẫn 2

Đầu vào: Values = {-999}, min = 0, max = 0

Đầu ra mong muốn: Average = -999

Mục đích: Để tạo ra Average = -999

 Trường hợp kiểm thử đường dẫn 3

Đầu vào: Values = {2, 6, 7, …, 120} (101 số), min = 0, max = 100

Đầu ra mong muốn: Trung bình của 100 số đầu tiên

Mục đích: Chỉ tính trung bình cho 100 số hợp lệ đầu tiên

 Trường hợp kiểm thử đường dẫn 4

Đầu vào: Values = {67, -2, 12, 23, -999}, min = 0, max = 100

Đầu ra mong muốn: Average = (67 + 12 + 23) / 3

Mục đích: Kiểm thử biên dưới (Values[i] > min, i < 100)

 Trường hợp kiểm thử đường dẫn 5

Đầu vào: Values = {7, 32, 102, 23, 68, 2, -999}, min = 0, max = 100

Đầu ra mong muốn: Average = (7 + 32 + 23 + 68 + 2) / 5

Mục đích: Kiểm thử biên trên (Values[i] < max, i < 100)

 Trường hợp kiểm thử đường dẫn 6

Đầu vào: Values = {3, 4, 12, 15, 16, 2, -999}, min = 0, max = 100

Đầu ra mong muốn: Average = (3 + 4 + 12 + 15 + 16 + 2) / 6

Mục đích: Việc tính giá trị trung bình là đúng

Phương pháp đường dẫn cơ sở tập trung trên “giá trị đại diện” của mỗiđường dẫn độc lập Cần có các trường hợp kiểm thử bổ sung (ngoài các trườnghợp kiểm thử đường dẫn cơ sở), nhất là để thực hiện các điều kiện biên

1.3.1.2 Kiểm thử cấu trúc điều khiển

Phương pháp kiểm thử đường dẫn cơ sở là phương pháp kiểm thử đơn giản

và hiệu quả nhưng nó vẫn chưa đủ Chúng ta sẽ xem xét các biến thể trên kiểmthử cấu trúc điều khiển mà phủ kiểm thử mở rộng và hoàn thiện chất lượng củaphương pháp kiểm thử hộp trắng

a) Kiểm thử điều kiện

Kiểm thử điều kiện là phương pháp thiết kế trường hợp kiểm thử thực thicác điều kiện logic trong module chương trình Mục đích là để xác định các lỗiđiều kiện và cả các lỗi khác trong chương trình Một số phương pháp kiểm thửđiều kiện như sau:

 Kiểm thử nhánh (Branch Testing): Là phương pháp kiểm thử

điều kiện đơn giản nhất Thiết kế các trường hợp kiểm thử sao cho vớimỗi điều kiện rẽ nhánh phức hợp C, các nhánh true và false của C vàmỗi điều kiện đơn giản trong C cần phải được thực thi ít nhất một lần

 Kiểm thử miền (Domain Testing): Cần 3 hoặc 4 trường hợp

kiểm thử cho biểu thức quan hệ Với một biểu thức quan hệ có dạng E1

<op> E2, cần có 3 trường hợp kiểm thử được thiết kế cho E1 == E2, E1

> E2, E1 < E2

b) Kiểm thử luồng dữ liệu

Phương pháp kiểm thử luồng dữ liệu lựa chọn các đường dẫn kiểm thử củachương trình dựa vào vị trí khai báo và sử dụng các biến trong chương trình Vớikiểm thử luồng dữ liệu, mỗi câu lệnh trong chương trình được gán số hiệu lệnhduy nhất và mỗi hàm không thay đổi tham số của nó và biến toàn cục Cho mộtlệnh với S là số hiệu câu lệnh Ta định nghĩa:

DEF(S) = là tập các biến được khai báo trong S

USE(S) = là tập các biến được sử dụng trong S

Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗi

DU được phủ ít nhất một lần Chiến lược này được gọi là chiến lược kiểm thử

DU [3] Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của một chươngtrình Tuy nhiên, một nhánh không đảm bảo được phủ bởi kiểm thử DU chỉ

trong rất ít tình huống như cấu trúc if – then – else mà trong đó phần then không

có một khai báo biến nào và có dạng khuyết (không tồn tại phần else) Trong tình huống đó, nhánh else của lệnh if là không cần thiết phải phủ bằng kiểm thử

DU

Trong đó n là số lần lặp tối đa của vòng lặp.

 Các bước cần kiểm tra cho vòng lặp lồng nhau

+ Khởi đầu với vòng lặp nằm bên trong nhất Thiết lập các tham

số lặp cho các vòng lặp bên ngoài về giá trị nhỏ nhất

+ Kiểm tra với tham số min + 1, 1 giá trị tiêu biểu, max - 1 vàmax cho vòng lặp bên trong nhất trong khi các tham số lặp của cácvòng lặp bên ngoài là nhỏ nhất

+ Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất cả vòng lặp bên ngoài được kiểm tra

 Các bước cần kiểm tra cho vòng lặp nối tiếp

Nếu các vòng lặp là độc lập với nhau thì kiểm tra như trường hợp cácvòng lặp dạng đơn giản, nếu không thì kiểm tra như trường hợp các vòng lặplồng nhau.

 Các bước cần kiểm tra cho vòng lặp phi cấu trúc

Nếu gặp các lớp vòng lặp này chúng ta sẽ không kiểm thử, mà sẽ thiết kếlại tương ứng với sử dụng việc xây dựng chương trình có cấu trúc

1.3.2 Kỹ thuật kiểm thử hộp đen

Kiểm thử hộp đen [19] 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 trongcủa phần mềm 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ứcnă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ácnhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng củachươ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ộptrắ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

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ườnghợ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 đảmbả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.

1.3.2.1 Phân hoạch tương đương

Như đã trình bày, 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áctrườ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

 Nên cố gắng phân hoạch các miền đầu vào của một chương trìnhthà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 đươngvớ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áihợ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ânhoạch thành một lớp tương đương hợp lệ và hai lớp tương đương khônghợ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 <= x <= 999, các lớp không hợp lệ là x < 1 và x > 999

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ànhmộ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ônghợp lệ

4.Nếu điều kiện đầu vào là Boolean, thì phân hoạch thành một lớptương đương hợp lệ và một lớp tương đương không hợp lệ tương ứngvớ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ử

Các lớp tương đương Điều kiện vào/ra

hợp lệ

Số ID của sinh viên Các thuộc tính khóa

Ký tự chữ cáiTên sinh viên

Không rỗng

Ký tự chữ cáiGiới tính sinh viên

“M” hoặc “F”

SốĐiểm của sinh viên

1.Gán một giá trị duy nhất cho mỗi lớp tương đương

2.Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trườnghợ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áctrường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao chomỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đươngkhông hợp lệ chưa được phủ.

1.3.2.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 đầuvà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ácvớ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ụngmộ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ợpkiể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ớptươ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áctrường hợp kiểm thử sẽ được thiết kế với giá trị a và b, các giá trị sáttrê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ợpkiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực 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.4 Kết luận

Trên đây là tổng quan về các mức và loại kiểm thử phần mềm cơ bản Kiểmthử hộp trắng xem xét chương trình ở mức độ chi tiết và phù hợp khi kiểm tracác môđun nhỏ Tuy nhiên, kiểm thử hộp trắng có thể không đầy đủ vì kiểm thửhết các lệnh không chứng tỏ là chúng ta đã kiểm thử hết các trường hợp có thể.Ngoài ra chúng ta không thể kiểm thử hết các đường đi đối với các vòng lặp lớn.Kiểm thử hộp đen chú trọng vào việc kiểm tra các quan hê ̣vào ra vànhững chức năng giao diêṇ bên ngoài , nó thích hợp hơn cho các hê ̣thống phần mềm lớn hay các thành phần quan trong ̣ của chúng Nhưng chỉ sử dụng kiểm thử hộp đen là chưa đủ Bởi vì, kiểm thử hộp đen chỉ dựa trên đặc tả của môđun nên không thể kiểm thử được các trường hợp không được khai báo trong đặc tả Ngoài ra, do không phân tích mã nguồn nên không thể biết được môđun nào củachương trình đã hay chưa được kiểm thử, khi đó phải kiểm thử lại hay bỏ qua những lỗi tiềm ẩn trong gói phần mềm

Phương pháp kiểm thử hộp trắng và kiểm thử hộp đen là hai phương pháp

cơ bản có vai trò rất quan trọng trong quá trình phát triển phần mềm, nếu chúng

ta biết kết hợp chúng để bổ sung khiếm khuyết lẫn nhau

CHƯƠNG 2 – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN

2.1 Giới thiệu

Hiệu quả của các dữ liệu thử khi chỉ ra được các lỗi của chương trình là rấtquan trọng đối với kiểm thử phần mềm Một dữ liệu thử được xem là “tốt” theonghĩa nó có khả năng phát hiện ra lỗi cụ thể mà các dữ liệu thử khác không pháthiện ra Ngược lại, một dữ liệu thử được xem là “nghèo” theo nghĩa nó không cókhả năng phát hiện một lỗi nào cả, nhưng rất khó để xác định được bởi vì chúng

ta không biết chương trình có lỗi hay không Trong cả hai trường hợp, chúng takhông có cách nào để đo được hiệu quả của dữ liệu thử Điều quan trọng là phảibiết liệu có tồn tại lỗi để kiểm thử hay không, nhưng nếu biết được điều này thìkiểm thử là dư thừa [18] Để gỡ bỏ nghịch lý này, người ta sử dụng các tiêuchuẩn để cung cấp các yêu cầu cho chất lượng dữ liệu thử, và vì vậy, mang lạimột thước đo để đánh giá và cải tiến bộ dữ liệu thử Ví dụ, các bộ dữ liệu thửđược cải tiến lặp đi lặp lại cho đến khi chúng thực hiện tất cả các câu lệnh trong

chương trình (kiểm thử câu lệnh), hoặc thực hiện tất cả các quyết định nhánh cả hai trường hợp đúng và sai (kiểm thử nhánh) Nếu phù hợp với tiêu chuẩn được xem xét thì dữ liệu thử được gọi là có chất lượng (đối với tiêu chuẩn đó), và do

đó, có nhiều khả năng hơn để chỉ ra các lỗi nếu chúng tồn tại

Tuy nhiên, các tiêu chuẩn thườ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à các lỗi; tiêu chuẩn chất lượng đột biến là một loại

tiêu chuẩn như vậy Nó cung cấp một thước đo để đánh giá tính hiệu quả của dữliệu thử bằng cách cho thấy các dữ liệu thử có thể làm lộ ra tất cả các lỗi đơngiản có thể có của một chương trình (ví dụ, sự khác biệt một từ đơn hoặc thay thếtên biến sai), tương tự như kiểm thử câu lệnh cho thấy tính hiệu quả của dữ liệuthử bằng cách đảm bảo rằng mọi dòng lệnh đã được thực hiện Tuy nhiên, bộ dữliệu thử có khả năng sẽ không thể xác định được tất cả các lỗi Trong trường hợpnhư vậy, tiêu chuẩn chất lượng đột biến cung cấp một thước đo để xác định việccải tiến bằng cách lựa chọn một bộ dữ liệu thử mới Ví dụ, một bộ dữ liệu thửphát hiện 80% lỗi sẽ cho phép tạo ra dữ liệu thử tập trung vào 20% còn lại.Thước đo này cho phép kiểm soát, đánh giá và cải tiến dữ liệu thử lặp đi lặp lại

dựa trên cơ sở kiểm thử đột biến (mutation testing) [7].

2.2 Khái niệm kiểm thử đột biến

Kiểm thử đột biến được đề xuất đầu tiên vào năm 1979 bởi DeMillo vàđồng nghiệp [7] Nó cung cấp một phương tiện để đánh giá và cải tiến chấtlượng dữ liệu thử cho chương trình được kiểm thử (PUT)

Kiểm thử đột biến bao gồm việc chèn các lỗi vào trong PUT để tạo ra cácphiên bản lỗi của chương trình, mỗi phiên bản chỉ chứa đúng một lỗi Mỗi phiên

bản lỗi của PUT được gọi là một đột biến (mutant) Mỗi đột biến được tạo ra bởi

chỉ một sự thay đổi cú pháp trong PUT, mỗi sự thay đổi cú pháp là một luật hay

được gọi là một toán tử đột biến (mutation operator) Các toán tử đột biến được

định nghĩa sẵn để tạo ra sự thay đổi cú pháp dựa trên các lỗi mà các lập trìnhviên thường phạm phải

Ví dụ: Toán tử đột biến toán tử quan hệ sẽ tạo ra một số các đột biến trong

đó mỗi đột biến có sự xuất hiện của một toán tử quan hệ được thay thế bởi toán

tử quan hệ khác Hình 2.1 là một ví dụ về hai đột biến của PUT được tạo ra bởitoán tử đột biến toán tử quan hệ

bộ dữ liệu thử càng chất lượng Mục đích của kiểm thử viên là tạo ra dữ liệu thửmới để cải tiến chất lượng của các dữ liệu thử hiện có Một kết quả khá hữu íchcủa phương pháp này là việc cải tiến chất lượng của dữ liệu thử sẽ cải thiện sựtin tưởng của kiểm thử viên vào tính đúng đắn của PUT Có thể nói rằng, sự tintưởng của kiểm thử viên vào chương trình cành nhiều, thì càng nhiều kiểm thửtốt hơn sẽ được sử dụng.

Ngoài ra, kiểm thử đột biến là phương pháp để cải tiến chất lượng dữ liệuthử cung cấp nhiều hỗ trợ quan trọng Nếu một lỗi làm cho đột biến của PUTthất bại khi thực hiện với một số dữ liệu thử và PUT thành công, thì chính PUTkhông thể chứa lỗi đó (tức là PUT là phiên bản đúng của chương trình đối vớilỗi đó) Kiểm thử mọi đột biến có thể có giúp kiểm thử biết rằng không có cáclỗi đó xuất hiện trong PUT Phát triển dữ liệu thử theo cách này cho phép kiểmthử viên tăng sự tin tưởng của họ vào tính đúng đắn của PUT

2.3 Cơ sở của kiểm thử đột biến

Kiểm thử đột biến được xây dựng dựa trên ba giả thuyết cơ bản [18] nhưsau:

 Giả thuyết đầu tiên là giả thuyết lập trình viên giỏi, trong đó giả

thuyết rằng lập trình viên giỏi tạo ra các chương trình nếu không đúngthì cũng gần đúng [7, 8] Các lập trình viên như vậy có ý tưởng về cácchương trình mong muốn như thế nào và phấn đấu để đạt được điều đó

 Giả thuyết thứ hai là hiệu ứng liên kết cho rằng dữ liệu thử có khả

năng xác định các lỗi đơn giản (ví dụ: sự khác biệt một từ đơn) thì cũng

có thể xác định các lỗi phức tạp hơn [7, 20] Hiệu ứng này được hỗ trợbởi bằng chứng thực nghiệm [20] và cho phép kiểm thử đột biến thựchiện hạn chế trên một tập các phiên bản PUT đơn giản, trong khi đó tạo

ra các kiểm thử hiệu quả xác định các lỗi phức tạp

 Giả thuyết thứ ba là dựa vào dự đoán (Oracle) để xác định kết quả đầu

ra khi thực hiện kiểm thử là đúng hay không

Những giả thuyết trên làm nền tảng cho các cơ sở kiểm thử đột biến vàcung cấp những giới hạn cho việc sử dụng của kiểm thử đột biến

2.4 Toán tử đột biến

Phần lớn các nghiên cứu về kiểm thử đột biến chủ yếu dựa trên các chươngtrình Fortran do tính sẵn có và dễ sử dụng của hệ thống đột biến Mothra [18].Mothra (hệ thống đột biến cho Fortran) sử dụng 22 toán tử đột biến để tạo ra các

đột biến cho 77 chương trình Fortran [11], được biểu diễn bảng 2.1 Các toán tử

này đã được phát triển và chọn lọc cách đây hơn 20 năm, ngày nay vẫn còn

nhiều toán tử được sử dụng dưới một số hình thức chẳng hạn như sử dụng toán

tử thay thế toán tử logic và một số toán tử tương tự như các toán tử LCR và SDL

của Mothra, MuJava (hệ thống đột biến cho Java) vẫn sử dụng các toán tử ABS,

AOR, LCR, ROR và UOI [15]

Toán tử đột biến

AARABSACRAORASRCARCNRCRPCSRDERDSAGLRLCRRORRSRSANSARSCRSDL

Bảng 2.1- 22 toán tử đột biến chuẩn được sử dụng trong Mothra

Các toán tử đột biến được thiết kế để làm lộ ra các lỗi trong PUT khi thực

hiện Ví dụ, toán tử thay thế toán tử quan hệ ROR Đột biến tạo ra từ toán tử này

sẽ giống với PUT ngoại trừ một toán tử quan hệ đơn được thay thế bằng mộttoán tử quan hệ khác, chẳng hạn như câu lệnh x < y sẽ được thay thế bằng x <=

y với mục đích để kiểm tra xem trong trường hợp < này, toán tử quan hệ có sửdụng đúng hay không

Nếu PUT thực sự là đúng thì nó có thể tìm thấy các dữ liệu thử tạo ra cáckết quả đầu ra không đúng cho tất cả các phiên bản toán tử quan hệ không tươngđương, do đó loại bỏ những đột biến đó để được phiên bản đúng của chươngtrình Tuy nhiên, trước khi kiểm thử, chúng ta không biết được liệu PUT là đúnghay không Thay vào đó, PUT phải được giả sử là đúng, trừ khi một dữ liệu thử

có thể chứng minh khác Trong tình huống đó, tỷ lệ các đột biến không tươngđương bị diệt bởi bộ dữ liệu thử là thước đo cho chất lượng của bộ dữ liệu thử

và thước đo của sự tin tưởng vào tính đúng đắn của PUT

Gần đây, nghiên cứu về kiểm thử đột biến đã tập trung phát triển các toán tửđột biến mới, đặc biệt cho các môi trường hướng đối tượng, cụ thể tập trung vàoJava [5, 14, 15, 16] Các ngôn ngữ lập trình hướng đối tượng khác với cácchương trình truyền thống rất nhiều, đặc biệt trong cấu trúc và trong mô hìnhnhư tính kế thừa và tính đa hình Các khác biệt này gây ra nhiều tiềm năng xuấthiện các lỗi mới, mà cần phải được biểu diễn trong các hệ thống kiểm thử độtbiến hướng đối tượng để có hiệu quả Tuy nhiên, nghiên cứu này tập trung kiểmthử các chương trình đơn giản, nhưng hầu hết các toán tử đột biến truyền thốngvẫn còn hiệu quả

2.5 Quy trình kiểm thử đột biến

Kiểm thử đột biến là một quy trình được lặp đi lặp lại để cải tiến dữ liệuthử đối với một chương trình, như ở hình 2.2 Các thông số ban đầu để xử lý làPUT (chương trình được kiểm thử) và bộ dữ liệu thử T

Trước tiên, bằng cách sử dụng Oracle, PUT phải được hiển thị để cung cấpcác đầu ra mong muốn khi thực hiện với các dữ liệu thử trong T Nếu có bất kỳkết quả đầu ra nào là không đúng thì T đã chứng minh rằng PUT chứa lỗi Cáclỗi này nên được sửa chữa trước khi tiếp tục quá trình

Khi đã xác định được tất cả các dữ liệu thử trong T cung cấp các đầu rachính xác, công đoạn tiếp theo là tạo ra một tập M – các đột biến của PUT Saukhi tạo ra tập M chứa tất cả các đột biến Các đột biến này được thực hiện với T

và các kết quả đầu ra của chúng được so sánh với các kết quả đầu ra của PUT

Nếu kết quả đầu ra của đột biến khác so với kết quả đầu ra của PUT thì chứng tỏ

lỗi đó (lỗi mà đột biến sửa chữa từ PUT) không xảy ra trong PUT Khi đó, sẽ

làm tăng sự tin tưởng của kiểm thử viên rằng PUT là đúng Các đột biến như vậy

trở nên không cần thiết vì dữ liệu thử hiện có đã phân biệt được chúng, và do đó

chúng đã bị biệt (bị loại bỏ) từ tập đột biến M

Các toán tử đột biến

Đầu vào chương trình P

Chạy T trên P

Sửa P

Kết thúc

Hình 2.2 – Quy trình kiểm thử đột biến

( Lưu ý: Các bước biểu diễn trong hộp liền nét được thực hiện tự động.

Còn các bước biểu diễn trong hộp nét dứt được thực hiện bằng tay)

Một khi tất cả các dữ liệu thử trong T đã được thực hiện trên tất cả các độtbiến trong M, các đột biến đó vẫn còn sống (vẫn còn tồn tại trong M) cho đếnlúc này vẫn không thể phân biệt chúng với chương trình gốc (PUT) Nói cáchkhác, không tồn tại dữ liệu thử trong T làm cho những đột biến còn sống tínhtoán kết quả đầu ra khác so với PUT Những đột biến này trở thành mục tiêu cho

lần lặp tiếp theo, trong đó dữ liệu thử mới sẽ được tạo ra với nỗ lực để phân biệtđược chúng.

Quá trình này tiếp tục cho đến khi tất cả các đột biến trong M bị diệt Tuynhiên, để diệt được các đột biến không phải là một công việc dễ dàng vì một số

đột biến có thể có ngữ nghĩa giống với PUT Những đột biến này được gọi là đột biến tương đương [18] và sẽ luôn luôn tạo ra kết quả đầu ra giống với PUT

không quan tâm đến dữ liệu thử được áp dụng, ví dụ ở hình 2.3 sẽ minh họa chođiều này

-if (x = = 2 && y = = 2)

z = x * y;

-Hình 2.3 – Ví dụ về đột biến tương đương

(Đột biến P’ là đột biến tương đương của PUT vì dữ liệu thử sẽ không thể phát hiện ra lỗi trong chương trình P do giá trị của z luôn luôn bằng 4)

Như vậy, M không bao giờ rỗng hoàn toàn khi đột biến tương đương tồn tại.Điều này ảnh hưởng không tốt đối với kiểm thử đột biến vì kiểm thử viên khôngbiết liệu các đột biến còn lại trong M là tương đương hay không Nếu chúng làtương đương thì không có dữ liệu thử nào diệt được chúng, còn nếu chúng không

là tương đương thì sẽ có dữ liệu thử có thể phát hiện được chúng nhưng cho đếnlúc này vẫn chưa tìm ra Hơn nữa, việc xác định liệu một đột biến là tươngđương hay không là vấn đề không giải được [4], và vì vậy, kiểm thử viên phảixác định một cách thủ công

Việc giảm tập M xuống còn tập rỗng cung cấp một thước đo hữu ích choviệc đánh giá chất lượng của T đối với PUT Nếu T diệt được tất cả các đột biếnkhông tương đương thì các dữ liệu thử có khả năng xác định rằng không lỗi nào(lỗi mà các đột biến cố gắng sửa chữa từ PUT) xuất hiện trong PUT Tuy nhiên,trước khi T đạt được chất lượng này, nó chỉ phân biệt một phần các đột biếnđược thể hiện bởi số lượng các đột biến không tương đương bị diệt từ M Phần

này được gọi là tỷ lệ đột biến (MS) và được định nghĩa như sau:

MS 

Trong đó, D là số đột biến đã bị diệt; N là tổng số các đột biến; E là số đột

biến tương đương Khi tỷ lệ này tăng (nghĩa là đột biến không tương đương bịdiệt nhiều hơn) thì chất lượng của dữ liệu thử và sự tin tưởng của kiểm thử viênvào tính đúng đắn của PUT cũng tăng Sau đó, lặp lại công việc tạo ra các dữliệu thử mới để cải tiến chất lượng của T

2.6 Một số vấn đề của kiểm thử đột biến

Mặc dù được xem là một kỹ thuật kiểm thử đơn vị mạnh [11, 26, 29], kiểmthử đột biến gặp phải một số vấn đề khó khăn trong ngành công nghiệp phần

mềm Các vần đề này có thể được phân loại thành hai nhóm: chi phí tính toán – tốn rất nhiều thời gian và công sức để thực hiện kiểm thử đột biến, và tự động hóa – tốn bao nhiêu công sức của kiểm thử viên.

Kiểm thử đột biến thì tốn kém vì số lượng lớn các chương trình đột biếncần được tạo ra và thực hiện Do đó, các nhà nghiên cứu tiến hành nghiên cứubằng thực nghiệm với kiểm thử đột biến thường chỉ sử dụng chương trình nhỏ

để hạn chế số lượng đột biến được tạo ra Trong khi đó, hạn chế này là chấpnhận được ở các trường (đại học, học viện, …), nó không dành cho công nghiệpthường mong muốn được kiểm thử các chương trình lớn hơn, phức tạp hơn Vìtính phức tạp gia tăng, do thời gian thực hiện cho một chương trình và các phiênbản đột biến của nó, do đó làm tăng toàn bộ thời gian chạy cho kiểm thử độtbiến

Các vấn đề trầm trọng hơn nữa là rất khó khăn trong việc tự động hoá toàn

bộ quá trình kiểm thử đột biến Mặc dù, một phần lớn quá trình có khả năng tựđộng được dễ dàng, các công việc như xác định các đột biến tương đương vàkiểm tra tính đúng đắn của kết quả đầu ra thường được thực hiện một cách thửcông Mặc dù, việc thực hiện những công việc này bằng thủ công cho phépchương trình được xem xét kỹ lưỡng hơn, nhưng nó rất là tẻ nhạt và dễ bị lỗi Vìvậy, làm tăng thời gian kiểm thử ở một giai đoạn trong vòng đời phát triển phầnmềm, khi thời gian kiểm thử thường là rất quan trọng

2.7 Kết luận

Kiểm thử đột biến được giới thiệu để cung cấp một phương tiện để đánhgiá và cải tiến chất lượng các bộ dữ liệu thử Nó được xây dựng dựa trên ba giảthuyết cơ bản: giả thuyết lập trình viên giỏi, hiệu ứng liên kết, và dựa vào dựđoán Do đó, kiểm thử đột biến chỉ tập trung vào các lỗi đơn giản của chươngtrình (ví dụ: sự khác biệt một từ đơn hoặc thay thế tên biến sai) Nếu một lỗi làmcho đột biến của PUT thất bại khi thực hiện với một số dữ liệu thử và PUT thành

công, thì chính PUT không thể chứa lỗi đó (tức là PUT là phiên bản đúng củachương trình đối với lỗi đó) Kiểm thử mọi đột biến có thể có giúp kiểm thử biếtrằng không có các lỗi đó xuất hiện trong PUT Phát triển dữ liệu thử theo cáchnày cho phép kiểm thử viên tăng sự tin tưởng của họ vào tính đúng đắn của PUT.Tuy nhiên, kiểm thử đột biến không được sử dụng rộng rãi trong thực tế dochi phí tính toán quá cao vì một số lượng lớn các chương trình đột biến cần phảiđược thực hiện bởi ít nhất một dữ liệu thử và khó khăn để tự động hóa vì các dữliệu thử mạnh cần phải được tạo ra, đột biến tương đương cần được loại bỏ, vàkết quả đầu ra của PUT cần được kiểm thử tính đúng đắn Vì vậy, chương 3 sẽ

đề cập đến các phương pháp cải tiến kỹ thuật kiểm thử đột biến để khắc phụccác vần đề trên

CHƯƠNG 3 - CÁC CẢI TIẾN KỸ THUẬT KIỂM THỬ

ĐỘT BIẾN

3.1 Giảm chi phí tính toán

Các hệ thống kiểm thử đột biến truyền thống tạo ra số lượng lớn cácchương trình đột biến Ví dụ, có 385 đột biến được tạo ra cho thủ tục tìm nghiệmtheo phương pháp NiuTơn gồm 18 dòng lệnh [29] Phân tích cho thấy rằng sốlượng các đột biến tạo ra xấp xỉ bằng tích của số các tham chiếu dữ liệu và sốcác đối tượng dữ liệu [18] Do đó, số lượng đột biến sẽ làm tăng tính phức tạpcủa chương trình Điều này làm tăng chi phí thực thi do mỗi đột biến phải thựcthi với ít nhất một trường hợp kiểm thử Như vậy, chi phí là chấp nhận được chonghiên cứu ở các trường (đại học, học viện, …) với các ràng buộc về thời gian

có thể linh hoạt, nhưng trong công nghiệp nói chung không thể lãng phí như thếđược

Hơn thế nữa, vì các hệ thống truyền thống phải thông dịch các chương trìnhđột biến nên thực tế thời gian chạy sẽ lâu hơn Điều này gây ra nhiều bất tiện, nólàm cho các hệ thống thực hiện chậm và rất khó để mô phỏng môi trường hoạtđộng Để khắc phục những chi phí liên quan với đột biến, nghiên cứu hầu hết đã

tập trung vào một trong ba lĩnh vực: làm ít hơn, làm nhanh hơn, hoặc làm thông minh hơn [26].

không làm giảm các khả năng tìm kiếm lỗi

3.1.1.1 Lấy mẫu đột biến

Lấy mẫu đột biến là một phương pháp đơn giản lựa chọn ngẫu nhiên mộttập con nhỏ các đột biến từ tập toàn bộ các đột biến Ý tưởng này được đề xuấtđầu tiên bởi Acree và Budd [30] Trong phương pháp lấy mẫu đột biến, đầu tiêntất cả các đột biến có thể có được tạo ra như trong kiểm thử đột biến truyềnthống Sau đó, x% của những đột biến này được lựa chọn ngẫu nhiên để phântích đột biến và các đột biến còn lại được bỏ đi