Phương pháp và kỹ thuật sinh Test case tự động

Phương pháp và kỹ thuật sinh Test case tự động

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 ĐỀ 7

1.1 Tầm quan trọng của yêu cầu phần mềm 7

1.2 Khái niệm về Test case 7

1.3 Vấn đề sinh Test case từ yêu cầu phần mềm 8

CHƯƠNG 2 TỔNG QUAN VỀ QUÁ TRÌNH 9

SINH TEST CASE TỰ ĐỘNG 9

2.1 Giới thiệu 9

2.2 Tổng quan về các phương pháp sinh Test case 9

2.2.1 Sinh Test case dựa trên đặc tả 10

2.2.2 Sinh Test case dựa trên mô hình 10

2.2.3 Sinh Test case hướng đường dẫn 11

2.3 Kiểm thử phần mềm và UML 11

CHƯƠNG 3 CÁC KỸ THUẬT VÀ PHƯƠNG PHÁP SINH 12

TEST CASE TỰ ĐỘNG 12

3.1 Giới thiệu 12

3.2 Kỹ thuật sinh Test case dựa trên đặc tả 13

3.2.1 Các phương thức đặc tả trạng thái SCR 14

3.2.2 Kỹ thuật sinh ra Test case dựa theo đặc tính của SCR 15

3.2.3 Kỹ thuật tạo Test case cho đặc tả UML 22

3.2.4 Các thuận toán sinh Test case dựa trên đặc tả 29

3.3 Kỹ thuật sinh Test case dựa trên mô hình 37

3.3.1 Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UML 38

3.3.2 Tạo Test case dựa trên Use case cải tiến 46

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 lợi ich và hạn chế 60

4.2.4 Kết luận 61

4.3 Cài đặt 62

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

DANH MỤC CÁC HÌNH VẼ

5 Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR

10 Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML

11 Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái

13 OCD cho việc sinh ra các Test case chỉnh sửa đầy đủ các thuộc tính

15 OCD cho việc sinh ra các Test case chỉnh sửa cặp chuyển tiếp

24 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

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

29 Các lược đồ test và các giá trị test

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

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)

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

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 (mô hình lỗi) Fault Model UML Diagram (biều đồ UML)

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ử:

Để 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à 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

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 tiếp đầu vào (M), tất cả các chuyển tiếp đầu ra (N), sau đó tạo ra các cặp M*N chuyển tiếp

(b) Xây dựng các cặp thuộc tính Những cặp chuyển tiếp này là được thay thế sau đó bởi các thuộc tính từ đồ thị đặc tả

6 Phát triển các yêu cầu kiểm thử tuần tự hoàn chỉnh

(a) Xác định các danh sách hoàn chỉnh của các trạng thái Các kiểm thử trình tự hoàn chỉnh được tạo ra bởi tester Điều này được thực hiện bằng việc chọn các trình tự của các trạng thái từ biều đồ đặc tả để đưa vào

(b) Xây dựng trình tự của các thuộc tính Trình tự của các trạng thái được vào trong các trình tự điều kiện mà sẽ làm cho các trạng thái đó được đưa vào

Ở điểm này, các yêu cầu kiểm thử cho bốn mức độ sẽ là một định dạng chuẩn, giống như việc chỉ định cho các thuộc tính

7 Xây dựng các đặc tả kiểm thử Với mỗi một yêu cầu kiểm thử cụ thể, việc tạo ra các giá trị tiền tố, các giá trị Test case, xác nhận các điều kiện, giải phóng các điều kiện, và các kết quả mong muốn Chú ý rằng có thể sự trùng nhau khá nhiều trong

số các yêu cầu kiểm thử, do đó có sự hạn chế nhất định Tạo ra các giá trị thực tế có thể liên quan đến một số phương trình đại số Cho ví dụ, nếu một điều kiện là A>B, giá trị của A và B phải được lựa chọn để đưa ra thuộc tính giá trị phù hợp Ở điểm này

nó cũng có thể phát hiện ra một số việc kiểm thử không phù hợp

8 Xây dựng các tập lệnh kiểm thử Mỗi đặc tả kiểm thử được sử dụng để xây dựng một tập lệnh Các tập lệnh kiểm thử thực sự phải phản ánh cú pháp đưa vào của chương trình, vì vậy sự am hiểu về cú pháp đưa vào của chương trình được yêu cầu cho bước này (lưu ý rằng đây chỉ là một bước kiểm thử mà đòi hỏi sự hiểu biết về việc thực hiện, tất cả các bước tiếp theo phụ thuộc rất lớn vào các đặc tả chức năng)

Chú ý:

Nó là có thể để tự động hóa hoàn toàn tất cả quá trình lấy ra này Nếu một dạng máy có thể đọc được của bảng đặc tả là sẵn có, các điều kiện chuyển tiếp có thể được đọ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 quan hệ để đối tượng có thể đáp ứng được những trách nhiệm của nó Các phương pháp của một đối tượng thực hiện hành vi của nó [1] Bằng việc test mỗi phương pháp, chúng ta có thể kiểm thử một vài mục của hành vi của một đối tượng, nhưng không phải là toàn bộ các hành vi Các máy trạng thái mô tả toàn bộ hành vi của một đối tượng, do vậy Test case được tạo ra từ các máy trạng thái kiểm thử toàn bộ hành vi của một đối tượng Lợi thế khác của biểu đồ UML đó là chúng có cùng ngữ nghĩa như các đặc tả được dựa trên trạng thái khác Điều này làm cho nó có thể sinh ra mô hình thế

hệ Test case được miêu tả ở các biểu đồ UML Để sửa mô hình tới các biểu đồ UML, chúng ta giải thích cùng ngữ nghĩa và cú pháp của biểu đồ trạng thái trong các đặc tả UML

Trạng thái của một đối tượng là sự kết hợp của tất cả các giá trị của thuộc tính

và các đối tượng mà đối tượng có; một trạng thái là tĩnh, tại một thời điểm, không phải

là động Trạng thái động của đối tượng được mô hình hóa thông qua sự chuyển tiếp,

đó là một sự chuyển động từ một trạng thái này sang một trạng thái khác Khi một đối tượng ở trong một trạng thái nhất định, một sự kiện xuất hiện dẫn đến làm nó chuyển động sang một trạng thái khác (hoặc trở lại trạng thái cũ) Trong khi chuyển tiếp từ trạng thái này tới trạng thái khác, một hành động xuất hiện Sự chuyển tiếp trong UML

có cú pháp như sau:

Event (arguments) [condition] ’ target.sendEvent (argments)/operation (arguments)Mỗi trong số các trường này là một tùy chọn-thậm chí tên có thể được bỏ đi nếu

nó rõ ràng khi sự việc chuyển tiếp xảy ra

Sự kiện là tên của việc chuyển tiếp Thông thường đây chỉ là một thứ được xác định cho chuyển tiếp Chuyển tiếp có một danh sách đối số tùy chọn để chỉ ra khi nào

dữ liệu được đưa ra trong chuyển tiếp, chẳng hạn một mã bị lỗi hoặc một giá trị được giám sát Danh sách đối số này được đưa vào trong ngoặc đơn giống như việc gọi chức năng chuẩn Điều kiện bảo đảm được đưa ra trong dấu ngoặc vuông Một bảo đảm là một điều kiện mà phải được thỏa mãn trước khi việc chuyển tiếp được thực hiện Danh sách sendEvent là một danh sách được ngăn cách bởi dấu phẩy Mỗi sự kiện được hướng tới một đối tượng mục tiêu, và có thể có các đối số Những sự kiện như vậy sẽ được phổ biến bên ngoài của các đối tượng đi kèm như một kết quả của sự chuyển tiếp này Đây là một cách mà các trạng thái đang xảy ra liên lạc với nhau, cho phép một sự 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

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

là một sự chuyển tiếp không có khởi động rõ ràng, mặc dầu nó có thể có một sự bảo đảm được xác định Khi tất cả chuyển tiếp và các thao tác đưa vào và các hành động đưa vào trong trạng thái hành động hiện có được hoàn thành Một sự chuyển trạng thái khả năng được cho phép bởi một sự kiện, và nó bắt nguồn từ một trạng thái hoạt động Một sự chuyển trạng thái khả năng được khởi động khi ở đó tồn tại ít nhất một đường dẫn hoàn chỉnh từ trạng thái gốc tới trạng thái mục tiêu

Phần này chỉ quan tâm đến sự chuyển trạng thái khả năng Mô hình trước đó đã được dựa chủ yếu trên sự thỏa mãn thuộc tính Trong UML, các sự chuyển trạng thái khả năng là tương tự các chuyển tiếp mà được dựa trên khái niệm về sự thỏa mãn thuộc tính.Vì mục đích sinh ra mô hình, các loại khác của chuyển tiếp là không được xem xét

Bốn loại sự kiện có thể được xác định trong UML: sự kiện gọi (call event), sự kiện báo hiệu (signal event), sự kiện thời gian (time event), và sự kiện thay đổi (change event) Một sự kiện gọi đưa ra sự tiếp nhận của một yêu cầu để thực hiện một hoạt động nhất định Kết quả mong đợi là một sự thực hiện của một trình tự các hành động mà tiêu biểu là hành vi tại một trạng thái cụ thể Sự tạo và phá hủy đối tượng là hai trường hợp đặc biệt của một sự kiện gọi Hình 6 minh họa một sự kiện gọi

Hình 6: Sự kiện gọi (call events)

Hình 7: Sự kiện báo hiệu (signal events)

Một sự kiện báo hiệu đưa ra sự chấp nhận của một dấu hiệu đồng bộ cụ thể Một ví dụ sự kiện báo hiệu không nên được nhầm lẫn với hành động (ví dụ hành động Send) mà đã tạo ra nó Các ngoại lệ là các ví dụ của các sự kiện báo hiệu Các sự kiện báo hiệu được mô hinh hóa như các loại được dập khuôn, được đưa ra trong hình 7 Sự 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)

Một sự kiện thay đổi xuất hiện khi một biểu thức boolean rõ ràng trở thành đúng như một kết quả của một sự thay đổi trong giá trị của một hoặc nhiều các thuộc tính hoặc các kết hợp Một sự kiện thay đổi được đưa rõ ràng và không là kết quả của một hành động thay đổi sự kiện Sự kiện thay đổi thì khác với một sự bảo vệ Một sự bảo vệ không chỉ được đánh giá tại thời điểm một sự kiện được gửi đi, ngược lại, dựa

trên các khái niệm biểu thức Boolean kết hợp với một sự kiện thay đổi được đánh giá liên tục cho tới khi nó trở thành đúng Sự kiện mà được tạo ra vẫn còn cho tới khi nó được sử dụng thậm chí nếu biểu thức Boolean biến thành sai Trong UML, sự kiện thay đổi được mô hình hóa bởi việc sử dụng từ khóa when được theo sau bởi một vài biểu thức Boolean Hình 9 minh họa một sự kiện thay đổi.

Hình 9: Sự kiện thay đổi (Change Events)

Trong số bốn loại sự kiện, sự kiện thay đổi có thể diễn đạt như một thuộc tính Sau đây, chúng ta áp dụng mô hình tạo Test case đặc tả dựa trên trạng thái tới sự chuyển trạng thái khả năng với sự kiện thay đổi

(1) Mức độ chỉnh sửa chuyển tiếp

Chỉnh sửa chuyển tiếp: Mỗi chuyển tiếp được phép trong biểu đồ trạng thái được thực hiện ít nhất một lần

(2) Mức chỉnh sửa thuộc tính đầy đủ

Chỉnh sửa thuộc tính đầy đủ: 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 có các giá trị chẳng hạn giá trị của thuộc tính sẽ luôn như là giá trị mệnh đề được kiểm thử

(3) Mức chỉnh sửa cặp chuyển tiếp

Mức độ chỉnh sửa cặp chuyển tiếp: Với mỗi trạng thái S, tạo thành các yêu cầu kiểm thử chẳng hạn cho mỗi chuyển tiếp tiếp theo và mỗi chuyển tiếp trong tương lai,

cả hai chuyển tiếp phải được thực hiện tuần tự

Chú ý: Tiêu chuẩn chỉnh sửa cặp chuyển tiếp có thể không khả thi trong biểu đồ trạng thái mà có các loại được pha trộn của các chuyển tiếp Kỹ thuật tạo ra dữ liệu kiểm thử chỉ cho các chuyển tiếp khả năng

Hình 10: Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML

Nếu sử dụng các loại chuyển tiếp khác trong biểu đồ trạng thái, kỹ thuật không thể tạo các Test case cho chúng Chúng ta không thể có các Test case cho một vài cặp chuyển tiếp

(4) Mức độ tuần tự hoàn chỉnh

Mức độ tuần tự hoàn chỉnh: Kỹ sư kiểm thử phải xác định các trình tự đầy đủ ý nghĩa của các chuyển tiếp trên biểu đồ trạng thái bằng việc chọn các trình tự của các trạng thái nên được đưa vào

Ghi chú: Tiêu chuẩn chỉnh sửa tuần tự hoàn chỉnh không thể khả thi trong một biểu đồ trạng thái mà có các loại được trộn của các chuyển tiếp Lý do là giống như của các tiêu chuẩn chỉnh sửa các cặp chuyển tiếp

2 Phát triển các yêu cầu kiểm thử chỉnh sửa chuyển tiếp

Lấy các thuộ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 các yêu cầu kiểm thử

3 Phát triển các yêu cầu kiểm thử thuộc tính đầy đủ

Tạo các bảng đúng cho tất cả các thuộc tính trong biểu đồ đặc tả Kiểm thử chỉnh sửa 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 thuộc tính Nếu tất cả các kết nối hợp lý là giống nhau (tất cả AND hoặc tất cả Or), nó

là một vấn đề đơn giản để chỉnh sửa các giá trị cho tất cả các mệnh đề trong các thuộc tính trực tiếp Tuy nhiên, nếu biểu thức có cả AND và Or, nó sẽ ít lỗi hơn để tạo cây biểu thức Các ngôn ngữ đặc tả tạo ra sự khác biệt giữa các sự kiện trigger và các sự kiên đầu tiên; trong trường hợp này, các biến khởi động phải được đánh dấu đặc biệt

để kỹ sư kiểm thử ghi nhớ để đặt những dữ liệu đưa vào đó sau các dữ liệu điều kiện đầu tiên.

4 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 Các công 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 cặp này đưa ra một dữ liệu đầ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ằng cách liệt kê tất cả các chuyển tiếp đưa vào (M), tất cả các chuyển tiếp kết quả (N), sau đó tạo các cặp chuyển tiếp M*N

b Xây dựng các cặp chuyển tiếp, các cặp chuyển tiếp này sau đó được thay thế bởi các thuộc tính từ các biểu đồ trạng thái

5 Phát triển các yêu cầu kiểm thử trình tự hoàn chỉnh

a Xác định danh sách của các trạng thái Công việc kiểm thử trình tự hoàn chỉnh được tạo ra bởi các tester Điều này được thực hiện bằng cách chọn các trình tự của các trạng thái từ các biểu đồ đặc tả để đưa vào

b Xây dựng trình tự của các thuộc tính Các trình tự của các trạng thái được chuyển vào trong các trình tự của các điều kiện mà sẽ khiến cho các trạng thái đó được đưa vào

Ở điểm này, các yêu cầu kiểm thử cho bốn mức độ sẽ được thực hiện theo dạng chuẩn mực, như các chỉ định đúng cho các thuộc tính

6 Xây dựng các đặc tả kiểm thử Cho mỗi yêu cầu kiểm thử cụ thể, tạo ra các giá trị tiền tố, các giá trị Test case, xác định các điều kiện, giải phóng các điều kiện, và kết quả mong muốn Ghi nhớ rằng có thể có một số lượng khá nhiều bị trùng nhau trong số các yêu cầu kiểm thử, do sự hạn chế là duy nhất Tạo ra các giá trị thực tế có thể liên quan đến việc giải quyết một số phương trình thuật toán

7 Xây dựng các tệp kiểm thử Mỗi đặc tả kiểm thử được sử dụng để xây dựng một tệp kiểm thử Các tệp này cụ thể phải phản ánh cú pháp đưa vào của một chương trình, vì sự hiểu biết của cú pháp đưa vào của chương trình được yêu cầu ở bước này (ghi nhớ rằng đây chỉ là bước mà yêu cầu sự am hiểu cho việc thực hiện, tất cả các bước tiếp theo phụ thuộc hoàn toàn vào các đặc tả chức năng.)

Chú ý:

Các đặc tả UML được tạo ra bởi nhiều công cụ, chẳng hạn như Rational Rose, các đặc tả này được lưu tất cả trong một dạng dễ hiểu, mà có thể đọc trên bất kỳ một máy nào Mỗi đối tượng là một trường hợp của một loại Một loại của các đặc tả UML

có các tên lớp, các thuộc tính lớp, các phương thức, và một máy trạng thái được đính kèm nó Các trạng thái và chuyển tiếp của một đối tượng có thể có được trực tiếp từ phần lớp của một đặc tả Bởi vì các biến được sử dụng trong mô tả các trạng thái chuyển tiếp được định nghĩa trong phần các thuộc tính lớp, các loại và giá trị ban đầu của các biến có thể đạt được Với một cấu trúc dữ liệu phù hợp cho các thuật toán, các thông tin có được cho mô hình, quá trình tạo ra Test case là hoàn toàn có thể được tự động hóa

3.2.4 Các thuận toán sinh Test case dựa trên đặc tả.

Trong phần này, đầu tiên chúng ta mô tả cấu trúc của các giả định và các file đặc

tả SCR và UML mà ta sẽ thực hiện trong thiết kế Sau đó chúng ta đưa ra thiết kế cấu trúc, cuối cùng là các thuật toán mà phân tích các file đặc tả và sinh ra các Test case cho việc chỉnh sửa đầy đủ thuộc tính và tiêu chuẩn chỉnh sửa cặp chuyển tiếp được đưa ra

3.2.4.1 Các files đặc tả UML và SCR

Các file đặc tả được lưu giữ như các file văn bản ASCII Đầu tiên, chúng ta phân tách cú pháp file đặc tả để có được ý nghĩa của nó Việc phân tách các file text đặc tả phụ thuộc rất nhiều vào cấu trúc của chúng Trong phần này, chúng ta sẽ đưa ra một cái nhìn tổng quan tương đối chi tiết về việc làm thế nào các file text đặc tả được tạo ra

(1) Cấu trúc của các file đặc tả SCR

File đặc tả có các mục riêng biệt sau đây:

• Từ điển loại ( Type Dictionary)

• Từ điển lớp trạng thái (Mode Class Dictionary)

• Từ điển hằng số (Constant Dictionary)

• Từ điển biến (Variable Dictionary)

• Từ điển xác nhận đặc tả (Specification Assertion Dictionary)

• Từ điển xác nhận môi trường (Environmental Assertion Dictionary)

• Từ điển biến giám sát liệt kê (Enumerated Monitored Variable Dictionary)

• Từ điển biến điều khiển (Controlled Class Table)

• Các bảng loại trạng thái (Mode Class Table)

• Các bảng biến điều kiện (Term Variable Table)

Các đặc tả cho tất cả các mục này được lưu giữ như các ASCII text file trong trật tự bên trên Không có sự hạn chế trong tên file, hoặc phần đuôi file mở rộng Cấu trúc của file text được chỉ ra ở bên dưới

- Các giả định cho các đặc tả SCR

Các giả định sau đây được thực hiện trong khi phân tách đặc tả SCR trong file text

• @T, @F biểu thị cho các sự kiện khởi động

• AND biểu thị cho sự logic và

• Chỉ có một loại lớp

• Các biến Boolean

• Thay đổi biến đơn trong sự kiện

• Không có biến nào hoặc các biến đơn hoặc đa biến trong điều kiện

• Những sự chuyển tiếp trạng thái được xác định

Type Dictionary

TYPE Type Name

BASETYPE Base Type Name

UNITS Unit Name

COMMENT Comments for the type usage

Mode Class Dictionary

MODECLASS Mode Class Name

MODES List of modes separated by comma

INITMODE Initial Mode

COMMENT Comments for the mode class usage

Constant Dictionary

CONSTANT Constant Name

TYPE Type Name

VAL Value

COMMENT Comments for the constant

Variable Dictionary

MON Name of a monitored variable

TYPE Type Name

INITVAL Initial value

ACCURACY Accuracy

COMMENT Rules for value assignment

CON Name of a controlled variable

TYPE Type Name

INITVAL Initial value

ACCURACY Accuracy

COMMENT Rules for value assignment

Specification Assertion Dictionary

ASSERTION Name of an assertion

EXPR Expression

COMMENT Explanation of assertion

Environmental Assertion Dictionary

Enumerated Monitored Variable Table

Event, Mode Transition, and Condition Functions

EVENTFUNC Event function table name

MCLASS Mode class name

MODES Mode name

EVENTS Event1, Event2

ASSIGNMENTS Value1, Value2

CONDFUNC Condition function table name

CONDITIONS Condition1, Condition2

ASSIGNMENTS Value1, Value2

MODETRANS Mode transition table name

FROM State name

EVENT Event

WHEN List of Disjunctive Conditions

TO State name

Cấu trúc của file text trong đặc tả SCR.

(2) Cấu trúc của các file UML MDL

Các file đặc tả UML được tạo ra bởi Rational Rose thường có đuôi file mở rộng

“mdl” Các file MDL lưu giữ thông tin đặc tả từ các hình phối cảnh khác nhau Có hai loại chủ yếu của thông tin: vật chất và logic Đặc tả bản thân được nhóm vào trong hai

gói: biểu đồ cộng tác đối tượng và use case Chúng ta quan tâm đến các biểu đồ chuyển tiếp trạng thái, do đó, chúng ta chỉ đưa ra cấu trúc của phần logical view của file MDL Hình 11 cho thấy cấu trúc bên trong của biểu đồ lớp và biểu đồ chuyển trạng thái trong một file MDL.

Hình 11: Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái.

- Các giả định cho các đặc tả UML

Trong phần này chúng ta chỉ quan tâm đến các chuyển tiếp khởi động bởi một vài sự kiện thay đổi, chúng ta không xem xét các loại chuyển tiếp khác Với các đầu vào file đặc tả UML, sẽ có các giả định sau:

• Tất cả các chuyển tiếp là được khởi động bằng các sự kiện thay đổi

• Các sự kiện và các điều kiện được diễn đạt thông qua các thuộc tính phân loại Boolean

• Đặc tả được viết ra hết sức chặt chẽ sau các chú giải UML Ví dụ, when giải thích một sự kiện thay đổi, các điều kiện là trong ngoặc đơn, vân vân… Bởi vì không

có cách nào để kiểm thử một đặc tả được hình thành hoặc thống nhất hay không, giả định này không thể được kiểm thử

• Các chuyển tiếp trạng thái được định trước

3.2.4.2.Thiết kế cấu trúc

Chúng ta giải thích mô hình thiết kế thông qua một biểu đồ lớp và ba biểu đồ cộng tác đối tượng được tạo ra bởi Rose.

(1) Biều đồ lớp

Hình 12 là một biều đồ lớp UML được thiết kế Các lớp được đưa ra như các hộp mà có ba phần: tên lớp, các thành viên dữ liệu được khai báo trong lớp, và các phương thức của lớp Có bốn đối tượng: một phân tách đặc tả UML, một phân tách đặc tả SCR, một máy tạo ra Test case đặc tả đầy đủ, và một máy tạo Test case cặp chuyển tiếp

Hình 12: Biểu đồ lớp của mô hình thiết kế