Những điểm lưu ý khi làm Automation Test cho người mới

Anh Tester chia sẻ đến bạn những điểm lưu ý khi làm Automation Test cho người mới.

🔆 Lưu ý về cách dùng Locators

Element Locators là một yếu tố quan trọng để quyết định sự ổn định một một automation test script. Nhiều bạn mới học thường không quan tâm nhiều đến việc lấy locator hiệu quả mà chỉ lấy để nó chạy được ngay lúc đó. Tuy nhiên việc một XPath chạy được ngay lúc đó không có nghĩa là một thời gian sau nó sẽ chạy tốt. Nhất là khi có một sự thay đổi nhỏ trên ứng dụng và tác động đến cấu trúc của XPath.
Việc đầu tư thời gian để tìm hiểu về locator sẽ giúp ích rất nhiều và cũng giảm thời gian để sửa đi sửa lại sau này nếu dùng XPath chuẩn. Việc tìm và sửa XPath nói riêng hay Locator nói chung là một việc làm mệt mỏi và tốn thời gian.

Ví dụ 2 XPath dưới này là cùng tìm một element, nhưng cách thứ nhất sẽ hay hơn. Nó dùng kiểu Xpath tương đối. Dựa vào Text thì khả năng thay đổi Text ít hơn là khả năng thay đổi thứ tự ví trí của các thẻ HTML như cách 2.

XPath 1: //button[normalize-space()='Login']
XPath 2: //form[1]/div[4]/button[1]

🔆 Lưu ý về việc chuẩn bị Test Data

Việc chuẩn bị Test Data (hay còn gọi là bước Pre-Conditions) cũng là một việc quan trọng. Phần lớn script lỗi là do locator, phần còn lại là về test data. Nhiều bạn thường sử dụng data có sẵn để test và không tự chuẩn bị data.

Ví dụ như khi kiểm tra chức năng tìm kiếm thì lấy ngẫu nhiên một tên sản phẩm đang tồn tại để search. Tuy nhiên cách này chỉ là cách tạm thời và mang nhiều rủi ro, vì có thể sau một thời gian tên sản phẩm đó bị đổi hoặc bị xoá bới một người khác, và khi đó script sẽ không tìm ra sản phẩm và trả về kết quả là Fail.

Việc tự tạo một data để test sẽ giúp chúng ta kiểm soát được điều kiện và đảm bảo luôn có đúng dữ liệu cần thiết, ví dụ như kịch bản phía trên, thay vì chọn ngẫu nhiên một tên sản phẩm thì việc Tạo mới sản phẩm trước để có data cần thiết, hoặc có thể tham khảo thêm một số cách để chuẩn bị data như bên dưới tương tự phần dưới về việc khôi phục Test Data.

🔆 Lưu ý về khôi phục Test Data

Việc khôi phục Test Data (Post-Conditions) cũng quan trọng như bước chuẩn bị, ví dụ như sau khi thực hiện test case thay đổi mật khẩu của một tài khoản thành công, chúng ta phải có bước để khôi phục lại giá trị cũ để những test khác có dùng đến tài khoản (hoặc data đó nói chung) không bị ảnh hưởng, tương tự như việc đổi quyền hạn, trạng thái của những data cần test.

Một số ý tưởng để restore lại data sau khi chạy automation test script

Dùng luôn UI để restore sau khi chạy test xong (Ví dụ sau khi tạo tài khoản và verify thành công thì xoá tài khoản đó trên web UI luôn). Cách này không cần can thiệp vào DB tuy nhiên sẽ tốn thời gian và làm script trở nên dài hơn.
Có API thì nên gọi API, nếu có thể nhờ dev viết thêm cho những API để sử dụng thì càng tốt. Cách này nhanh & an toàn tuy nhiên cần phải có sẵn những API cần thiết.
Xoá thông qua query SQL. Ví dụ tạo user có username là anhtester thì query user đó theo username ra để xoá, tuy nhiên đòi hỏi phải có quyền connect trực tiếp vào data và mang nhiều rủi ro.
Snapshot cả Database trước khi chạy test, test xong hết thì restore cả DB lại. Cách này sẽ đảm bảo DB sạch như ban đầu.
Không cần restore trên môi trường test nếu không lo lắng về việc data rác. Cái này không phải giải pháp hay.
Tạo sẵn 1 list các câu query cần thiết trước, chạy nó (hoặc nhờ DB admin chạy) sau khi run test. Áp dụng trong trường hợp không có quyền thực hiện trên DB mà phải nhờ DB admin chạy giúp các câu lệnh.

🔆 Lưu ý về việc phụ thuộc giữa các test cases

Các test cases không nên phụ thuộc nhau, hay nói cách khác nó nên độc lập.

Ví dụ mình có 3 test cases, thì 3 testcase này nên độc lập nhau, nếu chỉ lấy ra một trong ba thì vẫn có khả năng chạy được, tránh việc các test phụ thuộc gì đó với nhau và khi chạy riêng thì bị lỗi là không đúng. Nếu có ràng buộc thì cần chuẩn bị nó như một pre-condition tương tự bước chuẩn bị Test Data.

Việc phụ thuộc nhau còn dẫn đến tình huống nếu một test cases gặp lỗi sẽ ảnh hưởng đến những test cases khác phía sau.

Ví dụ: Có 3 cases là Add, Edit, Delete. Nếu thiết kế ràng buộc nhau chạy theo thứ tự là Add > Edit > Delete mà khi chạy case Add bị lỗi không add được Data thì case Edit không có được data để thực hiện edit và tương tự case Delete cũng không tìm thấy item để xoá.

🔆 Lưu ý về cách sử dụng cơ chế Waits

Đối với việc làm automation test trên Website, Mobile hay Desktop thì đều cần có một cơ chế Waits ổn định. Vì chúng ta kiểm thử chúng trên môi trường Mạng (network) nên việc ổn định là tương đối chứ không tuyệt đối. Hơn nữa các Element chúng sắp xếp và xuất hiện không như lý tưởng, có thể chậm, delay, hiệu ứng, lớp chồng lớp,...Chính vì thế nếu không có Waits chuẩn chỉnh sẽ dẫn đến lỗi thường xuyên.

Tức nhiên thì tuỳ cộng nghệ bạn sử dụng là gì khi làm Automation Test thì sẽ thiết lập cho phù hợp. Như trong Selenium thì nên dùng dạng Explicit Waits chẳng hạn.

Lưu ý là chúng ta hạn chế dùng wait dạng Sleep hay Delay code dạng chờ đợi cứng. Vì nó làm chậm code rất nhiều. Kiểu này thì mình thấy nhiều bạn mới làm automation test ưa dùng đó nhe 😁
Ví dụ trong Java hay C# có Thread.sleep, Task.delay,...

Tuy nhiên trong một số trường hợp vẫn phải dùng Sleep nhé. Đừng cứng nhắc quá 😄

======================

Yeah trên là những góp ý của An dành cho các bạn mới khi làm Automation Test. Hy vọng giúp ích được các bạn trong giai đoạn đầu nghiên cứu tìm hiểu. Chúc các bạn làm việc vui khoẻ 👋