Các Kỹ Thuật Thiết Kế Testcase Cơ Bản

1/ Kỹ Thuật Phân Lớp Tương Đương

2/ Kỹ Thuật Phân Tích Giá Trị Biên

3/ Kỹ Thuật Điều Kiện Ràng Buộc

4/ Kỹ Thuật Thay Đổi Trạng Thái

5/ Kỹ Thuật Đoán Lỗi

6/ Kỹ Thuật Về UI (Look and Feel)

7/ Kỹ Thuật Phủ Định - Tiêu Cực

8/ Kỹ Thuật Độ Hài Lòng Người Dùng

Vòng Đời Phát Triển Phần Mềm (SDLC)

13 LOẠI LỖI PHẦN MỀM THƯỜNG GẶP

13 LOẠI LỖI PHẦN MỀM THƯỜNG GẶP:

- User Interface: UI (giao diện)

- Error Handling: Xử lý lỗi (Thông báo lỗi không đầy đủ, rõ ràng/ Thông báo sai) => Dựa vào requirement để so sánh.

- Boundary - Related: Giá trị biên.

- Calculator: Tính toán.

- Initial and Later States: Giá trị khởi tạo và giá trị sau khi thực hiện xử lý.

- Control Flow: Luồng xử lý (VD: bị gián đoạn 1 giai đoạn nào đó).

- Handling or Interpreting Data: Import và Export dữ liệu.

- Race Condition: Trình tự của các xử lý (Trình tự xử lý không đúng).

- Load Condition: Quá tải.

- Hardware / Environment Compatibility: Phần cứng/ Phần mềm.

- Source, Version, ID control: Phiên bản (Update sai phiên bản).

- Testing: Lỗi do Tester.

- Documentation: Tài liệu.

Phân biệt giữa SEVERITY và PRIORITY

Một số định nghĩa trong testing.

Phương Pháp Testing - Test Type

Kỹ thuật thiết kế TESTCASE

Hiện tại có rất nhiều kỹ thuật thiết kế TESTCASE để việc viết testcase đạt được hiệu quả nhất định cũng như việc test đạt được hiệu quả không bị sót những case cơ bản.

Tuy nhiên, trong phạm vi bài này mình sẽ giới thiệu cách thiết kế testcase cơ bản nhất để mọi người có thể hiểu được một cách gọn gàng nhất có thể 😏

1 - Giá trị vùng tương đương

Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương.

Ví dụ:

Form Login gồm có:

User: Text-box

PassWord: Text-box

Yêu cầu:

Thiết kế test case sao cho người dùng nhập vào ô text-box user chỉ cho nhập ký tự chữ với độ dài trong khoảng [6-20]

Nếu nhập giá trị với số ký tự không nằm trong khoảng [6-20] => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6 => 20 ký tự”

Nếu để trống ô hoặc nhập ký tự khác ký tự chữ => hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ”

Sau khi áp dụng phân vùng tương đương, mình sẽ có các testcase sau:

+ Case 1: Nhập giá trị từ 6 => 20 => pass

+ Case 2: Nhập giá trị < 6 ký tự (có thể chọn nhập 1, 2, 3, 4 hoặc 5 ký tự) => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6 => 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 chỉ được phép nhập chuỗi từ 6 => 20 ký tự”

+ Case 4: Để trống không nhập gì hay nhập ký tự không phải dạng chữ => hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ”

2 - Giá trị biên

Hầu hết các lỗi được tìm thấy khi kiểm tra ở các giá trị biên. Vì vậy phương pháp này tập trung vào việc kiểm thử các giá trị biên này.

Phân tích giá trị biên là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng tương đương tester sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn test case phù hợp.

- Áp dụng kỹ thuật phân tích giá trị biên (ví dụ trên) ta chọn được các case sau:

+ Case 1: Nhập giá trị với 5 ký tự => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6 => 20 ký tự”

+ Case 2: Nhập giá trị với 6 ký tự => pass

+ Case 3: Nhập giá trị với 20 ký tự => pass

+ Case 4: Nhập giá trị với 21 ký tự => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6 => 20 ký tự”

+ Case 5: Để trống không nhập gì hay nhập ký tự không phải dạng chữ => hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ

3 - Giá trị ràng buộc

Trong trường hợp này, chúng ta sẽ xét trong ví dụ về thời gian giữa 2 form:

Form: Ngày bắt đầu
Form: Ngày kết thúc

Áp dụng kỹ thuật phân tích giá trị ràng buộc thì ta được các case sau:

+ Case 1: Nhập ngày bắt đầu < Ngày kết thúc => pass

+ Case 2: Nhập ngày bắt đầu = Ngày kết thúc => pass (tùy theo yêu cầu)

+ Case 3: Nhập ngày bắt đầu > Ngày kết thúc => Báo lỗi

4 - Trạng thái khi thay đổi

Trong trường hợp này, mình sẽ xét trong ví dụ chuyển trang or các nút next, previous. Và so sánh các tiêu chí xuất hiện hoặc thay đổi từ trang này qua trang khác nó như thế nào và so sánh lại với document để quyết định đó có thể là bug or not.

5 bước xác định khi log BUGs

What

-Bug này là bug gì,độ nghiêm trọng của nó như thế nào?

Where

-Xác định lỗi ở đâu,trên môi trường nào
(web thì browser nào,app thì trên hệ điều hành nào)

When

-Bug xảy ra khi nào
(nghĩa là thực hiện những bước nào thì xảy ra Bug)

How

-Hướng sửa Bug đó như thế nào? (expected result)

Who

-Bug do code của ai gây ra

Cách kiểm tra lỗi cơ bản của app trên thiết bị di động

Một số kinh nghiệm:

-Đăng nhập bằng nhiều account trên 1 thiết bị điện thoại sẽ bị trùng lặp thông báo, action, catches…


-Confirm bug bằng cách load hoặc refresh data sau khi đã thực hiện các steps trong reproduce bug (bug về con số, total)

-Kiểm tra giao diện có chế độ xoay màn hình hay ko ?


-Lay out, lỗi chính tả, định dạng chữ…


-Kiểm theo từng màn hình (nguyên tắc: từ trên xuống dưới, từ trái qua phải)


-Pop-up Allow access to library… When tắt permissionở app trên device thì khi access to libraryphải display thông báo Allow or Deny


-Function logic theo suy đoán


-Chú ý timezone khi tạo sự kiện.


-Lặp lại action đó lần 2 xem có lỗi hay ko ?