Kiểm tra đánh giá mã

Đánh giá mã là một hoạt động đảm bảo chất lượng để đảm bảo rằng các đăng ký được xem xét bởi một người nào đó không phải là tác giả. Nếu không lập trình cặp khi viết mã, các cửa hàng phát triển trưởng thành thường thực hành hoạt động này vì đây là một cách tuyệt vời để bắt lỗi sớm trong quá trình

Tôi thường tuyên bố rằng mã kiểm tra phải được xử lý cẩn thận giống như mã tính năng và do đó, nó cũng phải trải qua quá trình đánh giá mã. Mã kiểm tra có thể được xem xét bởi các kỹ sư hoặc nhà phát triển tự động hóa khác, những người đã quen thuộc với dự án và cơ sở mã

Nhưng chính xác những gì bạn nên tìm kiếm khi xem xét mã kiểm tra?

1. Bài kiểm tra có xác minh những gì cần thiết không?

Khi xác minh điều gì đó theo cách thủ công, có rất nhiều xác nhận trong tiềm thức đang được thực hiện. Vì vậy, nếu có bất cứ điều gì không chính xác, chúng tôi có thể nhận thấy. Các bài kiểm tra của chúng tôi không tốt ở điểm này. Trên thực tế, chúng sẽ chỉ thất bại nếu các điều kiện mà chúng tôi chỉ định rõ ràng không được đáp ứng

Ví dụ: giả sử chúng tôi có thử nghiệm để tăng số lượng của một trong các sản phẩm trong giỏ hàng trực tuyến. Và đây là bài kiểm tra mà bạn cần xem lại

@Test
public void testIncreaseQuantity() {
    cart.addProduct("Be A Good Person");

    String product = "Air Fryer Squad";
    cart.addProduct(product);
    cart.increaseQuantity(product, 1);
    cart.clickUpdate();
    assertEquals(cart.getQuantity(product), 2);
}

Thoạt nhìn, điều này có vẻ tốt. Thử nghiệm đã tăng số lượng của một trong những sản phẩm mới được thêm lên 1 và đang xác minh rằng số lượng hiện là 2. Tuy nhiên, hãy nhìn vào giao diện người dùng

Có quá nhiều thứ ở đây chưa được xác minh bằng bài kiểm tra này

• Xác nhận để đảm bảo giá của sản phẩm được cập nhật chính xác ở đâu?
• Làm thế nào về tổng phụ của toàn bộ giỏ hàng?
• Thuế sẽ thay đổi dựa trên tổng số, vì vậy khi số lượng tăng lên, thuế sẽ tăng lên. Khẳng định ở đâu?
• vận chuyển là một tỷ lệ cố định. Khi giỏ hàng thay đổi, làm thế nào bạn có thể chắc chắn rằng chi phí vận chuyển không thay đổi?
• Còn mặt hàng khác trong giỏ hàng thì sao?

Như bạn có thể thấy, một hành động tăng số lượng ảnh hưởng đến nhiều khía cạnh khác nhau của giỏ hàng – và điều này thường xảy ra với các tính năng phần mềm. Vì vậy, khi xem xét mã kiểm tra, hãy đảm bảo kiểm tra bao gồm các xác nhận cho tất cả những gì cần thiết. mẹo chuyên nghiệp. kiểm tra trực quan với Applitools sẽ nắm bắt được tất cả những khẳng định trong tiềm thức này mà bạn không cần phải nghĩ về tất cả chúng; . 🔑

2. Bài kiểm tra có tập trung vào một thứ không?

Mỗi bài kiểm tra nên tập trung vào một điều duy nhất. Điều này có thể hơi khó hiểu vì trong bài kiểm tra trên, tôi đã đề cập đến một loạt những điều nên khẳng định. Tuy nhiên, tất cả những xác nhận đó phối hợp với nhau để xác minh một điều duy nhất (tăng số lượng sản phẩm trong giỏ hàng)

Tuy nhiên, nếu thử nghiệm ở trên cũng xác minh logo của công ty hoặc một số tính năng khác ngoài giỏ hàng, thì điều đó sẽ nằm ngoài phạm vi của thử nghiệm này

3. Thử nghiệm có thể chạy độc lập không?

Ngoài việc tập trung vào một thứ duy nhất, mỗi bài kiểm tra phải độc lập, nghĩa là nó hoàn toàn không nên dựa vào các bài kiểm tra khác. Điều này giúp dễ dàng theo dõi các lỗi và nguyên nhân gốc rễ của chúng, đồng thời cũng sẽ cho phép nhóm chạy thử nghiệm song song để tăng tốc độ thực thi nếu cần

Mặc dù tác giả có thể đồng ý rằng các thử nghiệm nên được tách biệt, nhưng đôi khi họ vẫn rơi vào bẫy sử dụng các lần chạy thử nghiệm liên quan để thiết lập cho các thử nghiệm khác. Ví dụ: nếu thử nghiệm là xóa một mặt hàng khỏi giỏ hàng, bạn nên chạy thử nghiệm “thêm vào giỏ hàng” trước và phụ thuộc vào nó trước khi chạy thử nghiệm “xóa khỏi giỏ hàng”. Gọi điều này ra trong các bài đánh giá. Khuyến nghị của bạn là thử nghiệm nên tạo và xóa bất cứ thứ gì nó cần và nếu có thể hãy thực hiện việc này bên ngoài GUI. Thông tin thêm về điều này trong #4 ⬇️

4. Dữ liệu thử nghiệm được quản lý như thế nào?

Cách kiểm thử xử lý dữ liệu kiểm thử có thể là sự khác biệt giữa bộ kiểm thử ổn định và đáng tin cậy so với bộ kiểm thử không ổn định và không đáng tin cậy. Vì mỗi thử nghiệm nên được phát triển để chạy độc lập và tất cả các thử nghiệm có thể chạy song song cùng một lúc, mỗi thử nghiệm phải chịu trách nhiệm về dữ liệu thử nghiệm của riêng mình. Cố gắng chia sẻ dữ liệu đang bị thao túng là thành phần hoàn hảo cho một bài kiểm tra không đáng tin cậy. Khi các thử nghiệm đang chạy song song và có các kỳ vọng khác nhau về trạng thái của dữ liệu thử nghiệm, các thử nghiệm sẽ thất bại khi không có vấn đề thực sự với ứng dụng. Đề xuất với tác giả rằng họ tạo bất kỳ dữ liệu nào cần thiết cho thử nghiệm trong chính thử nghiệm đó. Vì việc thêm thứ gì đó vào giỏ hàng đã có thử nghiệm, nên thử nghiệm "xóa mặt hàng" có thể sử dụng các đường nối mã như lệnh gọi cơ sở dữ liệu hoặc API để thêm mặt hàng vào giỏ hàng

5. Có một sự tách biệt của mối quan tâm?

Hãy nhớ rằng, mã kiểm tra phải được xử lý cẩn thận như mã tính năng. Điều đó có nghĩa là nên tuân thủ các thực hành viết mã sạch, chẳng hạn như tách biệt các mối quan tâm. Phương pháp kiểm tra chỉ nên tập trung vào việc đưa ứng dụng vào trạng thái mong muốn và xác minh trạng thái đó. Việc triển khai thao túng trạng thái của ứng dụng không nên nằm trong bản thân thử nghiệm

Ví dụ: trong bài kiểm tra này, hãy chú ý cuộc gọi đến addToCart(). Việc triển khai thêm một sản phẩm vào giỏ hàng không phải là trách nhiệm của thử nghiệm và do đó, nó được tách ra thành một phương thức khác và thậm chí là một lớp khác. Tương tự với goToCart()

    @Test
    public void testAddToCart() {
        product.addToCart("Be A Good Person");
        page.goToCart();
        eyes.checkWindow();
    }

Tương tự như vậy, các phương pháp không kiểm tra không nên đưa ra bất kỳ xác nhận nào. Trách nhiệm của họ là thao túng trạng thái của ứng dụng và trách nhiệm của kiểm tra là xác minh trạng thái đó. Việc thêm các xác nhận trong các bài kiểm tra không làm giảm khả năng sử dụng lại của các phương thức đó

6. Có điều gì trong bài kiểm tra nên là một tiện ích không?

Việc tách mối quan tâm đã giải quyết vấn đề này trong hầu hết các trường hợp, nhưng hãy kiểm tra kỹ xem thử nghiệm có đang triển khai thứ gì đó có thể được sử dụng lại bởi các thử nghiệm khác không. Đôi khi, đây có thể là một loạt các bước xác minh phổ biến chắc chắn thuộc trách nhiệm của bài kiểm tra, tuy nhiên, đang/sẽ được lặp lại qua nhiều bài kiểm tra

Trong những trường hợp này, thật tốt khi khuyên tác giả nên chuyển khối mã này sang một phương thức tiện ích có thể được sử dụng lại bằng nhiều lần kiểm tra

7. Bộ chọn có đáng tin cậy không?

Đối với các thử nghiệm GUI và thiết bị di động, tác giả sẽ cần sử dụng các bộ chọn để định vị và tương tác với các phần tử web. Điều đầu tiên cần đảm bảo là những bộ định vị này không nằm trong bản thân các bài kiểm tra. Hãy nhớ…tách mối quan tâm

Tiếp theo, đảm bảo rằng các bộ chọn có thể chịu được thử thách của thời gian. Ví dụ: sử dụng bộ chọn phụ thuộc vào cấu trúc của trang (e. g. chỉ mục) sẽ chỉ hoạt động cho đến khi cấu trúc của trang bị thay đổi

Đây là một bộ chọn khủng khiếp và chỉ là vấn đề thời gian trước khi bài kiểm tra bị hỏng vì nó

//*[@id="main"]/ul[1]/li[2]/a

Nếu một mục danh sách khác được thêm vào trước mục này, đột nhiên, bộ chọn này không còn tốt nữa. Khuyến khích tác giả sử dụng ID duy nhất để định vị bất kỳ phần tử nào họ cần tương tác, ngay cả khi điều đó có nghĩa là thêm ID vào phần tử như một phần của đăng ký này

8. Chiến lược chờ đợi có vững chắc không?

Gắn cờ bất kỳ sự chờ đợi được mã hóa cứng nào. Thử nghiệm tự động chạy nhanh hơn so với khách hàng thực sự tương tác với sản phẩm và điều này có thể dẫn đến các vấn đề với thử nghiệm, chẳng hạn như cố gắng tương tác hoặc xác minh thứ gì đó chưa ở trạng thái mong muốn. Để giải quyết vấn đề này, mã cần đợi cho đến khi ứng dụng ở trạng thái mong đợi trước khi tiếp tục

Tuy nhiên, mã hóa cứng chờ đợi không phải là lý tưởng. Dẫn đến đủ thứ vấn đề như kéo dài thời gian thực thi, hay vẫn fail vì đợi không đủ lâu

Thay vào đó, khuyến nghị tác giả sử dụng thời gian chờ có điều kiện sẽ chỉ tạm dừng thực thi trong khoảng thời gian cần thiết ít nhất

Ví dụ: nếu kiểm tra yêu cầu API POST, trong khi phản hồi có thể đã được trả về, vẫn có thể có một số xử lý ở phần phụ trợ. Việc cố chạy một yêu cầu khác trên thực thể mới tạo này trước khi thực thể đó thực sự được tạo sẽ dẫn đến lỗi thử nghiệm. Thay vì đợi 3 giây trước khi tiếp tục, hãy đề xuất rằng tác giả nên bao gồm logic thăm dò vài mili giây một lần cho đến khi thử nghiệm chắc chắn rằng thực thể đã được tạo, rồi tiếp tục

Bạn đã sẵn sàng để xem xét

Hy vọng rằng những lời khuyên này cung cấp một cái gì đó đáng kể để tìm kiếm trong các đánh giá về mã kiểm tra. Hãy nhớ rằng, mã kiểm tra của bạn là thứ được sử dụng để xác định chất lượng mã tính năng của bạn, vì vậy điều thực sự quan trọng là nó được phát triển cẩn thận. Nếu bạn đang tìm kiếm thêm mẹo hoặc lời khuyên về cách thiết lập để thành công trong thử nghiệm tự động hóa, hãy xem khóa học miễn phí của tôi tại Đại học Tự động hóa thử nghiệm, Thiết lập nền tảng để tự động hóa thử nghiệm thành công

Kiểm tra đánh giá mã là gì?

7 bước để xem xét mã là gì?

Bạn có nên kiểm tra trong quá trình xem xét mã không?

3 loại đánh giá mã hóa là gì?