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

Sử dụng Postman trong kiểm thử web API 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.

MỤC LỤC

MỤC LỤC I DANH MỤC CÁC HÌNH VẼ III DANH MỤC CÁC BẢNG BIỂU V

MỞ ĐẦU 1

CHƯƠNG 1 : CÁC KHÁI NIỆM CƠ BẢN 3

1.1 Protocol dùng trong Restful API 3

1.2 Định dạng dữ liệu JSON và XML 5

CHƯƠNG 2 : TỔNG QUAN VỀ API VÀ API TESTING 8

2.1 Tổng quan về API 8

2.1.1 API là gì? 8

2.1.2 API thường ứng dụng vào đâu? 8

2.1.3 Web API là gì? 9

2.1.4 Những điểm nổi bật của Web API 9

2.1.5 Web API hoạt động như thế nào? 10

2.1.6 Ưu và nhược điểm của Web API 10

2.2 API Testing 12

2.2.1 Định nghĩa về API Testing 12

2.2.2 Cần chuẩn bị những gì để bắt đầu kiểm thử API? 12

2.3 Mục đích của việc API testing 14

2.4 Các cách, công cụ có thể thực hiện API 16

2.4.1 Các cách thực hiện API Testing 16

2.4.2 Các công cụ thực hiện API Testing 18

CHƯƠNG 3 : GIỚI THIỆU CHUNG VỀ POSTMAN 19

3.1 Ưu nhược điểm của Postman 19

3.2 Cách cài đặt Postman 19

3.3 Các thành phần chính của Postman 20

CHƯƠNG 4 : CÁCH SỬ DỤNG POSTMAN 23

4.1 Cách tạo Request 23

4.1.1 Tạo request GET 23

4.1.2 Tạo request POST 25

4.2 Collections trong Postman 26

4.2.1 Cách tạo collections 26

4.2.2 Các setting chính của 1 collections 28

4.3 Cách sử dụng Environments 29

4.4 Test Response 30

4.5 Sử dụng Pre – request Script 31

4.6 Xây dựng API Document 31

4.7 Run test Suites từ Runner 32

4.7.1 Quản lý Test Suites 32

4.7.2 Run Test Suites bằng chức năng Runner 33

4.8 Cách test API 34

CHƯƠNG 5 : TEST API WEBSITE: HTTPS://REQRES.IN 37

5.1 Tài liệu đặc tả API 37

5.1.1 List user 37

5.1.2 Single user 39

5.1.3 Single user NOT FOUND 39

5.1.4 List <resource> 40

5.1.5 Single <Resource> 41

5.1.6 Single <resource> NOT FOUND 42

5.1.7 Create 42

5.1.8 Update 43

5.1.9 Update 44

5.1.10 Delete 44

5.1.11 Register – successful 44

5.1.12 Register – unsuccessful 45

5.1.13 Login - successful 46

5.1.14 Login – unsuccessful 46

5.1.15 Delayed response 47

5.2 Kết quả test API 49

CHƯƠNG 6 : BẢN PHÂN CÔNG NHIỆM VỤ, KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 53

DANH MỤC CÁC HÌNH VẼ

Hình 1 Request 4

Hình 2 Response 5

Hình 3 Ví dụ key nằm bên trái, value ở bên phải 5

Hình 4 Ví dụ key có values là 1 dãy key + value 6

Hình 5 Ví dụ XML 6

Hình 6 Giao tiếp giữa Client và Server 7

Hình 7 Tổng quan về API 8

Hình 8 Web API 9

Hình 9 Ưu điểm API 11

Hình 10 API Testing 12

Hình 11 Giao diện download 19

Hình 12 Giao diện của postman 20

Hình 13 Setting của postman 20

Hình 14 Collections 21

Hình 15 API content 21

Hình 16 Tạo request GET 24

Hình 17 Response trả về sau khi GET 24

Hình 18 Tạo request POST 25

Hình 19 Response trả về sau khi POST 25

Hình 20 Tạo mới 1 collections 26

Hình 21 Tạo mới collections 27

Hình 22 Lưu request vào collections 27

Hình 23 Lưu request trong history vào collections 28

Hình 24 Các setting của một collections 29

Hình 25 Tạo một Environments 30

Hình 26 Pre – request Script 31

Hình 27 Quản lý Test Suites 32

Hình 28 Cấu trúc API cho từng task 33

Hình 29 Chức năng Runner 33

Hình 30 Kết quả sau khi thực hiện 34

Hình 31 Tổng quan về API 34

Hình 32 Test scenarios 36

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ảiqua 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 danhlập trình viên nhưng chuyên viên kiểm thử phần mềm đã, đang và sẽ là một trongnhữ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ácminh 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ụ haykhô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ủakhá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ủacô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 xuyên 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âusống còn đó

2 Tính cấp thiết, ý nghĩa khoa học và thực tiễn của API testing

[ CITATION ADM19 \l 1033 ]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ừ độiPhát triển đưa, và tiến hành gọi từng API một Và giai đoạn test API đều bi đẩyxuố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ếtbằng những ngôn ngữ khác nhau Tương tự, server back-end cũng được viết bằngcác ngôn ngữ khác nhau Để 2 thằng này có thể nói chuyện được với nhau chúngphả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 xuôi 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 đượcthự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 hayclient 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àngsớ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ấtxả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ì?

[ CITATION Ngu18 \l 1033 ]Giả sử: Có 2 người A và B nói chuyện với nhauqua đ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

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ớingườ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ếtchí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 clientmuố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

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ý 1chuyế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: Yê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ôngbiế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ạithiế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ửingược lại cho client 1 cái response Cấu trúc của 1 response tương đối giống phầnrequest nhưng Status code sẽ thay thế cho URL và Method

Hình 1 Request

Một response có cầu trúc 3 phần:

 Status code

 Header

 Body

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 ServiceUnavailable”, Danh sách các status code có ở:

 Trường hợp đặc biệt

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 luôn ví dụ ở trên nhưng viết bằng xml, nó sẽ như thế này:

Hình 4 Ví dụ key có values là 1 dãy key + value

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

Đô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 luôn 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

Hình 6 Giao tiếp giữa Client và Server

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àngnhiề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ộcngôn ngữ đã thúc đẩy việc ứng dụng API Vậy API là gì? Nguồn gốc và ưu điểmcủ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 ứngdụ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ốiInternet 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ếtcá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ậpnhậ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áctà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úplậ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ểnkhai 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 đểyê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ạngJSON 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/responseheaders, 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ôngviệ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 caohơn.

Khả năng tích hợp linh động : API cho phép lấy nội dung từ bất kỳ websitehoặ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ườidù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ôngtin 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ụngcũ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 đếnmá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 traxá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ứcHTTP/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ệuJSON/XML sẽ được parse để lấy data Sau khi có được data thì thực hiện tiếp cáchoạ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

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

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ácgiao 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ảomật không

Vì API thiếu GUI, API testing được thực hiện ở tầng nghiệp vụ Businesslayer

API testing được coi là quan trọng cho automation testing vì các API đóng vaitrò 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ớplogic 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àogiao 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ểmthử

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ấtthườ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ínhxá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ảomật bao gồm xác thực,quyền và kiểm siats truy cập.Xem một số mẹobả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 APIkhá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 nhaunê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 luôn

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 địnhtrong 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 hayclient 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ếnlượ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ả trongcuố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ựchiệ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ểmthử 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à duytrì 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àmnhiều hơn nữa kiểm thử tự động thông qua Unit test và API hơn là kiểm thử dựatrê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ậnlạ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à duytrì Một sự thay đổi nhỏ trong giao diện người dùng cũng có thể dẫn đến việc thựchiệ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 trongnhữ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ự độnghoá 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 chobiết tổ chức của họ sử dụng phương pháp Agile Agile không chỉ sử dụng ở nhữngcông ty startup và những nhóm phát triển sản phẩm nhỏ Lý do chính để áp dụngAgile 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áthành, do đó đã tạo ra nhu cầu ngày càng tăng về những phương pháp mới để nhanhchó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ồinhanh về chất lượng ứng dụng ngay khi được triển khai (deploy) Điều này cungcấ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 vikiểm tra tốt hơn API được ổn định sớm và không thay đổi thường xuyên như giaodiệ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ựngtrườ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ảinghiệ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ộtcá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, luôn có một số API đơn giản chỉ với một hoặc hai đầuvà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ôitrườ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ớmcà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 businesscủ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 testerluôn 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 APItesting

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 trongtoà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ểnphầ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 haymộ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ốnnhiề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ầnthự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? APItesting được thực hiện ở business giữa database và giao diện người dùng Điều bìnhthườ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ộidung 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ểukhá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ợpcho một API nhất định

Một số phương pháp cơ bản để test API response:

 So sánh toà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ầuqua 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à RESTfulWeb Services

Ngoà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 FunctionalTesting, 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 đầuphá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:https://www.postman.com/

Ư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 theoteam, support trực tiếp…

3.2 Cách cài đặt Postman

Download trực tiếp tại địa chỉ: https://www.postman.com/downloads/

Sau đó chúng ta tiến hành cài đặt phần mềm như bình thường

3.3 Các thành phần chính của Postman

Giao diện của postmans

Setting chứa các thông tin về cài đặt chung

Hình 12 Giao diện của postman

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

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 14 Collections

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ầnnày, mình có thể nhanh chóng đổi sang môi trường cần test mà khôngphả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

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àokhá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, SampleResponse

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

Bước 4: Phương thức GET không có body nên chúng ta phải điển tham số vàoParams.

Bước 5: Nhấn send

Lưu ý: Tất cả params truyền vào phải chính xác, không được để thừa 1 khoảngtrống hay xuống dòng

Sau khi ấn send thì chúng ta đã gửi request và chờ response trả về

Thông tin trả về chúng ta sẽ quan tâm tới:

Hình 16 Tạo request GET

Hình 17 Response trả về sau khi GET

 Định dạng dữ liệu trả về: Thông thường sẽ là json nên chúng ta để chế

độ Pretty cho dễ nhìn

 Nội dung dữ liệu: Đây là phần mà chúng ta sẽ phải kiểm tra:

o Chúng ta cần phải so sánh với Sample Response ở API doc để xemcấu trúc trả về đã đúng hay chưa

o Value của từng key đã đúng hay chưa, so sánh với nọi dung trongDB

 Trạng thái của API (status) và thời gian trả về Lưu ý: Thời gian chạyAPI bằng postman luôn ngắn hơn thời gian test trên giao diện vì nhiều

lý do: đường truyền internet, nhận response phải chạy code khởi tạogiao diện để hiện thị

4.1.2 Tạo request POST

Tương tự với phần tạo request GET, chỉ khác là chúng ta phải truyền tham sốvào phần body

Ở phần response chúng ta cũng quan tâm đến những phần tương tự ở GET

Hình 18 Tạo request POST

Hình 19 Response trả về sau khi POST