Tìm hiểu về công cụ tự động sinh test case tự động kiểm thử phần mềm

Tìm hiểu về công cụ tự động sinh test case tự động kiểm thử phần mềm

MỞ ĐẦU

Kiểm thử phần mềm là quá trình thực hiện một chương trìnhhoặc hệ thống với mục đích tìm kiếm lỗi Không giống như các hệthống vật lý, hầu hết các lỗi trong phần mềm là lỗi do thiết kế Xâydựng dữ liệu thử nghiệm trong kiểm thử phần mềm đòi hỏi chi phílớn và biết sử dụng phương pháp để tạo ra các dữ liệu thử nghiệm làrất quan trọng Theo các nghiên cứu: 50% chi phí phát triển phầnmềm là dành cho phần thử nghiệm Vì vây, việc sinh dữ liệu tự động

sẽ giúp chương trình thử nghiệm cung cấp các dữ liệu thử nghiệmcho phần mềm do đó sẽ hiệu quả đối với việc giảm chi phí và tăngchất lượng kiểm thử

Mặc dù việc nghiên cứu về các phương pháp và kỹ thuật sinhTest case tự động từ yêu cầu người dùng đã được quan tâm nhiềutrê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ầungườ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ệctạ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ựchiệ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ầnmềm sẽ tốt hơn những dự án viết Test case tồi Vậy tại sao chúng takhô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áctester, làm cho chất lượng của Test case tốt hơn

Đồ án gồm các phần sau:

Mở đầu: Giới thiệu về đề tài.

Chương 1: Cơ sở lý luận.

Chương 2: Tổng quan về quá trình sinh test case tự động Chương 3: Các kỹ thuật và phương pháp sinh test case tự

động

Chương 4: Java path finder và thực thi tượng trưng.

Chương 5: Một số ví dụ thực thi tượng trưng với jpf.

Kết luận: Trình bày kết quả và nêu nhận xét.

CHƯƠNG 1: CƠ SỞ LÝ LUẬN 1.1 Tổng quan kiểm thử phần mềm.

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành đểcung cấp cho các bên liên quan thông tin về chất lượng của sảnphẩm hoặc dịch vụ được kiểm thử Kiểm thử có thể cung cấp chodoanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm

để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trongquá trình triển khai phần mềm

Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiệnmột chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phầnmềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phêchuẩn và xác minh một chương trình máy tính / ứng dụng / sảnphẩm nhằm:

 Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và pháttriển phần mềm

 Thực hiện công việc đúng như kỳ vọng

 Có thể triển khai được với những đặc tính tương tự

 Và đáp ứng được mọi nhu cầu của các bên liên quan

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể đượcthực hiện bất cứ lúc nào trong quá trình phát triển phần mềm Theotruyền thống thì các nỗ lực kiểm thử được tiến hành sau khi các yêucầu được xác định và việc lập trình được hoàn tất nhưng trong Agile(là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựatrên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiếnhành liên tục trong suốt quá trình xây dựng phần mềm Như vậy,mỗi một phương pháp kiểm thử bị chi phối theo một quy trình pháttriển phần mềm nhất định

Vì vậy tích hợp với quá trình phát triển phần mềm, có một số lợi ích:

 Phát hiện ra lỗi có nguy cơ cao sớm, cho nhóm phát triểnthời gian để phát triển một giải pháp toàn diện hơn làmột sửa chữa tạm thời để thích ứng với thời hạn pháttriển Đây là lợi thế chính của kiểm chứng phần mềm

 Cung cấp thông tin quản lý liên tục và toàn diện về chấtlượng và tiến trình nỗ lực phát triển

 Cung cấp cho người sử dụng xem trước gia tăng hiệunăng hệ thống, với cơ hội để thực hiện điều chỉnh sớm

 Đánh giá các sản phẩm dựa vào các yêu cầu hệthống

1.2 Khái niệm Test Case

Trong quá trình phát triển dự án phầm mềm, thông thường mộtquy 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á:

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 đíchcủa thiết kế test là viết và chỉ định các Test case trong các bướckiể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ểmtra "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 quantrọng để đảm bảo chất lượng phần mềm Để làm được việc đó, trướchế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 haykhô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ểmthử, 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 racá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 Các nhóm kiểm định phần mềm

Trong lĩnh vực kiểm định chất lượng phần mềm hiện nay trênthế giới, hiện có nhiều kỹ thuật nhưng tựu chung có thể phân theo

ba nhóm chính: Phân tích mã nguồn tĩnh (static code analysis), kiểmthử dữ liệu động (dynamic data testing) và kỹ thuật hình thức dựatrên mô hình (model-based verification) Hai nhóm đầu tập trung vàoviệc nâng cao chất lượng phần mềm tại mức mã nguồn, trong khinhóm cuối cùng xử lý phần mềm tại mức trừu tượng cao hơn – môhình

Phân tích mã nguồn tĩnh là kỹ thuật phát hiện lỗi chương

trình mà không yêu cầu chạy chương trình đó Không giống như kỹ

thuật kiểm thử dữ liệu động đòi hỏi phải chạy chương trình với dữ

liệu đầu vào thật, kỹ thuật phân tích mã nguồn tĩnh chỉ xem xét mãnguồn của chương trình

Kỹ thuật kiểm thử phần mềm dựa trên mô hình: khác với

hai nhóm ở trên ở điểm đối tượng được kiểm thử là các mô hình đượctrừu tượng hóa từ hệ thống được xem xét Quá trình trừu tượng hóa

là việc lược bỏ những chi tiết của hệ thống trong khi chỉ giữ lạinhững thông tin/khía cạnh quan trọng cần được lưu tâm Kỹ thuậttrừu tượng hóa đơn giản hóa hệ thống được xem xét và do đó giảmkhông gian tìm kiếm và thời gian phân tích chương trình đi nhiều lần

so với lúc thực hiện công việc phân tích đó trên mã nguồn

Khi xây dựng xong phần mềm, chúng ta phải sử dụng cáctestcase (trường hợp kiểm thử) cho việc kiểm thử Chất lượng củaviệc kiểm thử phụ thuộc rất lớn vào tập hợp các testcase mà chúng

ta sử dụng Hai tiêu chí chính của việc đánh giá chất lượng kiểm thử

đó là hiệu quả cho chất lượng phần mềm được kiểm thử là độ phủdòng chảy (control flow coverage) và độ phủ dữ liệu (datacoverage) Tiêu chí thứ nhất tập trung vào việc kiểm thử tất cả cácđiểm điều khiển trên chương trình (ví dụ: các nhánh rẽ khả đạt trongcấu trúc chương trình – reachable control points) Trong khi tiêu chíthứ hai tập trung vào tập dữ liệu kiểm thử ứng với mỗi điểm điềukhiển trong cấu trúc chương trình

Bằng kỹ thuật phân tích chương trình dựa trên mô hình sau khitrừu tượng hóa mã nguồn của chương trình được kiểm thử, việc phântích cấu trúc logic của chương trình và tập dữ liệu ứng với mỗi điểmđiều khiển trong chương trình sẽ dễ dàng hơn Qua đó, quá trìnhsinh ra tập các testcase sẽ nhanh chóng và chính xác, đảm bảo cáctiêu chí control flow và data coverage tốt hơn nhiều so với cách tiếp

cận ở mức mã nguồn truyền thống Hơn nữa, nếu quá trình này đượcthực hiện một cách tự động sẽ giảm thiểu nhiều công sức cho cácchuyên gia kiểm thử chương trình Với cách tiếp cận như vậy, phầnmềm có thể được kiểm thử một cách tự động bằng máy, đem lại kếtquả chuẩn hơn, xét được nhiều trường hợp hơn, đặt biệt là các lỗilogic, tiết kiệm chi phí sản xuất.

Đánh giá tập dữ liệu kiểm thử: Ngoại trừ những chương

trình đơn giản, sẽ là không thực tế nếu kiểm chứng phần mềm trêntập tất cả dữ liệu đầu vào có thể Ngay cả khi chỉ tính tổ hợp của các

dữ liệu đầu vào hoặc tổ hợp của các hàm, số lượng đầu vào và sốlượng các trạng thái cũng là quá lớn Khi hệ thống có bộ nhớ lớn, các

dữ liệu đầu vào, đầu ra sẽ được log lại để theo dõi trạng thái Trongkhi không có một công cụ để tạo ra một thiết kế phần mềm chuẩn,hoàn chỉnh và chắc chắn thì việc kiểm thử là một khâu không thểthiếu để có thể đánh giá được chất lượng phần mềm Vì thế người taphải tìm cách chọn được một tập dữ liệu nhỏ mà có thể kiểm thửmang lại được độ tin cậy cao với mỗi hệ thống

Độ phủ hay mức độ đầy đủ bằng trực quan đánh giá đượcphạm vi hay mức độ kiểm thử Nếu kiểm thử không đầy đủ được hếtmọi khía cạnh của phần mềm đồng nghĩa với việc chúng ta bỏ sótnhiều lỗi Các tấn suất của các trường hợp cũng không giống nhau

Khái niệm ca kiểm thử đơn giản là kiểm chứng các trạng tháiđưa ra thể hiện cho hoạt động của hệ thống Chúng ta có thể tạo ra

ca kiểm thử đề đạt được trạng thái có thể bằng cách đưa vào cácbiến đặc biệt, trạng thái để điều khiển hệ thống

1.4 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ệctạ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ựchiện dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tàiliệu Test case tốt, có hiệu quả thì chất lượng phần mềm sẽ tốt hơnnhững dự án có các Tester viết Test case tồi (có nhiều trường hợptest 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ấtlượ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áctester, 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 racá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 Testcase một cách tự động từ yêu cầu người dùng rất hữu ích và cầnthiết trong quá trình phát triển các dự án phần mềm Quá trình nàynhằm mục đích tạo ra Test case một cách có hiệu quả, có chấtlượng Giúp giảm bớt công sức và thời gian của các tester, làm giảmbớt chi phí phát triển phần mềm và chất lượng phần mềm được nângcao 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 trongvòng đời phát triển của phần mềm Để cắt giảm chi phí của việc testbằ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 quantrọ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 đượcthiết lập theo một cách thức độc lập Chương này trình bày cáchnhì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ướckhi 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ượnglỗi được phát hiện và chỉnh sửa trước khi công bố hệ thống Điều nàylầ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 độclậ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ácTest 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ệuthiết kế Điều này sẽ chắc chắn sẽ làm giảm chi phí của việc xâydự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êncác giả định Kỹ thuật định hướng đường dẫn sử dụng các luồngthô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ạicác kỹ thuật động đạt được từ các dữ liệu cần thiết bằng việc chạychương trình trong khi test Kỹ thuật định hướng mục tiêu xác địnhcác Test case bao gồm một mục tiêu đã được lựa chọn chẳng hạnmột câu lệnh hoặc nhánh câu lệnh Các kỹ thuật thông minh của cácTest 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ựatrê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ácTest 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, sequencediagrams,… để sinh ra các Test case và dẫn đến việc sinh ra Testcase 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ộctí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ềukhiển test và test script để xác nhận các thành phần khi test Cáchtiếp cận trong một mẫu, chỉ ra các lớp và đặc tả biểu đồ trạng tháitương ứng cho hành vi của lớp đó, định rõ ánh xạ đưa ra bằng sự kếthợp các mã với đặc tả Sau đó tester chọn các tiêu chuẩn để chỉnhsửa Tóm lại, các lỗi được phát hiện ra như sự không nhất quán giữahà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áctiê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 conngườ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áttriể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ầnmềm, chi phí của việc test có thể chiếm hơn 40% tổng chi phí pháttriển cho một hệ thống phần mềm Đưa ra các thực tế này để pháthiệ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ậptrung 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ốiquan 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ềukhiển từ hoạt động này đến hoạt động khác xảy ra bên trong mộtmáy trạng thái UML có một phương pháp mô hình trước đó đượcbiế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ổitiế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ướngtới đường dẫn Phương pháp này đã nêu vấn đề của các cách tiếpcận sinh ra Test case tự động và đã cung cấp một giải pháp với thuậttoá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ươngthứ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ệuquả 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ọanhững sự khác biệt giữa các giai đoạn, cũng như biều đồ UML tiềmnăng cho việc sử dụng trong các giai đoạn.

Unit Code Correctness, error handling

pre/post conditions, invariants

Class and state diagramsFunction Functional Functional and API behavior, intergration issuses Interaction and class diagrams

System Operational scenarios Workload, contention, synchron, recovery

Use case, activity, and interaction diagramsRegresstio

Unexpected behavior from new/changed function

SAME AS FUNCTION

Solution

Systemcommun

Inter-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 ápdụng hiệu quả trong quá trình test

Có 2 vấn đề sau: Vấn đề đầu tiên quan tâm là các vấn đề liênquan đến việc sử dụng các mô hình UML trong quá trình test Testerhiểu được sự quan trọng của việc xây dựng hoặc chỉnh sửa cơ bảncá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 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áttriển không chuẩn mực từ một đặc tả chuẩn mực, đặc tả có thể đóngmộ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àonày Có hai vai trò chính một đặc tả có thể đóng vai trò trong testphần mềm Đầu tiên là cung cấp các công tin cần thiết để kiểm trahoặc là đầu ra của chương trình có đúng hay không Thứ hai là cungcấp thông tin để lựa chọn các Test case và để đánh giá sự phù hợpcủa test

Kiểm thử dựa trên đặc tả đưa ra nhiều ưu điểm trong test phầnmề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 chosản phẩm Đặc tả xác định chính xác các khía cạnh cơ bản của phầnmề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ảitriế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áchtiếp cận chuẩn hơn, được cấu trúc và đơn giản hơn cho sự phát triểncủ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áclỗ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áccủa kiểm thử dựa trên đặc tả gồm phát triển test cùng lúc với việcthự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ềmchuẩ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ônngữ, 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ạngthá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ệntrước trên các chuyển tiếp, mà là các giá trị mà các biến xác nhậnphải có cho các chuyển tiếp có thể được phép, các thay đổi trongcác giá tri biến đổi mà khiến các chuyển tiếp được diễn ra

3.1.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ắnvào thời gian thực tế Một lợi ích của phương pháp SCR đó là cấutrú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êucầ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 classhoạ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ườngcủa hệ thống được đưa ra bởi một tập hợp của các điều kiện môitrường Boolean Một event xuất hiện khi các giá trị của một điềukiện thay đổi từ True thành False hoặc ngược lại Do đó, các eventxác định các thời điểm, trong khi các điều kiện xác định khoảng thờigian Thông thường, một conditional event là một event mà xuấthiệ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ệnnhấ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ấtbiến của hệ thống là rõ ràng hoặc đôi khi là rõ ràng được xác địnhtrong đặ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êucầ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ốngnhư các tiêu chuẩn xác định

3.1.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ựccủa các yêu cầu phần mềm Điều này dẫn đến các kết quả khôngthống nhất, các vấn đề trong việc hiểu mục đích và kết quả của việckiểm thử, hoàn thành thiếu tính hiệu quả trong việc kiểm thử Việcxác định đúng cho một yêu cầu rõ ràng để thực hiện kiểm thử bởichúng mô tả chính xác phần mềm đóng vai trò như thế nào trongviệc trợ giúp việc cung cấp một mẫu cái mà có thể tự động điềukhiển Kỹ thuật sinh Test case dựa theo đặc tả SCR thiết lập các tiêuchuẩ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 cungcấp một quá trình chuẩn, một phương pháp để đo lường việc kiểmthử, 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ử

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ôngviệ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.

Thay cho việc chỉ bao hàm các điều kiện trước và sau thì rấtquan trọng để sử dụng việc kiểm thử để liên hệ chặt chẽ các điềukiệ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ụngSoftware 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ảnphẩ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ị đầuvào là các giá trị đầu vào của Test case, những giá trị này cần đượcthỏ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ácgiá 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ộtquá trình xử lý Các đặc tính chức năng được lọc trong các đặc tínhkiể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ụngnhữ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ácTest case ít hơn nhiều so với mức độ chỉnh sửa đầy đủ các thuộctí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 Dovậ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ểmthử các giao diện giữa các trạng thái; và kiểm thử các kết quả hoànthành là hướng đến kiểm thử phần mềm bằng việc thực thi phầnmề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ácnhau.

(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 trongkiể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ủaviệc đòi hỏi rằng mỗi điều kiện ban đầu trong một đặc tả được thỏamã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ếptrong đồ 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ẩmphầ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 đầuvà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ộtcá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 baogồm những toán tử Boolean Ví dụ, các biểu thức liênquan 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ácmệnh đề và không hoặc nhiều toán tử Boolean Một thuộctí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ộctí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êntiê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ộctí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ỉnhsử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ểmsoá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ụngmộ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ộtcây nhị phân mà có nhiều toán tử nhị phân và nhiều toán hạng chocá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ínhbằ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ểmthử và mệnh đề gốc

Một khi mệnh đề gốc đã đạt được, các giá trị có thể được sinhngượ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 conphải có giá trị False; nếu một nút V có giá trị True, thì một trong haicon 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ểmthử (đượ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àokhông phù hợp có thề giúp tìm ra các lỗi trong khi thực hiện cũngnhư sự trình bày rõ ràng của các đặc tả Rất nhiều nhà phát triển tinrằ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ôngcần được kiểm thử với các dữ liệu đầu vào mà đã vi phạm các điềukiện đầu tiên Không giải quyết một khía cạnh của vấn đề này, côngnghệ đượ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ặckhô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ấpcá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átkế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):

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ườnghợ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 độngnữ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ệnthự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ểmthử Đ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ưngkhô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ặpchuyể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ểmthử 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ựchiệ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êncá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ànchỉ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ểmthử 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ự độnghóa ít nhất của quá trình kiểm thử

3.1.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

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ệukiể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ácmối quan hệ để đối tượng có thể đáp ứng được những trách nhiệm của nó Cácphương pháp của một đối tượng thực hiện hành vi của nó Bằng việc test mỗi phươngphá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ưngkhô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 vicủ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ìnhthế 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 đốitượ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 trongUML 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ỏ đinế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ị đượcgiám sát Danh sách đối số này được đưa vào trong ngoặc đơn giống như việc gọichứ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ựchiệ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ệnnhư 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, chophé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áchbở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ộtkế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ắpdiễ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ếptụ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ậmchí 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ẫnchuyể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 đốitượ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ộttrì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áihoà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áigồ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ựchiệ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ạngthá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ộttrạng thái hoạt động Một sự chuyển trạng thái khả năng được khởi động khi ở đó tồntạ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áikhả 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ãnthuộ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 đượcxem 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ộthoạ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 độngSend) 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ệnbá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ìnhhó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ộctí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ủamộ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ựatrê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ệnthay đổ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àibiể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 trongkhi 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ộctí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ầukiể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ệukiểm thử chỉ cho các chuyển tiếp khả năng

3.1.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ấutrú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 casecho 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.1.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 taphâ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 ramộ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ả đượctạ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 trongtrậ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ấutrú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 filetext

 @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 commaINITMODE Initial Mode

COMMENT Comments for the mode class usageConstant 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 FunctionsEVENTFUNC Event function table name

MCLASS Mode class name

MODES Mode name

EVENTS Event1, Event2

ASSIGNMENTS Value1, Value2

CONDFUNC Condition function table name

CONDITIONS Condition1, Condition2ASSIGNMENTS Value1, Value2MODETRANS Mode transition table nameFROM State name

EVENT EventWHEN 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ó hailoạ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 haigó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ủafile MDL Hình 11 cho thấy cấu trúc bên trong của biểu đồ lớp và biểu đồ chuyểntrạ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ộtvà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 đầuvà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ânloạ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ảithí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.1.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áchộ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ácphươ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ặpchuyển tiếp

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

UMLSpecParser đọc một file text đặc tả UML, phân tách nó, và tạo ra bảngchuyển tiếp trạng thái cho các lớp có máy trạng thái SCRSpecParser đọc các file textđặc tả SCR, phân tách chúng, và tạo ra các bảng chuyển tiếp trạng thái cho các lớp.FullPredicate lấy một bảng chuyển tiếp trạng thái như một đầu vào, tạo ra các Testcase cho các tiêu chuẩn chỉnh sửa thuộc tính đầy đủ, và lưu giữ các Test case trongmột file Cặp chuyển tiếp lấy một bảng chuyển tiếp trạng thái như một đầu vào, tạo racác Test case cho tiêu chuẩn chỉnh sửa cặp chuyển tiếp, và lưu giữ các Test case trongmột file text.

(2) Các biểu đồ cộng tác đối tượng

Các biểu đồ cộng tác đối tượng (OCD) cho việc sinh ra các Test case chỉnh sửacặp chuyển tiếp, chỉnh sửa chuyển tiếp, chỉnh sửa thuộc tính đầy đủ được đưa ra tronghình 13, 14, và 15

Trong hình 13 Nó tương tác với người sử dụng, có các lệnh để đọc một file đặc

tả SCR hoặc UML và FullPredicate, gửi bảng chuyển tiếp trạng thái như một tham số.FullPredicate sinh ra các Test case cho các tiêu chuẩn chỉnh sửa thuộc tính đầy đủ, lưugiữ các Test case trong các file, và trả thông điệp mà Test case có thể được sinh ra

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

Hình 14: OCD cho việc sinh ra các Test case chỉnh sửa chuyển tiếp

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

3.1.4.3 Các thuật toán

Phần này đưa ra các thuật toán, các thuật toán được phát triển để phân tách cácfile text đặc tả SCR và UML để tạo ra các Test case

(1) Thuật toán phân tách đặc tả SCR

Hình 16 đưa ra một thuật toán để phân tách các file text đặc tả SCR Thuật toánSCRSpecparser lấy một file đặc tả SCR như một đầu vào, sau đó phân tách file để rút

ra từ điển lớp, từ điển biến và bảng chuyển đổi trạng thái và lưu giữ chúng trong cáccấu trúc dữ liệu

Hình 16: Thuật toán phân tích đặc tả SCR

(2) Thuật toán phân tách đặc tả UML

Hình 17 cho một thuật toán để phân tách file đặc tả UML (MDL files) Thuậttoán UMLSpecParser lấy một file đặc tả UML như một đầu vào, sau đó phân tách file

để rút ra thông tin cần thiết cho việc tạo ra Test case Nó lấy tên lớp, thuộc tính và máytrạng thái, và lưu giữ chúng trong các cấu trúc dữ liệu Trong thuật toán này, các lớpUML được ghép với các lớp chế độ của SCR, các thuộc tính lớp tới các từ điển biến,

và các máy trạng thái tới các bảng chuyển tiếp trạng thái

Hình 17: Thuật toán phân tách đặc tả UML

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

Kỹ thuật sinh Test case dựa trên mô hình là kỹ thuật tập trung vào việc sử dụngcác biểu đồ trong UML như biểu đồ trạng thái, biểu đồ lớp…để sinh Test case Trongphần 3.3.1 trình bày từ việc sử dụng các biểu đồ trạng thái trong việc tạo ra các Testcase đến việc phân tích mức độ tích hợp sử dụng biểu đồ cộng tác Kỹ thuật định racác tiêu chuẩn cho cả test tĩnh và động của các biểu đồ cộng tác các mức

Phần 3.3.2 đưa ra cơ sở tạo ra test case từ việc cải tiến các use case, use caseđóng vai trò như đầu vào cho việc test thống kê tự động Kỹ thuật này có thể sinh rađược các test case mang tính hệ thống để giúp trong việc dẫn chứng các tài liệu về

cách sử dụng và hành vi tương tác Quy trình này giúp cho việc nâng cao chất lượngphần mềm một cách hiệu quả.

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

Các Test case được tạo ra bằng cách sử dụng các biểu đồ cộng tác UML làmột trong những cách tiêu biểu trong kỹ thuật sinh Test case dựa trên mô hình.Các biểu đồ cộng tác UML cho thấy một chú ý quan trọng cho việc sinh test case bởi

vì chúng mô tả chính xác các chức năng phần mềm được thực hiện như thế nào, cácbiểu đồ này cung cấp một kết nối trong một hình thức mà có thể dễ dàng được vậndụng bởi các phương pháp tự động Phần này còn đưa ra các tiêu chuẩn test mới màdựa trên các biểu đồ cộng tác UML Các tiêu chuẩn được xác định cho cả việc testtĩnh và động của các biểu đồ cộng tác mức độ ví dụ và mức độ đặc tả [4] Các tiêuchuẩn này cho phép một sự tích hợp chính thức các test được dựa trên các chú giảithiết kế ở mức độ cao, làm cho phần mềm đáng tin cậy hơn

3.2.1.1 Các biểu đồ cộng tác

Trong phát triển phần mềm hướng đối tượng, các đối tượng tương tác với nhau

để thực hiện hành vi Sự tương tác này có thể được mô tả trong hai cách bổ sung, mộttập trung vào các đối tượng riêng và cách còn lại tập trung vào một tập hợp của việckết hợp các đối tượng Một máy trạng thái xem xét mỗi đối tượng riêng biệt Hành vicủa tập hợp của một bộ các đối tượng có thể được mô hình hóa trong điều kiện củaviệc làm thế nào chúng cộng tác với nhau

Một sự cộng tác là một phần mô tả của một tập hợp của các đối tượng màtương tác để thực hiện một vài hành vi bên trong một ngữ cảnh Nó gồm các đườngrãnh (Slots) mà là được điền vào bởi các đối tượng và các đường link tại thời điểmchạy Một rãnh cộng tác được gọi là một vai trò (role) bởi vì nó mô tả mục đích củamột đối tượng hoặc đường link bên trong cộng tác

Một sự cộng tác gồm các ClasssifierRoles, AssociationRoles, và Interaction.Một ClassifierRole xác định một vai trò để được tham gia bởi một đối tượng (Object)bên trong một sự cộng tác Một AssociationRole xác định các quan hệ củaClassifierRole tới các vai khác AssociationRole là một chủ thể của các đường linkđang tồn tại Một đường link là một sự kết nối riêng trong hai hoặc nhiều hơn các đốitượng, và là một trường hợp của một Association Các đối tượng phải là các trườnghợp định hướng hoặc không của các lớp tại các vị trí tương đương trong một sự kếthợp

Một Association là một sự quan hệ trong số hai hoặc nhiều các classifiers cụthể mà mô tả các kết nối trong số các trường hợp Các classifier tham gia đã được xếpvào các vị trí bên trong sự kết hợp.

Một interaction là một đặc tả hành vi mà là gồm một chuỗi của các liên kếttrong một bộ của các đối tượng bên trong một đặc tả để thực hiện một mục tiêu cụ thể.Mỗi sự tương tác chứa đựng một bộ được sắp xếp từng phần của các thông điệp Mộtthông điệp là một đặc tả của một tác nhân hoạt động, nói một cách khác, sự liên kếtgiữa một người gửi và một người nhận Thông điệp xác định vai trò tham gia bởi đốitượng gửi và đối tượng nhận và nó cho thấy thao tác nào nên được áp dụng cho ngườinhận bởi người gửi Một tác nhân hoạt động là một sự liên kết giữa hai đối tượng màgây ra một thao tác để một đối tượng được tạo ra hoặc phá hủy

Một thao tác là một đặc tả của một sự chuyển đổi hoặc xếp hàng mà một đốitượng có thể được yêu cầu thực hiện Nó có một cái tên và một danh sách các tham số.Một phương pháp là một thủ tục mà thực hiện một thao tác đó Nó là một thuật toánhoặc một phần mô tả thủ tục

Một biểu đồ cộng tác là một sự mô tả đồ họa của một sự cộng tác Các đốitượng trong một biểu đồ cộng tác là các trường hợp của các lớp trong một biểu đồ lớp.Không có các phần tương tác, một biểu đồ cộng tác tương tự với một biểu đồ lớp Tuynhiên, chúng không giống nhau Với một sự cộng tác, ở đó không cần một đối tượngcủa mọi lớp, bởi vì một vài lớp sẽ là không liên quan tới sự cộng tác cụ thể mà đượcxem xét Có thể là hai hoặc nhiều hơn các đối tượng khác nhau của cùng lớp

Một biểu đồ sự cộng tác có hai dạng Một biểu đồ cộng tác mức độ đặc tả chothấy ClassifierRoles, AssociationRoles, và Messages, ở đây biểu đồ cộng tác ở mức ví

dụ cho các Object, Link, và Stimuli Các phần phụ giới thiệu các biểu đồ cộng tácmức đặc tả và mức ví dụ tách biệt nhau, và khai thác các tính chất của chúng cho việcsinh ra Test case

Ví dụ các biểu đồ cộng tác và đặc tả

Các biểu đồ cộng tác mức đặc tả cho thấy các vai trò được xác định bên trongmột sự cộng tác Biểu đồ gồm một tập hợp của các lớp và các đường tương đương tớiClassifierRoles và AssociationRoles trong sự cộng tác Các mũi tên được gắn kèm tớibản đồ trên các thông điệp Hình 18 là một biểu đồ cộng tách mức độ đặc tả mà đượcphỏng theo từ Unified Modeling language Specification Về mặt đồ họa, mộtClassifierRole sử dụng một biểu tượng lớp, mà là một hình chữ nhật

Cú pháp của tên của một ClassifierRole là: ‘/’ClassifierRoleName ‘:’ClassifierName[‘,’ ClassifierName]*