Chương 4 : Thực nghiệm kiểm thử phần mềm
4.4 Mô hình xây dựng use-case với bài toán thực tế
4.4.5 Xây dựng các tình huống kiểm thử
Ta xây dựng các tình huống kiểm thử ứng với use case “Xuất hàng tiêu thụ” trong bài toán thực tiễn phát biểu trên.
Các use case scenario phát triển từ use case trên bao gồm:
Lập giao dịch bán hàng cho khách.
Kiểm tra giá trị giao dịch.
Lập hóa đơn giao dịch.
Dưới đây là bảng xây dựng các tình huống kiểm thử trên use case nhập giao dịch bán lẻ hàng.
Tình huống Các bước thực hiện Kết quả mong đợi
Lập giao dịch bán hàng cho khách. Thực hiện giao dịch bán hàng thành công – hàng có serial Mở chức năng “Lập giao dịch bán lẻ” trên menu. Nhập giao dịch bán lẻ thành công Loại dịch vụ: Chi tiết giao dịch: Ngày bán:
Lý do bán: HTTH:
Chương trình hiển thị các thông tin giao dịch nhập mới. Nhấn Thêm Nhập thông tin mặt hàng: Mặt hàng Số lượng Nhấn [Cập nhật] - Hàng vừa nhập được hiển thị trong danh sách các mặt hàng giao dịch, với thông tin: mã hàng,
giá, thuế, khuyến
mãi,Tổng tiền.
- Thông tin về tiền hàng được cập nhật vào phần tính tổng tiền cho toàn giao dịch.
Tìm kiếm serial hàng hóa trong kho.
Chọn số lượng các serial trong kho ứng với số lượng mặt hàng giao dịch. [Chấp nhận] dải serial giao dịch
Dải serial được cung cấp được gắn với hàng hóa. Mỗi số serial là duy nhất với từng mặt hàng lựa chọn.
Nhấn "Ghi giao dịch" Giao dịch được ghi thành
Lượng hàng giao dịch được trừ trong kho của giao dịch viên.
Trạng thái serial được cập nhật là không còn trong kho. Thực hiện giao dịch thành công – hàng không có serial Mở chức năng “Lập giao dịch bán lẻ” trên menu. Nhập giao dịch bán lẻ thành công Loại dịch vụ: Chi tiết giao dịch: Ngày bán:
Lý do bán: HTTH:
Chương trình hiển thị các thông tin giao dịch nhập mới. Nhấn Thêm Nhập thông tin mặt hàng: Mặt hàng Số lượng Nhấn [Cập nhật] - Hàng vừa nhập được hiển thị trong danh sách các mặt hàng giao dịch, với thông tin: mã hàng,
giá, thuế, khuyến
mãi,Tổng tiền.
- Thông tin về tiền hàng được cập nhật vào phần tính tổng tiền cho toàn giao dịch.
Nhấn "Ghi giao dịch" Giao dịch được ghi thành
công.
Lượng hàng giao dịch được trừ trong kho của giao dịch viên.
Kiểm tra lượng hàng trong kho không đủ giao dịch
Nhấn [Thêm] trên danh sách nhập hàng giao dịch Nhập tên mặt hàng
Nhập số lượng hàng>số lượng hiện có trong kho Nhấn “Cập nhật”
Hệ thống kiểm tra số lượng hàng có trong kho và hiển thị thông báo: hàng <…> không đủ để thực hiện giao dịch.
vào hệ thống. Nhập giao dịch gồm nhiều mặt hàng trong đó có mặt hàng số lượng giao dịch > số lượng hiện có. Hệ thống kiểm tra số lượng hàng có trong kho và hiển thị thông báo: Mặt hàng <…> không đủ để thực hiện giao dịch.
Giao dịch không được lưu vào hệ thống.
Kiểm tra thông tin giao dịch
Nhập ngày giao dịch > ngày hiện thời
Chương trình hiển thị thông báo: Ngày giao dịch nhập sau ngày hiện thời. Bỏ trống các thông tin
bắt buộc nhập
Không nhập các thông tin giao dịch bán lẻ bắt buộc như: Ngày bán: Lý do bán: HTTH: Nhập hàng hóa thực hiện giao dịch Nhấn "Lưu" Chương trình hiển thị thông báo: <<...>> không được để trống.
Số lượng hàng giao dịch bị bỏ trống
Nhấn [Thêm] trên danh sách hàng giao dịch Nhập mặt hàng giao dịch Không nhập số lượng hàng giao dịch Nhấn [Cập nhật] Hệ thống hiển thị thông báo: Bạn chưa nhập số lượng hàng thực hiện giao dịch.
Mặt hàng giao dịch chưa khai giá.
Nhấn [Thêm] trên danh sách hàng giao dịch
Nhập mặt hàng giao dịch
Hệ thống hiển thị thông báo: Chưa khai giá cho mặt hàng.
Số lượng hàng nhập trong giao dịch < 0.
Nhấn [Thêm] trên danh sách hàng giao dịch Nhập mặt hàng giao dịch Nhập số lượng hàng giao dịch < 0. Nhấn [Cập nhật] Hệ thống hiển thị thông báo: Số lượng hàng giao dịch phải lớn hơn 0.
Kiểm tra giá trị “tổng tiền”
Nhập mặt hàng giao dịch Tra cứu giá mặt hàng.
Giá trị trên đơn giá mặt hàng là giá trị đã bao gồm thuế.
Tổng tiền = Tổng [Đơn giá * số lượng] của các mặt hàng.
Kiểm tra giá trị thuế Dựa trên tổng tiền, VAT
từng mặt hàng: kiểm tra giá trị thuế đơn hàng.
Thuế = Tổng (đơn giá*số lượng)*VAT của các mặt hàng.
Kiểm tra giá trị chưa thuế.
Kiểm tra giá trị chưa thuế của đơn hàng.
Chưa thuế = Tổng tiền – Thuế.
Kiểm tra giá trị phải trả
Xác định lượng tiền phải trả của đơn hàng.
Phải trả = Chưa thuế + Thuế - Khuyến mãi – Chiết khấu.
Hóa đơn cho giao dịch bán hàng.
Lập hóa đơn bán hàng từ giao dịch bán lẻ thành công Trên màn hình lập giao dịch bán hàng. Nhập mặt hàng giao dịch. Nhấn “Ghi giao dịch” Chọn tùy chọn: Lập hóa đơn bán hàng. Chương trình thực hiện lập hóa đơn giao dịch thành công.
Hóa đơn trong kho nhân viên được sử dụng vào giao dịch.
Số hóa đơn trắng trong kho được giảm đi 1 hóa đơn.
Lập hóa đơn bán hàng cho nhiều giao dịch thành công. Mở chức năng “Lập hóa đơn bán hàng”. Chọn các giao dịch lập hóa đơn. Chọn [Lập hóa đơn]. Chương trình thực hiện lập hóa đơn thành công. Hóa đơn trong kho nhân viên được sử dụng vào giao dịch.
Số hóa đơn trắng trong kho được giảm đi 1 hóa đơn. Cửa hàng không còn hóa đơn trắng. Trên màn hình lập giao dịch bán hàng. Nhập mặt hàng giao dịch. Nhấn “Ghi giao dịch” Chương trình hiển thị thông báo: Kho hết hóa đơn sử dụng.
Chọn tùy chọn: Lập hóa đơn bán hàng. Mở chức năng “Lập hóa đơn bán hàng”. Chọn các giao dịch lập hóa đơn. Chọn [Lập hóa đơn]. Chương trình hiển thị thông báo: Kho hết hóa đơn sử dụng. Không chọn giao dịch lập hóa đơn Nhấn [Lập hóa đơn] từ màn hình Lập hóa đơn. Chương trình hiển thị thông báo: Chọn ít nhất 1 giao dịch để lập hóa đơn. Thông tin hóa đơn bỏ
trống
Mở chức năng lập hóa đơn Nhập thông tin hóa đơn Nhấn [Lập hóa đơn]
Chương trình hiển thị
thông báo: Trường
<<…>> không được bỏ trống.
Kiểm tra thông tin giao dịch trên hóa đơn
Thông tin giao dịch trên hóa đơn hiển thị giống trong màn hình giao dịch bán lẻ gồm:
Khách hàng, lý do bán hàng, hình thức bán.
Các mặt hàng giao dịch. Các giao dịch trên hóa đơn.
Kết luận
Hiện nay, phát triển phần mềm hướng cấu phần (CBSE) đang thu hút các nghiên cứu từ rất nhiều góc độ khác nhau như kỹ thuật xây dựng, đánh giá, kiểm định phần mềm, quy trình khảo sát, phân tích thiết kế, quản lý.
Phát triển phần mềm hướng cấu phần (CBSE) là một công nghệ quan trọng cho phép xây dựng những hệ thống phần mềm chất lượng cao, mở và các hệ thống phần mềm lớn bằng cách tích hợp các cấu phần phần mềm đã tồn tại trước đó. CBSE đã giảm bớt được giá thành phát triển phần mềm, xây dựng các hệ thống một cách nhanh chóng, giảm bớt được việc bảo trì theo kiểu xoắn ốc liên quan đến việc hỗ trợ và nâng cấp cho các hệ thống lớn. CBSE đang thu hút các nghiên cứu rất nhiều từ góc độ các kỹ thuật xây dựng, đánh giá phần mềm cho tới quy trình khảo sát, phân tích thiết kế, quản lý, đánh giá. Một trong những hướng nghiên cứu hiện nay là thay đổi cách phát triển của các hệ thống phần mềm: chuyển từ việc lập trình tạo ra các sản phẩm sang việc biên soạn các hệ thống phần mềm, tức là chỉ tập trung vào việc lựa chọn và tích hợp các cấu phần có sẵn để xây dựng nên các hệ thống. Trong phương pháp phát triển này việc tìm kiếm các cấu phần và lựa chọn tích hợp các dịch vụ của các cấu phần đang là hai vấn đề đang tập trung nghiên cứu.
UML hỗ trợ phát triển phần mềm hướng cấu phần đã đem đến cho các đối tượng phát triển hệ thống cái nhìn rõ ràng về hệ thống xây dựng, giúp cho người phân tích thiết kế thấy được các yếu tố ảnh hưởng trực tiếp tới hệ thống. Trên cơ sở đó, cán bộ phân tích hệ thống xác định được các cấu phần cần tích hợp với hệ thống.
Tham gia vào quy trình phát triển phần mềm luôn có sự góp mặt của bộ phận kiểm định phần mềm. Với phương pháp phát triển phần mềm cấu phần trên, kết hợp với bước kiểm định sẽ làm giảm thiểu một cách tối đa các lỗi trong phần mềm. Tuy thế, Mặt khác, ta cũng không thể khẳng định rằng khi phát triển phần mềm trên cơ sở cấu phần, với sự tham gia của UML trong thiết kế thì phần mềm làm ra sẽ không còn lỗi.
Tóm tắt kết quả chính đã đạt được
Qua thời gian nghiên cứu tìm hiểu về phần mềm xây dựng trên cơ sở cấu phần, áp dụng UML trong CBSE, kiểm thử phần mềm, tôi đã áp dụng nghiên cứu kiểm thử phần mềm vào phần mềm hướng cấu phần và đã đạt được những kết quả nhất định. Một trong những công việc quan trọng của kỹ thuật kiểm thử
đó là: phát hiện lỗi và hỗ trợ sửa lỗi nhằm đảm bảo chất lượng phần mềm. Với sự phát triển không ngừng của các kỹ thuật lập trình hiện nay, lập trình hướng cấu phần (COP) nổi lên như một kỹ thuật lập trình mới cung cấp khả năng phát triển hệ thống. Xét trên tính khả thi, và hiệu quả kinh tế của CBSE mang lại mà luận văn tập trung nghiên cứu đến khía cạnh kiểm thử phần mềm trên cơ sở cấu phần. Như vậy, sau quá trình tìm hiểu, nghiên cứu những vấn đề kiểm thử nói trên, luận văn của tôi đã đạt được một số kết quả như sau:
Tìm hiểu tổng quan về các khái niệm chuẩn trên phần mềm hướng
cấu phần, đánh giá, phân tích các ưu và nhược điểm phần mềm xây dựng trên cơ sở hướng cấu phần.
Kết hợp kỹ thuật kiểm thử vào quy trình phát triển phần mềm hướng
cấu phần. Từ đó thấy được ưu điểm của việc kiểm thử trong bài toán thực tế.
Xây dựng ví dụ thực nghiệm áp dụng nghiên cứu với bài toán “quản
lý bán hàng”.
Tồn tại và hướng phát triển
Với sự phát triển như vũ bão của nghành Công nghệ thông tin, các hệ thống phần mềm ngày càng phức tạp, nhu cầu có thể sử dụng lại các thành quả có sẵn nhằm giảm chi phí và giá thành cạnh tranh sản xuất là mục tiêu hướng tới của các doanh nghiệp. Chính vì thế hướng phát triển phần mềm trên cơ sở hướng cấu phần trong giai đoạn hiện nay là hợp lý và thu hút được quan tâm của nhiều đối tượng.
Các kỹ thuật kiểm thử phần mềm hiện nay hầu như chưa đáp ứng được một cách triệt để, chưa kiểm soát được hết các khía cạnh giao tiếp trong một cấu phần hoặc giữa các cấu phần với nhau. Việc sử dụng lại các cấu phần có thể phát triển theo các khía cạnh sử dụng lại hộp trắng, sử dụng lại hộp đen. Vì thế, vấn đề đặt ra là trong thời gian tới ta có thể xây dựng được kỹ thuật kiểm thử nào hiệu quả đáp ứng nhu cầu kiểm soát hoạt động của các cấu phần trong toàn bộ hệ thống hoặc kiểm soát các thay đổi, nâng cấp các tính nhăng tích hợp của từng cấu phần trong toàn bộ hệ thống. Vậy làm thế nào để chúng ta bao quát được vấn đề quản lý các cấu phần trong một hệ thống phần mềm, từ đó kiểm thử được những ảnh hưởng các cấu phần trong hệ thống. Và trong tương lai liệu sẽ có công cụ nào có thể hỗ trợ cho hướng kiểm thử này?
Với mục tiêu hướng tới phần mềm có chất lượng cao, đạt hiệu quả kinh tế,
- Nghiên cứu kỹ thuật kiểm thử hiệu quả trên từng đơn vị cấu phần cho sử dụng lại.
- Đi sâu vào từng kỹ thuật kiểm thử tích hợp các cấu phần đã có sẵn vào phần mềm xây dựng.
- Tìm hiểu các công cụ hỗ trợ kiểm thử đáp ứng các phần mềm xây dựng trên cơ sở hướng cấu phần.
Tài liệu tham khảo
1) Dinesh Maidasani, 2007, Software Testing, Firewall.
2) Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black, 2008,
Foundation of software testing, Cengage Learning (Thompson).
3) Bill Councill, George T. Heineman, May.2001, Component-Based
software engineering, Addison-Wesley.
4) Hans Gerhard, 2005, Component-Based Software Testing with UML,
Springer.
5) Jerry Zeyu Gao, H.-S.Jacob Tsao Ye Wu, August.2003, Testing And
Quality Assurance For Component Based Software, Artech House.
6) Bruce Powel Douglass, 2002, Real-Time Design Patterns, Addison-
Wesley.
7) Andy Ju An Wang, Kai Qian, 2005, Component-Oriented Programming,
John Wiley & Sons, Inc., Hoboken, New Jersey.
8) H. Muccini and A. Bucchiarone,2004, Testing Product Line Architectures.
9) Jean Hartmann; Claudio Imoberdorf; Michael Meisinger, 2000, UML-Based
Integration Testing.
10) Antonia Bertolino; Eda Marchetti; Andrea Polini, 2003, Intergration of
“Components” to Test Software Components, Vol.82.
11) Clay E. Williams, Software Testing and the UML, Center for Software
Engineering, IBM T. J. Watson Research Center.
12)Shaukat Ali1, Lionel C. Briand, Muhammad Jaffar-ur Rehman, Hajra Asghar,
Muhammad Zohaib Z. Iqbal, Aamer Nadeem, October 2006, A State-based
Approach to Integration Testing based on UML Models, Carleton Technical
Report SCE-05-02, Version 3.
13)Ye Wu and Mei-Hwa Chen and Jeff Offutt, UML-based Integration Testing for
Component-based Software, Information and Software Engineering Department George Mason University, Computer Science Department State University of New York at Albany.
14) British Computer Society Specialist Interest Group in Software Testing,2001,
15) Trung Thanh Dinh Trong, 2007, A Systematic Procedure for Testing UML Designs, Computer Science Department, Colorado State University.
16) Dominykas Barisas, Eduardas Bareisa, 2009, A Software testing approach
based on behavioral UML models, ISSN 1392-124X, Vol.38, No.2.
17) Adriana Carniello, Mario Jino, Marcos Lordello Chaim, August 2005,
Structural Testing with Use Case, JCS & T, Vol.5 No 2.
18) Zhen Ru Dai, Model- Driven Testing with UML 2.0, Fraunhofer FOKUS,
Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany.
19) Adrita Bhor, June 2001, Software Component Testing Strategies, Dept. of
Information and Computer Science University of California, Irvine, Report UCI-ICS-02-06.
20)Jerry Gao, Ph.D, Testing Component-Based Software, San Jose State