Xây dựng các ca kiểm thử tự động từ giao diện phần mềm

Để đồng nhất hóa công việc viết Test Case bằng các phương pháp tự động nhằm giảm bớt công sức và thời gian của tester, làm cho chất lượng của Test Case tốt hơn, chúng tôi nghiên cứu phươ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LỜI CAM ĐOAN 3

MỤC LỤC 4

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

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

DANH MỤC CÁC BẢNG 3

Mở đầu 1

Chương 1 3

Tổng quan về kiểm thử và kiểm thử tự động 3

1.1 Kiểm thử phần mềm 3

1.1.1 Khái niệm kiểm thử phần mềm 3

1.1.2 Mục tiêu kiểm thử 3

1.1.3 Luồng thông tin kiểm thử 3

1.2 Kiểm thử tự động 4

1.2.1 Khái niệm kiểm thử tự động 4

1.2.2 Lợi ích và hạn chế của kiểm thử tự động 5

1.2.3 Phân loại công cụ kiểm thử tự động 6

Chương 2 8

Phương pháp sinh ca kiểm thử tự động 8

2.1 Phương pháp sinh Test Case tự động dựa trên đặc tả 8

2.2.1 Phương pháp sinh Test Case dựa trên đặc tả SCR 8

2.2.2 Phương pháp sinh Test Case dựa trên đặc tả UML 12

2.2 Phương pháp sinh Test Case tự động dựa trên Mô hình 16

2.2.1 Phương pháp sinh Test Case dựa trên biểu đồ cộng tác UML 16

2.2.2 Phương pháp sinh Test Case tự động dựa trên lược đồ Use case 20

Chương 3 29

Phương pháp sinh Test Case tự động từ giao diện 29

3.1 Tổ hợp kiểm thử 29

3.1.1 Tham số và mức 29

3.1.2 Tổ hợp các tham số 30

3.1.3 Qui trình thiết kế tổ hợp kiểm thử 31

3.2 Áp dụng phương pháp sinh Test Case từ giao diện với ví dụ cụ thể 32

3.2.1 Kiểm thử form Login 32

3.2.2 Kiểm thử form Lương Cơ Bản 33

Chương 4 35

Công cụ hỗ trợ 35

4.1 Thiết kế chức năng 35

4.1.1 Thiết kế tổng quan 35

4.1.2 Biểu đồ Use case 36

4.1.3 Biểu đồ hoạt động 36

4.1.4 Biểu đồ lớp 37

4.2 Cài đặt 39

4.2.1 Nhập tham số 39

4.2.2 Nhập kết quả 40

4.3 Ưu, nhược điểm của công cụ 45

Kết luận 46 TÀI LIỆU THAM KHẢO 47

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

1 Test Case Ca kiểm thử

4

Hình 1.1 Luồng thông tin kiểm thử 4

Hình 2.1 Quy trình chung của việc tạo ra các Test Case từ đặc tả SCR 11

Hình 2.2 Sự kiện gọi (call events)1 13

Hình 2.3 Sự kiện tín hiệu (signal events)1 13

Hình 2.4 Sự kiện thời gian (time Events) 1 14

Hình 2.5 Sự kiện thay đổi (Change Events) 1 14

Hình 2.6 Quy trình tạo ra các Test Case từ đặc tả UML 15

Hình 2.7 Biểu đồ use-case mô tả yêu cầu của hệ thống đăng kí khóa học của một trường đại học 21

Hình 2.9 Tài liệu mô tả qui trình đăng kí môn học của luồng sự kiện cơ bản của use case 23

Hình 2.10 Tài liệu mô tả qui trình đăng kí môn học của luồng luân phiên của use case 23

Hình 3.1 Quy trình thiết kết tổ hợp kiểm thử 31

Hình 4.1 Biểu đồ Use case 36

Hình 4.2 Biểu đồ hoạt động 37

Hình 4.3 Biểu đồ lớp 38

Bảng 1.1 Các bước sử dụng công cụ để tiến hành kiểm thư tự động……… 5Bảng 2.1 Những kịch bản có thể xảy ra cho biểu đồ biểu diễn tại……… 24Bảng 2.2 Những kịch bản này sẽ sử dụng như cơ sở để tạo ra những Test Case…… 24Bảng 2.3 Ma trận kịch bản từng phần cho Use Case “Đăng kí môn học”………… 25Bảng 2.4 Ma trận Test Case cho Use Case “Đăng kí môn học”……… 26Bảng 2.5 Ma trận Test Case với giá trị dữ liệu……… 27

Mở đầu

Trong những năm gần đây cùng với sự phát triển của phần cứng máy tính, phần mềm có nhiều bước tiến quan trọng Sản xuất phát triển phần mềm hiện nay đã trở thành một ngành công nghiệp thực sự Cũng như các ngành công nghiệp khác, khi quy

mô chức năng của các phần mềm được sản xuất ngày càng phức tạp thì yêu cầu về quản lý chất lượng phần mềm ngày càng được quan tâm Do đó, kiểm thử phần mềm phải được thực hiện thường xuyên trong suốt vòng đời phát triển của phần mềm để đảm bảo chất lượng

Như chúng ta đã biết, giao diện người dùng đồ họa (Graphical User Interface - GUI) là một trong những cách phổ biến nhất để người sử dụng tương tác với hệ thống phần mềm Khi kết thúc giai đoạn kiểm thử hệ thống, các tester tiếp tục kiểm thử phần mềm với các chức năng bổ sung cung cấp bởi giao diện đồ hoạ GUI làm cho việc kiểm thử hệ thống khó khăn hơn vì các nguyên nhân: do bản chất sự kiện điều khiển của GUI, các sự kiện không mong muốn, miền dữ liệu đầu vào/đầu ra vô hạn mà lập trình viên không lường trước được vì không thể kiểm thử tất cả các luồng dữ kiện Thông qua GUI, các tester có thể thực hiện kiểm thử hộp đen để tìm ra lỗi của phần mềm Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các Test Case có hiệu quả Chi phí kiểm thử phần mềm thường chiếm tới 40% tổng các nỗ lực dành cho một dự án phát triển phần mềm Vì thế, giảm chi phí cho việc tạo Test Case (thời gian, công sức) cũng là một trong những vấn đề được quan tâm trong kiểm thử phần mềm Tự động hoá việc tạo Test Case không những giúp giảm chi phí trong việc tạo Test Case mà còn giúp đồng nhất hoá chất lượng Test Case Để đồng nhất hóa công việc viết Test Case bằng các phương pháp tự động nhằm giảm bớt công sức và thời gian của tester, làm cho chất lượng của Test Case tốt hơn, chúng tôi nghiên cứu phương pháp sinh Test Case từ giao diện, từ đó phát triển công cụ sinh Test Case từ giao diện để hỗ trợ tester trong việc tạo Test Case để kiểm thử phần mềm

Luận văn được trình bày theo bốn chương với nội dung sau:

Chương 1: Tổng quan về kiểm thử và kiểm thử tự động

Trình bày tổng quan về kiểm thử, kiểm thử tự động

Chương 2: Phương pháp sinh Test Case tự động

Trình bày các khái niệm cơ bản về Test Case và các Phương pháp sinh Test Case tự động hiện hay

Chương 3: Phương pháp sinh Test Case từ giao diện

Trình bày phương pháp sinh Test Case từ giao diện và áp dụng phương pháp sinh Test Case từ giao diện với ví dụ cụ thể

Chương 4: Công cụ hỗ trợ

Xây dựng công cụ sinh Test Case tự động bằng phương pháp sinh

Test Case từ giao diện

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ề công cụ sinh Test Case tự động, đồng thời đề ra hướng nghiên cứu tiếp theo

Chương 1 Tổng quan về kiểm thử và kiểm thử tự động

1.1 Kiểm thử phần mềm

1.1.1 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau

Theo Glen Myers: Kiểm thử phần mềm là quá trình vận hành chương trình để tìm

ra lỗi [12] Vấn đề đặt ra là: Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất và chi phí (công sức, thời gian) là ít nhất

1.1.2 Mục tiêu kiểm thử

Các nguyên tắc được xem như mục tiêu kiểm thử là:

Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi

Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện

Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát hiện

1.1.3 Luồng thông tin kiểm thử

Luồng thông tin cho kiểm thử được biểu diễn bởi mô hình trong hình 1.1 Hai kiểu của đầu vào được truyền cho quá trình kiểm thử:

Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn

Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm thử, và các công cụ kiểm thử

Hình 1.1 Luồng thông tin kiểm thử

1.2 Kiểm thử tự động

1.2.1 Khái niệm kiểm thử tự động

Trong hầu hết các mô hình phát triển phần mềm, “lập trình – phát triển – sửa lỗi” có thể lặp đi lặp lại rất nhiều lần trước khi phát hành, tuy nhiên hầu hết trong số chúng vẫn tồn tại lỗi Mặc dù nhóm phát triển đã cố gắng phát hiện và sửa lỗi thông qua kiểm thử thủ công nhưng lỗi luôn tiềm ẩn và xuất hiện trở lại Kiểm thử tự động là cách tốt nhất để nâng cao hiệu quả của kiểm thử phần mềm

Kiểm thử thủ công được thực hiện bởi kiểm thử viên thông qua việc quan sát ứng dụng trên màn hình, từ dữ liệu đầu vào, so sánh dữ liệu nhận được với kết quả mong đợi và lưu lại Kiểm thử thủ công được lặp đi lặp lại trong suốt vòng đời phát triển của phần mềm, mỗi khi có sự thay đổi về mã nguồn chương trình, sự thay đổi về môi trường, phần cứng đều phải tiến hành kiểm thử lại Nếu một phần mềm phải thực hiện vài nghìn Test Case thì có thể chỉ đủ thời gian thực hiện số Test Case ấy 1 lần, tuy nhiên, để đảm bảo phần mềm khi phát hành không có lỗi, nhóm phát triển phải kiểm thử rất nhiều lần để kiểm tra xem lỗi tìm ra trong lần kiểm thử trước đó đã được sửa hay chưa và đảm bảo không có lỗi mới phát sinh Kiểm thử tự động có thể giải quyết vấn đề này Kiểm thử tự động phần mềm là tiến trình thực hiện một cách tự động một

số bước của các ca kiểm thử, bằng cách sử dụng một công cụ nhằm rút ngắn thời gian

và công sức kiểm thử [1] Công cụ kiểm thử tự động có thể thực hiện lại các hành động được xác định trước, so sánh với kết qua mong đợi và ghi lại kết quả

Để kiểm thử tự động cần thực hiện các công việc sau [1]:

- Thu thập các đặc tả yêu cầu hoặc các ca kiểm thử, lựa chọn những phần cần thực hiện kiểm thử tự động

- Phân tích và thiết kế mô hình cho kiểm thử tự động

- Sử dụng công cụ để tiến hành kiểm thử, với các bước cho ở bảng sau:

1 Tạo testScript Sử dụng công cụ kiểm thử để ghi lại các thao tác

lên phần mềm và sinh tự động các testScript

2 Chỉnh sửa testScript Chỉnh testScript để thực hiện kiểm tra đúng yêu

cầu đặt ra, tức alf làm theo ca kiểm thử cần thực hiện

3 Chạy testScript Vận hành và giám sát hoạt động kiểm tra phần

mềm bằng testScript

4 Đánh giá kết quả Kiểm tra kết quả sau khi thực hiện kiểm thử tự

động Bổ sung, chỉnh sửa những sai sót nếu cần

Bảng 1.1 Các bước sử dụng công cụ để tiến hành kiểm thư tự động

1.2.2 Lợi ích và hạn chế của kiểm thử tự động

Kiểm thử tự động có một số ưu điểm:

 Tiết kiệm thời gian và chi phí

Sau khi xây dựng, công cụ kiểm thử tự động có thể làm đi làm lại mà không mất thêm chi phí và nhanh hơn kiểm thử thủ công thông thường Kiểm thử tự động có thể giảm thời gian kiểm thử từ thời lượng ngày, sang giờ Tiết kiệm được thời gian tức

là tiết kiệm được chi phí

 Tăng độ chính xác

Ngay cả những kiểm thử viên nhiều kinh nghiệm cũng có thể có những sai lầm khi thực hiện kiểm thử thủ công Kiểm thử tự động sẽ thực hiện các bước một cách chính xác vào mọi thời điểm và luôn ghi lại kết quả kiểm thử

 Tăng độ bao phủ của kiểm thử

Kiểm thử tự động tăng phạm vi của kiểm thử từ đó cải thiện chất lượng phần mềm Kiểm thử tự động có thể thực hiện những công việc mà kiểm thử thủ công không làm được, như chạy trên nhiều máy tính với cấu hình khác nhau Kiểm thử tự động có thể “nhìn” bên trong của ứng dụng, xem nội dung của bộ nhớ, bảng dữ liệu, nội dung tập tin và trạng thái của chương trình để xác định xem sản phẩm có đáp ứng được mong đợi không Kiểm thử tự động có thể thực hiện hàng nghìn Test Case phức tạp một cách dễ dàng trong suốt thời gian kiểm thử để bao phủ hết tất cả các trường hợp

 Kiểm thử tự động làm những việc mà kiểm thử thủ công không làm được

Với một công ty phần mềm lớn nhất cũng không thể thực hiện việc kiểm soát ứng dụng web với hàng nghìn người truy cập cùng 1 lúc Kiểm thử tự động có thể mô phỏng hàng chục, hàng trăm hay thậm chí hàng nghìn người sử dụng ảo tương tác với mạng hay ứng dụng web

Bên cạnh đó cũng có những khó khăn cơ bản sau [1]:

- Cần chi phí để tạo và bảo trì các đặc tả kiểm thử (script)

- Đòi hỏi kỹ thuật viên phải có kĩ năng sử dụng công cụ tạo script

- Không áp dụng được trong việc tìm lỗi mới của phần mềm

1.2.3 Phân loại công cụ kiểm thử tự động

Chi phí kiểm thử phần mềm thường chiếm tới 40% tổng các nỗ lực dành cho một dự án phát triển phần mềm Vì thế, các nhà nghiên cứu và người thực hành đã cố gắng phát triển một số thế hệ các công cụ kiểm thử tự động khác nhau để giúp giảm thiểu chi phí này Chúng bao gồm:

- Bộ phân tích tĩnh Các hệ thống phân tích chương trình hỗ trợ cho “việc chứng minh” các lỹ lẽ tĩnh để phát hiện những vấn đề yếu kém về cấu trúc

và định dạng của chương trình

- Bộ kiểm toán mã Những bộ lọc chuyên dụng dùng để kiểm tra chất lượng chương trình để đảm bảo rằng, nó đáp ứng các chuẩn mã hoá tối thiểu

- Bộ xử lý khẳng định Những hệ thống tiền xử lý/hậu xử lý này được sử dụng

để cho biết liệu những mệnh đề do người lập trình tạo ra, được gọi là khẳng định về hành vi của chương trình có thực sự đáp ứng được yêu cầu khi thực hiện chương trình hay không

- Bộ sinh tệp kiểm thử Những bộ xử lý sinh ra và điền các giá trị đã xác định vào các tệp để chương trình đọc vào khi kiểm thử

- Bộ sinh dữ liệu kiểm thử Những hệ thống phân tích hỗ trợ cho người dùng trong việc lựa chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một cách cụ thể

- Bộ kiểm chứng kiểm thử Chúng đo mức bao quát của việc kiểm thử bên trong, thường liên quan tới cấu trúc điều khiển của sự vật kiểm thử và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng

- Bộ mô phỏng môi trường Nó là một hệ thống dựa trên máy tính giúp người kiểm thử mô hình hoá môi trường bên ngoài của hệ thời gian thực để mô phỏng các điều kiện vận hành thực một cách động

- Bộ phân tích luồng dữ liệu Công cụ này theo dõi dấu vết luồng dữ liệu đi qua hệ thống (tương tự như bộ phân tích đường đi) và cố gắng tìm ra những

tham chiếu dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên quan tới dữ liệu

Việc dùng công cụ để tự động hoá kiểm thử phần mềm đang phát triển, và có thể

sẽ phát triển rất nhanh trong thập kỉ tới Các công cụ kiểm thử tạo ra những thay đổi lớn trong kiểm thử phần mềm, đem lại hiệu quả kinh tế cũng như cải tiến độ tin cậy của các hệ thống dựa trên máy tính một cách đáng kể

Chương 2 Phương pháp sinh ca kiểm thử tự động

Ca kiểm thử (Test Case) là một thành phần mô tả đầu vào, hành động hoặc sự kiện và một kết quả mong đợi để xác định liệu một chức năng của ứng dụng đó làm việc đúng không Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các Test Case có hiệu quả Chi phí kiểm thử phần mềm thường chiếm tới 40% tổng các nỗ lực dành cho một dự án phát triển phần mềm Vì thế, giảm chi phí cho việc tạo Test Case (thời gian, công sức) cũng là một trong những vấn đề được quan tâm trong kiểm thử phần mềm Tự động hoá việc tạo Test Case không những giúp giảm chi phí trong việc tạo Test Case mà còn giúp đồng nhất hoá chất lượng Test Case

Có hai phương pháp tạo Test Case tự động: phương pháp tĩnh và phương pháp động Phương pháp tĩnh dựa trên thực thi các ký hiệu mô tả; phương pháp động đạt được từ dữ liệu cần thiết bằng việc chạy chương trình trong khi kiểm thử

Đã có nhiều nghiên cứu về việc sinh 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 Từ khi ngôn ngữ mô hình được sử dụng rộng rãi, đã có rất nhiều nghiên cứu về phương pháp sinh Test Case tự động dựa trên mô hình bằng cách sử dụng lược đồ UML như: state-chart diagrams, use-case diagrams, sequence diagrams,

2.1 Phương pháp sinh Test Case tự động dựa trên đặc tả

Đặc tả có vai trò quan trọng trong kiểm thử phần mềm Thứ nhất, đặc tả cung cấp thông tin để kiểm tra đầu vào/đầu ra của chương trình có đúng không Thứ hai, đặc

tả cung cấp thông tin để lựa chọn Test Case và để đánh giá độ phù hợp của kiểm thử Kiểm thử dựa trên đặc tả lấy thông tin kiểm thử từ đặc tả của phần mềm Trong kiểm thử phần mềm, kiểm thử dựa trên đặc tả có nhiều ưu điểm Kiểm thử dựa trên đặc tả đơn giản hơn các kỹ thuật kiểm thử không dựa trên đặc tả Bên cạnh đó, nhờ phát triển giai đoạn kiểm thử cùng lúc với việc thực hiện và thiết kế cho phép sử dụng các kiểm thử đã lấy được để chuẩn hoá đặc tả gốc giúp tăng chất lượng đặc tả - cũng là tăng chất

lượng phần mềm

2.2.1 Phương pháp sinh Test Case dựa trên đặc tả SCR

Đặc tả SCR (Software Cost Reducation) xây dựng bảng để xác định yêu cầu hành vi cho hệ thống phần mềm gắn vào thời gian thực Lợi ích của phương pháp SCR là: cấu trúc xác định tốt, điều này cho phép sử dụng phương pháp phân tích cấu trúc

kiểm tra sự đồng nhất và 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ừ yêu cầu phần mềm với mã nguồn Phương pháp sinh Test Case dựa theo đặc tả SCR thiết lập các tiêu chuẩn 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 hoá hoàn toàn việc tạo Test Case [10]

2.2.2.1 Mô hình kiểm thử

Trong mô hình, kiểm thử được tạo ra như một sản phẩm nhiều mức, nhiều bước thực hiện và nhiều 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 thoả 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 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

Để áp dụng những mức này, các đặc tính/yêu cầu dựa trên trạng thái và xem 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 chuyển tiếp có thể

(1) Mức chỉnh sửa kế tiếp

Mức này tương tự với tiêu chuẩn chỉnh sửa nhánh trong kiểm thử cấu trúc 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

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 giống như mệnh đề được kiểm thử

 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 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 thuộc tính, mỗi sự xuất hiện là một mệnh đề riêng biệt

Mức chỉnh sửa đầy đủ các thuộc tính đòi hỏi 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

Giả sử ta có thuộc tính (X^Y), X là mệnh đề kiểm thử, thì Y phải đúng Tương

tự như vậy, nếu thuộc tính là (XvY), Y phải là sai

Để thoả mãn đầy đủ các thuộc tính, ta sử dụng cây biểu thức từng phần Cây biểu thức từng phần là một cây nhị phân có nhiều toán tử nhị phân và nhiều toán hạng

cho các nút, 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 là AND(^), OR(v), và các toán tử liên quan {> , < , <=, >= , #}; toán tử NOT

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 thì 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

Khi mệnh đề gốc đã đạt được, các giá trị có thể được sinh ngược trở lại bằng cách 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 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

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 Trường hợp này, mệnh đề tương đương với các biến khởi động sự kiện nên đưa ra giá trị khác nhau, nhưng nên duy trì các biến đó Nếu nó không còn là một biến khởi động nữa tương đương với việc không Test Case Thêm vào đó, một biến khởi động sự kiện thực tế xác định hai giá trị, một giá trị trước và một giá trị sau Để kiểm thử đầy đủ các thuộc tính với các biến khởi động sự kiện, cả giá trị trước và sau nên được kiểm thử Điều này được thực hiện bằng việc giả định hai phiên bản của biến khởi động sự kiện, A và A',

ở đó A đưa ra giá trị trước và A' cho ra giá trị sau

(3) Mức chỉnh sửa các 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 nên các yêu cầu kiểm thử Giả sử 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ự

Giả sử có trạng thái sau:

Để kiểm trử trạng thái S ở mức độ cặp chuyển tiếp, phải kiểm thử 6 lần: (1) từ 1 đến i, (2) từ 2 đến i, (3) từ 1 đến ii, (4) từ 2 đến ii, (5) từ 1 đến iii, (6) từ 2 đến iii Việc

kiểm thử này đòi hỏi các đầu vào phải thoả mãn các thuộc tính: P1:Pi, P1:Pii, P1:Piii, P2:Pi, P2:Pii và P2:Piii

Quy trình sinh ra Test Case từ đặc tả SCR gồm các bước sau:

- Bước 1: Phát triển các điều kiện chuyển tiếp Với một số ngôn ngữ đặc tả (ví

dụ SCR), các điều kiện chuyển tiếp được mã hóa trực tiếp trong các đặc tả (đặc tả chức năng) Với các ngôn ngữ khác, các điều kiện có thể phải qua một thao tác chuyển hoá khác

- Bước 2: Phát triển các đồ thị đặc tả Ta có thể lấy trực tiếp đồ thị đặc tả từ bảng đặc tả

- Bước 3: Phát triển các yêu cầu kiểm thử Các yêu cầu kiểm thử xuất phát từ các đặc tính chuyển tiếp và được tạo ra từ các điều kiện chuyển tiếp ở bước 1

- Bước 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 chân lý cho tất cả các thuộc tính trong đồ thị đặc tả, từ đó xây dựng cây biểu thức từng

Đặc tả chức năng

Đồ thị đặc tả Yêu cầu kiểm thử Đặc tả kiểm thử

Kịch bản kiểm thử

Hình 2.1 Quy trình chung của việc tạo ra các Test Case từ đặc tả SCR

phần Ta có thể dựa trên cây biểu thức từng phần hoặc dựa trực tiếp vào đặc tả để kiểm thử chỉnh sửa các thuộc tính

- Bước 5: Phát triển các yêu cầu kiểm thử cặp chuyển tiếp Xác định tất cả các cặp chuyển tiếp bằng cách: 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 Những cặp chuyển tiếp này sẽ được thay thế bởi các thuộc tính từ đồ thị đặc tả

- Bước 6: Phát triển các yêu cầu kiểm thử hoàn chỉnh Xác định danh sách hoàn chỉnh của các trạng thái bằng cách: từ biểu đồ đặc tả, chọn trình tự của các trạng thái (công việc này do tester đảm nhiệm) Sau đó, xây dựng trình tự của các thuộc tính

- Bước 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ử 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

- Bước 8: Xây dựng các tập lệnh kiểm thử Mỗi đặc tả kiểm thử sử dụng để xây dựng một tập lệnh Các tập lệnh kiểm thử phản ánh cú pháp đưa vào của chương trình,

vì vậy cần có sự am hiểu về cú pháp đưa vào của chương trình

2.2.2 Phương pháp sinh Test Case dựa trên đặc tả UML

Đặc tả UML mô tả hành vi của đối tượng, do đó, xây dựng Test Case từ đặc tả UML sẽ kiểm thử được toàn bộ hành vi của đối tượng

2.2.2.1 Mô hình kiểm thử

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ó Trạng thái động của đối tượng được mô hình hóa thông qua sự chuyển đổi từ một trạng thái này sang trạng thái khác Trong UML có năm loại chuyển trạng thá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 Vì mục đích sinh ra mô hình nên ta chỉ xem xét đến chuyển trạng thái khả năng Trạng thái khả năng được kích hoạt khi tồn tại ít nhất một đường dẫn hoàn chỉnh từ trạng thái nguồn đến trạng thái đích [11]

Sự kiện xuất hiện khi đối tượng chuyển từ trạng thái này sang trạng thái khác UML xác định bốn loại sự kiện: sự kiện gọi (call event), sự kiện tín 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 đinh 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 2.2 minh họa một sự kiện gọi

Một sự kiện tín hiệu đưa ra sự chấp nhận của một dấu hiệu đồng bộ cụ thể Các

sự kiện tín hiệu được mô hình hóa như các loại được dập khuôn đưa ra trong hình 2.3

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 2.4 minh họa một sự kiện thời gian

1 Tham khảo theo tài liệu [11]

event

Paramenters startAutopilot(normal)

Hình 2.2 Sự kiện gọi (call events) 1

<<signal>>

Collision

Force:Float

MovementAgent Position

velocity MoveTo()

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 2.5 minh họa một sự kiện thay đổi

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

Idle

Active

after (2 seconds) /dropConnection()

(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ị của 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ự

(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

2.2.2.2 Tổng kết

Hình 2.6 đưa ra quy trình chung tạo ra các Test Case

Quy trình tạo ra Test Case từ đặc tả UML gồm các bước:

- Bước 1: Phát triển các điều kiện chuyển tiếp Bước đầu tiên là được phát triển các điều kiện chuyển tiếp, được xác định những điều kiện mỗi chuyển tiếp được thực hiện Trong UML, các điều kiện được mã hóa trực tiếp trong các đặc tả

- Bước 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ử

- Bước 3: 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 chân lý cho tất cả các thuộc tính trong đồ thị đặc tả, từ đó xây dựng cây biểu thức từng

Trạng thái UML Phát triển điều kiện chuyển tiếp Yêu cầu kiểm thử

Đặc tả kiểm thử Kịch bản kiểm thử

Hình 2.6 Quy trình tạo ra các Test Case từ đặc tả UML

phần Ta có thể dựa trên cây biểu thức từng phần hoặc dựa trực tiếp vào đặc tả để kiểm thử chỉnh sửa các thuộc tính

- Bước 4: Phát triển các yêu cầu kiểm thử cặp chuyển tiếp Phát triển các yêu cầu kiểm thử cặp chuyển tiếp Xác định tất cả các cặp chuyển tiếp bằng cách: 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 Những cặp chuyển tiếp này sẽ được thay thế bởi các thuộc tính

từ đồ thị đặc tả

- Bước 5: Phát triển các yêu cầu kiểm thử trình tự hoàn chỉnh Xác định danh sách hoàn chỉnh của các trạng thái bằng cách: từ biểu đồ đặc tả, chọn trình tự của các trạng thái (công việc này do tester đảm nhiệm) Sau đó, xây dựng trình tự của các thuộc tính

- Bước 6: Xây dựng các đặc tả kiểm thử Với mỗi một yêu cầu kiểm thử 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

- Bước 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, do đó cần có sự hiểu biết về cú pháp đưa vào của chương trình

2.2 Phương pháp sinh Test Case tự động dựa trên Mô hình

Phương pháp sinh Test Case dưa trên Mô hình là phương pháp tập trung vào việc

sử dụng các biểu đồ trong UML như biểu đồ trạng thái, biểu đồ lớp, lược đồ use-case,

để sinh Test Case

Sử dụng các biểu đồ trạng thái trong việc tạo ra các Test Case định ra cá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

Sử dụng lược đồ use-case trong việc tạo ra Test Case cho phép sinh ra các Test Case mang tính hệ thống, giúp 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ượng phần mềm một cách hiệu quả

2.2.1 Phương pháp sinh Test Case dựa trên biểu đồ cộng tác UML

Biểu đồ cộng tác UML mô tả chính xác chức năng của phần mềm Bên cạnh đó, biểu đồ cộng tác UML cung cấp một kết nối trong một hình thức mà có thể dễ dàng được vận dụng để tự động hoá Tạo Test Case tự động dựa trên biểu đồ cộng tác UML

là một trong những phương pháp tiêu biểu sinh Test Case dựa trên mô hình

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

Mô ̣t biểu đồ cô ̣ng tác là mô ̣t sự mô tả đồ ho ̣a của mô ̣t sự cô ̣ng tác 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 đường rãnh (Slots) được điền vào bởi

các đối tượng và các đường liên kết tại thời điểm chạ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ủa một đối tượng hoặc đường liên kết bên trong cộng tác

Mô ̣t sự cô ̣ng tác gồm các ClassifierRoles , AssociationRoles, và Interaction Mô ̣t ClassifierRole xác đi ̣nh 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 đi ̣nh các mối qua n hê ̣ của ClassifierRole tới các vai trò khác Mô ̣t Interaction là mô ̣t chuỗi của các liên kết trong mô ̣t bô ̣ các đối tươ ̣ng bên trong mô ̣t đă ̣c tả để thực hiê ̣n mô ̣t mu ̣c tiêu cu ̣ thể

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 đối tươ ̣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ủ tu ̣c mà thực hiê ̣n mô ̣t thao tác đó Nó là một thuật toán hoă ̣c mô ̣t phần mô tả thủ tục

Các đối tượ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

Có 2 dạng biểu đồ cộng tác: biểu đồ cộng tác mức đặc tả và biểu đồ cộng tác mức thao tác Biểu đồ cộng tác mức đặc tả cho thấy các vai trò được xác định bên trong mộ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ới ClassifierRoles và AssociationRoles trong sự cộng tác; Biểu đồ cộng tác mức thao tác dùng để mô tả thao tác trên đối tượng, cung cấp các thông tin xác định, chẳng hạn (1) các tham số cho thao tác và cách sử dụng chúng, (2) các tính chất của việc tham gia vào các biến, ví dụ cục bộ hoặc toàn cục, (3) các ràng buộc qua các kết hợp, và (4) việc xây dựng và/hoặc bỏ đi của các đối tượng trong quá trình

2.2.1.2 Các tiêu chuẩn test

Các biểu đồ cộng tác mô tả cấu trúc và hành vi của hệ thống Mô ̣t biểu đồ cô ̣ng tác UML xác định những yêu cầu gì phải được hoàn thành bởi các đối tượng trong một

hê ̣ thống, và những liên kết gì phải được thực hiê ̣n giữa các đối tượng cho mô ̣t công viê ̣c cu ̣ thể đươ ̣c thực hiê ̣n Các biểu đồ cộng tác UML được sử dụng ở các mức độ trừu tượng đă ̣c tả khác nhau Với các biểu đồ cô ̣ng tác hoă ̣c các biểu đồ lớp với các biểu đồ cô ̣ng tác, có thể được sử dụng để kiểm tra tĩnh mã và test việc chạy ứng dụng

(1) Mô ̣t số đi ̣nh nghi ̃a

Trước khi xác đi ̣nh các tiêu chuẩn test ta xác đi ̣nh 12 loại có thể kết nối trong các biểu đồ cô ̣ng tác Các loại của các cặp hoặc các đường link, là gọi lại về các định nghĩa về luồng dữ liê ̣u , nhưng đưa ra các tương tác dữ liê ̣u mà xuất hiê ̣n ở mô ̣t mức đô ̣ thiết kế cao hơn luồng dữ liê ̣u tryền thống Chúng được phân loại dựa trên thông tin từ các biểu đồ lớp và các biểu đồ cộng tác, nhưng một khi đã định nghĩa, chỉ các biểu đồ cộng tác cần để tạo ra các test

Một cặp cộng tác là một cặp của ClassifierRolers hoặc AssociationRoles mà được kết nối thông qua một đường link trong biểu đồ cộng tác Phần ClassifierRolers mô tả loại của Object với một bộ của các thao tác và thuộc tính được yêu cầu

Một đường link định nghĩa biến số là một đường link mà các tác nhân hoạt động của nó có một giá trị trả lại và được gán vào biến cục bộ Một đường link cách sử dụng biến số là một đường link mà danh sách đối số của các tác nhân hoạt động gồm một biến cục bộ Một đường link định nghĩa đối tượng là một tác nhân hoạt động mà đưa lại một tham chiếu tới một đối tượng mà có thể sử dụng được cho đối tượng mục tiêu

Sử dụng một đường link tạo ra đối tượng là một đường link các tác nhân hoạt động của

nó dẫn chứng tạo ra của lớp CollaborationRole Một đường link cách sử dụng đối tượng là một đường link mà các tác nhân hoạt động của nó dẫn chứng một phương thức về một đối tượng có thể sử dụng cục bộ Một đường link phá hủy một đối tượng

là một đường link mà các tác nhân hoạt động của nó dẫn chứng phá hủy về một đối tượng có thể sử dụng cục bộ

Đôi khi chúng ta quan tâm đến các cặp của các đường link Một cặp đường link

sử dụng khác của biến số là một cặp của các đường link mà trong đó một đối tượng trước tiên được sử dụng và sau đó bị bỏ đi Một đường dẫn chuỗi các tin nhắn là một đường dẫn mà gồm tất cả tin nhắn trong một cộng tác theo một trật tự được xác định bởi một biểu đồ cộng tác

Các cặp đường link cách sử dụng định nghĩa biến số, các cặp đường link cách sử dụng tạo ra đối tượng có thể được sử dụng để kiểm tra tĩnh các mã Các đường dẫn chuỗi tin nhắn có thể được sử dụng để tạo ra các Test Case

(2) Kiểm tra tĩnh

Kiểm tra có thể thực hiện tĩnh hoặc động Ở khía cạnh nào đó phần mềm được thực hiện trên một vài dữ liệu nhập Kiểm tra tĩnh liên quan tới một vài khía cạnh của phần mềm mà không cần thực hiện, thường bằng cách đánh giá mã nguồn

Các biểu đồ cộng tác cung cấp các ràng buộc trên một hệ thống Ví dụ, một biểu

đồ cộng tác cho một thao tác mô tả thông tin cụ thể mà cần thiết cho thao tác này để được hoàn thành, chẳng hạn các giá trị trả lại cho một phương thức trong một quá trình, các loại tham số, vv…

Chúng ta xác định bốn mục nên được sử dụng để kiểm tra mã tĩnh, được mô tả như sau:

1 ClassifierRoles: Trong một động tác, nếu hai ClassifierRoles bắt nguồn cùng một lớp cơ sở giống nhau, chúng nên được phân biệt trong điều kiện của các thao tác được yêu cầu của chúng và các giá trị của các thuộc tính Bởi vì chúng bắt đầu tư cùng lớp, có khả năng rằng chúng có thể nhầm lẫn với nhau Vì lí do này, ClassifierRoles

mà bắt đầu từ cùng lớp nên được test để biết nếu chúng có tất cả các thuộc tính và các thao tác được yêu cầu

2 Collaborating: Các đường link trên một biểu đồ cộng tác mô tả các ràng buộc cấu trúc của một cặp cộng tác và các thông điệp liên kết của chúng Sự kết hợp này nói nếu nó là một mối quan hệ một - một, một - nhiều hoặc nhiều - nhiều mối quan hệ phản ánh một ràng buộc trong đặc tả yêu cầu Do đó, test mối quan hệ cấu trúc giữa các đối tượng có thể như là sự xác nhận của các yêu cầu Mỗi cặp cộng tác trên biểu đồ cộng tác nên được kiểm tra hoặc test ít nhất một lần

3 Thông điệp hoặc các tác nhân kích thích: Các thông điệp cung cấp thông tin về:

- Loại giá trị trả về

- Chuỗi kiểm soát

- Thao tác hoặc tên phương pháp được dẫn chứng trên đối tượng mục tiêu

- Các tham số tới các toán tử hoặc phương thức

Test của một thông điệp bản thân nó có bộc lộ nhiều vấn đề tích hợp nhất

Một tác nhân hoạt động là một ví dụ về một thông điệp Một tác nhân hoạt động

có thể là một dấu hiệu, một phương thức hoặc việc gọi toán tử, hoặc một sự kiện mà khiến một đối tượng tạo ra hoặc bị phá hủy Bên cạnh đó mang theo một dữ liệu xác định các thông điệp có một đường Đó là, một tác nhân hoạt động bắt nguồn từ một đối tượng nguồn (Sender) và cư trú trên một đối tượng đích (Receiver) Chúng ta có thể nhận thấy rằng các tác nhân hoạt động cung cấp thông tin ban đầu cho việc test tích hợp, do đó mỗi tác nhân hoạt động nên được sử dụng như một cơ sở cho việc tạo ra các đầu vào test

4 Kiểm tra đường link cách sử dụng định nghĩa biến số (Local variable Definition- Usage Link Pairs) cho chúng ta tìm thấy những sự không bình thường của luồng dữ liệu ở mức độ thiết kế Các cặp đường link sau đây tất cả nên được kiểm tra cho các bất thường của luồng dữ liệu:

- Global Variable Definition- Use Pairs

- Object Creation- Use Pairs

- Object Use- Destruction Pairs

- Object Creation - Destruction Pairs

(3) Kiểm tra động

Các biểu đồ cộng tác cung cấp một đường dẫn hoàn chỉnh cho một Use case hoặc một sự hiểu rõ về một toán tử Vì mục đích của kiểm tra động ta tập trung vào các biểu đồ cộng tác cho sự hiểu rõ của các toán tử Chúng ta giả định rằng có một biểu đồ cộng tác mỗi thao tác, và sự thực hiện của một thao tác khẳng định tới sự cộng tác Thêm nữa, các biểu đồ cộng tác cung cấp một thông tin cần thiết để test sự tương tác đối tượng

Tiêu chuẩn test: Với mỗi biểu đồ cộng tác trong đặc tả phải có ít nhất một Test Case như vậy như phần mềm được thực hiện sử dụng phần mềm mà thực hiện đường dẫn chuỗi thông điệp của biểu đồ cộng tác phải được thực hiện

Mỗi biểu đồ cộng tác mô tả một dấu vết hoàn chỉnh của các thông điệp trong khi thực hiện một toán tử Do đó, một đường dẫn chuỗi thông điệp gồm tất cả các cặp đường link sử dụng khác nhau biến số các cặp đường link sử dụng khác nhau các đối tượng, các cặp đường link cách sử dụng tạo ra đối tượng, các cặp đường link phá hủy cách sử dụng đối tượng

Chúng ta có thể tạo ra một đường dẫn chuỗi thông điệp bằng việc sử dụng các thông điệp và số lượng trong chuỗi đó Các đường dẫn chuỗi thông điệp có thể là dấu vết của các tương tác mức hệ thống hoặc các tương tác mức thành phần (đối tượng)

Các tiêu chuẩn của loại này thường được sử dụng theo một trong hai cách sau đây Tiêu chuẩn có thể được sử dụng là một hướng dẫn cho việc tạo ra các test, hoặc tiêu chuẩn có thể được sử dụng như là một hệ cho việc đánh giá các test được tạo ra bên ngoài Ở đây tập trung vào việc khuôn khổ của tiêu chuẩn: tạo ra test

Để test hệ thống sẽ đưa ra một dấu vết của sự kiện khẳng định cho đường dẫn chuỗi thông điệp chúng ta lấy được từ biểu đồ cộng tác, đưa các câu lệnh vào trương chương trình gốc

2.2.1.3 Kết luận

Phương pháp sinh Test Case tự động dựa trên biểu đồ cộng tác UML sử dụng

cả theo hướng tĩnh và động Các phân tích tĩnh cho phép tester phát hiện các vấn đề nhất định mà phản ánh sự nhập nhằng trong thiết kế và các hiểu sai về phần của người lập trình và người thiết kế chi tiết Kỹ thuật động cho phép dữ liệu test được tạo ra có thể đảm bảo khả năng tin cậy của các đối tượng ở mức độ thực hiện và khả năng tương tác giữa chúng

2.2.2 Phương pháp sinh Test Case dựa trên lược đồ use case

Use case là một khối chức năng được thực hiện bởi hệ thống để mang lại một kết quả có giá trị đối với một actor nào đó Use case mô tả sự tương tác đặc trưng giữa người dùng và hệ thống Nó thể hiện ứng xử của hệ thống đối với bên ngoài, trong một hoàn cảnh nhất định, xét từ quan điểm của người sử dụng Nó mô tả các yêu cầu đối với hệ thống, có nghĩa là những gì hệ thống phải làm chứ không phải mô tả hệ thống làm như thế nào Tập hợp tất cả use case của hệ thống sẽ mô tả tất cả các trường hợp

mà hệ thống có thể được sử dụng