Kiểm thử phi chức năng website bán gạo

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ến trìnhhay 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ực hiện theocái mà chúng đã được

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN

-o0o -BÁO CÁO KIỂM CHỨNG PHẦN MỀM

Kiểm Thử Phi Chức Năng Website Bán Gạo LỚP: CNTT K14A

Giáo viên hướng dẫn: Ths Hà Thị Thanh

Thái nguyên, tháng năm 2019

CHƯƠNG I: TỔNG QUAN VỀ KIỂM THỬ PHẦN

hệ thống hay thành phần đó (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ

kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering 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ìm lỗi.(Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm)

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phầnmềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người

có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm

ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằmđảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau (TheoBách khoa toàn thư mở Wikipedia)

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ến trìnhhay 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ực hiện theocái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mongmuố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âydự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 haychưa?

1.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

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ạicá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 tra logic, lầntừng chi tiết mà không cần chạy chương trình

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

1.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

1.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ên trong củachương trình Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thựchiện theo các đặc tả của nó

Theo hướng tiếp cận này, dữ liệu kiểm tra đượ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ử mọi cặp – All-pairs testing

 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ềm theonhữ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 để đượccung 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 địnhtrong 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ên chỉ 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 đòi hỏ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ập trình viên đã khôngtì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óngtối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm trathự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ểmthử 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ử duy nhất, và/hoặc một số phần của chương trìnhkhô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ù”

1.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ểmthử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong củachươ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 trongchươ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 (applicationprogramming interface): là phương pháp kiểm thử của ứng dụng sử dụng cácAPI công khai và riêng tư

 Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêuchuẩn về bao phủ mã lệnh

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

 Các phương pháp 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ànthà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 đượckiể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

1.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ải thuật bêntrong 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ênngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sự khác biệt này đặcbiệ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 fdbao 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

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ích hợp, Kiểmthử hệ thống và Kiểm thử chấp nhận sản phẩm

Sơ đồ các cấp độ kiểm thử

1.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 tra 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íchkết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tươngđối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra 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ềuthời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mứ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ỏi Unit)

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ều nàythườ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ện nhánhphá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ột Unit 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ệcchọ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ước các cakiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu đầuvà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àynên được giữ lại để tái sử dụng

1.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 ứngdụ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ối cù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ấutrú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ữa Unit với cácthành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự đượckiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã đượckiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa.Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với cá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ệc tích hợp giữa các Unit

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit MộtUnit 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ích hợp trước đó

và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm thử giao tiếpcủa Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho

số lượng can kiểm thử giảm đi rất nhiều, và 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ấutrúc nhằm bảo đảm các thành phần bên trong của một chương trình chạyđúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại củachương trình chẳng hạn các câu lệnh và nhánh bên trong

 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 quantâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêucầ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

1.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ích hợ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ợp thànhcô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ềutrường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặcthù, đặ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ác liê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à System Test 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ếpgiữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phảithực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúnghoạ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ình thànhcùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặckiể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ích cá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ểm thử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ần cứng bênngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ Sau giai đoạnSystem 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ùngkiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (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óm phá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ấtgồm:

 Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thốngthỏ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àinguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian 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ốngvận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) StressTest 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ấtthường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm trathiế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ăngkhôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc

dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàngtrự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êucầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập

kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào

1.1.4.4 Kiểm thử chấp nhận sản phẩm – Acceptance Test

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thựchiệ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ách hàng và khách hàng chấpnhậ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ọi trườnghợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bảnchấ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ểmthử Beta – Beta Test Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi pháttriển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửachữa Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trongmôi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngượ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ìnhphá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ần mề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ểu sai yêu cầucũng như sự mong chờ của khách hàng Ví dụ đôi khi một phần mềm xuất sắc vượt quacá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àngkhi 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àiliệ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 đi kèm phảiđược cập nhật và kiểm thử chặt chẽ

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

Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:

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ọn củamột hệ thống hay thành phần để xác minh là những sự thay đổi không gây ra những hậuquả không mong muốn…” Trên thực tế, quan niệm này là chỉ ra rằng phần mềm mà đãqua được các kiểm tra trước đó vẫn có thể được kiểm tra lại Beizer định nghĩa đó là sựlặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềm không bị thay đổi, ngoạitrừ tới mức như yêu cầu Hiển nhiên là sự thỏa hiệ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ần thự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 đó.

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ủa kiểmthử Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách hoạt độngđúng đắn từ cách hoạt động sai lầm Kiểm thử viên có thể biết hoặc không biết các chitiế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 đó, hoặc là quan điểm hộp trắng, hoặc là quan điểm hộp đen có thể đượcthực hiện trong kiểm thử phần mềm

1.1.4.6 Các phương pháp kiểm thử con người

Hai phương pháp kiểm thử con người chủ yếu là Code Inspections vàWalkthroughs Hai phương pháp này bao gồm một nhóm người đọc và kiểm tra theo mãlệnh của chương trình Mục tiêu của chúng là để tìm ra lỗi mà không gỡ lỗi

Một Inspection hay Walkthrough là 1 sự cải tiến của phương pháp kiểm tra mà lậptrình viên đọc chương trình của họ trước khi kiểm thử nó Inspections và Walkthroughshiệu quả hơn là bởi vì những người khác sẽ kiểm thử chương trình tốt hơn chính tác giảcủa chương trình đó

Inspections/Walkthroughs và kiểm thử bằng máy tính bổ sung cho nhau Hiệu quảtìm lỗi sẽ kém đi nếu thiếu đi 1 trong 2 phương pháp Và đối với việc sửa đổi chương

trình cũng nên sử dụng các phương pháp kiểm thử này cũng như các kỹ thuật kiểm thửhồi quy.

CÔNG CỤ KIỂM THỬ HIỆU NĂNG JMETER

1.1 Kiểm thử phi chức năng

2.1.1 Khái niệm kiểm thử phi chức năng

Ki m th phi ch c năng là khía c nh r t quan tr ng c a vi c đ m b o ch tể ử ứ ạ ấ ọ ủ ệ ả ả ấ

lượng và gi ng nh Ki m th ch c năng, Ki m th phi ch c năng cũng đòi h i chi nố ư ể ử ứ ể ử ứ ỏ ế

lược và l p k ho ch Chúng ta có th bao g m thông tin chi ti t v Ki m th phiậ ế ạ ể ồ ế ề ể ử

ch c năng trong k ho ch ki m th ho c có th vi t ra m t chi n lứ ế ạ ể ử ặ ể ế ộ ế ược riêng bi t vàệlên k ho ch cho nó Trong c hai trế ạ ả ường h p, m c tiêu là đ có th bao quát đợ ụ ể ể ược

t t c các khía c nh phi ch c năng c a ph n m m.ấ ả ạ ứ ủ ầ ề

Nh ng khía c nh phi ch c năng là nh ng gì? Hay tôi nên nói nh ng tính năng mà ữ ạ ứ ữ ữkhông liên quan đ n các ch c năng c a ng d ng là gì? Vâng, chúng là đây:ế ứ ủ ứ ụ

 Ứng d ng làm vi c trong đi u ki n bình thụ ệ ề ệ ường nh th nào?ư ế

 Ứng d ng hành x nh th nào khi quá nhi u ngụ ử ư ế ề ười dùng đăng nh p đ ng ậ ồ

th i?ờ

 Ứng d ng có th ch u đụ ể ị ượ ả ớc t i l n không?

 Ứng d ng b o m t t i m c nào?ụ ả ậ ớ ứ

 Ứng d ng có th ph c h i t b t kì s c nào hay không?ụ ể ụ ồ ừ ấ ự ố

 Ứng d ng có th hành x đ ng nh t trong nhi u môi trụ ể ử ồ ấ ề ường hay OS khác nhau không?

 Đ a ng d ng lên h th ng khác nhau có d dàng không?ư ứ ụ ệ ố ễ

 Tài li u/Hệ ướng d n s d ng đẫ ử ụ ược cung c p kèm ng d ng có d hi u hay ấ ứ ụ ễ ểkhông?

Danh sách trên đây có th v n còn nhi u n a Nh ng v n đ đây là, các tính năng ể ẫ ề ữ ư ấ ề ởnày có góp ph n vào ch t lầ ấ ượng c a ng d ng hay không? Câu tr l i là CÓ Nh ng ủ ứ ụ ả ờ ữtính năng này quan tr ng không kém các ch c năng chính Hãy tọ ứ ưởng tượng ng ứ

 Xác nh n r ng h th ng đáp ng đậ ằ ệ ố ứ ược th i gian ph n h i mong đ i.ờ ả ồ ợ

 Đánh giá các thành ph n chính c a ng d ng đáp ng đầ ủ ứ ụ ứ ược th i gian ph n ờ ả

h i mong mu n.ồ ố

 Có th để ược th c hi n nh m t ph n c a Ki m th tích h p.ự ệ ư ộ ầ ủ ể ử ợ

 Có th để ược th c hi n nh m t ph n c a Ki m th h th ng.ự ệ ư ộ ầ ủ ể ử ệ ố

2.1.2.2 Ki m th t i l ể ử ả ượ ng: Đánh giá xem li u hi u su t c a h th ng ệ ệ ấ ủ ệ ố

có đ ượ c nh mong đ i trong đi u ki n bình th ư ợ ề ệ ườ ng và đi u ki n th ề ệ ử nghi m hay không Nh ng đi m m u ch t là: ệ ữ ể ấ ố

 Xác nh n r ng h th ng ho t đ ng nh thi t k khi ngậ ằ ệ ố ạ ộ ư ế ế ười dùng đ ng th i ồ ờtruy c p ng d ng và nh n đậ ứ ụ ậ ược th i gian ph n h i mong đ i.ờ ả ồ ợ

 Th nghi m này đử ệ ượ ặc l p đi l p l i v i nhi u ngặ ạ ớ ề ười dùng đ ghi l i th i gianể ạ ờ

ph n h i và thông lả ồ ượng

 T i th i đi m ki m th , c s d li u nên là th c ho c mô ph ng th c t ạ ờ ể ể ử ơ ở ữ ệ ự ặ ỏ ự ế

 Th nghi m này c n đử ệ ầ ược ti n hành trên m t máy ch chuyên d ng mô ế ộ ủ ụ

 Nhi u ngề ườ ử ụi s d ng th c hi n các giao d ch nh nhau trên cùng m t d ự ệ ị ư ộ ữ

2.1.2.4 Ki m th quy mô: ể ử Ướ ượ c l ng các hành vi c a các ph n ủ ầ

m m khi kh i l ề ố ượ ng l n d li u có liên quan Nh ng đi m m u ch t là: ớ ữ ệ ữ ể ấ ố

 Áp d ng m t lụ ộ ượng l n d li u và ki m tra gi i h n n i các ph n m m b ớ ữ ệ ể ớ ạ ơ ầ ề ị

l i.ỗ

 Kích thướ ơ ở ữ ệ ốc c s d li u t i đa đượ ạc t o ra và nhi u truy v n c a khách ề ấ ủhàng vào c s d li u ho c t o báo cáo l n h n.ơ ở ữ ệ ặ ạ ớ ơ

 Ví d : N u ng d ng đang x lý c s d li u đ t o ra m t báo cáo, m t bài ụ ế ứ ụ ử ơ ở ữ ệ ể ạ ộ ộ

ki m th quy mô sẽ thể ử ường là s d ng m t t p k t qu l n và ki m tra báo ử ụ ộ ậ ế ả ớ ểcáo được in m t cách chính xác hay không.ộ

2.1.2.5 Ki m th tính kh d ng: Xem xét tính d s d ng cho ể ử ả ụ ễ ử ụ

ng ườ i dùng Nh ng đi m m u ch t là: ữ ể ấ ố

 Đ u ra có chính xác và có ý nghĩa cũng nh gi ng v i d ki n c a công vi c ầ ư ố ớ ự ế ủ ệhay không?

 Các l i có đỗ ược ch n đoán chính xác hay không?ẩ

 GUI có chính xác và nh t quán v i tiêu chu n đ ra hay không?ấ ớ ẩ ề

 Ứng d ng có d s d ng hay không?ụ ễ ử ụ

2.1.2.6 Ki m th giao di n ng ể ử ệ ườ i dùng: Đánh giá GUI Nh ng đi m ữ ể

m u ch t là: ấ ố

 GUI nên cung c p s giúp đ và ch d n đ làm cho ph n m m d s d ng.ấ ự ỡ ỉ ẫ ể ầ ề ễ ử ụ

 Thi t k có nh t quán không?ế ế ấ

 D li u đữ ệ ược truy n d n chính xác t trang này sang trang khác không?ề ẫ ừ

 GUI không nên làm phi n ngề ười dùng ho c khó hi u.ặ ể

2.1.2.7 Ki m th tính t ể ử ươ ng thích: Đánh giá xem ng d ng có t ứ ụ ươ ng thích v i ph n c ng/ph n m m khác mà có c u hình t i thi u ho c t i ớ ầ ứ ầ ề ấ ố ể ặ ố

đa hay không Nh ng đi m m u ch t là: ữ ể ấ ố

 Th nghi m v i m i ph n c ng v i c u hình t i thi u và t i đa.ử ệ ớ ỗ ầ ứ ớ ấ ố ể ố

 Th nghi m v i các trình duy t khác nhau.ử ệ ớ ệ

 Các testcase gi ng v i quá trình th nghi m ch c năng.ố ớ ử ệ ứ

 Trong trường h p s lợ ố ượng ph n c ng và ph n m m quá nhi u, chúng ta có ầ ứ ầ ề ề

th s d ng kỹ thu t OATS đ xác đ nh các trể ử ụ ậ ể ị ường h p th nghi m có vùng ợ ử ệ

ph sóng t i đa.ủ ố

2.1.2.8 Ki m th ph c h i: Đánh giá xem ng d ng có t t m t ể ử ụ ồ ứ ụ ắ ộ cách chính xác trong tr ườ ng h p có s c và d li u có đ ợ ự ố ữ ệ ượ c ph c h i ụ ồ

m t cách thích h p sau b t kỳ s c ph n c ng hay ph n m m nào ộ ợ ấ ự ố ầ ứ ầ ề không Các th nghi m có th nhi u h n nh ng g i ý d ử ệ ể ề ơ ữ ợ ướ i đây:

 Ng t đi n máy khách trong khi ng d ng đang làm vi c.ắ ệ ở ứ ụ ệ

 Con tr và khóa trong c s d li u không h p l ỏ ơ ở ữ ệ ợ ệ

 Ti n trình C s d li u b h y b ho c ch m d t trế ơ ở ữ ệ ị ủ ỏ ặ ấ ứ ước khi hoàn thành

 Con tr , các trỏ ường và giá tr c a C s d li u b phá ho i th công và tr c ị ủ ơ ở ữ ệ ị ạ ủ ự

2.1.2.10 Ki m tra tài li u: Đánh giá các tài li u và h ể ệ ệ ướ ng d n s ẫ ử

d ng ụ

 Xác nh n r ng các tài li u đậ ằ ệ ược tuyên b có s n trong s n ph m.ố ẵ ả ẩ

 Xác nh n t t c nh ng gì hậ ấ ả ữ ướng d n s d ng, hẫ ử ụ ướng d n cài đ t, file ghi chú,ẫ ặthay đ i c p nh t và tr giúp tr c tuy n đ u s n sàng.ổ ậ ậ ợ ự ế ề ẵ

2.1.3 Kiểm thử hiệu năng

Dưới đây là một số thuật ngữ hay được sử dụng trong kiểm thử hiệu năng:

- Yêu cầu/mục đích hiệu năng (performance requirements/goals):

Là định lượng đưa ra tiêu chí cho rằng hiệu năng của hệ thống là tốt Yêu cầuhiệu năng của một ứng dụng được thể hiện trong thời gian phản hồi, số lượt truy cậptrong 1 giây (hits), số giao địch trong 1 giây, v.v…

- Tải công việc (workload):

Là tải người sử dụng hệ thống trong thời gian thực khi người sử dụng đang truycập hoặc trong khi kiểm thử hiệu năng

- Thời gian phản hồi (response time):

Là thời gian phục vụ hoặc xử lý để phản hồi lại yêu cầu Thời gian phản hồi đượctính từ khi trình duyệt web gửi yêu cầu tới máy chủ web cho tới khi trình duyện webnhận được những byte phản hồi đầu tiên từ máy chủ

- Thông lượng (throughput):

Là tổng dữ liệu (bytes) được chuyền từ máy chủ tới máy khách để phụ

- Concurrency:

Số giao dịch đồng thời được thực hiện, tính bằng số giao dịch đồng thời hệ thốngđáp ứng được Đơn vị là transaction, vd: 200 transactions đồng thời, 300 transactionsđồng thời

- CPU usage: Hiệu suất sử dụng CPU Đơn vị là %.

- RAM usage: Hiệu suất sử dụng RAM Đơn vị là %.

- Fail rate:

Tỉ lệ lỗi, tính bằng số giao dịch không thực hiện thành công trên tổng số giaodịch đã thực hiện Giá trị này dùng để làm điều kiện cần cho các mục tiêu trên Đơn vị

là %

2.1.4 Các hoạt động trong kiểm thử hiệu năng

Có 4 giai đoạn chính trong thực hiện kiểm thử hiệu năng, trong mỗi giai đoạn

có các hoạt động khác nhau và lần lượt thứ tự thực hiện là:

- Lên kế hoạch kiểm thử: Hiểu hệ thống, Hiểu yêu cầu hiệu năng, Mô hình người

sử dụng, Mô hình tải

- Tạo kịch bản: Phát triển kịch bản, Tạo dữ liệu kiểm thử

- Thực hiện và phân tích: Cài đặt môi trường, Thực hiện kiểm thử, Phân tích kếtquả

- Báo cáo kết quả

2.1.5 Kiểu kiểm thử hiệu năng

- Kiểm thử cơ sở (baseline test)

Kiểm thử cơ sở là kiểm thử được xây dựng đánh giá hiệu năng ứng dụng với tảimột người sử dụng Kịch bản kiểm thử có thể được tạo ra với thời gian nghĩ (thinktime) trong thực tế và những cài đặt khác giống sử dụng trong thời gian thực

- Kiểm thử chuẩn (benchmark test)

Kiểm thử chuẩn là kiểm thử được tiến hành để đo lường hiệu năng của ứng dụngtrong một điều kiện tải thấp Thông thường kiểm thử chuẩn chiếm 15-20% mức tảimục tiêu

- Kiểm thử tải (load test):

Kiểm thử tải được thực hiện xác định hiệu năng hệ thống với điều kiện tải nhiềungười sử dụng đồng hệ thống như trong thực tế Nó được xây dựng với mục đích tìm

ra hiệu năng hệ thống trong điều kiện tải mục tiêu

- Kiểm thử áp lực (stress test)

Kiểm thử áp lực là kiểm thử được tiến hành bằng cách kiểm thử hệ thống trongđiều kiện tải bất hợp lý để xác định điểm dừng (breakpoint) của hệ thống

- Kiểm thử Spike (spike test)

Kiểm thử này rất giống kiểm thử áp lực (stress test) nhưng hệ thống được đặttrong tải cực cao trong một thời gian gian ngắn Kiểm thử giúp xác nhận hiệu năng hệthống trong điều kiện tải cao đột ngột trong giờ giao dịch cao điểm của ứng dụng

- Kiểm thử chịu tải(endurance test)

Kiểm thử chịu đựng tập trung vào đánh giá hiệu năng của hệ thống với mức tải

sử dụng được định trước trong khoảng thời gian kéo dài Kiểm thử chịu đựng chạy với70%- 80% của tải mục tiêu, trong kịch bản có cài đặt thời gian nghĩ giống như trongthực tế

- Kiểm thử cô lập nghẽn cổ chai (bottleneck isolation test)

Kiểm thử cô lập nghẽn cổ chai là kiểm thử được thực hiện trên hệ thống hoặcmột thành phần cụ thể để tìm ra các vấn đề và nguyên nhân ảnh hưởng đến hiệu năngcủa hệ thống

- Volume test

Volume testlà kiểm thử hiệu năng cho hệ thống khi nó phải thao tác với mộtlượng dữ liệu nhất định Số lượng này có thể là kích thước bản ghi dữ liệu hoặc nócũng có thể là kích thước của 1 tập tin.

1.2 Công cụ kiểm thử hiệu năng website tự động Jmeter

1.2.1 Giới thiệu

Jmeter là công cụ để đo độ tải và performance của đối tượng, có thể sử dụng để test performance trên cả nguồn tĩnh và nguồn động, có thể kiểm tra độ tải và hiệu năng trên nhiều loại server khác nhau như: Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – SMTP(S), POP3(S) and IMAP(S)…

Jmeter là một mã nguồn mở được viết bằng java Cha đẻ của JMeter là Stefano Mazzocchi sau đó Apache đã thiết kế lại để cải tiến hơn giao diện đồ họa cho người dùng và khả năng kiểm thử hướng chức năng

Cách thức hoạt động: JMeter mô phỏng một nhóm người dùng gửi yêu cầu đến một máy chủ mục tiêu, và trả về số liệu thống kê cho thấy hiệu năng / chức năng của máy chủ / mục tiêu ứng dụng thông qua các bảng, đồ thị,…

1.2.2 Đặc trưng của Jmeter

- Nguồn mở, miễn phí

- Giao diện đơn giản, trực quan dễ sử dụng

Có thể kiểm thử nhiều kiểu server: Web HTTP, HTTPS, SOAP, Database JDBC, LDAP, JMS, Mail - POP3,…

Một công cụ độc lập có thể chạy trên nhiều nền tảng hệ điều hành khác nhau, trên Linux chỉ cần chạy bằng một shell scrip, trên Windows thì chỉ cần chạy một file bat

- Đa luồng, giúp xử lý tạo nhiều request cùng một khoảng thời gian, xử lý các

dữ liệu thu được một cách hiệu quả.

- Đặc tính mở rộng, có rất nhiều plugin được chia trẻ rộng rãi và miễn phí

- Một công cụ tự động để kiểm thử hiệu năng và tính năng của ứng dụng.

1.2.3 Các thành phần chính của Jmeter

1.2.3.1 Test Plan

Một Test Plan bao gồm các bước sẽ được Jmeter thực thi Nó xác định những

gì phải kiểm tra và làm thế nào với những vấn đề cần kiểm tra đó.

Bao gồm hai nút:

- Nút Test Plan - là nơi mà các kế hoạch thử nghiệm thực tế được lưu giữ.

- Nút Workbench - Nó chỉ đơn giản là cung cấp một nơi để lưu trữ tạm thời các yếu tố thử nghiệm trong khi không sử dụng, cho mục đích sao chép / dán.

Bước 2: Add/ Remove Elements

Elements có thể được thêm vào một kế hoạch kiểm thử bằng cách kích chuột phải vào nút Test Plan và chọn một elements mới từ “Add” danh sách.

Ngoài ra, ta cũng có thể tải một element từ một tập tin và thêm nó vào bằng cách chọn tùy chọn “merge” hay “open”.

Để loại bỏ một phần tử, đảm bảo các yếu tố được chọn, nhấn chuột phải vào element, và chọn “Remove”.

Bước 3: Load and Save the Elements

Để tải một phần tử từ tập tin:

- Nhấp chuột phải vào cây elements đang tồn tài mà ta muốn thêm vào các thánh phần được tải.

- Chọn Merge.

- Chọn các tập tin mà ta đã lưu các elements.

Jmeter sẽ hợp nhất cacselements này vào cây.

Theo mặc định, JMeter không lưu lại các yếu tố, bạn cần phải lưu lại nó.

Để lưu các thành phần của cây:

- Nhấp chuột phải vào phần tử.

- Chọn Save Selection As…

JMeter sẽ lưu các phần tử được chọn, cộng với tất cả các phần tử con bên dưới nó.

Bước 4: Cấu hình của Elements Tree

Bất kỳ yếu tố nào trong kế hoạch kiểm thử có thể được cấu hình bằng cách sử dụng các điều khiển hiện trong khung bên phải của JMeter Những điều khiển này cho phép bạn cấu hình các hành vi của các yếu tố kiểm tra cụ thể đó Ví dụ, Thread Group có thể được cấu hình cho một số người sử dụng, đoạn đường nối lên thời gian, vv, như hình 2.1.

Bước 5: Lưu các kế hoạch kiểm thử

Ta có thể lưu toàn bộ một kế hoạch kiểm thử bằng cách sử dụng một trong

hai lựa chọn Save hoặc "Test Plan Save As " từ menu File.

Bước 6: Chạy Test Plan

Ta có thể chạy các kế hoạch kiểm thử bằng cách nhấn vào Start(Control + r)

từ Run Khi JMeter bắt đầu chạy, nó cho thấy một hộp màu xanh lá cây nhỏ ở cuối

bên phải của phần ngay dưới thanh menu.

Những con số bên trái của hộp màu xanh lá cây là số lượng các chủ đề đang hoạt động / tổng số bài Những chỉ áp dụng cho một thử nghiệm chạy ở địa phương; họ không bao gồm bất kỳ thread bắt đầu trên hệ thống từ xa khi sử dụng chế độ client-server.

Bước 7: Dừng các Test Plan

- Sử dụng Stop (Control + '.') Nó dừng lại các chủ đề ngay lập tức nếu có

thể.

- Sử dụng Shutdown (Control + ',') Nó yêu cầu các chủ đề để dừng lại ở cuối

của bất kỳ công việc hiện tại.

1.2.3.2 Các thành phần của Test Plan

Thread Group: Đại diện cho người dùng ảo (virtual user), kiểm soát số lượng các thread Jmeter sẽ sử dụng trong quá trình thử nghiệm.

- Thiết lập số lượng các chủ đề

- Thiết lập các thời điểm khó khăn

- Thiết lập số lần lặp lại thử nghiệm

Các Thread Group Panel chứa các thành phần sau:

Hành động được thực hiện sau khi một lỗi Sampler - Trong mọi trường

hợp lỗi xảy ra trong quá trình thực hiện kiểm tra, ta có thể để thử nghiệm hoặc là –

- Tiếp tục đến phần tử tiếp theo trong các thử nghiệm

- Dừng Thread để ngăn chặn các chủ đề hiện tại.

- Dừng Test hoàn toàn, trong trường hợp ta muốn kiểm tra các lỗi trước khi

nó tiếp tục chạy.

Số chủ đề - Mô phỏng số lượng người dùng hoặc các kết nối đến máy chủ

ứng dụng của bạn.

Ramp-Up Thời gian Định nghĩa bao lâu nó sẽ mất JMeter để có được tất cả

các chủ đề hoạt động.

Vòng Đếm - Xác định số lần để thực hiện các bài kiểm tra.

Hộp kiểm Scheduler - Sau khi lựa chọn, phần Scheduler Configuration sẽ

xuất hiện ở dưới cùng của bảng điều khiển.

Scheduler Cấu hình – Ta có thể cấu hình bắt đầu và kết thúc thời gian chạy

thử nghiệm.

Controllers: gồm hai loại là Samplers và Logic Controllers.

Samplers: cho phép JMeter để gửi các yêu cầu cụ đến một máy chủ Chúng

mô phỏng một yêu cầu người sử dụng cho một trang từ các máy chủ mục tiêu Logic Controllers: cho phép kiểm soát thứ tự xử lý Sampler trong một Thread Logic Controllers có thể thay đổi thứ tự của một yêu cầu đến từ bất kì phần tự con nào của nó

Listeners: Cho phép xem kết quả sampler dưới dạng bảng biểu, đồ thị, cây, hoặc văn bản đơn giản trong một số tập tin log Nó cung cấp truy cập trực quan cho các dữ liệu được thu thập bởi Jmeter về các trường hợp kiểm thử như một thành phần Sampler của Jmeter được thực thi.

Listener có thể được thêm vào bất cứ nơi nào trong các kiểm thử, bao gồm cả trực tiếp theo kế hoạch kiểm tra Nó sẽ thu thập dữ liệu chỉ từ các yếu tố bằng hoặc thấp hơn mức của nó

Timers: Theo mặc định, một thread Jmeter gửi yêu cầu mà không cần tạm dừng giữa mỗi sampler Ta có thể thêm yếu tố đếm thời gian (Timer) cho phép xác đinh một khoảng thời gian chờ giữa mỗi yêu cầu.

Các yếu tố cấu hình:

- Các yếu tố cấu hình cho phép ta tạo ra các giá trị mặc định và các biến được

sử dụng bởi các Samplers Chúng được sử dụng để thêm hoặc sửa đổi các yêu cầu do lấy mẫu.

- Chúng được thực hiện vào đầu những phạm vi mà họ là một phần, trước khi lấy mẫu được đặt trong cùng một phạm vi Do đó, một cấu hình phần tử được truy cập chỉ từ bên trong các chi nhánh, nơi nó được đặt.

Các yếu tố xử lý trước và xử lý sau

- Một yếu tố tiền xử lý là cái gì mà chạy ngay trước khi một mẫu thực hiện Chúng thường được sử dụng để thay đổi các thiết lập của một yêu cầu mẫu ngay trước khi nó chạy, hoặc cập nhật các biến không được trích từ văn bản trả lời.

- Một yếu tố xử lý sau thực thi sau khi Sampler kết thúc việc thực hiện của

nó Yếu tố này thường được sử dụng để xử lý các dữ liệu phản hồi.

1.2.4 Hướng dẫn cài đặt

Bước 1:Tải Jmetter

Đường link: https://jmeter.apache.org/

Bước 2:Chạy file đã tải với quyền admin

Bước 3: Khởi động Jmeter