1 Test case 1 1 Một số kỹ thuật thiết kế test case Để giảm thiểu số trường hợp đến mức tối ưu mà vẫn đảm bảo chất lượng website, mỗi thành viên trong nhóm dự án cần linh hoạt trong việc lựa chọn các k[.]
1 Test case 1.1 Một số kỹ thuật thiết kế test case Để giảm thiểu số trường hợp đến mức tối ưu mà đảm bảo chất lượng website, thành viên nhóm dự án cần linh hoạt việc lựa chọn kỹ thuật thiết kế test case Dưới nhóm dự án xin trình bày số kỹ thuật thiết kế test case sau: 1.1.2 Kỹ thuật phân lớp tương đương (Equivalence Partitioning) a Đặc điểm: ● Đây phương pháp kiểm thử chia miền đầu vào chương trình thành lớp liệu tương đương ● Tất giá trị vùng tương đương cho kết đầu giống ● Có thể test giá trị đại diện vùng tương đương b Ví dụ ● Kiểm thử form cập nhập thông tin người dùng bao gồm: ○ Username ô text ○ Email định dạng email ○ Bio text ○ Wallet address định dạng text ● Yêu cầu: ○ Thiết kế test case cho người dùng nhập user vào text cho nhập số ký tự chữ với độ dài khoảng [6 – 20] ● Phân tích ca kiểm thử sau: ○ Nếu nhập giá trị với số ký tự không nằm khoảng [6-20] ⇒ hiển thị lỗi “Bạn phép nhập chuỗi từ đến 20 ký tự” ● Dựa vào u cầu tốn ta có lớp tương đương (phân vùng) sau: ○ Phân vùng 1: Nhập giá trị hợp lệ từ đến 20 kí tự ○ Phân vùng 2: Nhập giá trị khơng hợp lệ < ký tự ○ Phân vùng 3: Nhập giá trị không hợp lệ > 20 ký tự ● Sau áp dụng phân vùng tương đương chọn ca kiểm thử (test case) sau: ○ Case 1: Nhập giá trị từ đến 20 ký tự ⇒ pass ○ Case 2: Nhập giá trị < ký tự (có thể chọn nhập 1, 2, 3, ký tự) ⇒ hiển thị lỗi “Bạn phép nhập chuỗi từ => 20 ký tự” ○ Case 3: Nhập giá trị > 20 ký tự (có thể chọn nhập 21, 22, 23,… ký tự) ⇒ hiển thị lỗi “Bạn phép nhập chuỗi từ => 20 ký tự” c Đánh giá Ưu điểm Nhược điểm Vì vùng tương đương ta cần test phần tử đại diện nên số lượng test case giảm nhiều nhờ mà thời gian thực test giảm đáng kể Khơng phải với tốn áp dụng kỹ thuật Có thể bị lack lỗi biên chọn giá trị khoảng miền tương đương Vì việc kết hợp linh hoạt kỹ thuật phân vùng tương đương phân tích giá trị biên mang lại hiệu cao để vừa tối ưu số lượng test case đảm bảo đươc chất lượng website 1.1.3 Kỹ thuật phân tích giá trị biên (Boundary-value Analysis) a Đặc điểm ● Một phương pháp có điều kiện biên giá trị đầu vào cho ca kiểm thử ● Là trường hợp đặc biệt phân lớp tương đương, dựa phân vùng tương đương tester xác định giá trị biên phân vùng lựa chọn test case phù hợp ● Phương pháp bổ sung ca kiểm thử cho phương pháp phân lớp tương đương Một số quy tắc xác định ca kiểm thử là: ○ Giá trị nhỏ ○ Giá trị gần kề lớn giá trị nhỏ ○ Giá trị bình thường ○ Giá trị gần kề bé giá trị lớn ○ Giá trị biên lớn b Ví dụ ● Như ví dụ trên, textbox username cho phép nhập từ [6,20] ký tự” ● Thiết kế trường hợp kiểm thử theo phương pháp là: ○ Số lượng ký tự nhỏ nhất: ○ Số lượng ký tự gần kề lớn Số lượng ký tự nhỏ nhất: ○ Số lượng ký tự bình thường: 13 ○ Số lượng ký tự gần kề bé giá trị lớn nhất: 19 ○ Số lượng ký tự biên lớn nhất: 20 c Đánh giá Ưu điểm Nhược điểm Thay phải test hết tồn giá trị vùng tương đương, kỹ thuật phân tích giá trị biên tập trung vào việc kiểm thử giá trị biên miền giá trị inputs để thiết kế test case “lỗi thường tiềm ẩn ngõ ngách tập hợp biên” Tiết kiệm thời gian thiết kế test case thực test Phương pháp hiệu trường hợp đối số đầu vào (input variables) độc lập với đối số có miền giá trị hữu hạn 1.1.3 Kỹ thuật sử dụng bảng định (Decision Table Testing) a Tổng quan ● Kỹ thuật phân tích giá trị biên kỹ thuật phân vùng tương đương kỹ thuật sử dụng hệ thống hiển thị kết đầu tập hợp lớn input đầu vào Tuy nhiên, hệ thống với giá trị đầu vào khác nhau, kết đầu hệ thống khác kỹ thuật giá trị biên phân vùng tương đương không hiệu việc đảm bảo phạm vi test ● Trong trường hợp này, bảng định lựa chọn tốt Vì kỹ thuật đảm bảo độ bao phủ test case với cách trình bày đơn giản dễ sử dụng b Đặc điểm ● Là kỹ thuật test sử dụng để kiểm tra hành vi hệ thống (system behavior) với cách kết hợp input đầu vào khác ● Là cách tiếp cận có hệ thống, kết kết hợp hành vi hệ thống tương ứng chúng (output) ghi lại dạng bảng ● Số lượng cột trường hợp bảng tính cơng thức 2^n Trong n số lượng input đầu vào c Ví dụ: Tạo bảng định cho form upload hình ảnh sau: ● ● ● Điều kiện upload thành cơng là: ○ Hình ảnh phải có định dạng JPG ○ Kích thước file hình ảnh từ 200kb trở xuống ○ Độ phân giải: HD (1280 x 720 pixels) Nếu có điều kiện khơng thỏa việc upload ảnh không thành công hệ thống gửi thông báo tương ứng đến người dùng Ngược lại hình upload thành cơng Từ u cầu có bảng định cho form upload ảnh sau: Điều kiện Test case Test Case Test Case Test Case Test case Định dạng jpg jpg jpg jpg Không Không Không Không phải jpg phải jpg phải jpg phải jpg Kích thước < 200 Kb < 200 Kb >= 200 Kb >= 200 Kb < 200 Kb < 200 Kb >= 200 Kb >= 200 Kb Độ phân HD giải Không phải HD HD Không phải HD HD Không phải HD HD Không phải HD Kết Thông báo lỗi "Độ phân giải Thơng báo lỗi "Kích thước chưa Thơng báo lỗi "Kích thước Độ Thơng báo lỗi "Định dạng chưa Thông báo lỗi "Định dạng Độ phân Thơng báo lỗi "Định dạng Kích Thơng báo lỗi "Định dạng, Kích Upload ảnh thành cơng Test Case Test case Test Case chưa đúng" đúng" phân giải chưa đúng" đúng" giải chưa đúng" thước chưa đúng" thước Độ phân giải chưa đúng" C Đánh giá Ưu điểm Nhược điểm Dễ dàng xây dựng chuyển đổi thành quy tắc Có thể sử dụng trình tạo test case test kiểm tra logic hệ thống dựa knowledge-based hệ thống Dựa vào bảng định phát số case test mà xây dựng test case theo cách thông thường tester dễ bị thiếu Được dùng làm tài liệu làm việc với stakeholders - bên liên quan thành viên nontechnical team dự án bảng định trình bày, minh họa vấn đề dạng bảng giúp cho người dễ hiểu Khi số lượng input đầu vào tăng bảng định trở nên phức tạp Khơng có bước chi tiết step by step để thực test 1.1.4 Đoán lỗi (Error Guessing) a Đặc điểm: ● Là phương pháp dựa đoán trực giác kinh nghiệm, tester viết danh sách loại lỗi hay trường hợp dễ xảy lỗi sau viết ca kiểm thử dựa danh sách ● Đây phương pháp bổ sung ca kiểm thử cho phương pháp dựa vào kinh nghiệm tester Đối phương pháp này, khơng có quy trình cụ thể để áp dụng, chủ yếu phụ thuộc vào kinh nghiệm kiểm thử tester b Các ví dụ: ● Sau upload ảnh, thử reload trang xem ảnh xem ảnh có thực upload hay khơng? ● Kiểm tra lỗi chia cho ● Nhập username khoảng trắng ● Để trống giá trị submit số form ● Nhập ký tự dài vào ô textbox ● Nhập ký tự đặc biệt vào ô textbox c Đánh giá Ưu điểm Nhược điểm Sử dụng phương pháp giúp tester tìm lỗi điển hình thường xảy phần mềm lỗi khơng thể tìm thấy thiết kế test case theo hình thức formal Kỹ thuật thường thực Tester có kinh nghiệm khơng theo quy tắc định, thiết kế test case dựa nhiều vào cảm tính 1.2 Minh họa số test case 1.2.1 Test case 1: Kiểm tra hệ thống đăng nhập Tên dự án: Xây dựng website giao dịch NFT Tiêu đề: Kiểm tra hệ thống đăng nhập Mã test case: TC001 Độ ưu tiên: Cao Người viết test case: Trần Linh Đa Ngày viết test case: 01/12/2022 Người thực thi kiểm thử: Lê Hữu Huy Ngày kiểm thử: 02/12/2022 Mơ tả Kiểm tra để đảm bảo đăng nhập với username token kết nối ví điện tử hợp lệ Tiền điều kiện Người dùng có tên đăng nhập hợp lệ Trình duyệt có cài đặt ví điện tử Trạng thái hệ thống sau chạy trường hợp thử nghiệm Chuyển đến giao diện trang chủ ứng với vai trò người dùng hệ thống báo lỗi Kỹ thuật sử dụng Bảng định ● ● ● Điều kiện đăng nhập thành công: ○ Người dùng nhập username hợp lệ ○ Có API trả kết nối ví điện tử thành cơng Nếu có điều kiện khơng thỏa việc đăng nhập không thành công hệ thống gửi thông báo username khơng hợp lệ kết nối ví điện tử thất bại đến người dùng Ngược lại, hệ thống hiển thị giao diện ứng với vai trò người dùng Từ yêu cầu có bảng định cho form đăng nhập sau: Điều kiện Trường hợp Trường hợp Trường hợp Trường hợp Username Hợp lệ Hợp lệ Không hợp lệ Không hợp lệ Mã trạng thái API trả (khi kết nối với ví Thành cơng Thất bại Thành công Thất bại điện tử) Kết ● Hiển thị trang chủ Hiển thị lỗi Hiển thị lỗi Hiển thị lỗi Ta có testcase cho trường hợp sau: Trường hợp Trường hợp (dữ liệu hợp lệ) Trường hợp Trường hợp Trường hợp Bộ liệu kiểm thử Loại liệu Bộ liệu (User) Username ‘linhdatran’ Mã trạng thái API trả (khi kết nối với ví điện tử) 200 Username ‘lehuuhuy’ Mã trạng thái API trả (khi kết nối với ví điện tử) 401 Username NULL Mã trạng thái API trả (khi kết nối với ví điện tử) 200 Username NULL Mã trạng thái API trả (khi kết nối với ví điện tử) 401 Báo cáo kết kiểm thử Trường hợp Kết mong đợi Kết thực tế Trạng thái Trường hợp (dữ liệu hợp lệ) Hiển thị thông báo thành công chuyển qua form trang chủ Kết mong đợi Pass Trường hợp Hiển thị thông báo lỗi Kết mong đợi Pass Trường hợp Hiển thị thông báo lỗi Kết mong đợi Pass Trường hợp Hiển thị thông báo lỗi Kết mong đợi Pass 1.2.2 Test case 2: Kiểm tra chức tạo NFT Tên dự án: Xây dựng website giao dịch NFT Tiêu đề: Kiểm tra chức tạo NFT Mã test case: TC001 Độ ưu tiên: Cao Người viết test case: Trần Linh Đa Ngày viết test case: 01/12/2022 Người thực thi kiểm thử: Lê Hữu Huy Ngày kiểm thử: 02/12/2022 Mô tả Kiểm tra đảm bảo chức chạy quy trình Tiền điều kiện Người dùng đăng nhập hệ thống Đã tạo gian hàng Trạng thái hệ thống sau chạy trường hợp thử nghiệm Màn hình thơng báo tạo thành công NFT hiển thị gian hàng Kỹ thuật sử dụng Bảng định Các hoạt động thử nghiệm STT Mô tả bước Kết mong đợi Kết thực tế Trạng thái Nhập thông tin: “Upload” hình ảnh, nhập tên, nhập giá NFT Hiển thị hình ảnh Như mong đợi NFT lỗi tồn Nhấn vào nút “create” Hệ thống thực lưu NFT vào sở liệu cập nhập vào gian hàng Hệ thống thực Thành cơng theo trình tự quy định Vào gian hàng Thấy sản phẩm Hệ thống phát Thành công Thất bại kiểm tra hiển thị gian hàng sinh lỗi khơng tìm NFT vừa tạo Bộ liệu kiểm thử Loại liệu Bộ liệu Bộ liệu Image-NFT bear.jpg cow.jpg Name Bear with knife Cow and tree Price 4.5 9.24 Kết kiểm thử Fail Fail ... test case dựa nhiều vào cảm tính 1. 2 Minh họa số test case 1. 2 .1 Test case 1: Kiểm tra hệ thống đăng nhập Tên dự án: Xây dựng website giao dịch NFT Tiêu đề: Kiểm tra hệ thống đăng nhập Mã test case: ... upload thành cơng Từ yêu cầu có bảng định cho form upload ảnh sau: Điều kiện Test case Test Case Test Case Test Case Test case Định dạng jpg jpg jpg jpg Không Không Không Không phải jpg phải jpg... thể sử dụng trình tạo test case test kiểm tra logic hệ thống dựa knowledge-based hệ thống Dựa vào bảng định phát số case test mà xây dựng test case theo cách thông thường tester dễ bị thiếu Được