Kỹ thuật sinh test case tự động từ yêu cầu phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

VŨ THỊ ĐÀO

KỸ THUẬT SINH TEST CASE TỰ ĐỘNG TỪ YÊU CẦU
PHẦN MỀM

LUẬN VĂN THẠC SĨ

Hà Nội - 2008


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

VŨ THỊ ĐÀO

KỸ THUẬT SINH TEST CASE TỰ ĐỘNG TỪ YÊU CẦU
PHẦN MỀM

Ngành : Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số:
LUẬN VĂN THẠC SĨ
NGƢỜI HƢỚNG DẪN KHOA HỌC
TS.TRƢƠNG ANH HOÀNG
:

Hà Nội - 2008

LỜI CẢM ƠN
Luận văn này là thành quả của quá trình học tập nghiên cứu của tôi cùng sự giúp
đỡ, khuyến khích của các quý thầy sau 2 năm tôi theo học Chƣơng trình đào tạo Thạc sỹ,
chuyên ngành Công nghệ phần mềm của Khoa Công nghệ, Trƣờng Đại học Công nghệ
Hà Nội.
Tôi xin đặc biệt cảm ơn Thầy giáo hƣớng dẫn TS. Trƣơng Anh Hoàng. Thầy đã
nhiệt tình hƣớng dẫn tôi, giúp đỡ và động viên tôi rất nhiều, cho tôi có cơ hội đƣợc tiếp
xúc với các tài liệu tham khảo quý giá trong quá trình nghiên cứu để hoàn thành đề tài
này.
Xin trân trọng cảm ơn các Thầy giáo của Khoa Công Nghệ và Viện Công nghệ
thông tin đã dạy dỗ tôi trong hai năm học, cảm ơn các cán bộ công tác tại Phòng Sau Đại
học-Đại Học Công nghệ Hà Nội đã giúp đỡ tôi nhiều trong quá trình học tập và công tác
bảo vệ luận văn.

MỘT LẦN NỮA TÔI XIN CHÂN THÀNH CẢM ƠN!!


MỤC LỤC

CHƢƠNG 1. ĐẶT VẤN ĐỀ ................................................................................ 9
1.1. Tầm quan trọng của các yêu cầu phần mềm ................................................. 9
1.2. Khái niệm về Test case .................................................................................. 9
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm . ...................................... 10
CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH . Error! Bookmark not defined.
SINH TEST CASE TỰ ĐỘNG .............................. Error! Bookmark not defined.
2.1. Giới thiệu ..................................................... Error! Bookmark not defined.
2.2. Tổng quan về các phƣơng pháp sinh Test caseError! Bookmark not defined.
2.2.1. Sinh Test case dựa trên đặc tả ..................... Error! Bookmark not defined.
2.2.2. Sinh Test case dựa trên mô hình.................. Error! Bookmark not defined.

2.2.3. Sinh Test case hƣớng đƣờng dẫn................. Error! Bookmark not defined.
2.3. Kiểm thử phần mềm và UML ..................... Error! Bookmark not defined.
CHƢƠNG 3. CÁC KỸ THUẬT VÀ PHƢƠNG PHÁP SINH Error! Bookmark
not defined.
TEST CASE TỰ ĐỘNG ........................................ Error! Bookmark not defined.
3.1. Giới thiệu ..................................................... Error! Bookmark not defined.
3.2. Kỹ thuật sinh Test case dựa trên đặc tả ....... Error! Bookmark not defined.
3.2.1. Các phƣơng thức đặc tả trạng thái SCR ...... Error! Bookmark not defined.
3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tả của SCR .. Error! Bookmark not
defined.
3.2.3. Kỹ thuật tạo Test case cho đặc tả UML ...... Error! Bookmark not defined.
3.2.4. Các thuận toán sinh Test case dựa trên đặc tả.Error! Bookmark not defined.
3.3. Kỹ thuật sinh Test case dựa trên mô hình ... Error! Bookmark not defined.
3.3.1. Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UMLError! Bookmark
not defined.
3.3.2. Tạo Test case dựa trên Use case cải tiến ..... Error! Bookmark not defined.
CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNGError! Bookmark
not defined.
QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG ....... Error! Bookmark not defined.
4.1. Mục tiêu ....................................................... Error! Bookmark not defined.
4.2. Tóm tắt quá trình sinh Test case tự động .... Error! Bookmark not defined.
4.2.1. Ví dụ ............................................................ Error! Bookmark not defined.
4.2.2. Các Test case của ví dụ ............................... Error! Bookmark not defined.
4.2.3. Tính ứng dụng, các ƣu điểm và nhƣợc điểmError! Bookmark not defined.
4.2.4. Kết luận ....................................................... Error! Bookmark not defined.


4.3.

Cài đặt .......................................................... Error! Bookmark not defined.

DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT

Từ và cụm từ viết tắt
UML
OCD
SCR
Test
Tester

Viết đầy đủ
Unified Modeling Language
Object Collaboration Diagram
Software Cost Reducation
Sự kiểm thử
Kiểm thử viên



DANH MỤC CÁC HÌNH VẼ
Stt
1
2
3
4
5
6
7
8
9

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Tên hình vẽ
Một quy trình kiểm tra cơ bản.
Kiểm thử dựa trên đặc tả
Kiểm thử dựa trên chƣơng trình
Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp
Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR
Sự kiện gọi (call events)
Sự kiện báo hiệu (signal events)

Sự kiện thời gian (time Events)
Sự kiện thay đổi (Change Events)
Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML
Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái.
Biểu đồ lớp của mô hình thiết kề
OCD cho việc sinh ra các Test case chỉnh sửa đầy đủ các thuộc tính
OCD cho việc sinh ra các Test case chỉnh sửa chuyển tiếp
OCD cho việc sinh ra các Test case chỉnh sửa cặp chuyển tiếp.
Thuật toán phân tích đặc tả SCR
Thuật toán phân tách đặc tả UML
Biểu đồ cộng tác mức độ đặc tả
Biểu đồ cộng tác cho một thao tác
Các cặp cộng tác
Một đƣờng chuỗi thông điệp
Thuật toán instrumentation
Mô hình hóa các vùng trong thiết kế phần mềm
Các hoạt động của cách tiếp cận đƣợc đề xuất bên trong quá trình phát
triển phần mềm.
Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3.
Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3
Mô hình cách sử dụng có thể cho ví dụ thƣ viện của bảng 3.
Mô hình hành vi
Các lƣợc đồ test và các giá trị test
Test case cho kịch bản chính


DANH MỤC CÁC BẢNG BIỂU

Stt
1

2
3

Tên bảng biểu
Phân biệt các biểu đồ UML và các mức độ test
Mẫu cải tiến các use case
Một ví dụ về mẫu chi tiết các use case


MỞ ĐẦU
Mặc dù việc nghiên cứu về các phƣơng pháp và kỹ thuật sinh Test case tự động từ
yêu cầu ngƣời dùng đã đƣợc quan tâm nhiều trên thế giới, nhƣng ở Việt Nam các nghiên
cứu và ứng dụng chỉ mới ở bƣớc đầu. Thực vậy, công việc sinh Test case tự động từ yêu
cầu ngƣời dùng một cách có hiệu quả trong quá trình kiểm thử là vấn đề cần thiết và bức
xúc của các công ty sản xuất phần mềm cũng nhƣ các tổ chức thực hiện phát triển dự án
phần mềm.
Trong quá trình phát triển dự án phần mềm, thƣờng công việc tạo ra các Test case
từ yêu cầu ngƣời dùng do các Tester phụ trách. Nhƣng không phải Tester nào viết các tài
liệu Test case này cũng nhƣ nhau. Vì vậy trong các công ty phần mềm cũng nhƣ các tổ
chức thực hiện phát triển các dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết
tài liệu Test case tốt, có hiệu quả thì chất lƣợng phần mềm sẽ tốt hơn những dự án có Test
case tồi. Vậy tại sao chúng ta không đồng nhất hóa công việc viết Test case bằng các
phƣơng pháp và kỹ thuật tự động nhằm giảm bớt công sức và thời gian của các tester,
làm cho chất lƣợng của Test case tốt hơn.
Có các hƣớng tiếp cận khác nhau trong việc sinh Test case tự động: thứ nhất là có
thể sinh Test case tự động dựa trên đặc tả từ một file input đã đƣợc định sẵn; thứ hai là
sinh Test case tự động dựa trên code, chƣơng trình có sẵn; thứ ba là sinh Test case tự
động dựa trên các mô hình UML. Trong ba hƣớng tiếp cận trên chúng tôi chọn hƣớng
tiếp cận thứ ba và nghiên cứu các phƣơng pháp theo hƣớng tiếp cận này.
Trong đề tài luận văn này chúng tôi nghiên cứu các vấn đề về tạo Test case tự

động từ yêu cầu ngƣời dùng. Sau đó, chúng tôi xem xét các phƣơng pháp và kỹ thuật hiện
có trong việc tạo Test case tự động để từ đó có thể đƣa ra những cải tiến bổ sung và phát
triển. Cuối cùng là xây dựng một công cụ sinh Test case tự động có thể áp dụng trong
thực tế.
Bố cục của luận văn gồm phần mở đầu, phần kết luận và 4 chƣơng nội dung nhƣ
sau:
 Chƣơng 1: Đặt vấn đề, đƣa ra các vấn đề cần thiết và cấp bách trong việc nghiên
cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu ngƣời dùng.
 Chƣơng 2: Giới thiệu tổng quan về sinh Test case tự động. Trên cơ sở đó chọn
hƣớng tiếp cận sẽ đi sâu vào nghiên cứu ở Chƣơng 3.
 Chƣơng 3: Trình bày các phƣơng pháp và kỹ thuật sinh Test case tự động hiện có.
Từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ƣu điểm của nó so với các
kỹ thuật trƣớc.


 Chƣơng 4: Trình bày quá trình sinh Test case hiệu quả dựa trên kỹ thuật đƣợc đề
xuất. Đồng thời xây dựng chƣơng trình demo quá trình sinh Test case tự động.
Sau khi nghiên cứu và thử nghiệm, trong phần Kết luận có nêu một số tổng kết và
nhận xét về việc sinh Test case tự động, đồng thời đề ra hƣớng nghiên cứu tiếp theo.

CHƢƠNG 1. ĐẶT VẤN ĐỀ
1.1. Tầm quan trọng của các yêu cầu phần mềm
Các yêu cầu phần mềm là rất quan trọng với mọi dự án phần mềm. Các dự án
thành công hoặc thất bại có nguyên nhân là do chất lƣợng của các yêu cầu. Các yêu cầu
này cấu thành phạm vi của tất cả các công việc sau đó cho nhóm phát triển dự án. Không
có các yêu cầu tốt, các dự án sẽ thất bại, bị chậm trễ, tốn kém, hoặc làm ra các hệ thống
không bao giờ đƣợc sử dụng.
Các vấn đề yêu cầu nên đƣợc cố định sớm, trƣớc khi vào giai đoạn thiết kế, bởi vì
các vấn đề là do các yêu cầu kém có khuynh hƣớng gắn chặt vào trong thiết kế và khó để
cho việc sửa chữa sau này. Những ngƣời phát triển và ngƣời dùng có một cách nhìn khác

nhau từ những yêu cầu khi ngƣời phát triển xem xét yêu cầu từ quan điểm làm thế nào để
thực hiện còn ngƣời dùng chỉ cảm nhận vấn đề là sử dụng nó nhƣ thế nào. Cách an toàn
nhất để bảo đảm rằng nhu cầu của ngƣời dùng đã đƣợc đáp ứng những gì đã đƣợc đƣa ra,
ta nên làm hai tài liệu song song, những gì ngƣời dùng cần, và những gì một hệ thống sẽ
phải làm để đáp ứng nhu cầu đó. Đây là các yêu cầu ngƣời dùng và các đặc tả hệ thống
theo thứ tự định sẵn.
Vậy tại sao cần có các yêu cầu phần mềm tốt? Bất kỳ lỗi nào đƣợc phát hiện trong
giai đoạn đầu trong quá trình phát triển dự án phần mềm là kết quả rất quan trọng. Nếu ở
các giai đoạn sau lỗi mới đƣợc phát hiện ra thì chi phí cho việc sửa chữa hệ thống phần
mềm sẽ tốn kém hơn rất nhiều. Nếu những ngƣời thiết kế hệ thống hƣớng tới mục tiêu
không đúng, việc thực thi hệ thống sẽ đi chệch với mong muốn ban đầu. Một yêu cầu sai
có thể tạo ra hàng loạt các lỗi thiết kế. Vì vậy để một sản phẩm phần mềm tốt thì điều đầu
tiên quan trọng là chúng ta phải có các yêu cầu tốt.
1.2. Khái niệm về Test case
Trong quá trình phát triển dự án phầm mềm, thông thƣờng một quy trình kiểm thử
có các bƣớc cơ bản nhƣ sau: lập kế hoạch, thiết kế Test, phát triển test script, thực hiện
test và đánh giá (xem Hình 1)


Trong đó Test case đƣợc viết trong bƣớc thiết kế test. Mục đích của thiết kế test là
viết và chỉ định các Test case trong các bƣớc kiểm tra chi tiết cho mỗi phiên bản phần
mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm
tra "quét" hết tất cả yêu cầu cần kiểm tra.
Vì vậy công việc tạo ra các Test case hiệu quả là đặc biệt quan trọng để đảm bảo
chất lƣợng phần mềm. Để làm đƣợc việc đó, trƣớc hết phải hiểu Test case là gì?
Một Test case có thể coi là một tình huống kiểm thử, đƣợc thiết kế để kiểm thử một đối
tƣợng có thỏa mãn yêu cầu đặt ra hay không. Một Test case thƣờng bao gồm 3 phần cơ
bản:
• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm thử.
• Đầu vào: đặc tả đối tƣợng hay dữ liệu cần thiết, đƣợc sử dụng làm đầu vào để

thực hiện việc kiểm thử.
• Kết quả mong muốn: kết quả trả về từ đối tƣợng kiểm thử, chứng tỏ đối tƣợng đã
thỏa mãn yêu cầu.
Test case có một ý nghĩa vô cùng quan trọng, mục đích đƣa ra các trƣờng hợp test
nhằm phát hiện ra các lỗi nhiều nhất có thể, để cho các dự án phát triển phần mềm có chất
lƣợng tốt hơn.
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm .
Trong quá trình phát triển dự án phần mềm, thƣờng công việc tạo ra các Test case
từ yêu cầu ngƣời dùng do các Tester phụ trách. Nhƣng không phải Tester nào viết các tài
liệu Test case này cũng nhƣ nhau.Vì vậy trong các công ty phần mềm cũng nhƣ các tổ
chức thực hiện dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tài liệu Test
case tốt, có hiệu quả thì chất lƣợng phần mềm sẽ tốt hơn những dự án có các Test case tồi
(có nhiều trƣờng hợp test trùng lặp nhau hoặc thiếu các trƣờng hợp test). Vậy chúng ta
phải chuẩn hóa và đồng bộ hóa để làm sao tạo ra Test case một cách hiệu quả và có chuẩn
về chất lƣợng. Để làm điều này, chúng ta phải nghiên cứu các phƣơng pháp và kỹ thuật
để tự động tạo ra các Test case. Việc tạo ra Test case một cách tự động cũng làm giảm
bớt công sức và thời gian của các tester, giúp giảm bớt chi phí phát triển phần mềm.
Qúa trình tạo ra các Test case sẽ giúp các tester phát hiện ra các vấn đề mâu thuẫn
hoặc chƣa rõ ràng của các yêu cầu phần mềm. Nếu bƣớc này đƣợc làm sớm, các vấn đề
có thể đƣợc loại bỏ sớm, tiết kiệm thời gian và nguồn lực khi phát triển các dự án phần
mềm.
Vậy việc nghiên cứu các phƣơng pháp và công cụ sinh Test case một cách tự động
từ yêu cầu ngƣời dùng rất hữu ích và cần thiết trong quá trình phát triển các dự án phần
mềm. Quá trình này nhằm mục đích tạo ra Test case một cách có hiệu quả, có chất lƣợng.


TÀI LIỆU THAM KHẢO
[1] Andras Toth, Daniel Varro, Andras Pataricca, 2003, Model Level Automatic Test
Generation for UML State-Charts, Sixth IEEE workshop on Design and Diagnostics
of Electronic Circuits and System, (DDECS 2003).

[2] Clay E. Williams, November 1999, Software testing and the UML, International
Symposium on Software Reliability Engineering (ISSRE’99), Boca, Raton.
[3] Jeff Offutt, Aynur Abdurazik, October 1999, Generating Tests from UML
specifications, Second International Conference on the Unified Modeling Language
(UML99).
[4] Jeff Offutt, Aynur Abdurazik, October 2000, Using UML Collaboration diagrams for
static checking and test generation, Third International Conference on UML, York,
UK.
[5] Jeff Offutt, Shaoying Liu, Aynur Abdurazik, Paul Ammann, March 2003, Generating
Test data from State based Specifications, The Journal of Software Testing,
Verification and Reliability.
[6] Matthias Riebish, Ilka Philippow, Marco Gotze, UML Based Statistical Test Case
Generation".