Tại Twilio SendGrid, chúng tôi viết các bài kiểm tra end-to-end (E2E) vào cuối chu kỳ phát triển trang hoặc tính năng mới để đảm bảo tất cả các phần được kết nối và hoạt động bình thường giữa giao diện người dùng và phụ trợ từ góc độ người dùng cuối. Quảng cáo sản phẩm với phần mềm gửi email marketing phanmemmarketing.vn/phan-mem-email/ Chúng tôi đã thử nghiệm với nhiều khung và thư viện thử nghiệm E2E khác nhau như khuôn khổ Ruby Selenium nội bộ tùy chỉnh của riêng chúng tôi, WebdriverIO và chủ yếu là Cypress trong hơn hai năm như được nhấn mạnh trong phần một và phần hai của loạt bài đăng trên blog ghi lại quá trình di chuyển của chúng tôi trên tất cả bản đồ đường viền. Bất kể khuôn khổ hoặc thư viện mà chúng tôi sử dụng, chúng tôi đều đặt ra những câu hỏi giống nhau về những tính năng mà chúng tôi có thể tự động hóa và viết các bài kiểm tra E2E cho. Sau khi xác định những tính năng nào chúng tôi có thể kiểm tra, chúng tôi cũng nhận thấy rằng bản thân áp dụng cùng một chiến lược chung lặp đi lặp lại để viết và thiết lập các bài kiểm tra. Bài đăng trên blog này không yêu cầu bất kỳ kiến thức trước nào về việc viết các bài kiểm tra E2E trong một thư viện hoặc khuôn khổ nhất định, nhưng nó sẽ hữu ích nếu bạn đã xem các ứng dụng web và băn khoăn về cách tự động hóa tốt nhất mọi thứ trong trình duyệt để kiểm tra các trang hoạt động chính xác. Mục đích của chúng tôi là hướng dẫn bạn cách nghĩ về các bài kiểm tra E2E, vì vậy bạn có thể áp dụng những câu hỏi này và chiến lược chung để viết bài kiểm tra cho bất kỳ khuôn khổ nào bạn có thể chọn. Các câu hỏi để hỏi xem bạn có thể tự động hóa bài kiểm tra E2E không Khi nói đến việc viết các bài kiểm tra E2E, chúng tôi cần đảm bảo các luồng trong các trang chúng tôi đang kiểm tra trong ứng dụng của mình đáp ứng các tiêu chí nhất định. Hãy xem qua một số câu hỏi cấp cao mà chúng tôi tự hỏi để xác định xem liệu bài kiểm tra E2E có thể tự động hóa hay không. 1. Có thể thiết lập lại dữ liệu người dùng về một trạng thái nhất định trước mỗi lần kiểm tra thông qua một số cách đáng tin cậy như API không? Nếu không có cách nào để đặt lại người dùng một cách đáng tin cậy về trạng thái bạn muốn, nó không thể được tự động hóa và dự kiến sẽ chạy như một phần của các thử nghiệm chặn của bạn trước khi triển khai. Nó cũng là một phản vật chất và thường không xác định để đưa người dùng trở lại một trạng thái nhất định thông qua giao diện người dùng vì nó chậm và việc tự động hóa các bước thông qua giao diện người dùng đã đủ phức tạp. Sẽ đáng tin cậy hơn khi thực hiện các lệnh gọi API để đặt lại trạng thái của người dùng mà không cần phải mở một trang trong trình duyệt. Một giải pháp thay thế khác, nếu bạn có một dịch vụ tồn tại, là tạo người dùng mới trước mỗi lần thử nghiệm với dữ liệu thích hợp. Miễn là chúng tôi đặt lại người dùng liên tục hoặc tạo người dùng trước mỗi lần kiểm tra, thì chúng tôi có thể tập trung vào các phần chúng tôi đang kiểm tra trên trang. 2. Chúng tôi có quyền kiểm soát tính năng, API hoặc hệ thống mà chúng tôi định kiểm tra không? Nếu đó là dịch vụ của bên thứ ba mà bạn đang dựa vào để thanh toán hoặc cho bất kỳ tính năng nào khác, có cách nào để chế nhạo chúng hoặc để nó hoạt động một cách xác định với các giá trị nhất định không? Bạn muốn kiểm soát bài kiểm tra càng nhiều càng tốt để giảm bớt tình trạng bong tróc. Bạn có thể tạo người dùng thử nghiệm chuyên dụng với tài nguyên hoặc dữ liệu riêng biệt cho mỗi lần chạy thử nghiệm để không thể bị ảnh hưởng bởi bất kỳ thứ gì khác. 3. Bản thân dịch vụ hoặc tính năng có đủ nhất quán để hoạt động trong thời gian chờ hợp lý không? Thông thường, bạn có thể phải triển khai thăm dò hoặc đợi dữ liệu nhất định được xử lý và đưa nó vào cơ sở dữ liệu (như cập nhật không đồng bộ chậm hơn và các sự kiện email được kích hoạt). Nếu các dịch vụ đó thường xuyên xảy ra trong khoảng thời gian hợp lý và đáng tin cậy, bạn có thể đặt thời gian chờ thăm dò thích hợp khi đợi các phần tử DOM cụ thể hiển thị hoặc dữ liệu được cập nhật. Chiến lược chung để viết bài kiểm tra E2E 1. Tìm ra các trường hợp kiểm thử giá trị cao mà chúng ta có thể tự động hóa . Một số ví dụ bao gồm kiểm tra đường dẫn vui bao gồm hầu hết quy trình tính năng: thực hiện các hoạt động CRUD thông qua giao diện người dùng để biết thông tin hồ sơ của người dùng, lọc xuống một bảng để tìm kết quả phù hợp với một số dữ liệu, tạo bài đăng hoặc thiết lập khóa API. Tuy nhiên, các trường hợp cạnh khác và xử lý lỗi có thể tốt hơn nếu bao gồm các bài kiểm tra đơn vị và tích hợp. Chạy nó qua các câu hỏi mà chúng tôi đã đề cập trong phần trước để giúp rút ngắn danh sách các trường hợp thử nghiệm của bạn. 2. Suy nghĩ về cách lặp lại các thử nghiệm này bằng cách thiết lập hoặc chia nhỏ thông qua API càng nhiều càng tốt. Đối với các trường hợp thử nghiệm có giá trị cao, có thể tự động hóa, hãy bắt đầu lưu ý những điều bạn nên thiết lập thông qua API. Một số ví dụ đang cung cấp cho người dùng dữ liệu thích hợp nếu người dùng không có đủ dữ liệu có thể lọc để phân trang, nếu dữ liệu của người dùng hết hạn trong thời hạn luân phiên là 30 ngày hoặc nếu chúng tôi có thể cần loại bỏ một số dữ liệu còn sót lại từ thành công hoặc không đầy đủ kiểm tra trước khi kiểm tra hiện tại bắt đầu lại. Các bài kiểm tra phải có thể chạy và tự thiết lập ở cùng một trạng thái có thể lặp lại bất kể lần chạy kiểm tra cuối cùng thành công hay thất bại như thế nào. Điều quan trọng là phải suy nghĩ: làm cách nào để tôi có thể đặt lại dữ liệu của người dùng này về điểm ban đầu để tôi chỉ có thể kiểm tra một phần của tính năng mà tôi muốn? Ví dụ: nếu bạn muốn kiểm tra khả năng người dùng thêm một bài đăng để cuối cùng nó hiển thị trong danh sách bài đăng của người dùng, thì bài đăng đó trước tiên phải bị xóa. 3. Đi trong đôi giày của khách hàng của bạn và theo dõi các bước giao diện người dùng cần thiết để hoàn thành toàn bộ quy trình tính năng. Ghi lại các bước để khách hàng hoàn thành toàn bộ quy trình hoặc hành động. Theo dõi những gì người dùng nên hoặc không nên xem hoặc tương tác sau mỗi bước. Chúng tôi sẽ thực hiện kiểm tra và xác nhận sự tỉnh táo trong suốt quá trình để đảm bảo người dùng đang gặp phải các chuỗi sự kiện phù hợp cho các hành động của họ. Sau đó, chúng tôi sẽ chuyển các kiểm tra độ tỉnh táo thành các lệnh và xác nhận tự động. 4. Duy trì các thay đổi và tự động hóa các luồng bằng cách thêm các bộ chọn cụ thể và triển khai các đối tượng trang (hoặc bất kỳ loại trình bao bọc nào khác). Xem lại các bước bạn đã viết ra để biết cách điều động và thực hiện quy trình tính năng. Thêm các bộ chọn cụ thể hơn như thuộc tính `data-hook` vào các phần tử mà người dùng đã tương tác như nút, phương thức, đầu vào, hàng bảng, cảnh báo và thẻ. Nếu muốn, bạn có thể tạo các đối tượng trang, trình bao bọc hoặc tệp trợ giúp với các tham chiếu đến các phần tử đó thông qua các bộ chọn bạn đã thêm. Sau đó, bạn có thể triển khai các chức năng có thể tái sử dụng để tương tác với các phần tử có thể hành động của trang. 5. Dịch các bước của người dùng mà bạn đã ghi lại thành các bài kiểm tra Cypress với các trình trợ giúp mà bạn đã tạo. Trong các thử nghiệm, chúng tôi thường đăng nhập vào người dùng thông qua API và bảo toàn cookie phiên trước khi mỗi trường hợp thử nghiệm chạy để duy trì trạng thái đăng nhập. Sau đó, chúng tôi thiết lập hoặc chia nhỏ dữ liệu của người dùng thông qua API để có điểm khởi đầu nhất quán. Với mọi thứ đã sẵn sàng, chúng tôi truy cập trang mà chúng tôi sẽ kiểm tra trực tiếp tính năng của mình. Chúng tôi tiến hành thực hiện các bước cho quy trình như tạo, cập nhật hoặc xóa quy trình, xác nhận điều gì sẽ xảy ra hoặc hiển thị trên trang trong suốt quá trình. Để tăng tốc độ kiểm tra và giảm rung lắc, hãy tránh đặt lại hoặc xây dựng trạng thái thông qua giao diện người dùng và bỏ qua những thứ như đăng nhập qua trang đăng nhập hoặc xóa mọi thứ thông qua giao diện người dùng để tập trung vào các phần bạn muốn kiểm tra. Đảm bảo luôn thực hiện các phần đó trong móc nối `before` hoặc 'beforeEach`. Ngược lại, nếu bạn đã sử dụng móc nối `after` hoặc` afterEach`, 6. Búa và dập thử độ bong tróc. Sau khi thực hiện các thử nghiệm và nó vượt qua một vài lần cục bộ, bạn nên thiết lập một yêu cầu kéo, hợp nhất nó ngay lập tức và để các thử nghiệm chạy theo lịch trình với phần còn lại của bộ thử nghiệm của bạn hoặc kích hoạt chúng trong các bước triển khai của bạn. Trước khi bạn làm điều đó: Trước tiên, hãy thử để người dùng ở các trạng thái khác nhau và xem liệu các bài kiểm tra của bạn có còn vượt qua không để đảm bảo bạn có các bước thiết lập thích hợp. Tiếp theo, điều tra việc chạy các thử nghiệm của bạn song song khi được kích hoạt trong một trong các luồng triển khai của bạn. Điều này cho phép bạn xem liệu tài nguyên có đang được sử dụng bởi những người dùng giống nhau hay không và liệu có bất kỳ điều kiện đua nào xảy ra hay không. Sau đó, hãy quan sát cách các bài kiểm tra của bạn chạy ở chế độ không đầu trong vùng chứa Docker để xem liệu bạn có thể cần tăng thời gian chờ hay điều chỉnh bất kỳ bộ chọn nào không. Mục đích là để xem các thử nghiệm của bạn hoạt động như thế nào khi chạy thử nghiệm lặp đi lặp lại trong các điều kiện khác nhau và làm cho chúng ổn định và nhất quán nhất có thể để chúng tôi dành ít thời gian hơn để sửa các thử nghiệm và tập trung nhiều hơn vào việc phát hiện các lỗi thực tế trong môi trường của chúng tôi. TOP Marketing Website : phanmemmarketing.vn 102 Tran Phu, Ha Dong, Ha Noi
