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 ĐỀ.....................................................................................6
1.1.
1.2.
1.3.
Tầm quan trọng của yêu cầu phần mềm..................................................................6
Khái niệm về Test case............................................................................................6
Vấn đề sinh Test case từ yêu cầu phần mềm ..........................................................7
CHƯƠNG 2.TỔNG QUAN VỀ QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG 8
2.1.
2.2.
2.2.1.
2.2.2.
2.2.3.
2.3.
Giới thiệu.................................................................................................................8
Tổng quan về các phương pháp sinh Test case........................................................8
Sinh Test case dựa trên đặc tả..................................................................................9
Sinh Test case dựa trên mô hình..............................................................................9
Sinh Test case hướng đường dẫn...........................................................................10
Kiểm thử phần mềm và UML................................................................................10
CHƯƠNG 3.CÁC KỸ THUẬT VÀ PHƯƠNG PHÁP SINH TEST CASE
TỰ ĐỘNG...............................................................................................................11
3.1.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.3.
3.3.1.
3.3.2.
Giới thiệu...............................................................................................................11
Kỹ thuật sinh Test case dựa trên đặc tả..................................................................12
Các phương thức đặc tả trạng thái SCR.................................................................13
Kỹ thuật sinh ra Test case dựa theo đặc tính của SCR...........................................14
Kỹ thuật tạo Test case cho đặc tả UML.................................................................21
Các thuận toán sinh Test case dựa trên đặc tả........................................................28
Kỹ thuật sinh Test case dựa trên mô hình..............................................................36
Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UML............................37
Tạo Test case dựa trên Use case cải tiến................................................................45
CHƯƠNG 4.PHÁT TRIỂN CHƯƠNG TRÌNH ỨNG DỤNG QUÁ TRÌNH
SINH TEST CASE TỰ ĐỘNG.............................................................................56
4.1.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.2.4.
4.3.
Mục tiêu.................................................................................................................56
Tóm tắt quá trình sinh Test case tự động...............................................................56
Ví dụ......................................................................................................................56
Các Test case của ví dụ..........................................................................................59
Tính ứng dụng, các lợi ich và hạn chế...................................................................59
Kết luận..................................................................................................................60
Cài đặt....................................................................................................................61
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
Số trang
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à 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
Số trang
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 và 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 viết 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ứ 2
sinh Test case tự động dựa trên code, chương trình có sẵn; thứ 3 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ứ 3 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 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 pham 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 sự
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)
Thực hiện Test
Lập kế
hoạch
Thiết kế
Test
Phát triển
Test Script
Đánh giá
Hình 1: Một quy trình kiểm tra cơ bản.
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 chất lượng các dự án phát triển
phần mềm được tốt hơn.
1.3. Vấn đề sinh Test case từ 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
Tester viết Test case tồi (có nhiều trường hợp test trùng lặp nhau). 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 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.
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. Giúp giảm bớt công sức và thời gian của các tester, làm giảm bớt chi phí
phát triển phần mềm và chất lượng phần mềm được nâng cao hơn.
CHƯƠNG 2.
TỔNG QUAN VỀ QUÁ TRÌNH
SINH TEST CASE TỰ ĐỘNG
2.1. Giới thiệu
Việc test phần mềm là một công việc rất quan trọng trong vòng đời phát triển
của phần mềm. Để cắt giảm chi phí của việc test bằng tay và tăng độ tin cậy của phần
mềm thì chúng ta đang cố gắng thực hiện tự động hóa nó. Một trong những công việc
quan trọng trong môi trường test là tạo ra Test case một cách tự động mô tả về cách
thức test, mỗi một hệ thống phần mềm nhất định được thiết lập theo một cách thức độc
lập. Chương này trình bày cách nhìn tổng quan về kỹ thuật tạo Test case một cách tự
động.
Các tổ chức phần mềm sử dụng một phần ngân sách đáng kể của mình để thực
hiện các công việc liên quan đến test. Một hệ thống phần mềm test tốt sẽ được kiểm
chứng bởi khách hàng trước khi chấp nhận, làm thỏa mãn yêu cầu của khách hàng.
Tính hiệu quả của qúa trình xác nhận và kiểm chứng này phụ thuộc vào số lượng lỗi
được phát hiện và chỉnh sửa trước khi công bố hệ thống. Điều này lần lượt phụ thuộc
vào chất lượng của các Test case được tạo ra.
Các phương pháp khác nhau về việc sinh ra Test case đã được đề xuất. Một Test
case là một sự miêu tả cách thức test, mỗi một hệ thống phần mềm nhất định được
thiết lập theo một cách thức độc lập. Test case có thể được viết ra trực tiếp từ yêu cầu
người dùng, từ các yêu cầu hệ thống, hoặc từ các use case. Một trong những lợi thế
của việc tạo ra Test case từ các đặc tả và thiết kế đó là chúng có thể được sinh ra sớm
hơn trong vòng đời phát triển và sẵn sàng để sử dụng trước khi các chương trình được
tạo ra. Thêm vào đó, khi các Test case được sinh ra ban đầu các kỹ sư phần mềm phát
hiện ra sự không nhất quán và mập mờ trong đặc tả các yêu cầu và các tài liệu thiết kế.
Điều này sẽ chắc chắn sẽ làm giảm chi phí của việc xây dựng hệ thống phần mềm khi
các lỗi được loại bỏ sớm trong vòng đời phát triển của sản phẩm.
2.2. Tổng quan về các phương pháp sinh Test case
Một vài cách tiếp cận được đưa ra trong việc tạo ra Test case, một số mang tính
ngẫu nhiên, có mục đích, định hướng và một số rất thông minh. Kỹ thuật ngẫu nhiên
xác định các Test case dựa trên các giả định. Kỹ thuật định hướng đường dẫn sử dụng
các luồng thông tin kiểm soát để xác định một tập hợp các đường dẫn để được bao
quát và tạo ra các Test case phù hợp cho các đường dẫn này. Những kỹ thuật này có
thể được phân chia thành tĩnh và động. Kỹ thuật tĩnh thường được dựa trên thực thi
các ký hiệu mô tả, ngược lại các kỹ thuật động đạt được từ các dữ liệu cần thiết bằng
việc chạy chương trình trong khi test. Kỹ thuật định hướng mục tiêu xác định các Test
case bao gồm một mục tiêu đã được lựa chọn chẳng hạn một câu lệnh hoặc nhánh câu
lệnh. Các kỹ thuật thông minh của các Test case được sinh ra tự động lệ thuộc vào các
tính toán phức tạp để xác định Test case.
Rất nhiều nghiên cứu về việc sinh ra các Test case tối ưu dựa trên các đặc tả,
tuy nhiên không thể đạt 100% các Test case tối ưu. Ngôn ngữ mô hình được sử dụng
để có được đặc tả và sinh ra các Test case. Kể từ khi UML (Unified Modeling
Language) là ngôn ngữ được sử dụng rộng rãi nhất thì nhiều nghiên cứu sử dụng lược
đồ UML như state-chart diagrams, use-case diagrams, sequence diagrams,… để sinh
ra các Test case và dẫn đến việc sinh ra Test case dựa trên mô hình.
2.2.1. Sinh Test case dựa trên đặc tả
Sinh Test case dựa trên đặc tả là phương pháp sinh Test case mà phỏng theo trạng
thái được xác định trước dựa trên đặc tả để tạo ra Test case từ biều đồ trạng thái UML.
Việc kiểm thử đủ các thuộc tính, các cặp chuyển tiếp và chỉnh sửa các câu lệnh là các
kỹ thuật được đưa ra trong Chương 3. Các kỹ thuật đã sử dụng các biểu đồ trạng thái
UML như một cở sở và tự động sinh ra các bộ phận điều khiển test và test script để xác
nhận các thành phần khi test. Cách tiếp cận trong một mẫu, chỉ ra các lớp và đặc tả
biểu đồ trạng thái tương ứng cho hành vi của lớp đó, định rõ ánh xạ đưa ra bằng sự kết
hợp các mã với đặc tả. Sau đó tester chọn các tiêu chuẩn để chỉnh sửa. Tóm lại, các lỗi
được phát hiện ra như sự không nhất quán giữa hành vi và đặc tả biểu đồ trạng thái
được đưa ra bởi người sử dụng. Mục tiêu là để xác định các đặc tả được cải tiến được
dựa trên các tiêu chuẩn chỉnh sửa thích hợp cho hệ thống và để phát triển các kỹ thuật
cho việc tạo ra bộ điều khiển test với ít nhất thao tác của con người.
2.2.2. Sinh Test case dựa trên mô hình
UML đã nhận được một sự quan tâm lớn từ các công đồng phát triển và thiết kế
phần mềm, và các công việc đang được thực hiện để tăng cường và mở rộng các tính
năng của nó. Tuy nhiên, cộng đồng test phần mềm đã không quan tâm nhiều và thảo
luận nhiều về UML, sự thiếu hụt lớn khi tiêu chuẩn mô hình hóa được phát triển. Đây
là vấn đề cần quan tâm, bởi vì trong các tổ chức phát triển phần mềm, chi phí của việc
test có thể chiếm hơn 40% tổng chi phí phát triển cho một hệ thống phần mềm. Đưa ra
các thực tế này để phát hiện ra khả năng sử dụng UML cho việc test phần mềm.
Đa phần công việc test dựa trên mô hình của các hệ thống tập trung vào việc sử
dụng của các biểu đồ trạng thái hoặc lớp.Các biểu đồ lớp chỉ một tập các lớp, các giao
diện và các sự cộng tác, các mối quan hệ của chúng. Các biểu đồ trạng thái biểu diễn
dòng điều khiển từ trạng thái này đến trạng thái khác, nó nhấn mạnh dòng điều khiển
từ hoạt động này đến hoạt động khác xảy ra bên trong một máy trạng thái. UML có
một phương pháp mô hình trước đó được biết đến là kỹ thuật mô hình đối tượng
(Object Modeling Technique) mà đã thêm một mô hình chức năng cũng được sử dụng
cho quá trình test.
2.2.3. Sinh Test case hướng đường dẫn
Một khung chuẩn sử dụng chiến lược tìm kiếm nhị nguyên nổi tiếng trong việc
sinh ra Test case hướng đường dẫn đã được đưa ra. Toán tử được đề xuất có thể được
phận loại như cách tiếp cận hướng tới đường dẫn. Phương pháp này đã nêu vấn đề của
các cách tiếp cận sinh ra Test case tự động và đã cung cấp một giải pháp với thuật toán
sinh ra Test case dựa trên phương thức tìm kiếm nhị nguyên. Đường dẫn được bao
quát được xem xét từng bước từng bước một và các Test case sau đó được nghiên cứu
để hoàn thiện chúng. Phương thức tìm kiếm nhị nguyên được sử dụng đề xác định các
Test case, đòi hỏi các giả định nhất định nhưng cho phép sinh ra Test case hiệu quả.
Các lợi thế của phương pháp này đó là nó không đòi hỏi bất cứ một một sự điều chỉnh
tham số nào và không cần bất cứ kỹ thuật tối ưu nào để tạo ra dữ liệu test.
2.3. Kiểm thử phần mềm và UML
Có nhiều giai đoạn trong quá trình test phần mềm gồm đơn vị, chức năng, hệ
thống, hồi qui, và test giải pháp. Bảng sau minh họa những sự khác biệt giữa các giai
đoạn, cũng như biều đồ UML tiềm năng cho việc sử dụng trong các giai đoạn.
Test Type
(Loại test)
Coverage
Criteria
Fault Model
(mô hình lỗi)
Correctness, error handling pre/post
conditions, invariants
Functional and API behavior,
intergration issuses
UML Diagram
(biều đồ UML)
Class and state
diagrams
Interaction and class
diagrams
Use case, activity, and
interaction diagrams
Unit
Code
Function
Functional
System
Operational
scenarios
Workload, contention, synchron,
recovery
Regresstion
Functional
Unexpected behavior from
new/changed function
SAME AS FUNCTION
Solution
Inter-System
commun
Interop. Problems
Use case and
deployment diagrams
Bảng 1: Phân biệt các biểu đồ UML và các mức độ test
Tuy nhiên, vấn đề của việc sử dụng UML không kết thúc bằng sự chú ý đơn
thuần trong quá trình test mà các biểu đồ có thể được sử dụng hữu ích trong nhiều giai
đoạn khác nhau của quá trình này. Một vài vấn đề phải được giải quyết trước khi UML
có thể được áp dụng hiệu quả trong quá trình test [2].
Có 2 vấn đề sau: Vấn đề đầu tiên quan tâm là các vấn đề liên quan đến việc sử
dụng các mô hình UML trong quá trình test. Tester hiểu được sự quan trọng của việc
xây dựng hoặc chỉnh sửa cơ bản các mô hình để được sử dụng trong quá trình test.
Thứ hai, các mô hình từ quá trình phát triển thiếu đi các chi tiết và tính năng đặc thù
mà được yêu cầu để phát triển các Test case.
CHƯƠNG 3.
CÁC KỸ THUẬT VÀ PHƯƠNG PHÁP SINH
TEST CASE TỰ ĐỘNG
3.1. Giới thiệu
Test phần mềm là công việc chạy một chương trình trên một bộ các Test case và
so sánh kết quả thực tế của với các kết quả mong muốn. Test và thiết kế test là các giai
đoạn để đảm bảo chất lượng phần mềm, tập trung vào việc phát hiện lỗi. Chúng ta nên
tìm các nguyên nhân để có thể phát hiện ra các triệu chứng được gây ra các lỗi. Cuối
cùng, khi test nên cung cấp chẩn đoán rõ ràng để các lỗi có thể dễ dàng được sửa chữa.
Vậy trong quá trình test phần mềm “tiêu chuẩn test là gì”. Một tiêu chuẩn test là
một quy tắc hoặc một tập hợp của các quy tắc mà áp đặt các yêu cầu vào một bộ của
các Test case. Có nhiều cách để phân loại các tiêu chuẩn phù hợp. Một trong những
cách thông dụng nhất là bằng nguồn thông tin được sử dụng để xác định các yêu cầu
test và sự phù hợp của test. Do đó, một tiêu chuẩn phù hợp có thể là được dựa trên đặc
tả hoặc dựa trên chương trình.
Một tiêu chuẩn dựa trên đặc tả xác định công việc test được yêu cầu trong điều
kiện của các chức năng khác nhau của các đặc tả phần mềm, vì vậy một bộ test là phù
hợp nếu tất cả các chức năng được xác định đã được đưa ra đầy đủ vào các Test case.
Ở đây các đặc tả được sử dụng để tạo ra các Test case, cũng như tạo ra chương trình.
Một cái nhìn trừu tượng về quá trình test dựa trên đặc tả được đưa ra trong Hình số 2.
Một tiêu chuẩn được dựa trên chương trình xác định các yêu cầu test trong điều
kiện chương trình đang test và quyết định nếu một bộ test là phù hợp theo chương
trình đã được thử nghiệm kỹ lưỡng hay không. Một quan điểm trừu tượng về quá trình
test được dựa trên chương trình được cho thấy ở Hình số 3.
Chú ý rằng cả test dựa trên chương trình và test dựa trên đặc tả, tính chính xác
của các kết quả chương trình phải được kiểm tra với các yêu cầu hoặc đặc tả. Tuy
nhiên, trong cả hai trường hợp, đánh giá sự phù hợp của test không phụ thuộc vào các
kết quả của việc kiểm tra này. Thêm vào đó, sự định nghĩa về các tiêu chuẩn được dựa
trên đặc tả đã đưa trước đó không coi là sự tồn tại của một đặc tả chuẩn.
Hình 2:Kiểm thử dựa trên đặc tả
Hình 3: Kiểm thử dựa trên chương trình
3.2. Kỹ thuật sinh Test case dựa trên đặc tả
Kiểm thử dựa trên đặc tả lấy được các thông tin test từ một đặc tả của phần
mềm khi test.Tuy nhiên, khi việc thực hiện được phát triển không chuẩn mực từ một
đặc tả chuẩn mực, đặc tả có thể đóng một vai trò chủ yếu trong quá trình test bằng
cách cho phép chúng ta thu được các đầu vào test và các kết quả mong đợi từ các đầu
vào này. Có hai vai trò chính một đặc tả có thể đóng vai trò trong test phần mềm [3].
Đầu tiên là cung cấp các công tin cần thiết để kiểm tra hoặc là đầu ra của chương trình
có đúng hay không. Thứ hai là cung cấp thông tin để lựa chọn các Test case và để đánh
giá sự phù hợp của test.
Kiểm thử dựa trên đặc tả đưa ra nhiều ưu điểm trong test phần mềm. Đặc tả
chuẩn của một sản phầm phần mềm có thể được sử dụng như một sự hướng dẫn cho
việc thiết kế các test chức năng cho sản phẩm. Đặc tả xác định chính xác các khía cạnh
cơ bản của phần mềm, trong khi thông tin cấu trúc và chi tiết bị loại bỏ. Dó đó, tester
có các thông tin thiết yếu về tính năng của sản phẩm không phải triết xuất nó ra từ các
chi tiết thiết yếu.
Kiểm thử dựa trên đặc tả từ các đặc tả chuẩn đưa ra một cách tiếp cận chuẩn
hơn, được cấu trúc và đơn giản hơn cho sự phát triển của các test chức năng hơn là các
kỹ thuật test không dựa trên đặc tả. Mối quan hệ mạnh mẽ giữa đặc tả và test giúp phát
hiện ra các lỗi và có thể đơn giản quá trình hồi quy. Đặc tả là một bản mô tả thẩm
quyền của hành vi hệ thống và có thể được sử dụng để lấy được các kết quả mong
muốn cho các dữ liệu test. Các lợi ích khác của kiểm thử dựa trên đặc tả gồm phát
triển test cùng lúc với việc thực hiện và thiết kế, sử dụng các test đã lấy được để phê
chuẩn đặc tả gốc, và kiểm định đã được đơn giản của quá trình test. Đặc tả có thể cũng
được phân tích tương ứng với khả năng test ổn định.
Có ba cách tiếp cận chính tới các đặc tả chức năng phần mềm chuẩn: (1) các
đặc tả dựa trên mô hình, (2)các đặc tả định hướng đến thuộc tính chẳng hạn các đặc tả
thuật toán và có nhiều ngôn ngữ, và (3) các đặc tả dựa trên trạng thái.
Các ngôn ngữ đặc tả dựa trên mô hình, cố gắng để có được các đặc tả chuẩn của
phần mềm dựa trên các mô hình của các đối tượng thực tế. Ngôn ngữ đặc tả thuật toán
mô tả phần mềm bằng việc đưa ra các câu lệnh chuẩn, về các mối quan hệ trong số
các thao tác và các chức năng mà có tác dụng lên chúng. Các đặc tả dựa trên trạng thái
mô tả phần mềm trong điều kiện của các chuyển tiếp trạng thái. Các đặc tả được dựa
trên trạng thái tiêu biểu xác định điều kiện trước trên các chuyển tiếp, mà là các giá trị
mà các biến xác nhận phải có cho các chuyển tiếp có thể được phép, các thay đổi trong
các giá tri biến đổi mà khiến các chuyển tiếp được diễn ra.
3.2.1. Các phương thức đặc tả trạng thái SCR
Có một vài phương pháp để xác định các hệ thống trạng thái cơ bản. Phương
pháp này xác định các tiêu chuẩn test dựa trên đặc tả, và đã phát triển một mô hình
sinh Test case cho các đặc tả SCR.
Đặc tả Software Cost Reducation (SCR) xây dựng các bảng để xác định các yêu
cầu hành vi cho các hệ thông phần mềm được gắn vào thời gian thực tế. Một lợi ích
của phương pháp SCR đó là cấu trúc được xác định tốt cho phép các phân tích cấu trúc
được sử dụng để kiểm tra sự đồng nhất, tính hoàn chỉnh của đặc tả. Bên cạnh đó, các
ứng dụng SCR cung cấp khả năng phát hiện dấu vết từ các yêu cầu phần mềm tới mã
nguồn. Nhiều loại của các phân tích đã được áp dụng tới các đặc tả SCR.
Trong một đặc tả SCR, một mode class là một máy trạng thái mà trạng thái của
nó được gọi là system modes hoặc modes. Hành vi của Complex system có thể được
xác định bởi một vài mode class hoạt động song song. Mỗi mode class mô tả một khía
cạnh của hành vi của hệ thống, và hành vi bao trùm của toàn bộ hệ thống được xác
định bởi thành phần của các mode class của hệ thống. Môi trường của hệ thống được
đưa ra bởi một tập hợp của các điều kiện môi trường Boolean. Một event xuất hiện
khi các giá trị của một điều kiện thay đổi từ True thành False hoặc ngược lại. Do đó,
các event xác định các thời điểm, trong khi các điều kiện xác định khoảng thời gian.
Thông thường, một conditional event là một event mà xuất hiện khi các điều kiện nhất
định tiếp tục.
Các mode và mode transitions xác định các thuộc tính của hệ thống mà giữ
những điều kiện nhất định. Một mode invariant phải là True khi hệ thống tham gia vào
mode, phải duy trì True trong khi hệ thống ở trong mode đó, và có thể hoặc là True
hoặc là False khi hệ thống không còn ở trong mode đó. Sự không thay đổi của mode là
các thuộc tính bất biến của một mode hệ thống. Nếu các điều kiện nhất định tiếp tục
sau đó hệ hoặc là hệ thống là ở trong một mode cụ thể, các điều kiện hệ thống nhất
định có các giá trị bất biến. Các đặc tả SCR xác định hành vi chức năng hệ thống phần
mềm. Sự bất biến của hệ thống là rõ ràng hoặc đôi khi là rõ ràng được xác định trong
đặc tả. Một đặc tả SCR có thể gồm một bộ của các biến không đổi an toàn như một sự
khẳng định, nhưng hệ thống các biến không đổi này không phải là các ràng buộc thêm
vào của hành vi đuợc yêu cầu, chúng không đuợc tính vào, chỉ là các mục tiêu mà các
yêu cầu được trình bày thành dạng bảng được mong muốn được đưa đến. Thêm vào
đó, nếu các biến bất biến này không đuợc liệt kê rõ ràng, sau đó chúng ta có thể nên
lấy chúng từ đặc tả. Các biến không đổi có được có thể được so sánh với các biến rõ
không đổi rõ ràng giống như các tiêu chuẩn xác định.
3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tính của SCR
Kiểm thử các mức độ trong phát triển phần mềm thực tế đã được thực hiện từ
lâu được dựa trên các phân tích không chuẩn mực của các yêu cầu phần mềm. Điều
này dẫn đến các kết quả không thống nhất, các vấn đề trong việc hiểu mục đích và kết
quả của việc kiểm thử, hoàn thành thiếu tính hiệu quả trong việc kiểm thử. Việc xác
định đúng cho một yêu cầu rõ ràng để thực hiện kiểm thử bởi chúng mô tả chính xác
phần mềm đóng vai trò như thế nào trong việc trợ giúp việc cung cấp một mẫu cái mà
có thể tự động điều khiển. Kỹ thuật sinh Test case dựa theo đặc tả SCR thiết lập các
tiêu chuẩn và giải quyết việc sinh ra các ca kiểm thử mức độ hệ thống từ các xác
nhận/các yêu cầu chức năng. Những tiêu chuẩn này cung cấp một quá trình chuẩn, một
phương pháp để đo lường việc kiểm thử, và một nền tảng cho việc tự động hóa hoàn
toàn việc tạo ra các ca kiểm thử.
3.2.2.1. Mô hình kiểm thử
Thỏa mãn thuộc tính sử dụng các điều kiện đầu vào, các biến, và luôn luôn
đúng để tạo ra kết quả, sau đó sinh ra các Test case để thỏa mãn các yêu cầu riêng biệt
trong một kết quả xác nhận. Công việc này liên quan chặt chẽ đến việc nghiên cứu sự
tạo ra kiểm thử tự động được dựa trên mã hóa trước đó. Mộ hình được đưa ra ở đây
phát triển thêm các ý tưởng trước đó về sự thỏa mãn các kết quả xác nhận theo một số
cách [5]
Thay cho việc chỉ bao hàm các điều kiện trước và sau thì rất quan trọng để sử
dụng việc kiểm thử để liên hệ chặt chẽ các điều kiện trước và sau. Việc kiểm thử nhằm
mục đích phát hiện ra các lỗi, bao gồm cả vùng dữ liệu đưa vào. Phần này đưa ra các
ví dụ sử dụng Software Cost Reduction Specifications (SCR).
Trong mô hình này, các việc kiểm thử được tạo ra như một sản phẩm đa mức
độ, nhiều bước thực hiện và nhiều phần. Nhiều phần có nghĩa là một Test case sinh ra
một vài thành phần. Các giá trị đầu vào là các giá trị đầu vào của Test case, những giá
trị này cần được thỏa mãn trực tiếp các yêu cầu. Các thành phần khác cung cấp các giá
trị hỗ trợ, gồm các kết quả đầu ra được mong đợi, các dữ liệu đầu vào cần thiết để có
trạng thái phù hợp. Nhiều bước có nghĩa là việc kiểm thử sinh ra một số bước từ các
đặc tính chức năng bởi một quá trình xử lý. Các đặc tính chức năng được lọc trong các
đặc tính kiểm thử, cái mà sau đó được lọc trong các tập lệnh. Đa mức độ có nghĩa là
việc kiểm thử tạo ra để kiểm thử phần mềm ở một số mức độ trừu tượng hóa.
Mô hình này định nghĩa Test case tại bốn mức độ: (1) mức độ chỉnh sửa kế tiếp,
(2) mức độ chỉnh sửa đầy đủ các thuộc tính, (3) mức độ chỉnh sửa từng cặp kế tiếp, và
(4) mức độ thứ tự hoàn thành. Các định nghĩa về từng mức độ được định nghĩa ở dưới.
Để áp dụng những mức độ này, các đặc tính/yêu cầu được dựa trên trạng thái được
nhìn nhận như một đồ thị trực tiếp, được gọi là đồ thị đặc tả. Mỗi nút cho thấy một
trạng thái trong đặc tính/yêu cầu, và các cạnh đưa ra những sự chuyển tiếp có thể.
Có thể áp dụng tất cả các mức độ này, hoặc lựa chọn một mức độ được dựa trên sự cân
bằng lợi ích và chi phí. Hai mức độ đầu tiên là có mối liên quan đến nhau, mức độ
chỉnh sửa kế tiếp đòi hỏi các Test case ít hơn nhiều so với mức độ chỉnh sửa đầy đủ
các thuộc tính, nhưng nếu mức độ chỉnh sửa đầy đủ các thuộc tính được sử dụng, việc
kiểm thử sẽ thỏa mãn được mức độ chỉnh sửa kế tiếp. Do vậy chỉ một trong hai mức
độ nên được sử dụng. Hai mức độ sau có ý nghĩa độc lập, chỉnh sửa các cặp chuyển
tiếp hướng đến để kiểm thử các giao diện giữa các trạng thái; và kiểm thử các kết quả
hoàn thành là hướng đến kiểm thử phần mềm bằng việc thực thi phần mềm thông qua
các luồng xử lý hoàn chỉnh. Như nó đã diễn ra, chỉnh sửa các cặp chuyển tiếp vào
trong sự chuyển tiếp, nhưng chúng được thiết lập để kiểm thử phần mềm trong rất
nhiều cách khác nhau.
(1) Mức độ chỉnh sửa kế tiếp
Mức độ này là tương tự với tiêu chuẩn chỉnh sửa nhánh trong kiểm thử cấu trúc.
Yêu cầu ở đây là mỗi sự chuyển tiếp trong đồ thị đặc tả được thực hiện ít nhất một lần.
Điều này là một cách khác của việc đòi hỏi rằng mỗi điều kiện ban đầu trong một đặc
tả được thỏa mãn ít nhất một lần.
Tóm lại, mức độ chỉnh sửa kế tiếp đòi hỏi mỗi sự chuyển tiếp trong đồ thị đặc
tả được thực hiện ít nhất một lần.
(2) Mức độ chỉnh sửa đầy đủ các thuộc tính
Một câu hỏi trong khi kiểm thử đó là các thuộc tính trong đặc tả có được lập
công thức chính xác hay không. Những sai xót nhỏ trong các đặc tả có thể dẫn tới rắc
rối lớn khi phát triển sản phẩm phần mềm. Mức độ chỉnh sửa đầy đủ các thuộc tính
thực hiện vai trò kiểm thử phân mềm, ít nhất chúng ta nên cung cấp các dữ liệu đầu
vào để kiểm thử mỗi mệnh đề. Mức độ này đòi hỏi rằng mỗi mệnh đề trong mỗi thuộc
tính trên mỗi sự chuyển tiếp được kiểm thử một cách độc lập, do đó cố gắng để nêu rõ
câu hỏi về mệnh đề nào là cần thiết và nó đã được lập công thức chính xác hay chưa.
Một mệnh đề là một biểu thức Boolean mà không bao gồm những toán tử
Boolean. Ví dụ, các biểu thức liên quan và các biến số Boolean là các mệnh đề.
Một thuộc tính là một biểu thức Boolean nó gồm các mệnh đề và không hoặc
nhiều toán tử Boolean. Một thuộc tính không có một toán tử Boolean cũng là một
mệnh đề. Nếu một mệnh đề xuất hiện hơn một lần trong một thuộc tính, mỗi sự xuất
hiện là một mệnh đề riêng biệt.
Quan điểm về chỉnh sửa các thuộc tính đầy đủ được dựa trên tiêu chuẩn kiểm
thử cấu trúc của việc sửa quyết định/điều kiện, mà đòi hỏi mọi quyết định và rất nhiều
điều kiện trong quyết định đã dẫn đến mỗi kết quả ít nhất một lần, và mỗi điều kiện đã
cho thấy ảnh hưởng độc lập đối với quyết định của nó. Sửa đầy đủ các thuộc tính được
định nghĩa như sau:
Sửa đầy đủ các thuộc tính: Mỗi mệnh đề lần lượt lấy giá trị đúng và sai trong
khi tất cả các mệnh đề khác trong thuộc tính đều lần lượt có các giá trị, giá trị của
thuộc tính sẽ luôn luôn giống như mệnh đề được kiểm thử.
Sự định nghĩa này bảo đảm rằng mỗi mệnh đề được kiểm thử không bị ảnh
hưởng bởi những mệnh đề khác. Nhớ rằng nếu chỉnh sửa đầy đủ các thuộc tính được
thực hiện, sự chỉnh sửa kế tiếp sẽ được thực hiện. Để thỏa mãn đòi hỏi đó thì kiểm tra
mệnh đề kiểm soát trị của thuộc tính, các mệnh đề khác phải là đúng hoặc là sai. Nếu
thuộc tính là (X^Y), và mệnh đề kiểm thử là X, thì Y phải đúng. Tương tự như vậy,
nếu thuộc tính là (X v Y), Y phải là sai.
Cách đơn giản để thỏa mãn đầy đủ các thuộc tính là sử dụng một cây biểu thức
từng phần. Một cây biểu thức từng phần là một cây nhị phân mà có nhiều toán tử nhị
phân và nhiều toán hạng cho các nút nội bộ, và các biến hoặc các hằng số tại các nút
lá. Các toán tử nhị phân liên quan là And (^), Or (v), và các toán tử liên quan {> , < , ≤
, ≥, =, ≠}; toán tử Not.
Ví dụ, cây biểu thức từng phần cho (A v B)^C là:
Đưa ra một cây từng phần, một sự chỉnh sửa đầy đủ thuộc tính bằng việc đi trên
cây. Đầu tiên, một mệnh đề kiểm thử được chọn. Sau đó cây từng phần được đi từ
mệnh đề kiểm thử tới gốc, sau đó từ gốc đi tới mỗi mệnh đề. Nếu mẹ của nó là V, anh
chị em của nó phải có giá trị False, nếu cha mẹ của nó là ^, anh chị em của nó phải có
giá trị True. Nếu một nút là toán tử not, nút mẹ được cho giá trị ngược của nút con.
Điều này lặp lại cho mỗi nút giữa mệnh đề kiểm thử và mệnh đề gốc.
Một khi mệnh đề gốc đã đạt được, các giá trị có thể được sinh ngược trở lại sử
dụng việc di chuyển cây đơn. Nếu một nút ^ có giá trị True, thì cả hai con phải có giá
trị True, nếu một nút ^ có giá trị False (xem hình 4), thì một trong hai con cũng phải có
giá trị False (cái nào cũng được). Nếu một nút V có giá trị False, thì cả hai con phải có
giá trị False; nếu một nút V có giá trị True, thì một trong hai con phải có giá trị False
(cái nào cũng được). Nếu một nút là toán tử Not, nút mẹ cho giá trị ngược của nút con.
Hình 4: Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp
Hình số 4 minh họa quá trình cho biểu thức bên trên, chỉ ra cả B và C của mệnh
đề kiểm thử. Trong trình từ trên, B là mệnh đề kiểm thử (được chỉ ra trong hộp có ô
được gạch). Trong cây 2, nhánh của nó, A được gán cho giá trị False, và trong cây 3, C
được gán giá trị True. Trong trình từ cuối cùng, C là mệnh đề kiểm thử. Trong cây 2,
nhánh của C là một nút V, và được gán cho giá trị True. Trong cây 3, A được gắn giá trị
True. Ghi nhớ rằng trong cây 3, A hoặc B có thể được gán giá trị True; tùy vào sự lựa
chọn.
Mẫu Test case đầy đủ thuộc tính từ cả sự dịch chuyển phù hợp và không phù
hợp, với chỉ một sự chuyển tiếp là phù hợp mỗi lần. Thêm vào đó, các kỹ sư kiêm thử
có thể chọn những sự kết hợp đầy đủ ý nghĩa của các điều kiện. Kiểm thử với những
dữ liệu đầu vào không phù hợp có thề giúp tìm ra các lỗi trong khi thực hiện cũng như
sự trình bày rõ ràng của các đặc tả. Rất nhiều nhà phát triển tin rằng một thành phần
phần mềm có các trạng thái ban đầu tốt, nó là trách nhiệm của người sử dụng để bảo
đảm rằng các điều kiện ban đầu đó đã được đáp ứng. Điều này có nghĩa rằng thành
phần không cần được kiểm thử với các dữ liệu đầu vào mà đã vi phạm các điều kiện
đầu tiên. Không giải quyết một khía cạnh của vấn đề này, công nghệ được mô tả ở đây
cung cấp một cơ chế cho việc phát triển các dự liệu đầu vào không phù hợp; chúng có
thể được sử dụng hoặc không khi những người kiểm thử nhận thấy là phù hợp.
Như một ví dụ rõ ràng, xem xét công thức của cây phân đoạn được đề cập ở trên,
(A v B) ^ C. Bảng giá trị đúng sau đây cung cấp các giá trị cho mệnh đề kiểm thử:
(A v B) ^ C
1
T
2
F
3
T
4
F
5
T
6
F
Để chắc chắn yêu cầu mà mệnh đề kiểm thử phải kiểm soát kết quả cuối cùng,
bảng đúng từng phần phải được làm rộng ra như sau (cho hai thực thể cuối cùng, là A
hoặc B có thể là True, hoặc cả hai được gán giá trị True):
(A v B) ^ C
1
2
3
4
5
6
T
F
F
F
T
T
F
F
T
F
T
T
T
F
T
F
T
F
Một số ngôn ngữ đặc thù, chẳng hạn như SCR, xem xét các biến khởi động sự
kiện khác biệt so với các biến khác trong thuộc tính chuyển tiếp. Khi ở trong trường
hợp này, mệnh đề mà tương đương với các biến khởi động sự kiện nên đưa ra giá trị
khác nhau, nhưng nên duy trì các biến đó. Nếu nó không còn là một biến khởi động
nữa, tương đương với việc không Test case. Thêm vào đó, một biến khởi động sự kiện
thực tế xác định hai giá trị, một giá trị trước và một giá trị sau. Để kiểm thử đầy đủ các
thuộc tính với các biến khởi động sự kiện, cả giá trị trước và sau nên được kiểm thử.
Điều này được thực hiện bằng việc giả định hai phiên bản của biến khởi động sự kiện,
A và A’, ở đó A đưa ra giá trị trước và A’ cho ra giá trị sau của nó.
(3) Mức chỉnh sửa các cặp chuyển tiếp
Các mức độ kiểm thử trước đó là kiểm thử việc chuyển tiếp độc lập, nhưng
không kiểm thử trình tự của các chuyển tiếp trạng thái. Mức độ này đòi hỏi các cặp
chuyển tiếp đó thực hiện.
Mức chỉnh sửa cặp chuyển tiếp: Cho mỗi trạng thái S, tạo nên các yêu cầu kiểm
thử chẳng hạn đó cho mỗi chuyển tiếp đến và đi, cả hai sự chuyển tiếp phải được thực
hiện tuần tự.
Xem trạng thái sau:
Để kiểm thử trạng thái S ở mức độ cặp chuyển tiếp, phải kiểm thử sáu lần: (1)
từ 1 đến i, (2) 2 tới i, (3) 1 tới ii, (4) 2 tới ii, (5) 1 tới iii, và (6) 2 tới iii. Việc kiểm thử
này đòi hỏi các đầu vào phải thỏa mãn các thuộc tính: P1:Pi,:P1:Pii, P1:Piii, P2:Pi,
P2:Pii và P2:Piii.
(4) Mức độ tuần tự hoàn chỉnh
Không thể chắc chắn rằng bất kỳ kiểm thử thành công nào cũng có thể dựa trên
các phương pháp thông thường, đôi khi kinh nghiệm và sự hiểu biết của các kỹ sư
kiểm thử phải được sử dụng. Đặc biệt ở mức độ hệ thống, việc kiểm thử hiệu quả có
thể đòi hỏi một kiến thức chi tiết về lĩnh vực đó. Một mức độ trình tự hoàn chỉnh là
một tuần tự của các chuyển tiếp trạng thái mà tạo ra một sự sử dụng thực tiễn hoàn
chỉnh của hệ thống. Trong hầu hết các ứng dụng thực tế, số lượng các tuần tự có thể là
quá lớn để chọn tất cả các tuần tự hoàn chỉnh. Trong nhiều trường hợp, số các tuần tự
hoàn chỉnh là được xác định.
Mức độ tuần tự hoàn chỉnh: Các kỹ sư kiểm thử phải xác định các tuần tự đầy
đủ của các chuyển tiếp trên đồ thị đặc tả bằng việc chọn các tuần tự trạng thái nên
được đưa vào.
Đôi khi việc chọn các tuần tự nào chỉ có thể được quyết định bởi kỹ sư kiểm
thử với việc sử dụng kiến thức và kinh nghiệm của mình. Đây là một mức độ tự động
hóa ít nhất của quá trình kiểm thử.
3.2.2.2. Tổng kết
Phần này đưa ra một phương pháp để tạo ra các Test case. Phương pháp này
cho tất cả bốn mức độ của việc kiểm thử được đưa ra cùng nhau, bởi vì có một số khá
lớn trùng với nhau. Nếu không sử dụng cả bốn mức độ, một số bước này nên được bỏ
qua. Các bước được đưa ra để xây dựng cho việc làm tự động khi mà rất nhiều bước
có thể được phát triển.
Quá trình chung được chỉ ra ở hình 5, điều này đơn thuần phản ánh khía cạnh
các bước của quá trình sinh ra các ca kiểm thử.
Hình 5: Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR
- Xem thêm -
.DOC 
67 
63 
97 
