1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

96 460 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 96
Dung lượng 1,5 MB

Nội dung

Ý 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ụn

Trang 1

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ướngdẫ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ínhtrọ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ọcTự 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ốtquá 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

Trang 2

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Ữ 4

II) DANH MỤC CÁC BẢNG BIỂU 4

III) DANH MỤC CÁC HÌNH VẼ 4

LỜI MỞ ĐẦU 5

CHƯƠNG 1 – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 8

1.1 Khái niệm 8

1.2 Các cấp độ kiểm thử phần mềm 8

1.2.1 Kiểm thử đơn vị (Unit Test) 9

1.2.2 Kiểm thử tích hợp (Integration Test) 9

1.2.3 Kiểm thử hệ thống (System Test) 10

1.2.4 Kiểm thử chấp nhận sản phẩm (Acceptance Test) 12

1.3 Kỹ thuật kiểm thử phần mềm 12

1.3.1 Kỹ thuật kiểm thử hộp đen (Black – box Testing) 12

1.3.1.1 Phân hoạch tương đương 14

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

1.3.2 Kỹ thuật kiểm thử hộp trắng (White – box Testing) 17

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

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

1.4 Kết luận 25

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

2.1 Một số khái niệm 26

2.1.1 Kiểm thử đột biến 26

2.1.2 Đột biến 26

2.1.3 Toán tử đột biến 29

Trang 3

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

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

3.1.1 Phương pháp làm ít hơn (A “do fewer” approach) 35

3.1.1.1 Lấy mẫu đột biến (Mutant Sampling) 36

3.1.1.2 Đột biến ràng buộc (Constrained Mutation) 38

3.1.1.3 N - đột biến lựa chọn (N - Selective Mutation) 39

3.1.2 Phương pháp làm nhanh hơn (A “do smarter” approach) 41

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

3.1.2.2 Đột biến yếu (Weak Mutation) 44

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

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

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

3.3 Kết luận 52

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) 53

4.1 Tìm hiểu về NUnit 54

4.1.1 Định nghĩa 54

4.1.2 Đặc điểm của NUnit 54

4.1.3 Thuộc tính hay dùng trong thư viện NUnit.Framework 54

4.1.4 Phương thức tĩnh hay dùng trong NUnit.Framework.Assert 56

4.1.5 Cài đặt NUnit 58

4.1.6 Cách sử dụng NUnit 60

4.2 Công cụ Nester 68

4.2.1 Điều kiện tiên quyết 68

4.2.2 Giải pháp cho đột biến 68

4.2.3 Chạy Nester 69

4.2.4 Lựa chọn Nester.exe.config 71

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 71

4.3.1 Kiểm thử 72

4.3.2 Tạo đột biến 73

4.4 Kết luận 75

KẾT LUẬN 76

TÀI LIỆU THAM KHẢO 78

Trang 4

PHỤ LỤC 1 81

PHỤ LỤC 2 83

PHỤ LỤC 3 89

PHỤ LỤC 4 93

PHỤ LỤC 5 94

Trang 5

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ạolượ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 – moneysau 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 đườngdẫ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#

Trang 6

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ể xemnhẹ 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ếtcá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ộtphầ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ồntà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 địnhmộ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á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 đó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ươngtrì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ỗicao nhất Vấn đề đặt ra là làm thế nào để đánh giá được khả năng phát hiện lỗi

Trang 7

liên quan đến tiêu chuẩn chất lượng được định trước, thường là một số dấuhiệ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ểmthử 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àoviệ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ênnhâ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êuchuẩ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ứacá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ươngtrình sẽ tăng Kiểm thử đột biến đã được áp dụng cho nhiều ngôn ngữ lậptrì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ậtkiểm thử hộp trắng và hộp đen để thiết kế dữ liệu thử

Trang 8

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ệnphươ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ậtkiể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ăngphân tích và tạo đột biến Tiếp đó là ứng dụng kỹ thuật kiểm thử độtbiến để kiểm thử các chương trình C# sử dụng hai công cụ trên

Trang 9

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ườngnhư 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ìmmộ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áchcó hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thờigian, công sức và chi phí

(Integration test)

Kiểm thử mức tích hợp các đơn vị

Kiểm thử để chấp nhận sản phẩm (Acceptance test)

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

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

Các nhóm bộ phận

Các nhóm bộ phận

Trang 10

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ếtxuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chứcnă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ảichuẩn bị trước các ca kiểm thử (hay trường hợp kiểm thử) (test case) hoặckị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ácthà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 nhauvà 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)

Trang 11

 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ạncá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ủahệ 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.1.1 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ẫncá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ăngvà 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 đã đượctí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ứcvà 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 gianthực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểmthử 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ốnglà 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ểmthử tích hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúnglà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

Trang 12

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ínhxá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 đã đượchình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểmnày, lập trình viên hoặc kiểm thử viên (Tester) bắt đầu kiểm thử phần mềmnhư một hệ thống hoàn chỉnh Việc lập kế hoạch cho kiểm thử hệ thống nênbắ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ểmthử 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ậpvớ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ấtcùng lúc) Stress test tập trung vào các trạng thái tới hạn, các "điểmchế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 độngtươ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

Trang 13

nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giaodịch như ngân hàng trực tuyến.

1.1.2 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ố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ủakhá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ứcquan trọng tránh cho việc hiểu sai yêu cầu cũng như sự mong đợi của kháchhà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ữngdị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ấtcả 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ốithiể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

Trang 14

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ệntượng mà phần mềm không hành xử theo đúng đặc tả của nó Do đó, dữ liệukiể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ựngcá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ủ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áphộ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ìnhkiểm thử, kiểm thử hộp đen được áp dụng trong các giai đoạn sau của kiểmthử Vì kiểm thử hộp đen không để ý có chủ đích cấu trúc điều khiển, sự quantâm tập trung trên miền thông tin Nếu người kiểm thử muốn sử dụng phươngphá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ảikiể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ộttrườ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

Trang 15

1.1.2.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 nhaucó 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ànhmộ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 đầuvào (thông thường là một câu lệnh hoặc một cụm từ trong đặc tả) và phânhoạch nó thành hai hay nhiều nhóm Các lớp tương đương bao gồm một tậpcá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 đầuvà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 đươngkhô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 <= x < = 999, các lớp không hợp lệ là x < 1 và x >999

Trang 16

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ônghợ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 đươngkhô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 ứ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ăngphá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 hợp lệ Các lớp tương đương không hợp lệ

Không rỗng

Không phải chữ cáiRỗng

Giới tính sinh viên Ký tự chữ cái, “M’ hoặc “F” Không phải chữ cái

Không phải “M” hoặc “F”

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

Từ 0 đến 100

Không phải số

Số nhỏ hơn 0Số 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ểmthử 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

Trang 17

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 saocho 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.1.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đầ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ớptươ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:

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ợpkiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức là cáclớ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á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

Trang 18

tiểu Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng đượckiể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ếtkế 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ủamì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ểmtra 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áccâ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ử truynhậ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 TomMcCabe đề 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ụcvà 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ệntập cơ sở Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh

Trang 19

Trong thực tế, phương pháp đường dẫn cơ sở có thể được dùng khôngcần sử dụng đồ thị luồng điều khiển Tuy nhiên, đồ thị luồng điều khiển (minhhọ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à minhhọ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ộtcá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

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ảnhcủa phương pháp đường dẫn cơ sở, giá trị được xác định cho độ phức tạp chutrình cho biết số lượng đường dẫn độc lập trong một tập cơ sở của chươngtrì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

Trang 20

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ìnhV(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 chutrình V(G) được tính như sau:

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ở

Trang 21

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 kết thúc bằng giá trị -999.

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 (trong 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

Bước 4: Thiết kế các trường hợp kiểm thử cho mỗi đường dẫn độc lập

trong tập cơ sở đã chọn

1 1

Trang 22

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

Trang 23

trường hợp kiểm thử đường dẫn cơ sở), nhất là để thực hiện các điều kiệnbiên

1.3.2.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ử đơngiản và hiệu quả nhưng 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ượngcủa phươ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áclỗ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ểmthử đ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 Cvà mỗi điều kiện đơn giản trong C cần phải được thực thi ít nhất mộtlần

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ủa chương trình dựa vào vị trí khai báo và sử dụng các biến trong chươngtrình Với kiểm thử luồng dữ liệu, mỗi câu lệnh trong chương trình được gánsố hiệu lệnh duy nhất và mỗi hàm không thay đổi tham số của nó và biến toàncục Cho một lệ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

Trang 24

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ỗichuỗi DU được phủ ít nhất một lần Chiến lược này được gọi là chiến lượckiểm thử DU Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của mộtchương trì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

c) Kiểm thử vòng lặp

Là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp Có

4 kiểu vòng lặp khác nhau được mô tả bằng sơ đồ khối như sau:

Vòng lặp đơn Vòng lặp nối tiếp Vòng lồng nhau Vòng lặp phi cấu trúc

Hình 1.4 –Các kiểu vòng lặp

Trang 25

 Các bước cần kiểm tra cho vòng lặp đơn giản

+ Bỏ qua toàn bộ vòng lặp;

+ Chỉ qua một vòng lặp;

+ Qua hai vòng lặp;

+ Qua vòng lặp m với (m < n);

+ Qua vòng lặp (n - 1), n, (n + 1)

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 dạng 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à maxcho 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 khitấ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 các vònglặp dạng đơn giản, nếu không thì kiểm tra như trường hợp các vòng lặp lồngnhau

 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ếtkế 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

Trang 26

1.2 Kết luận

Trong chương 1 đã nêu tổng quan về các cấp độ và loại kiểm thử phầnmềm cơ bản Kiểm thử hộp trắng xem xét chương trình ở mức độ chi tiết vàphù hợp khi kiểm tra cá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ểmthử 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ện bên ngoài, nó thích hợp hơn cho các hệ thốngphần mềm lớn hay các thành phần quan trọng của chúng Nhưng chỉ sử dụngkiểm thử hộp đen là chưa đủ Bởi vì, kiểm thử chức năng 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 khaibá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ủa chương trình đã hay chưa được kiểm thử, khi đó phảikiể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ươngphá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

Trang 27

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

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àocủa chương trình, mà chúng ta chỉ có thể tạo ra các dữ liệu thử có khả năngphát hiện lỗi cao nhất Vấn đề đặt ra là làm sao để đánh giá được khả năngphát hiện lỗi của một bộ dữ liệu thử? Chính kỹ thuật kiểm thử đột biến làcâu trả lời Kỹ thuật này cho phép đánh giá chất lượng (khả năng phát hiệnlỗi) của một bộ dữ liệu thử

2.1 Một số khái niệm

2.1.1 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 [13] 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 tập trung vào việc đánh giá khả năng phát hiện lỗicủa dữ liệu dùng để kiểm thử Kiểm thử đột biến được dùng kết hợp vớicác kỹ thuật kiểm thử thông thường nhưng không thể được dùng để thaythế cho các kỹ thuật kiểm thử thông thường đó

2.1.2 Đột biến

Kiểm thử đột biến bao gồm việc tạo ra các phiên bản lỗi của chươngtrình gốc được kiểm thử nhờ vào các toán tử đột biến Các phiên bản lỗi đó

được gọi là các đột biến (mutant).

Khi tiến hành thực thi kiểm thử lần lượt chương trình gốc P và đột biếnP’ của P với một dữ liệu kiểm thử T, sẽ có hai kịch bản khác nhau có thể xảyra:

Trang 28

- Một là, đột biến P’ được gọi là bị diệt bởi dữ liệu kiểm thử T.

- Hai là, chương trình gốc P và đột biến P’ cho ra kết quả hoàn toàn

giống nhau, đột biến P’ được cho là còn sống.

Các đột biến tương đương (equivalent mutant) là các đột biến của

chương trình gốc nhưng hoạt động hoàn toàn giống với chương trình gốc vàcho ra kết quả giống với chương trình gốc trong mọi trường hợp kiểm thử

(Độ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)

Tỷ số MS = 100 * D/(N - E) được gọi là tỷ lệ đột biến (Mutation Score - MS) Trong đó, D là độ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 Tỷ lệ đột biến cho phép đánh giá chất lượng

bộ dữ liệu thử

Ví dụ: Toán tử đột biến 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 rabởi toán tử đột biến toán tử quan hệ

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

z = x * y;

-

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

z = x * y;

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

Trang 29

Dựa trên tiêu chuẩn chất lượng đột biến, các đột biến được thực hiện vớimột bộ dữ liệu thử để xác định có bao nhiêu đột biến thất bại (tức là cung cấpđầu ra không đúng cho đầu vào kiểm thử đó) Thất bại càng nhiều, càng lớnthì 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 ích củ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ự tin tưởng của kiểm thử viên vào chương trình càng 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ệu thử cung cấp nhiều hỗ trợ quan trọng Nếu một lỗi làm cho đột biến củaPUT 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ủa chươngtrình đối với lỗi đó) Kiểm thử mọi đột biến có thể có giúp kiểm thử biết rằng

Chương trình PUT gốc

int max (int x, int y) {

Trang 30

không có các lỗi đó xuất hiện trong PUT Phát triển dữ liệu thử theo cách nàycho 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

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

Toán tử đột biến (mutation operator) là một luật được áp dụng vào

chương trình gốc để tạo ra các đột biến Các toán tử đột biến được xác địnhbởi ngôn ngữ của chương trình được kiểm thử và hệ thống đột biến đượcdùng để kiểm thử

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

Kiểm thử đột biến là một kỹ thuật kiểm thử hộp trắng hay kiểm thửcấu trúc, được xây dựng dựa vào hai g iả thuyết cơ bản [13]:

- Giả thuyết “lập trình viên giỏi” (competent programmer)

- Giả thuyết “ hiệu ứng liên kết” (coupling effect)

Giả thuyết “lập trình viên giỏi” giả thiết rằng lập trình viên chỉ phạmnhững lỗi đơn giản do sơ suất Giả thuyết “hiệu ứng liên kết” giả thuyếtrằng, nếu dữ liệu thử phát hiện được các lỗi đơn giản thì dữ liệu đó cũng chophép phát hiện các lỗi phức tạp

2.3 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ácchương trình Fortran do tính sẵn có và dễ sử dụng của hệ thống đột biếnMothra [14] Mothra (hệ thống đột biến cho Fortran) sử dụng 22 toán tử độtbiến để tạo ra các đột biến cho 77 chương trình Fortran [5], được biểu diễnbả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

Trang 31

Toán tử đột biến Mô Tả

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ệ được thay thế bằngmột toá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ôngtương đương, do đó loại bỏ những đột biến đó để được phiên bản đúng củachương trình Tuy nhiên, trước khi kiểm thử, chúng ta không biết được liệuPUT là đúng hay không Thay vào đó, PUT phải được giả sử là đúng, trừ khi

Trang 32

một dữ liệu thử có thể chứng minh khác Trong tình huống đó, tỷ lệ các độtbiến không tương đương bị diệt bởi bộ dữ liệu thử là thước đo cho chất lượngcủ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 như C, C++,C_Sharp,… Nghiên cứu này tập trung kiểm thử các chương trình đơn giản,hầu hết các toán tử đột biến truyền thống vẫn còn hiệu quả

2.4 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 và được chia thành các bước cơ bản [13] sau:

Bước 1: Sản sinh đột biến (dùng công cụ sản sinh tự động hoặc

sản sinh thủ công) từ chương trình gốc

Bước 2: Sản sinh các dữ liệu kiểm thử.

Bước 3: Thực hiện từng dữ liệu kiểm thử với chương trình gốc Bước 3.1: Nếu kết quả không đúng, phải chỉnh sửa l ạ i

chương trình và kiểm thử lại

Bước 3.2: Nếu kết quả đúng, thực hiện bước tiếp theo.

Bước 4: Thực hiện từng dữ liệu kiểm thử với từng đột biến còn sống.

Trang 33

Bước 4.1: Nếu kết quả ra của đột biến khác với chương

trình gốc, chương trình đột biến được xem là không

đúng và bị diệt Hoàn thành kiểm thử.

Bước 4.2: Nếu đột biến sống sót được (qua kiểm thử): phân

tích các đột biến còn sống Có hai khả năng xảy ra:

- Hoặc các đột biến là đột biến tương đương: không thểbị diệt

- Hoặc có thể diệt các đột biến được nhưng các dữ liệukiểm thử không đủ mạnh để diệt đột biến Do đóphải tạo ra các dữ liệu kiểm thử khác và lặp lại bước1

Từ các bước của thuật toán đã được tóm tắt thành sơ đồ [7] như hìnhsau:

T F

F T

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

Tất cả các đột biến bị diệt?

Đầu vào

chương trình

P

Đầu vào test cases, T

Chạy T trên P

P(T) đúng

? Sửa P

Chạy test cases trên từng đột biến còn sống

Phân tích và

đánh dấu các đột biến tương đương Kết thúc

Cập nhật T

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

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

Trang 34

( Lưu ý: Trong hình trên 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 đứt được thực hiện bằng tay)

2.5 Hạn chế 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, tuy nhiên 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 – để giảm 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ôngnghiệp thường mong muốn được kiểm thử các chương trình lớn hơn, phức tạphơ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ên bản đột biến của nó, do đó làm tăng toàn bộ thời gian chạy chokiểm thử đột biế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ệnmộ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ép chương trình được xem xét kỹ lưỡng hơn, nhưng dễ bị lỗi Vì

Trang 35

2.6 Kết luận

Kiểm thử đột biến được giới thiệu để cung cấp một phương tiện đểđánh giá 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ênhai giả thuyết cơ bản: giả thuyết lập trình viên giỏi, hiệu ứng liên kết Do đó,kiểm thử đột biến chỉ tập trung vào các lỗi đơn giản của chương trình (ví dụ:sự khác biệt một từ đơn hoặc thay thế tên biến sai)

Tuy nhiên, chi phí để thực hiện kiểm thử đột biến khá 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ộtdữ liệu thử và khó khăn để tự động hóa vì các dữ liệu thử mạnh cần phải đượctạ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 một số phươngpháp cải tiến kỹ thuật kiểm thử đột biến để khắc phục các vần đề trên

Trang 36

CHƯƠNG 3 - MỘT SỐ 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ìmnghiệm theo phương pháp NiuTơn gồm 18 dòng lệnh Phân tích cho thấy rằngsố 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 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ảithực thi 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 cho nghiên cứu ở các trường (đại học, học viện, …) với các ràng buộcvề thời gian có thể linh hoạt, nhưng trong công nghiệp sự lãng phí này làkhông thể

Mặt khác, 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ườnghoạt động Để khắc phục những chi phí liên quan với đột biến, các nghiên cứu

hầu hết đã tập trung vào một số phương pháp: làm ít hơn, làm nhanh hơn mà

không làm giảm khả năng phát hiện lỗi

3.1.1 Phương pháp làm ít hơn (A “do fewer” approach)

Muốn giảm chi phí kiểm thử đột biến thì phải giảm số lượng cácchương trình đột biến thực thi Để làm được điều này, chúng ta sử dụng một

Trang 37

3.1.1.1 Lấy mẫu đột biến (Mutant Sampling)

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 [19, 7] Trong phương pháp lấy mẫu độtbiến, đầu tiên tất cả các đột biến có thể có được tạo ra như trong kiểm thử độtbiến truyền thống Sau đó, x% của những đột biến này được lựa chọn ngẫunhiên để phân tích đột biến và các đột biến còn lại được bỏ đi

Đã có nhiều nghiên cứu thực nghiệm về phương pháp này Vấn đề chínhlà về việc chọn tỷ lệ lựa chọn ngẫu nhiên (x) còn được gọi là tỷ lệ lấy mẫu x

% Các nghiên cứu của Acree và Budd đề nghị rằng tỷ lệ lấy mẫu 10% có thểxác định trên 99% tất cả đột biến không tương đương trong khi cung cấp tiếtkiệm chi phí đáng kể Wong [23] tiếp tục nghiên cứu các lợi ích về chi phícủa lấy mẫu đột biến bằng cách thay đổi tỷ lệ lấy mẫu từ 10% đến 40% Ngaycả ở mức thấp nhất, các kết quả của Wong cho thấy lẫy mẫu đột biến là mộtchiến lược cắt giảm chi phí hiệu quả cung cấp các tập dữ liệu thử có khả năngxác định ít nhất 96,14% tất cả các đột biến nhưng chỉ phải kiểm tra 9,8% độtbiến

Một điểm nổi bật hơn nữa trong [23] là đối với các tập dữ liệu thử chấtlượng dựa vào lấy mẫu, một tỷ lệ lấy mẫu cao không có nghĩa là sẽ tạo ra tỷ lệđột biến cao hơn tỷ lệ lấy mẫu thấp Ban đầu, điều này có vẻ không hợp lý.Một trong những mong chờ đó là các dữ liệu thử được tạo ra từ tỷ lệ lấy mẫulớn thì sẽ chất lượng hơn trong việc xác định đột biến còn lại so với từ tỷ lệlấy mẫu nhỏ Tuy nhiên, các kết quả của Wong cho thấy; đối với hàmTEXTFMT, tỷ lệ lấy mẫu 25% đạt được tỷ lệ đột biến 98,92% so với 99,01%cho tỷ lệ lấy mẫu 10% Các kết quả này cho thấy rằng số lượng đột biến đượckiểm tra không phải là chỉ báo rõ ràng về tỷ lệ đột biến (ngoại trừ kiểm tra tấtcả các đột biến), nhưng thay vào đó, dấu hiệu là các dữ liệu thử có khả năng

xác định đột biến nhiều hơn những dấu hiệu khác Trong trường hợp này, việc

Trang 38

lựa chọn các đột biến cho kiểm thử có ảnh hưởng đến các dữ liệu thử được tạo ra và tỷ lệ đột biến không?

Các đột biến có thể được phân loại dựa trên tập các dữ liệu thử diệtchúng Đột biến mạnh là rất khó phát hiện, đòi hỏi dữ liệu thử đặc biệt để diệtnó Ngược lại, đột biến yếu có thể dễ dàng phát hiện bởi bất kỳ dữ liệu thửnào Do đó, cần có các tập dữ liệu thử khác nhau để diệt chúng Các tập dữliệu thử này nói chung là không được biết trước khi (và thường sau khi) kiểmthử Tuy nhiên, tập dữ liệu thử đó phải được tạo ra để diệt đột biến Xem xéttình huống, chọn W là đột biến yếu và chọn S là đột biến mạnh, W sẽ có tậpdữ liệu thử để diệt nó - TW và S chưa có dữ liệu thử diệt được nó - TS Có batình huống có thể xảy ra được minh họa ở hình 3.1:

1 TS  TW Tập dữ liệu thử diệt đột biến mạnh hơn là tập con của tập dữ

liệu thử diệt các đột biến yếu hơn– hình 3.3(a).

2 (TS  TW)  (TS  TW  ) TS không phải là tập con của TW nhưng

hai tập giao nhau – hình3.3 (b).

3 TS TW =  Hai tập dữ liệu thử rời nhau – hình 3.3 (c).

Nếu tình huống 1 xảy ra, thì chọn đột biến mạnh hơn trong quá trình lấymẫu sẽ đảm bảo dữ liệu thử được tạo ra diệt đột biến yếu hơn- tức là dữ liệu

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

Trang 39

dữ liệu thử có khả năng diệt đột biến đặc biệt Tình huống 2 là sự kết hợp củahai loại Lựa chọn đột biến mạnh hơn sẽ tạo ra dữ liệu thử có thể hoặc khôngthể diệt được đột biến yếu hơn và ngược lại Nói chung, kích thước của TW cóthể sẽ lớn hơn kích thước của TS, dữ liệu thử từ TW giao nhau với TS có thể sẽnhỏ hơn so với dữ liệu thử từ TS giao nhau với TW Ví dụ, cho một dữ liệu thử

x là giao với hai tập |TW| = 20 và |TS| = 5 Nếu dữ liệu thử được tạo ra để diệtđột biến yếu hơn (nghĩa là dữ liệu thử thuộc TW) thì tỷ lệ của x là 1/20 Nếudữ liệu thử được tạo ra để diệt đột biến mạnh hơn (nghĩa là dữ liệu thử thuộc

TS) thì tỷ lệ của x là 1/5

Ba tình huống trên cho thấy rằng, đột biến được chọn trong quá trình lấymẫu sẽ ảnh hưởng đến các dữ liệu thử được tạo ra Hơn nữa, chúng cho thấyrằng lựa chọn các đột biến mạnh hơn cải thiện cơ hội diệt các đột biến yếuhơn và vì vậy kích thước của lấy mẫu đột biến là không quan trọng, nhưng đóvẫn là sự lựa chọn đột biến Lấy mẫu từ đột biến mạnh hơn với tỷ lệ thấp hơncó thể tạo ra tỷ lệ đột biến cao hơn lấy mẫu từ đột biến yếu hơn với tỷ lệ caohơn

3.1.1.2 Đột biến ràng buộc (Constrained Mutation)

Giảm số lượng các đột biến cũng có thể đạt được bằng cách giảm sốlượng các toán tử đột biến được áp dụng Đây là ý tưởng cơ bản làm nền tảngcho đột biến ràng buộc được đề xuất bởi Mathur [4], bằng cách lựa chọn mộttập con các toán tử đột biến tạo ra một tập con tất cả các đột biến có thể có màkhông mất tính hiệu quả của kiểm thử đột biến

Các kiểm tra dựa trên kinh nghiệm thu được các kết quả khá thuyết phụckhi sử dụng đột biến ràng buộc Nhìn chung, các kết quả của Wong cho thấyrằng các tỷ lệ đột biến trung bình từ các tập dữ liệu thử chất lượng dựa trênràng buộc bằng cách sử dụng chỉ hai toán tử ABS và ROR đạt trên 95% trongsố bốn chương trình kiểm tra và giảm số lượng đột biến từ 14.39% đến19.94% của tổng số đột biến [22] Trong khi đó, tiết kiệm chi phí không lớn

Trang 40

bằng tỷ lệ lấy mẫu 10% (thực hiện từ 9,8% cho đến 10,98% tổng số đột biến),

tỷ lệ đột biến trung bình là xấp xỉ bằng 97,56% với tỷ lệ lấy mẫu 10% và97,18% với đột biến ràng buộc ABS / ROR Các nghiên cứu của Mathur vàđồng nghiệp cũng cho ra kết quả tương tự, kết quả này thu được 7 trong số 10thí nghiệm, đột biến ràng buộc ABS / ROR đạt hiệu quả ít nhất bằng tỷ lệ lấymẫu 10% trong việc phát hiện có lỗi Hơn nữa, còn lại 3 thí nghiệm đều đượcthực hiện trên cùng một chương trình không được sử dụng trong 7 thí nghiệmkhác

3.1.1.3 N - đột biến lựa chọn (N - Selective Mutation)

Offutt và đồng nghiệp [9, 10] mở rộng nghiên cứu đột biến ràng buộccủa Mathur bằng cách sử dụng tất cả các toán tử đột biến trừ đi hai toán tử tạo

ra hầu hết các đột biến (được gọi là phương pháp 2 - đột biến lựa chọn) Giả

thuyết phương pháp N – đột biến lựa chọn, trong đó N là số toán tử đột biếntạo ra nhiều đột biến nhất được loại bỏ Ban đầu, 28 chương trình đã đượckiểm tra để xác định tỷ lệ đột biến được tạo ra bởi mỗi toán tử đột biến, nhưthể hiện trong hình 3.2 Dựa trên đó, họ đề xuất loại bỏ hai toán tử SVR vàASR cho 2 - đột biến lựa chọn, cùng với SCR và CSR cho 4 - đột biến lựachọn, kết hợp với ACR và SRC cho 6 - đột biến lựa chọn

Đối với mỗi phương pháp lựa chọn, bộ tạo dữ liệu thử tự động Godzillađược dùng để tạo ra dữ liệu thử chất lượng dựa trên đột biến lựa chọn Sau đó,các tập dữ liệu thử này được thực hiện với tất cả các đột biến để xác định hiệuquả của chúng đối với tất cả các đột biến - tức là tỷ lệ đột biến của chúng Cáckết quả mang lại nhiều hứa hẹn Phương pháp 2 - đột biến lựa chọn cho kếtquả tỷ lệ đột biến 99,99% và tiết kiệm 23,98% số lượng đột biến không phải

Ngày đăng: 18/06/2016, 21:44

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Trường Đại học Tổng hợp TP.HCM Sách, tạp chí
Tiêu đề: Công nghệ phần mềm
Tác giả: Nguyễn Xuân Huy
Năm: 1994
[2] Lê Văn Tường Lân (2004), Giáo trình công nghệ phần mềm, Trường Đại học Khoa học Huế - Đại học Huế Sách, tạp chí
Tiêu đề: Giáo trình công nghệ phần mềm
Tác giả: Lê Văn Tường Lân
Năm: 2004
[4] A.P. Mathur (1991), Performance, effectiveness and reliability issues in software testing, Tokyo, Japan Sách, tạp chí
Tiêu đề: Performance, effectiveness and reliability issuesin software testing
Tác giả: A.P. Mathur
Năm: 1991
[5] A.J.Offutt and K.N.King, “A Fortran 77 interpreter for mutation analysis”, in 1987 Symposium on Interpreters and Interpretive Techniqes, pp. 177-188, ACM SIGPLAN, June 1987 Sách, tạp chí
Tiêu đề: A Fortran 77 interpreter for mutationanalysis”, "in 1987 Symposium on Interpreters and InterpretiveTechniqes
[6] A.J. Offutt and W.M. Craft, “Using compiler optimization techniques to detect equivalent mutants,” The Journal of Softwave Testing, Verification, and Reliability, vol.4, pp. 131-154, September 1994 Sách, tạp chí
Tiêu đề: Using compiler optimization techniques todetect equivalent mutants,” "The Journal of Softwave Testing,Verification, and Reliability
[7] A.T. Acree, T.A. Budd, R.A. DeMillo, R.J. Lipton, and F.G. Sayward,“Mutation Analysis”, Georgia Institute of Technology, Technical Report, GIT – ICS – 79/08, 1979 Sách, tạp chí
Tiêu đề: Mutation Analysis”, Georgia Institute of Technology, "TechnicalReport
[8] A.T.Acree, On Mutation, PhD thesis, Georgia Institute of Technology, Atlanta GA, 1980 Sách, tạp chí
Tiêu đề: On Mutation
[9] Jeff Offutt, Ammei Lee, Gregg Rothermel, Roland H. Untch, and Christian Zapf (1996), An Experimental Determination of Sufficient Mutant Operators, George Mason University Sách, tạp chí
Tiêu đề: An Experimental Determination of SufficientMutant Operators
Tác giả: Jeff Offutt, Ammei Lee, Gregg Rothermel, Roland H. Untch, and Christian Zapf
Năm: 1996
[11] K.S.H.T.Wah, “Fault coupling in finite bijecttive functions,” the Journal of Softwave testing Verification, and Reliability, vol.5, pp.3-47, March 1995 Sách, tạp chí
Tiêu đề: Fault coupling in finite bijecttive functions,” "theJournal of Softwave testing Verification, and Reliability
[12] Mark Harman and Rob Hierons (2006), “An Overview of Mutation Testing”, Genetic Algorithms for Mutation Testing, Brunel University, London Sách, tạp chí
Tiêu đề: An Overview ofMutation Testing”, "Genetic Algorithms for Mutation Testing
Tác giả: Mark Harman and Rob Hierons
Năm: 2006
[13] R.A. DeMillo and A.J. Offutt (1993), Experimental results from an automatic test case generator, ACM transactions on Softwar Engineering Methodology, 2(2) pages 109-127 Sách, tạp chí
Tiêu đề: Experimental results from anautomatic test case generator
Tác giả: R.A. DeMillo and A.J. Offutt
Năm: 1993
[14] R.A. DeMillo, D.S. Guindi, K.N.King, W.M.Mc Cracken and A.J.Offutt, “An extended overview of the Mothra Softwave testing environment,” in Proceeding of the Second wrokshop on Softwave Testing, Verification, and Anlysis, (Banff Alberta) pp. 142-151, IEEE Computer Society Press, July 1988 Sách, tạp chí
Tiêu đề: An extended overview of the Mothra Softwave testingenvironment,” "in Proceeding of the Second wrokshop on SoftwaveTesting, Verification, and Anlysis
[15] R.Geist, A.J.Offutt, and F. Harris, “Estimation and endhancement of real-time softwave reliability through mutation analysis,” IEEE Transactions on Computers, vol.41, pp. 550-558, May 1992. Special Issue on Fault – Tolerant Computing Sách, tạp chí
Tiêu đề: Estimation and endhancement ofreal-time softwave reliability through mutation analysis,” "IEEETransactions on Computers
[16] R.Untch (1992), “Mutation-based software testing using program schemata”, Proceedings of 30th ACM Southeast Regional Conference, Raleigh, NC Sách, tạp chí
Tiêu đề: Mutation-based software testing using programschemata”, "Proceedings of 30th ACM Southeast Regional Conference
Tác giả: R.Untch
Năm: 1992
[17] R.J.Lipton and F.G. Sayward, “the status of reseach on program mutation,” in Digest for the Workshop on Softwave Testing and Test Documentation, pp. 355-373, December 1978 Sách, tạp chí
Tiêu đề: the status of reseach on programmutation,” "in Digest for the Workshop on Softwave Testing and TestDocumentation
[19] T.A. Budd (1980), Mutation Analysis of Program Test Data, Ph.D Thesis, Yale University, New Haven CT Sách, tạp chí
Tiêu đề: Mutation Analysis of Program Test Data
Tác giả: T.A. Budd
Năm: 1980
[20] Nguyen Thanh Binh, C. Robach (2001), “Mutation Testing Applied to Hardware: the Mutants Genenration”, Proceedings of the 11th IFIP International Conference on Very Large Scale Integration,118-- 123, Montpellier, France Sách, tạp chí
Tiêu đề: Mutation Testing Appliedto Hardware: the Mutants Genenration”, "Proceedings of the 11thIFIP International Conference on Very Large Scale Integration
Tác giả: Nguyen Thanh Binh, C. Robach
Năm: 2001
[21] W.E. Howden (1982), Weak mutation testing and completeness of test sets, IEEE Transactions on Software Engineering, 8(4) pages 371-379 Sách, tạp chí
Tiêu đề: IEEE Transactions on Software Engineering
Tác giả: W.E. Howden
Năm: 1982
[22] W.Wong, J.Maldonado, an M.Delamaro Peducing the cost of regression test by using selective mutation. In 8 th CITS – International Conference on Softwave Technology, pages 11 – 13, Curitiba, PR, June 1997 Sách, tạp chí
Tiêu đề: the cost ofregression test by using selective mutation
[23] W.E.Wong, On Mutation and Data Flow. PhD thesis, Purduce University, December 1993. (Also Technical Re-port SERC – TR – 149 – P, Softwave Engineering Research Center, Purduce University, West Lafayetle Sách, tạp chí
Tiêu đề: On Mutation and Data Flow

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w