Các Test case là cần thiết để xác nhận sự bổ sung thành công của ứng dụng trong việc tham chiếu tới các yêu cầu xác định (use cases). Các Test case được tạo ra từ các use case được sử dụng cho việc kiểm thử sự xác nhận mà xem xét hệ thống như một hộp đen. Lấy được các Test case từ các mô hình là khá dễ hiểu bởi vì chúng ta đã có các kịch bản có thể thực hiện được trong đó người sử dụng có thể tương tác với ứng dụng. Các điều kiện trước và sau xác nhận tình trạng của hệ thống trước khi use case được bắt đầu và sau khi actor tương tác với hệ thống tương ứng. Tương tự như vậy cho một Test case các điều kiện trước có thể được sử dụng cho cùng một mục đích như trong các use case và các điều kiện sau có thể được sử dụng để xác định các tiêu chuẩn kiểm thử pass/fail.
4.2.3. Tính ứng dụng, các ưu điểm và nhược điểm
Kiểm thử dựa trên các use case là một phương pháp hiệu quả và phương pháp này có thể ứng dụng cho các ứng dụng phần mềm khác nhau. Cách này đưa ra khả năng tìm dấu vết rất tốt từ các yêu cầu gốc. Bằng cách gán tương ứng các Test case tới các kịch bản use case chúng ta có thể kiểm thử các yêu cầu phần mềm và xác định rằng phần mềm đã đáp ứng được các yêu cầu của nó. Chúng ta thấy rằng cách tiếp cận này là hiệu quả hơn và cho ra các kết quả tốt với những yêu cầu ban đầu của phần mềm. Trong ví dụ, các Test case được tạo ra từ use case là hiệu quả trong việc xác nhận các yêu cầu và trong việc phát hiện ra các khiếm khuyết trong phần mềm. Chúng
ta có thể phát hiện ra sự không nhất quán trong các yêu cầu và loại trừ các lỗi trong phần mềm như đã chỉ ra.
Những ưu điểm của phương pháp này là:
Sự kỹ lưỡng của mô hình use case để kiểm thử các yêu cầu.
Sinh ra các Test case hiệu quả và có được chất lượng của phần mềm tốt hơn.
Cung cấp cho người phát triển phần mềm và các tester thông tin về các thành phần có thể gây lỗi. Điều này có thể cải thiện được quá trình kiểm thử.
Mô hình hóa các Test case dựa trên Use Case, cho phép những tester kiểm soát việc kiểm thử phần mềm hiệu quả hơn.
Tuy nhiên, có một số hạn chế của phương pháp này. Use case được sử dụng chỉ để mô hình hóa các yêu cầu chức năng, chúng không được sử dụng để mô hình các yêu cầu phi chức năng chẳng hạn sự bảo mật, sự chịu tải của hệ thống, sự thực hiện của hệ thống… vì vậy là cần thiết để xác nhận các yêu cầu phi chức năng được tách riêng ra. Từ đó cũng đưa ra một hướng nghiên cứu tiếp có thể giám sát vào việc làm thế nào để cách thức các yêu cầu phi chức năng vào trong các use case và vẫn tạo ra các Test case hữu ích.
4.2.4. Kết luận
Phần này đưa ra một phương pháp về việc sử dụng các mô hình từ use cases, để có được các Test case hiệu quả. Phương pháp này giúp những người phát triển phần mềm và các tester sớm khởi đầu quá trình kiểm thử trong chu kỳ phát triển phần mềm. Bằng cách có được các Test case từ use cases, các tester sẽ đảm bảo rằng không chỉ các chức năng được yêu cầu của hệ thống được phát triển mà nó còn được gắn liền với kế hoạch test. Thêm vào đó, sử dụng các use case tới các các Test case được tạo ra ban đầu trong chu kỳ phát triển phần mềm cung cấp cho người phát triển phần mềm và tester một cơ chế để xác định các khiếm khuyết và sửa chúng ngay khi có thể. Phương pháp này có thể cho phép các Test case được tạo ra dựa trên use case và các kịch bản để cung cấp một đường cơ sở cho việc lập kế hoạch ban đầu của test và phát hiện ra lỗi nguồn gốc từ các yêu cầu ban đầu.
So sánh quá trình này so với những phương pháp hiện có:
Quá trình này liên quan đến các yêu cầu chức năng, các yêu cầu chức năng được diễn đạt với các use case, các use case được miêu tả trong ngôn ngữ tự nhiên cho nên tạo thuận lợi cho các tester hơn những phương pháp hiện có. Tuy nhiên, quá trình này chưa thật đầy đủ vì mục đích của quá trình tạo ra test case là để có được một vài test case kiểm tra tất cả các thông tin có trong các use case đã được bổ sung thành công vào trong hệ thống lúc test.
Quá trình được tạo ra dựa trên use case đã chứng tỏ là cơ chế hiệu quả để xác nhận các yêu cầu phần mềm. Thêm vào đó, chúng ta có thể phát hiện các lỗi ngay từ
các giai đoạn đầu trong chu kỳ phát triển phần mềm, tính năng bị thiếu và các lỗi phần mềm khi phần mềm được phát triển.
4.3. Cài đặt
Sử dụng chức năng Login với giao diện như sau, để tạo ra các Test case của chức năng này.
Hình 31: Chức năng Login Cách thực hiện trong chƣơng trình Generate Test case:
- Đầu tiên, chúng ta tạo các Cause (C) và các Effect (E) (là các hành động và kết quả của hành động trong một trường hợp test) bằng cách sử dụng menu hoặc các button trên thanh công cụ. Trong chức năng Login, trường hợp test đầu tiên (xem hình 32) là :
+ (C): Enter the Hostname + (C): Enter the Username + (C): Enter the PasswordOK + (C): Validate the information + (C): Hostname is online + (E): Enter Application
Hình 32: Tạo ra các hành động trong trƣờng hợp test thứ 1 của Test case trong chức năng Login
Tiếp tục tạo các (C) và (E) trong các trường hợp test tiếp theo. Xem Hình 33, chức năng Login có 9 trường hợp test.
Hình 34: Tạo ra các hành động tuần tự của một Test case bằng nhấn vào chuột phải để hiện thị menu trong chức năng Login
Hình 35: Hiển thị màn hình Test case sau khi click vào button [Generate Testcase]
+ Sử dụng chức năng Export trên menu để export ra file Test case của chức năng Login có nội dung như sau:
Test Enter System 1_3 (Cont.)
Test case-Login
Prepare by: daovt Creation date: 2008-08-30
Reviewed by: Version: Page 1/3
Test Case ID 1
Steps Description Expected Results
1
Enter a hostname in the field Hostname”, the Hostname is On- Line
Enter a Username in the field "Username" Enter a correct password in the field “Password” Click Ok button
The Hostname is On-Line
Test Case ID 2
Steps Description Expected Results
2
Enter a hostname in the field "Hostname”, the Hostname is Not On-Line
Enter a Username in the field "Username" Enter an correct password in the field “Password” Click Ok button
Error message: “The Hostname is Not On-Line”
Test Case ID 3
Steps Description Expected Results
3
Enter a hostname in the field "Hostname" Enter a Username in the field "Username" Enter a correct password in the field "Password" Click Cancell button
Exit the login window
Test Case ID 4
Steps Description Expected Results
4
Enter a hostname in the field "Hostname" Enter a Username in the field "Username"
Enter an incorrect password in the field "Password" Click Ok button
Error message : “Username or Password is incorrect”
Test Case ID 5
Steps Description Expected Results
5
Enter a hostname in the field "Hostname" Enter a Username in the field "Username" Enter an incorrect password in the field "Password" Click Cancell button
Exit the login window
Test Case ID 6
Steps Description Expected Results
6 Enter a hostname in the field "Hostname" Do not enter a Username in the field "Username" Click Ok button
Error message: „Username is
Test Case ID 7
Steps Description Expected Results
7 Enter a hostname in the field "Hostname" Do not enter a Username in the field "Username" Click Cancell button
Exit the login window
Test Case ID 8
Steps Description Expected Results
8 Click Ok buttonDo not enter a hostname in the field "Hostname" Error mandatory” message: “Hostname is
Test Case ID 9
Steps Description Expected Results
9 Click Cancell buttonDo not enter a hostname in the field "Hostname" Exit the login window
KẾT LUẬN
Trong quá trình phát triển các dự án phần mềm, để đảm bảo chất lượng phần mềm thì giai đoạn kiểm thử đóng một vai trò rất quan trọng.Thực tiễn đã chứng minh, chi phí cho quá trình kiểm thử 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. Mục đích của kiểm thử là để đảm bảo rằng tất cả các thành phần của ứng dụng phải chạy đúng, vận hành như mong đợi, phù hợp với các tiêu chuẩn thiết kế và tìm ra các lỗi nhiều nhất có thể kể cả những lỗi tiềm ẩn.
Trong giai đoạn kiểm thử, đa phần các lỗi được tìm ra đều theo những kịch bản có sẵn (ngoại trừ những lỗi được test theo kinh nghiệm của tester và đặc thù của ứng dụng). Các kịch bản này đều được tài liệu hóa trong các Test case. Do đó, Test case là một tài liệu đặc biệt quan trọng trong quá trình kiểm thử. Vậy làm thế nào để sinh ra Test case tốt, có chất lượng và giảm bớt thời gian viết của các tester. Điều này cho thấy, sự cần thiết của việc nghiên cứu quá trình sinh Test case tự động là rất quan trọng và đặc biệt có ý nghĩa.
Đề tài đã nghiên cứu vấn đề này và thu được một số kết quả sau:
Có một cách nhìn tổng quan về việc sinh Test case tự động trong giai đoạn kiểm thử của quá trình phát triển các dự án phần mềm.
Phân tích, đánh giá các phương pháp và kỹ thuật sinh Test case tự động hiện có. Từ đó đề xuất một quá trình 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.
Từ đó xây dựng chương trình demo cho quá trình sinh Test case tự động. Hướng nghiên cứu tiếp của đề tài là tách các yêu cầu chức năng và các yêu cầu phi chức năng riêng ra. Sau đó, tập trung vào việc phân tích các yêu cầu phi chức năng để có thể xây dựng được cách sinh tự động các Test case từ các yêu cầu phi chức năng này. Mục đích của công việc này nhằm hoàn thiện quá trình tạo ra Test case để có chất lượng phần mềm tốt hơn.
Ngoài ra, chúng ta có thể nghiên cứu theo các hướng tiếp cận khác trong việc sinh Test case tự động: thứ nhất có thể sinh Test case tự động dựa trên đặc tả từ một file input đã được định sẵn, cách tiếp cận này khá khó khăn vì chúng ta phải xây dựng bộ từ điển để làm sao có thể đọc được file input đã định sẵn và theo cách này thì tester cũng tốn công sức để tài liệu hóa yêu cầu theo định dạng của file input này. Nhưng ưu điểm của hướng nghiên cứu này, cũng tạo ra các tài liệu Test case từ giai đoạn đầu của quá trình phát triển nên các lỗi được phát hiện và ngăn chặn từ rất sớm trong khi phát triển các dự án phần mềm. Thứ hai có thể sinh Test case tự động dựa trên code, chương trình có sẵn nhưng theo cách này thì việc tạo Test case phải được làm sau giai đoạn lập trình. Chính vì vậy mà việc phát hiện các lỗi về sai yêu cầu phần mềm, sai về thiết kế mãi đến giai đoạn sau của dự án mới có thể phát hiện ra được. Điều này không có lợi và sẽ làm tăng chi phí trong việc phát triển các dự án phần mềm hơn là các dự án mà việc sinh Test case được thực hiện ngay ở giai đoạn đầu của dự án sau khi phân tích các yêu cầu phần mềm.
TÀI LIỆU THAM KHẢO
[1] Andras Toth, Daniel Varro, Andras Pataricca, 2003, Model Level Automatic Test
Generation for UML State-Charts, Sixth IEEE workshop on Design and
Diagnostics of Electronic Circuits and System, (DDECS 2003).
[2] Clay E. Williams, November 1999, Software testing and the UML, International Symposium on Software Reliability Engineering (ISSRE‟99), Boca, Raton.
[3] Jeff Offutt, Aynur Abdurazik, October 1999, Generating Tests from UML
specifications, Second International Conference on the Unified Modeling
Language (UML99).
[4] Jeff Offutt, Aynur Abdurazik, October 2000, Using UML Collaboration diagrams
for static checking and test generation, Third International Conference on UML,
York, UK.
[5] Jeff Offutt, Shaoying Liu, Aynur Abdurazik, Paul Ammann, March 2003,
Generating Test data from State based Specifications, The Journal of Software
Testing, Verification and Reliability.
[6] Matthias Riebish, Ilka Philippow, Marco Gotze, UML Based Statistical Test Case