Báo cáo bài tập lớn kiểm thử phần mềm đề tài nghiên cứu và ứng dụng công cụ kiểm thử tự động serenity cumcuber

Nhưngkiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát triểnphần mềm nào.Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “Sinh viêncủa chúng ta tốt nghiệp v

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

Lê Quang Đạt – 2022600010 Trần Tiến Đạt - 2022600083 Trần Tăng Sỹ - 2022600034

LỜI MỞ ĐẦU

Đã có rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụng phát triển ngày càng linh động Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát triển phần mềm nào.

Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “Sinh viên của chúng ta tốt nghiệp và đi làm mà không có được những kiến thức thực tế cần thiết về cách để kiểm thử một chương trình Hơn nữa, chúng ta hiếm khi

có được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ”.

Việc kiểm thử phần mềm thật sự quan trọng trong “dây chuyền” sản xuất phần mềm Đây cũng chính là lý do để nhóm em nghiên cứu về đề tài

này, và chính xác hơn là đề tài “Trình bày và ứng dụng kỹ thuật kiểm thử giao

diện của ứng dụng web” mà chúng em sẽ trình bày dưới đây.

Nhóm 19 thực hiện!

LỜI CẢM ƠN

Để hoàn thiện được bài tập lớn, nhóm 19 chúng em xin được gửi lời cảm ơn chân thành nhất tới ThS Nguyễn Ngọc Quang đã giảng dạy tận tình

và đưa ra cho chúng em những lời nhận xét, góp ý thẳng thắn và bổ ích.

Được thầy giảng dạy học phần Kiểm thử phần mềm, chúng em không chỉ nắm chắc về các kỹ thuật kiểm thử mà còn học thêm được rất nhiều kiến thức bổ ích khác về lập trình web, môi trường doanh nghiệp, kĩ năng mềm…

Qua quá trình tìm hiểu và nhận được sự giúp đỡ nhiệt tình từ thầy, nhóm chúng em đã tiếp thu được rất nhiều điều, tư duy mới và những kiến thức mới hữu ích Những kiến thức đó sẽ được trình bày chi tiết trong báo cáo bài tập lớn này, rất mong nhận được các nhận xét và đóng góp từ tất cả mọi người!

Nhóm 19 thực hiện!

Bảng 4.1 Test Case cho UI Testing 33

Bảng 4.2 Test Case cho API Testing 34

DANH MỤC HÌNH ẢNH Hình 1.1 Các chiến lược kiểm thử 8

Hình 1.2 Các cấp độ kiểm thử 11

Hình 1.3 Các quy tắc kiểm thử 16

Hình 3.1 Một số thành phần của giao diện trang web 21

Hình 3.2 Một số công cụ kiểm thử tự động 22

Hình 3.3 Một trang web có thể có nhiều thành phần phức tạp 23

Hình 3.4 Sự khác nhau giữa API testing và Unit testing 26

Hình 4.5 Tạo Test Class 37

Hình 4.6 Tạo file feature để viết kịch bản 39

Hình 4.7 Tạo các Step Definitions 41

Hình 4.8 Kết quả kiểm thử tự động giao diện Website 43

Hình 4.9 Kết quả kiểm thử tự động API 46

Chương 1: MỞ ĐẦU 1.1 Đặt vấn đề

Trong những năm gần đây với sự phát triển rất mạnh của công nghệ thông tin, ngànhcông nghệ phần mềm đang chiếm một vị trí hết sức quan trọng trong xu hướng phát triểnkinh tế công nghiệp hóa, hiện đại hóa của nước ta Cùng với sự phát triển ấy các chươngtrình phần mềm ra đời ngày càng nhiều, đòi hỏi các nhà sản suất phần mềm phải có mộtphương pháp để nâng cao chất lượng sản phẩm cũng như tối ưu hiệu suất làm việc để có thểcạnh tranh Vì vậy kiểm thử phần mềm đang ngày càng đóng vai trò quan trọng trong ngànhcông nghiệp phát triển phần mềm không chỉ ở Việt Nam mà trên thế giới Kiểm thử phầnmềm là một khâu rất quan trọng trong quá trình phát triển phần mềm Kiểm thử phần mềm

để kiểm tra phần mềm có đúng với đặc tả và thiết kế hệ thống không, có đáp ứng yêu cầungười dùng không, có lỗi lập trình không, hoạt động có hiệu quả không…Như vậy, kiểm thửphần mềm là để đáp ứng yêu cầu người dùng, phát triển lỗi để từ đó nâng cao chất lượngphần mềm Vậy làm thế nào để có thể kiểm tra dự án phần mềm của ta chạy ổn định, đạtđược tính hiệu quả cao, nhưng lại tiết kiệm được thời gian cũng như kinh phí trong quá trìnhkiểm thử là một điều thiết yếu đối với các nhà kiểm thử

Với mong muốn có cái nhìn xác thực, rõ ràng hơn về quy trình kiểm thử phần mềm, đảmbảo chất lượng phần mềm và tiếp cận với các công cụ hỗ trợ kiểm thử, giải quyết phần nàovấn đề về tiết kiệm thời gian, kinh phí trong việc tìm kiếm lỗi, quản lý lỗi khi tiến hànhkiểm thử; đồng thời rèn kỹ năng làm việc, tạo tiền đề định hướng cho tương lai sau khi ratrường Được sự đồng ý của Th.S Nguyễn Ngọc Quang và Khoa CNTT chúng em chọn đề

tài “Sử dụng senerity-cumcuber để kiểm thử website”

1.2 Mục đích và yêu cầu

1.2.1 Mục đích

Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm, các công cụ hỗ trợ trong quá trình kiểmthử và ứng dụng để kiểm thử một số chức năng của website eop.edu.vn Mục tiêu cụ thểnhư sau:

 Nắm được tổng quan về quá trình kiểm thử phần mềm

 Hiểu được tầm quan trọng, mục đích, vai trò kiểm thử phần mềm

 Tìm hiểu về các cấp độ, các nguyên tắc, các phương pháp, kỹ thuật kiểm thử phầnmềm

 Biết cài đặt và sử dụng các công cụ trong quá trình kiểm thử

 Áp dụng tiến hành kiểm thử chức năng, hiệu năng trên website cụ thể

yêu cầu và cần tập trung vào tìm hiểu tài liệu liên quan đến vấn đề nghiên cứu:

 Hiểu được các kiến thức cơ bản về (khái niệm, quy trình, cấp độ, nguyên tắc…)trong kiểm thử và tận dụng theo đúng quy trình

 Hiểu biết các phương pháp kiểm thử, thiết kế các trường hợp kiểm thử cho một phầnmềm xác định

 Sử dụng công cụ Serenity-cucumber, ngôn ngữ Gherkin, và ứng dụng vào dự án thựctế

1.3 Tình hình nghiên cứu trong nước

Công nghệ thông tin Việt Nam nói chung và phát triển phần mềm nói riêng đang cónhững bước phát triển tốt và sinh động Tuy nhiên, có một thực tế là kiểm thử phần mềm ởViệt Nam đã đi sau nhiều nước khác Về mă ̣t số lượng thì Việt Nam thấp hơn rất nhiều sovới thế giới Tỷ lệ developer và tester trong dự án của thể giới là 3:1 còn ở Việt Nam lại là5:1

Trước đây, về mă ̣t chất lượng, ở Viê ̣t Nam chủ yếu là các dự án outsource (gia côngphần mềm), mà đa phần các dự án này chủ yếu tâ ̣p trung vào những công viê ̣c cấp thấp Dù

đã có nhiều công ty đảm nhâ ̣n những dự án lớn, giá trị cao nhưng số lượng đó còn rất ít, do

đó cần phải tăng tốc để bắt kịp trình độ của thế giới

Ở thời điểm hiện tại, nhiều công ty, doanh nghiệp trước kia phát triển mạnh về xâydựng phần mềm cũng đã phát triển mạnh về kiểm thử, có thể kể đến 1 số doanh nghiệp lớnnhư: IT Sol, Citigo, Fsoft, Viettel, Simax…

Về xu hướng kiểm thử phần mềm đang phát triển mạnh ở Việt Nam, nó vẫn là một bàitoán không chỉ với các công ty sản xuất phần mềm Nó vừa để kiểm soát lỗi trong quá trìnhlập trình cũng vừa là chứng minh cho khách hàng phần mềm đã thực hiện đúng các yêu cầu

họ dặt ra Là các xu hướng về kiểm thử trên nền web, kiểm thử app mobile, sử dụng cáccông cụ hỗ trợ đang được nhiều công ty, doanh nghiệp hướng đến và ưu tiên phát triển

1.4 Tình hình nghiên cứu ngoài nước

Testing ở thế giới đã phát triển từ lâu, nếu như ở Việt Nam tỉ lệ chỉ có 1 Tester thì có

5 lập trình viên nhưng ở nước ngoài tỉ lệ này là 4:1, như vậy với 4 Tester thì mới có một lậptrình viên Có thể nói Testing có rất nhiều tiềm năng phát triển

Nhật Bản là một quốc gia có nền Công nghệ thông rất phát triển Người Nhật vốn đã

tỉ mỉ nên họ muốn sản phẩm của họ làm ra phải đạt được chất lượng, cũng như quy trìnhlàm ra sản phẩm phải được quản lý chặt chẽ kể từ giai đoạn đầu của dự án Nên vớiQA/Tester người Nhật không chỉ có kiểm thử sản phẩm mà họ còn vừa phải đảm bảo quytrình của phần mềm, vừa phải tìm ra những lỗi của sản phẩm Vì vậy Test Matrix là mộtphần quan trọng và không thể thiếu trong các dự án của Nhật Bản

2.1 Các khái niệm cơ bản về kiểm thử phần mềm

2.1.1 Kiểm thử phần mềm là gì?

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dướinhững điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnhnào đó của hệ thống hay thành phần đó (Theo Bảng chú giải thuật ngữ chuẩn IEEEcủa Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of SoftwareEngineering Terminology)

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìmlỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm)

Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiếntrình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thựchiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gìkhông mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống,giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đápứng yêu cầu đặt ra hay chưa?

2.1.2 Các phương pháp kiểm thử

Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động

2.1.2.1 Kiểm thử tĩnh – Static testing

Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc

tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm thử logic, lần từng chi tiết màkhông cần chạy chương trình Kiểu kiểm thử này thường được sử dụng bởi chuyênviên thiết kế người mà viết mã lệnh một mình

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn

bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biêndịch mà xác nhận tính hợp lệ về cú pháp của chương trình

2.1.2.2 Kiểm thử động – Dynamic testing

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình đểđiều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên các ca kiểm thửxác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình Kiểmthử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng

động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động thực sự baogồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra cónhư mong muốn hay không.

Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểmthử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thửchấp nhận sản phẩm – Acceptance Tests

2.1.3 Các chiến lược kiểm thử

Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thửhộp đen, Kiểm thử hộp trắng, và Kiểm thử hộp xám

Hình 1.0.1 Các chiến lược kiểm thử

2.1.3.1 Kiểm thử hộp đen – Black box testing

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng

dữ liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình như là một “hộpđen” Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bêntrong của chương trình Thay vào đó, tập trung vào tìm các trường hợp mà chươngtrình không thực hiện theo các đặc tả của nó Theo hướng tiếp cận này, dữ liệu kiểmtra được lấy chỉ từ các đặc tả

Các phương pháp kiểm thử hộp đen:

• Phân lớp tương đương – Equivalence partitioning.

• Phân tích giá trị biên – Boundary value analysis.

• Kiểm thử fuzz – Fuzz testing.

• Kiểm thử dựa trên mô hình – Model-based testing.

• Ma trận dấu vết – Traceability matrix.

• Kiểm thử thăm dò – Exploratory testing.

• Kiểm thử dựa trên đặc tả – Specification-base testing.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềmtheo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy

dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thửtriệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữliệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trịmong muốn đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trênđặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viênchỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi Sử dụng nguyên tắc “ Hãy đòihỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lậptrình viên đã không tìm ra Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen

“giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên khôngbiết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó là lý do

mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử đểkiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duynhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”,mặt khác nó lại có nhược điểm của “thăm dò mù”

2.1.3.2 Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộpđen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúcbên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sựkiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu

và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng)

Các phương pháp kiểm thử hộp trắng:

• Kiểm thử giao diện lập trình ứng dụng - API testing (application programming interface): là phương pháp kiểm thử của ứng dụng sử

dụng các API công khai và riêng tư

• Bao phủ mã lệnh – Code coverage: tạo các ca kiểm thử để đáp ứng

một số tiêu chuẩn về bao phủ mã lệnh

• Các phương pháp gán lỗi – Fault injection.

• Kiểm thử hoán chuyển – Mutation testing methods.

• Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm

thử tĩnh

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sựhoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thửhộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống

ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đãđược kiểm tra

2.1.3.3 Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giảithuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ởmức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng

dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào vàđầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểmtra Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp –Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kếkhác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử

Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định,

ví dụ, giá trị biên hay thông báo lỗi

2.1.4 Các cấp độ kiểm thử phần mềm

Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tíchhợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm

Hình 1.0.2 Các cấp độ kiểm thử

2.1.4.1 Kiểm thử đơn vị – Unit test

Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thửđược Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức(Method) đều có thể được xem là Unit

Vì Unit được chọn để kiểm thử thường có kích thước nhỏ và chức năng hoạtđộng đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận

và phân tích kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân và khắcphục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểmtra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bùbằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở cácmức kiểm thử sau đó

Unit Test thường do lập trình viên thực hiện Công đoạn này cần được thực hiệncàng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code củachương trình Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏiUnit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit Điềunày thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiệnnhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong mộtUnit Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then

else là một nhánh Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử

và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa

Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trướccác ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định

rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các Test case

và Test script này nên được giữ lại để tái sử dụng

2.1.4.2 Kiểm thử tích hợp – Intergration Test

Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như mộtứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻthì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng

Hai mục tiêu chính của Integration Test:

• Phát hiện lỗi giao tiếp xảy ra giữa các Unit

• Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuốicùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ởmức hệ thống (System Test)

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng

và cấu trúc nội tại của Unit Có một số phép kiểm thử đơn giản trên giao tiếp giữaUnit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unitchỉ thật sự được kiểm thử đầy đủ khi các Unit tích hợp với nhau trong khi thực hiệnIntegration Test

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đãđược kiểm thử cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã đượcsửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test vớicác giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa Thực tế việctích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từngUnit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tíchhợp trước đó và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểmthử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điềunày sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, sai sót sẽ giảm đáng kể

Có 4 loại kiểm thử trong Integration Test:

• Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm

thử cấu trúc nhằm bảo đảm các thành phần bên trong của một chươngtrình chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc

• Kiểm thử chức năng (Functional Test): Tương tự Black Box Test,

kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, màkhông quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng củachương trình theo yêu cầu kỹ thuật

• Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của

hệ thống

• Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của

hệ thống

2.1.4.3 Kiểm thử hệ thống – System Test

Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tíchhợp) có thỏa mãn yêu cầu đặt ra hay không

System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợpthành công Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian.Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềmhoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố,hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi,nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khácliên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then chốt giữa Integration Test và System Test là SystemTest chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng

sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thôngthường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sựtương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test

Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hìnhthành cùng với các thành phần đã được kiểm thử đầy đủ Tại thời điểm này, lập trìnhviên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh.Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tíchcác yêu cầu

System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu

về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểmthử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phầncứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ Saugiai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc

người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùngthử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Testthường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhómphát triển dự án Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổbiến nhất gồm:

• Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ

thống thỏa mãn đúng yêu cầu thiết kế

• Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân

bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thờigian xử lý hay đáp ứng câu truy vấn

• Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ

thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùnglúc) Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết",các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuấthiện nhiều trong kiểm thử thiết bị như POS, ATM )

• Kiểm thử cấu hình (Configuration Test).

• Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật

của dữ liệu và của hệ thống

• Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có

khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tàinguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịchnhư ngân hàng trực tuyến

Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng:Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực Lưu ý làkhông nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên Tùy yêu cầu và đặctrưng của từng hệ thống, khả năng và thời gian cho phép của dự án, khi lập kếhoạch, quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào

2.1.4.4 Kiểm thử chấp nhận – Acceptance Test

Thông thường, sau giai đoạn System Test là Acceptance Test, được kháchhàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) Mục đích của

Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của kháchhàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọitrường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương

tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người

sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha –

Alpha Test và kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử

phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặcphản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi tới chongười dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửingược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quátrình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phầnmềm đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quan đến việc hiểusai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ đôi khi một phần mềm xuấtsắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án,nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn,thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ

và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v Tất cả tài liệu đikèm phải được cập nhật và kiểm thử chặt chẽ

2.1.4.5 Một số cấp độ kiểm thử khác

a Kiểm thử hồi quy – Regression Testing:

Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa chọncủa một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ranhững hậu quả không mong muốn…” Trên thực tế, quan niệm này là chỉ ra rằngphần mềm mà đã qua được các lần kiểm thử trước đó vẫn có thể được kiểm thử lại

Beizer định nghĩa đó là sự lặp lại các ca kiểm thử để chỉ ra rằng cách hoạt độngcủa phần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu Hiển nhiên là sự thỏahiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lầnthực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó

b Kiểm thử tính đúng – Correctness testing:

Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu củakiểm thử Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cáchhoạt động đúng đắn từ cách hoạt động sai lầm Kiểm thử viên có thể biết hoặckhông biết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụluồng điều khiển, luồng dữ liệu, v.v… Do đó, kỹ thuật hộp trắng hoặc là kỹ thuậthộp đen có thể được thực hiện trong kiểm thử phần mềm

Kiểm thử chỉ có thể chứng minh được rằng sản phẩm có lỗi Kiểm thử phầnmềm không thể chứng mình rằng sản phẩm không còn lỗi Nghĩa là sản phẩm luôn

có lỗi cho dù có kiểm thử nhiều bao nhiêu Do đó, điều quan trọng là chúng ta phảithiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗicàng tốt

Quy tắc 2: Kiểm thử toàn bộ là không thể

Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giátrị đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm khôngcòn bug cho dù có kiểm thử nhiều đến đâu là không khả thi Hầu hết các sản phẩmngày nay rất đa dạng và phức tạp do được phát triển trên nhiều nền tảng, công nghệphong phú cũng như khả năng lưu trữ kết nối dữ liệu lớn, khiến việc kiểm thử trởnên khó khăn và việc kiểm thử toàn bộ là gần như không thể Kiểm thử với tất cảcác kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉbao gồm ít trường hợp thì có thể kiểm thử toàn bộ Thay vì kiểm thử toàn bộ, việcphân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểmthử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn

Quy tắc 3: Kiểm thử càng sớm càng tốt

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầucủa vòng đời phát triển phần mềm Các hoạt động kiểm thử phần mềm từ giai đoạnđầu sẽ giúp phát hiện bug sớm hơn Nó cho phép chuyển giao phần mềm theo yêucầu đúng thời gian với chất lượng dự kiến Ngoài ra ai làm phần mềm cũng biếtđược rằng việc phát hiện lỗi càng trể bao nhiêu thì chi phí để sửa lỗi càng cao bấynhiêu Tương tự, việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phíthay đổi tính năng trong hệ thống

Quy tắc 4: Lỗi thường được phân bố tập trung

Thông thường, phần lớn lỗi tập trung vào những module, thành phần chứcnăng chính của hệ thống Điều này cũng thuận theo nguyên lý Pareto: 80% số lượnglỗi được tìm thấy trong 20% tính năng của hệ thống Nếu bạn thành công xác địnhđược điều này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định Nóđược coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả

Quy tắc 5: Nghịch lý thuốc trừ sâu

Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test casethì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này

Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúctrước đã được sửa trong khi những trường hợp kiểm thử đã cũ Do đó, khi một lỗiđược sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làmregression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này khôngảnh hưởng đến những vùng khác của sản phẩm.

Quy tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh

Theo nguyên tắc này thì nếu bạn đang kiểm thử ứng dụng web và ứng dụng

di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì điều đó là sai lầm.Chiến lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó Chiếnlược cho test web application phải khác với ứng dụng android mobile

Quy tắc 7: Quan niệm sai lầm về việc “hết lỗi”

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm

đã sẵn sàng để tung ra thị trường Việc không tìm thấy lỗi cũng có thể là do bộtrường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúngtheo yêu cầu thay vì nhằm tìm kiếm lỗi mới

Chương 3: KIỂM THỬ GIAO DIỆN, API WEBSITE

VÀ KIỂM THỬ TỰ ĐỘNG 3.1 Kiểm thử giao diện website

3.1.1 Kiểm thử giao diện website là gì?

Kiểm thử giao diện người dùng, còn được gọi là Kiểm thử GUI, về cơ bản làmột cơ chế nhằm kiểm tra các khía cạnh của bất kỳ phần mềm nào mà người dùng

sẽ tiếp xúc Điều này thường có nghĩa là kiểm tra các yếu tố trực quan để xác minhrằng chúng đang hoạt động theo yêu cầu – về mặt chức năng và hiệu suất Thửnghiệm giao diện đảm bảo rằng các chức năng giao diện người dùng không có lỗi

Trang web bao gồm các phần tử web được tạo bằng HTML, CSS, JavaScript vànhiều ngôn ngữ lập trình khác Thử nghiệm giao diện người dùng thực hiện các thửnghiệm và xác nhận các yếu tố này để xác thực tính hiệu quả của chúng Nó tập trungvào việc kiểm tra các phần trực quan của phần mềm, tức là các thành phần mà ngườidùng có thể thấy, có thể tương tác được, hơn là logic bên trong của phần mềm

3.1.2 Phạm vi kiểm thử

Kiểm thử giao diện người dùng chủ yếu liên quan đến hai yếu tố: xác minhxem ứng dụng có xử lý các hành động của người dùng như mong đợi hay không vàkiểm tra xem các thành phần giao diện người dùng của ứng dụng có hoạt động vàtrông như dự kiến hay không Tuy nhiên, nó thường trở nên khó phân biệt giữanhững gì nên và không nên trong phạm vi kiểm thử giao diện người dùng

Ví dụ: kiểm thử giao diện người dùng có nên cố gắng bao phủ mọi nhánh cóthể có trong ứng dụng không? Câu trả lời là không Chỉ riêng việc đạt được mức độbao phủ mã như vậy thông qua thử nghiệm giao diện người dùng sẽ dẫn đến một bộcác ca kiểm thử được tiến hành chậm, tốn kém và phức tạp Trong trường hợp nàykiểm thử đơn vị sẽ được sử dụng

Một vấn đề khác: chúng ta có nên sử dụng thử nghiệm giao diện người dùng đểkiểm thử tương thích giữa ứng dụng và các phần phụ thuộc bên ngoài, chẳng hạn như

cơ sở dữ liệu hoặc API không? Mặc dù trên thực tế ta có thể, nhưng lại không nên vìnhư vậy sẽ làm mờ ranh giới giữa kiểm thử giao diện người dùng và kiểm thử đầu cuối(end-to-end) Việc thực hiện kiểm thử giao diện người dùng đối với những bộ dữ liệumẫu của các yếu tố phụ thuộc đó sẽ đảm bảo các ca kiểm thử mang tính quyết định hơn

Khi thực hiện kiểm thử giao diện người dùng, bạn thường rất dễ đi chệchkhỏi làn đường của mình và dẫm lên chân các hình thức kiểm tra khác Tránh điều

đó Theo nguyên tắc chung, hãy nhớ rằng kiểm thử giao diện người dùng nên quantâm đến giao diện và hành vi của giao diện người dùng Cách các yếu tố hình ảnhđược trình bày, cách chúng tương tác, phản hồi đầu vào của người dùng và xác thực

dữ liệu đầu vào Đó phải là phạm vi kiểm tra giao diện người dùng

Dưới đây là một số thành phần thiết yếu của một trang web mà kiểm thử giaodiện người dùng có xu hướng xác minh:

- Kích thước màn hình: kiểm tra xem phần mềm, trang web có hiển thị

đúng trên các kích thước màn hình được hỗ trợ hay không

- Lỗi loại dữ liệu: kiểm tra xem chỉ có thể nhập dữ liệu hợp lệ cho một số

trường dữ liệu nhất định như ngày tháng, tiền tệ, v.v

- Giới hạn kí tự: kiểm tra xem các trường văn bản nhất định không cho

phép người dùng nhập vào quá giới hạn ký tự cụ thể

- Các nút điều hướng: kiểm tra xem tất cả các nút điều hướng trên một

trang có đang hoạt động không và chúng có chuyển hướng người dùngđến đúng trang không

- Thanh tiến trình: kiểm tra xem khi hiển thị các trang hoặc màn hình cần

thời gian để tải hoàn toàn, một thanh tiến trình sẽ xuất hiện giúp chongười dùng biết rằng trang đang được tải

- Placeholder text: Nếu giao diện người dùng sử dụng danh sách thả

xuống, thì cần thiết phải có dữ liệu tạm được chọn Trong menu thảxuống có nhiều tùy chọn, người dùng có thể tìm đúng tùy chọn bằng cáchnhập chữ cái đầu tiên Bắt người dùng xem qua một danh sách dài tạo nêntrải nghiệm người dùng không thuận lợi

- Cuộn trong bảng dữ liệu: Nếu trang web có bảng dữ liệu và nếu bảng

mở rộng sang trang thứ hai, thì người dùng sẽ có thể cuộn qua tất cả dữliệu trong khi vẫn giữ các tiêu đề hiển thị và ở đúng vị trí

- Các mục trong menu: kiểm tra xem phần mềm chỉ hiển thị menu có sẵn

ở vị trí cụ thể

Hình 3.0.4 Một số thành phần của giao diện trang web

3.1.3 Phương pháp kiểm thử

Kiểm thử giao diện người dùng có thể được tiến hành thủ công hoặc tự độnghóa Người thử nghiệm có thể đưa ra lựa chọn giữa một trong hai kỹ thuật hoặc dùng cảhai, tùy thuộc vào bản chất của ứng dụng cũng như bản thân nhóm phát triển

Kiểm thử thủ công: Trong trường hợp này, người kiểm thử sử dụng thủ

công tất cả các tính năng của trang web hoặc ứng dụng để kiểm tra mọi điểm khácbiệt Điều này hợp lý khi phần mềm có một số thành phần giao diện người dùng hạnchế, thường xảy ra trong các phiên bản đầu tiên của trang web hoặc ứng dụng Tuynhiên, với cơ sở người dùng am hiểu công nghệ của thời đại chúng ta, hầu hết mongđợi phần mềm có giao diện người dùng nhiều lớp, phong phú với hàng trăm, có lẽhàng nghìn thành phần giao diện người dùng yêu cầu xác minh

Điều này làm cho việc kiểm thử thủ công không hiệu quả, tốn thời gian và dễxảy ra lỗi do con người Ví dụ: hãy tưởng tượng số lần người dùng phải nhập thôngtin theo cách thủ công vào một trang có hơn 10 trường nhập liệu, nếu trang đó phảiđược kiểm tra với nhiều bộ giá trị

Kiểm thử tự động: Những lợi thế của kiểm thử tự động khá rõ ràng: Các bài

dùng mong đợi phần mềm hàng đầu với tốc độ cực nhanh Thử nghiệm Selenium tựđộng cho phép phần mềm được đưa vào nhiều tình huống thử nghiệm và để các thửnghiệm tương tự được chạy lặp lại (với các biến khác nhau, nếu cần) một cáchnhanh chóng và chính xác.

Ngoài ra, các bài kiểm thử tự động không dễ bị lỗi và cần ít nhân lực hơn.Miễn là kịch bản kiểm thử được viết chính xác và sử dụng đúng công cụ, kết quảđem lại sẽ rất đáng mong đợi

3.1.4 Các thách thức khi kiểm thử giao diện website

3.1.4.1 Cần chọn công cụ kiểm thử phù hợp

Hình 3.0.5 Một số công cụ kiểm thử tự động

Thông thường, kiểm thử tự động sẽ cần đến các phần mềm, ứng dụng đặc thù

hỗ trợ Nếu không có công cụ kiểm tra giao diện người dùng tự động phù hợp, tester

sẽ phải kiểm thử giao diện người dùng theo cách thủ công, điều này sẽ tốn nhiềuthời gian và công sức Chưa kể, kiểm thử thủ công dễ xảy ra lỗi do con người hơnkiểm thử tự động Tuy nhiên, việc chọn một công cụ phù hợp với quy trình làm việchiện có của nhóm thử nghiệm là điều cần thiết Nó cũng phải có khả năng ghi/phátlại, hỗ trợ các bài kiểm tra có thể tái sử dụng và yêu cầu bảo trì tối thiểu Công cụkiểm thử cũng cần có các cơ chế tích hợp để báo cáo và theo dõi lỗi Với số lượngkhổng lồ các khung tự động hóa trên thị trường, ta có thể hiểu tại sao việc đưa ra lựachọn sẽ là một thách thức

3.1.4.2 Sự phức tạp của các thành phần web

Việc biểu diễn trực quan của dữ liệu, quy trình, số liệu thống kê,… giúp ta dễhiểu hơn nhiều Không có gì ngạc nhiên khi khách hàng mong đợi các quy trìnhnhanh chóng và giao diện hấp dẫn trực quan Dữ liệu có bản chất động và đôi khi cóthể mất thời gian để xử lý và trình bày Tạo biểu đồ, sơ đồ, biểu diễn đồ họa,… vànhiều yếu tố phức tạp khác giúp trải nghiệm người dùng tốt hơn nhiều, nhưng cũng

Hình 3.0.6 Một trang web có thể có nhiều thành phần phức tạp

Hầu hết các trang web hiện nay đều có các chức năng yêu cầu một số thànhphần web phức tạp và đặc thù để có thể hoạt động, ví dụ như biểu đồ tương tácđược, các bảng dữ liệu nhiều thành phần,… Nếu việc kiểm tra các yếu tố phức tạpnhư vậy không được thực hiện đúng cách, thì mục đích tạo ra chúng để nâng caotrải nghiệm người dùng cuối sẽ là vô nghĩa

3.1.4.3 Vấn đề xử lý lỗi

Vì kiểm thử giao diện người dùng gần như luôn là một quy trình mở rộng nênviệc tạo các tập lệnh kiểm thử (test script) để kiểm thử giao diện người dùng tự động sẽtốn rất nhiều thời gian Do đó, khi lỗi xuất hiện, việc xử lý chúng trở nên khó khăn

Dưới đây là danh sách các lỗi giao diện phổ biến nhất trong các ứng dụng web:

• Lỗi về khả năng tương thích chéo giữa các trình duyệt (Cross Browser

Adaptability Bugs)

• Lỗi xác thực biểu mẫu (Form Validation Bugs)

• Lỗi về khả năng sử dụng (Usability Bugs)

• Sự không nhất quán trong Bố cục trang trên các thiết bị

• Các yếu tố giao diện người dùng bị lỗi dẫn đến hành vi không mong đợi

3.1.4.4 Giao diện web thay đổi liên tục theo thời gian

Các trang web hiện đại phải được nâng cấp liên tục để thích ứng với nhu cầu

và sở thích không ngừng phát triển của người dùng Thông thường, những nâng cấpnày liên quan đến việc tích hợp với các công cụ của bên thứ ba hoặc các phiên bảnmới hơn của chúng Đương nhiên, điều này dẫn đến một tập hợp các chức năng mớiphải được thử nghiệm Lặp lại quy trình này với mỗi lần nâng cấp và người ta sẽnhận ra thách thức nằm ở đâu Lúc này, kiểm thử hồi quy được áp dụng, nhóm kiểmthử phải trải qua một chu trình lặp đi lặp lại

Kiểm thử hồi quy được sử dụng để xác minh rằng mọi thay đổi hệ thốngkhông ảnh hưởng đến các tính năng và/hoặc cấu trúc mã hiện có Kiểm thử hồi quy

là một phần của hầu hết mọi quy trình kiểm thử trong phát triển phần mềm Nguyên

do là các nhà phát triển thường thay đổi hoặc thêm một đoạn mã và vô tình làm giánđoạn thứ gì đó đang hoạt động tốt trước đây

3.1.4.5 Chi phí kiểm thử

Cùng với việc giao diện của các trang web liên tục thay đổi, phát triển và nângcấp các công cụ kiểm thử (nhất là các công cụ tự động hóa) phải được cập nhật tươngứng để theo kịp Thử nghiệm nâng cấp hầu như luôn liên quan đến việc đầu tư nhiềuthời gian và tiền bạc hơn, do đó khó đưa ra ước tính chi phí chắc chắn Đương nhiên,điều này gây rắc rối khi lập kế hoạch tài chính cho quá trình thử nghiệm

3.2 Kiểm thử API

 Một request thường sử dụng 4 phương thức chính đó là:

GET để truy vấn object

POST để tạo object mới

PUT để sửa đổi hoặc thay thế một object

DELETE để loại bỏ một object

 Mỗi phương thức trên phải được API call thông qua để gửi chỉ thị cho server phải làm gì

3.2.2 Vì sao 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 nhaunên có nhiều chỗ client chưa làm xong, mình không thể chờ client làm xong để testđược dữ liệu mà test API bằng công cụ khác luôn –> Lúc này việc test hoàn toànkhông phụ thuộc gì vào client

Kể cả khi client làm xong rồi, nếu mình test trên client mà thấy lỗi liên quanđến logic và dữ liệu thì cũng cần test thêm cả API để biết chính xác là server sai hayclient sai –> fix lỗi sẽ nhanh hơn

Khi làm hệ thống web services, dự án của mình chỉ viết API cho bên khácdùng, mình sẽ không có client để test giống như các dự án khác –> phải test APIhoàn toàn

3.2.3 Test case trong API testing

 Giá trị được trả về dựa trên điều kiện đầu vào: tương đối đơn giản khi kiểm tra, vìđầu vào có thể được xác định và kết quả có thể đã được xác thực

 Không trả về bất cứ kết quả gì: Khi không có giá trị nào được trả về, một hành vịAPI trên hệ thống sẽ được tiến hành kiểm tra

 Kích hoạt một số API/Interrupt/API: Nếu đầu ra của API được kích hoạt một sốevent hoặc gián đoạn, thì listener của interrupt hoặc event sẽ được theo dõi

 Cập nhật cấu trúc dữ liệu: Cập nhật cấu trúc dữ liệu sẽ trả về một số kết quả hoặcảnh hưởng đến hệ thống và cần được xác thực

 Sửa đổi một số tài nguyên: Nếu lệnh gọi API có sửa đổi một số tài nguyên thì nóphải được xác thực bằng các truy cập các tài nguyên tương ứng

3.2.4 Sự khác nhau giữa API testing và Unit testing

Hình 3.0.7 Sự khác nhau giữa API testing và Unit testing

3.2.5 Những điều cần kiểm tra trong test API

 Discovery testing: Kiểm tra các API khi truy cập các tài nguyên và xem các APItruy 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: Đội kiểm thử 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

3.2.6 Những điều nên làm khi kiểm thử API

 Test case nên được nhóm theo loại kiểm thử

 Trên mỗi test case, nên bao gồm cả phần khai báo các API được gọi

 Các tham số lựa chọn nên được liệt kê dầy đủ trong các test case

 Nên đặt độ ưu tiên cho các API được gọi để dễ dàng test hơn

 Mỗi test các nên được khép kín, độc lập và tránh ít phục thuộc

 Nên tránh kiểm tra xâu chuỗi (test chaining) trong quá trình phát triển

 Đặc biệt chú ý khi thực hiện xử lý các chức năng gọi một lần như xóa, đóng cửasổ

 Gọi trình tự nên được thực hiện và lập kế hoạch tốt

 Để đảm bảo hoàn thành các kiểm thử, tạo test case cho tất cả các tổ hợp đàu vào có