Sử dụng Postman trong kiểm thử web API

Kiêm thử và đảm bảo chất lượng phần mềm

MỤC LỤC

Nhóm 02

1

1

Lớp CNPM 62


Kiêm thử và đảm bảo chất lượng phần mềm

DANH MỤC CÁC BẢNG BIỂU

Nhóm 02

2

2

Lớp CNPM 62


MỞ ĐẦU
1. Tổng quan về tình hình thực tiễn của kiểm thử phần mềm nói chung và API
testing nói riêng
[1]Nhắc đến ngành Công nghiệp phần mềm (PM) là người ta thường nhắc đến
lập trình viên - những người trực tiếp làm ra các sản phẩm PM. Vậy có phải những

sản phẩm do các lập trình viên làm ra có thể ứng dụng ngay hay không? Câu trả lời
là không.
Bất kỳ một PM hay ứng dụng nào trước khi đưa vào hoạt động đều phải trải
qua khâu kiểm tra. Những người phụ trách công việc này được gọi là Tester Chuyên viên kiểm thử phần mềm. Tuy chưa nổi tiếng và phổ biến như chức danh
lập trình viên nhưng chuyên viên kiểm thử phần mềm đã, đang và sẽ là một trong
những nghề “hot”, một nghề không thể thiếu được trong ngành Cơng nghiệp PM.
Cơng việc của tester là tìm kiếm các lỗi của hệ thống PM hoặc thẩm định, xác
minh xem hệ thống PM có đáp ứng các yêu cầu kỹ thuật và yêu cầu nghiệp vụ hay
không. Tester giúp cho sản phẩm được hoàn thiện nhằm đáp ứng yêu cầu đặt ra của
khách hàng. Sản phẩm hoàn thiện, chất lượng cao sẽ tạo thêm niềm tin và uy tín của
cơng ty với đối tác. Nếu khơng có khâu này, tình trạng khách hàng trả sản phẩm về
sẽ xảy ra thường xun. Như vậy có thể thấy tester vơ cùng quan trọng, có thể nói
đây là khâu sống cịn của việc phát triển PM và API testing là một phần của khâu
sống cịn đó
2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của API testing
[2]API đã được áp dụng từ rất lâu rồi, nhưng để phổ biến với thuật ngữ API
Testing thì chưa nhiều.
Đa số các tester test API các bạn chỉ đều biết và dừng lại ở việc có API từ đội
Phát triển đưa, và tiến hành gọi từng API một. Và giai đoạn test API đều bi đẩy
xuống cuối cùng ở giai đoạn làm sản phẩm.
Nói đơn giản, API là cái cầu nối giữa client và server. Client ở đây có thể là
web trên máy tính, app trên điện thoại sử dụng hệ điều hành khác nhau và được viết
bằng những ngôn ngữ khác nhau. Tương tự, server back-end cũng được viết bằng
các ngôn ngữ khác nhau. Để 2 thằng này có thể nói chuyện được với nhau chúng
phải nói cùng 1 ngơn ngữ chính là API.


Trong dự án phần mềm, phần server và client làm độc lập với nhau nên có
nhiều chỗ client chưa làm xong, mình khơng thể chờ xong xi mới test được như
vậy là quá muộn–> Lúc này việc test cần phải thực hiện qua một cái công cụ khác

để kiểm tra dữ liệu trao đổi giữa client và server có chính xác hay không cần được
thực hiện càng sớm càng tốt
Kể cả khi client làm xong rồi, nếu mình test trên client mà thấy lỗi liên quan
đến logic và dữ liệu thì cũng cần test thêm cả API để biết chính xác là server sai hay
client sai –> sửa lỗi sẽ nhanh hơn.
Ngày nay các hệ thống tích hợp có phương thức trao đổi client và server là
đang rất phổ biến. Tester dù manual hay auto đều cần có kiến thức api testing càng
sớm càng tốt sẽ hỗ trợ trong việc test hiệu quả và giảm thiểu các lỗi nguy hiểm nhất
xảy ra.


CHƯƠNG 1: CÁC KHÁI NIỆM CƠ BẢN
1.1 Protocol dùng trong Restful API
Protocol là gì?
[3]Giả sử: Có 2 người A và B nói chuyện với nhau qua điện thoại, nếu người A
hỏi 1 câu rồi im lặng, người B sẽ biết rằng người A đang chờ đợi câu trả lời và đến
lượt người B nói. Hai chiếc máy tính cũng giao tiếp 1 cách lịch sự như vậy và được
mô tả với cái thuật ngữ “Protocol” – giao thức.
 Giao thức chính là những luật lệ được chấp thuận để 2 cái máy tính có
thể nói chuyện với nhau.
Tuy nhiên, luật lệ này chặt chẽ hơn rất nhiều so với giao tiếp giữa người với
người. Máy tính sẽ khơng thơng minh để có thể nhận biết 2 câu “A là chồng B” hay
“B là vợ A” có cùng ý nghĩa. Để 2 máy tính giao tiếp hiệu quả, server phải biết
chính xác cách mà client sắp xếp cái message nó gửi lên như thế nào.
Chúng ta đã từng nghe đến những Protocol cho những mục đích khác nhau, ví
dụ như Mail có POP hay IMAP, message có XMPP, kết nối thiết bị: Bluetooth.
Trong web thì Protocol chính là HTTP – HyperText Transfer Protocol, vì sự phổ
biến của nó mà hầu hết các cơng ty chọn nó là giao thức cho các API.
HTTP hoạt động như thế nào?
Cuộc sống của HTTP xoay quanh cái vòng luẩn quẩn: Request và Response.

Client gửi request, server gửi lại response là liệu server có thể làm được cái client
muốn hay không. Và API được xây dựng trên chính 2 thành phần: Request và
Reponse. Trước tiên, ta phải hiểu cấu trúc của mỗi thành phần.


a. Request
Một request đúng chuẩn cần 4 thứ:
•
•
•
•

URL
Method
Header
Body

Hình 1 Request
URL: là 1 cái địa chỉ duy nhất cho 1 thứ (dùng danh từ), có thể là web page,
image, hoặc video. API mở rộng cái ý tưởng gốc của URL cho những thứ khác, ví
dụ: customers, products. Và như thế client dễ dàng cho server biết cái nó muốn là
cái gì, những cái này còn được gọi chung là “resources” – nguồn lực.
Method: là cái hành động client muốn tác động lên “resources”, và nó thường
là động từ. Có 4 loại Method hay được dùng:
• GET: Yêu cầu server đưa lại resource: Hãy tưởng tượng ra cái cảnh vào
fb, tay vuốt new feeds.
• POST: Yêu cầu server cho tạo ra 1 resource mới. Ví dụ: đăng ký 1
chuyến đi ở GrabBike.
• PUT: Yêu cầu server cho sửa / thêm vào resource đã có trên hệ thống.
Ví dụ: Edit 1 post ở trên fb.

• DELETE: u cầu server cho xóa 1 resourse. Cái này chắc chả cần ví
dụ.
Header: 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: nơi chứa thông tin mà client sẽ điền. Giả sử bạn đặt 1 cái bánh pizza, thì
thơng tin ở phần body sẽ là: Loại bánh pizza, kích cỡ, số lượng đặt.
b. Response
Sau khi nhận được request từ phía client, server sẽ xử lý cái request đó và gửi
ngược lại cho client 1 cái response. Cấu trúc của 1 response tương đối giống phần
request nhưng Status code sẽ thay thế cho URL và Method.
Một response có cầu trúc 3 phần:


• Status code
• Header
• Body

Hình 2 Response
Status code: là những con số có 3 chữ số và có duy nhất 1 ý nghĩa. Chắc các
bạn cũng khơng cịn lạ lẫm với những Error “404 Not Found” hoặc “503 Service
Unavailable”,.. Danh sách các status code có ở:
/>Header và Body: tương tự như Request
1.2 Định dạng dữ liệu JSON và XML
a Định dạng JSON
Ngày nay, JSON được sử dụng nhiều trong Restful API. Nó được xây dựng từ
Javascript, ngơn ngữ mà được dùng nhiều, tương thích với cả front-end và back-end
của cả web app và web service. JSON là 1 định dạng đơn giản với 2 thành phần:
keys và values. Key thể hiện thuộc tính của Object cịn Value thể hiện giá trị của
từng Key.

Ví dụ:
• Trường hợp đơn giản

Hình 3 Ví dụ key nằm bên trái, value ở
bên phải
• Trường hợp đặc biệt


Hình 4 Ví dụ key có values là 1 dãy key + value
c. Định dạng XML
Trong JSON dùng { } và [ ] để dánh dấu dữ liệu. XML thì tương tự như
HMTL, dùng thẻ để đánh dấu và được gọi là nodes.
Lấy ln ví dụ ở trên nhưng viết bằng xml, nó sẽ như thế này:

Hình 5 Ví dụ XML

d. Định dạng dữ liệu được sử dụng thế nào trong HTTP
Phần header có chức năng lưu những thơng tin mà người dùng khơng biết,
trong đó có 1 thành phần xác định format của data: Content-Type


Khi client gửi Content-Type trong header của request, nó đang nói với server
rằng dữ liệu trong phần body của request là được định dạng theo kiểu đó. Khi client
muốn gửi JSON nó sẽ đặt Content-Type là “application/json”. Khi bắt đầu nhận
request, server sẽ check cái ContentType đầu tiên và như thế nó biết cách đọc dữ
liệu trong body. Ngược lại, khi server gửi lại client 1 response, nó cũng gửi lại
Content-Type để cho client biết cách đọc body của response.

Hình 6 Giao tiếp giữa Client và Server
Đôi khi client chỉ đọc được 1 loại định dạng, ví dụ là JSON mà server lại trả

về XML thì client sẽ bị lỗi. Do đó, 1 thành phần khác ở trong header là Accept sẽ
giúp client xử lý vấn đề trên bằng cách nói ln với server loại nó có thể đọc được.
Ví dụ : Accept : “application/json” . Chốt lại: dựa vào 2 thành phần Content-Type
và Accept, client và server có thể hiểu và làm việc một cách chính xác.


CHƯƠNG 2: TỔNG QUAN VỀ API VÀ API TESTING
2.1 Tổng quan về API
Hiện nay API nói chung và Web API nói riêng đang được ứng dụng ngày càng
nhiều. Kiến trúc ứng dụng hiện đại ngày nay ngày càng phân tán, không phụ thuộc
ngôn ngữ đã thúc đẩy việc ứng dụng API. Vậy API là gì? Nguồn gốc và ưu điểm
của nó là như thế nào?
2.1.1 API là gì?
API là các phương thức, giao thức kết nối với các thư viện và ứng dụng khác.
Nó là viết tắt của Application Programming Interface – giao diện lập trình ứng
dụng. API cấp khả năng truy xuất đến một tập các hàm hay dùng. Và từ đó có thể
trao đổi dữ liệu giữa các ứng dụng.

Ví dụ: Khi sử dụng một ứng dụng trên điện thoại di động, ứng dụng kết nối
Internet và gửi dữ liệu tới máy chủ. Sau đó, máy chủ lấy ra dữ liệu đó, diễn giải
nó, thực hiện các hành động cần thiết và gửi nó trở lại điện thoại. Ứng dụng sau
đó sẽ diễn giải dữ liệu đó và trình bày thơng tin bạn muốn theo cách có thể đọc
được.

Hình 7 Tổng quan về API
2.1.2 API thường ứng dụng vào đâu?
Web API: là hệ thống API được sử dụng trong các hệ thống website. Hầu hết
các website đều ứng dụng đến Web API cho phép bạn kết nối, lấy dữ liệu hoặc cập
nhật cơ sở dữ liệu. Ví dụ: Bạn thiết kế chức nằng login thông Google, Facebook,
Twitter, Github… Điều này có nghĩa là bạn đang gọi đến API của. Hoặc như các

ứng dụng di động đều lấy dữ liệu thông qua API.


API trên hệ điều hành: Windows hay Linux có rất nhiều API, họ cung cấp các
tài liệu API là đặc tả các hàm, phương thức cũng như các giao thức kết nối. Nó giúp
lập trình viên có thể tạo ra các phần mềm ứng dụng có thể tương tác trực tiếp với hệ
điều hành.
API của thư viện phần mềm hay framework: API mô tả và quy định các hành
động mong muốn mà các thư viện cung cấp. Một API có thể có nhiều cách triển
khai khác nhau và nó cũng giúp cho một chương trình viết bằng ngơn ngữ này có
thể sử dụng thư viện được viết bằng ngơn ngữ khác. Ví dụ bạn có thể dùng Php để
u cầu một thư viện tạo file PDF được viết bằng C++.
2.1.3 Web API là gì?
Web API là một phương thức dùng để cho phép các ứng dụng khác nhau có
thể giao tiếp, trao đổi dữ liệu qua lại. Dữ liệu được Web API trả lại thường ở dạng
JSON hoặc XML thông qua giao thức HTTP hoặc HTTPS.

Hình 8 Web API
2.1.4 Những điểm nổi bật của Web API
Web API hỗ trợ restful đầy đủ các phương thức: Get/Post/put/delete dữ liệu.
Nó giúp bạn xây dựng các HTTP service một cách rất đơn giản và nhanh chóng. Nó
cũng có khả năng hỗ trợ đầy đủ các thành phần HTTP: URI, request/response
headers, caching, versioning, content format.
Tự động hóa sản phẩm: Với Web API, chúng ta sẽ tự động hóa quản lý cơng
việc, cập nhật luồng công việc, giúp tăng năng suất và tạo hiệu quả công việc cao
hơn.


Khả năng tích hợp linh động : API cho phép lấy nội dung từ bất kỳ website
hoặc ứng dụng nào một cách dễ dàng nếu được cho phép, tăng trải nghiệm người

dùng. API hoạt động như một chiếc cổng, cho phép các công ty chia sẻ thông tin
được chọn nhưng vẫn tránh được những yêu cầu không mong muốn.
Cập nhật thơng tin thời gian thực : API có chức năng thay đổi và cập nhật thay
đổi theo thời gian thực. Với công nghệ này, dữ liệu sẽ được truyền đi tốt hơn, thơng
tin chính xác hơn, dịch vụ cung cấp linh hoạt hơn.
Có tiêu chuẩn chung dễ sử dụng : Bất kỳ người dùng, cơng ty nào sử dụng
cũng có thể điều chỉnh nội dung, dịch vụ mà họ sử dụng.
Hỗ trợ đầy đủ các thành phần MVC như: routing, controller, action result,
filter, model binder, IoC container, dependency injection, unit test.
2.1.5 Web API hoạt động như thế nào?
Đầu tiên là xây dựng URL API để bên thứ ba có thể gửi request dữ liệu đến
máy chủ cung cấp nội dung, dịch vụ thông qua giao thức HTTP hoặc HTTPS.
Tại web server cung cấp nội dung, các ứng dụng nguồn sẽ thực hiện kiểm tra
xác thực nếu có và tìm đến tài nguyên thích hợp để tạo nội dung trả về kết quả.
Server trả về kết quả theo định dạng JSON hoặc XML thông qua giao thức
HTTP/HTTPS.
Tại nơi yêu cầu ban đầu là ứng dụng web hoặc ứng dụng di động , dữ liệu
JSON/XML sẽ được parse để lấy data. Sau khi có được data thì thực hiện tiếp các
hoạt động như lưu dữ liệu xuống Cơ sở dữ liệu, hiển thị dữ liệu…
2.1.6 Ưu và nhược điểm của Web API
Ưu điểm:
Web API được sử dụng hầu hết trên các ứng dụng desktop, ứng dụng mobile
và ứng dụng website.
Linh hoạt với các định dạng dữ liệu khi trả về client: Json, XML hay định
dạng khác.
Nhanh chóng xây dựng HTTP service: URI, request/response headers,
caching, versioning, content formats và có thể host trong ứng dụng hoặc trên IIS.


Mã nguồn mở, hỗ trợ chức năng RESTful đầy đủ, sử dụng bởi bất kì client nào

hỗ trợ XML, Json.
Hỗ trợ đầy đủ các thành phần MVC như: routing, controller, action result,
filter, model binder, IoC container, dependency injection, unit test.
Giao tiếp hai chiều được xác nhận trong các giao dịch, đảm bảo độ tin cậy cao.

Hình 9 Ưu điểm API
Nhược điểm:
Web API chưa hoàn toàn phải là RESTful service, mới chỉ hỗ trợ mặc định
GET, POST
Để sử dụng hiệu quả cần có kiến thức chuyên sâu, có kinh nghiệm backend tốt
Tốn thời gian và chi phí cho việc phát triển, nâng cấp và vận hành
Có thể gặp vấn đề về bảo mật khi hệ thống bị tấn công nếu không giới hạn
điều kiện kỹ.


2.2 API Testing
2.2.1 Định nghĩa về API Testing
API testing là một loại kiểm thử phần mềm bao gồm kiểm tra trực tiếp các
giao diện lập trình ứng dụng (API) và là một phần của kiểm thử tích hợp để xác
định xem chúng có đáp ứng mong đợi về chức năng, độ tin cậy, hiệu suất và bảo
mật khơng.
Vì API thiếu GUI, API testing được thực hiện ở tầng nghiệp vụ Business layer.
API testing được coi là quan trọng cho automation testing vì các API đóng vai
trị là giao diện chính cho logic ứng dụng và do GUI test rất khó duy trì với các chu
kỳ release ngắn và các thay đổi thường được sử dụng trong Agile và DevOps.
API Testing hoàn toàn khác với GUI Testing và chủ yếu tập trung vào lớp
logic nghiệp vụ của kiến trúc phần mềm. Thử nghiệm này sẽ không tập trung vào
giao diện của ứng dụng.

Hình 10 API Testing

2.2.2 Cần chuẩn bị những gì để bắt đầu kiểm thử API?
Thiết lập môi trường kiểm thử API
Thiết lập môi trường kiểm thử API với tập hợp các tham số cần thiết của API.
Cấu hình cơ sở dữ liệu và máy chủ theo các yêu cầu của ứng dụng.
Thử thực hiện gọi API để đảm bảo khơng có lỗi gì trước khi tiến hành kiểm
thử.
Xác định phạm vi và yêu cầu kiểm thử
Đặt các câu hỏi liên quan đến API để xác định phạm vi và yêu cầu kiểm thử.
Ví dụ:


• Những môi trường nào nên sử dụng API như thế nào?
• Độ ưu tiên trong kiểm thuer API?
• Điều gì sẽ xảy ra trong những trường hợp bình thường,trường hợp bất
thường
• API nào khác có thể tương tác với API này?
Quyết định xem muốn kiểm thử API của mình như thế nào?
Một số phương pháp kiểm thử API phổ biến:
Functionality testing(kiểm thử chức năng) - Xác nhận API hoạt động chính
xác theo đúng chức năng mà nó được tạo ra.
• Usability testing - Xác nhận API có thể sử dụng một cách dễ dàng
• Reliability testing(Kiểm thử độ tin cậy) - Xác nhận việc gọi API và trả
kết quả hoạt động ổn định và nhất quán.
• Security testing(kiểm thử bảo mật) - API đã xác định cá yêu cầu bảo
mật bao gồm xác thực,quyền và kiểm siats truy cập.Xem một số mẹo
bảo mật để bảo vệ dữ liệu quan trọng.
Testcase trong API Testing
Các trường hợp thử nghiệm về kiểm tra API dựa trên:
• Kiểm tra các giá trị trả về dựa trên điều kiện đầu vào.
• Xác minh nếu API kích hoạt một số sự kiện khách hoặc gọi một API

khác.
• Xác minh nếu API khơng trả lại bất kỳ kết quả gì hoặc kết quả sai.
• Xác minh xem API đang cập nhật bất kỳ cấu trúc dữ liệu nào.
Một số kiểu lỗi cần chú ý khi kiểm thử API
• Vấn đề bảo mật
• Các vấn đề về sựu tin cậy.Khó khăn khi kết nối và nhận phản hồi từ
•
•
•
•

API
Vấn đề hiệu năng.API thời gian phản hồi rất cao.
Lỗi / cảnh báo không đúng cho người gọi
Xử lý sai số giá trị đối số hợp lệ
Dữ liệu phản hồi khơng được cấu trúc chính xác(JSON hoặc XML)

2.3 Mục đích của việc API testing
a. Kiểm thử ứng dụng sớm và không cần giao diện người dùng


Trong quá trình triển khai dự án, phần server và client làm độc lập với nhau
nên có nhiều chỗ client chưa làm xong, mình khơng thể chờ client làm xong để test
được dữ liệu mà test API bằng công cụ khác ln.
Với API testing, bạn có thể bắt đầu kiểm thử ứng dụng sớm ngay cả khi khơng
có giao diện người dùng. Điều này giúp xác định và khắc phục sớm các vấn đề
trong vịng đời phát triển, nếu khơng thì sẽ tốn kém để khắc phục khi được xác định
trong quá trình kiểm thử GUI.
Kể cả khi client làm xong rồi, nếu mình test trên client mà thấy lỗi liên quan
đến logic và dữ liệu thì cũng cần test thêm cả API để biết chính xác là server sai hay

client sai –> fix lỗi sẽ nhanh hơn.
b. Để có được một chiến lược kiểm thử tự động tuyệt vời và giảm chi phí.

Hãy nhìn lại vào kim tự tháp “Test automation pyramid” để đưa ra một chiến
lược kiểm thử tối ưu nhất.
Khái niệm kim tự tháp được Mike Cohn phát triển và đã được mô tả trong
cuốn sách “Thành công với Agile”. Tầng thứ nhất của kim tự tháp là Unit test. Thực
hiện unit test là cách nhanh nhất và mang lại kết quả cao nhất. Tầng thứ 2 là kiểm
thử API dựa trên service layer. Cuối cùng, ở đỉnh của kim tự tháp là kiểm thử UI.
Đi từ tầng dưới kim tự tháp lên trên, chi phí liên quan đến việc tạo ra và duy
trì các phương pháp kiểm thử, thời gian thực hiện kiểm thử, phạm vi kiểm thử sẽ
tăng lên. Các kim tự tháp tự động (Automation pyramid) nói rằng bạn nên làm


nhiều hơn nữa kiểm thử tự động thông qua Unit test và API hơn là kiểm thử dựa
trên GUI. Sự thành công của Agile rất phụ thuộc vào phản hồi (feedback) sớm.
Trong các thực tiễn, việc tích hợp liên tục, thời gian kiểm thử hồi quy GUI và nhận
lại phản hồi quá dài. Kiểm tra giao diện người dùng rất tốn kém để phát triển và duy
trì. Một sự thay đổi nhỏ trong giao diện người dùng cũng có thể dẫn đến việc thực
hiện kiểm thử lại rất nhiều.
Trong một số trường hợp, người kiểm thử bắt buộc phải thực hiện tự động hoá
ở tầng UI. Tuy nhiên, kiểm thử có thể chậm và tốn nhiều chih phí. Đây là một trong
những lý do khiến nhiều công ty thất bại trong nỗ lực thực hiện chiến lược tự động
hoá hiệu quả.
c. Phát triển phần mềm theo phương pháp Agile và giảm việc thực hiện
kiểm thử hồi quy bằng tay
Theo một cuộc khảo sát gần đây của VersionOne, 95% người được hỏi cho
biết tổ chức của họ sử dụng phương pháp Agile. Agile không chỉ sử dụng ở những
công ty startup và những nhóm phát triển sản phẩm nhỏ. Lý do chính để áp dụng
Agile thay vì phương pháp truyền thống là đẩy nhanh việc phân phối sản phẩm và

chấp nhận những thay đổi. Agile cũng đã tăng tần số mà các ứng dụng được phát
hành, do đó đã tạo ra nhu cầu ngày càng tăng về những phương pháp mới để nhanh
chóng kiểm tra chúng. Kiểm tra tự động hóa đã trở thành một yếu tố quan trọng để
duy trì tính nhanh chóng. Vì vậy, cần thiết cho các đội Agile tăng mức độ kiểm thử
API và giảm sự phụ thuộc của họ vào việc kiểm tra GUI.
Tự động hóa API có thể giảm đáng kể áp lực của kiểm thử hồi quy của nhóm
QA. Bằng cách tích hợp kiểm thử tự động API, nhóm QA có thể cung cấp phản hồi
nhanh về chất lượng ứng dụng ngay khi được triển khai (deploy). Điều này cung
cấp một đánh giá nhanh chóng về hệ thống trước khi kiểm thử GUI. Kiểm thử tự
động API yêu cầu code ít hơn và cung cấp kết quả kiểm tra nhanh hơn và phạm vi
kiểm tra tốt hơn. API được ổn định sớm và không thay đổi thường xuyên như giao
diện người dùng.
API testing là một hình thức thử nghiệm phần mềm độc đáo và đặc biệt có giá
trị đối với các doanh nghiệp nắm bắt quá trình hội nhập liên tục. Việc xây dựng
trường hợp kiểm thử API trong quá trình phát triển bất kỳ phần mềm hoặc dịch vụ
nào có những lợi ích sâu rộng trong các đội, tất cả đều là cách khách hàng trải
nghiệm sản phẩm. Làm phần mềm mà khách hàng mục tiêu của bạn sẽ yêu thích là


điều thiết yếu cho sự thành công của doanh nghiệp và bằng cách kiểm thử API một
cách nghiêm túc và thường xuyên, là một cách đáng tin cậy để đạt được nó.
2.4 Các cách, cơng cụ có thể thực hiện API
2.4.1 Các cách thực hiện API Testing
Hiểu được các yêu cầu của test API
Trước khi test API, bạn cần phải xác định được mục đích test là gì để chuẩn bị
tốt dữ liệu test cho đầu vào và đầu ra.
Hiểu được quy trình làm việc của cơng cụ sử dụng để test.
Bước này sẽ giúp bạn xác định được phương pháp test.
Viết testcase và tập trung vào các API nhỏ
Trong một dự án test, ln có một số API đơn giản chỉ với một hoặc hai đầu

vào như API đăng nhập, API lấy token, API health check…
Tuy nhiên, các API này là cần thiết và được coi là cánh cổng để xử dụng API.
Tập trung vào các API này trước các API khác sẽ đảm bảo rằng các server, môi
trường và xác thực API hoạt động đúng.
Giữ test case của bạn đơn giản nhất có thể.
Xác định kế hoạch và định nghĩa cho các tham số truyền vào
Tận dụng khả năng Automation để test API
Tận dụng khả năng automation để test API của bạn càng nhiều và càng sớm
càng tốt.
Dữ liệu test và lịch sử thực hiện có thể được lưu cùng với các API endpoint.
Điều này làm cho testcase dễ chạy lại hơn cho các test sau này.
API testcase nên ổn định và thay đổi cẩn thận. Một API phản ánh một business
của hệ thống. Mọi thay đổi trong API đều cần một yêu cầu rõ ràng, vì vậy tester
ln có thể chú ý mọi thay đổi và điều chỉnh chúng đúng hạn.
API testing được coi là test hộp đen trong đó người dùng gửi đầu vào và nhận
đầu ra để test. Automation với cách tiếp cận dựa trên dữ liệu – tức là áp dụng các bộ
dữ liệu khác nhau trong cùng một kịch bản test – có thể giúp tăng phạm vi API
testing.


Nhập và xuất dữ liệu theo một số mẫu hoặc mơ hình cụ thể để bạn chỉ có thể
tạo tập lệnh test một lần. Các kịch bản test này cũng có thể được sử dụng lại trong
tồn bộ dự án test.
Các test API có thể được thực hiện ở giai đoạn đầu của vòng đời phát triển
phần mềm. Cách tiếp cận automation với các kỹ thuật mock có thể giúp test API và
tích hợp của nó trước khi API thực tế được phát triển.
Chọn một công cụ Automation phù hợp
Công cụ có hỗ trợ import API/Web service từ WSDL, Swagger, WADL hay
một số phương thức khác không? Đây là một tính năng tùy chọn. Tuy nhiên, sẽ tốn
nhiều thời gian nếu bạn có hàng trăm API để test.

Cơng cụ có hỗ trợ các phương pháp test dựa trên dữ liệu khơng? Đây cũng là
một tính năng tùy chọn. Tuy nhiên, phạm vi test của bạn sẽ tăng đáng kể nếu cơng
cụ có chức năng này.
Cuối cùng nhưng khơng kém phần quan trọng, bên cạnh test API, bạn có cần
thực hiện các loại test khác, chẳng hạn như WebUI hoặc nguồn dữ liệu không? API
testing được thực hiện ở business giữa database và giao diện người dùng. Điều bình
thường là tất cả các phần này phải được test. Một công cụ hỗ trợ tất cả các loại test
sẽ là một lựa chọn lý tưởng để các đối tượng test.
Chọn phương pháp test phù hợp
Trong khi response status cho biết trạng thái của request, response body là nội
dung mà API trả về với đầu vào đã chỉ định. API response thay đổi từ loại dữ liệu
đến kích thước. Các response có thể ở dạng văn bản, JSON, XML hoặc các kiểu
khác. Chúng có thể là một chuỗi vài từ đơn giản (thậm chí trống) hoặc tệp JSON /
XML hàng trăm trang. Do đó, điều cần thiết là chọn một phương thức test phù hợp
cho một API nhất định.
Một số phương pháp cơ bản để test API response:
• So sánh tồn bộ nội dung response với expected info
• So sánh từng giá trị thuộc tính của response
• So sánh kết hợp với regex (biểu thức chính quy)
Chạy các testcase và so sánh kết quả mong muốn với kết quả thực tế


2.4.2 Các cơng cụ thực hiện API Testing
Có 3 loại API test-tool phổ biến rộng rãi nhất là: Postman, Curl và SoapUI.
Postman là một công cụ mạnh mẽ được sử dụng để kiểm tra các dịch vụ web.
Nó được phát triển để gửi các yêu cầu HTTP một cách đơn giản và nhanh chóng.
Curl là một cơng cụ command-line được sử dụng để phân phối các yêu cầu
qua giao thức HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, LDAP, DAP, DICT,
TELNET, FILE, IMAP, POP3, SMTP và RTSP.
SoapUI là một công cụ miễn phí được sử dụng để kiểm tra SOAP và RESTful

Web Services.
Ngồi ra có một số cơng cụ test API khác như: Runscope, Cfix, Check,
Katalon Studio, Rest-Assured, Karate DSL, Selenium, HP Unified Functional
Testing, IBM Rational Functional Tester, App Thwack…


CHƯƠNG 3: GIỚI THIỆU CHUNG VỀ POSTMAN
3.1 Ưu nhược điểm của Postman
Postman là 1 công cụ để test API của cty Postdot Technologies được bắt đầu
phát triển từ năm 2012. Postman cho phép làm việc với các API, nhất là REST,
giúp ích rất nhiều cho việc testing. Hỗ trợ tất cả các phương thức HTTP (GET,
POST, PUT, DELETE, OPTIONS, HEAD …) Postman cho phép lưu lại các lần sử
dụng. Sử dụng cho cá nhân hoặc team lớn. Trang chủ postman:
/>Ưu điểm:
• Dễ sử dụng, hỗ trợ cả chạy bằng UI và non-UI. Tức là đã có hoặc chưa
có giao diện người dùng (User Interface)
• Hỗ trợ viết code cho assert tự động bằng Javascript.
• Hỗ trợ cả RESTful services và SOAP services.
• Có chức năng tạo API document.
Nhược điểm:
• Những bản tính phí mới hỗ trợ những tính năng advance: Làm việc theo
team, support trực tiếp…
3.2 Cách cài đặt Postman
Download trực tiếp tại địa chỉ: />Sau đó chúng ta tiến hành cài đặt phần mềm như bình thường.

Hình 11 Giao diện download


3.3 Các thành phần chính của Postman
Giao diện của postmans

Hình 12 Giao diện của postman
Setting chứa các thông tin về cài đặt chung

Hình 13 Setting của postman


Collections lưu trữ thông tin của các API theo folder hoặc thời gian

Hình 14 Collections

API content hiện thị nội dung chi tiết API và các phần hỗ trợ giúp thực hiện
việc test API. Đây là phần người sử dụng – tester sử dụng nhiều nhất.
Trong phần API content có bố cục 3 phần:

Hình 15 API content


• Enviroments: Chứa các thơng tin mơi trường. Ví dụ: mình làm 1 dự án
nhưng có 3 mơi trường khác nhau: dev, staging và product. Có phần
này, mình có thể nhanh chóng đổi sang mơi trường cần test mà khơng
phải mất công đổi URL của từng request. (Cái này sẽ được nói rõ hơn ở
những chương sau)
• Request: Phần chứa các thơng tin chính của API, có thể đọc lại chương
trước.
• Reponse: Chứa các thơng tin trả về sau khi Send Request.


CHƯƠNG 4: CÁCH SỬ DỤNG POSTMAN
4.1 Cách tạo Request

Khi làm việc với API, chúng ta làm việc với các dạng API chính đó là GET và
POST, PUT, DELETE.
GET: u cầu server đưa lại resource. Hãy tưởng tượng chúng ta nhận lại một
thông tin của người sử dụng từ server
POST: Yêu cầu server tạo cho 1 resource mới. Ví dụ như: chúng ta tạo một
người dùng mới
PUT: Yêu cầu server sửa dữ liệu. Ví dụ như chúng ta đổi mật khẩu người dùng
DELETE: u cầu server xố dữ liệu. Ví dụ như chúng ta xố một người dùng
khi khơng có nhu câu sử dụng nữa
Và một request gồm có 4 thành phần:
•
•
•
•

URL
Method
Headers
Body

Khi vào dự án thật, những thơng tin trên thì bạn lấy ở đâu? Thì câu trả lời đó là
từ phía lập trình viên (deverloper). Muốn kiểm thử được API hay bất cứ loại nào
khác thì việc đầu tiên chúng ta cần tài liệu đặc tả và tại liệu đặc tả cho việc kiểm thử
API ở đây chính là chúng ta phải có API documents. Cái này tuỳ cơng ty sẽ có
nhưng chuẩn riêng, nhưng nhìn chung chúng cung cấp cho ta nhưng thơng tin sau:
Tên của API, mục đích sử dụng, Method, URL, Params, Sample Request, Sample
Response.
4.1.1 Tạo request GET
Bước 1: Nhập URL vào phần request.
Bước 2: Chọn phương thức GET.

Bước 3: Phần headers để nguyên.