ĐẠ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Ĩ
3.2.1. Các phƣơng thức đặc tả trạng thái SCR 13
3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tả của SCR 14
3.2.3. Kỹ thuật tạo Test case cho đặc tả UML 21
3.2.4. Các thuận toán sinh Test case dựa trên đặc tả. 28
3.3. Kỹ thuật sinh Test case dựa trên mô hình 36
3.3.1. Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UML 37
3.3.2. 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 57
QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG 57
4.1. Mục tiêu 57
4.2. Tóm tắt quá trình sinh Test case tự động 57
4.2.1. Ví dụ 57
4.2.2. Các Test case của ví dụ 60
4.2.3. Tính ứng dụng, các ƣu điểm và nhƣợc điểm 60
4.2.4. Kết luận 61
4.3. Cài đặt 62 -2-
DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT Từ và cụm từ viết tắt
Viết đầy đủ
-3-
DANH MỤC CÁC HÌNH VẼ Stt
Tên hình vẽ
1
Một quy trình kiểm tra cơ bản.
2
Kiểm thử dựa trên đặc tả
3
Kiểm thử dựa trên chương trình
4
Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp
5
Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR
6
Sự kiện gọi (call events)
7
Sự kiện báo hiệu (signal events)
8
Sự kiện thời gian (time Events)
9
Sự kiện thay đổi (Change Events)
phát triển phần mềm.
25
Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3.
26
Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3
27
Mô hình cách sử dụng có thể cho ví dụ thư viện của bảng 3.
28
Mô hình hành vi
29
Các lược đồ test và các giá trị test
30
Test case cho kịch bản chính
-4-
DANH MỤC CÁC BẢNG BIỂU Stt
Tên bảng biểu
1
Phân biệt các biểu đồ UML và các mức độ test
2
Mẫu cải tiến các use case
3
Một ví dụ về mẫu chi tiết các use case
-5-
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
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)
Hình 1: Một quy trình kiểm tra cơ bản.
Lập kế
hoạch
Thiết kế
Test
Phát triển
Test Script
Đánh giá
Thực hiện Test -7-
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.
độ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.
-8-
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 giai đoạ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
ích 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
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 số mô hình chức năng cũng được sử
dụng cho quá trình test.
-10-
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
intergration issuses
Interaction and class
diagrams
System
Operational
scenarios
Workload, contention, synchron,
recovery
Use case, activity, and
interaction diagrams
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
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.
-12-
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
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 -14-
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ả của SCR
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à -15-
(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
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. -17-
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ự
2 F F F
3 F T T
4 F F F
5 T T T
6 T 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.
-20-
1. Phát triển các điều kiện chuyển tiếp. Bước đầu tiên để phát triển các điều
kiện chuyển tiếp là các thuộc tính định nghĩa dưới các điều kiện mỗi chuyển tiếp sẽ
được thực hiện. Với một vài ngôn ngữ đặc tả (ví dụ SCR), các điều kiện chuyển tiếp là
được mã hóa trực tiếp vào trong các đặc tả. Với các ngôn ngữ khác, các điều kiện có
thể phải được chuyển hóa.
2. Phát triển đồ thị đặc tả. Đồ thị đặc tả được mô tả trong hình 5. Nó có thể lấy
trực tiếp từ bảng đặc tả, và các cạnh được tự động với các điều kiện bắt nguồn từ bước 1.
Đây là một điểm tại quá trình tách biệt cho bốn mức độ kiểm thử.
3. Phát triển các yêu cầu kiểm thử việc chỉnh sửa chuyển tiếp.
Xuất phát từ các đặc tính chuyển tiếp. Các điều kiện từ bước 1 được liệt kê một
lần tại thời điểm tạo ra các yêu cầu kiểm thử.
4. Phát triển các yêu cầu kiểm thử thuộc tính đầy đủ.
Xây dựng các bảng đúng cho tất cả các thuộc tính trong đồ thị đặc tả. Việc kiểm
thử chỉnh sửa các thuộc tính có thể được dựa trên một cây biểu thức hoặc trực tiếp trên
các đặc tả. Nếu tất cả các bộ nối hợp lý là giống nhau (tất cả AND hoặc tất cả Or), nó
rất đơn giản để chỉnh sửa trực tiếp các giá trị của các mệnh đề trong các thuộc tính.
Tuy nhiên, nếu AND và OR được trộn tự do vào nhau, nó có ít lỗi hơn để tạo ra cây
biểu thức. Các ngôn ngữ đặc tả có dấu hiệu phân biệt giữa các sự kiện trigger và các
điều kiện đầu tiên; trong trường hợp này, các sự kiện trigger phải được đánh dấu đặc
biệt để các kỹ sư kiểm thử nhớ để đặt đầu vào đó sau các đầu vào của điều kiện đầu
tiên.
5. Phát triển các yêu cầu kiểm thử cặp chuyển tiếp.
(a) Xác định tất cả các cặp chuyển tiếp. Việc kiểm thử cặp chuyển tiếp được sắp
xếp các cặp giá trị điều kiện, mỗi giá trị điều kiện đại diện một đầu vào tới trạng thái
và một kết quả từ trạng thái. Chúng được tạo thành bởi việc liệt kê tất cả các chuyển
đọc trực tiếp từ bảng. Đồ thị đặc tả sau đó có thể được tự động tạo ra từ các trạng thái
và điều kiện chuyển tiếp. Các yêu cầu kiểm thử lấy dạng của các bảng có phần đúng
xác định trên các thuộc tính chuyển tiếp, các thuộc tính trạng thái, và các cặp của
thuộc tính trạng thái. Đưa ra đặc tả chức năng chuẩn, hầu như không phải tất cả các
yêu cầu kiểm thử này có thể được tạo ra một cách tự động. Tiền tố của một test case
gồm các đầu vào cần thiết để đặt hệ thống vào trong một trạng thái ban đầu nhất định.
Đưa ra biểu đồ đặc tả, nhiều trong số những tiền tố này có thể được tạo ra tự động. Nó
cũng có thể cải tiến tự động các đặc tả kiểm thử vào các tập lệnh kiểm thử. Cuối cùng,
các thuật toán cho việc tự động tạo ra các tập lệnh kiểm thử có thể được phát triển,
mặc dầu cú pháp đưa vào của chương trình sẽ là cần thiết. Bước cuối cùng, tạo ra việc
kiểm thử trình tự hoàn chỉnh, không thể được tự động hóa hoàn toàn. Nhưng một giao
diện phù hợp có thể đưa ra đồ thị đặc tả, và cho phép các tester chọn các trình tự của
các trạng thái bằng cách chỉ và nhấn vào màn hình. Mỗi lần một trạng thái được chọn,
việc chuyển tiếp từ trạng thái trước đó có thể được tự động dịch sang các giá trị và
được lưu giữ như một phần của Test case. Điều này sẽ cho phép công việc của tester
trở thành một công việc trí óc đơn thuần của việc lựa chọn các trình tự của các trạng
thái được đưa vào.
3.2.3. Kỹ thuật tạo Test case cho đặc tả UML
Phần này trình bày một cách chi tiết về làm thế nào để có thể sử dụng đặc tả UML
để tạo ra Test case, và qui trình làm như thế nào.
3.2.3.1. Mô hình kiểm thử
UML có thể được sử dụng để xác định một vùng rộng các khía cạnh của một hệ
thống. Các biểu đồ trạng thái là một nơi rõ ràng nhất để bất đầu với việc tạo ra dữ liệu
kiểm thử. Các biểu đồ UML được dựa trên các máy trạng thái hạn chế sử dụng một ký
hiệu biểu đồ trạng thái được mở rộng, và được sử dụng để đưa hành vi của một đối
tượng. Hành vi gắn kết cấu trúc của một đối tượng tới các thuộc tính của nó và các mối -22-
quan hệ để đối tượng có thể đáp ứng được những trách nhiệm của nó. Các phương
chuyển tiếp trong một máy trạng thái ảnh hưởng tới các máy trạng thái đang tồn tại
khác. Cuối cùng, danh sách toán tử xác nhận danh sách được ngăn cách bởi dấu hai
chấm của các chức năng (mỗi cái đi với một đối số) mà sẽ được gọi là một kết quả của
sự chuyển tiếp được thực hiện.
Trong các trạng thái, cả các hành động vào và ra, cũng như các hành động sắp
diễn ra, có thể được chỉ rõ. Một hành động vào là một chức năng mà được gọi khi
trạng thái được đưa vào (thậm chí khi sự chuyển tiếp được tự định hướng). Một hành
động thoát là một chức năng mà được thực hiện khi trạng thái được thoát (thậm chí
việc chuyển tiếp được tự định hướng). Các hành động chứng tỏ việc xử lý đang tiếp -23-
tục được hoàn thành, hoặc cho đến khi được ngăn chặn bởi một sự chuyển tiếp (thậm
chí khi sự chuyển tiếp bản thân nó được tự định hướng).
Các đối tượng kiểm thử cho mô hình chuyển tiếp trạng thái là các đường dẫn
chuyển tiếp, các đường dẫn thông qua biểu đồ đưa ra một chu kỳ sống toàn bộ của đối
tượng từ lúc sinh ra đến lúc bị phá hủy. Đó là, mỗi đối tượng kiểm thử đưa ra một trình
tự có thể của các trạng thái giữa việc sinh ra và mất đi của một đối tượng. Chúng ta
không thể kiểm thử một mô hình chu kỳ sống của đối tượng với mô hình hiện có, mà
chỉ là một phần của nó thôi.
UML phân loại các chuyển trạng thái vào trong năm loại sau: chuyển trạng thái
ở mức cao, chuyển trạng thái phức hợp, chuyển trạng thái bên trong, chuyển trạng thái
hoàn thành, chuyển trạng thái khả năng. Sự chuyển trạng thái ở mức cao có nguồn gốc
từ đường biên của các trạng thái ghép lại. Một trạng thái ghép lại là một trạng thái gồm
có hoặc là các trạng thái phụ xảy ra cùng một thời điểm hoặc các trạng thái phụ tách
rời. Nếu được khởi động, nó thoát tất cả các trạng thái phụ của trạng thái ghép bắt đầu
việc thoát với các trạng thái ở tận trong cùng ở trong cấu hình trạng thái hoạt động. Sự
chuyển trạng thái phức hợp bắt nguồn từ một tập hợp các trạng thái và hướng đến một
tập hợp của các trạng thái. Một sự chuyển trạng thái bên trong thực hiện mà không
thoát hoặc vào lại trạng thái mà nó đã xác định. Một sự chuyển trạng thái hoàn thành
phụ thuộc của sự kiện send chỉ ra rằng một thao tác đưa một dấu hiệu cụ thể.
Một sự kiện thời gian đưa ra sự chuyển qua của một khoảng thời gian được chỉ
định sau một sự kiện được chỉ định (thường là đầu vào của một trạng thái hiện tại)
hoặc sự kiện của một thời gian nhất định. Trong UML, sự kiện thời gian được mô hình
hóa bằng sử dụng các từ khóa after được theo sau bởi một vài biểu thức mà đánh giá
tới một khoảng thời gian. Hình 8 minh họa một sự kiện thời gian.
Hình 8: Sự kiện thời gian (time Events)
Copyright: Tài liệu đại học ©