Luận văn: Kỹ thuật sinh test case tự động từ yêu cầu phần mềm : Luận văn ThS. Công nghệ thông tin: 60 48 10
Nhà xuất bản: ĐHCN
Ngày: 2008
Chủ đề: Công nghệ phần mềm
Kỹ thuật sinh test case
Phần mềm
Tin học
Miêu tả: 68 tr. + CD-ROM
Đưa ra các vấn đề cần thiết và cấp bách trong việc nghiên cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu người dùng. Giới thiệu tổng quan về quá trình sinh test case tự động và các phương pháp sinh Test case: Sinh Test case dựa trên đặc tả, sinh test case dựa trên mô hình, sinh test case hướng đường dẫn. Trình bày các phương pháp và kỹ thuật sinh Test case tự động hiện có, từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ưu điểm của nó so với các kỹ thuật trước. Phát triển chương trình ứng dụng quá trình sinh Test case tự động
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công Nghệ. Đại học Quốc gia Hà Nội, 2008
MỤC LỤC
CHƢƠNG 1. ĐẶT VẤN ĐỀ ................................................................................ 6
1.1. Tầm quan trọng của các yêu cầu phần mềm .................................................6
1.2. Khái niệm về Test case..................................................................................6
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm . ........................................7
CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH ................................................... 8
SINH TEST CASE TỰ ĐỘNG................................................................................ 8
2.1. Giới thiệu.......................................................................................................8
2.2. Tổng quan về các phƣơng pháp sinh Test case .............................................8
2.2.1. Sinh Test case dựa trên đặc tả .......................................................................9
2.2.2. Sinh Test case dựa trên mô hình....................................................................9
2.2.3. Sinh Test case hƣớng đƣờng dẫn.................................................................10
2.3. Kiểm thử phần mềm và UML .....................................................................10
CHƢƠNG 3. CÁC KỸ THUẬT VÀ PHƢƠNG PHÁP SINH .......................... 11
TEST CASE TỰ ĐỘNG ........................................................................................ 11
3.1. Giới thiệu.....................................................................................................11
3.2. Kỹ thuật sinh Test case dựa trên đặc tả .......................................................12
3.2.1. Các phƣơng thức đặc tả trạng thái SCR ......................................................13
3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tả của SCR ...................................14
3.2.3. Kỹ thuật tạo Test case cho đặc tả UML ......................................................21
3.2.4. Các thuận toán sinh Test case dựa trên đặc tả.............................................28
3.3. Kỹ thuật sinh Test case dựa trên mô hình ...................................................36
3.3.1. Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UML .................37
3.3.2. Tạo Test case dựa trên Use case cải tiến .....................................................45
CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG......................... 57
QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG....................................................... 57
4.1. Mục tiêu.......................................................................................................57
4.2. Tóm tắt quá trình sinh Test case tự động ....................................................57
4.2.1. Ví dụ ............................................................................................................57
4.2.2. Các Test case của ví dụ ...............................................................................60
4.2.3. Tính ứng dụng, các ƣu điểm và nhƣợc điểm...............................................60
4.2.4. Kết luận .......................................................................................................61
4.3. Cài đặt..........................................................................................................62
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-2-
DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT
Từ và cụm từ viết tắt Viết đầy đủ
UML Unified Modeling Language
OCD Object Collaboration Diagram
SCR Software Cost Reducation
Test Sự kiểm thử
Tester Kiểm thử viên-3-
DANH MỤC CÁC HÌNH VẼ
Stt Tên hình vẽ
1 Một quy trình kiểm tra cơ bản.
2 Kiểm thử dựa trên đặc tả
3 Kiểm thử dựa trên chương trình
4 Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp
5 Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR
6 Sự kiện gọi (call events)
7 Sự kiện báo hiệu (signal events)
8 Sự kiện thời gian (time Events)
9 Sự kiện thay đổi (Change Events)
10 Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML
11 Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái.
12 Biểu đồ lớp của mô hình thiết kề
13 OCD cho việc sinh ra các Test case chỉnh sửa đầy đủ các thuộc tính
14 OCD cho việc sinh ra các Test case chỉnh sửa chuyển tiếp
15 OCD cho việc sinh ra các Test case chỉnh sửa cặp chuyển tiếp.
16 Thuật toán phân tích đặc tả SCR
17 Thuật toán phân tách đặc tả UML
18 Biểu đồ cộng tác mức độ đặc tả
19 Biểu đồ cộng tác cho một thao tác
20 Các cặp cộng tác
21 Một đường chuỗi thông điệp
22 Thuật toán instrumentation
23 Mô hình hóa các vùng trong thiết kế phần mềm
24
Các hoạt động của cách tiếp cận được đề xuất bên trong quá trình
phát triển phần mềm.
25 Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3.
26 Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3
27 Mô hình cách sử dụng có thể cho ví dụ thư viện của bảng 3.
28 Mô hình hành vi
29 Các lược đồ test và các giá trị test
30 Test case cho kịch bản chính
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-4-
DANH MỤC CÁC BẢNG BIỂU
Stt Tên bảng biểu
1 Phân biệt các biểu đồ UML và các mức độ test
2 Mẫu cải tiến các use case
3 Một ví dụ về mẫu chi tiết các use case-5-
MỞ ĐẦU
Mặc dù việc nghiên cứu về các phương pháp và kỹ thuật sinh Test case tự động
từ yêu cầu người dùng đã được quan tâm nhiều trên thế giới, nhưng ở Việt Nam các
nghiên cứu và ứng dụng chỉ mới ở bước đầu. Thực vậy, công việc sinh Test case tự
động từ yêu cầu người dùng một cách có hiệu quả trong quá trình kiểm thử là vấn đề
cần thiết và bức xúc của các công ty sản xuất phần mềm cũng như các tổ chức thực
hiện phát triển dự án phần mềm.
Trong quá trình phát triển dự án phần mềm, thường công việc tạo ra các Test
case từ yêu cầu người dùng do các Tester phụ trách. Nhưng không phải Tester nào viết
các tài liệu Test case này cũng như nhau. Vì vậy trong các công ty phần mềm cũng
như các tổ chức thực hiện phát triển các dự án phần mềm sẽ phát sinh một vấn đề là:
Tester nào viết tài liệu Test case tốt, có hiệu quả thì chất lượng phần mềm sẽ tốt hơn
những dự án có Test case tồi. Vậy tại sao chúng ta không đồng nhất hóa công việc viết
Test case bằng các phương pháp và kỹ thuật tự động nhằm giảm bớt công sức và thời
gian của các tester, làm cho chất lượng của Test case tốt hơn.
Có các hướng tiếp cận khác nhau trong việc sinh Test case tự động: thứ nhất là
có thể sinh Test case tự động dựa trên đặc tả từ một file input đã được định sẵn; thứ
hai là sinh Test case tự động dựa trên code, chương trình có sẵn; thứ ba là sinh Test
case tự động dựa trên các mô hình UML. Trong ba hướng tiếp cận trên chúng tui chọn
hướng tiếp cận thứ ba và nghiên cứu các phương pháp theo hướng tiếp cận này.
Trong đề tài luận văn này chúng tui nghiên cứu các vấn đề về tạo Test case tự
động từ yêu cầu người dùng. Sau đó, chúng tui xem xét các phương pháp và kỹ thuật
hiện có trong việc tạo Test case tự động để từ đó có thể đưa ra những cải tiến bổ sung
và phát triển. Cuối cùng là xây dựng một công cụ sinh Test case tự động có thể áp
dụng trong thực tế.
Bố cục của luận văn gồm phần mở đầu, phần kết luận và 4 chương nội dung
như sau:
Chƣơng 1: Đặt vấn đề, đưa ra các vấn đề cần thiết và cấp bách trong việc
nghiên cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu người dùng.
Chƣơng 2: Giới thiệu tổng quan về sinh Test case tự động. Trên cơ sở đó chọn
hướng tiếp cận sẽ đi sâu vào nghiên cứu ở Chương 3.
Chƣơng 3: Trình bày các phương pháp và kỹ thuật sinh Test case tự động hiện
có. Từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ưu điểm của nó so
với các kỹ thuật trước.
Chƣơng 4: Trình bày quá trình sinh Test case hiệu quả dựa trên kỹ thuật được
đề xuất. Đồng thời xây dựng chương trình demo quá trình sinh Test case tự động.
Sau khi nghiên cứu và thử nghiệm, trong phần Kết luận có nêu một số tổng kết và
nhận xét về việc sinh Test case tự động, đồng thời đề ra hướng nghiên cứu tiếp theo.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-6-
CHƢƠNG 1. ĐẶT VẤN ĐỀ
1.1. Tầm quan trọng của các yêu cầu phần mềm
Các yêu cầu phần mềm là rất quan trọng với mọi dự án phần mềm. Các dự án
thành công hay thất bại có nguyên nhân là do chất lượng của các yêu cầu. Các yêu
cầu này cấu thành phạm vi của tất cả các công việc sau đó cho nhóm phát triển dự án.
Không có các yêu cầu tốt, các dự án sẽ thất bại, bị chậm trễ, tốn kém, hay làm ra các
hệ thống không bao giờ được sử dụng.
Các vấn đề yêu cầu nên được cố định sớm, trước khi vào giai đoạn thiết kế, bởi
vì các vấn đề là do các yêu cầu kém có khuynh hướng gắn chặt vào trong thiết kế và
khó để cho việc sửa chữa sau này. Những người phát triển và người dùng có một cách
nhìn khác nhau từ những yêu cầu khi người phát triển xem xét yêu cầu từ quan điểm
làm thế nào để thực hiện còn người dùng chỉ cảm nhận vấn đề là sử dụng nó như thế
nào. Cách an toàn nhất để bảo đảm rằng nhu cầu của người dùng đã được đáp ứng
những gì đã được đưa ra, ta nên làm hai tài liệu song song, những gì người dùng cần,
và những gì một hệ thống sẽ phải làm để đáp ứng nhu cầu đó. Đây là các yêu cầu
người dùng và các đặc tả hệ thống theo thứ tự định sẵn.
Vậy tại sao cần có các yêu cầu phần mềm tốt? Bất kỳ lỗi nào được phát hiện
trong giai đoạn đầu trong quá trình phát triển dự án phần mềm là kết quả rất quan
trọng. Nếu ở các giai đoạn sau lỗi mới được phát hiện ra thì chi phí cho việc sửa chữa
hệ thống phần mềm sẽ tốn kém hơn rất nhiều. Nếu những người thiết kế hệ thống
hướng tới mục tiêu không đúng, việc thực thi hệ thống sẽ đi chệch với mong muốn ban
đầu. Một yêu cầu sai có thể tạo ra hàng loạt các lỗi thiết kế. Vì vậy để một sản phẩm
phần mềm tốt thì điều đầu tiên quan trọng là chúng ta phải có các yêu cầu tốt.
1.2. Khái niệm về Test case
Trong quá trình phát triển dự án phầm mềm, thông thường một quy trình kiểm
thử có các bước cơ bản như sau: lập kế hoạch, thiết kế Test, phát triển test script, thực
hiện test và đánh giá (xem Hình 1)
Hình 1: Một quy trình kiểm tra cơ bản.
Lập kế
hoạch
Thiết kế
Test
Phát triển
Test Script
Đánh giá
Thực hiện Test-7-
Trong đó Test case được viết trong bước thiết kế test. Mục đích của thiết kế test
là viết và chỉ định các Test case trong các bước kiểm tra chi tiết cho mỗi phiên bản
phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình
huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra.
Vì vậy công việc tạo ra các Test case hiệu quả là đặc biệt quan trọng để đảm
bảo chất lượng phần mềm. Để làm được việc đó, trước hết phải hiểu Test case là gì?
Một Test case có thể coi là một tình huống kiểm thử, được thiết kế để kiểm thử một
đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test case thường bao gồm 3
phần cơ bản:
• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm thử.
• Đầu vào: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để
thực hiện việc kiểm thử.
• Kết quả mong muốn: kết quả trả về từ đối tượng kiểm thử, chứng tỏ đối tượng
đã thỏa mãn yêu cầu.
Test case có một ý nghĩa vô cùng quan trọng, mục đích đưa ra các trường hợp
test nhằm phát hiện ra các lỗi nhiều nhất có thể, để cho các dự án phát triển phần mềm
có chất lượng tốt hơn.
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm .
Trong quá trình phát triển dự án phần mềm, thường công việc tạo ra các Test
case từ yêu cầu người dùng do các Tester phụ trách. Nhưng không phải Tester nào viết
các tài liệu Test case này cũng như nhau.Vì vậy trong các công ty phần mềm cũng như
các tổ chức thực hiện dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tài
liệu Test case tốt, có hiệu quả thì chất lượng phần mềm sẽ tốt hơn những dự án có các
Test case tồi (có nhiều trường hợp test trùng lặp nhau hay thiếu các trường hợp test).
Vậy chúng ta phải chuẩn hóa và đồng bộ hóa để làm sao tạo ra Test case một cách hiệu
quả và có chuẩn về chất lượng. Để làm điều này, chúng ta phải nghiên cứu các phương
pháp và kỹ thuật để tự động tạo ra các Test case. Việc tạo ra Test case một cách tự
động cũng làm giảm bớt công sức và thời gian của các tester, giúp giảm bớt chi phí
phát triển phần mềm.
Qúa trình tạo ra các Test case sẽ giúp các tester phát hiện ra các vấn đề mâu
thuẫn hay chưa rõ ràng của các 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 khi phát triển các dự
án phần mềm.
Vậy việc nghiên cứu các phương pháp và công cụ sinh Test case một cách tự
động từ yêu cầu người dùng rất hữu ích và cần thiết trong quá trình phát triển các dự
án phần mềm. Quá trình này nhằm mục đích tạo ra Test case một cách có hiệu quả, có
chất lượng. Giúp giảm bớt công sức và thời gian của các tester, làm giảm bớt chi phí
phát triển phần mềm và chất lượng phần mềm được nâng cao hơn.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-8-
CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH
SINH TEST CASE TỰ ĐỘNG
2.1. Giới thiệu
Việc test phần mềm là một công việc rất quan trọng trong vòng đời phát triển
của phần mềm. Để cắt giảm chi phí của việc test bằng tay và tăng độ tin cậy của phần
mềm thì chúng ta đang cố gắng thực hiện tự động hóa nó. Một trong những công việc
quan trọng trong môi trường test là tạo ra Test case một cách tự động mô tả về cách
thức test, mỗi một hệ thống phần mềm nhất định được thiết lập theo một cách thức độc
lập. Chương này trình bày cách nhìn tổng quan về kỹ thuật tạo Test case một cách tự
động.
Các tổ chức phần mềm sử dụng một phần ngân sách đáng kể của mình để thực
hiện các công việc liên quan đến giai đoạn test. Một hệ thống phần mềm test tốt sẽ
được kiểm chứng bởi khách hàng trước khi chấp nhận, làm thỏa mãn yêu cầu của
khách hàng. Tính hiệu quả của qúa trình xác nhận và kiểm chứng này phụ thuộc vào số
lượng lỗi được phát hiện và chỉnh sửa trước khi công bố hệ thống. Điều này lần lượt
phụ thuộc vào chất lượng của các Test case được tạo ra.
Các phương pháp khác nhau về việc sinh ra Test case đã được đề xuất. Một
Test case là một sự miêu tả cách thức test, mỗi một hệ thống phần mềm nhất định
được thiết lập theo một cách thức độc lập. Test case có thể được viết ra trực tiếp từ yêu
cầu người dùng, từ các yêu cầu hệ thống, hay từ các use case. Một trong những lợi
ích của việc tạo ra Test case từ các đặc tả và thiết kế đó là chúng có thể được sinh ra
sớm hơn trong vòng đời phát triển và sẵn sàng để sử dụng trước khi các chương trình
được tạo ra. Thêm vào đó, khi các Test case được sinh ra ban đầu các kỹ sư phần mềm
phát hiện ra sự không nhất quán và mập mờ trong đặc tả các yêu cầu và các tài liệu
thiết kế. Điều này sẽ chắc chắn sẽ làm giảm chi phí của việc xây dựng hệ thống phần
mềm khi các lỗi được loại bỏ sớm trong vòng đời phát triển của sản phẩm.
2.2. Tổng quan về các phương pháp sinh Test case
Một vài cách tiếp cận được đưa ra trong việc tạo ra Test case, một số mang tính
ngẫu nhiên, có mục đích, định hướng và một số rất thông minh. Kỹ thuật ngẫu nhiên
xác định các Test case dựa trên các giả định. Kỹ thuật định hướng đường dẫn sử dụng
các luồng thông tin kiểm soát để xác định một tập hợp các đường dẫn để được bao
quát và tạo ra các Test case phù hợp cho các đường dẫn này. Những kỹ thuật này có
thể được phân chia thành tĩnh và động. Kỹ thuật tĩnh thường được dựa trên thực thi
các ký hiệu mô tả, ngược lại các kỹ thuật động đạt được từ các dữ liệu cần thiết bằng
việc chạy chương trình trong khi test. Kỹ thuật định hướng mục tiêu xác định các Test
case bao gồm một mục tiêu đã được lựa chọn chẳng hạn một câu lệnh hay nhánh câu-9-
lệnh. Các kỹ thuật thông minh của các Test case được sinh ra tự động lệ thuộc vào các
tính toán phức tạp để xác định Test case.
Rất nhiều nghiên cứu về việc sinh ra các Test case tối ưu dựa trên các đặc tả,
tuy nhiên không thể đạt 100% các Test case tối ưu. Ngôn ngữ mô hình được sử dụng
để có được đặc tả và sinh ra các Test case. Kể từ khi UML (Unified Modeling
Language) là ngôn ngữ được sử dụng rộng rãi nhất thì nhiều nghiên cứu sử dụng lược
đồ UML như state-chart diagrams, use-case diagrams, sequence diagrams,… để sinh
ra các Test case và dẫn đến việc sinh ra Test case dựa trên mô hình.
2.2.1. Sinh Test case dựa trên đặc tả
Sinh Test case dựa trên đặc tả là phương pháp sinh Test case mà phỏng theo trạng
thái được xác định trước dựa trên đặc tả để tạo ra Test case từ biểu đồ trạng thái UML.
Việc kiểm thử đủ các thuộc tính, các cặp chuyển tiếp và chỉnh sửa các câu lệnh là các
kỹ thuật được đưa ra trong Chương 3. Các kỹ thuật đã sử dụng các biểu đồ trạng thái
UML như một cở sở và tự động sinh ra các bộ phận điều khiển test và test script để
xác nhận các thành phần khi test. Cách tiếp cận trong một mẫu, chỉ ra các lớp và đặc tả
biểu đồ trạng thái tương ứng cho hành vi của lớp đó, định rõ ánh xạ đưa ra bằng sự kết
hợp các mã với đặc tả. Sau đó tester chọn các tiêu chuẩn để chỉnh sửa. Tóm lại, các lỗi
được phát hiện ra như sự không nhất quán giữa hành vi và đặc tả biểu đồ trạng thái
được đưa ra bởi người sử dụng. Mục tiêu là để xác định các đặc tả được cải tiến được
dựa trên các tiêu chuẩn chỉnh sửa thích hợp cho hệ thống và để phát triển các kỹ thuật
cho việc tạo ra bộ điều khiển test với ít nhất thao tác của con người.
2.2.2. Sinh Test case dựa trên mô hình
UML đã nhận được một sự quan tâm lớn từ các công đồng phát triển và thiết kế
phần mềm, và các công việc đang được thực hiện để tăng cường và mở rộng các tính
năng của nó. Tuy nhiên, cộng đồng test phần mềm đã không quan tâm nhiều và thảo
luận nhiều về UML, sự thiếu hụt lớn khi tiêu chuẩn mô hình hóa được phát triển. Đây
là vấn đề cần quan tâm, bởi vì trong các tổ chức phát triển phần mềm, chi phí của việc
test có thể chiếm hơn 40% tổng chi phí phát triển cho một hệ thống phần mềm. Đưa ra
các thực tế này để phát hiện ra khả năng sử dụng UML cho việc test phần mềm.
Đa phần công việc test dựa trên mô hình của các hệ thống tập trung vào việc sử
dụng của các biểu đồ trạng thái hay lớp.Các biểu đồ lớp chỉ một tập các lớp, các giao
diện và các sự cộng tác, các mối quan hệ của chúng. Các biểu đồ trạng thái biểu diễn
dòng điều khiển từ trạng thái này đến trạng thái khác, nó nhấn mạnh dòng điều khiển
từ hoạt động này đến hoạt động khác xảy ra bên trong một máy trạng thái. UML có
một phương pháp mô hình trước đó được biết đến là kỹ thuật mô hình đối tượng
(Object Modeling Technique) mà đã thêm một số mô hình chức năng cũng được sử
dụng cho quá trình test.
mức độ cao nhất. Biểu đồ mức độ cao nhất này tương tự một framework trong đó use
case có thể được thực hiện phụ thuộc vào những điều kiện đầu tiên của chúng, và trong
đó có thêm các trạng thái cách sử dụng toàn bộ, được ngoại suy từ các điều kiện ban
đầu của tất cả các use case, có thể được chuyển đổi giữa chúng, thêm nữa bằng các
công cụ của use case. Một biểu đồ trạng thái mức độ cao hay một trật tự như vậy, với
các hệ thống phức tạp hơn) là được xây dựng bằng cách tôn trọng triệt để các hướng
dẫn sau:
Từ tất cả các điều kiện ban đầu và cao hơn của tất cả các use case, các trạng
thái toàn thể của cách sử dụng là được ngoại suy. Trong ngữ cảnh đó, “các trạng thái
của cách sử dụng” tham chiếu tới sự liên hệ của hệ thống người sử dụng. Ví dụ, trong
một ứng dụng dựa trên GUI tương tác, những trạng thái như vậy mô tả các thực đơn
khác nhau.
Các biều đồ trạng thái của use case xuất hiện như những người có địa vị, có
nghĩa là chỉ đường viền trạng thái của chúng và tên được đưa vào cùng, tham chiếu tới
biểu đồ trạng thái thực tế. Bên trong chúng, các bộ nối biểu đồ phù hợp với các điều
kiện cao hơn được lấy ra. Một bộ nối biểu đồ là một sự tham khảo biểu trưng tới một
sự xuất hiện khác của cùng biểu tượng trong một biểu đồ khác, cho phép các kết nối
này trong số các biểu đồ tách biệt. Cơ chế này là một sự mở rộng của các biểu đồ trạng
thái UML. Các bộ nối cho phép các biểu đồ trạng thái tách biệt của mỗi use case hơn
một biểu đồ phức tạp và giúp ích cho việc sửa lại/sử dụng lại (cải thiện tính dễ hiểu và
tránh các lỗi). Sự đa dạng và sự mở rộng của các use case đưa thêm các điều kiện cao
hơn trong các biểu đồ trạng thái được cải tiến thường xuyên cung cấp thêm các bộ nối
biểu đồ.
Các trạng thái quan trọng của mỗi use case nhận các chuyển tiếp hồi lại từ
tất cả các trạng thái toàn bộ mô tả các điều kiện ban đầu của use case trong tiều đề cập
đến. Sự khởi động của mỗi chuyển tiếp là bước đầu tiên của kịch bản thành công chính
(ví dụ, các tác nhân kích thích khởi động sự thực hiện của use case). Nếu có đa tác
nhân kích thích khởi động, một sự chuyển tiếp tách biệt cần được đưa vào cho mỗi tác
nhân kích thích.
Các bộ nối biểu đồ bên trong các trạng thái quan trọng (place-holding) của
các use case là được kết nối tới các trạng thái hệ thống toàn bộ tương ứng với điều
kiện cao hơn được tương đồng bởi bộ nối biểu đồ trong điều được đề cập đến. Những
chuyển tiếp này được chuyển tiếp tự động (và sẽ khó tránh khỏi sự chuyển tiếp ở giai
đoạn sau).
Các chuyển tiếp đầu tiên và kết thúc được thêm vào, mô tả sự kích hoạt và
kết thúc của phần mềm, tương ứng.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
Nhà xuất bản: ĐHCN
Ngày: 2008
Chủ đề: Công nghệ phần mềm
Kỹ thuật sinh test case
Phần mềm
Tin học
Miêu tả: 68 tr. + CD-ROM
Đưa ra các vấn đề cần thiết và cấp bách trong việc nghiên cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu người dùng. Giới thiệu tổng quan về quá trình sinh test case tự động và các phương pháp sinh Test case: Sinh Test case dựa trên đặc tả, sinh test case dựa trên mô hình, sinh test case hướng đường dẫn. Trình bày các phương pháp và kỹ thuật sinh Test case tự động hiện có, từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ưu điểm của nó so với các kỹ thuật trước. Phát triển chương trình ứng dụng quá trình sinh Test case tự động
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công Nghệ. Đại học Quốc gia Hà Nội, 2008
MỤC LỤC
CHƢƠNG 1. ĐẶT VẤN ĐỀ ................................................................................ 6
1.1. Tầm quan trọng của các yêu cầu phần mềm .................................................6
1.2. Khái niệm về Test case..................................................................................6
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm . ........................................7
CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH ................................................... 8
SINH TEST CASE TỰ ĐỘNG................................................................................ 8
2.1. Giới thiệu.......................................................................................................8
2.2. Tổng quan về các phƣơng pháp sinh Test case .............................................8
2.2.1. Sinh Test case dựa trên đặc tả .......................................................................9
2.2.2. Sinh Test case dựa trên mô hình....................................................................9
2.2.3. Sinh Test case hƣớng đƣờng dẫn.................................................................10
2.3. Kiểm thử phần mềm và UML .....................................................................10
CHƢƠNG 3. CÁC KỸ THUẬT VÀ PHƢƠNG PHÁP SINH .......................... 11
TEST CASE TỰ ĐỘNG ........................................................................................ 11
3.1. Giới thiệu.....................................................................................................11
3.2. Kỹ thuật sinh Test case dựa trên đặc tả .......................................................12
3.2.1. Các phƣơng thức đặc tả trạng thái SCR ......................................................13
3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tả của SCR ...................................14
3.2.3. Kỹ thuật tạo Test case cho đặc tả UML ......................................................21
3.2.4. Các thuận toán sinh Test case dựa trên đặc tả.............................................28
3.3. Kỹ thuật sinh Test case dựa trên mô hình ...................................................36
3.3.1. Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UML .................37
3.3.2. Tạo Test case dựa trên Use case cải tiến .....................................................45
CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG......................... 57
QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG....................................................... 57
4.1. Mục tiêu.......................................................................................................57
4.2. Tóm tắt quá trình sinh Test case tự động ....................................................57
4.2.1. Ví dụ ............................................................................................................57
4.2.2. Các Test case của ví dụ ...............................................................................60
4.2.3. Tính ứng dụng, các ƣu điểm và nhƣợc điểm...............................................60
4.2.4. Kết luận .......................................................................................................61
4.3. Cài đặt..........................................................................................................62
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-2-
DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT
Từ và cụm từ viết tắt Viết đầy đủ
UML Unified Modeling Language
OCD Object Collaboration Diagram
SCR Software Cost Reducation
Test Sự kiểm thử
Tester Kiểm thử viên-3-
DANH MỤC CÁC HÌNH VẼ
Stt Tên hình vẽ
1 Một quy trình kiểm tra cơ bản.
2 Kiểm thử dựa trên đặc tả
3 Kiểm thử dựa trên chương trình
4 Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp
5 Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR
6 Sự kiện gọi (call events)
7 Sự kiện báo hiệu (signal events)
8 Sự kiện thời gian (time Events)
9 Sự kiện thay đổi (Change Events)
10 Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML
11 Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái.
12 Biểu đồ lớp của mô hình thiết kề
13 OCD cho việc sinh ra các Test case chỉnh sửa đầy đủ các thuộc tính
14 OCD cho việc sinh ra các Test case chỉnh sửa chuyển tiếp
15 OCD cho việc sinh ra các Test case chỉnh sửa cặp chuyển tiếp.
16 Thuật toán phân tích đặc tả SCR
17 Thuật toán phân tách đặc tả UML
18 Biểu đồ cộng tác mức độ đặc tả
19 Biểu đồ cộng tác cho một thao tác
20 Các cặp cộng tác
21 Một đường chuỗi thông điệp
22 Thuật toán instrumentation
23 Mô hình hóa các vùng trong thiết kế phần mềm
24
Các hoạt động của cách tiếp cận được đề xuất bên trong quá trình
phát triển phần mềm.
25 Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3.
26 Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3
27 Mô hình cách sử dụng có thể cho ví dụ thư viện của bảng 3.
28 Mô hình hành vi
29 Các lược đồ test và các giá trị test
30 Test case cho kịch bản chính
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-4-
DANH MỤC CÁC BẢNG BIỂU
Stt Tên bảng biểu
1 Phân biệt các biểu đồ UML và các mức độ test
2 Mẫu cải tiến các use case
3 Một ví dụ về mẫu chi tiết các use case-5-
MỞ ĐẦU
Mặc dù việc nghiên cứu về các phương pháp và kỹ thuật sinh Test case tự động
từ yêu cầu người dùng đã được quan tâm nhiều trên thế giới, nhưng ở Việt Nam các
nghiên cứu và ứng dụng chỉ mới ở bước đầu. Thực vậy, công việc sinh Test case tự
động từ yêu cầu người dùng một cách có hiệu quả trong quá trình kiểm thử là vấn đề
cần thiết và bức xúc của các công ty sản xuất phần mềm cũng như các tổ chức thực
hiện phát triển dự án phần mềm.
Trong quá trình phát triển dự án phần mềm, thường công việc tạo ra các Test
case từ yêu cầu người dùng do các Tester phụ trách. Nhưng không phải Tester nào viết
các tài liệu Test case này cũng như nhau. Vì vậy trong các công ty phần mềm cũng
như các tổ chức thực hiện phát triển các dự án phần mềm sẽ phát sinh một vấn đề là:
Tester nào viết tài liệu Test case tốt, có hiệu quả thì chất lượng phần mềm sẽ tốt hơn
những dự án có Test case tồi. Vậy tại sao chúng ta không đồng nhất hóa công việc viết
Test case bằng các phương pháp và kỹ thuật tự động nhằm giảm bớt công sức và thời
gian của các tester, làm cho chất lượng của Test case tốt hơn.
Có các hướng tiếp cận khác nhau trong việc sinh Test case tự động: thứ nhất là
có thể sinh Test case tự động dựa trên đặc tả từ một file input đã được định sẵn; thứ
hai là sinh Test case tự động dựa trên code, chương trình có sẵn; thứ ba là sinh Test
case tự động dựa trên các mô hình UML. Trong ba hướng tiếp cận trên chúng tui chọn
hướng tiếp cận thứ ba và nghiên cứu các phương pháp theo hướng tiếp cận này.
Trong đề tài luận văn này chúng tui nghiên cứu các vấn đề về tạo Test case tự
động từ yêu cầu người dùng. Sau đó, chúng tui xem xét các phương pháp và kỹ thuật
hiện có trong việc tạo Test case tự động để từ đó có thể đưa ra những cải tiến bổ sung
và phát triển. Cuối cùng là xây dựng một công cụ sinh Test case tự động có thể áp
dụng trong thực tế.
Bố cục của luận văn gồm phần mở đầu, phần kết luận và 4 chương nội dung
như sau:
Chƣơng 1: Đặt vấn đề, đưa ra các vấn đề cần thiết và cấp bách trong việc
nghiên cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu người dùng.
Chƣơng 2: Giới thiệu tổng quan về sinh Test case tự động. Trên cơ sở đó chọn
hướng tiếp cận sẽ đi sâu vào nghiên cứu ở Chương 3.
Chƣơng 3: Trình bày các phương pháp và kỹ thuật sinh Test case tự động hiện
có. Từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ưu điểm của nó so
với các kỹ thuật trước.
Chƣơng 4: Trình bày quá trình sinh Test case hiệu quả dựa trên kỹ thuật được
đề xuất. Đồng thời xây dựng chương trình demo quá trình sinh Test case tự động.
Sau khi nghiên cứu và thử nghiệm, trong phần Kết luận có nêu một số tổng kết và
nhận xét về việc sinh Test case tự động, đồng thời đề ra hướng nghiên cứu tiếp theo.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-6-
CHƢƠNG 1. ĐẶT VẤN ĐỀ
1.1. Tầm quan trọng của các yêu cầu phần mềm
Các yêu cầu phần mềm là rất quan trọng với mọi dự án phần mềm. Các dự án
thành công hay thất bại có nguyên nhân là do chất lượng của các yêu cầu. Các yêu
cầu này cấu thành phạm vi của tất cả các công việc sau đó cho nhóm phát triển dự án.
Không có các yêu cầu tốt, các dự án sẽ thất bại, bị chậm trễ, tốn kém, hay làm ra các
hệ thống không bao giờ được sử dụng.
Các vấn đề yêu cầu nên được cố định sớm, trước khi vào giai đoạn thiết kế, bởi
vì các vấn đề là do các yêu cầu kém có khuynh hướng gắn chặt vào trong thiết kế và
khó để cho việc sửa chữa sau này. Những người phát triển và người dùng có một cách
nhìn khác nhau từ những yêu cầu khi người phát triển xem xét yêu cầu từ quan điểm
làm thế nào để thực hiện còn người dùng chỉ cảm nhận vấn đề là sử dụng nó như thế
nào. Cách an toàn nhất để bảo đảm rằng nhu cầu của người dùng đã được đáp ứng
những gì đã được đưa ra, ta nên làm hai tài liệu song song, những gì người dùng cần,
và những gì một hệ thống sẽ phải làm để đáp ứng nhu cầu đó. Đây là các yêu cầu
người dùng và các đặc tả hệ thống theo thứ tự định sẵn.
Vậy tại sao cần có các yêu cầu phần mềm tốt? Bất kỳ lỗi nào được phát hiện
trong giai đoạn đầu trong quá trình phát triển dự án phần mềm là kết quả rất quan
trọng. Nếu ở các giai đoạn sau lỗi mới được phát hiện ra thì chi phí cho việc sửa chữa
hệ thống phần mềm sẽ tốn kém hơn rất nhiều. Nếu những người thiết kế hệ thống
hướng tới mục tiêu không đúng, việc thực thi hệ thống sẽ đi chệch với mong muốn ban
đầu. Một yêu cầu sai có thể tạo ra hàng loạt các lỗi thiết kế. Vì vậy để một sản phẩm
phần mềm tốt thì điều đầu tiên quan trọng là chúng ta phải có các yêu cầu tốt.
1.2. Khái niệm về Test case
Trong quá trình phát triển dự án phầm mềm, thông thường một quy trình kiểm
thử có các bước cơ bản như sau: lập kế hoạch, thiết kế Test, phát triển test script, thực
hiện test và đánh giá (xem Hình 1)
Hình 1: Một quy trình kiểm tra cơ bản.
Lập kế
hoạch
Thiết kế
Test
Phát triển
Test Script
Đánh giá
Thực hiện Test-7-
Trong đó Test case được viết trong bước thiết kế test. Mục đích của thiết kế test
là viết và chỉ định các Test case trong các bước kiểm tra chi tiết cho mỗi phiên bản
phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình
huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra.
Vì vậy công việc tạo ra các Test case hiệu quả là đặc biệt quan trọng để đảm
bảo chất lượng phần mềm. Để làm được việc đó, trước hết phải hiểu Test case là gì?
Một Test case có thể coi là một tình huống kiểm thử, được thiết kế để kiểm thử một
đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test case thường bao gồm 3
phần cơ bản:
• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm thử.
• Đầu vào: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để
thực hiện việc kiểm thử.
• Kết quả mong muốn: kết quả trả về từ đối tượng kiểm thử, chứng tỏ đối tượng
đã thỏa mãn yêu cầu.
Test case có một ý nghĩa vô cùng quan trọng, mục đích đưa ra các trường hợp
test nhằm phát hiện ra các lỗi nhiều nhất có thể, để cho các dự án phát triển phần mềm
có chất lượng tốt hơn.
1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm .
Trong quá trình phát triển dự án phần mềm, thường công việc tạo ra các Test
case từ yêu cầu người dùng do các Tester phụ trách. Nhưng không phải Tester nào viết
các tài liệu Test case này cũng như nhau.Vì vậy trong các công ty phần mềm cũng như
các tổ chức thực hiện dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tài
liệu Test case tốt, có hiệu quả thì chất lượng phần mềm sẽ tốt hơn những dự án có các
Test case tồi (có nhiều trường hợp test trùng lặp nhau hay thiếu các trường hợp test).
Vậy chúng ta phải chuẩn hóa và đồng bộ hóa để làm sao tạo ra Test case một cách hiệu
quả và có chuẩn về chất lượng. Để làm điều này, chúng ta phải nghiên cứu các phương
pháp và kỹ thuật để tự động tạo ra các Test case. Việc tạo ra Test case một cách tự
động cũng làm giảm bớt công sức và thời gian của các tester, giúp giảm bớt chi phí
phát triển phần mềm.
Qúa trình tạo ra các Test case sẽ giúp các tester phát hiện ra các vấn đề mâu
thuẫn hay chưa rõ ràng của các 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 khi phát triển các dự
án phần mềm.
Vậy việc nghiên cứu các phương pháp và công cụ sinh Test case một cách tự
động từ yêu cầu người dùng rất hữu ích và cần thiết trong quá trình phát triển các dự
án phần mềm. Quá trình này nhằm mục đích tạo ra Test case một cách có hiệu quả, có
chất lượng. Giúp giảm bớt công sức và thời gian của các tester, làm giảm bớt chi phí
phát triển phần mềm và chất lượng phần mềm được nâng cao hơn.
Ket-noi.com kho tai lieu mien phi Ket-noi.com kho tai lieu mien phi-8-
CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH
SINH TEST CASE TỰ ĐỘNG
2.1. Giới thiệu
Việc test phần mềm là một công việc rất quan trọng trong vòng đời phát triển
của phần mềm. Để cắt giảm chi phí của việc test bằng tay và tăng độ tin cậy của phần
mềm thì chúng ta đang cố gắng thực hiện tự động hóa nó. Một trong những công việc
quan trọng trong môi trường test là tạo ra Test case một cách tự động mô tả về cách
thức test, mỗi một hệ thống phần mềm nhất định được thiết lập theo một cách thức độc
lập. Chương này trình bày cách nhìn tổng quan về kỹ thuật tạo Test case một cách tự
động.
Các tổ chức phần mềm sử dụng một phần ngân sách đáng kể của mình để thực
hiện các công việc liên quan đến giai đoạn test. Một hệ thống phần mềm test tốt sẽ
được kiểm chứng bởi khách hàng trước khi chấp nhận, làm thỏa mãn yêu cầu của
khách hàng. Tính hiệu quả của qúa trình xác nhận và kiểm chứng này phụ thuộc vào số
lượng lỗi được phát hiện và chỉnh sửa trước khi công bố hệ thống. Điều này lần lượt
phụ thuộc vào chất lượng của các Test case được tạo ra.
Các phương pháp khác nhau về việc sinh ra Test case đã được đề xuất. Một
Test case là một sự miêu tả cách thức test, mỗi một hệ thống phần mềm nhất định
được thiết lập theo một cách thức độc lập. Test case có thể được viết ra trực tiếp từ yêu
cầu người dùng, từ các yêu cầu hệ thống, hay từ các use case. Một trong những lợi
ích của việc tạo ra Test case từ các đặc tả và thiết kế đó là chúng có thể được sinh ra
sớm hơn trong vòng đời phát triển và sẵn sàng để sử dụng trước khi các chương trình
được tạo ra. Thêm vào đó, khi các Test case được sinh ra ban đầu các kỹ sư phần mềm
phát hiện ra sự không nhất quán và mập mờ trong đặc tả các yêu cầu và các tài liệu
thiết kế. Điều này sẽ chắc chắn sẽ làm giảm chi phí của việc xây dựng hệ thống phần
mềm khi các lỗi được loại bỏ sớm trong vòng đời phát triển của sản phẩm.
2.2. Tổng quan về các phương pháp sinh Test case
Một vài cách tiếp cận được đưa ra trong việc tạo ra Test case, một số mang tính
ngẫu nhiên, có mục đích, định hướng và một số rất thông minh. Kỹ thuật ngẫu nhiên
xác định các Test case dựa trên các giả định. Kỹ thuật định hướng đường dẫn sử dụng
các luồng thông tin kiểm soát để xác định một tập hợp các đường dẫn để được bao
quát và tạo ra các Test case phù hợp cho các đường dẫn này. Những kỹ thuật này có
thể được phân chia thành tĩnh và động. Kỹ thuật tĩnh thường được dựa trên thực thi
các ký hiệu mô tả, ngược lại các kỹ thuật động đạt được từ các dữ liệu cần thiết bằng
việc chạy chương trình trong khi test. Kỹ thuật định hướng mục tiêu xác định các Test
case bao gồm một mục tiêu đã được lựa chọn chẳng hạn một câu lệnh hay nhánh câu-9-
lệnh. Các kỹ thuật thông minh của các Test case được sinh ra tự động lệ thuộc vào các
tính toán phức tạp để xác định Test case.
Rất nhiều nghiên cứu về việc sinh ra các Test case tối ưu dựa trên các đặc tả,
tuy nhiên không thể đạt 100% các Test case tối ưu. Ngôn ngữ mô hình được sử dụng
để có được đặc tả và sinh ra các Test case. Kể từ khi UML (Unified Modeling
Language) là ngôn ngữ được sử dụng rộng rãi nhất thì nhiều nghiên cứu sử dụng lược
đồ UML như state-chart diagrams, use-case diagrams, sequence diagrams,… để sinh
ra các Test case và dẫn đến việc sinh ra Test case dựa trên mô hình.
2.2.1. Sinh Test case dựa trên đặc tả
Sinh Test case dựa trên đặc tả là phương pháp sinh Test case mà phỏng theo trạng
thái được xác định trước dựa trên đặc tả để tạo ra Test case từ biểu đồ trạng thái UML.
Việc kiểm thử đủ các thuộc tính, các cặp chuyển tiếp và chỉnh sửa các câu lệnh là các
kỹ thuật được đưa ra trong Chương 3. Các kỹ thuật đã sử dụng các biểu đồ trạng thái
UML như một cở sở và tự động sinh ra các bộ phận điều khiển test và test script để
xác nhận các thành phần khi test. Cách tiếp cận trong một mẫu, chỉ ra các lớp và đặc tả
biểu đồ trạng thái tương ứng cho hành vi của lớp đó, định rõ ánh xạ đưa ra bằng sự kết
hợp các mã với đặc tả. Sau đó tester chọn các tiêu chuẩn để chỉnh sửa. Tóm lại, các lỗi
được phát hiện ra như sự không nhất quán giữa hành vi và đặc tả biểu đồ trạng thái
được đưa ra bởi người sử dụng. Mục tiêu là để xác định các đặc tả được cải tiến được
dựa trên các tiêu chuẩn chỉnh sửa thích hợp cho hệ thống và để phát triển các kỹ thuật
cho việc tạo ra bộ điều khiển test với ít nhất thao tác của con người.
2.2.2. Sinh Test case dựa trên mô hình
UML đã nhận được một sự quan tâm lớn từ các công đồng phát triển và thiết kế
phần mềm, và các công việc đang được thực hiện để tăng cường và mở rộng các tính
năng của nó. Tuy nhiên, cộng đồng test phần mềm đã không quan tâm nhiều và thảo
luận nhiều về UML, sự thiếu hụt lớn khi tiêu chuẩn mô hình hóa được phát triển. Đây
là vấn đề cần quan tâm, bởi vì trong các tổ chức phát triển phần mềm, chi phí của việc
test có thể chiếm hơn 40% tổng chi phí phát triển cho một hệ thống phần mềm. Đưa ra
các thực tế này để phát hiện ra khả năng sử dụng UML cho việc test phần mềm.
Đa phần công việc test dựa trên mô hình của các hệ thống tập trung vào việc sử
dụng của các biểu đồ trạng thái hay lớp.Các biểu đồ lớp chỉ một tập các lớp, các giao
diện và các sự cộng tác, các mối quan hệ của chúng. Các biểu đồ trạng thái biểu diễn
dòng điều khiển từ trạng thái này đến trạng thái khác, nó nhấn mạnh dòng điều khiển
từ hoạt động này đến hoạt động khác xảy ra bên trong một máy trạng thái. UML có
một phương pháp mô hình trước đó được biết đến là kỹ thuật mô hình đối tượng
(Object Modeling Technique) mà đã thêm một số mô hình chức năng cũng được sử
dụng cho quá trình test.
mức độ cao nhất. Biểu đồ mức độ cao nhất này tương tự một framework trong đó use
case có thể được thực hiện phụ thuộc vào những điều kiện đầu tiên của chúng, và trong
đó có thêm các trạng thái cách sử dụng toàn bộ, được ngoại suy từ các điều kiện ban
đầu của tất cả các use case, có thể được chuyển đổi giữa chúng, thêm nữa bằng các
công cụ của use case. Một biểu đồ trạng thái mức độ cao hay một trật tự như vậy, với
các hệ thống phức tạp hơn) là được xây dựng bằng cách tôn trọng triệt để các hướng
dẫn sau:
Từ tất cả các điều kiện ban đầu và cao hơn của tất cả các use case, các trạng
thái toàn thể của cách sử dụng là được ngoại suy. Trong ngữ cảnh đó, “các trạng thái
của cách sử dụng” tham chiếu tới sự liên hệ của hệ thống người sử dụng. Ví dụ, trong
một ứng dụng dựa trên GUI tương tác, những trạng thái như vậy mô tả các thực đơn
khác nhau.
Các biều đồ trạng thái của use case xuất hiện như những người có địa vị, có
nghĩa là chỉ đường viền trạng thái của chúng và tên được đưa vào cùng, tham chiếu tới
biểu đồ trạng thái thực tế. Bên trong chúng, các bộ nối biểu đồ phù hợp với các điều
kiện cao hơn được lấy ra. Một bộ nối biểu đồ là một sự tham khảo biểu trưng tới một
sự xuất hiện khác của cùng biểu tượng trong một biểu đồ khác, cho phép các kết nối
này trong số các biểu đồ tách biệt. Cơ chế này là một sự mở rộng của các biểu đồ trạng
thái UML. Các bộ nối cho phép các biểu đồ trạng thái tách biệt của mỗi use case hơn
một biểu đồ phức tạp và giúp ích cho việc sửa lại/sử dụng lại (cải thiện tính dễ hiểu và
tránh các lỗi). Sự đa dạng và sự mở rộng của các use case đưa thêm các điều kiện cao
hơn trong các biểu đồ trạng thái được cải tiến thường xuyên cung cấp thêm các bộ nối
biểu đồ.
Các trạng thái quan trọng của mỗi use case nhận các chuyển tiếp hồi lại từ
tất cả các trạng thái toàn bộ mô tả các điều kiện ban đầu của use case trong tiều đề cập
đến. Sự khởi động của mỗi chuyển tiếp là bước đầu tiên của kịch bản thành công chính
(ví dụ, các tác nhân kích thích khởi động sự thực hiện của use case). Nếu có đa tác
nhân kích thích khởi động, một sự chuyển tiếp tách biệt cần được đưa vào cho mỗi tác
nhân kích thích.
Các bộ nối biểu đồ bên trong các trạng thái quan trọng (place-holding) của
các use case là được kết nối tới các trạng thái hệ thống toàn bộ tương ứng với điều
kiện cao hơn được tương đồng bởi bộ nối biểu đồ trong điều được đề cập đến. Những
chuyển tiếp này được chuyển tiếp tự động (và sẽ khó tránh khỏi sự chuyển tiếp ở giai
đoạn sau).
Các chuyển tiếp đầu tiên và kết thúc được thêm vào, mô tả sự kích hoạt và
kết thúc của phần mềm, tương ứng.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
You must be registered for see links
Last edited by a moderator: