Là một chuyên gia , việc tạo người dùng mới để thử nghiệm sản phẩm có vẻ như là một nhiệm vụ đơn giản – chỉ cần hoàn thành biểu mẫu đăng ký và bạn đã sẵn sàng. Tuy nhiên, nếu bạn cần kiểm tra người dùng có lịch sử tin nhắn trong một năm hoặc đánh giá cách thức hoạt động của một tính năng dịch vụ video cho một nhóm thử nghiệm A/B cụ thể thì sao? Những tình huống này có thể nhanh chóng trở nên tẻ nhạt và tốn thời gian khi tạo người dùng theo cách thủ công. QA Trong bài viết này, chúng tôi sẽ chia sẻ hành trình phát triển một công cụ tự động hóa hoàn toàn quy trình đó. Hãy đi sâu vào! Giới thiệu Công cụ quản lý người dùng của chúng tôi Tại Social Discovery Group, chúng tôi cung cấp các dịch vụ trực tuyến kết nối mọi người trên khắp thế giới. Các sản phẩm của chúng tôi cho phép người dùng giao tiếp thông qua trò chuyện và video cũng như chia sẻ nội dung đa phương tiện. Khi các sản phẩm của chúng tôi phát triển, chúng tôi bắt đầu gặp phải các kịch bản thử nghiệm ngày càng phức tạp. Ví dụ: chúng tôi cần kiểm tra hồ sơ của người dùng có đăng ký đã hết hạn hoặc phân tích chức năng của danh sách liên hệ có hơn 30 mục nhập. Để tạo người dùng "giàu lịch sử", chúng tôi phải thực hiện nhiều truy vấn API, gửi tin nhắn tới RabbitMQ và chạy tập lệnh SQL. Vì các bước này đã được tích hợp vào thử nghiệm tự động của chúng tôi nên nhóm QA thủ công thường yêu cầu chúng tôi thực hiện thử nghiệm tự động để tạo người dùng cần thiết. Theo thời gian, việc tạo một người dùng bắt đầu mất nhiều thời gian hơn so với quá trình thử nghiệm. Do đó, chúng tôi quyết định tìm cách trao quyền cho bất kỳ nhân viên nào để xử lý quá trình tạo người dùng một cách độc lập. Tự động hóa thử nghiệm của chúng tôi được viết bằng C#. Chúng tôi tích cực sử dụng lệnh gọi API tới tài nguyên ứng dụng của mình trong các thử nghiệm tự động. Chẳng hạn, chúng tôi sử dụng phương pháp sau để đăng ký khách hàng: RegisterClient(client, param1, param2, param3); var client = new Client(); Sau khi phân tích khuôn khổ của chúng tôi, chúng tôi kết luận rằng giải pháp dễ dàng nhất để tạo những người dùng cần thiết cho thử nghiệm là phát triển một ứng dụng ASP.NET Web Forms bằng các phương pháp của chúng tôi. Chúng tôi đã hình dung ra một trang web mà những người kiểm tra QA có thể sử dụng để dễ dàng tạo những người dùng cần thiết. Đây là những gì chúng tôi đã làm: Đã tạo một dự án ASP.NET Web Forms mới được gọi là "Công cụ quản lý người dùng" hoặc UMT. Đã thêm dự án thử nghiệm tự động chính dưới dạng mô hình con trong GIT. Đã định cấu hình việc xây dựng và triển khai UMT tới một trong các máy chủ của chúng tôi (dựa trên máy chủ web IIS) thông qua Jenkins. Đã gán một DNS và bắt đầu phát triển chức năng. Đầu tiên, chúng tôi đã thêm một trang để người dùng tạo. Người thử nghiệm có thể chọn các tham số bổ sung và định cấu hình người dùng theo tùy chọn của họ – với tư cách là người dùng mới hoặc với lịch sử trò chuyện lâu dài. Đây là quá trình trông như thế nào: Tạo trang ASPX và thêm các yếu tố cần thiết cho cấu hình người dùng như tuổi, giới tính, tên, quốc gia, v.v. Thêm một phần tử để hiển thị kết quả. Thực hiện logic để gọi các chức năng cần thiết khi nhấp vào nút hành động. Đây là mã cho trang, bao gồm cả phần tử đầu ra. <!DOCTYPE html> <title></title> </head> <body> <div> <div> <label>Client type:</label> </asp:DropDownList> </div> <label>How much clients we should register:</label> </div> </div> <div> </div> </div> </form> </body> </html> <%@ Page Language = "C#" AutoEventWireup = "true" CodeBehind = "WebForm1.aspx.cs" Inherits = "Habrl.Pages.Registration.RegistrationForm1" %> <html xmlns = "http://www.w3.org/1999/xhtml" > <head runat = "server" > <form id = "registration" runat = "server" > <asp:DropDownList ID = "clientType" runat = "server" AutoPostBack = "true" CssClass = "select" OnSelectedIndexChanged = "clientType_OnSelectedIndexChanged" > <asp:ListItem value = "regularClient" Selected = "True" >Regular client</asp:ListItem> <asp:ListItem value = "clientWithChatHistory" >Client with chat history</asp:ListItem> <asp:ListItem value = "inactiveClient" >Inactive Client</asp:ListItem> <div id = "usersCountDiv" runat = "server" > <asp:TextBox ID = "clientsCount" runat = "server" CssClass = "input" Text = "1" ></asp:TextBox> <div class = "errorMsg" > <asp:RequiredFieldValidator Display = "Dynamic" runat = "server" ControlToValidate = "usersCount" ErrorMessage = "Define clients count!" ></asp:RequiredFieldValidator> <asp:RangeValidator Display = "Dynamic" runat = "server" ControlToValidate = "clientsCount" Type = "Integer" MinimumValue = "1" MaximumValue = "30" ErrorMessage = "We can create from 1 till 30 clients at once!" ></asp:RangeValidator> <asp:Button CssClass = "MyButton separateButton" ID = "SubmitButton" runat = "server" text = "Register" OnClick = "OnRegisterButtonClick" ></asp:Button> <div runat = "server" id = "result" ></div> Đây là cách thực hiện logic: int _clientsCount; string _clientType; { _clientsCount = int.Parse(clientsCount.Text); _clientType = clientType.SelectedValue; } { { RegisterClient(client, _clientType); clients.Add(client); }); result.InnerHtml = GenerateTableViewForClientsEnumerable(clients); } } public partial class RegistrationForm : System . Web . UI . Page { protected void Page_Load ( object sender, EventArgs e ) protected void OnRegisterButtonClick ( object sender, EventArgs e ) var clients = new ConcurrentBag<Client>(); Parallel.For( 0 , _clientsCount, _ => var client = new Client(); Khi đăng ký, chúng tôi nhận được bảng sau: Phương thức RegisterClient được sử dụng trong UMT giống với phương thức được sử dụng trong các bài kiểm tra tự động của chúng tôi. Điều này có nghĩa là bất cứ khi nào chúng tôi giới thiệu chức năng mới cho các sản phẩm của mình, các bài kiểm tra tự động của chúng tôi sẽ tự động được cập nhật và những thay đổi đó cũng được phản ánh trong UMT. Về cơ bản, UMT đóng vai trò là triển khai giao diện người dùng đối với các hợp đồng của chúng tôi, cung cấp mã tự động kiểm tra cơ bản. Nhờ có UMT, giờ đây toàn bộ nhóm có thể dễ dàng tạo hồ sơ người dùng cần thiết trong bất kỳ môi trường thử nghiệm nào của chúng tôi chỉ bằng một vài cú nhấp chuột. Nhóm QA thủ công có thể tạo hồ sơ người dùng thậm chí phức tạp nhất một cách độc lập mà không yêu cầu bất kỳ sự tham gia nào từ nhóm tự động hóa. Trước sự ngạc nhiên của chúng tôi, nhóm phát triển cũng đã bắt đầu tận dụng UMT cho các mục đích của họ. Phát triển và Cải thiện Sau khi chúng tôi phát hành UMT, chúng tôi bắt đầu nhận được yêu cầu về các tính năng mới. Chúng tôi đã thêm các trang để quản lý người dùng (bao gồm mô phỏng trạng thái trực tuyến và nhắn tin) và quản lý thanh toán. Sau đó, nhóm di động đã tiếp cận chúng tôi với một mối lo ngại: việc tạo người dùng UMT trên thiết bị di động cần rất nhiều thời gian và công sức để nhập chi tiết email và mật khẩu. Để đáp lại, chúng tôi đã thêm một tính năng nhỏ nhưng hữu ích vào UMT – tạo mã QR có liên kết đăng nhập và liên kết sâu cho ứng dụng di động. Khi chúng tôi tiếp tục phát triển UMT, chúng tôi đã trải qua hai lần thiết kế lại chính và thêm một menu dạng cây vào trang web. Do đó, trang đăng ký người dùng ban đầu đã trải qua quá trình chuyển đổi đáng kể và giờ trông hoàn toàn khác. Trong suốt 5 năm rưỡi tồn tại của UMT, chúng tôi đã mở rộng công cụ này vượt xa mục đích ban đầu là tạo điều kiện thử nghiệm sản phẩm. Chúng tôi đã thêm các phần để tự động hóa các hoạt động DevOps, chẳng hạn như khởi động lại dịch vụ và máy chủ, định cấu hình, dọn dẹp và liên kết môi trường thử nghiệm, đồng thời cung cấp thông tin thống kê, cũng như cơ sở kiến thức, v.v. Trong phần tiếp theo, tôi sẽ xem xét kỹ hơn một số tính năng này. ủy quyền Sau một thời gian, chúng tôi quyết định hạn chế quyền truy cập vào UMT đối với một số nhân viên (ví dụ: những người đang trong thời gian thử việc). Để thực hiện việc này, chúng tôi đã thêm cơ sở dữ liệu và bảng có vai trò và người dùng, xác thực miền đã triển khai và cấp quyền. Với hệ thống này, chúng tôi có thể xác định phiên người dùng và cấp cho người dùng quyền truy cập vào chức năng cụ thể dựa trên quyền của họ. Chúng tôi cũng đã thêm ủy quyền của Google vào UMT, do công ty chúng tôi sử dụng các dịch vụ của Google. Dịch vụ và môi trường thử nghiệm Khi UMT trở thành công cụ phổ biến trong nhóm, nhóm QA của chúng tôi muốn quản lý dịch vụ và giường thử nghiệm thông qua UMT thay vì dựa vào các tập lệnh và công cụ khác nhau như Ansible. Chúng tôi đã thêm khả năng khởi động lại các dịch vụ Docker và Windows, IIS và các nút web cũng như chỉnh sửa cấu hình của các dịch vụ đó. Chúng tôi cũng bao gồm một tính năng để định cấu hình các dịch vụ này và so sánh chúng trên các giường thử nghiệm. TestRail và Jenkins là một phần quan trọng trong công việc của chúng tôi và chúng tôi thường có hơn mười lần chạy thử nghiệm đang diễn ra tại bất kỳ thời điểm nào. Tuy nhiên, có thể khó xác định vị trí của một lượt chạy cụ thể trong số nhiều lượt chạy khác trong Jenkins hoặc để kiểm tra vị trí của nó trong hàng đợi. Để giải quyết vấn đề này, chúng tôi đã phát triển một trang trong UMT hiển thị dữ liệu về tất cả các lần chạy hiện tại và những lần chạy trong hàng đợi. Trang này thăm dò tất cả các phiên bản Jenkins của chúng tôi để thu thập thông tin về các công việc đang chạy, sau đó được trình bày trong các bảng để dễ dàng tham khảo. Tự động hóa thử nghiệm Ngoài ra, UMT cung cấp một trang riêng để tạo TestPlan với TestRun được bật trong TestRail. Chỉ với một vài cú nhấp chuột, người dùng có thể chọn từ một số TestPlan cơ bản với các kịch bản thử nghiệm. UMT cũng đã được chứng minh là hữu ích để phân tích cú pháp kiểm tra tự động không thành công hoặc điều tra hành vi bất thường của người dùng. Trước đây, các tác vụ này yêu cầu mở Fiddler theo cách thủ công cho các truy vấn API hoặc kết nối với cơ sở dữ liệu để thực hiện các truy vấn SQL. Tuy nhiên, với UMT, các trang chuyên dụng cung cấp thông tin kỹ thuật toàn diện về người dùng được tạo trên giường thử nghiệm, giúp giải quyết vấn đề nhanh hơn và hiệu quả hơn. Ngày nay, UMT là một dự án chính thức tiếp tục phát triển khi bộ phận tự động hóa thử nghiệm nhận nhiệm vụ mới để thêm chức năng hoặc sửa lỗi. Nhiệm vụ ưu tiên được bao gồm trong nước rút. UMT vẫn là một công cụ thiết yếu cho nhân viên của chúng tôi, giúp họ tiết kiệm thời gian và công sức bằng cách thu thập nhiều hoạt động thường ngày vào một nơi. Không còn cần ghi chú, lưu các truy vấn API vào Fiddler hoặc Postman hoặc mở SQL Studio để thực hiện các quy trình cơ sở dữ liệu. Vì vậy, nếu công ty của bạn phải đối mặt với những thách thức tương tự, bây giờ bạn biết phải làm gì. Viết bởi Pavel Yasonau, Trưởng nhóm QA Automation tại Social Discovery Group

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

Hợp lý hóa tự động hóa QA: Dự án kỳ nghỉ của chúng tôi để tạo người dùng thử nghiệm

dài quá đọc không nổi

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Hợp lý hóa tự động hóa QA: Dự án kỳ nghỉ của chúng tôi để tạo người dùng thử nghiệm

dài quá đọc không nổi

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN