Lời mở đầu

Bug là một phần không thể thiếu trong quá trình phát triển gêm nói riêng và phần mềm nói chung. Dự án HOE (Hero of Empire) có những giai đoạn gặp rất nhiều bug, bug trước khi bàn giao cho phía gd/tester, bug trong quá trình review/test, bug sau khi merge vào nhánh chung,….

Anh em có đề xuất một yêu cầu là trước khi bàn giao cho các bên khác, anh em dev cần tự test lại kĩ hơn, nhưng kĩ hơn như thế nào thì rất mông lung và khó đo đếm.

Sau bao nhiêu ngày trăn trở, đêm fix bug, tôi chợt nhớ ra ngày trước đã từng học 1 khóa “Aglie toolkit for developer”, trong khóa học đó đó cũng đã có bài nói về vấn đề làm sao để test kĩ hơn bằng các phương pháp, nay tôi xin phép đọc lại và tổng kết cho anh em những thứ đã học được, mong rằng những thứ sau đây sẽ giúp ích cho anh em trong việc nâng cao chất lượng sản phẩm.

Sơ lược về các kĩ thuật test

Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó.

Các kĩ thuật phổ biến trong Blackbox testing như sau:

1. Kỹ thuật phân lớp tương đương (Equivalence Class Partitioning).
2. Kỹ thuật phân tích các giá trị biên (Boundary value analysis).
3. Kỹ thuật dùng các bảng quyết định (Decision Tables)
4. Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise)
5. Kỹ thuật dùng bảng chuyển trạng thái (State Transition)
6. Kỹ thật phân tích vùng miền (domain analysis)
7. Kỹ thuật dựa trên đặc tả Use Case (Use case)
8. Kỹ thuật dùng lược đồ quan hệ nhân quả (Cause-Effect Diagram)

Kiểm thử hộp trắng (While box test) là phương pháp thử nghiệm phần mềm, trong đó các thiết kế, cấu trúc giải thuật bên trong, và việc thực hiện các công việc đều được biết đến. Các kĩ thuật phổ biến trong Whitebox testing như sau:

1. Statement Coverage
2. Decision Coverage
3. Branch Coverage
4. Condition Coverage
5. Multiple Condition Coverage
6. Finite State Machine Coverage
7. Path Coverage
8. Control flow testing
9. Data flow testing

Qua sự chỉ bảo nhiệt tình của Tester Hạnh, bài viết này chỉ nêu ra một vài phương pháp dễ thực hiện nhất cho dev mà không bị chồng lấn vai trò giữa dev và tester. Nếu team nào anh em không có tester hoàn toàn có thể đọc và tìm hiểu kĩ về nghiệp vụ test, coi như 2 tay 2 súng luôn

Các kĩ thuật sinh test case

Một trong những flow Internal test thường thấy nhất mà các anh em (cũng như tôi) hay sử dụng là: 

Đọc GD document → code tính năng → test đi test lại hữu hạn lần → bàn giao cho bên khác.

Cách làm này tuy không có gì sai, nhưng nó không toàn diện, ở chỗ: khi chúng ta test đi test lại 1 trường hợp và đảm bảo nó không xảy ra lỗi, chúng ta không biết rằng còn bao nhiêu trường hợp khác có thể xảy ra lỗi.

Những kĩ thuật dưới đây sẽ giúp anh em sinh ra nhiều test case hơn từ các góc độ khác nhau, bằng cách tự test hết những test case này, anh em sẽ kiểm soát được mức độ rủi ro trước khi bàn giao cho bên test. 

1 – Sinh test case dựa vào use case

Kĩ thuật này đòi hỏi dev phải đứng ở vị trí người dùng, không biết gì về hệ thống, tất cả những gì người dùng cần là tính năng trong game phải đáp ứng được kì vọng.

Những tài liệu cần chuẩn bị cho kĩ thuật này: GD Document về tính năng 

Workflow như sau:

• Đọc GD Document
• Viết ra checklist những thứ mà người dùng có thể dùng
• Viết ra kì vọng của từng checklist item

Từ các yêu cầu kể trên, ta có thể tạo ra 1 list những usecase sau, coi mỗi usecase là 1 testcase

Case	Hành vi	Kì vọng
1	Bấm vào button đổi tên	Hiện lên popup đổi tên
2	Trong popup đổi tên, bấm nút x hoặc bấm ra ngoài	Popup tắt đi
3	Trong popup đổi tên, nếu bấm vào vùng dấu chấm,	Hiện ra bàn phím ảo để nhập tên
4	Nhập tên thành công	Bàn phím ảo tắt đi, ở vùng dấu chấm hiển thị tên vừa nhập
5	Nếu nhập tên thành công, nhưng tên không hợp lệ	Hiện ra thông báo yêu cầu nhập lại
6	Nếu tên hợp lệ, người chơi không đủ tiền để đổi tên, bấm vào nút có hiện chi phí đổi tên	Hiện popup hỏi vào shop để mua thêm
7	Nếu tên hợp lệ, người chơi đủ tiền để đổi tên, bấm vào nút có hiện chi phí đổi tên	Thông báo đổi tên thành công
8	Sau khi có thông báo đổi tên thành công, check profile	Hiển thị tên mới theo như tên vừa đổi ở bước bên trên
9	Sau khi đổi tên, thoát game vào lại, check profile	Hiển thị tên mới theo như tên vừa đổi ở bước bên trên

2 – Vùng tương đương

Cơ sở lí thuyết: 

Phân vùng lớp tương đương cho phép bạn phân chia tập hợp các điều kiện kiểm tra thành một phân vùng nên được coi là giống nhau.

Phương pháp kiểm thử phần mềm này chia miền đầu vào của chương trình thành các lớp dữ liệu mà từ đó các trường hợp kiểm thử nên được thiết kế.

Với các giá trị đầu vào chia thành các vùng tương đương:

• Vùng tương đương hợp lệ: tập hợp các giá trị kiểm thử thỏa mãn điều kiện của hệ thống
• Vùng tương đương không hợp lệ: Tập hợp các giá trị kiểm thử mô tả trạng thái khác của hệ thống: sai, thiếu, không đúng,…

Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện.

Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:

• Xác định các lớp tương đương
• Xác định các ca kiểm thử

Nguyên tắc:

• 1 lớp các giá trị lớn hơn
• 1 lớp các giá trị nhỏ hơn
• n lớp các giá trị hợp lệ

Áp dụng vào dự án:

Theo như mô tả trên hình, điều kiện đầu vào của tính năng đổi tên gồm 2 phần

Độ dài tên từ 3-13 kí tự

Các kí tự hợp lệ: a-z, A-Z, 0-9

Ta chia thành các phân vùng tương đương sau:

1. Nhập kí tự chữ hoặc số có độ dài từ 0-2, 
2. Nhập kí tự chữ hoặc số có độ dài từ 3-13
3. Nhập kí tự chữ hoặc số có độ dài >=13
4. Không nhập gì cả
5. Nhập kí tự đặc biệt

Mỗi phân vùng chỉ lấy 1 giá trị đại diện cho phân vùng đó, ta có bảng test case sau

Case	Chuỗi nhập vào	Kì vọng
1	a	Không có báo lỗi
2	#	Báo lỗi nhập không đúng định dạng
3	cde	Không có báo lỗi
4	c$e	Báo lỗi nhập không đúng định dạng
5	tendai99kitu	Không có báo lỗi
6	tendai13kitu@	Báo lỗi nhập không đúng định dạng
7		Báo lỗi nhập không đúng định dạng

3 – Giá trị biên

Cơ sở lí thuyết:

Phân tích giá trị biên dựa trên việc kiểm thử tại các ranh giới giữa các phân vùng, Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu. Thay vì chọn nhiều giá trị trong lớp đương tương để làm đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm điều kiện test.

Chúng ta thường thấy rằng một số lượng lớn lỗi xảy ra tại các ranh giới của các giá trị đầu vào được xác định thay vì các giá trị giữa, còn được gọi là các giá trị biên. Từ đó đưa ra lựa chọn các test cases thực hiện giá trị đầu vào các giá trị biên.

Kỹ thuật thiết kế test cases này bổ sung cho phân vùng tương đương. Kỹ thuật kiểm thử phần mềm này dựa trên nguyên tắc: Nếu một hệ thống hoạt động tốt với các giá trị biên thì nó sẽ hoạt động tốt cho tất cả các giá trị nằm giữa hai giá trị biên.

Ý tưởng cơ bản trong kiểm thử giá trị biên là chọn các giá trị đầu vào tại những điểm:

1. Giá trị ngay dưới giá trị nhỏ nhất
2. Giá trị nhỏ nhất
3. Giá trị ngay trên giá trị nhỏ nhất
4. Giá trị ngay dưới giá trị lớn nhất
5. Giá trị lớn nhất
6. Giá trị ngay trên giá trị lớn nhất

Áp dụng vào dự án:

Với nguyên tắc trên ta có bảng test case sau

Case	Số kí tự nhập vào	Kì vọng
1	2	Báo lỗi nhập không đúng định dạng
2	3	Không có báo lỗi
3	4	Không có báo lỗi
4	12	Không có báo lỗi
5	13	Không có báo lỗi
6	14	Báo lỗi nhập không đúng định dạng

Lời kết

Dẫu biết rằng việc Internal test của dev không thể thay thế cho tester được, nhưng việc tự test là điều rất cần thiết, nó vừa giúp giảm thiểu rủi ro trước khi chuyển giao cho các bên khác, vừa giúp các dev nâng cao hiểu biết cũng như uy tín của bản thân.

Bài viết sau mình sẽ đi sâu hơn vào các kĩ thuật của Whitebox testing, giúp anh em test dưới góc nhìn của dev. Anh em chú ý đón đọc 😀

Cảm ơn anh em đã cố gắng đọc đến hết bài này. Dưới đây là link con game được lôi ra làm ví dụ trong bài, anh em đọc đến đây rồi thì còn ngại gì mà không ủng hộ nó 1 lượt tải nhỉ 😀  

https://play.google.com/store/apps/details?id=com.zonmob.heroofempire

Tài liệu tham khảo

https://viblo.asia/p/cac-ky-thuat-kiem-thu-phan-mem-gGJ599eG5X2

https://viblo.asia/p/use-case-va-use-case-testing-Az45bgmzKxYhttps://www.geeksforgeeks.org/boundary-value-test-cases-robust-cases-and-worst-case-test-cases/

https://viblo.asia/p/nhung-luu-y-khi-test-gia-tri-bien-aWj531r1Z6m

https://blog.haposoft.com/kiem-thu-phan-mem-cac-ky-thuat-thiet-ke-kiem-thu-phan-2/

https://viblo.asia/p/ky-thuat-kiem-thu-hop-trang-white-box-testing-maGK7MpOlj2

https://viblo.asia/p/phan-biet-black-box-test-va-white-box-test-so-luoc-mot-so-ky-thuat-trong-black-box-test-Az45bpm6ZxY

https://www.geeksforgeeks.org/software-engineering-white-box-testing/