Những việc bạn bắt buộc phải thành thạo khi làm API testing
Aug 26, 2024
Dưới đây là những thứ mình gặp đi gặp lại khi làm API testing mà mình nghĩ là ai làm cũng nên nắm rõ, nó không hề liên quan đến tool hay ngôn ngữ lập trình. Nếu sau này mình rảnh, mình sẽ viết hướng dẫn cách xử lý từng tình huống. Bắt đầu luôn cho đỡ mất thời gian.
Data test: Với mỗi test lại có 1 data test khác nhau nên chúng ta nên khởi tạo data trong scope của mỗi test. Tất nhiên là những đoạn nào chung có thể viết vào 1 chỗ rồi dùng lại.
Thực hiện actions: Chính là việc call API
Kiểm tra kết quả: Tự động kiểm tra kết quả sau mỗi lần call API
Với mỗi 1 mục trong 3 phần trên ta sẽ có khá nhiều việc phải làm
II. Làm gì với data test:
Khi làm việc với data test bạn sẽ nhận ra được là có 2 kiểu data input đầu vào:
Dùng lại được
Không dùng lại được
“Dùng lại được” có nghĩa là nếu là cái data test đấy bao nhiêu lần đi chăng nữa thì vẫn không ảnh hưởng đến kết quả hay không hề gây ra error.
“Không dùng lại được” có nghĩa là cái data test đó bạn chỉ được dùng 1 lần. Ví dụ như khi bạn register 1 account trong hệ thống, bạn không thể dùng đi dùng lại 1 email được. Hệ thống sẽ báo lỗi là “email đã tồn tại”
Nói đến đây có thể bạn sẽ nghĩ là thế thì chỉ cần xử lý data “không dùng lại được” thôi –> Đúng mà cũng không đúng.
Bạn nên xử lý cả 2 phần data trên trước khi call API
Với data dùng lại được, bạn nên có thêm 1 cái gì đó để bạn có thể phân biệt sau mỗi lần run hoặc để phân biệt giữa manual test và automation test, sau này nếu có lỗi thì có nhiều thông tin để debug hơn. Ví dụ như trường thông tin mô tả, bạn có thể cho thêm date-time kiểu như "Automation test at 08/07/2019 16:40:22"
Với data không dùng lại được, bạn sẽ cần có thêm 1 cái gì đó để phân biệt và không bị trùng lặp. Có 2 cách khá dễ dàng đó là sử dụng: UUID hoặc timestamp. Ví dụ: testemail1562310163272@sharklasers.com
Với các loại data khác, bạn cũng phải cần biết cách để xử lý như phone number, name, company, date-time, ID… Hãy tìm những function hoặc library để giúp bạn tạo ra data 1 cách nhanh chóng. Ví dụ như Faker của Java, Faker của JS hay Function của Jmeter
Với các loại data mà nó nằm ở response của API khác thì bạn phải biết cách extract data. Nếu data dạng json thì có 2 loại dữ liệu bạn phải biết cách lấy, đó là dạng object và array. Bạn có thể đọc thêm https://goessner.net/articles/JsonPath/ và thực hành trước ở đây http://jsonpath.com/
Domain của URL nên được config 1 cách dễ dàng. Ví dụ: {{url}}/get?foo1=bar1&foo2=bar2 thay vì http://postman-echo.com/get?foo1=bar1&foo2=bar2
Những test case có dùng chung path thì cũng nên đặt biến để dùng chung, sẽ tránh được các lỗi về typos (lỗi chính tả).
Test case để test 1 api thì nên viết chung phần call API ra 1 function. Ví dụ như hình.
IV. Check kết quả API như thế nào?
Nên check response code cho tất cả các test
Nếu API nào có liên quan đến logic thì bạn phải biết extract dữ liệu từ response trả về và sử dụng các library giúp check kết quả như JUnit/hamscret/AssertJ hoặc có thể sử dụng các built-in function của các tools như trong Postman hoặc Jmeter.
V. Kết luận
Trên đây là những tasks mà hầu như test API nào cũng gặp phải, hãy cố gắng thành thạo chúng để có thể viết test hiệu quả hơn.
