How Guru’s Engineers Use Cypress for Better Burn Testing
Cần một cách tốt hơn để xử lý kiểm thử burn? Hai trong số các kỹ sư front end của chúng tôi đã tìm ra cách sử dụng Cypress để cải thiện cách họ xử lý QA.
Chúng tôi luôn hướng tới việc chia sẻ kiến thức tại Guru, và khi phát hiện ra điều gì đó mới mẻ và hữu ích, chúng tôi muốn cả thế giới biết đến! Đội ngũ kỹ sư của chúng tôi sử dụng Cypress trong quy trình kiểm thử và QA của họ. Họ đã phát hiện ra một cách mới để giúp thực hiện các bài kiểm tra burn tốt hơn, và họ muốn chia sẻ quy trình mới và được cải tiến của họ với các kỹ sư và người kiểm thử khác.
Trong năm qua, chúng tôi đã tập trung vào việc tăng cường phạm vi kiểm thử của chúng tôi - cụ thể là việc kiểm thử end-to-end nhằm đảm bảo các phần khác nhau của quy trình sản phẩm của chúng tôi hoạt động đúng khi chúng tôi cập nhật mã. Đối với loại kiểm thử này, chúng tôi tận dụng một công cụ có tên là Cypress, mô phỏng hành vi người dùng với ứng dụng web của chúng tôi và tiện ích mở rộng Google Chrome. Gói kiểm thử này chạy trên mọi yêu cầu kéo để đảm bảo mã mới không làm hỏng giao diện người dùng của chúng tôi. Chúng tôi cũng muốn ngăn chặn việc phát hành nếu gói Cypress của chúng tôi không thành công trên nhánh sản xuất của mình.
Những gì chúng tôi tìm kiếm trong kiểm thử truyền thống
Một vấn đề mà chúng tôi đã gặp phải là thấy một số bài kiểm thử của chúng tôi thất bại, nhưng không phải vì lý do liên quan đến giao diện người dùng hoặc mã. Vậy làm thế nào Cypress giúp chúng tôi trong những trường hợp này? Chúng tôi có Cypress hoạt động như một người dùng mà hành vi của họ có thể được xác định. Có một số biến có thể dẫn đến việc Cypress báo cáo rằng có một sự cố, nhưng từ góc nhìn của người dùng, không có gì trông có vẻ sai cả.
Ví dụ, có thể có một bài kiểm tra nói rằng, “Chuyển đến phần này của ứng dụng web > Thêm một thẻ Guru mới > Mong đợi thấy trạng thái sau khi tạo”. Nếu trạng thái tải của việc tạo một thẻ treo quá lâu một mili giây và Cypress bắt đầu tìm kiếm trạng thái sau khi tạo trước khi nó xuất hiện, thì bài kiểm tra này có thể thất bại (phần lớn thời gian, bài kiểm tra này sẽ thành công). Nếu nó thành công một lần trên yêu cầu kéo, chúng tôi có thể hợp nhất mã mà đôi khi có thể không ổn định. Nhưng chúng tôi sẽ không biết nếu nó xảy ra; một bài kiểm tra đã vượt qua không đảm bảo rằng mã là chính xác.
Tình huống này làm giảm độ tin cậy của phạm vi kiểm thử của chúng tôi. Kết quả là, khi một lỗi kiểm thử xuất hiện trong quy trình triển khai của chúng tôi, chúng tôi cần kiểm tra xem đó có phải là vấn đề với giao diện người dùng - hay là với bài kiểm tra. Để khắc phục điều này, chúng tôi đã bắt đầu nghĩ về những cách mà chúng tôi có thể phát hiện nếu một bài kiểm tra có thể không ổn định trước khi nó được đưa vào nhánh mã sản xuất của chúng tôi.
Cách kiểm thử burn giúp đỡ
Giới thiệu về kiểm thử burn. Kiểm thử burn là một quy trình được sử dụng để kiểm tra một cái gì đó dưới những điều kiện khắc nghiệt hoặc khắt khe hơn. Nó cũng đôi khi được gọi là kiểm thử tải hoặc kiểm thử áp lực, tùy thuộc vào phương pháp hoặc lĩnh vực cụ thể đang được kiểm tra.
Tại Guru, chúng tôi sử dụng kiểm thử burn như một phần của gói Cypress của chúng tôi cho bất kỳ bài kiểm tra nào mới hoặc đã chỉnh sửa được thêm vào cơ sở mã của chúng tôi. Trước khi những bài kiểm tra này có thể được hợp nhất, chúng tôi chạy chúng nhiều lần liên tiếp và tất cả phải thành công để tiến tới bước tiếp theo trong quy trình xây dựng CircleCI của chúng tôi.
Bước này diễn ra ngay trước khi chúng tôi chạy toàn bộ gói kiểm tra Cypress. Lợi thế của thứ tự này là nếu bước kiểm thử burn của chúng tôi tạo ra một lỗi, chúng tôi có thể đánh dấu toàn bộ kiểm tra là lỗi sớm. Bỏ qua phần còn lại của bài kiểm tra cho phép chúng tôi tiết kiệm thời gian và giảm số lần lặp để đảm bảo rằng các bài kiểm tra mới được giới thiệu đáng tin cậy và kháng lỗi như chúng tôi cần.
Để tìm các tệp mà chúng tôi đang tìm kiếm, chúng tôi sử dụng git diff trên nhánh hiện tại và cung cấp đầu ra như một tham số cho một công cụ có tên là cypress-repeat, cho phép chúng tôi chạy những bài kiểm tra đó bất kỳ số lần nào được chỉ định, hiệu quả là thêm kiểm thử burn như một bước trong bộ kiểm thử end-to-end của chúng tôi.
Kết quả
Việc điều chỉnh kế hoạch kiểm thử của chúng tôi đã mang lại kết quả tích cực khá ổn định. Đối với chúng tôi, việc thêm kiểm thử burn có thể giảm thời gian tìm kiếm các bài kiểm tra không đáng tin cậy đến 30 phút. Nó cũng cải thiện thời gian phản hồi cho việc thêm chức năng mới. Vì các bài kiểm tra mới được thêm vào hiện được chạy trước, chúng cho phép chúng tôi xác minh tính ổn định trước khi tiếp tục với phần còn lại của quy trình xây dựng.
Tóm lại, việc duy trì sự tập trung vào việc làm cho quy trình kiểm thử của chúng tôi hiệu quả và mạnh mẽ hơn sẽ giúp tăng cường sự tự tin của toàn đội kỹ sư trong việc nhanh chóng phát hành các tính năng mới. Chúng tôi đang sửa lỗi nhanh hơn và dễ dàng làm việc trên tất cả các mã nguồn của mình. Chúng tôi hy vọng rằng bài viết này sẽ giúp những người sử dụng Cypress khác tạo ra những bài kiểm tra tốt hơn và các đội ngũ phát triển hiệu quả hơn.
Chúng tôi luôn hướng tới việc chia sẻ kiến thức tại Guru, và khi phát hiện ra điều gì đó mới mẻ và hữu ích, chúng tôi muốn cả thế giới biết đến! Đội ngũ kỹ sư của chúng tôi sử dụng Cypress trong quy trình kiểm thử và QA của họ. Họ đã phát hiện ra một cách mới để giúp thực hiện các bài kiểm tra burn tốt hơn, và họ muốn chia sẻ quy trình mới và được cải tiến của họ với các kỹ sư và người kiểm thử khác.
Trong năm qua, chúng tôi đã tập trung vào việc tăng cường phạm vi kiểm thử của chúng tôi - cụ thể là việc kiểm thử end-to-end nhằm đảm bảo các phần khác nhau của quy trình sản phẩm của chúng tôi hoạt động đúng khi chúng tôi cập nhật mã. Đối với loại kiểm thử này, chúng tôi tận dụng một công cụ có tên là Cypress, mô phỏng hành vi người dùng với ứng dụng web của chúng tôi và tiện ích mở rộng Google Chrome. Gói kiểm thử này chạy trên mọi yêu cầu kéo để đảm bảo mã mới không làm hỏng giao diện người dùng của chúng tôi. Chúng tôi cũng muốn ngăn chặn việc phát hành nếu gói Cypress của chúng tôi không thành công trên nhánh sản xuất của mình.
Những gì chúng tôi tìm kiếm trong kiểm thử truyền thống
Một vấn đề mà chúng tôi đã gặp phải là thấy một số bài kiểm thử của chúng tôi thất bại, nhưng không phải vì lý do liên quan đến giao diện người dùng hoặc mã. Vậy làm thế nào Cypress giúp chúng tôi trong những trường hợp này? Chúng tôi có Cypress hoạt động như một người dùng mà hành vi của họ có thể được xác định. Có một số biến có thể dẫn đến việc Cypress báo cáo rằng có một sự cố, nhưng từ góc nhìn của người dùng, không có gì trông có vẻ sai cả.
Ví dụ, có thể có một bài kiểm tra nói rằng, “Chuyển đến phần này của ứng dụng web > Thêm một thẻ Guru mới > Mong đợi thấy trạng thái sau khi tạo”. Nếu trạng thái tải của việc tạo một thẻ treo quá lâu một mili giây và Cypress bắt đầu tìm kiếm trạng thái sau khi tạo trước khi nó xuất hiện, thì bài kiểm tra này có thể thất bại (phần lớn thời gian, bài kiểm tra này sẽ thành công). Nếu nó thành công một lần trên yêu cầu kéo, chúng tôi có thể hợp nhất mã mà đôi khi có thể không ổn định. Nhưng chúng tôi sẽ không biết nếu nó xảy ra; một bài kiểm tra đã vượt qua không đảm bảo rằng mã là chính xác.
Tình huống này làm giảm độ tin cậy của phạm vi kiểm thử của chúng tôi. Kết quả là, khi một lỗi kiểm thử xuất hiện trong quy trình triển khai của chúng tôi, chúng tôi cần kiểm tra xem đó có phải là vấn đề với giao diện người dùng - hay là với bài kiểm tra. Để khắc phục điều này, chúng tôi đã bắt đầu nghĩ về những cách mà chúng tôi có thể phát hiện nếu một bài kiểm tra có thể không ổn định trước khi nó được đưa vào nhánh mã sản xuất của chúng tôi.
Cách kiểm thử burn giúp đỡ
Giới thiệu về kiểm thử burn. Kiểm thử burn là một quy trình được sử dụng để kiểm tra một cái gì đó dưới những điều kiện khắc nghiệt hoặc khắt khe hơn. Nó cũng đôi khi được gọi là kiểm thử tải hoặc kiểm thử áp lực, tùy thuộc vào phương pháp hoặc lĩnh vực cụ thể đang được kiểm tra.
Tại Guru, chúng tôi sử dụng kiểm thử burn như một phần của gói Cypress của chúng tôi cho bất kỳ bài kiểm tra nào mới hoặc đã chỉnh sửa được thêm vào cơ sở mã của chúng tôi. Trước khi những bài kiểm tra này có thể được hợp nhất, chúng tôi chạy chúng nhiều lần liên tiếp và tất cả phải thành công để tiến tới bước tiếp theo trong quy trình xây dựng CircleCI của chúng tôi.
Bước này diễn ra ngay trước khi chúng tôi chạy toàn bộ gói kiểm tra Cypress. Lợi thế của thứ tự này là nếu bước kiểm thử burn của chúng tôi tạo ra một lỗi, chúng tôi có thể đánh dấu toàn bộ kiểm tra là lỗi sớm. Bỏ qua phần còn lại của bài kiểm tra cho phép chúng tôi tiết kiệm thời gian và giảm số lần lặp để đảm bảo rằng các bài kiểm tra mới được giới thiệu đáng tin cậy và kháng lỗi như chúng tôi cần.
Để tìm các tệp mà chúng tôi đang tìm kiếm, chúng tôi sử dụng git diff trên nhánh hiện tại và cung cấp đầu ra như một tham số cho một công cụ có tên là cypress-repeat, cho phép chúng tôi chạy những bài kiểm tra đó bất kỳ số lần nào được chỉ định, hiệu quả là thêm kiểm thử burn như một bước trong bộ kiểm thử end-to-end của chúng tôi.
Kết quả
Việc điều chỉnh kế hoạch kiểm thử của chúng tôi đã mang lại kết quả tích cực khá ổn định. Đối với chúng tôi, việc thêm kiểm thử burn có thể giảm thời gian tìm kiếm các bài kiểm tra không đáng tin cậy đến 30 phút. Nó cũng cải thiện thời gian phản hồi cho việc thêm chức năng mới. Vì các bài kiểm tra mới được thêm vào hiện được chạy trước, chúng cho phép chúng tôi xác minh tính ổn định trước khi tiếp tục với phần còn lại của quy trình xây dựng.
Tóm lại, việc duy trì sự tập trung vào việc làm cho quy trình kiểm thử của chúng tôi hiệu quả và mạnh mẽ hơn sẽ giúp tăng cường sự tự tin của toàn đội kỹ sư trong việc nhanh chóng phát hành các tính năng mới. Chúng tôi đang sửa lỗi nhanh hơn và dễ dàng làm việc trên tất cả các mã nguồn của mình. Chúng tôi hy vọng rằng bài viết này sẽ giúp những người sử dụng Cypress khác tạo ra những bài kiểm tra tốt hơn và các đội ngũ phát triển hiệu quả hơn.
Trải nghiệm sức mạnh của nền tảng Guru trực tiếp - tham gia tour sản phẩm tương tác của chúng tôi
