Bài viết này sẽ gửi đến bạn những câu hỏi và gợi ý câu trả lời phỏng vấn vị trí API Tester. Hi vọng bài viết này sẽ giúp cho các bạn tự tin hơn trước buổi phỏng vấn ứng tuyển...
Đọc ngay nhé, nếu có thêm câu hỏi vui lòng viết comment giúp mình. Xin chân thành cảm ơn.
Câu hỏi 1: API là gì? Test API với test website có gì khác nhau ?
Gợi ý trả lời
Định nghĩa API là Application Programming Interface - Giao diện lập trình ứng dụng. Là một tập hợp các quy tắc, giao thức và công cụ cho phép các ứng dụng phần mềm khác nhau giao tiếp và tương tác với nhau. Từ API có thể xác định được phương thức và định dạng dữ liệu mà ứng dụng sử dụng để request và trao đổi thông tin.
API là thực hiện test back-end mà không cần tương tác GUI. còn test website sẽ tập trung cả test giao diện, và tác động của người dùng nên ứng dụng
Câu hỏi 3: Bạn đã report lỗi liên quan đến API chưa? Nội dung bug như thế nào?
Gợi ý trả lời
Nội dung bug API khác so với 1 bug khi test giao diện. Bug về API cần đề cập các thông tin URL, method, Payload trên truyền vào trong body, request và Respon trả về.
Câu hỏi 4: Những ký thuật nào được sử dụng khi thiết kế Testcase API
Gợi ý trả lời
Kỹ thuật được sử dụng: Phân vùng tương đương, giá trị biên, bảng quyết định, đoán lỗi,
Câu hỏi 5: Method nào mà bạn hay sử dụng khi Test API ? liệt kê chúng và mô tả sơ qua.
Gợi ý trả lời
Có 9 loại method API:
- GET: Sử dụng để lấy thông tin từ server theo URI đã cung cấp.
- HEAD: Giống với GET nhưng response trả về không có body, chỉ có header.
- POST: Gửi thông tin tới sever thông qua các parameters HTTP.
- PUT: Ghi đè tất cả thông tin của đối tượng với những gì được gửi lên.
- PATCH: Ghi đè các thông tin được thay đổi của đối tượng.
- DELETE: Xóa resource trên server.
- CONNECT: Thiết lập một kết nối tới server theo URI.
- OPTIONS: Mô tả các tùy chọn giao tiếp cho resource.
- TRACE: Thực hiện một bài test loop-back theo đường dẫn đến resource.
2 phương thức API hay sử dụng là POST và GET
Câu hỏi 6: Cho biết thành phần của một Request. Từng thành phần ấy có chức năng, nhiệm vụ gì?
Gợi ý trả lời
Một Request chuẩn sẽ có 4 phần:
-
Phần URL: là địa chỉ đi đến request, thường là đường dẫn tới một hàm xử lí logic. Dùng để định danh nguồn tài nguyên mà client yêu cầu, bắt buộc phải có ít nhất là dấu “/”.
-
Phần Method: có thể là: GET, POST, HEAD, PUT và DELETE. Hai phương thức phổ biến nhất là GET và POST, trong ví dụ trên là phương thức GET thường dùng để yêu cầu tài nguyên cung cấp trong trường URL.
-
Header: Là nơi chứa các thông tin cần thiết của 1 request nhưng end-users không biết có sự tồn tại của nó. Ví dụ: độ dài của request body, thời gian gửi request, loại thiết bị đang sử dụng, loại định dạng cái response mà client có đọc được…
-
Body: Là nơi chứa thông tin mà client sẽ điền. Dữ liệu gửi từ client đến server trong gói tin HTTP request. Đa số các gói tin gửi theo phương thức GET sẽ có Body trống, các phương thức như POST hay PUT thường dùng để gửi dữ liệu nên sẽ có bao gồm dữ liệu trong trường Body
Một số header thông dụng như:
-
Accept: loại nội dung có thể nhận được từ thông điệp response. Ví dụ: text/plain, text/html
-
Accept-Encoding: các kiểu nén được chấp nhận. Ví dụ: gzip, deflate, xz, exi…
-
Connection: tùy chọn điều khiển cho kết nối hiện thời. Ví dụ: Keep-Alive, Close…
-
Cookie/Session: thông tin HTTP Cookie từ server
Câu hỏi 7: Sự khác nhau giữa method POST và PUT
Gợi ý trả lời
Dựa trên bản chất của method là
- POST: Gửi thông tin tới sever thông qua các parameters HTTP.
- PUT: Ghi đè tất cả thông tin của đối tượng với những gì được gửi lên.
Nói cách khác PUT được sử dụng để cập nhật hoặc tạo tài nguyên nếu nó không tồn tại, trong khi POST được sử dụng đặc biệt để tạo tài nguyên mới để sử dụng chúng phù hợp cho các tính năng Thêm mới hay Update
Câu hỏi 8: Các lỗi API phổ biến thường gặp là gì? lấy ví dụ cho từng trường hợp phát sinh lỗi
Gợi ý trả lời
Có 5 loại hay gặp là:
1xx (100 – 199): Information responses / Phản hồi thông tin – Yêu cầu đã được chấp nhận và quá trình xử lý yêu cầu đang được tiếp tục.
2xx (200 – 299): Successful responses / Phản hồi thành công – Yêu cầu đã được máy chủ tiếp nhận, hiểu và xử lý thành công.
3xx (300 – 399): Redirects / Điều hướng – Phía client cần thực hiện hành động bổ sung để hoàn tất yêu cầu.
4xx (400 – 499): Client errors / Lỗi phía client – Yêu cầu không thể hoàn tất hoặc yêu cầu chứa cú pháp không chính xác.Đây là lỗi từ phía client do yêu cầu không hợp lệ.
5xx (500 – 599): Server errors / Lỗi phía máy chủ – Máy chủ không thể hoàn thành yêu cầu được cho là hợp lệ. Khi 5xx xảy ra, bạn chỉ có thể đợi để bên hệ thống máy chủ xử lý xong.
Ví dụ cho từng trường hợp tương ứng với lỗi trên
200 – OK: Ví dụ: trang web hoạt động đúng, dữ liệu trả về chính xác.
GET: Tài nguyên được tìm va trả về thành công.
POST/PUT: Hành động tạo, cập nhật dữ liệu thành công.
Với 201 - Created: Vi dụ: report thành công một bug, hoặc tạo thành công một sản phẩm trên trnag bán hàng
Với 400 – Bad Request: Ví dụ: Nhập sai giá trị tham số (invalid - không hợp lệ), user không nhập tham số nhưng yêu cầu thiếu tham số là trường required.
Với 401 – Unauthorized: Ví dụ: User nhập sai mật khẩu hoặc đang sử dụng nhưng log out và chưa đăng nhập lịa nhưng vẫn nhấn vào các button chức năng trên hệ thống
Với 403 – Forbidden: Ví dụ: khi người dùng cố gắng truy cập vào tài khoản người dùng khác or truy cập vào những tính năng không được phân quyền
Với 404 – Not Found: Ví dụ: khi người dùng truy cập vào một trang web không tồn tại.
Với 500 – Server error: Thông báo lỗi chung về các vấn đề ở phía server, như môi trường không hoạt động (thiếu thư viện, không thể kết nối cơ sở dữ liệu)
Ví dụ: lỗi kết nối cơ sở dữ liệu, lỗi xử lý lỗi, hay lỗi không xác định được.
Với 503 – Service Unavailable: Mã trạng thái HTTP được sử dụng để chỉ ra rằng máy chủ không thể xử lý yêu cầu của bạn tại thời điểm đó vì nó đang tạm ngưng hoạt động hoặc bảo trì. Đây thường là một thông báo tạm thời, nhưng đôi khi nó cũng có thể chỉ ra rằng máy chủ không thể xử lý yêu cầu vì quá tải hoặc lỗi phần mềm.
Câu hỏi 9: Bạn đã test Security cho API chưa ? Phân biệt Authorize và Authentication
Gợi ý trả lời
-
Authentication (xác thực) có nghĩa là xác nhận danh tính của riêng bạn, trong khi authorization (ủy quyền) có nghĩa là cấp quyền truy cập vào hệ thống. Ví dụ như việc Xác thực thông tin đăng nhập của bạn như Tên người dùng / ID người dùng và mật khẩu để xác minh danh tính của bạn và đôi khi kết hợp với các yếu tố xác thực, trong đó đề cập đến các cách khác nhau để được xác thực.
-
Authorization xảy ra sau khi hệ thống của bạn được authentication (xác thực) thành công, cuối cùng cho phép bạn toàn quyền truy cập các tài nguyên như thông tin, file, cơ sở dữ liệu, quỹ, địa điểm, hầu hết mọi thứ. Nói một cách đơn giản, authorization xác định khả năng của bạn để truy cập hệ thống và ở mức độ nào. Khi danh tính của bạn được hệ thống xác minh sau khi xác thực thành công, bạn sẽ được phép truy cập tài nguyên của hệ thống.
Nói một cách đơn giản, authentication là quá trình xác minh bạn là ai, trong khi authorization là quá trình xác minh những gì bạn có quyền truy cập.
Cảm ơn bạn đã đọc bài viết, hãy chia sẻ nó nếu bạn thấy hữu ích.