Kỹ thuật dùng bảng quyết định

6. Giả thuyết khoa học

2.2.3 Kỹ thuật dùng bảng quyết định

Bảng quyết định là 1 công cụ rất hữu ích để đặc tả các yêu cầu phần mềm hoặc để đặc tả bảng thiết kế hệ thống phần mềm. Nó miêu tả các quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dưới dạng dễ đọc và dễ kiểm soát:

Trường hợp kiểm định (testcase) Rule 1 Rule 2 ……….. Rule p Conditions Điều kiện 1

(Điều kiện) ….. Điều kiện m Actions (Hoạt động) Hoạt động 1 ….. Hoạt động n

Bảng quyết định được sử dụng trong trường hợp hành động được lựa chọn phù hợp với lượng lớn các điều kiện.

“Điều kiện 1” tới “Điều kiện m” miêu tả m điều kiện dữ liệu nhập khác nhau có thể có. “Hoạt động1” tới “Hoạt động n” miêu tả n hoạt động khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp điều kiện dữ liệu nhập nào. Mỗi cột miêu tả 1 luật cụ thể: Tổ hợp điều kiện nhập cụ thể và các hoạt động cụ thể cần thực hiện.

Lưu ý các hoạt động cần thực hiện không phụ thuộc vào thứ tự các điều kiện nhập, nó chỉ phụ thuộc vào giá trị các điều kiện nhập.

Tương tự, các hoạt động cần thực hiện không phụ thuộc vào trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào các điều kiện nhập đã có trước đó.

Chúng ta sẽ lấy một số thí dụ cụ thể để làm rõ bảng quyết định.

Thí dụ 1:

Giả sử TPPM cần kiểm định là phân hệ chức năng nhỏ của công ty bảo hiểm: nó sẽ khuyến mãi cho những chủ xe (cũng là tài xế) nếu họ thỏa mãn ít nhất 1 trong 2 điều kiện: Đã lập gia đình / Là sinh viên giỏi.

Test case

1 2 3 4

Sinh viên giỏi Yes No Yes No

Hoạt động Khuyến mại ($) 60 25 50 0

Quy trình cụ thể để thực hiện kiểm định dùng bảng quyết định:

1. Tìm bảng quyết định từ đặc tả về yêu cầu chức năng của TPPM hay từ bảng thiết kế TPPM. Nếu chưa có thì xây dựng nó dựa vào đặc tả về yêu cầu chức năng hay dựa vào bảng thiết kế TPPM.

2. Từ bảng quyết định chuyển thành bảng các testcase trong đó mỗi cột miêu tả 1 luật được chuyển thành 1 đến n cột miêu tả các testcase tương ứng với luật đó:

Nếu điều kiện nhập là trị luận lý thì mỗi cột luật được chuyển thành 1 cột testcase.

Nếu điều kiện nhập là 1 lớp tương đương (nhiều giá trị liên tục) thì mỗi cột luật được chuyển thành nhiều testcase dựa trên kỹ thuật lớp tương đương hay kỹ thuật giá trị biên.

Ta có thể xây dựng bảng quyết định theo trình tự như sau: - Xác định tất cả các điều kiện

- Xác định tất cả các hành động - Tính số kết hợp giữa các điều kiện - Điền các kết hợp (rule) vào bảng

- Loại bỏ các kết quả không cần thiết (hợp xung đột hoặc dư thừa) - Điền các hành động (action) vào bảng tương ứng với các kết hợp Bảng quyết định có nhiều loại, trong đó phổ biến và đơn giản nhất là bảng quyết định giới hạn (Limited Entry Table). Với bảng quyết định loại này, điều kiện (condition) được thỏa mãn một cách đầy đủ và hành động

(action) được thực hiện một cách trọn vẹn. Có thể dùng các ký hiệu sau đây để mô tả trong bảng quyết định:

“Y” : Điều kiện thỏa mãn

“N” :Điều kiện không thỏa mãn

“-” : Điều kiện hoặc hành động không áp dụng “X” : Hành động được thực hiện

Thí dụ 2:

Ngân hàng sử dụng các nguyên tắc sau đây để phân loại tài khoản ngân hàng mới mở:

- Nếu người gởi tiền có tuổi >=21 và số tiền gởi >=100 thì đó là TK loại A

- Nếu người gởi tiền có tuổi <21 số tiền gởi >=100 thì đó là TK loại B - Nếu người gởi tiền có tuổi >=21 và số tiền gởi <100 thì đó là TK loại C - Nếu người gởi tiền có tuổi <21 số tiền gởi <100 thì không mở tài khoản

Để giải quyết bài toán này, ta xây dựng bảng quyết định như sau: Xác định các điều kiện: Có 2 điều kiện

C1: Tuổi >= 21

C2: Số tiền gửi >= 100 Xác định hành động:

- Phân loại các tài khoản mới mở là A,B,C hoặc không mở TK

Xác định các kết hợp (Rules): Có 2 điều kiện và mỗi điều kiện có 2 giá trị (Y/N) nên có tất cả là 4 kết hợp.

Ta có bảng quyết định như sau:

Test case

1 2 3 4

ĐIỀU KIỆN Tuổi >= 21 Y Y N N

KẾT QUẢ

Tài khoản loại A X

Tài khoản loại B X

Tài khoản loại C X

Không mở tài khoản X

Thí dụ 3:

Giả sử yêu cầu bài toán như sau:

Nếu bạn có thẻ đường sắt "Over 60s" thì được giảm giá 34% trên tất cả các vé bạn mua. Nếu bạn “Đi cùng với trẻ em dưới 16 tuổi" thì bạn sẽ được giảm 50% nếu bạn có thẻ "Family Rail Card", ngược lại bạn sẽ được giảm 10%. Bạn chỉ được sử dụng 1 loại thẻ đường sắt.

Hãy viết bảng quyết định liệt kê toàn bộ các kết hợp loại thẻ và kết quả giảm giá. Và viết test case từ bảng quyết định này.

Ta sẽ có bảng quyết định như sau:

Trường hợp kiểm thử

1 2 3 4 5 6 7 8

ĐIỀU KIỆN

Có thẻ Over 60s Y Y Y Y N N N N

Đi cùng trẻ em dưới 16 tuổi Y Y N N Y Y N N Có thẻ Family Rail Card Y N Y N Y N Y N

KẾT QUẢ

Giảm 34% X X X

Giảm 50% X X

Giảm 15% X

Gộp các kết quả giống nhau ta được:

Trường hợp kiểm thử

1 2 3 4 5 6

ĐIỀU KIỆN

Có thẻ Over 60s Y Y Y N N N

Đi cùng trẻ em dưới 16 tuổi Y Y N Y Y N

Có thẻ Family Rail Card Y N - Y N -

KẾT QUẢ Giảm 34% X X Giảm 50% X X Giảm 15% X

Không được giảm X

Sau khi làm xong bảng quyết định thì dựa vào đó ta có thể viết test case, mỗi rule là 1 test case:

1. Có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => được giảm 50%

2. Có thẻ Over 60s và không có thể Family Rail Card và đi cùng trẻ em => được giảm 34%

3. Có thẻ Over 60s và không đi cùng trẻ em => được giảm 34%

4. Không có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => được giảm 50%

5. Không có thẻ Over 60s và không có thẻ Family Rail Card và đi cùng trẻ em => được giảm 15%

6. Không có thẻ Over 60s và không đi cùng trẻ em => không được giảm

CHƯƠNG 3. ÁP DỤNG KỸ THUẬT KIỂM ĐỊNH HỘP ĐEN

3.1 Mô tả yêu cầu bài toán

Xây dựng kịch bản kiểm thử theo phương pháp hộp đen cho giao diện và chức năng của ứng dụng quản lý danh bạ điện thoại dựa trên việc đưa ra các test cases.

Phạm vi và đối tượng của bài toán sẽ tập trung vào giúp cho người phát triển phần mềm dễ dàng trong việc thao tác, kiểm tra từng phần hoặc toàn bộ cấu trúc chương trình.

Ngoài ra còn giúp cho người sử dụng tránh được các lỗi liên quan tới việc sử dụng các chức năng mà phần mềm cung cấp, giúp tránh những phiền toái và nâng cao hiệu quả trong công việc.

3.2 Giải pháp giải quyết bài toán

Mô hình giải quyết vấn đề được mô tả tại hình 3.1 với các tính năng cụ thể như sau.

Phần đầu vào của chương trình sẽ là một ứng dụng quản lý danh bạ điện thoại với tập hợp các dữ liệu là thông tin liên lạc có trong danh bạ. Dựa trên những đặc tả ban đầu và giao diện của phần mềm, từ đó xây dựng một bảng các liên kết chi tiết các trạng thái sẽ xảy ra đối với từng chức năng, và sẽ được coi đó là đầu vào cho một ca kiểm thử cụ thể của chức năng đó.

Trong phần kết quả, đưa ra các chức năng của ứng dụng đã được kiểm định thông qua báo cáo cụ thể. Phần kết quả sẽ chỉ ra được các trường hợp kiểm thử và kết quả đạt được của ca kiểm thử.

ng ng u n danh - p c ca m c t kê i ng Excel - c thi c ca m t u m - Ghi ra p Excel - p i n nh m t u u o u ra t c

Hình 3.1 Mô hình giải quyết bài toán

3.2.1 Đầu vào cho ứng dụng kiểm định

Đầu vào kiểm định là chương trình quản lý danh bạ điện thoại sử dụng ngôn ngữ C#. Giao diện cho người dùng gồm có:

- Dialog [Danh bạ]: Trên Dialog [Danh bạ] có thanh tìm kiếm giúp người dùng có thể tìm kiếm thông tin danh bạ có trong danh sách hiện có. Chức năng tìm kiếm có thể tìm kiếm theo tên và tìm kiếm theo số điện thoại của danh bạ.

Hình 3.2 Màn hình tìm kiếm theo tên Hình 3.3 Màn hình tìm kiếm theo số + Mục thêm mới cho phép người dùng thêm mới một liên lạc vào

danh bạ.

+ Tiếp theo là danh sách liên lạc được sắp xếp theo thứ tự a, b, c… + Cuối cùng là hiển thị tổng số liên lạc có trong danh bạ.

- Dialog [Thông tin liên lạc]: Hiển thị thông tin chi tiết một liên lạc có trong danh bạ gồm có các trường:

+ Họ + Tên + Công ty + Số điện thoại + Email + Ngày sinh.

Hình 3.4 Màn hình danh bạ Hình 3.5 Màn hình thông tin liên lạc - Dialog [Sửa thông tin liên lạc]: Hiển thị các thông tin giống như trong - Dialog [Thông tin liên lạc] nhưng cho phép người dùng có thể thực hiện:

+ Sửa đổi thông tin trong các trường

+ Nút [Xóa liên hệ] để xóa bỏ thông tin liên lạc hiện tại ra khỏi danh sách.

+ Nút [Xong] để cho phép lưu thông tin đã sửa chữa và cập nhật danh sách danh bạ.

+ Nút [Hủy] để hủy bỏ việc sửa thông tin và không cập nhật danh sách danh bạ.

Hình 3.6

Màn hình thêm thông tin liên lạc

Hình 3.7

Màn hình xóa thông tin liên lạc - Dialog [Liên hệ mới]: Cho phép người dùng tạo thêm liên hệ vào danh sách liên lạc, trong đó gồm các trường:

Họ; Tên; Công ty; Số điện thoại; Email; Ngày sinh.

Nút [Xong]: Cho phép nhập liên hệ mới cà cập nhật vào danh sách liên lạc.

Nút [Hủy]: Hủy bỏ việc thêm mới vào danh sách.

Đầu vào kiểm thử là sẽ là giao diện người sử dụng của phần mềm như mô tả ở trên và luồng nghiệp vụ cho các chức năng phần mềm thực hiện qua giao diện như trong hình 3.8 đảm bảo các chức năng được thực hiện đúng.

Danh m m

Liên i

Thông tin liên c

Danh ch liên c Tên Công ty n i Email Danh ch liên c Nhan : Anh ( )... Tên: Van A : Nguyen Công ty: XYZ n i: Email: nguyenvana@gmail.com y sinh: ơ ua : Danh ch liên c Nhan : Anh ( )... Tên: Van A : Nguyen Công ty: XYZ n i: Email: nguyenvana@gmail.com y sinh: ơ ua : Danh ch liên c y Xong i liên a y Xong n p a i ng liên c a liên + Thêm i

Hình 3.8 Giao diện liên kết các màn hình của chương trình.

3.2.2 Kiểm định giao diện người sử dụng (User Interface Testing)

Kiểm định giao diện người sử dụng (UI) kiểm tra các tương tác của người dùng với phần mềm. Mục tiêu của kiểm định UI là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sử dụng thích hợp thông qua các chức năng trong mục tiêu kiểm định. Ngoài ra, kiểm định UI còn để đảm bảo rằng các đối tượng trong phạm vi chức năng UI

giống như mong đợi và phù hợp yêu cầu thẩm mỹ.

Mục đích kiểm định:

Kiểm tra:

Việc sử dụng thông qua mục tiêu kiểm định phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình, trường đến trường và sử dụng các phương pháp truy cập (phím tabs, di chuột, tổ hợp phím)

Các đối tượng và thuộc tính màn hình như menus, size, position, state, và tập trung vào việc tương thích với chuẩn.

Cách thực hiện:

Tạo ra và chỉnh sửa kịch bản kiểm định cho mỗi màn hình để kiểm tra việc sử dụng đúng cách và tình trạng các đối tượng cho mỗi màn hình và đối tượng của ứng dụng

Điều kiện hoàn thành:

Mỗi màn hình được kiểm tra thành công đúng với phiên bản kiểm tra hoặc phạm vi chấp nhận được

Các vấn đề đặc biệt:

Không phải toàn bộ các thuộc tính của các đối tượng đều truy cập được

Test case giao diện gồm hai phần chính

Testcase giao diện chung: hiển thị màn hình ở trạng thái khởi tạo, kiểm tra tab, shift+ tab order, …

Testcase kiểm tra validate cho từng control riêng rẽ trên màn hình: viết cho từng control một. Khi viết test case cho các control, người kiểm định sẽ viết hết testcase kiểm tra định dạng cho control này rồi mới chuyển sang testcase cho control tiếp theo theo thứ tự từ trái sang phải, từ trên xuống dưới.

Mã test case

Mục đích kiểm

định Các bước thực hiện Kết quả mong muốn

Test case cho Dialog [Liên hệ mới]

TC_1 Kiểm tra giao diện

dialog [Liên hệ mới]

1. Tại màn hình [Danh bạ]

2. Click nút [Thêm mới]

2. Hiển thị dialog [Liên hệ mới]:

- Các trường dữ liệu: Họ: Textbox Tên: Textbox Điện thoại: Textbox Công ty: Textbox Email: Textbox Ngày sinh:

- Các button: Hủy, Xong

TC_2 Kiểm tra thứ tự di

chuyển trỏ trên màn hình khi nhấn phím Tab hoặc Shift+Tab

1. Tại dialog [Thêm mới]

2. Nhấn phím Tab liên tục

2. Con trỏ di chuyển lần lượt theo thứ tự: Từ trái qua phải và từ trên xuống dưới.

Tiếp tục xây dựng Test casecho cho các Dialog khác…

3.2.3 Kiểm định luồng nghiệp vụ (Business Flow Testing)

Mục đích của kiểm định luồng nghiệp vụ là tập trung vào các yêu cầu kiểm định có thể được lưu vết trực tiếp trong các chức năng và quy tắc nghiệp vụ.

Mục tiêu của kiểu kiểm định này là kiểm tra tính đúng đắn của các dữ liệu, quy trình và báo cáo cũng như việc thực hiện đúng những quy tắc nghiệp vụ. Tức là kiểm tra ứng dụng và các xử lý nội tại bằng cách tương tác với ứng dụng thông qua giao diện người sử dụng và phân tích các kết quả hoặc đầu ra.

Mục đích kiểm định:

Đảm bảo mục tiêu kiểm định đúng đắn của chức năng, bao gồm định hướng, dữ liệu đầu vào, xử lý và dữ liệu nhận được.

Kiểm định chức năng đảm bảo các yêu cầu sau: - Nhập dữ liệu hợp lệ thì chương trình phải cho nhập - Luồng nghiệp vụ đúng

- Quá trình xử lý dữ liệu và kết quả đầu ra phải đúng

Cách thực hiện:

Thực hiện các chức năng, sử dụng các dữ liệu hợp lệ và không hợp lệ để kiểm tra. Cụ thể như sau:

- Kết quả mong đợi với dữ liệu hợp lệ.

- Lỗi thích hợp hoặc thông báo hiển thị khi dữ liệu không hợp lệ.

- Mỗi quy tắc nghiệp vụ đều được áp dụng đúng

Điều kiện hoàn thành:

- Toàn bộ kế hoạch kiểm định đã được thực hiện. - Toàn bộ các lỗi phát hiện ra đã được ghi nhận.

Các vấn đề đặc biệt:

Xác định hoặc mô tả các vấn đề (nội bộ hoặc bên ngoài) ảnh hưởng đến việc kiểm định chức năng

Testcase cho phần chức năng gồm testcase cho các nội dung sau: - Kiểm tra giá trị trong các trường nhập.

- Kiểm tra ràng buộc giữa các liên kết trong phần mềm (có sự truy vấn dữ liệu trong cơ sở dữ liệu để kiểm tra).

- Kiểm tra các màn hình trung gian để thực hiện chức năng chính: ví dụ để thực hiện chức năng phải có màn hình popup.

- Các ràng buộc tuân thủ theo nghiệp vụ: Thí dụ trong màn hình [Liên hệ mới] khi ta nhập đủ các trường thì phần mềm cho thêm danh bạ vào danh

sách; Nhưng nếu không nhập trường nào mà lưu lại thì sẽ có thông báo là “chưa nhập tên”, …

- Các test case trong luồng nghiệp vụ:

+ Thứ tự sắp xếp các test case phải theo thứ tự tương ứng trên luồng trong tài liệu đặc tả yêu cầu: kiểm tra các luồng sự kiện phụ trước, cuối cùng là sự kiện chính.

+ Đối với test case chức năng ta có thể viết theo hai cách.

 Cách 1: các bước thực hiện chỉ mô tả các bước thực hiện đứng từ phía người dùng cuối bao gồm nhập dữ liệu, nhấn button. Việc kiểm tra dữ liệu trong cơ sở dữ liệu so với hiện thị trên màn hình