Bài tập lớn môn kiểm chứng phần mềm Đề tài kiểm thử hộp trắng áp dụng nunit

Các mức kiểm thử test levels Các mức kiểm thử là tập hợp các hoạt động test được thực hiện ở một giaiđoạn phát triển cụ thể của sản phẩm, ví dụ từ lúc vài chức năng nhỏ được lập trình,ch

Giảng viên hướng dẫn Thạc sỹ: Vũ Thị Thương

Nhóm sinh viên thực hiện:

MỤC LỤC

CHƯƠNG 1: TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM 4

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

1.1.1 Khái niệm 4

1.1.2 Mục tiêu 4

1.2 Các mức kiểm thử (test levels) 5

1.2.1 Kiểm thử (mức) đơn vị (unit testing) 5

1.2.2 Kiểm thử tích hợp (integration testing) 6

1.2.3 Kiểm thử hệ thống (system testing) 9

1.2.4 Kiểm thử chấp nhận (acceptance testing) 9

1.3 Các loại kiểm thử (test types) 10

1.3.1 Kiểm thử chức năng (functional testing) 10

1.3.2 Kiểm thử phi chức năng (non-functional testing) 10

1.3.3 Kiểm thử bảo trì (maintenance testing) 11

1.4 Quy trình kiểm thử phần mềm 12

1.4.1 Lập kế hoạch và kiểm soát 12

1.4.2 Phân tích và thiết kế 12

1.4.3 Thực hiện kiểm thử 13

1.4.4 Đánh giá tiêu chí hoàn thành và báo cáo 13

1.4.5 Hoàn tất kiểm thử 13

CHƯƠNG 2: KIỂM THỬ HỘP TRẮNG (WHITEBOX TESTING) 15

2.1 Kiểm thử hộp trắng là gì? 15

2.2 Các loại kiểm thử hộp trắng 16

2.2.1 Kiểm thử đơn vị (Unit Testing) 16

2.2.2 Kiểm tra rò rỉ bộ nhớ (Testing for Memory Leaks) 17

2.3 Ưu & nhược điểm kiểm thử hộp trắng 17

2.3.1 Ưu điểm của White box testing 17

2.3.2 Nhược điểm của White box testing 18

2.4 Các Phương Pháp Kiểm Thử Hộp Trắng 18

2.4.1 Kiểm thử đường cơ bản – Đồ thị dòng 18

2.4.2 Kiểm thử dựa trên luồng điều khiển 20

2.5 Những Kỹ Thuật Kiểm Thử Hộp Trắng 21

2.6 Các bước thực hiện kiểm thử hộp trắng 22

2.7 Khác Nhau Giữa Kiểm Thử Hộp Trắng Và Hộp Đen 23

CHƯƠNG 3: CÀI ĐẶT VÀ SỬ DỤNG NUNIT TRONG KIỂM THỬ 25

3.1 NUnit là gì? 25

3.1.1 Khái niệm 25

3.1.2 Thực thi các phương thức kiểm thử với NUnit 25

3.2 Các từ khóa cơ bản sử dụng trong khi viết kiểm thử tự động với NUnit .28

3.3 Kiểm thử tự động với NUnit theo hướng Data-Driven 29

3.3.1 Thiết lập dữ liệu 29

3.3.2 Thiết lập hướng sử dụng dữ liệu 30

3.4 Thực hành sử dụng NUnit trong kiểm thử 31

CHƯƠNG 1: TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM1.1 Kiểm thử phần mềm là gì?

1.1.1 Khái niệm

Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và pháthiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và đầy đủ theoyêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra Software testing cũngcung cấp mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá vàhiểu rõ các rủi ro khi thực thi phần mềm

Các phương pháp kiểm thử phần mềm:

 Kiểm thử hộp trắng (white box testing): Trong kiểm thử hộp trắng cấu trúc

mã, thuật toán được đưa vào xem xét Người kiểm thử truy cập vào mãnguồn của chương trình để có thể kiểm tra nó

 Kiểm thử hộp đen (black box testing) : Kiểm tra các chức năng của hệ thốngdựa trên bản đặc tả yêu cầu

 Kiểm thử hộp xám (gray box testing): Là sự kết hợp giữa black box testing

và white box testing

1.1.2 Mục tiêu

Tuỳ vào quy mô của dự án hay loại hình của công ty và giai đoạn phát triểnphần mềm mà mục tiêu kiểm thử sẽ khác nhau, tuy nhiên đây là một số mục tiêukiểm thử thường gặp (danh sách này không mang tính thứ tự và không phải là giớihạn):

 Kiểm tra xem phần mềm (sản phẩm) đã đáp ứng tất cả yêu cầu đã mô

tả chưa hoặc xác nhận xem phần mềm đã hoàn thiện và hoạt độngđúng như mong đợi của người dùng và các bên liên quan khác chưa

 Kiểm thử để ngăn ngừa lỗi bằng cách review tài liệu mô tả yêu cầuhay thiết kế hệ thống, bao gồm mã nguồn (source code) để phát hiệnlỗi sớm

 Kiểm thử nhằm nâng cao chất lượng phần mềm, tăng sự tin tưởng củakhách hàng đối với phần mềm thông qua việc phát hiện lỗi và sửa lỗi(và dĩ nhiên là phải kiểm thử lại sau khi được sửa)

 Cung cấp thông tin cho các bên liên quan (bao gồm quản lý dự án haykhách hàng tùy dự án) để họ có thể đưa ra quyết định về việc pháthành (release) một phần mềm nào đó hay không

 Giảm thiểu rủi ro do lỗi của phần mềm gây ra trong quá trình sử dụngthực tế

 Ngoài ra còn nhiều mục tiêu khác như kiểm thử để đánh giá xem hệthống có đáp ứng các tiêu chuẩn của các tổ chức quốc tế như ISO,CMMI hay quy định của khu vực như GDPR (General DataProtection Regulation)

1.2 Các mức kiểm thử (test levels)

Các mức kiểm thử là tập hợp các hoạt động test được thực hiện ở một giaiđoạn phát triển cụ thể của sản phẩm, ví dụ từ lúc vài chức năng nhỏ được lập trình,cho đến lúc sản phẩm hoàn thiện, và có thể tích hợp với các hệ thống khác Dướiđây là một số mức kiểm thử cơ bản:

1.2.1 Kiểm thử (mức) đơn vị (unit testing)

Đây là mức kiểm thử thấp nhất Ở mức kiểm thử này, các thành phần nhỏnhất của một hệ thống phần mềm như class, function, hay module sẽ được kiểmthử riêng lẻ Phần lớn test case (các trường hợp kiểm thử) ở mức này sẽ gọi trựctiếp đối tượng được kiểm thử (như class, function… nào đó) trong code (mãnguồn) nên cần phải có sự hỗ trợ của các thư viện (unit test framework phổ biếnnhư XUnit, JUnit, Nunit, Jest,… đa phần ngôn ngữ lập trình nào cũng có nhiều thưviện hỗ trợ cho unit testing) để giả lập các cụm chức năng (class, function,…) liênquan nhằm tách riêng phần cần kiểm thử

Khi phát hiện lỗi ở mức kiểm thử này thường sẽ giúp tiết kiệm thời gian vàchi phí nhiều vì nếu không được phát hiện lỗi này sớm, có thể nó sẽ gây ra các lỗitích hợp, hoặc gây ra sự cố khi đưa vào sử dụng thực tế Lúc này chúng ta phải đisửa lỗi ở 1 đơn vị code nào đó, và phải test lại (confirmation testing) để xem lỗinày đã được sửa đúng hay chưa, ngoài ra còn phải kiểm thử các khu vực khác đểbảo đảm quá trình sửa lỗi không gây ra lỗi mới khác (regression testing)

Ví dụ, như hình bên dưới, để kiểm thử đơn vị code màu vàng, chúng ta phảigiả lập các đơn vị có liên quan trực tiếp đến nó (màu xanh tím)

bổ sung, giúp xác định kết quả mong đợi cho các test case đó.

Trong ví dụ trong hình dưới, chương trình kiểm tra số nguyên tố đơn giản,không cần phải giả lập gì Và 2 test case cơ bản để kiểm tra 1 số là số nguyên tố và

1 số không phải là số nguyên tố

Hình 1.2.2: Test case cơ bản kiểm tra số nguyên tố

1.2.2 Kiểm thử tích hợp (integration testing)

Ở giai đoạn này, các chức năng (hoặc class, function,…) đã được phát triển

và kiểm thử xong, đã đến lúc tích hợp chúng lại với nhau Và phải kiểm thử sựtương tác qua lại giữa các thành phần này Tương tự như vậy, chúng ta cũng cần

Thường thì lập trình viên (dev) sẽ phụ trách thực hiện mức kiểm thử tíchhợp này, hay gọi chung là integration testing.

Ví dụ kiểm thử tích hợp các thành phần trong một hệ thống

Hình 1.2.3: Kiểm thử tích hợp các thành phần trong một hệ thống

System integration testing

Kiểm thử tích hợp (các) hệ thống là khi các hệ thống độc lập có liên quanđến nhau thì chúng ta cần phải thực hiện kiểm thử tích hợp giữa chúng để đảm bảorằng chúng đáp ứng các luồng nghiệp vụ mong muốn

Ví dụ như một hệ thống bán hàng thương mại điện tử bất kỳ thường sẽ sửdụng dịch vụ thanh toán trực tuyến được cung cấp bởi một bên thứ 3 (3rd party)hoặc hệ thống thanh toán trực tuyến do công ty mình phát triển (bởi một nhómkhác) Chúng ta phải kiểm thử các luồng thanh toán cơ bản như thanh toán thànhcông, không thành công, v.v… Tương tự như chúng ta cần phải kiểm thử tích hợpgiữa 1 sàn thương mại điện tử (tiki, lazada) và bên giao hàng như Giao hàngnhanh, giao hàng tiết kiệm

Thường thì Tester (QC/QA) là người thực hiện việc kiểm thử ở mức tíchhợp các hệ thống này.

Một số phương pháp tiếp cận thường gặp để kiểm kiểm thử tích hợp:

 Big-Bang integration testing: tích hợp tất cả các thành phần (cần

kiểm thử) cùng một lúc và tiến hành kiểm thử theo các kịch bản,trường hợp cần thiết Cách tiếp cận này thường gặp, và được áp dụngcho các hệ thống đơn giản, nhỏ, ít thành phần Khi áp dụng cho các hệthống lớn thì sẽ gặp nhiều khó khăn trong việc xác định vị trí nơi gây

ra lỗi để sửa

 Top-Down integration testing: Việc kiểm thử được thực hiện từ các

đơn vị (module/function) ở cấp trên xuống theo luồng điều khiển của

hệ thống Các đơn vị cao nhất được kiểm tra trước và các cấp đơn vịthấp hơn được kiểm tra từng bước sau đó

 Bottom-Up integration testing: Ngược lại với Top-Down integration

testing, ở phương pháp tiếp cận này các đơn vị cấp thấp được kiểm tratrước và các đơn vị cấp cao hơn sẽ được kiểm tra sau đó

 Sandwich/Hybrid integration testing: Là sự kết hợp của hai phương

pháp Top-Down integration testing và Bottom-Up integration testing

Ở đây, các đơn vị ở cấp cao được kiểm tra với các đơn vị thấp hơnđồng thời các đơn vị thấp hơn được tích hợp với các đơn vị cấp trêncao để kiểm thử

Trên đây là phương pháp tiếp cận dựa vào cấu trúc/kiến trúc của mã nguồn.Ngoài ra chúng ta có thể tích hợp dựa vào luồng chức năng

Hình 1.2.4: Phương pháp tiếp cận kiểm thử tích hợp top-down

1.2.3 Kiểm thử hệ thống (system testing)

Một khi hệ thống đã được phát triển (lập trình) hoàn thiện, chúng ta cầnkiểm thử các luồng xử lý chức năng, và một số khía cạnh phi chức năng như hiệunăng (trong đó có load testing – kiểm thử tải) và đánh giá tính khả dụng của hệthống (usability – xem dễ sử dụng dễ hiểu cho mọi đối tượng người dùng haykhông)

Thường sẽ dựa vào tài liệu mô tả chức năng và áp dụng các kỹ thuật kiểmthử hộp đen để viết test case (là end-to-end test case) cho mức kiểm thử này Cũng

có thể dựa vào kinh nghiệm của tester và các vai trò khác trong dự án như PM/PO,khách hàng

Tester là người thực hiện kiểm thử ở mức này

1.2.4 Kiểm thử chấp nhận (acceptance testing)

Một khi tester đã thực hiện xong quá trình kiểm thử ở mức hệ thống, thìnhóm nhân viên khác trong công ty đến từ nhóm Chăm sóc khách hàng, Bán hàng,

… hoặc khách hàng sẽ thực hiện đánh giá tổng thể hệ thống dựa trên tài liệu mô tảyêu cầu của hệ thống Hoặc kiểm thử chấp nhận có thể được thực hiện song songvới quá trình kiểm thử mức hệ thống

Quá trình kiểm thử chấp nhận sẽ trả lời cho các câu hỏi như:

 Hệ thống đã sẵn sàng đưa vào sử dụng thực tế chưa?

 Hệ thống chạy đã đáp ứng như mong đợi của người dùng chưa?

 Có thể chấp nhận và thanh toán tiền cho sản phẩm này không?

 Vân vân…

Vậy ta có thể thấy, system testing là kiểm thử xem hệ thống có đúng yêu cầukhông, với mục đích là tìm lỗi Còn kiểm thử chấp nhận ở đây là xem phần mềm

có chạy đúng như người dùng và các bên liên quan mong đợi hay chưa

Riêng các công ty phát triển phần mềm theo dạng đóng gói hoặc sản phẩmcung cấp cho một nhóm khách hàng người dùng đặc thù (COTS software) thì có 2dạng kiểm thử chấp nhận thường gặp như:

 Alpha testing: Được thực hiện tại nơi phát triển phần mềm bởi những

người không tham gia trực tiếp vào quá trình phát triển chúng (nhưcác nhân viên đến từ nhóm chăm sóc khách hàng, bán hàng, hay cácnhóm phát triển phần mềm khác) Thường được thực hiện trước khithực hiện beta testing

 Beta testing: Có thể được thực hiện sau hoặc song song với alpha

testing Được thực hiện bởi người dùng (thường là khách hàng) Betatesting thường được diễn ra ở phía khách hàng và người dùng sảnphẩm trên môi trường thực tế của họ (như máy tính hoặc điện thoạicủa khách hàng)

Tuy nhiên, tester cũng thường phối hợp với khách hàng trong giai đoạn kiểmthử chấp nhận này (tùy theo yêu cầu của dự án)

1.3 Các loại kiểm thử (test types)

Loại kiểm thử là các nhóm các hoạt động kiểm thử được thực hiện để nhắmđến một mục đích cụ thể nào đó, ví dụ như để đánh giá chức năng, hiệu năng, haycác khía cạnh khác Sau đây là một số loại kiểm thử thường gặp:

1.3.1 Kiểm thử chức năng (functional testing)

Các hoạt động kiểm thử chức năng sẽ tập trung vào việc kiểm tra xem hệthống có hoạt động theo đúng theo yêu cầu nghiệp vụ đã mô tả hay chưa Tậptrung đánh giá tính đúng đắn, mức độ chính xác, và tính phù hợp của hệ thống vớingười dùng, và một số khía cạnh khác Kiểm thử chức năng có thể được thực hiện

ở tất cả các mức kiểm thử

Dưới đây là 2 cách tiếp cận để kiểm thử chức năng:

Requirements-based testing: quan điểm này dựa vào tài liệu mô tả yêu cầu

của hệ thống (như SRS – software requirement specification) để viết test case vàthực hiện kiểm thử

Cách tốt để bắt đầu là:

 Sử dụng nội dung của đặc tả yêu cầu để xác định phạm vi kiểm thử(danh sách các hạng mục cần kiểm thử và sẽ không kiểm thử)

 Chúng ta nên xét độ ưu tiên của các yêu cầu này dựa trên mức độ rủi

ro và độ ưu tiên để kiểm thử Điều này sẽ đảm bảo những chức năngquan trọng nhất sẽ được kiểm thử trước

Business-process-based testing: sẽ sử dụng các kiến thức/hiểu biết về quy

trình nghiệp vụ để viết test case và thực hiện kiểm thử Dựa vào quy trình nghiệp

vụ chúng ta có thể xác định được các kịch bản có thể xảy ra trong thực tế, giúpphát hiện sớm các lỗi liên quan đến xử lý nghiệp vụ

Ví dụ khi kiểm thử chức năng chuyển tiền liên ngân hàng có thể chúng taphát hiện lỗi liên quan đến trường hợp ngân hàng của người nhận đang bảo trì (khi

đó server sẽ không liên lạc được) hoặc xử lý chậm (do quá tải hệ thống) Và đây làtrường hợp rất có thể sẽ gặp phải trong thực tế, nhất là cuối tuần

1.3.2 Kiểm thử phi chức năng (non-functional testing)

Là các hoạt động kiểm thử nhằm đánh giá các đặc điểm chất lượng, hoặcthuộc tính phi chức năng như hiệu năng, bảo mật, và tính dễ sử dụng

Việc kiểm thử này cũng giống như kiểm thử chức năng, được thực hiện ởmọi mức kiểm thử (test level) Ví dụ khi áp dụng kiểm thử hiệu năng ở mức hệthống thì thường sẽ:

 Thực hiện các hoạt động kiểm thử để đánh giá mức chịu tải của hệthống (đánh giá xem hệ thống có thể xử lý được bao nhiêu yêu cầucùng lúc) thì đó là kiểm thử tải (load testing) Các công cụ (tool) hữuích trong kiểm thử hiệu năng gồm: JMeter, K6

 Hoặc kiểm thử tính khả dụng (usability testing) là các hoạt động đánhgiá xem hệ thống dễ sử dụng như thế nào

1.3.3 Kiểm thử bảo trì (maintenance testing)

“Kiểm thử bảo trì” mô tả các hoạt động kiểm thử được thực hiện trên một hệthống đang vận hành và sử dụng thực tế Các kỹ thuật và phương pháp tiếp cận đểkiểm thử cũng không có gì đặc biệt lắm so với việc kiểm thử được thực hiện trongquá phát triển phần mềm Tuy nhiên có 2 khái niệm kiểm thử quan trọng cần lưu ýnhư sau:

Kiểm thử xác nhận (Confirmation testing): là quá trình kiểm thử xem một

lỗi (bug/defect) đã được sửa (fix) đúng, hay một thay đổi yêu cầu đã được thựchiện đúng như mong đợi hay chưa Nơi thực hiện kiểm thử là vị trí những chỗđược thực hiện thay đổi (nơi được thực hiện thay đổi)

Kiểm thử hồi quy (Regression testing): là quá trình kiểm thử đánh giá các

khu vực không bị thay đổi để xem chúng có bị ảnh hưởng do quá trình thực hiệnthay đổi hay sửa lỗi (fix bug) gây ra “Regression” là những tác dụng phụ khôngmong muốn khi thực hiện thay đổi trong hệ thống (khi sửa đổi mã nguồn/sourcecode) nên regression testing là kiểm thử để tìm kiếm những tác dụng phụ khôngmong muốn này Thường các test case cho loại kiểm thử này sẽ được tự động hoá(gọi là automated test case) vì chúng thường xuyên được thực thi (sử dụng) nhiềulần trong suốt quãng đời phát triển và bảo trì phần mềm (thêm tính năng mới, xoáhoặc sửa các tính năng hiện có)

Các khái niệm trên cũng đồng thời áp dụng cho các hoạt động kiểm thửtrong quá trình phát triển phần mềm, khi kiểm thử trên các phần chức năng (hay

module) đã được phát triển (lập trình) xong trước đó rồi (ví dụ trong các Sprinttrước) Và bây giờ có một vài thay đổi liên quan đến các phần code/chức năng nàythì chúng ta cũng phải “test lại” để bảo đảm “mọi thứ vẫn ổn” (nghĩa là các chứcnăng cũ vẫn còn hoạt động như cũ – regression testing), bên cạnh việc kiểm thử đểxác nhận các yêu cầu mới hay fix bug đã được thực hiện đúng (confirmationtesting).

Ví dụ về phạm vi kiểm thử của confirmation testing và regression testing

1.4.1 Lập kế hoạch và kiểm soát

Lập kế hoạch kiểm thử là việc tạo ra một tài liệu mô tả tiếp cận tổng thể vàcác mục tiêu cần test Bao gồm xem xét cơ sở test, xác định các điều kiện dựa trênphân tích các mục thử test, viết các trường hợp và thiết kế môi trường test Tiêu chíhoàn thành được chỉ định để biết khi nào việc kiểm thử hoàn tất (ở bất kỳ giai đoạnnào)

Kiểm soát là hoạt động so sánh tiến độ thực tế so với kế hoạch và báo cáotình trạng, bao gồm cả những sai lệch so với kế hoạch Nó liên quan đến việc thựchiện các hành động cần thiết để đáp ứng mục tiêu của dự án

Mục đích của bước này là:

 Xác định phạm vi, rủi ro và các mục tiêu test

 Xác định các tài nguyên test cần thiết như con người, môi trường, v.v

 Lên lịch trình cho các nhiệm vụ phân tích và thiết kế, thực hiện, vàđánh giá test

1.4.2 Phân tích và thiết kế

Phân tích và thiết kế kiểm thử có các nhiệm vụ chính sau:

 Xem xét cơ sở test – thông tin dựa trên các trường hợp test, chẳng hạnnhư yêu cầu, đặc điểm thiết kế, phân tích rủi ro, kiến trúc và giao diện

 Xác định các điều kiện test

 Thiết kế các bài test

 Thiết kế môi trường thử test, thiết lập và xác định cơ sở hạ tầng vàcông cụ cần thiết

1.4.3 Thực hiện kiểm thử

Thực hiện kiểm thử là việc test chỉ định trên hệ thống máy tính theo cách thủcông hoặc sử dụng công cụ test tự động Việc triển khai test có nhiệm vụ chínhsau:

 Tiến hành các trường hợp test bằng cách sử dụng các kỹ thuật và tạo

dữ liệu cho các thử nghiệm đó

 Tạo các bộ kiểm thử từ các trường hợp test để thực hiện hiệu quả Bộkiểm thử là tập hợp các trường hợp test được sử dụng để kiểm thửphần mềm

 Thực hiện lại các trường hợp test không thành công trước đó để xácnhận bản sửa lỗi

 Ghi lại kết quả của việc thực hiện test Ở đó nhật ký kiểm thử ghi lạitrạng thái của trường hợp test (đạt / không đạt)

 So sánh kết quả thực tế với kết quả mong đợi

1.4.4 Đánh giá tiêu chí hoàn thành và báo cáo

Đánh giá tiêu chí hoàn thành là quá trình xác định thời điểm dừng kiểm thử

Nó phụ thuộc vào phạm vi của mã code, chức năng hoặc rủi ro Ngoài ra cũng phụthuộc vào rủi ro business, chi phí, thời gian và sự khác nhau giữa các dự án Đánhgiá tiêu chí hoàn thành có các nhiệm vụ chính sau:

 Đánh giá xem có cần test thêm hoặc tiêu chí hoàn thành đã chỉ định cócần thay đổi hay không

 Viết một báo cáo tóm tắt kiểm thử cho các bên liên quan

1.4.5 Hoàn tất kiểm thử

Quy trình hoàn tất kiểm thử được thực hiện khi phần mềm sẵn sàng đượcbàn giao Ngoài ra, kiểm thử có thể bị dừng lại vì các lý do khác như:

 Khi dự án bị hủy bỏ

 Khi đạt được một số mục tiêu

 Khi bản cập nhật hoặc release bảo trì hoàn thành

Bước này có các nhiệm vụ chính sau:

 Kiểm tra xe sản phẩm được bàn giao chưa, theo kế hoạch nào, và đểđảm bảo rằng tất cả các báo cáo sự cố đã được giải quyết

 Hoàn thiện và lưu trữ phần mềm kiểm thử như scripts, môi trườngtest, v.v để sử dụng lại sau này

 Bàn giao phần mềm kiểm thử cho bên bảo trì

 Đánh giá cách test đã thực hiện và rút kinh nghiệm cho các bảnrelease và dự án trong tương lai

Có thể rất khó để thực hiện mọi thứ trong quá trình từ đầu đến cuối một cáchhoàn hảo, từ lập kế hoạch đến thực hiện và hậu kỳ test Tuy nhiên, việc xác địnhquy trình và cải thiện test là một bước rất quan trọng để kiểm soát chất lượng sảnphẩm Kiểm thử phần mềm sẽ trở nên đơn giản hơn nếu hiểu mục đích, nắm rõ cácbước của quy trình và tuân theo

CHƯƠNG 2: KIỂM THỬ HỘP TRẮNG (WHITEBOX

TESTING)2.1 Kiểm thử hộp trắng là gì?

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 StructuralTesting) là 1 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ấtcần thiết trong kiểm thử hộp trắng

Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòngthông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để đánh giánhững hành động của phần mềm không được định hướng trước

Mục đích của White box testing là đảm bảo tất cả các câu lệnh và điều kiện

sẽ được thực hiện đúng, kết quả đầu ra như mong đợi Tester sẽ xác minh luồnghoạt động cho ứng dụng bằng cách kiểm tra một loạt đầu vào (Input) đã được xácđịnh từ trước có dẫn đến đầu ra (Output) như dự kiến không? Nếu Output khôngkhớp với kỳ vọng, có nghĩa là sản phẩm đang bị lỗi

Am hiểu về lập trình, có kiến thức về công nghệ thông tin là điều kiện tiênquyết để tester có thể tiến hành kiểm thử hộp trắng Thông thường, nhiệm vụ thựcthi White box Testing sẽ do chính các Developers đảm nhiệm

Phương pháp Kiểm tra Hộp trắng áp dụng cho các mức độ kiểm tra phầnmềm sau đây:

 Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơnvị

 Integration Testing(Test tích hợp): Để kiểm tra đường dẫn giữa cácđơn vị

 System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các

hệ thống con

Tuy nhiên, nó là chủ yếu áp dụng cho các kiểm thử đơn vị