3.2.1. Kiểm thử form Login
Hộp thoại Login cho một ứng dụng: Mục đích của hộp thoại này là để xác thực người sử dụng và cho phép người sử dụng đăng nhập hay ngăn chặn người sử dụng đăng nhập vào hệ thống. Giả sử có thành phần quản lý user và xử lý số user và mật khẩu (password) cho mỗi user. Đặc tả cho ví dụ này như sau:
Một textbox cho phép nhập user name: Cho phép người sử dụng nhập user name đã đăng kí. Nếu người sử dụng bấm chọn nút OK, chương trình sẽ kiểm tra xem, password đã được nhập vào chưa, và nếu đã được nhập thì password có đúng không.
Một textbox cho phép nhập password: Cho phép người sử dụng nhập password. Nếu người dùng đã đưa ra một user name hợp lệ và nếu người sử dụng nhấp chuột vào OK, chương trình sẽ so sánh mật khẩu nhập vào với mật khẩu được lưu trữ và ứng dụng sẽ bắt đầu. Nếu không, người sử dụng sẽ bị chặn.
Nút OK và nút Cancel.
Theo đặc tả, ta có 3 tham số: User Name, Password, Button. Ứng với mỗi tham số có các giá trị như sau:
User Name: [ Known UserName, Unknown UserName, Empty]
Password: [Correct Password, Incorrect Password, Empty]
Button: [OK, Cancel]
Nhận xét:
Về mặt lý thuyết, một textbox với giới hạn 255 kí tự có thể có tới hàng trăm nghìn khả năng xảy ra. Bằng cách thêm vào Logic ứng dụng, ta đã giảm chỉ còn 3 khả năng xảy ra cho một textbox.
TT Tham số Giá trị Ví dụ
1 User Name - Known UserName - Unknown UserName - Empty
2 Password - Correct Password - Incorrect Password - Empty
3 Button - OK - Cancel
Số kết hợp có thể có = 2x32=18 Số Test Case có thể sinh ra là 18 Test Case.
3.2.2. Kiểm thử form Lương Cơ Bản
Giả sử ta đang kiểm thử chương trình quản lý nhân sự, ta cần kiểm thử form bảng lương như sau:
Nhận xét:
Áp dụng phương pháp sinh Test Case từ giao diện phần trên, ta có:
- Mã lương: người sử dụng nhập mã lương của nhân viên. Có 2 trường hợp có thể xảy ra: Dữ liệu nhập là hợp lệ hoặc không hợp lệ.
- Chức vụ: Người sử dụng sẽ chọn trong danh sách sổ xuống. Có chức vụ sau: Giám đốc nhân sự, trưởng phòng kinh doanh, trưởng phòng kế hoạch, Quản đốc xưởng, để trống.
- Chức danh: Tổng giám đốc, giám đốc, trưởng phòng, phó phòng, nhân viên, để trống.
- Lương cơ bản: người sử dụng nhập lương cơ bản cho nhân viên. Có 2 trường hợp xảy ra: Dữ liệu nhập là hợp lệ, hoặc không hợp lệ.
- PC Chức vụ: cũng có 2 trường hợp: dữ liệu nhập là hợp lệ hoặc không hợp lệ (trong trường hợp là nhân viên thông thường, không có chức vụ).
- Các nút: Nhập, Sửa, Xoá, Thoát. Ta có bảng mô tả sau: TT Tham số Giá trị Ví dụ 1 Mã lương - Hợp lệ - Không hợp lệ KD01 -1,#,.. 2 Chức vụ Giám đốc nhân sự, trưởng phòng kinh doanh,
trưởng phòng kế hoạch, Quản đốc xưởng, để trống.
3 Chức danh Tổng giám đốc, giám đốc, trưởng phòng, phó phòng, nhân viên, để trống. 4 Lương cơ bản Dữ liệu nhập là hợp lệ Không hợp lệ 5 PC chức vụ Dữ liệu nhập là hợp lệ Không hợp lệ 6 Nút Nhập Sửa Xoá Thoát
Theo phương pháp sinh Test Case đề cập phần trên, số tham số = 6; số giá trị có thể nhận được = 21 số Test Case mà tester cần viết cho form LuongCoBan là: 216 Test Case.
Chương 4 Công cụ hỗ trợ
Trong các công ty phát triển phần mềm hầu hết công việc kiểm thử của kiểm thử viên được thực hiện thủ công bằng tay. Một trong những công việc quan trọng trong quá trình kiểm thử là việc tạo Test Case. Để giải quyết vấn đề này ta xây dựng công cụ sinh Test Case từ phương pháp sinh Test Case từ giao diện đã giới thiệu trong chương 3.
4.1. Thiết kế chức năng 4.1.1. Thiết kế tổng quan 4.1.1. Thiết kế tổng quan
Công cụ sinh Test Case tự động, được mô hình hoá bởi các tham số đầu vào và các miền giá trị có thể có của các tham số (hay các lớp tương đương), kết quả mong đợi được biễu diễn là kết quả Boolean, điều kiện được xem như là các biểu thức logic bằng cách sử dụng các tham số được định nghĩa trước và các miền giá trị liên kết chúng với kết quả mong đợi. Ngoài ra, điều kiện Null là điều kiện cho phép xác định sự kết hợp không mong muốn để giảm số lượng các kết quả kiểm thử.
Tập Test Case sinh ra có thể lưu lại bằng ứng dụng MS Excel, XML... Dựa trên mô hình kiểm thử, công cụ sẽ thực hiện công việc vất vả nhất thay cho tester. Công cụ sẽ tạo ra tất cả các kết hợp có thể có của các tham số và miền giá trị của nó. Sau khi sinh Test Case, công cụ này sẽ áp dụng các qui định về mô hình liên kết các kết quả mong đợi với các kết hợp để loại bỏ các kết hợp không mong muốn.
Để có thể sinh Test Case, trước hết, kiểm thử viên cần thực thiện thao tác Nhập các tham số xuất hiện trên màn hình kiểm thử. Sau khi nhập tham số, ứng với mỗi tham số, dựa theo đặc tả của phần mềm mà kiểm thử viên sẽ nhập miền giá trị cho mỗi tham số. Để mô tả một Test Case cần có kết quả mong đợi. Kết quả này chúng ta có thể thấy trong đặc tả của phần mềm. Ngoài ra, tester cũng cần nhập thêm các điều kiện, để dựa vào điều kiện này có thể loại bỏ những Test Case dư thừa.
4.1.2. Biểu đồ Use case
- Thao tác Nhập tham số: Tester sẽ thực hiện nhập các tham số có trên giao diện chính mà tester đang thực hiện viết Test Case.
- Thao tác nhập giá trị: Sau khi nhập xong tham số, tester sẽ nhập các giá trị mà tham số có thể nhận được (để viết được phần này, yêu cầu tester đọc kĩ đặc tả phần mềm)
- Thao tác Nhập kết quả: Những phản hồi của phần mềm.
- Thao tác Sinh Test Case: sau khi nhập thực hiện các thao tác trên, công cụ sẽ tự động sinh Test Case và cho phép export ra file Excel, XML, SQL.
4.1.3. Biểu đồ hoạt động
Hình 4.2 mô tả các hoạt động của công cụ trong quá trình sinh Test Case.
Nhập tham số Nhập giá trị Nhập kết quả Sinh Test Case Tester Nhập điều kiện
4.1.4. Biểu đồ lớp
Mục đích cụ thể các lớp (Class) như sau:
1 – Class ThamSo: Cho biết thông tin 1 tham số gồm có:
- Tên của tham số
- Các giá trị của tham số đó (Ở đây lưu bằng 1 IDictionary vì có lợi điểm tìm kiếm)
- Các giá trị sample của tham số đó (Lưu bằng 1 IDictionary) 2- Class KetQua: Cho biết thông tin 1 kết quả, gồm có:
- Tên của kết quả
- Mô tả chi tiết kết quả đó
- Kiểu kết quả
3- Class DieuKienDon: Cho biết thông tin 1 điều kiện đơn. Trong 1 điều kiện của chương trình sẽ có 1 hoặc nhiều điều kiện đơn, gồm có các thuộc tính:
- 2 Đối số của điều kiện đơn
- Toán tử kết hợp của 2 đối số đó (kiểu enum)
4 – Class DieuKien: Cho biết thông tin 1 điều kiện, gồm có các thuộc tính:
- Tên điều kiện
- Công thức của điều kiện đó
- Tên của kết quả chọn để hiện thị kết quả của điều kiện đó
- 1 biến bool cho biết có chọn điều kiện đó hay không 5 – Class Test Case: Cho biết thông tin một Test Case gồm có:
- Mã Test Case
- Tên Tham số
- Tên Kết quả
Ngoài ra, chúng tôi dùng Class toàn cục GlobalVar: lưu các biến toàn cục sử dụng cho toàn bộ chương trình, gồm có:
- IDictionary tham số: lưu toàn bộ các tham số của chương trình
- IDictionary kết quả: lưu toàn bộ các kết quả của chương trình
- IDictionary công thức: Lưu toàn bộ các điều kiện của chuong trình
- Datatable Test Case: Lưu thông tin kết quả sau khi đã phát sinh Test Case
- Đường dẫn file save: cho biết đường dẫn file đã save của chương trình
4.2. Cài đặt
Công cụ hỗ trợ lập trình: 1. Visual studio 2010 2. Dotnet bar
Giao diện công cụ như sau:
4.2.1. Nhập tham số
Form này cho phép nhập tất cả các tham số xuất hiện trên GUI. Người dùng nhập tên tham số, sau đó click thêm:
Kiểm tra trong Dictionary tham số đã tồn tại tham số có tên trên chưa:
- Nếu có thì báo là đã tồn tại tham số này rồi
- Nếu không thì thêm tham số này vào Dictionary tham số và hiển thị ở DataGridView bên dưới
Khi người dùng nhập giá trị cho 1 tham số:
- Người dùng phải chọn tham số nào để nhập.
- Nhập 1 giá trị, đầu tiên sẽ kiểm tra tham số đã có giá trị đó chưa, nếu có thì sẽ thông báo đã tồn tại giá trị này rồi, nếu không thì thêm giá trị này cho tham số đó.
Cập nhật tên 1 tham số:
- Kiểm tra tên tham số vừa cập nhật đã tồn tại chưa, nếu chưa thì cho cập nhật vào Dictionary tham số.
Cập nhật 1 giá trị
- Kiểm tra giá trị đó đã tồn tại chưa, nếu chưa thì cho cập nhật vào Dictionary tham số.
Xóa 1 tham số:
- Kiểm tra nếu tham số đó tồn tại thì remove tham số đó khỏi Dictionary tham số.
Xóa 1 giá trị
- Kiểm tra nếu giá trị đó tồn tại thì remove giá trị đó khỏi Dictionary tham số.
4.2.2. Nhập kết quả
Cho phép nhập kết quả trả về khi các tham số lần lượt nhận các giá trị được mô tả theo đặc tả của hệ thống.
Khi nhập 1 kết quả:
Kiểm tra kết quả đó có tồn tại trong IDictionary kết quả chưa:
- Nếu có thì thông báo kết quả này đã tồn tại.
Cập nhật thông tin 1 kết quả
Kiểm tra kết quả vừa mới cập nhật đã tồn tại trong Dictionary kết quả chưa:
- Nếu có thì thông báo kết quả này đã tồn tại.
- Nếu chưa thì cập nhật kết quả này vào Dictionary kết quả.
Xóa 1 kết quả
Kiểm tra kết quả muốn xóa đã tồn tại trong Dictionary kết quả chưa:
- Nếu có thì remove kết quả này ra khỏi dictionary kết quả.
- Nếu chưa thì thông báo kết quả này không tồn tại.
4.2.3. Nhập điều kiện
Cho phép nhập các điều kiện để có thể làm giảm số lượng Test Case sinh ra.
Khi người dùng thêm 1 điều kiện:
- Kiểm tra điều kiện đó có đúng cú pháp hay không.
- Kiểm tra tên điều kiện này đã tồn tại hay chưa.
- Kiểm tra đã tạo kết quả nào chưa.
Khi xóa 1 công thức:
- Kiểm tra điều kiện đó đã tồn tại hay chưa. - Nếu có thì remove ra khỏi dictionary công thức. - Nếu không thì báo công thức không tồn tại.
4.3.4.Sinh Test Case
Sau khi nhập Tham số, Kết quả trả về, Điều kiện thực hiện, công cụ sẽ giúp Tester tự động sinh Test Case thông qua form Sinh Test Case.
Khi nhấn vào phát sinh:
- Kiểm tra chiều sâu phát sinh có vượt quá số giá trị của bất kì 1 tham số nào hay không. Nếu có thì báo lỗi.
- Tổ hợp các giá trị của từng tham số theo chiều sâu phát sinh nhập như trên.
Xuất tập Test Case dưới các dạng:
- Export ra file Excel.
- Export dữ liệu trên datagridview ra file excel. - Export ra file XML.
- Export dữ liệu trên datagridview ra file XML.
Lưu Test Case
Lưu tất cả các biến toàn cục ra file xml theo dịnh dạng: <Root> <ThamSo> <Item Ten=""> <GiaTri></GiaTri> <GiaTriSample></GiaTriSample> <GiaTri></GiaTri> <GiaTriSample></GiaTriSample> <GiaTri></GiaTri> <GiaTriSample></GiaTriSample> <Item> ...
</ThamSo> <KetQua> <Item> <Ten></Ten> <MoTaChiTiet></MoTaChiTiet> <Kieu></Kieu> </Item> ... </KetQua> <CongThuc> <Item> <DieuKinDon> <DoiSo></DoiSo> <DoiSo></DoiSo> <ToanTuKetHop></ToanTuKetHop> </DieuKienDon> ... <ToanTu></ToanTu> ... <DieuKien> <TenDieuKien></TenDieuKien> <CongThuc></CongThuc> <TenKetQua></TenKetQua> <ChonKetQua></ChonKetQua> </DieuKien> </Item> … </CongThuc> </Root>
4.3. Ưu, nhược điểm của công cụ
Ưu điểm
- Do quá trình sinh Test Case là tự động vì vậy mà rút ngắn thời làm phần mềm, và chất lượng phần mềm tốt hơn.
- Quá trình sinh ra các Test Case được thực hiện một cách tự động nên sinh ra nhiều ca kiểm thử và phát hiện nhiều lỗi.
- Tester sẽ không bị nhàm chán khi phải thực hiện lặp lại nhiều lần một công việc, điều đó làm cho tester không nhàm chán với công việc của mình.
- Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết kế vì vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử.
- Tự động tạo và kiểm tra chánh các ca kiểm thử trùng nhau hoặc không hữu hiệu.
Nhược điểm
- Tester phải yêu cầu là những người có khả năng phân tích và thiết kế hệ thống.
- Tester phải đầu tư đáng kể cả về thời gian, trí tuệ cho việc nghiên cứu tài liệu đặc tả của hệ thống.
Kết luận
Thông qua việc tìm hiểu lý thuyết về kiểm thử, kiểm thử tự động, các phương pháp sinh Test Case tự động cũng như áp dụng lý thuyết vào việc xây dựng công cụ sinh Test Case tự động. Luận văn đã đạt được các kết quả như sau:
Trước hết, chúng tôi đã tìm hiểu và trình bày lại một cách nhìn tổng quan về kiểm thử, vai trò và lợi ích về kiểm thử tự động và phân loại các công cụ kiểm thử tự động.
Bên cạnh đó, chúng tôi cũng đã nghiên cứu các phương pháp sinh Test Case tự động phổ biến hiện nay, từ đó xây dựng lên phương pháp sinh Test Case tự động từ giao diện. Vận dụng phương pháp sinh Test Case tự động từ giao diện, chúng tôi xây dựng thành công công cụ sinh Test Case tự động.
Thông qua việc thực hiện luận văn này, chúng tôi nhận thấy rằng, kiểm thử tự động cho phép giảm chi phí (thời gian, công sức) của quá trình kiểm thử, bên cạnh đó, kiểm thử tự động còn làm tăng độ chính xác, độ bao phủ của kiểm thử. Không những thế, kiểm thử tự động còn có thể làm được những việc mà con người khó có thể làm được (Ví dụ: việc cố gắng hoàn thành đúng như thực tế một ca kiểm thử của hệ thống với 200 người dùng cùng trực tuyến (online) có thể không thực hiện được nếu thực hiện kiểm thử bằng tay. Nhưng 200 người dùng này có thể được giả lập bằng các công cụ kiểm thử tự động).
Trong tương lai, luận văn có hướng nghiên cứu sau:
Hiện tại công cụ mới chỉ dừng lại ở mức hỗ trợ sinh Test Case mà chưa tự động nhận diện được các tham số xuất hiện trên màn hình giao diện phần mềm. Chúng tôi sẽ nghiên cứu để hệ thống có thể tự nhận diện được các tham số có trên giao diện mà tester không cần nhập bằng tay để có thể đem lại hiệu quả một cách cao nhất.
TÀI LIỆU THAM KHẢO
Tiếng Việt
1. Nguyễn Văn Vỵ , Nguyễn Việt Hà (2000), Giáo trình kỹ nghệ phần mềm, NXB Giáo dục.
2. Vũ Thị Đào (2008), Kỹ thuật sinh Test Case tự động từ yêu cầu phần mềm, Luận văn Thạc sĩ, Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội.
Tiếng Anh
3. Aditya P. Mathur (2007), Foundations of Software Testing: Fundamental Algorithms and Techniques, Pearson Education India.
4. Aynur Abdurazik and Jeff Offutt (2000), Using UML colloboration diagrams for Static Checking and Test Generation, USA.
5. Brian Marick (2009), When Should a Test Be Automated, StickyMinds.com. Retrieved 2009-08-20.
6. Douglas Hoffman (1999), Test Automation Architectures: Planning for Test Automation, Software Quality Methods, LLC.
7. Elfriede Dustin (1999), Automated Software Testing, Addison Wesley, 1999, ISBN