Đồ án tốt nghiệp - Đắc Thị Trà My - 69DCHT20083-đã chuyển đổi

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ GIAO THÔNG VẬN TẢI
KHOA CÔNG NGHỆ THÔNG TIN
Đắc Thị Trà My
NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ TRIỂN

KHAI KIỂM THỬ API BẰNG CÔNG CỤ
POSTMAN
ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Hệ thống thông tin
Hà Nội - 2022
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ GIAO THÔNG VẬN TẢI
KHOA CÔNG NGHỆ THÔNG TIN
NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ TRIỂN

KHAI KIỂM THỬ API BẰNG CÔNG CỤ
POSTMAN
ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Hệ thống thông tin
Cán bộ hướng dẫn: ThS. Vũ Thị Thu Hà
Hà Nội - 2022
NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN
(Của giảng viên hướng dẫn)
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
Điểm: ...................................................... (bằng chữ: .................................................. )
Đồng ý / Không đồng ý cho sinh viên bảo vệ trước hội đồng chấm đồ án tốt nghiệp?
...........................................
Hà Nội, ngày tháng năm 2022
GIẢNG VIÊN HƯỚNG DẪN
(ký, họ tên)
NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN
(Của giảng viên phản biện)
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
Điểm: ...................................................... (bằng chữ: .................................................. )
Đồng ý / Không đồng ý cho sinh viên bảo vệ trước hội đồng chấm đồ án tốt nghiệp?
...........................................
Hà Nội, ngày tháng năm 2022
GIẢNG VIÊN PHẢN BIỆN
(ký, họ tên)
Đồ án tốt nghiệp Trường Đại học Công Nghệ GTVT
TÓM TẮT
Mục đích của Đồ án nhằm giải quyết các vấn đề về trạng thái lỗi, và kết quả trả về
cho mỗi chức năng của phần mềm có thể phát sinh trong một tổ chức, một doanh nghiệp.
Theo dõi và tìm ra các vấn đề phát sinh trong quá trình của một dự án là công việc rất quan
trọng, tuy nhiên hiện nay các dự án phát triển đang được thực hiện theo mô hình
Agile/Scrum thì việc sử dụng công cụ Postman ngày càng nhiều. Postman là một phần
mềm mã nguồn mở để test RestAPI mà không cần đến dòng code nào, nhờ đó mà các vấn
đề trong phát triển dự án trở nên dễ dàng hơn với mọi tổ chức.
Công nghệ thông tin ngày càng phát triển mạnh, việc tự động hóa các công việc ngày càng
được chú ý hơn giúp tiết kiệm thời gian, công sức, tăng năng suất làm việc và giảm các rủi
ro trong quá trình phát triển cũng như triển khai phần mềm. Vì vậy, nên em đã quyết định
chọn đề tài “Nghiên cứu kiểm thử phần mềm và triển khai kiểm thử API bằng công
cụ Postman” với mong muốn nghiên cứu, nâng cao trình độ trong quá trình học tập và làm
việc, từ đó áp dụng vào công việc thực tế.
Mục tiêu của đồ án này là xây dựng thành công kịch bản kiểm thử chi tiết và kiểm
thử tự động toàn bộ các ca kiểm thử đã thiết kế, ứng dụng kiểm thử các chức năng chính
của các chức năng chính trong API bán sách. Đồng thời đưa ra các hướng giải quyết phù
hợp.
Bố cục đồ án gồm có bốn chương:
Chương 1. Tổng quan
Chương 2. Cơ sở lý thuyết
Chương 3. Công cụ kiểm thử Postman
Chương 4. Triển khai kiểm thử API bằng công cụ Postman
Đắc Thị Trà My i 69DCHT20083

LỜI CAM ĐOAN

Em xin cam đoan đồ án này là công trình nghiên cứu của cá nhân em, dưới sự hướng
dẫn của ThS. Vũ Thị Thu Hà – giảng viên Trường Đại học Công nghệ GTVT. Các nội
dung nghiên cứu, kết quả trong đề tài đều là trung thực và chưa hề được sử dụng để bảo vệ
bởi một học vị nào. Các nguồn kiến thức trích dẫn có chú thích rõ ràng, có tính kế thừa,
phát triển từ một số tài liệu đã được liệt kê ở mục Tài Liệu Tham Khảo.
Em xin chân thành chịu trách nhiệm về lời cam đoan của mình.
Hà Nội, tháng 5 năm 2022
Sinh viên thực hiện
Đắc Thị Trà My ii 69DCHT20083

MỤC LỤC
TÓM TẮT........................................................................................................................ i
LỜI CAM ĐOAN ........................................................................................................... ii
MỤC LỤC ..................................................................................................................... iii
LỜI NÓI ĐẦU .................................................................................................................v
BẢNG THUẬT NGỮ VIẾT TẮT ................................................................................ vi
DANH MỤC HÌNH ẢNH ............................................................................................ vii
DANH MỤC BẢNG BIỂU ......................................................................................... viii
CHƯƠNG 1. TỔNG QUAN ...........................................................................................1
1.1. Lý do chọn đề tài................................................................................................1
1.2. Mục tiêu của đề tài .............................................................................................1
1.3. Giới hạn và phạm vi của đề tài ..........................................................................1
1.4. Kết quả dự kiến ..................................................................................................1
CHƯƠNG 2. CƠ SỞ LÝ THUYẾT ................................................................................3
2.1. Tổng quan về kiểm thử phần mềm ....................................................................3
2.1.1. Định nghĩa và vai trò của kiểm thử phần mềm ...........................................3
2.1.2. Các kĩ thuật kiểm thử phần mềm ................................................................4
2.1.3. Các loại kiểm thử phần mềm ......................................................................9
2.1.4. Các mô hình phát triển phần mềm và ưu nhược điểm ..............................11
2.1.5. Quy trình kiểm thử phần mềm ..................................................................18
2.2. Tổng quan về API ............................................................................................20
2.2.1. Khái niệm ..................................................................................................20
2.2.2. Lý do cần phải test API .............................................................................20
2.2.3. Những điều cần lưu ý khi thực hiện API Testing .....................................20
2.2.4. Các testcase cho kiểm thử API..................................................................21
2.2.5. Sự khác nhau giữa API testing và Unit testing .........................................22
CHƯƠNG 3. CÔNG CỤ KIỂM THỬ POSTMAN ......................................................23
3.1. Giới thiệu POSTMAN .....................................................................................23
3.1.1. Khái niệm ..................................................................................................23
3.1.2. Ưu nhược điểm của POSTMAN ...............................................................23
3.1.3. Những tính năng đặc biệt ..........................................................................23
3.2. Các chức năng chính của POSTMAN .............................................................24
3.3. Dowload và cài đặt công cụ POSTMAN .........................................................25
3.4. Các thành phần chính của POSTMAN ............................................................25
Đắc Thị Trà My iii 69DCHT20083

3.5. Collections trong POSTMAN ..........................................................................27

3.5.1. Cách tạo collection ....................................................................................27
3.5.2. Các settings chính của 1 Collection. .........................................................28
3.6. Cách sử dụng Environments ............................................................................30
CHƯƠNG 4. TRIỂN KHAI KIỂM THỬ API BẰNG CÔNG CỤ POSTMAN ..........32
4.1. Giới thiệu về API bán sách online và các chức năng chính.............................32
4.1.1. API bán sách online ..................................................................................32
4.1.2. Một số chức năng chính của API bán sách ...............................................32
4.2. Thiết kế testcase cho các chức năng chính ......................................................36
4.2.1. Chức năng xem danh sách tất cả sách và đơn hàng ..................................36
4.2.2. Chức năng đặt hàng ...................................................................................37
4.2.3. Chức năng chỉnh sửa thông tin đơn hàng ..................................................39
4.2.4. Chức năng xóa đơn hàng ...........................................................................41
4.2.5. Chức năng tìm kiếm thông tin đơn hàng ...................................................43
4.2.6. Chức năng tìm kiếm thông tin sách...........................................................45
4.3. Tạo collection tự động và biến môi trường cho giá trị kiểm thử dựa vào các
testcase đã thiết kế ......................................................................................................46
4.4. Kiểm thử và tổng hợp kết quả ..........................................................................49
4.4.1. Kiểm thử tự động Collection Runner ........................................................49
4.5. Báo cáo kết quả kiểm thử tự động ...................................................................53
4.6. Đánh giá kết quả kiểm thử ...............................................................................56
KẾT LUẬN ...................................................................................................................57
TÀI LIỆU THAM KHẢO .............................................................................................58
Đắc Thị Trà My iv 69DCHT20083

LỜI NÓI ĐẦU
Ngày nay, với sự phát triển mạnh mẽ của khoa học công nghệ, đặc biệt là sự phát
triển nhanh chóng của lĩnh vực công nghệ thông tin, công nghệ thông tin ngày càng đi vào
đời sống và được con người khai thác một cách rất hiệu quả biến nó thành công cụ lao
động hữu ích và đóng vai trò rất quan trọng trong đời sống xã hội. Kiểm thử phần mềm là
một phần quan trọng của lĩnh vực công nghệ thông tin, nó giúp tìm ra các lỗi và thiếu sót
của phần mềm mà người lập trình không thể kiểm soát hết từ đó giúp cho chất lượng phần
mềm được tốt hơn rất nhiều, thực hiện các công việc đúng như kì vọng ban đầu và hơn thế
nữa. Em thực hiện đề tài “ Nghiên cứu kiểm thử phần mềm và triển khai kiểm thử API
bằng công cụ Postman” nhằm nâng cao thêm kiến thức và tầm hiểu biết của mình về lĩnh
vực này. Lĩnh vực công nghệ thông tin nói chung và bộ môn kiểm thử phần mềm nói riêng.
Em xin gửi lời cảm ơn sâu sắc đến giảng viên, Thạc sĩ Vũ Thị Thu Hà, người đã
trực tiếp hướng dẫn và giúp đỡ em rất nhiều trong thời gian em thực hiện đồ án, giúp em
hoàn thiện đồ án một cách tốt nhất.
Em xin cảm ơn các thầy cô giáo trong khoa Công nghệ thông tin nói riêng và các
thầy cô giáo của Trường Đại học Công nghệ Giao Thông Vận Tải nói chung đã chỉ dạy,
hướng dẫn và giúp đỡ em trong suốt bốn năm học tập tại trường. Vì thời gian, điều kiện
còn có hạn, em đã cố gắng rất nhiều để hoàn thành đồ án tốt nghiệp, nhưng chắc chắn vẫn
còn nhiều hạn chế và không thể tránh khỏi những thiếu sót, mong thầy cô và các bạn có
những ý kiến đóng góp để em có thể hoàn thiện và phát triển đề tài hơn.
Cuối cùng, em xin kính chúc các thầy cô giảng viên trong Trường Đại học Công
nghệ Giao Thông Vận Tải nói chung, các thầy cô khoa Công nghệ thông tin nói riêng có
nhiều sức khỏe và nhiều thành công trong sự nghiệp cao quý.
Em xin chân thành cảm ơn!
Hà Nội, tháng 5 năm 2022
Sinh viên thực hiện
Đắc Thị Trà My v 69DCHT20083

BẢNG THUẬT NGỮ VIẾT TẮT

STT Viết tắt Tên tiếng Anh Tên tiếng Việt
1 CSDL Database Cơ sở dữ liệu
2 API Application Programming Giao diện chương trình
Interface ứng dụng
3 Request Yêu cầu
4 Response Trả về
5 Collection Tập hợp nhiều request
6 Test script Các đoạn mã lệnh thực thi
một chức năng cụ thể sau
khi có kết quả
7 Pre request Các đoạn mã lệnh thực thi
một chức năng cụ thể
trước khi gửi yêu cầu
8 Tester Kiểm thử viên
Đắc Thị Trà My vi 69DCHT20083

DANH MỤC HÌNH ẢNH

Hình 2.1 Vòng đời của quá trình kiểm thử ......................................................................... 3
Hình 2.2 Kiểm thử hộp đen ................................................................................................ 5
Hình 2.3 Kiểm thử hộp trắng .............................................................................................. 7
Hình 2.4 Kiểm thử hộp xám ............................................................................................... 8
Hình 2.5 Mô hình thác nước ............................................................................................. 11
Hình 2.6 Mô hình chữ V................................................................................................... 13
Hình 2.7 Mô hình xoắn ốc ................................................................................................ 14
Hình 2.8 Mô hình Agile.................................................................................................... 16
Hình 2.9 Vòng đời kiểm thử phần mềm ........................................................................... 18
Hình 2.10 API ................................................................................................................... 20
Hình 3.1. Giao diện trang chủ POSTMAN ...................................................................... 25
Hình 3.2. Collections của Postman................................................................................... 26
Hình 3.3. API content của Postman.................................................................................. 27
Hình 3.4. Tạo Collection .................................................................................................. 28
Hình 3.5. Viết tên collection và mô tả .............................................................................. 28
Hình 3.6. Các settings của collection ............................................................................... 29
Hình 3.7. Vị trí của Environment trong khung làm việc của Postman ............................ 30
Hình 3.8. Tests Response ................................................................................................. 31
Hình 4.1. Trang chủ website bán sách của Nhã Nam....................................................... 32
Hình 4.2. Tạo folder cho collection .................................................................................. 47
Hình 4.3. Chi tiết kịch bản kiểm thử chức năng với công cụ kiểm thử Postman ............. 48
Hình 4.4. Tạo biến môi trường cho collection ................................................................. 48
Hình 4.5. Testscipt kiểm tra response time ...................................................................... 49
Hình 4.6. Testcript kiểm tra status code ........................................................................... 51
Hình 4.7. Testcript kiểm tra giá trị trả về trong response ................................................. 52
Hình 4.8. Giao diện run collection ................................................................................... 53
Hình 4.9. Báo cáo kết quả kiển thử tự động run collection .............................................. 56
Đắc Thị Trà My vii 69DCHT20083

DANH MỤC BẢNG BIỂU

Bảng 2.1 Sự khác nhau giữa API testing và Unit testing .................................................. 22
Bảng 4.1 Mô tả yêu cầu chức năng xem danh sách tất cả Sách ........................................ 33
Bảng 4.2 Mô tả yêu cầu chức năng xem danh sách tất cả đơn hàng ................................. 33
Bảng 4.3 Mô tả yêu cầu chức năng thêm mới đơn hàng ................................................... 34
Bảng 4.4. Mô tả yêu cầu chức năng thêm mới đơn hàng .................................................. 35
Bảng 4.5. Testcase cho chức năng xem danh sách tất cả sách và đơn hàng ..................... 36
Bảng 4.6. Testcase cho chức năng đặt hàng ...................................................................... 38
Bảng 4.7 Testcase cho chức năng chỉnh sửa thông tin đơn hàng ...................................... 39
Bảng 4.8 Testcase cho chức năng xóa đơn hàng ............................................................... 41
Bảng 4.9 Testcase cho chức năng tìm kiếm thông tin đơn hàng ....................................... 43
Bảng 4.10 Testcase cho chức năng tìm kiếm thông tin sách ............................................. 45
Đắc Thị Trà My viii 69DCHT20083

CHƯƠNG 1. TỔNG QUAN

1.1. Lý do chọn đề tài
Ngày nay, với sự phát triển mạnh mẽ của khoa học công nghệ, đặc biệt là sự phát triển
nhanh chóng của lĩnh vực công nghệ thông tin, công nghệ thông tin ngày càng đi vào đời
sống và được con người khai thác một cách rất hiệu quả biến nó thành công cụ lao động
hữu ích và đóng vai trò rất quan trọng trong đời sống xã hội.
Kiểm thử phần mềm là một phần quan trọng của lĩnh vực công nghệ thông tin, nó giúp
tìm ra các lỗi và thiếu sót của phần mềm mà người lập trình không thể kiểm soát hết từ đó
giúp cho chất lượng phần mềm được tốt hơn rất nhiều, thực hiện các công việc đúng như
kỳ vọng ban đầu và hơn thế nữa. Vì vậy, em thực hiện đề tài “Nghiên cứu kiểm thử phần
mềm và triển khai kiểm thử API bằng công cụ POSTMAN” nhằm nâng cao thêm kiến
thức và tầm hiểu biết của mình về lĩnh vực này. Lĩnh vực công nghệ thông tin nói chung
và Đồ án tốt nghiệp nói riêng.
1.2. Mục tiêu của đề tài
- Chỉ ra những khiếm khuyết và sai sót đã được thực hiện trong giai đoạn phát triển
phần mềm;
- Để giảm nhân lực kiểm thử và đảm bảo chất lượng phần mềm hơn với công việc
kiểm thử bằng tay;
- Nghiên cứu giai đoạn nào cần áp dụng công cụ Postman để test API;
- Kiểm chứng những kiến thức đã được học trên giảng đường Đại học, đồng thời
trang bị những kiến thức mới, là hành trang chuẩn bị bước vào cuộc sống.
1.3. Giới hạn và phạm vi của đề tài

- Tìm hiểu cơ sở lí thuyết về kiểm thử phần mềm;
- Thực hiện kiểm thử trên dữ liệu có sẵn bằng công cụ POSTMAN;
- Sử dụng công cụ kiểm thử tự động POSTMAN để kiểm thử tự động các chức
năng đã phân tích.
1.4. Kết quả dự kiến
- Bản báo cáo nghiên cứu và triển khai kiểm thử;
- Trình bày được các kiến thức cơ bản về kiểm thử phần mềm nói chung và kiểm
thử phần mềm tự động API nói riêng;
Đắc Thị Trà My 1 69DCHT20083

- Giới thiệu được các đặc điểm, thành phần chức năng của công cụ kiểm thử tự
động POSTMAN;
- Áp dụng các kiến thức đã tìm hiểu vào thực hiện kiểm thử tự động các chức năng
chính của một API bán sách online.

CHƯƠNG 2. CƠ SỞ LÝ THUYẾT
2.1. Tổng quan về kiểm thử phần mềm
2.1.1. Định nghĩa và vai trò của kiểm thử phần mềm
2.1.1.1. Định nghĩa
Kiểm thử phần mềm là một quá trình kiểm tra để phát hiện ra lỗi của những phần mềm,
ứng dụng nhằm cung cấp cho khách hàng, lập trình viên… thông tin về chất lượng của
phần mềm được kiểm thử. Mục đích cuối cùng của công việc này là để đảm bảo sản phẩm
(phần mềm, ứng dụng) được tạo ra theo đúng mong muốn khách hàng và hoạt động hiệu
quả. Với các công ty phát triển phần mềm thì Tester (chuyên viên kiểm thử phần mềm) có
vai trò cốt yếu để đảm bảo uy tín của công ty, tránh những trường hợp sản phẩm lỗi bị
khách hàng trả về nơi sản xuất.
Hình 2.1 Vòng đời của quá trình kiểm thử

2.1.1.2. Vai trò
Xác định những lỗi và khiếm khuyết có thể xảy ra trong quá trình phát triển phần
mềm. Mức độ thành công của một phần mềm được đánh giá bởi chất lượng và độ
tin tưởng của khách hàng. Để cung cấp một ứng dụng có chất lượng cao thì kiểm thử
phần mềm là một trong những yếu tố tiên quyết. Điều này nâng cao trải nghiệm của
người dùng. Hơn nữa, một sản phẩm được kiểm thử tốt sẽ phát sinh chi phí bảo trì
ít hơn do đó kết quả được cung cấp chính xác, phù hợp và đáng tin cậy hơn.
Để thiết kế bất kỳ sản phẩm hoặc phần mềm nào cũng sẽ tốn rất nhiều chi phí
trong quá trình phát triển, vì vậy điều quan trọng đối với một ứng dụng hoặc sản

phẩm khi muốn đem lại kết quả khả quan là tránh mọi chi phí phát sinh ngoài dự
toán. Để củng cố vị trí của bạn trên thị trường, hiệu suất sản phẩm phải thực sự tốt
và hiệu quả. Kết quả này chỉ có thể đạt được khi thực hiện các biện pháp kiểm thử
hữu hiệu và hợp lý. Kiểm thử có thể phân ra thành hai phương pháp chính gồm: kiểm
thử phần mềm và kiểm thử Ad-hoc (kiểm thử dựa trên kinh nghiệm).
Kiểm thử phần mềm thường được sử dụng để kiểm tra phần mềm trong quá trình
phát triển ứng dụng của lập trình viên. Quá trình này bao gồm đánh giá các loại
thông tin liên quan đến sản phẩm phần mềm. Hiệu quả của các hoạt động hàng ngày
của một doanh nghiệp được cải thiện sau khi quy trình kiểm thử phần mềm được
thực hiện. Các công ty ngày nay đang hoạt động trong môi trường có tính cạnh tranh
cao. Mọi ứng dụng đều có mục tiêu đạt hiệu năng cao nhất so với đối thủ. Do đó
chất lượng của sản phẩm trở nên rất quan trọng. Thông qua kiểm thử phần mềm, các
lỗi cụ thể trong sản phẩm có thể được xác định chính xác để có thể thực hiện các
giải pháp phù hợp để cải thiện chất lượng. Quá trình này cũng giúp phát hiện ra bất
kỳ lỗi có thể phát sinh để cải thiện năng lực và độ chính xác tổng thể của hệ thống.
2.1.2. Các kĩ thuật kiểm thử phần mềm

2.1.2.1. Kĩ thuật kiểm thử hộp đen– Black Box Testing (BBT)
- Khái niệm:
Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiện
mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm
tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong
của cái hộp.
+ Nó còn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out;
+ Người kiểm thử nên xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy
đủ tất cả các yêu cầu chức năng của chương trình;
+ Cách tiếp cận của các tester đối với hệ thống là không dùng bất kỳ một
kiến thức về cấu trúc lập trình bên trong hệ thống, xem hệ thống là một
cấu trúc hoàn chỉnh, không thể can thiệp vào bên trong.

Hình 2.2 Kiểm thử hộp đen

Black Box Testing chủ yếu là được thực hiện trong Function test và System
test. Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm,
trong con mắt của các tester giống như một hộp đen, bên trong mà người ta không
thể nhìn thấy. Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:
+ Chức năng không chính xác hoặc thiếu;

+ Lỗi giao diện;
+ Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài;
+ Hành vi hoặc hiệu suất lỗi;
+ Khởi tạo và chấm dứt các lỗi.
- Ưu điểm của kiểm thử hộp đen:
+ Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ
trong việc sáng tỏ sự chênh lệch về thông số kỹ thuật;
+ Các tester theo phương pháp black box không có “mối ràng buộc” nào
với code, và nhận thức của một tester rất đơn giản: một source code có
nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box
tìm được nhiều bug ở nơi mà các DEV không tìm thấy;
+ Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn
ngữ lập trình hoặc làm thế nào các phần mềm đã được thực hiện;
+ Các tester có thể được thực hiện bởi một cơ quan độc lập từ các
developer, cho phép một cái nhìn khách quan và tránh sự phát triển thiên
vị;

+ Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác;
+ Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức
năng được xác định.
- Nhược điểm của kiểm thử hộp đen:
+ Dữ liệu đầu vào yêu cầu một khối lượng mẫu khá lớn;
+ Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó
và do đó khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu
vào, và thiếu cả thời gian cho việc tập hợp này;
+ Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao;
+ Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn
chương trình sẽ được để lại chưa được kiểm tra;
+ Kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà
không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được
xây dựng như thế nào. Có nhiều trường hợp khi một tester viết rất nhiều
trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường
hợp test và/hoặc một vài phần cuối cùng không được test hết.
2.1.2.2. Kĩ thuật kiểm thử hộp trắng– White Box Testing (WBT)
- Khái niệm:
Kiểm thử Hộp Trắng (còn gọi là Clear Box Testing, Open Box Testing, Glass
Box Testing, Transparent Box Testing, Code-Based Testing hoặc Structural
Testing) là một phương pháp kiểm thử phần mềm trong đó tester biết về cấu trúc
nội bộ / thiết kế. Người kiểm tra chọn đầu vào để thực hiện các đường dẫn thông
qua mã và xác định đầu ra thích hợp. Kiến thức lập trình và kiến thức thực hiện
là rất cần thiết trong kiểm thử hộp trắng.

Hình 2.3 Kiểm thử hộp trắng
- Mức độ áp dụng:
+ Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơn
vị;
+ Integration Testing(Test tích hợp): Để kiểm tra đường dẫn giữa các đơn
vị;
+ System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các hệ
thống con.
- Ưu điểm của kiểm thử hộp trắng:
+ Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho GUI
để có thể test;
+ Test kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn;
+ Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh;
+ Cho phép tìm kiếm các lỗi ẩn bên trong;
+ Các lập trình viên có thể tự kiểm tra;
+ Giúp tối ưu việc mã hoá;
+ Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm
soát lỗi tối đa nhất.
- Nhược điểm của kiểm thử hộp trắng:

+ Vì các bài kiểm tra rất phức tạp, đòi hỏi phải có các nguồn lực có tay nghề
cao, với kiến thức sâu rộng về lập trình và thực hiện;
+ Maintenance test script có thể là một gánh nặng nếu thể hiện thay đổi quá
thường xuyên;
+ Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang
được test, nên các công cụ để phục vụ cho mọi loại triển khai / nền tảng
có thể không sẵn có.
2.1.2.3. Kĩ thuật kiểm thử hộp xám– Gray Box Testing (GBT)
- Khái niệm:
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa
phương pháp kiểm thử hộp đen và phương pháp kiểm thử hộp trắng.
Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần,
tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với
mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là
ở mức hộp đen.
Hình 2.4 Kiểm thử hộp xám

- Ưu điểm kiểm thử hộp xám:
+ Quan điểm kiểm thử của kiểm thử hộp xám là từ quan điểm của người
dùng;
+ Cung cấp các lợi ích của cả thử nghiệm hộp đen và hộp trắng cùng
nhau;

+ Sẽ dựa trên các đặc tả chức năng, mô tả của người dùng và sơ đồ kiến
trúc hệ thống, từ đó xác nhận các yêu cầu ngay từ ban đầu;
+ Việc kiểm tra sẽ tường minh vì sẽ có nhiều sự quan tâm giữa người
kiểm thử phần mềm và người thiết kế hoặc kỹ sư.
- Nhược điểm kiểm thử hộp xám:
+ Kiểm tra hộp xám cũng có thể mất nhiều thời gian để kiểm tra từng
đường dẫn và đôi khi điều này là không thực tế;
+ Rất khó để liên kết lỗi khi thực hiện kiểm tra hộp xám cho một ứng
dụng có hệ thống phân tán;
+ Thông thường sẽ dẫn đến phạm vi kiểm tra thấp hơn so với thực hiện
kiểm tra hộp trắng và đen riêng biệt;
+ Có thể không phù hợp để thử nghiệm một số loại chức năng.
2.1.3. Các loại kiểm thử phần mềm
2.1.3.1. Kiểm thử chức năng
Kiểm thử chức năng chú trọng đến chức năng của chương trình, bảo đảm các
chức năng của hệ thống thỏa mãn đúng yêu cầu. Các loại kiểm thử chức năng
bao gồm:
- Kiểm thử đơn vị (Unit Testing): Kiểm thử đơn vị được định nghĩa là một
loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của
phần mềm được kiểm thử. Kiểm thử đơn vị được thực hiện trong quá trình
phát triển (coding) ứng dụng. Mục tiêu của Kiểm thử đơn vị là cô lập một
phần code và xác minh tính chính xác của đơn vị đó;
- Kiểm thử giao diện (Interface Testing): là một kỹ thuật kiểm thử trong đó
giao diện người dùng của ứng dụng được kiểm tra xem ứng dụng có hoạt
động như mong đợi đối với hành vi giao diện người dùng hay không;
- Kiểm thử tích hợp (Integration Testing): là một loại kiểm thử trong đó
các module của phần mềm được tích hợp logic và được kiểm thử theo
nhóm;

- Kiểm thử hệ thống (System Testing): một phương pháp theo dõi và đánh
giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chỉnh và đã được
tích hợp đầy đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác
định trước;
- Kiểm thử hồi quy (Regression Testing): là một hình thức kiểm thử phần
mềm để xem các chức năng cũ và mới của nó có còn hoạt động đúng sau
khi thay đổi hệ thống hay không;
- Kiểm thử chấp nhận (Acceptance Testing): là một loại kiểm thử thực hiện
bởi khách hàng để xác nhận hệ thống đã làm việc đúng như mong đợi và
thỏa mãn yêu cầu của người dùng;
- Một số công cụ kiểm thử chức năng: Selenium , soapUI , Watir, v.v..
2.1.3.2. Kiểm thử phi chức năng
Kiểm thử phi chức năng chú trọng nhiều hơn vào những khía cạnh khác của
phần mềm, như là hiệu suất, bảo mật,…của phần mềm.
Ví dụ: Bao nhiêu người có thể đăng nhập vào phần mềm cùng 1 lúc.
Các loại kiểm thử phi chức năng bao gồm:
- Documentation testing (Kiểm tra tài liệu): để kiểm tra tính chính xác của
tài liệu hướng dẫn sử dụng và 1 số tài liệu khác;
- Performance Testing (Kiểm thử hiệu năng): là một loại phần mềm kiểm
thử sử dụng để đảm bảo các ứng dụng phần mềm hoạt động hiệu quả
trong khoảng công việc dự kiến của ứng dụng;
- Installation testing (Kiểm thử cài đặt): thường sẽ xoay quanh việc cài đặt,
tháo gỡ các ứng dụng trên các môi trường khác nhau tránh trường hợp
sản phẩm đã cài đặt nhưng không thể hoạt động hoặc không thể cài đặt;
- Usability Testing (Kiểm thử khả năng sử dụng): là kỹ thuật được triển
khai trong thiết kế tương tác lấy người dùng làm trung tâm để đánh giá
sản phẩm hoặc dịch vụ bằng cách thử nghiệm nó với một số người dùng;
- Maintainability Testing (Kiểm thử khả năng bảo trì): Kiểm thử những
thay đổi tới hoạt động hệ thống hoặc tác động của thay đổi môi trường
tới hoạt động hệ thống;

- Reliability Testing (Kiểm thử độ tin cậy): là việc thực hiện một ứng dụng
để các lỗi được phát hiện và loại bỏ trước khi hệ thống được triển khai.
Mục đích của kiểm tra độ tin cậy là xác định độ tin cậy của sản phẩm và
để xác định xem phần mềm có đáp ứng các yêu cầu về độ tin cậy của
khách hàng hay không;
- Portability Testing (Kiểm thử khả năng thích ứng): là việc thực hiện test
để xác định một hệ thống có thể đáp ứng và ổn định với yêu cầu độ tải
cao. Nó được sử dụng chủ yếu để xác định bất kỳ vướng mắc hoặc vấn
đề hiệu suất hơn là việc tìm kiếm lỗi trong một phần mềm;
- Security testing được định nghĩa là 1 dạng kiểm thử phần mềm (Software
Testing) nhằm đảm bảo hệ thống phần mềm và các ứng dụng được bảo
vệ an toàn khỏi các lỗ hổng, mối đe dọa hay bất cứ nguy hiểm nào có thể
dẫn tới tổn thất lớn;
- Một số công cụ kiểm thử chức năng: Jmeter , LoadStorm, v.v…
2.1.4. Các mô hình phát triển phần mềm và ưu nhược điểm
2.1.4.1. Mô hình thác nước – Waterfall model
Đây được coi như là mô hình phát triển phần mềm đầu tiên được sử dụng. Mô hình
này áp dụng tuần tự các giai đoạn của phát triển phần mềm. Đầu ra của giai đoạn trước
là đầu vào của giai đoạn sau. Giai đoạn sau chỉ được thực hiện khi giai đoạn trước đã
kết thúc. Đặc biệt không được quay lại giai đoạn trước để xử lý các yêu cầu khi muốn
thay đổi.
Hình 2.5 Mô hình thác nước

- Phân tích mô hình
+ Requirement gathering: Thu thập và phân tích yêu cầu được ghi lại vào tài liệu
đặc tả yêu cầu trong giai đoạn này;
+ System Analysis: Phân tích thiết kế hệ thống phần mềm, xác định kiến trúc hệ
thống tổng thể của phần mềm;
+ Coding: Hệ thống được phát triển theo từng unit và được tích hợp trong giai
đoạn tiếp theo. Mỗi Unit được phát triển và kiểm thử bởi dev được gọi là Unit
Test;
+ Testing: Cài đặt và kiểm thử phần mềm. Công việc chính của giai đoạn này là
kiểm tra và sửa tất cả những lỗi tìm được sao cho phần mềm hoạt động chính
xác và đúng theo tài liệu đặc tả yêu cầu;
+ Implementation: Triển khai hệ thống trong môi trường khách hàng và đưa ra
thị trường;
+ Operations and Maintenance: Bảo trì hệ thống khi có bất kỳ thay đổi nào từ
phía khách hàng, người sử dụng;
- Ứng dụng: Mô hình thường được áp dụng cho các dự án phần mềm như sau:
+ Các dự án nhỏ , ngắn hạn;
+ Các dự án có ít thay đổi về yêu cầu và không có những yêu cầu không rõ ràng.
- Ưu điểm:
+ Dễ sử dụng, dễ tiếp cận, dễ quản lý;
+ Sản phẩm phát triển theo các giai đoạn được xác định rõ ràng;
+ Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi.
- Nhược điểm:
+ Ít linh hoạt, phạm vi điều chỉnh hạn chế;
+ Rất khó để đo lường sự phát triển trong từng giai đoạn;
+ Mô hình không thích hợp với những dự án dài, đang diễn ra, hay những dự án
phức tạp, có nhiều thay đổi về yêu cầu trong vòng đời phát triển;

+ Khó quay lại khi giai đoạn nào đó đã kết thúc.
2.1.4.2. Mô hình chữ V – V Shaped model
Hình 2.6 Mô hình chữ V

Mô hình V là một phần mở rộng của mô hình thác nước và được dựa trên sự kết
hợp của một giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng. Điều này
có nghĩa là đối với mỗi giai đoạn trong chu kỳ phát triển, có một giai đoạn thử nghiệm
liên quan trực tiếp. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ
bắt đầu sau khi hoàn thành giai đoạn trước.
Với V model thì công việc test được tham gia ngay từ đầu, từ lúc lấy yêu cầu là có
thể “test” bằng cách review tài liệu yêu cầu, rồi cho tới review đặc tả chi tiết, các bản
thiết kế, review code rồi cuối cùng là test ở mức thấp nhất – từng module, chức năng,
màn hình, đến test tích hợp rồi kiểm thử hệ thống. So với mô hình khác thì ở mô hình
này, công việc test đi sát hơn và ngay từ đầu khi bắt đầu phát triển.
- Ứng dụng:
+ Xác định sản phẩm ổn định;
+ Công nghệ không thay đổi và được hiểu rõ bởi nhóm dự án;
+ Không có yêu cầu không rõ ràng hoặc không xác định;
+ Dự án ngắn.
- Ưu điểm:

+ Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành cùng
một lúc;
+ Hoạt động tốt cho các dự án nhỏ, khi các yêu cầu được hiểu rất rõ;
+ Đơn giản và dễ hiểu và dễ sử dụng;
+ Dễ quản lý, mỗi giai đoạn có phân phối cụ thể và quy trình đánh giá.
- Nhược điểm:
+ Khó quản lý kiểm soát rủi ro, rủi ro cao;
+ Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng;
+ Mô hình kém cho các dự án dài và đang diễn ra;
+ Không thích hợp cho các dự án có nguy cơ thay đổi yêu cầu trung bình đến cao;
+ Khi ứng dụng đang ở giai đoạn thử nghiệm, rất khó để quay lại và thay đổi chức
năng.
2.1.4.3. Mô hình xoắn ốc – Spiral model
Hình 2.7 Mô hình xoắn ốc

- Mô tả:
+ Là mô hình kết hợp giữa các tính năng của mô hình prototyping và mô hình thác
nước;

+ Mô hình xoắn ốc được ưa chuộng cho các dự án lớn, đắt tiền và phức tạp;
+ Mô hình này sử dụng những giai đoạn tương tự như mô hình thác nước, về thứ
tự, plan, đánh giá rủi ro, v.v..
+ Phân tích mô hình.
- Các pha trong quy trình phát triển xoắn ốc bao gồm:
+ Objective identification- Thiết lập mục tiêu: xác định mục tiêu, đối tượng cho
từng pha của dự án;
+ Alternate evaluation- Đánh giá và giảm thiểu rủi ro: đánh giá rủi ro và thực hiện
các hành động để giảm thiểu rủi ro;
+ Product development- Phát triển sản phẩm: Lựa chọn mô hình phù hợp để phát
triển hệ thống;
+ Next phase planning- Lập kế hoạch: đánh giá dự án và lập kế hoạch cho pha
tiếp theo;
- Ứng dụng:
+ Mô hình này thường được sử dụng cho các ứng dụng lớn và các hệ thống được
xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn.
- Ưu điểm:
+ Tốt cho các hệ phần mềm quy mô lớn;
+ Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa;
+ Đánh giá thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan
trọng đã được phát hiện sớm hơn.
- Nhược điểm:
+ Manager cần có kỹ năng tốt để quản lý dự án, đánh giá rủi ro kịp thời;
+ Chi phí cao và mất nhiều thời gian để hoàn thành dự án;
+ Phức tạp và không thích hợp với các dự án nhỏ và ít rủi ro;
+ Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn;
+ Chưa được dùng rộng rãi.
2.1.4.4. Mô hình Agile – Agile model

Hình 2.8 Mô hình Agile

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm
đến tay người dùng càng nhanh càng tốt và được xem như là sự cải tiến so với những
mô hình cũ như mô hình “Thác nước (waterfall)” .
- Mô tả:
+ Dựa trên mô hình iterative and incremental;
+ Các yêu cầu và giải pháp phát triển dựa trên sự kết hợp của các function;
+ Trong Agile, các tác vụ được chia thành các khung thời gian nhỏ để cung cấp
các tính năng cụ thể cho bản phát hành cuối.
- Ứng dụng:
+ Có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng cần sự tham gia và
tính tương tác của khách hàng;
+ Sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian
ngắn.
- Ưu điểm:
+ Tăng cường tình thần làm việc nhóm và trao đổi công việc hiệu quả;
+ Các chức năng được xây dựng nhanh chóng và rõ ràng, dế quản lý;
+ Dễ dàng bổ sung, thay đổi yêu cầu;
+ Quy tắc tối thiểu, tài liệu dễ hiểu, dễ sử dụng.
- Nhược điểm:

+ Mô hình Agile được sử dụng rộng rãi trên thế giới nhưng cũng không đồng
nghĩa với phù hợp với tất cả các dự án phần mềm;
+ Không thích hợp để xử lý các phụ thuộc phức tạp;
+ Có nhiều rủi ro về tính bền vững, khả năng bảo trì và khả năng mở rộng;
+ Cần một team có kinh nghiệm;
+ Phụ thuộc rất nhiều vào sự tương tác rõ ràng của khách hàng;
+ Chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn
do thiếu tài liệu.
2.1.4.5. Mô hình Scrum
Scrum là một quy trình phát triển phần mềm theo mô hình Agile nhờ đó mang lại
tính thích nghi cao.
- Mô tả:
+ Chia các yêu cầu ra làm theo từng giai đoạn. Mỗi 1 giai đoạn(sprint) chỉ làm 1 số
lượng yêu cầu nhất định;
+ Mỗi một sprint thường kéo dài từ 1 tuần đến 4 tuần ( ko dài hơn 1 tháng);
+ Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào. Sau đó, sẽ thực hiện code và
test;
+ Cuối sprint là 1 sản phẩm hoàn thiện cả code lẫn test có thể demo và chạy được;
+ Hoàn thành sprint 1, tiếp tục làm sprint 2, sprint… cho đến khi hoàn thành hết
các yêu cầu;
+ Trong mỗi 1 sprint thì sẽ có họp hàng ngày – daily meeting từ 15 – 20 phút. Mỗi
thành viên sẽ báo cáo: Hôm qua tôi đã làm gì? Hôm nay tôi sẽ làm gì? Có gặp
khó khăn gì không?
- Ưu điểm:
+ Một người có thể thực hiện nhiều việc ví dụ như dev có thể test;
+ Phát hiện lỗi sớm;
+ Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ
ràng ngay từ đầu.
- Nhược điểm:
+ Trình độ của nhóm cần có một kỹ năng nhất định;
+ Phải có sự hiểu biết về mô hình aglie;
+ Khó khăn trong việc xác định ngân sách và thời gian;

+ Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo
dài.
2.1.5. Quy trình kiểm thử phần mềm
Kiểm thử phần mềm bao gồm nhiều giai đoạn với sự phối hợp của nhiều bên liên
quan chứ không chỉ là một hoạt động đơn lẻ. Chính vì thế, cần có quy trình kiểm thử
phần mềm để làm rõ các công đoạn, các bước kiểm thử phần mềm, người chịu trách
nhiệm và khi nào việc kiểm thử phần mềm được tiến hành trong toàn bộ quy trình phát
triển phần mềm. Nói cách khác, quy trình kiểm thử phần mềm chính là chuỗi các hoạt
động được tiến hành để thực hiện việc kiểm thử. Các giai đoạn trong quy trình kiểm thử
phần mềm được biểu diễn tổng quát bằng sơ đồ sau:
Hình 2.9 Vòng đời kiểm thử phần mềm

2.1.5.1. Phân tích yêu cầu (Requirement analysis)
Phân tích yêu cầu trong giai đoạn này sẽ được trưởng nhóm kiểm thử (test leader)
bắt đầu nghiên cứu các yêu cầu xem chúng có thể kiểm thử được hay không? Nếu
không thì yêu cầu là mơ hồ và cần được xem xét lại, các kiểm thử viên sẽ cần làm việc
với các bên liên quan để làm rõ các yêu cầu. Từ đó các kiểm thử viên sẽ xác định loại
kiểm thử sẽ dùng và độ ưu tiên của các hoạt động kiểm thử, xác định môi trường kiểm
thử cần chuẩn bị.
Yêu cầu có thể là yêu cầu về chức năng (mô tả tính năng của phần mềm) cũng như
yêu cầu hiệu năng, tính bảo mật, tính hữu dụng của phần mềm (non-functional). Các
kiểm thử viên cũng đánh giá khả năng kiểm thử tự động ở trong giai đoạn này.

2.1.5.2. Lập kế hoạch kiểm thử (Test planning)

Giai đoạn này là giai đoạn vạch ra chiến lược kiểm thử. Kiểm thử viên cần chuẩn
bị chiến lược kiểm thử, kế hoạch kiểm thử, lịch biểu kiểm thử và ước lượng thời gian
kiểm thử. Lên kế hoạch nhân sự, xác định vai trò và trách nhiệm tương ứng, có thể lên
kế hoạch đào tạo nếu cần.
2.1.5.3. Thiết kế kịch bản kiểm thử ( Test case development)
Các kiểm thử viên bắt đầu xây dựng các ca kiểm thử, kịch bản kiểm thử và dữ liệu
cần thiết dựa trên yêu cầu của phần mềm. Mục tiêu cần đạt được ở giai đoạn này là bộ
ca kiểm thử/ kịch bản kiểm thử, và bộ dữ liệu kiểm thử.
Viết ca kiểm thử cần cho các trường hợp sẽ kiểm thử bao gồm cả 3 trường hợp:
thành công, thất bại và không xác định (là trường hợp mới phát sinh hoặc không có tài
liệu nào mô tả). Viết mã nếu có sử dụng công cụ để thực hiện kiểm thử tự động cho
kiểm thử chức năng, giao diện hoặc các kịch bản.
2.1.5.4. Thiết lập môi trường kiểm thử ( Test enviroment set up )
Giai đoạn này có thể được làm đồng thời với giai đoạn thiết kế ca kiểm thử và cũng
có thể không cần nếu trường hợp khách hàng đã chuẩn bị sẵn cho mình rồi thì khi đó
kiểm thử viên chỉ cần kiểm tra xem nó có hoạt động tốt hay không?
Ở giai đoạn này các kiểm thử viên cần chuẩn bị môi trường kiểm thử như phần
mềm, phần cứng cần thiết.
2.1.5.5. Thực hiện kiểm thử ( Test execution )
Giai đoạn này sẽ tiến hành kiểm thử dựa trên kế hoạch kiểm thử, các dữ liệu kiểm
thử và môi trường kiểm thử đã được chuẩn bị ở các giai đoạn trước. Kiểm thử viên tiến
hành kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hệ thống và giúp khách hàng
tiến hành kiểm thử chấp nhận của người dùng.
Nếu phát hiện ra lỗi (các trường hợp bị thất bại), kiểm thử viên sẽ tiến hành log
bug và chuyển lập trình viên (developer) để sửa lỗi và kiểm tra lại. Sau khi lỗi được
sửa thì kiểm thử viên sẽ kiểm tra lại. Đóng lỗi nếu đã được sửa thành công (kiểm thử
hồi quy).
Trong quá trình này có thể có update thêm một số case còn thiếu (nếu có hoặc phát
sinh thêm).
2.1.5.6. Kết thúc quá trình kiểm thử ( Test cycle closure)

Giai đoạn này, các kiểm thử viên thực hiện hoàn thành báo cáo, các tài liệu kiểm
thử (báo cáo hàng ngày, hàng tuần, ca kiểm thử – số lượng ca kiểm thử thành công,
thất bại, lỗi, đánh giá mức độ nghiêm trọng của các lỗi). Các kiểm thử viên cũng cần
thảo luận với nhau và rút kinh nghiệm, những điểm tốt nên phát huy và điểm xấu cần
loại bỏ để nâng cao chất lượng cho những dự án sau đó.
2.2. Tổng quan về API
2.2.1. Khái niệm
Hình 2.10 API

API là viết tắt của Application Programming Interface là giao diện lập trình ứng
dụng, phần mềm trung gian cho phép các ứng dụng giao tiếp với nhau.Khi sử dụng ứng
dụng trên thiết bị di động, ứng dụng sẽ kết nối Internet và gửi dữ liệu tới máy chủ. Sau
đó máy chủ lấy dữ liệu, phân tích dữ liệu, thực hiện các hành động cần thiết và gửi dữ
liệu trở lại thiết bị di động. Ứng dụng phân tích dữ liệu và hiển thị các thông tin đọc
được cho nguời dùng được gọi là API.
2.2.2. Lý do cần phải test API

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, tester 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ì vậy, lúc này việc test hoàn toàn không phụ
thuộc gì vào client. Kể cả khi client làm xong rồi, nếu tester 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. Khi làm hệ thống web services, dự án chỉ viết
API cho bên khác dùng, tester sẽ không có client để test giống như các dự án khác cho
nên phải test API hoàn toàn.
2.2.3. Những điều cần lưu ý khi thực hiện API Testing

Kiểm thử API nên được thực theo các phương pháp kiểm thử trong quy trình phát
triển phần mềm:
- Discovery testing: Kiểm tra các API khi truy cập các tài nguyên và xem các API
truy cập các tài nguyên, có được các quyền xem, xóa và sửa hợp lệ hay không;
- Usability testing: Loại kiểm thử này kiểm tra xem API có làm đúng chức năng
và thân thiện hay không và API được tích hợp tốt trên các nền tảng khác hay
không;
- Security testing: Loại kiểm thử này bao gồm các loại xác thực được yêu cầu và
xem các dữ liệu nhạy cảm có được mã hóa thông qua HTTP hoặc cả hai hay
không;
- Automated testing: Kiểm thử API được nâng cao trong việc tạo ra các đoạn mã
hoặc công cụ mà có thể chạy API thường xuyên;
- Documentation: Tester phải đảm bảo rằng các tài liệu thích hợp và cung cấp đầy
đủ các thông tin để tương tác với API. Tài liệu nên là một phần khi bàn giao.
2.2.4. Các testcase cho kiểm thử API
Các test case cho kiểm thử API được dựa trên:
- Dữ liệu trả về dựa trên điều kiện đầu vào: Điều này tương đối dễ dàng kiểm tra,
như đầu vào có thể được xác định và kết quả có thể được xác thực;
- Không trả về gì cả: Khi không có giá trị trả về, hành vi của API trên hệ thống có
thể được kiểm tra;
- Kích hoạt một vài API/event/interrupt: Nếu đầu ra của một API kích hoạt các
event hoặc interrupt, thì các listeners của event và interrupt nên đươc kiểm tra;
- Cập nhật cấu trúc dữ liệu: Cập nhật cấu trúc dữ liệu sẽ có một vài kết quả hoặc
ảnh hưởng lên hệ thống, và chúng nên được kiểm tra;
- Chỉnh sửa các tài nguyên (resources) nhất định: Nếu API gọi chỉnh sửa một vài
tài nguyên thì nó nên được xác nhận bằng cách truy cập vào các tài nguyên tương
ứng.

2.2.5. Sự khác nhau giữa API testing và Unit testing
Bảng 2.1 Sự khác nhau giữa API testing và Unit testing
Unit testing API testing
Lập trình viên thực hiện Tester thực hiện
Từng chức năng được kiểm thử Các chức năng liên quan đến nhau cần
được kiểm thử
Lập trình viên có thể truy cập vào source Tester không thể truy cập vào source
code code
Phải kiểm tra cả UI Chỉ kiểm tra các hàm API
Chỉ các chức năng đơn giản được kiểm Tất cả các chức năng được kiểm thử
thử
Giới hạn phạm vi Phạm vi mở rộng
Thường được chạy trước khi build Thường được chạy sau khi build

CHƯƠNG 3. CÔNG CỤ KIỂM THỬ POSTMAN

3.1. Giới thiệu POSTMAN
3.1.1. Khái niệm
Postman là một công cụ rất thuận tiện cho việc test Rest API, được 4 triệu developer
trên toàn thế giới tin dùng. Với Postman, ta có thể gọi RestAPI mà không cần viết dòng
code nào. Postman hỗ trợ tất cả các phương thức HTTP (GET, POST, PUT, PATCH,
DELETE, …). Bên cạnh đó, nó còn cho phép lưu lại lịch sử các lần request, rất tiện cho
việc sử dụng lại khi cần.
3.1.2. Ưu nhược điểm của POSTMAN
- Ưu điểm:
+ Postman sử dụng Collection nên người dùng có thể tạo bộ sưu tập cho những
lệnh gọi API của họ. Mỗi một bộ sưu tập đều có thể tạo ra thư mục con với
nhiều request. Đây là điểm mạnh giúp quá trình tổ chức các bộ thử nghiệm
được dễ dàng hơn;
+ Trong Postman, Collections và environment sẽ được import hoặc export giúp

người dùng có thể chia sẻ tệp dễ dàng hơn.;
+ Postman có khả năng test trạng thái phản hồi của HTTP;
+ Hỗ trợ gỡ lỗi: Bộ phận bảng điều khiển của Postman có thể giúp người dùng
kiểm tra dữ liệu đã xuất. Từ đó, quá trình gỡ lỗi sẽ trở nên dễ dàng và linh hoạt
hơn;
+ Hỗ trợ tạo thử nghiệm: Những điểm kiểm tra thử nghiệm và xác định trạng thái
phản hồi HTTP thành công. Và vai trò xác nhận có thể được thêm vào mỗi lệnh
gọi API nhằm đảm bảo phạm vi kiểm tra;
+ Tích hợp liên tục: Postman có khả năng hỗ trợ tích hợp liên tục cho các hoạt
động phát triển và có thể được duy trì.
- Nhược điểm:
+ Những bản tính phí mới hỗ trợ các tính năng advance: Team work, support trực
tiếp, v.v.
3.1.3. Những tính năng đặc biệt
- Gửi các HTTP Request kèm theo các method như Post, Patch, Delete, Get;

- Post mọi dữ liệu dưới định dạng key-value, text, json;
- Truy xuất và hiển thị kết quả trả về dưới các dạng text, JSON, hình ảnh, XML;
- Thay đổi các header trong request;
- Hỗ trợ authorization.
3.2. Các chức năng chính của POSTMAN

- New: Chức năng hỗ trợ tạo lập các request, collection hay enviroment mới;
- Import: Chức năng này giúp người dùng import collection hay environment;
- Runner: Chức năng này cho phép kiểm tra hoàn toàn tự động qua collection
runner;
- Open New: Là chức năng dùng trong mở tab mới, cửa sổ Runner hoặc Postman;
- My Workspace: Chức năng hỗ trợ tạo không gian làm việc cho cá nhân hoặc
nhóm;
- Invite: Chức năng được sử dụng để mời thành viên khi có nhu cầu cộng tác với
nhiều người;
- History: Mọi request đã thực hiện đều được lưu trữ và hiển thị tại History, người
dùng có thể thoải mái theo dõi lịch sử hoạt động của mình;
- Collections: Đây là chức năng hỗ trợ tạo lập ra các bộ thử nghiệm. Mỗi collection
thường có nhiều thư mục con và Request. Hai yếu tố này có thể dẫn đến trùng lặp;
- Tab Request : Hỗ trợ hiển thị phần tiêu đề của Requet đang hoạt động, request
không có phần tiêu đề sẽ hiển thị ra ‘Untitled Request’;
- HTTP Request: Nơi người dùng có thể click vào và thấy một loạt các request khác
nhau. Thông thường, Get và Post là hai Request phổ biến nhất trong thử nghiệm;
- Request URL: Chức năng này còn được gọi với cái tên là Endpoint. Đây là nơi
người dùng có thể xác định được các liên kết đến API nào;
- Save: Chức năng này cho phép người dùng lưu trữ các thay đổi mới khi tiến hành
các thay đổi với request;
- Params: Người dùng viết những tham số cần thiết của mỗi request tại đây;
- Authorization: Đây là chức năng liên quan đến việc cấp quyền để truy cập API.
Nó có thể tồn tại dưới nhiều dạng khác nhau như, cần được cấp quyền.
- Headers: Người dùng có thể tạo header theo yêu cầu và cách tổ chức riêng của
mình;

- Body: Người dùng tùy chỉnh các chi tiết trong request tại đây;
- Pre-request Script: Chức năng này bao gồm nhiều tập lệnh được tiến hành trước
khi request để chắc chắn rằng các kiểm tra được hoạt động trong đúng môi trường;
- Tests: Đây là các script được thực thi khi request. Điều quan trọng là phải có các
thử nghiệm như thiết lập các điểm checkpoint để kiểm tra trạng thái là ok, dữ liêu
nhận được có như mong đợi không và các thử nghiệm khác.
3.3. Dowload và cài đặt công cụ POSTMAN
- Truy cập trang https://www.getpostman.com/downloads/ và chọn nền tảng muốn tải về
như cho Mac, Windows hoặc Linux. Click Download.
Hình 3.1. Giao diện trang chủ POSTMAN

3.4. Các thành phần chính của POSTMAN
Settings: Chứa các thông tin về cài đặt chung.
- Thông tin Account: dùng để Login, logout và sync data;
- Settings tùy chỉnh: themes, shortcut, format, v.v;
- Import data từ ngoài vào.
Collections: Lưu trữ thông tin của các API theo folder hoặc theo thời gian.

Hình 3.2. Collections của Postman

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 test API.
Đây là phần mà tester phải làm việc nhiều nhất.

Hình 3.3. API content của Postman

Trong phần này gồm có 3 thành phần chính:
• Environments: Chứa các thông tin môi trường. Trong dự án thực tế, người
ta thường dùng deploy RestAPI trên nhiều môi trường (local,
test, production). Postman hỗ trợ cài đặt các biến môi trường (url gốc, API
key, …), thuật tiện hơn khi cần test trên nhiều môi trường;
• Request: Phần chứa các thông tin chính của API;
• Response: Chứa các thông tin trả về sau khi Send Request.
3.5. Collections trong POSTMAN

Khi làm việc với API, việc tạo ra nhiều request mà không đóng gói chúng vào một
folder sẽ làm cho việc tìm ra request cần tìm gặp một số vấn đề sau đây:
- Sẽ phải dùng History để tìm lại những request đã dùng, tương tự như việc suốt
ngày phải lục lọi phần History của Chrome, trong khi chỉ cần 1 động tác
bookmark lại là xong;
- Không dùng được chức năng tạo API documents tự động mà Postman cung cấp;
- Không thể dùng được chức năng Runner, giúp chạy liên tục các Request.
Vì thế, Collections đã ra đời nó giúp đóng gói những request này vào chung một chỗ.
3.5.1. Cách tạo collection

- Click vào button [tạo collection] bên sidebar;
Hình 3.4. Tạo Collection

- Điền tên và mô tả (không bắt buộc) collection đó;
Hình 3.5. Viết tên collection và mô tả

- Lưu request vào Collection.
3.5.2. Các settings chính của 1 Collection.

Hình 3.6. Các settings của collection

- Share collections: tạo ra link để share với người khác collection (bị hạn chế
bởi kiểu account);
- Run collection: chạy tất cả các request trong collection;
- Edit: Sửa tên và mô tả của collection;
- Add request: tạo thêm request mới bên trong Collection đó;
- Add folder: tạo thêm folder mới bên trong Collection đó;
- Monitor Collection: Dùng để test hiệu năng (bị hạn chế bởi kiểu account);
- Mock Collection: giúp giả lập các API sử dụng chức năng Example mà
postman hỗ trợ. (bị hạn chế bởi kiểu account);
- Publish Docs: Tạo ra API Docs định dạng HTML;
- Delete: Xóa Collection;
- Rename: Đổi tên của collection;
- Duplicate: nhân đôi collection đang có;
- Export: Xuất collection ra dạng file .json.

3.6. Cách sử dụng Environments

- Chức năng chính: 1 chỗ lưu “biến” giống như “biến” trong code để có thể tái sử
dụng ở nhiều nơi;
- Ứng dụng:
+ Nhanh chóng chuyển qua lại giữa các môi trường Dev và Product mà không
cần tạo lại các request mới vì phải thay đổi lại URL;
+ Giúp lưu lại giá trị của response API trước để điền vào API sau;
+ Không phải sửa giá trị của các tham số quá nhiều lần;
+ Ở Postman sẽ chia làm 2 loại Environments: Local và Global
o Local: Phạm vi ảnh hưởng chỉ có khi chọn đúng Enviroments;
o Global: Phạm vi ảnh hưởng đến toàn bộ các project có trong Postman,
nhưng nếu có 2 biến cùng tên ở Local và Global thì sẽ ưu tiên lấy Local.
- Vị trí của Environment trong khung làm việc của Postman:
Hình 3.7. Vị trí của Environment trong khung làm việc của Postman
Test response là tính năng đặc biệt quan trọng với những người test API. Không thể
suốt ngày run từng cái request rồi check từng kết quả trả về một cách thủ công được. Phần
này cung cấp 2 tính năng cực hay giúp tester đẩy nhanh được tốc độ test API:
- Check tự động kết quả trả về của từng field với 1, 2 dòng code, rất dễ, không cần
biết code cũng làm được;

- Lưu giá trị của Response thành biến trong Environment để tiếp tục truyền vào param
của API tiếp theo.
Hình 3.8. Tests Response

CHƯƠNG 4. TRIỂN KHAI KIỂM THỬ API BẰNG CÔNG CỤ POSTMAN

Chương 4 xây dựng kịch bản kiểm thử cho các chức năng chính của API bán sách
online. Đồng thời đưa ra quy trình thực thi kiểm thử tự động, phương hướng giải quyết bài
toán và đưa ra các báo cáo kết quả kiểm thử.
4.1. Giới thiệu về website bán sách Nhã Nam và các chức năng chính cần kiểm thử
của API bán sách
4.1.1. Giới thiệu website bán sách Nhã Nam
Mục đích xây dựng phần mềm bán sách online là để giúp người mua có trải nghiệm
mua hàng tốt hơn khi không phải đến cửa hàng mà vẫn có thể mua sách. Ngoài ra còn
có thể xem được các đánh giá của người mua hàng khác đối với sách để từ đó người
mua hàng yên tâm hơn về giá cả cũng như chất lượng sách.
Hình 4.1. Trang chủ website bán sách của Nhã Nam
Dưới đây là các chức năng chính cần được kiểm thử để xác định được rằng phần
mềm có hoạt động tốt với người dùng. API bán sách này được mô phỏng lại từ trang
Web bán sách của nhà sách Nhã Nam với các chức năng chính bao gồm: Xem danh sách
Sách, Đặt hàng, Sửa thông tin đơn hàng, Xóa đơn hàng, Tìm kiếm đơn hàng, Tìm kiếm
sách theo bộ lọc.
4.1.2. Một số chức năng chính của API bán sách

4.1.2.1. Chức năng xem danh sách tất cả Sách

- Sau khi truy cập được vào hệ thống sẽ đi đến phần Danh mục Sách để xem
thông tin Sách;
Bảng 4.1 Mô tả yêu cầu chức năng xem danh sách tất cả Sách
Tên thuộc tính Kiểu dữ Required Mô tả

liệu
STT - - Hiển thị số thứ tự sách
Name String - Hiển thị tên sách
Author Boolean - Hiển thị vào tên tác giả của sách
Type String - Hiển thị tên loại sách
Price String - Hiển thị giá tiền
Curent-stock Number - Hiển thị số lượng sách trong kho
Available String - Hiển thị trạng thái hoạt động của

sách.
4.1.2.2. Chức năng xem danh sách tất cả đơn hàng

- Sau khi truy cập được vào hệ thống, người dùng sẽ đi đến phần Quản lý Đơn
hàng đã đặt để xem thông tin đơn hàng;
Bảng 4.2 Mô tả yêu cầu chức năng xem danh sách tất cả đơn hàng

liệu
ID - - Hiển thị ID đơn hàng, tự sinh

khi tạo đơn hàng mới
bookId String - Hiển thị ID sách, được lấy từ

danh mục Sách
customerName String - Hiển thị tên khách hàng đã đặt

sách
CreatedBy String - Hiển thị mã người tạo đơn hàng
quantity String - Hiển thị số lượng sách đã đặt

4.1.2.3. Chức năng đặt hàng

- Sau khi truy cập được vào hệ thống sẽ đi đến phần Danh mục Sách để xem hoặc
thêm mới 1 đơn hàng;
- Người dùng điền các trường thông tin bắt buộc bao gồm: BookID (ID của sách),
CustomerName(Tên khách hàng) và điền accessToken đã đăng ký.
- AccessToken này dùng để định dạng user.
- Nhấn nút “Lưu” để thêm mới đơn hàng. Hệ thống kiểm tra dữ liệu nhập vào
đúng định dạng, lưu vào cơ sở dữ liệu.
- Chuyển về màn hình Danh mục và thông báo "Đặt hàng thành công" với API
đã đăng ký;
Bảng 4.3 Mô tả yêu cầu chức năng thêm mới đơn hàng

liệu
bookId String - Nhập vào mã Sách
CustomerName String - Nhập vào tên khách hàng
quantity number - Nhập số lượng sách muốn đặt

hàng
4.1.2.4. Chức năng sửa thông tin đơn hàng

- Sau khi truy cập được vào hệ thống sẽ đi đến phần quản lý đơn hàng để xem
hoặc chỉnh sửa thông tin đơn hàng;
- Người dùng điền các trường thông tin chỉnh sửa bao gồm: CustomerName(Tên
khách hàng), Type(thể loại sách) và điền accessToken đã đăng ký.
- AccessToken này dùng để định dạng user.
- Nhấn nút “Lưu” để chỉnh sửa đơn hàng. Hệ thống kiểm tra dữ liệu nhập vào
đúng định dạng, lưu vào cơ sở dữ liệu.
- Chuyển về màn hình Danh sách và thông báo "Cập nhật thành công" với API
đã đăng ký;

Bảng 4.4. Mô tả yêu cầu chức năng thêm mới đơn hàng

liệu
CustomerName String Bắt buộc Cho phép người dùng cập nhật
tên khách hàng.
Type String Bắt buộc Cho phép người dùng cập nhật
tên sách
4.1.2.5. Chức năng xóa đơn hàng

- Sau khi truy cập được vào hệ thống sẽ đi đến phần quản lý đơn hàng để xem
hoặc xóa thông tin đơn hàng;
- Nhấn nút “Xóa” để xóa đơn hàng. Hệ thống kiểm tra dữ liệu tồn tại trong cơ sở
dữ liệu và thực hiện xóa.
- Chuyển về màn hình Danh sách và thông báo "Xóa thành công";
4.1.2.6. Chức năng tìm kiếm thông tin đơn hàng
- Sau khi truy cập được vào hệ thống sẽ đi đến phần quản lý đơn hàng để tìm
kiếm đơn hàng và một số thuộc tính liên quan đến đơn hàng;
- Cho phép người dùng tìm kiếm gần đúng theo trường orderID;
- Nhấn nút “Tìm kiếm” nếu thông tin đơn hàng tồn tại trong database thì sẽ hiển
thị thông tin đơn hàng và trạng thái trả về;
- Hệ thống thông báo không thành công tức là thông tin nhập vào không đúng
định dạng hoặc thông tin tìm kiếm không tồn tại trong database.
4.1.2.7. Chức năng tìm kiếm thông tin sách
- Sau khi truy cập được vào hệ thống sẽ đi đến phần quản lý sách để tìm kiếm
sách và một số thuộc tính liên quan đến sách;
- Cho phép người dùng sử dụng bộ lọc Type hoặc Limit để tìm kiếm thông tin
sách. Có thể tìm kiếm theo ID sách.
- Nhấn nút “Tìm kiếm” nếu thông tin sách tồn tại trong database thì sẽ hiển thị
thông tin sách và trạng thái trả về;

- Hệ thống thông báo không thành công tức là thông tin nhập vào không đúng
định dạng hoặc thông tin tìm kiếm không tồn tại trong database.
4.2. Thiết kế testcase cho các chức năng chính
Các mẫu kiểm thử chức năng trên được ghi lại thành các HTTP Request bao gồm các
chức năng: đặt hàng, sửa thông tin đơn hàng, xóa đơn hàng, tìm kiếm đơn hàng, tìm kiếm
sách theo bộ lọc. Các testcase cần kiểm thử như sau:
4.2.1. Chức năng xem danh sách tất cả sách và đơn hàng
Bảng 4.5. Testcase cho chức năng xem danh sách tất cả sách và đơn hàng
STT Test Case Pre-condition Steps Desired Actual

Name results Results
1 All 1.Đăng nhập 1. Tại Tests nhập: 1.Status 1. Kết

pm.test("Status code
book_200 postman is 200", function ( “200 OK” quả trả về
) { danh sách
2.Chọn phương thức pm.response.to.h
ave.status(200); tất cả
GET });
sách có
3.Điền request URL: trong
https://simple- CSDL
books-
api.glitch.me/book
s
2 All 1.Đăng nhập 1. Tại Tests nhập: 1.Status 1. Kết

book_404 postman is 404", function ( “404 Not quả trả về
(Nhập sai ) {
2.Chọn phương thức pm.response.to.h Found” không
URL) ave.status(404);
tìm thấy
GET });
dữ liệu
3.Điền request URL:
https://simple-
bookks-


api.glitch.me/booo
ks
3 All Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết quả
tại Header/Auth:
books_20 postman trả về danh trả về:
d84a2231c24b01bd
0 1c38029b989f35e7f sách các Message
2.Chọn phương thức 70499986162ea82c9
POST 2eb2adfb07182f đơn hàng " 200
2.Status OK"
3.Điền request URL:
https://simple- “200 OK”
books-
api.glitch.me/orders
4 All Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết quả
tại Header/Auth:
book_404 postman trả về trả về
d84a2231c24b01bd
(Nhập sai 1c38029b989f35e7f status: Message
2.Chọn phương thức 70499986162ea82c9
URL) "404 Not " 404 Not
POST 2eb2adfb07182f
Found" Found "
3. Điền request
URL: https://simple-
books-
api.glitch.me/ordeer
s
4.2.2. Chức năng đặt hàng

Bảng 4.6. Testcase cho chức năng đặt hàng

1 Order 1.Đăng nhập 1. Nhập accesToken 1.Status 1. Kết

tại Header/Auth:
book_201 postman quả trả
d84a2231c24b01bd “201
1c38029b989f35e7f về: Thêm
2.Chọn phương thức 70499986162ea82c Created”
mới dữ
POST 92eb2adfb07182f
2. Tại liệu thành
3.Điền request Body/raw/json
công
nhập:
URL: {
"bookId": 2,
https://simple- "customerName":
books- "{{$randomFullName
}}"
api.glitch.me/order }
2 Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết quả

tại Header/Auth:
book_404 postman trả về: trả về:
d84a2231c24b01bd
(Nhập sai 1c38029b989f35e7f Không tìm Message
2.Chọn phương thức 70499986162ea82c
API) thấy dữ liệu " 404 Not
2. Tại Found"
3.Điền request Body/raw/json 2.Status
nhập: “404 Not
URL: https://simple- { "bookId": 2,
books-api.glitch.me/ "customerName": Found”
"{{$randomFullName
orderss }}"
}
3 Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết quả

tại Header/Auth:
book_404 postman trả về trả về
d84a2231c24b01bd
(Nhập sai 1c38029b989f35e7f status: "401 Message
2.Chọn phương thức 70499986162ea82c
URL) Unauthorize " 401
2. Tại d" Unauthori
3. Điền request Body/raw/json
nhập: zed "
URL: https://simple- { "bookId": 2,


boooks- "customerName":
"{{$randomFullName
api.glitch.me/orders }}"
}
4.2.3. Chức năng chỉnh sửa thông tin đơn hàng
Bảng 4.7 Testcase cho chức năng chỉnh sửa thông tin đơn hàng

1 Update 1.Đăng nhập 1. Nhập accesToken 1.Status 1. Kết

Order tại Auth: quả trả về
postman d84a2231c24b01bd “200 OK”
book_200 Message
2.Chọn phương thức 1c38029b989f35e7f
70499986162ea82c 200 OK
PATCH
92eb2adfb07182f
3.Điền request 2. Tại Params/Path
Variable nhập:
URL:
Key: orderId
https://simple- Value:UDtpfRDpd
books- kfr9UHD1Se0B
3. Tại
api.glitch.me/order Body/raw/json
s/ nhập:
{
4.Tồn tại ID đơn "customerName":
"{{$randomFullName
hàng }}"
}
2 Update 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết

Order tại Auth: quả trả
postman trả về:
d84a2231c24b01bd về:
book_404 Không tìm Message
70499986162ea82c " 404
PATCH thấy dữ
92eb2adfb07182f Not
liệu


3.Điền request 2. Tại Params/Path 2.Status Found"

Variable nhập: với
URL: “404 Not {
Key: orderId
https://simple- Value: fee Found” "error":
"No order
books- 3. Tại with id
Body/raw/json feee."
api.glitch.me/order }
nhập:{
s "customerName":
"{{$randomFullName
}}"
}

postman trả về:
(Nhập sai 70499986162ea82c " 404
PATCH thấy dữ
92eb2adfb07182f Not
API)
2. Tại Params/Path liệu Found"
3.Điền request
Variable nhập:
URL: 2.Status
Key: orderId
https://simple- Value: “404 Not
books- d84a2231c24b01bd Found”
1c38029b989f35e7f
api.glitch.me/ordd 70499986162ea82c
ers 92eb2adfb07182f
3. Tại
Body/raw/json
nhập:{
"customerName":
"{{$randomFullName
}}"
}
4 Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết

book_404 postman tại Auth:
trả về: quả trả
d84a2231c24b01bd
(Nhập sai Không tìm
2.Chọn phương thức 1c38029b989f35e7f về:
URL) 70499986162ea82c thấy dữ
PATCH
92eb2adfb07182f
Message
2. Tại Params/Path liệu " 401
Variable nhập:


3.Điền request Key: orderId Unauthori

2.Status “
URL: Value: zed”
d84a2231c24b01bd 401
https://simple- 1c38029b989f35e7f Unauthorize
bookkks- 70499986162ea82c
d”
92eb2adfb07182f
api.glitch.me/order
3. Tại
s Body/raw/json
nhập:{
"customerName":
"{{$randomFullName
}}"}
4.2.4. Chức năng xóa đơn hàng
Bảng 4.8 Testcase cho chức năng xóa đơn hàng

1 Delete 1.Đăng nhập 1. Nhập accesToken 1.Status 1. Kết

Order tại Auth: quả trả về
postman d84a2231c24b01bd “200 OK”
book_200 Message
70499986162ea82c 200 OK
DELETE
92eb2adfb07182f
3.Điền request 2. Tại Params/Path
Variable nhập:
URL:
Key: orderId
https://simple- Value:UDtpfRDpd
books- kfr9UHD1Se0B
3. Tại Test nhập:
api.glitch.me/order pm.test("Status cod
e is 204", function
s/ () {
pm.response.to.
4.Tồn tại ID đơn have.status(204);
});
hàng


2 Delete 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết

postman trả về:
(ID đơn 70499986162ea82c " 404
DELETE thấy dữ
92eb2adfb07182f Not
hàng
không tồn 3.Điền request với
Variable nhập: 2.Status
URL: {
tại trong Key: orderId “404 Not "error":
DB) https://simple- Value:fee Found” "No order
3. Tại Test nhập: with id
books- fee."
pm.test("Status cod
}
api.glitch.me/order e is 204", function
() {pm.response.to
s/ .have.status(204);}
);

postman trả về:
(Nhập sai 70499986162ea82c " 404
DELETE thấy dữ
92eb2adfb07182f Not
API)
3.Điền request
Variable nhập:
URL: 2.Status
Key: orderId
https://simple- Value:fee “404 Not
books- 3. Tại Test nhập: Found”
pm.test("Status cod
api.glitch.me/orrde e is 204", function
() {
rs/ pm.response.to.
have.status(204);
});
4 Order 1.Đăng nhập 1. Nhập accesToken 1.Kết quả 1.Kết

book_404 postman tại Auth:
trả về: quả trả
d84a2231c24b01bd
(Nhập sai Không tìm
2.Chọn phương thức 1c38029b989f35e7f về:
URL) 70499986162ea82c thấy dữ
DELETE
92eb2adfb07182f
Message
liệu


3.Điền request 2. Tại Params/Path " 401

2.Status “
URL: Variable nhập:
401 Unauthori
Key: orderId
Unauthorize zed”
https://simple- Value:fee
bookkks- 3. Tại Test nhập:
d”
pm.test("Status cod
api.glitch.me/order e is 204", function
() {
s/ pm.response.to.
have.status(204);
});
4.2.5. Chức năng tìm kiếm thông tin đơn hàng
Bảng 4.9 Testcase cho chức năng tìm kiếm thông tin đơn hàng

1 Search 1.Đăng nhập 1. Nhập accesToken 1. Kết quả 1. Kết

book tại Auth: quả trả về
postman d84a2231c24b01bd trả về
order_ID Message thông tin
_200 70499986162ea82c9 200 OK chi tiết
GET
2eb2adfb07182f đơn hàng
3.Điền request URL: 2. Tại Params/Path với ID đã
Variable nhập:
https://simple- Key: orderId tìm kiếm
books- Value: và
79R0Ykpc2IowwI
api.glitch.me/order Message
DHAWwe_
s//:orderld 3. Tại 200 OK
Body/raw/json nhập:
{
"bookId": 3,
"customerName":"Dot"
}
is 200", function (
) {


pm.response.to.h
ave.status(200);
});

tại Auth: quả trả về
book postman trả về
d84a2231c24b01bd Message
order_ID Message "404 Not
2.Chọn phương thức 1c38029b989f35e7f Found"
_404 70499986162ea82c9 404 Not
GET với
2eb2adfb07182f {
Found
3.Điền request URL: 2. Tại Params/Path "error":
"No order
Variable nhập:
https://simple- with id
Key: orderId idbook."
books- Value: idbook }
3. Tại
api.glitch.me/order
Body/raw/json nhập:
s//:orderld {
"bookId": 3,
"customerName":"Dot"
}
is 404", function (
) {
pm.response.to.have.
status(404);
});
3 Seach 1.Đăng nhập 1. Nhập accesToken 1. Kết quả 1. Kết

tại Auth: quả trả về
book postman trả về
d84a2231c24b01bd Message
order_cus Message "404 Not
2.Chọn phương thức 1c38029b989f35e7f Found"
tomer_20 70499986162ea82c9 200 OK và
GET với
0 2eb2adfb07182f {
danh sách
3.Điền request URL: 2. Tại Params/Path "error":
Variable nhập: các đơn "No order

Key:customerName hàng có tên Tommy Led
books- Value: Tommy ner."
"Tommy }
Ledner
api.glitch.me/order Ledner"
3. Tại
s//:customerName Body/raw/json nhập:
{ "bookId": 3}


is 200", function (
) {
status(200);
});
4.2.6. Chức năng tìm kiếm thông tin sách
Bảng 4.10 Testcase cho chức năng tìm kiếm thông tin sách


book_ID_ postman tại Auth: quả trả về
d84a2231c24b01bd trả về
200 Message thông tin
70499986162ea82c9 200 OK chi tiết
GET
2eb2adfb07182f sách với
3.Điền request URL: 2. Tại Params/Path ID đã tìm
Variable nhập:
https://simple- kiếm và
Key: id
books- Value:2 Message
api.glitch.me/books/ 3. Tại Test nhập: 200 OK
/:id is 200", function (
) {
pm.response.to.h
ave.status(200);
});
2 Search 1.Đăng nhập 1. Tại Tests nhập: 1.Status 1. Kết

pm.test("Status code quả trả về
book_ID_ postman is 404", function ( “404 Not Message
404 (ID ) { "404 Not
2.Chọn phương thức pm.response.to.have. Found”
Found"
không có status(404);
GET });
với
trong {
"error":
danh 3.Điền request URL:
"No book
sách)
20"
books- }


api.glitch.me/books/
/:id
3 Search 1.Đăng nhập 1. Tại Params/Query 1. Kết quả 1. Kết

books_ty Path nhập: quả trả về
postman Key: type trả về
pe&limit Message thông tin
2.Chọn phương thức Value: fiction
_200 Key: limit 200 OK sách với
GET
Value: 3 bộ lọc đã
3.Điền request URL: 3. Tại Test nhập: tìm kiếm
https://simple- is 200", function ( và
) {
books- Message
api.glitch.me/books? status(200);
200 OK
});
type=fiction&limit=
3
4 Search 1.Đăng nhập 1. Tại Params/Query 1. Kết quả 1. Kết

Path nhập: quả trả về
books_ty postman trả về
Key: type Message
pe&limit Message "400 Bad
2.Chọn phương thức Value: romatic Request "
_404 Key: limit 400 Bad
GET với
Value: 3 {"error":
Request
3.Điền request URL: 3. Tại Test nhập: "Invalid
pm.test("Status code value for
is 400", function ( query
https://simple- parameter
) {
books- pm.response.to.h 'type'.Mu
ave.status(400); s
api.glitch.me/books? }); be one of
: fiction
type=romatic&limit , non-
=3 fiction."
}
4.3. Tạo collection tự động và biến môi trường cho giá trị kiểm thử dựa vào các
testcase đã thiết kế
- Collection name: Tạo một collection với name là "Đồ án tốt nghiệp"
- Add folder: Click chuột phải trên "Đồ án tốt nghiệp" để thêm các Folder như sau:

+ Folder thứ nhất " Test Book API";

+ Folder thứ hai " Test Order Book API";
+ Folder thứ ba " Register Token".
Hình 4.2. Tạo folder cho collection

- Thiết lập các giá trị kiểm thử theo testcase đã thiết kế.

Hình 4.3. Chi tiết kịch bản kiểm thử chức năng với công cụ kiểm thử Postman
- Tạo biến môi trường
• Từ Collection Đồ án tốt nghiệp chọn Variables và tạo 2 biến như sau:
• Đặt tên variable là urlBooks và accesToken. Trong đó urlBooks là biến
HTTP cho mỗi HTTP, accesToken là Token dùng để dịnh danh người dùng
sử dụng khi gọi các phương thức.
+ Lấy HTTP: https://simple-books-api.glitch.me rồi điền vào cột INITIAL
VALUE;
+ Lấy accesToken đã được đăng ký:
eea886e0edb5ecc438fffb493b5056dfeb66b2b2b2f6a518266701ba8a34d
040 rồi điền vào cột INITIAL VALUE.
Hình 4.4. Tạo biến môi trường cho collection

4.4. Kiểm thử và tổng hợp kết quả

4.4.1. Kiểm thử tự động Collection Runner
4.4.1.1. Viết testcript kiểm tra giá trị trả về
- Chọn Tests trong folder Test Book API, Test Order Book API, Register
Token.
- Viết testscript kiểm tra thời gian trả về cho cả folder
Hình 4.5. Testscipt kiểm tra response time

- Viết testscript kiểm tra các giá trị cho các request
+ Testcript kiểm tra status code

Hình 4.6. Testcript kiểm tra status code

+ Testcript kiểm tra giá trị trả về trong response
Hình 4.7. Testcript kiểm tra giá trị trả về trong response
4.4.1.2. Collection Runner

- Chọn Run collection trong collection Đồ án tốt nghiệp như hình dưới

Hình 4.8. Giao diện run collection
- Run và Results page sẽ hiển thị sau khi click run Test API. Lệ thuộc vào thời gian
chờ, sẽ thấy các testcase chạy. Mỗi testcase hoàn thành , sẽ thấy test status là Passed
hay Failed.
4.5. Báo cáo kết quả kiểm thử tự động



Hình 4.9. Báo cáo kết quả kiển thử tự động run collection
- Kết quả trả về 39 testcase passed và 5 testcase failed.
4.6. Đánh giá kết quả kiểm thử
Từ kết quả kiểm thử API nhận được sau nhiều lần chạy với nhiều testcase, nhận
được kết quả chi tiết cho API của trang web bán sách như sau: do hệ thống là máy chủ
miễn phí, nên API của hệ thống cũng bị ảnh hưởng khá nhiều.
Các trạng thái trả về của hệ thống khá đầy đủ theo các chức năng chính, tuy nhiên
thời gian trả về của các testcase sẽ phụ thuộc vào người dùng đặt thời gian chờ chạy
cho các testcase.

KẾT LUẬN
Kết luận:
Qua quá trình nghiên cứu, sử dụng công cụ Postman để kiểm thử API web bán sách, em
đã đạt được một số kết quả như sau:
- Nắm rõ khái niệm, các kỹ thuật, phương pháp, quy trình và các loại kiểm thử phần
mềm và API;
- Sử dụng thành thạo các chức năng cơ bản của công cụ Postman và các tiện ích hỗ
trợ kiểm thử API;
- Xây dựng báo cáo kiểm thử API, hiểu rõ các kết quả, phân tích dữ liệu nhận được
sau khi kiểm thử;
- Bên cạnh những kết quả đạt được, đề tài còn có những hạn chế như sau:
• Chưa sử dụng công cụ kiểm thử Postman một cách triệt để;
• Trong quá trình chạy phần mềm, chất lượng mạng còn kém và không ổn định
nên kết quả test chỉ mang tính tương đối.
Hướng phát triển:
Đề tài chủ yếu tập trung nghiên cứu ứng dụng kiểm thử API sử dụng công cụ Postman
để mô phỏng và tạo môi trường kiểm thử.
Hướng nghiên cứu, phát triển của đề tài là sử dụng nhiều công cụ khác nhau cùng thực
hiện trên các môi trường phần cứng và phần mềm khác nhau để có thể cho ra một kết quả
chính xác nhất đồng thời tìm ra ưu khuyết điểm của các công cụ khác so với Postman để
có một cái nhìn khách quan và rõ ràng hơn về các công cụ kiểm thử, để có nhận xét chính
xác, đúng đắn hơn về công cụ Postman.

TÀI LIỆU THAM KHẢO

[1] Phạm Ngọc Hùng, Trương Anh Hoàng và Đặng Văn Hưng, Giáo Trình Kiểm
Thử Phần Mềm, Đại Học Quốc Gia Hà Nội.
[2] Th.s Thạc Bình Cường, Bài giảng điện tử môn học Kiểm thử và đảm bảo chất
lượng phần mềm, bộ môn CNPM, Viện CNTT&TT, Đại học Bách Khoa Hà Nội,
[3] https://blog.postman.com/author/joyce/

Đồ án tốt nghiệp - Đắc Thị Trà My - 69DCHT20083-đã chuyển đổi

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Đồ án tốt nghiệp - Đắc Thị Trà My - 69DCHT20083-đã chuyển đổi

Uploaded by

Copyright:

Available Formats

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ GIAO THÔNG VẬN TẢI

KHOA CÔNG NGHỆ THÔNG TIN

Đắc Thị Trà My

NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ TRIỂN

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Hệ thống thông tin

KHOA CÔNG NGHỆ THÔNG TIN

Đắc Thị Trà My

NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ TRIỂN

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Cán bộ hướng dẫn: ThS. Vũ Thị Thu Hà

Đắc Thị Trà My i 69DCHT20083

LỜI CAM ĐOAN

Hà Nội, tháng 5 năm 2022

Sinh viên thực hiện

Đắc Thị Trà My

Đắc Thị Trà My ii 69DCHT20083

Đắc Thị Trà My iii 69DCHT20083

3.5. Collections trong POSTMAN ..........................................................................27

Đắc Thị Trà My iv 69DCHT20083

LỜI NÓI ĐẦU

Em xin chân thành cảm ơn!

Hà Nội, tháng 5 năm 2022

Sinh viên thực hiện

Đắc Thị Trà My

Đắc Thị Trà My v 69DCHT20083

BẢNG THUẬT NGỮ VIẾT TẮT

Đắc Thị Trà My vi 69DCHT20083

DANH MỤC HÌNH ẢNH

Đắc Thị Trà My vii 69DCHT20083

DANH MỤC BẢNG BIỂU

Đắc Thị Trà My viii 69DCHT20083

CHƯƠNG 1. TỔNG QUAN

1.3. Giới hạn và phạm vi của đề tài

Đắc Thị Trà My 1 69DCHT20083

Đắc Thị Trà My 2 69DCHT20083

Hình 2.1 Vòng đời của quá trình kiểm thử

Đắc Thị Trà My 3 69DCHT20083

2.1.2. Các kĩ thuật kiểm thử phần mềm

Đắc Thị Trà My 4 69DCHT20083

Hình 2.2 Kiểm thử hộp đen

+ Chức năng không chính xác hoặc thiếu;

Đắc Thị Trà My 5 69DCHT20083

Đắc Thị Trà My 6 69DCHT20083

Hình 2.3 Kiểm thử hộp trắng

Đắc Thị Trà My 7 69DCHT20083

Hình 2.4 Kiểm thử hộp xám

Đắc Thị Trà My 8 69DCHT20083

Đắc Thị Trà My 9 69DCHT20083

Đắc Thị Trà My 10 69DCHT20083

Hình 2.5 Mô hình thác nước

Đắc Thị Trà My 11 69DCHT20083

- Phân tích mô hình

+ Các dự án nhỏ , ngắn hạn;

+ Dễ sử dụng, dễ tiếp cận, dễ quản lý;

+ Ít linh hoạt, phạm vi điều chỉnh hạn chế;

+ Rất khó để đo lường sự phát triển trong từng giai đoạn;

Đắc Thị Trà My 12 69DCHT20083

+ Khó quay lại khi giai đoạn nào đó đã kết thúc.

2.1.4.2. Mô hình chữ V – V Shaped model

Hình 2.6 Mô hình chữ V

Đắc Thị Trà My 13 69DCHT20083

Hình 2.7 Mô hình xoắn ốc