Có bao nhiêu trạng thái của lỗi trong kiểm thử năm 2024
một bài kiểm tra là gì? Theo Wikipedia: "Kiểm thử phần mềm liên quan đến việc thực thi một thành phần phần mềm hoặc thành phần hệ thống để đánh giá một hoặc nhiều thuộc tính quan tâm." Nói cách khác, đó là kiểm tra tính chính xác của hệ thống của chúng tôi trong các tình huống nhất định. Chà, hãy xem nói chung có những loại thử nghiệm nào: Show
Tất cả điều này nghe có vẻ tốt, nhưng nó hoạt động như thế nào trong thực tế? Đơn giản! Chúng tôi sử dụng kim tự tháp thử nghiệm của Mike Cohn: Đây là phiên bản đơn giản hóa của kim tự tháp: giờ đây nó được chia thành các phần thậm chí còn nhỏ hơn. Nhưng hôm nay chúng ta sẽ không quá phức tạp. Chúng tôi sẽ xem xét phiên bản đơn giản nhất.
Các khái niệm chính trong kiểm thử đơn vịPhạm vi kiểm tra (độ bao phủ của mã) là một trong những biện pháp chính để đánh giá ứng dụng được kiểm tra tốt như thế nào. Đây là tỷ lệ phần trăm mã được kiểm tra (0-100%). Trong thực tế, nhiều người theo đuổi tỷ lệ phần trăm này như là mục tiêu của họ. Đó là điều tôi không đồng ý, vì nó có nghĩa là các bài kiểm tra bắt đầu được áp dụng ở những nơi không cần thiết. Ví dụ: giả sử chúng tôi có các thao tác CRUD (tạo/lấy/cập nhật/xóa) tiêu chuẩn trong dịch vụ của mình mà không cần logic bổ sung. Các phương thức này hoàn toàn là các trung gian ủy thác công việc cho lớp làm việc với kho lưu trữ. Trong tình huống này, chúng tôi không có gì để kiểm tra, ngoại trừ có lẽ phương thức đã cho có gọi là phương thức DAO hay không, nhưng đó là một trò đùa. Các công cụ bổ sung thường được sử dụng để đánh giá phạm vi kiểm thử: JaCoCo, Cobertura, Clover, Emma, v.v. Để nghiên cứu chi tiết hơn về chủ đề này,
TDD là viết tắt của phát triển dựa trên thử nghiệm. Theo cách tiếp cận này, trước khi làm bất cứ điều gì khác, bạn viết một bài kiểm tra để kiểm tra mã cụ thể. Điều này hóa ra là thử nghiệm hộp đen: chúng tôi biết đầu vào là gì và chúng tôi biết đầu ra sẽ là gì. Điều này giúp tránh trùng lặp mã. Phát triển dựa trên thử nghiệm bắt đầu bằng việc thiết kế và phát triển các thử nghiệm cho từng phần chức năng trong ứng dụng của bạn. Trong cách tiếp cận TDD, trước tiên chúng tôi tạo một thử nghiệm xác định và kiểm tra hành vi của mã. Mục tiêu chính của TDD là làm cho mã của bạn dễ hiểu hơn, đơn giản hơn và không có lỗi. Cách tiếp cận bao gồm những điều sau đây:
TDD dựa trên các bài kiểm tra đơn vị, vì chúng là các khối xây dựng nhỏ nhất trong kim tự tháp tự động hóa kiểm tra. Với các bài kiểm tra đơn vị, chúng ta có thể kiểm tra logic nghiệp vụ của bất kỳ lớp nào. BDD là viết tắt của phát triển dựa trên hành vi. Cách tiếp cận này dựa trên TDD. Cụ thể hơn, nó sử dụng các ví dụ bằng ngôn ngữ đơn giản để giải thích hành vi của hệ thống cho mọi người tham gia phát triển. Chúng tôi sẽ không đi sâu vào thuật ngữ này, vì nó chủ yếu ảnh hưởng đến người thử nghiệm và nhà phân tích kinh doanh. Trường hợp kiểm thử là một kịch bản mô tả các bước, điều kiện cụ thể và tham số cần thiết để kiểm tra mã đang được kiểm thử. Lịch thi thử là mã thiết lập môi trường thử nghiệm để có trạng thái cần thiết để phương thức được thử nghiệm chạy thành công. Đó là một tập hợp các đối tượng được xác định trước và hành vi của chúng trong các điều kiện được chỉ định. Các giai đoạn thử nghiệmMột bài kiểm tra bao gồm ba giai đoạn:
môi trường thử nghiệmVì vậy, bây giờ đến điểm. Có một số môi trường thử nghiệm (khung) có sẵn cho Java. Phổ biến nhất trong số này là JUnit và TestNG. Để xem xét ở đây, chúng tôi sử dụng: Kiểm tra JUnit là một phương thức trong một lớp chỉ được sử dụng để kiểm tra. Lớp thường được đặt tên giống như lớp mà nó kiểm tra, với "Test" được thêm vào cuối. Ví dụ: CarService -> CarServiceTest. Hệ thống xây dựng Maven tự động bao gồm các lớp như vậy trong phạm vi thử nghiệm. Trên thực tế, lớp này được gọi là lớp kiểm tra. Hãy xem qua các chú thích cơ bản:
Chúng ta hãy xem xét một số phương pháp được sử dụng để so sánh kết quả:
AssertJ cũng cung cấp một phương pháp so sánh hữu ích: assertThat(firstObject).isEqualTo(secondObject) . Ở đây tôi đã đề cập đến các phương pháp cơ bản — những phương pháp khác là biến thể của các phương pháp trên. Thử nghiệm trong thực tếBây giờ hãy xem tài liệu trên trong một ví dụ cụ thể. Chúng tôi sẽ kiểm tra phương pháp cập nhật của dịch vụ. Chúng tôi sẽ không xem xét lớp DAO vì chúng tôi đang sử dụng mặc định. Hãy thêm một phần khởi động cho các bài kiểm tra:
Và ở đây chúng ta có lớp dịch vụ:
Dòng 8 — lấy đối tượng được cập nhật từ cơ sở dữ liệu. Dòng 9-14 — tạo đối tượng thông qua trình tạo. Nếu đối tượng đến có một trường, hãy đặt nó. Nếu không, chúng tôi sẽ để lại những gì có trong cơ sở dữ liệu. Bây giờ hãy nhìn vào thử nghiệm của chúng tôi:
Dòng 1 - Người chạy của chúng tôi. Dòng 4 — chúng tôi cách ly dịch vụ khỏi lớp DAO bằng cách thay thế một bản mô phỏng. Dòng 11 - chúng tôi đặt một thực thể thử nghiệm (thực thể mà chúng tôi sẽ sử dụng làm vật thí nghiệm) cho lớp. Dòng 22 - chúng tôi đặt đối tượng dịch vụ, đây là đối tượng chúng tôi sẽ kiểm tra. |