Test API (Application Programming Interface) là quá trình kiểm tra và xác nhận tính đúng đắn, hoạt động và hiệu suất của một API. API là một bộ giao diện và tập hợp các quy tắc mà một ứng dụng, dịch vụ hoặc thư viện cung cấp để cho phép các ứng dụng khác tương tác và sử dụng chức năng của nó. Khi phát triển phần mềm hoặc ứng dụng, API thường được sử dụng để truyền thông tin và thực hiện các tác vụ. Ví dụ, API của một dịch vụ thanh toán có thể cho phép ứng dụng gửi yêu cầu thanh toán và nhận phản hồi tương ứng. Để đảm bảo API hoạt động chính xác và đáp ứng yêu cầu, việc kiểm tra API là cần thiết.
Trang 1KHOA 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
Trang 2
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Ụ
Trang 3(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)
Trang 4(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)
Trang 5TÓ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
Trang 6LỜ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
Trang 7MỤ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
Trang 83.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
Trang 9LỜ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
Trang 10BẢNG THUẬT NGỮ VIẾT TẮT
2 API Application Programming
một chức năng cụ thể sau khi có kết quả
một chức năng cụ thể trước khi gửi yêu cầu
Trang 11DANH 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
Trang 12DANH 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
Trang 13CHƯƠ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;
Trang 14- 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
Trang 15CHƯƠ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í
Trang 16phẩ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)
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
Trang 17Hì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
+ 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ị;
Trang 18+ 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
+ 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
Trang 19+ 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
Trang 20+ 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
ở 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:
dùng;
nhau;
Trang 21+ 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;
kiểm thử phần mềm và người thiết kế hoặc kỹ sư.
+ 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;
Trang 22- 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;
Trang 23- 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
Trang 24- 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
+ 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;
Trang 25+ 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
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:
Trang 26+ Đâ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;
Trang 27+ 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
Trang 28+ 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
+ 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:
Trang 29+ 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
Trang 30+ 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
Trang 312.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)
Trang 32Giai đ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 đó
đó 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
Trang 33Kiể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
Trang 342.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
được kiểm thử Lập trình viên có thể truy cập vào source
code
Tester không thể truy cập vào source code
Chỉ các chức năng đơn giản được kiểm
Trang 35CHƯƠ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ữ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