Kiểm thử phần mềm
Thiết kế ca kiểm thử biên và tự động hóa với JUnit 5
Từ quy tắc sĩ số 15–45, xây bộ ca có thể phát hiện lỗi ở cả hai biên và lỗi giá trị ngoài miền.
Thích và đánh giá Bình luận và hỏi đáp1. Chuyển yêu cầu nghiệp vụ thành điều kiện đo được
Giả sử phòng đào tạo chỉ mở lớp nếu sĩ số từ 15 đến 45 sinh viên, tính cả hai đầu. Đầu vào của hàm là một số nguyên. Đầu ra là giá trị đúng khi cho phép mở lớp và sai khi từ chối. Điều kiện “tính cả hai đầu” cần ghi rõ vì chỉ một ký tự trong phép so sánh cũng có thể loại nhầm lớp.
Ta chia miền đầu vào thành ba lớp tương đương. Dưới 15 bị từ chối, từ 15 đến 45 được chấp nhận và trên 45 bị từ chối. Một mẫu giữa mỗi vùng giúp kiểm tra định hướng. Các giá trị sát ranh giới tập trung vào nơi quy tắc đổi kết quả.
2. Chọn ca ngay dưới, ngay tại và ngay trên mỗi biên
| Nhóm | Giá trị | Kết quả theo thứ tự | Lỗi có thể phát hiện |
|---|---|---|---|
| Biên dưới | 14, 15, 16 | Từ chối, chấp nhận, chấp nhận | Mở nhầm lớp 14 hoặc loại nhầm lớp 15 |
| Ở giữa | 30 | Chấp nhận | Biểu thức chỉ nhận một vài giá trị ở sát biên |
| Biên trên | 44, 45, 46 | Chấp nhận, chấp nhận, từ chối | Loại nhầm lớp 45 hoặc nhận nhầm lớp 46 |
Giá trị mong đợi đến từ quy tắc đào tạo. Nếu viết ca kiểm thử bằng chính biểu thức điều kiện của chương trình, lỗi dùng toán tử sai có thể xuất hiện ở cả phần triển khai lẫn phần kiểm thử. Trong bài này, dữ liệu và kết quả mong đợi được ghi tường minh từng hàng.
3. Viết một phương thức JUnit, chạy bảy lần
Với một dự án Java đã bật JUnit Jupiter, đặt SiSoTest.java vào thư mục mã kiểm thử. Đảm bảo có thư viện hỗ trợ kiểm thử tham số junit-jupiter-params. Hàm cần kiểm tra được đặt chung trong ví dụ để có thể đọc độc lập. Trong dự án thật, gọi hàm nghiệp vụ từ mã sản phẩm.
Môi trường thực hành. Dự án Java có JUnit Jupiter 5 và junit-jupiter-params. Đặt tệp vào thư mục mã kiểm thử của dự án rồi chạy bằng IDE hoặc Maven.
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
class SiSoTest {
static boolean choPhepMoLop(int siSo) {
return siSo >= 15 && siSo <= 45;
}
@ParameterizedTest(name = "siSo={0} -> chapNhan={1}")
@CsvSource({
"14, false",
"15, true",
"16, true",
"30, true",
"44, true",
"45, true",
"46, false"
})
void kiemTraGiaTriBien(int siSo, boolean mongDoi) {
assertEquals(mongDoi, choPhepMoLop(siSo));
}
}@CsvSource đưa mỗi hàng vào một lượt chạy của phương thức @ParameterizedTest. Tham số đầu nhận sĩ số, tham số thứ hai nhận kết quả mong đợi. Chuỗi name giúp báo cáo chỉ ra ngay đầu vào gặp lỗi khi nhiều hàng dùng chung phương thức.
4. Chủ động tạo lỗi để đánh giá bộ kiểm thử
Chạy ca bằng IDE hoặc mvn test nếu dự án đã cấu hình Maven. Bảy lượt đầu đều phải đạt. Đổi >= 15 thành > 15 rồi chạy lại. Lượt 15 phải thất bại. Khôi phục dòng này, đổi <= 45 thành < 45 và kiểm tra lượt 45. Hai thay đổi giúp chứng minh rằng bộ ca có khả năng phát hiện đúng loại lỗi được thiết kế để bắt.
Nếu hệ thống nhận dữ liệu từ ô nhập hoặc API, hãy tạo một tầng ca riêng cho chuỗi rỗng, chuỗi có chữ và số vượt phạm vi kiểu int. Những đầu vào này kiểm tra bước chuyển đổi dữ liệu, trong khi bảng trên kiểm tra hàm nghiệp vụ sau khi đã chuyển đổi thành công.
Đọc thêm tại JUnit 5 User Guide.