Testing Fundamentals

LESSON 1. WHAT IS SOFTWARE TESTING? DEFINITION, BASICS, TYPES

ĐỊNH NGHĨA

Kiểm tra phần mềm có đúng với yêu cầu hay không
Nhằm: Đảm bảo sản phẩm đưa ra không có lỗi
Xác định lỗi, lỗ hổng hoặc yêu cầu còn thiếu so với thực tế

Là quá trình đánh giá 1 sản phẩm phần mềm để xem sản phẩm hiện tại có đáp ứng các điều kiện yêu
cầu hay không. Quá trình kiểm thử bao gồm việc đánh giá các tính năng theo các yêu cầu: về yêu cầu
còn thiếu, lỗi, lỗ hổng tính bảo mật, độ tin cậy và hiệu suất.

Bao gồm thực thi các thành phần của phần mềm/hệ thống bằng cách sử dụng các công cụ thủ
công (manual) hoặc tự động (automated) để đánh giá một hoặc nhiều thuộc tính cần thiết.
Kiểm thử phần mềm thường được nhắc đến là White Box và Black Box testing.
Software testing có nghĩa là Verification of Application Under Test (AUT) – Xác minh ứng dụng
dưới việc kiểm thử.

TẠI SAO KIỂM THỬ PHẦN MỀM LẠI QUAN TRỌNG?

Để phát hiện và giải quyết lỗi sớm trước khi giao sản phẩm.
Giúp đảm bảo độ tin cậy, bảo mật, hiệu suất cao, tiết kiệm thời gian, giả thiểu chi phí, tăng niềm
tin với khách hàng.

LỢI ÍCH CỦA KIỂM THỬ PHẦN MỀM

Hiệu quả về chi phí: Tiết kiệm chi phí về lâu dài. Trong trường hợp nếu các lỗi được phát hiện ở
giai đoạn kiểm thử phần mềm trước đó thì chi phí sửa chữa sẽ ít hơn.
Bảo mật: Đây là lợi ích dễ bị tổn thương và nhạy cảm nhất của kiểm thử phần mềm. Mọi người
đang tìm kiếm các sản phẩm đáng tin cậy. Nó giúp loại bỏ rủi ro và vấn đề sớm hơn.
Chất lượng sản phẩm: Việc kiểm tra đảm bảo chất lượng sản phẩm được giao đến tay khách
hàng.
Sự hài lòng của khách hàng: Kiểm thử UI/UX đảm bảo trải nghiệm người dùng tốt nhất.
CÁC CHIẾN LƯỢC KIỂM THỬ TRONG CÔNG NGHỆ PHẦN MỀM – Strategies

Unit Testing (Kiểm thử đơn vị): Cách tiếp cận cơ bản về kiểm thử phần mềm này được lập trình
viên tuân theo để kiểm thử đơn vị của chương trình. Nó giúp các nhà phát triển biết liệu đơn vị
mã riêng lẻ có hoạt động tốt hay không.
Integration Testing (Kiểm thử tích hợp): Tập trung vào việc xây dựng và thiết kế phần mềm.
Bạn cần xem các thiết bị tích hợp có hoạt động tốt không có lỗi hay không.
System Testing (Kiểm thử hệ thống): Trong phương pháp này, phần mềm của bạn được biên
dịch toàn bộ và sau đó được kiểm tra toàn bộ. Chiến lược thử nghiệm này kiểm tra chức năng,
bảo mật, tính di động, cùng nhiều thứ khác.

CÁC DẠNG KIỂM THỬ PHẦN MỀM

Testing
Types of Testing Description
Category
Functional  Unit Testing  Kiểm thử đơn vị: test các thành phần nhỏ
Testing  Integration như function, method, procedure, module
Testing or object
 Smoke  Kiểm thử tích hợp: test giữa các Module
 UAT ( User với nhau
Acceptance  Kiểm thử khói – check xem hệ thống có
Testing) khởi dộng được hay không
 Localization  Kiểm thử chấp nhận của người dùng (UAT)
 Globalization  Localization Testing - kiểm tra chức năng
 Interoperability phần mềm khi nó được chuyển đổi giữa các
 So on ngôn ngữ
 Globalization Testing - Đây là một kỹ thuật
 xác nhận liệu một ứng dụng có thừa nhận
tất cả các văn bản đầu vào ngôn ngữ và nó
có thể được sử dụng trên toàn cầu hay
không.
 Kiểm thử khả năng tương tác - kiểm tra
xem phần mềm có thể tương tác với các
thành phần, phần mềm hoặc hệ thống khác
hay không

 Performance
 Endurance
Non-  Load
Functional  Volume
Testing  Scalability
 Usability
 So on
 Regression
Maintenance
 Maintenance

LESSON 2. 7 PRINCIPLES OF SOFTWARE TESTING WITH EXAMPLES

1. Testing shows presence of defects: Test cho thấy sự hiện diện của lỗi:
Kiểm thử phần mềm làm giảm xác suất còn sót lại các lỗi chưa được phát hiện trong
phần mềm nhưng ngay cả khi không tìm thấy lỗi nào thì đó không phải là bằng chứng về
tính chính xác.
2. Exhaustive testing is not possible – Không thể test toàn bộ
3. Early testing – Kiểm thử sớm: càng sớm càng tốt
4. Defect clustering – Phân cụm lỗi
5. Pesticide paradox – Nghịch lý thuốc trừ sâu:
Nếu cùng một loạt các thử nghiệm lặp đi lặp lại được tiến hành, phương pháp này sẽ vô
ích trong việc phát hiện ra các lỗi mới.
6. Testing is context dependent – Test phụ thuộc vào ngữ cảnh:
Sử dụng một cách tiếp cận, phương pháp, kỹ thuật và loại thử nghiệm khác nhau tùy
thuộc vào loại ứng dụng
7. Absence of errors – fallacy: Không có lỗi – Ngụy biện:
Việc tìm và sửa lỗi sẽ không giúp ích gì nếu bản dựng hệ thống không sử dụng được và
không đáp ứng được nhu cầu và yêu cầu của người dùng
LESSON 3. V MODEL
Mô hình V là mô hình SDLC có tính kỷ luật cao, có giai đoạn test song song với từng giai đoạn
phát triển. Mô hình V là phần mở rộng của mô hình thác nước trong đó việc phát triển và thử
nghiệm phần mềm được thực hiện theo cách tuần tự.
Nó được gọi là Mô hình xác thực hoặc xác minh (Validation or Verification Model).

KEY WORD:
SDLC (Software Development Life Cycle): Vòng đời phát triển phần mềm. Đó là chuỗi các hoạt
động được Nhà phát triển thực hiện để thiết kế và phát triển phần mềm.
STLC (Software Testing Life Cycle): Nó bao gồm một loạt các hoạt động được Tester thực hiện
một cách có phương pháp để kiểm tra sản phẩm phần mềm của bạn.
Mô hình thác nước (Waterfall Model): Mô hình thác nước là mô hình tuần tự được chia thành
các giai đoạn khác nhau của hoạt động phát triển phần mềm. Mỗi giai đoạn được thiết kế để
thực hiện hoạt động cụ thể. Giai đoạn thử nghiệm trong mô hình thác nước chỉ bắt đầu sau khi
triển khai hệ thống xong.

EXAMPLE TO UNDERSTAND THE V MODEL

Giả sử nhiệm vụ là phát triển một phần mềm tùy chỉnh cho khách hàng. Trình tự các bước như
sau:
 Phases of Software Activities performed in each stage
Development
Requirement Gathering Gather as much information as possible about the details &
stage – Thu thập yêu cầu specifications of the desired software from the client. This is
nothing but the Requirements gathering stage.

Design Stage – Thiết kế Plan the programming language like Java, PHP, .net;
database like Oracle, MySQL, etc. Which would be suited for
the project, also some high-level functions & architecture.

Build Stage – Xây dựng After the design stage, it is build stage, that is nothing but
actually code the software

Test Stage – Kiểm thử
Deployment stage – Triển
khai
Maintenance stage – Bảo trì
Next, you test the software to verify that it is built as per the
specifications are given by the client.
Deploy the application in the respective environment
Once your system is ready to use, you may require to change
the code later on as per customer request

Problem with the Waterfall Model

Việc thử nghiệm trong mô hình chỉ bắt đầu sau khi quá trình triển khai hoàn tất. Nhưng nếu làm
việc trong dự án lớn, nơi có hệ thống phức tạp, rất dễ bỏ lỡ các chi tiết quan trọng trong giai
đoạn yêu cầu.

Solution: The V Model

Để giải quyết mối lo ngại này, mô hình thử nghiệm V đã được phát triển trong đó đối với mỗi
giai đoạn, trong Vòng đời phát triển đều có giai đoạn Thử nghiệm tương ứng.
LESSON 4. STLC (SOFTWARE TESTING LIFE CYCLE) PHASES, ENTRY, EXIT
CRITERIA

WHAT IS SOFTWARE TESTING LIFE CYCLE (STLC)?

Là một chuỗi các hoạt động cụ thể được thực hiện trong quá trình kiểm thử để đảm bảo đạt
được mục tiêu chất lượng phần mềm. STLC liên quan đến cả hoạt động xác minh (verification)
và xác nhận (validation).
Kiểm thử phần mềm không chỉ là một hoạt động đơn lẻ/riêng biệt. Nó bao gồm một loạt các
hoạt động được thực hiện một cách có phương pháp để giúp chứng nhận (certify) sản phẩm
phần mềm của bạn.

STLC PHASES

Có 6 giai đoạn chính sau đây trong

mọi Mô hình STLC:
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

WHAT IS ENTRY AND EXIT CRITERIA IN STLC?

 Entry Criteria: Tiêu chí đầu vào đưa ra các mục tiên quyết phải được hoàn thành trước
khi thử nghiệm có thể bắt đầu
 Exit Criteria: Tiêu chí kết thúc xác định các mục phải được hoàn thành trước khi kết thúc
quá trình kiểm tra

REQUIREMENT PHASE TESTING

Giai đoạn kiểm thử yêu cầu còn được gọi là Phân tích yêu cầu, trong đó nhóm kiểm thử nghiên
cứu các yêu cầu từ quan điểm kiểm thử để xác định các yêu cầu có thể kiểm thử được và nhóm
QA có thể tương tác với các bên liên quan khác nhau để hiểu chi tiết các yêu cầu. Yêu cầu có
thể là chức năng hoặc phi chức năng. Tính khả thi về tự động hóa cho dự án thử nghiệm cũng
được thực hiện trong giai đoạn này.
Activities in Requirement Phase Testing
 Xác định các loại Test cần thực hiện.
 Thu thập thông tin chi tiết về các ưu tiên và trọng tâm thử nghiệm.
 Chuẩn bị Ma trận truy xuất nguồn gốc yêu cầu (Requirement Traceability Matrix -
RTM).
 Xác định chi tiết môi trường thử nghiệm nơi thử nghiệm được cho là sẽ được thực hiện.
 Phân tích tính khả thi tự động hóa (nếu cần).

Deliverables of Requirement Phase Testing

 RTM
 Automation feasibility report. (if applicable)

TEST PLANNING IN STLC

Senior QA manager xác định chiến lược kế hoạch kiểm thử cùng với nguồn lực (efforts) và ước
tính chi phí cho dự án. Hơn nữa, tài nguyên, môi trường test, giới hạn test và lịch trình cũng
được xác định. Kế hoạch kiểm thử được chuẩn bị và hoàn thiện trong cùng một giai đoạn.

Test Planning Activities

 Preparation of test plan/strategy (chiến lược) document for various types of testing
 Test tool selection
 Test effort estimation (ước lượng)
 Resource planning and determining roles (vai trò) and responsibilities (trách nhiệm).
 Training requirement

Deliverables of Test Planning

 Test plan/strategy document.
 Effort estimation document.

Test Case Development Phase

Giai đoạn phát triển trường hợp kiểm thử bao gồm việc tạo, xác minh và rework test cases &
test scripts sau khi test plan đã sẵn sàng.
Ban đầu, Test data được xác định, sau đó được tạo và xem xét, sau đó được làm lại dựa trên
các điều kiện tiên quyết. Sau đó, nhóm QA bắt đầu quá trình phát triển các test case cho từng
đơn vị.
Test Case Development Activities
 Create test cases, automation scripts (if applicable)
 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables of Test Case Development

 Test cases/scripts
 Test data

Test Environment Setup

Quyết định các điều kiện phần mềm và phần cứng mà sản phẩm được thử nghiệm.
Đây là một trong những khía cạnh quan trọng của quá trình thử nghiệm và có thể được thực
hiện song song với Giai đoạn phát triển trường hợp thử nghiệm.
Nhóm kiểm thử có thể không tham gia vào hoạt động này nếu nhóm phát triển cung cấp môi
trường kiểm thử. Nhóm kiểm thử được yêu cầu thực hiện kiểm tra mức độ sẵn sàng (kiểm tra
khói – Smoke Testing) của môi trường nhất định.

Test Environment Setup Activities

 Understand the required architecture, environment set-up and prepare hardware and
software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables of Test Environment Setup

 Environment ready with test data set up
 Smoke Test Results.

Test Execution Phase

Giai đoạn thực hiện kiểm thử được thực hiện bởi Tester, trong đó việc kiểm thử bản dựng phần
mềm được thực hiện dựa trên các test plan và các test case đã chuẩn bị.
Quá trình này bao gồm thực thi tập lệnh kiểm thử (test scripts), bảo trì tập lệnh kiểm thử và
báo cáo lỗi. Nếu lỗi được báo cáo thì nó sẽ được gửi lại cho nhóm phát triển để sửa chữa và
việc kiểm tra lại sẽ được thực hiện.
 Test Execution Activities
 Execute tests as per plan
 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure

Deliverables of Test Execution

 Completed RTM with the execution status
 Test cases updated with results
 Defect reports

Test Cycle Closure

Là giai đoạn hoàn tất việc thực hiện kiểm thử bao gồm một số hoạt động: báo cáo hoàn thành
kiểm thử, thu thập ma trận hoàn thành kiểm thử và kết quả kiểm thử.

Test Cycle Closure Activities

 Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical
Business Objectives, Quality
 Prepare test metrics based on the above parameters (thông số).
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the customer.
Báo cáo định tính và định lượng về chất lượng của sản phẩm công việc cho khách hàng.
 Test result analysis to find out the defect distribution by type and severity.
Phân tích kết quả kiểm thử để tìm ra sự phân bố lỗi theo loại và mức độ nghiêm trọng.

Deliverables of Test Cycle Closure

 Test Closure report
 Test metrics

STLC Stage Entry Criteria Activity Exit Criteria Deliverables

Requirement Requirements Analyse business functionality to know Signed off RTM RTM
Analysis Document the business modules and module
available (both specific functionalities. Test automation Automation
functional and feasibility report feasibility
non functional) Identify all transactions in the modules. signed off by the report (if
client applicable)
Acceptance Identify all the user profiles.
criteria defined.
Gather user interface/ authentication,
Application geographic spread requirements.
architectural
document Identify types of tests to be performed.
available.
Gather details about testing priorities
and focus.

Prepare Requirement Traceability
Matrix (RTM).

Identify test environment details where

testing is supposed to be carried out.

Automation feasibility analysis (if

required).

Test Planning Requirements Analyze various testing approaches Approved test Test
Documents available plan/strategy plan/strategy
document. document.
Requirement Finalize on the best-suited approach
Traceability Effort estimation Effort
matrix. Preparation of test plan/strategy document signed estimation
document for various types of testing off. document.
Test automation
feasibility Test tool selection
document.
Test effort estimation

Resource planning and determining

roles and responsibilities.
Test case Requirements Create test cases, test design, Reviewed and Test
development Documents automation scripts (where applicable) signed test cases/scripts
Cases/scripts
RTM and test Review and baseline test cases and Test data
plan Reviewed and
 Automation scripts signed test data
analysis report
Create test data
Test System Design Understand the required architecture, Environment setup Environment
Environment and architecture environment set-up is working as per ready with test
setup documents are the plan and data set up
available Prepare hardware and software checklist
development requirement list Smoke Test
Environment Test data setup is Results.
set-up plan is Finalize connectivity requirements complete
available
Prepare environment setup checklist Smoke test is
successful
Setup test Environment and test data

Perform smoke test on the build

Accept/reject the build depending on

smoke test result

Test Baselined Execute tests as per plan All tests planned Completed RTM
Execution RTM, Test Plan , are executed with execution
Test case/scripts Document test results, and log defects status
are available for failed cases Defects logged and
tracked to closure Test cases
Test Update test plans/test cases, if updated with
environment is necessary results
ready
Map defects to test cases in RTM Defect reports
Test data set up
is done Retest the defect fixes

Unit/Integration Regression Testing of application

test report for
the build to be Track the defects to closure
tested is
available
Test Cycle Testing has been Evaluate cycle completion criteria based Test Closure report Test Closure
closure completed on – Time, Test coverage, Cost, signed off by client report
Software Quality, Critical Business
Test results are Objectives Test metric
available
Prepare test metrics based on the above
Defect logs are parameters.
available
Document the learning out of the
project

Prepare Test closure report

Qualitative and quantitative reporting of

quality of the work product to the
customer.

Test result analysis to find out the

defect distribution by type and severity
Types of Testing
LESSON 1. MANUAL TESTING TUTORIAL FOR BEGINNERS: CONCEPTS,
TYPES, TOOL

MANUAL TESTING

Kiểm thử thủ công là một loại kiểm thử phần mềm trong đó các trường hợp kiểm thử được
người kiểm thử thực hiện thủ công mà không sử dụng bất kỳ công cụ tự động nào.
Mục đích của Manual testing là xác định các lỗi, sự cố và khiếm khuyết trong ứng dụng phần
mềm.
Kiểm thử phần mềm thủ công đòi hỏi nhiều nỗ lực hơn nhưng cần thiết để kiểm tra tính khả thi
của tự động hóa.
Một trong những Nguyên tắc cơ bản về kiểm thử phần mềm là "Không thể tự động hóa 100%".
Điều này làm cho việc Manual testing trở nên bắt buộc.

GOAL OF MANUAL TESTING

Khái niệm chính của manual testing là đảm bảo rằng ứng dụng không có lỗi và nó hoạt động
phù hợp với các yêu cầu chức năng đã chỉ định.
Bộ kiểm thử (Test Suites) hoặc cases được thiết kế trong giai đoạn thử nghiệm và phải có phạm
vi kiểm thử 100%.
Nó cũng đảm bảo rằng các lỗi được báo cáo đã được dev sửa chữa và việc kiểm tra lại đã được
thực hiện bởi tester về các lỗi đã sửa.
Về cơ bản, thử nghiệm này kiểm tra chất lượng của hệ thống và cung cấp sản phẩm không có lỗi
cho khách hàng.

HOW TO PERFORM MANUAL TESTING

1. Đọc và hiểu tài liệu/hướng dẫn dự án phần mềm. Ngoài ra, hãy nghiên cứu Ứng dụng
đang kiểm tra (AUT) nếu có.
2. Dự thảo các Test Case bao gồm tất cả các yêu cầu được đề cập trong tài liệu.
3. Xem xét và baseline các test case với Team Lead, Client (nếu có)
4. Thực thi các test case trên AUT
5. Report bugs.
6. Khi lỗi được sửa, một lần nữa thực hiện các Test Case không thành công để xác minh
chúng passed
MANUAL TESTING VS AUTOMATION TESTING
Manual Testing
Manual testing requires human intervention
for test execution.
Manual testing will require skilled labour,
long time & will imply high costs.
Any type of application can be tested
manually, certain testing types like ad-hoc
and monkey testing are more suited for
manual execution.
Manual testing can become repetitive and
boring.
TYPES OF MANUAL TESTING:
Automated Testing
Automation Testing is use of tools to execute
test cases
Automation Testing saves time, cost and
manpower. Once recorded, it’s easier to run an
automated test suite
Automated testing is recommended only for
stable systems and is mostly used
for Regression Testing
The boring part of executing same test cases
time and again is handled by automation
software in Automation Testing.
Black Box Testing
Kiểm thử hộp đen là một phương pháp kiểm thử phần mềm trong đó các chức năng của ứng
dụng phần mềm được kiểm tra mà không cần có kiến thức về cấu trúc mã nội bộ, chi tiết triển
khai và đường dẫn nội bộ.
Kiểm thử hộp đen chủ yếu tập trung vào đầu vào và đầu ra của ứng dụng phần mềm và nó hoàn
toàn dựa trên các yêu cầu và thông số kỹ thuật của phần mềm. Nó còn được gọi là Kiểm tra
hành vi.

Black Box Testing Techniques

Sau đây là Chiến lược kiểm thử (Test Strategy) nổi bật trong số nhiều chiến lược được sử dụng
trong Black box Testing:

 Equivalence Class Testing - Kiểm tra lớp tương đương: Nó được sử dụng để giảm thiểu
số lượng các trường hợp kiểm thử có thể đến mức tối ưu trong khi vẫn duy trì phạm vi
kiểm thử hợp lý.
 Boundary Value Testing - Kiểm tra giá trị biên: Kiểm tra giá trị biên tập trung vào các giá
trị tại ranh giới. Kỹ thuật này xác định liệu một phạm vi giá trị nhất định có được hệ
thống chấp nhận hay không. Nó rất hữu ích trong việc giảm số lượng các trường hợp
thử nghiệm. Nó phù hợp nhất cho các hệ thống có đầu vào nằm trong phạm vi nhất
định.
 Decision Table Testing - Kiểm tra bảng quyết định: Bảng quyết định đặt nguyên nhân và
kết quả của chúng trong một ma trận. Có một sự kết hợp độc đáo trong mỗi cột.
Types of Black Box Testing
 Functional testing – Loại kiểm thử hộp đen này liên quan đến các yêu cầu chức năng của
hệ thống; nó được thực hiện bởi Tester
 Non-functional testing – Loại kiểm tra hộp đen này không liên quan đến kiểm tra chức
năng cụ thể mà liên quan đến các yêu cầu phi chức năng như hiệu suất, khả năng mở
rộng, khả năng sử dụng…
 Regression testing – Hồi quy: được thực hiện sau khi sửa mã, nâng cấp hoặc bất kỳ bảo
trì hệ thống nào khác để kiểm tra mã mới không ảnh hưởng đến mã hiện có.
How to do BlackBox Testing in Software Engineering
Dưới đây là các bước chung được thực hiện để thực hiện bất kỳ loại Blackbox Testing nào
1. Ban đầu, các yêu cầu và thông số kỹ thuật của hệ thống được kiểm tra.
2. Tester chọn đầu vào hợp lệ (kịch bản kiểm tra tích cực – positive test scenario) để kiểm
tra xem SUT có xử lý chúng chính xác hay không. Ngoài ra, một số đầu vào không hợp lệ
(kịch bản thử nghiệm không tích cực – negative test scenario) được chọn để xác minh
rằng SUT có thể phát hiện ra chúng.
3. Xác định kết quả đầu ra dự kiến cho tất cả những đầu vào đó.
4. Xây dựng các trường hợp thử nghiệm với các đầu vào đã chọn.
5. Các trường hợp thử nghiệm được thực hiện.
6. So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến.
7. Các lỗi nếu có đều được khắc phục và kiểm tra lại.

Tools used for Black Box Testing:

Các công cụ được sử dụng để kiểm thử hộp đen phần lớn phụ thuộc vào loại kiểm thử hộp đen
mà bạn đang thực hiện.

 For Functional/ Regression Tests you can use – QTP, Selenium

 For Non-Functional Tests, you can use – LoadRunner, Jmeter

Black Box Testing and Software Development Life Cycle (SDLC)

Kiểm thử hộp đen có vòng đời riêng được gọi là Vòng đời kiểm thử phần mềm (STLC) và nó liên
quan đến mọi giai đoạn của SDLC của Kỹ thuật phần mềm (Software Engineering)

 Requirement – Đây là giai đoạn đầu của SDLC và trong giai đoạn này, một yêu cầu được
thu thập. Tester cũng tham gia vào giai đoạn này
 Test Planning & Analysis – Các loại kiểm thử áp dụng cho dự án được xác định. Test
Plan được tạo ra để xác định các rủi ro dự án có thể xảy ra và cách giảm thiểu chúng
 Design – Test cases/scripts được tạo trên cơ sở các tài liệu yêu cầu phần mềm
 Test Execution – Test Cases đã chuẩn bị sẽ được thực thi. Các lỗi nếu có đều được sửa
và kiểm tra lại.
White Box Testing
Kiểm thử hộp trắng là một kỹ thuật kiểm thử trong đó cấu trúc (structure), thiết kế và mã hóa
(code) bên trong của phần mềm được kiểm tra để xác minh luồng đầu vào - đầu ra và cải thiện
thiết kế, khả năng sử dụng (usability) và bảo mật (security).
What do you verify in White Box Testing?
Việc kiểm thử hộp trắng bao gồm kiểm thử code của phần mềm cho các nội dung sau:

 Lỗ hổng bảo mật nội bộ - Internal security holes

 Đường dẫn bị hỏng hoặc có cấu trúc kém trong quy trình mã hóa
 Luồng đầu vào cụ thể thông qua code
 Đầu ra dự kiến
 Chức năng của các vòng lặp điều kiện
 Kiểm tra từng câu lệnh (statement), đối tượng (object) và chức năng (function) trên cơ
sở riêng lẻ
Việc kiểm thử có thể được thực hiện ở cấp độ system, integration và unit.
Một trong những mục tiêu cơ bản của thử nghiệm hộp trắng là xác minh quy trình làm việc của
ứng dụng. Nó liên quan đến việc kiểm tra một loạt đầu vào được xác định trước so với đầu ra
mong muốn để khi một đầu vào cụ thể không mang lại kết quả đầu ra như mong đợi thì bạn đã
gặp phải lỗi.

Kiểm thử Hộp trắng được chia thành 2 bước cơ bản:

STEP 1) UNDERSTAND THE SOURCE CODE

Tìm hiểu và hiểu source code của ứng dụng.
Vì kiểm thử hộp trắng liên quan đến việc kiểm thử các hoạt động bên trong của một ứng dụng
nên người kiểm thử phải rất am hiểu về các ngôn ngữ lập trình được sử dụng trong các ứng
dụng mà họ đang kiểm thử.
Ngoài ra, tester phải biết về hoạt động mã hóa bảo mật.
Bảo mật thường là một trong những mục tiêu chính của phần mềm thử nghiệm. Người kiểm tra
phải có thể tìm ra các vấn đề bảo mật và ngăn chặn các cuộc tấn công từ tin tặc và những người
dùng có thể truyền mã độc vào ứng dụng dù vô tình hay cố ý.
STEP 2) CREATE TEST CASES AND EXECUTE
Test source code của ứng dụng để biết quy trình và cấu trúc phù hợp.
Một cách là viết thêm mã để kiểm tra mã nguồn của ứng dụng. Tester sẽ phát triển các bài kiểm
tra nhỏ cho từng quy trình hoặc chuỗi quy trình trong ứng dụng. Phương pháp này yêu cầu
tester phải có kiến thức sâu về code và thường được thực hiện bởi dev.
Các phương pháp khác bao gồm Manual Testing, trial và error testing cũng như sử dụng các
công cụ kiểm tra (tools)

White Box Testing Techniques

Code Coverage analysis – Phân tích độ phủ của code .
Giúp loại bỏ các khoảng trống trong Test Case suite. Nó xác định các khu vực của chương trình
không được thực hiện bởi một tập hợp các test case. Sau khi xác định được các lỗ hổng, tạo các
TC để xác minh các phần code chưa được test, từ đó nâng cao chất lượng của sản phẩm.
Có sẵn các công cụ tự động (automated tools) để thực hiện Code Coverage analysis. Dưới đây
là một số kỹ thuật phân tích mức độ phù hợp mà người kiểm tra hộp có thể sử dụng:

 Statement Coverage – Phạm vi câu lệnh: Kỹ thuật này yêu cầu mọi câu lệnh có thể có
trong code phải được kiểm tra ít nhất một lần trong quá trình test.
 Branch Coverage – Phạm vi nhánh: Kỹ thuật này kiểm tra mọi đường dẫn possible (if-
else và các vòng lặp có điều kiện khác) của software application.
Using Statement and Branch coverage you generally attain 80-90% code coverage which is
sufficient.
Following are important WhiteBox Testing Techniques:

 Statement Coverage
 Decision Coverage
 Branch Coverage
 Condition Coverage
 Multiple Condition Coverage
 Finite State Machine Coverage
 Path Coverage
 Control flow testing
 Data flow testing
Types of White Box Testing
 Unit Testing: Thường được thực hiện bởi dev
Đây thường là loại thử nghiệm đầu tiên được thực hiện trên một ứng dụng.
Được thực hiện trên từng đơn vị (unit) hoặc khối mã (block of code) khi nó được phát
triển.
Giúp xác định phần lớn lỗi ngay từ đầu vòng đời phát triển phần mềm. Các lỗi được xác
định trong giai đoạn này sẽ rẻ hơn và dễ sửa hơn.
 Testing for Memory Leaks:
Rò rỉ bộ nhớ là nguyên nhân hàng đầu khiến các ứng dụng chạy chậm hơn. Chuyên gia
QA có kinh nghiệm phát hiện rò rỉ bộ nhớ là điều cần thiết trong trường hợp bạn có ứng
dụng phần mềm chạy chậm.
Ngoài những điều trên, một số loại thử nghiệm là một phần của cả thử nghiệm hộp đen và hộp
trắng. Chúng được liệt kê dưới đây:
 White Box Penetration Testing: tester/developer có đầy đủ thông tin về mã nguồn của
ứng dụng, thông chi tiết về network, địa chỉ IP liên quan và tất cả thông tin máy chủ mà
ứng dụng chạy trên đó. Mục đích là để tấn công mã từ nhiều góc độ để phơi bày các mối
đe dọa an ninh.
 White Box Mutation Testing: Kiểm tra đột biến thường được sử dụng để khám phá các
kỹ thuật mã hóa tốt nhất để sử dụng cho việc mở rộng giải pháp phần mềm.
White Box Testing Tools
 EclEmma
 NUnit
 PyUnit
 HTMLUnit
 CppUnit

Advantages of White Box Testing

 Tối ưu hóa mã bằng cách tìm lỗi ẩn.
 Các trường hợp kiểm tra hộp trắng có thể dễ dàng tự động hóa.
 Kiểm tra kỹ lưỡng hơn vì tất cả các đường dẫn mã thường được che phủ.
 Thử nghiệm có thể bắt đầu sớm trong SDLC ngay cả khi GUI không có sẵn.
Disadvantages of WhiteBox Testing
 Thử nghiệm hộp trắng có thể khá phức tạp và tốn kém.
 Dev test không chi tiết và có thể dẫn đến lỗi sản xuất.
 Đòi hỏi các nguồn lực chuyên nghiệp với sự hiểu biết chi tiết về lập trình và triển khai.
 Tốn thời gian, các ứng dụng lập trình lớn hơn mất thời gian để kiểm tra đầy đủ.
Comparison of Black Box and White Box Testing:
Black Box Testing White Box Testing
the main focus of black box testing White Box Testing (Unit Testing) validates internal structure
is on the validation of your and working of your software code
functional requirements.
Black box testing gives abstraction To conduct White Box Testing, knowledge of underlying
from code and focuses on testing programming language is essential. Current day software
effort on the software system systems use a variety of programming languages and
behavior. technologies and its not possible to know all of them.

Black box testing facilitates testing White box testing does not facilitate testing communication
communication amongst modules amongst modules

SOFTWARE TESTING HIERARCHY – Phân cấp kiểm thử

Như với hầu hết các quy trình kỹ thuật phần

mềm, kiểm thử phần mềm có một thứ tự quy
định trong đó mọi thứ nên được thực hiện.
Sau đây là danh sách các danh mục kiểm thử
phần mềm được sắp xếp theo thứ tự thời
gian. Đây là các bước được thực hiện để kiểm
tra đầy đủ phần mềm mới để chuẩn bị cho
việc tiếp thị nó:

 UNIT TESTING: được thực hiện trên mỗi mô-đun hoặc khối mã trong quá trình phát
triển. Unit Testing thường được thực hiện bởi lập trình viên viết code.
 INTEGRATION TESTING: được thực hiện trước, trong và sau khi tích hợp một mô-đun
mới vào main software package - kiểm tra từng mô-đun code riêng lẻ. Điều quan trọng
là phải kiểm tra hiệu quả của từng mô-đun trên toàn bộ mô hình chương trình.
 SYSTEM TESTING: được thực hiện bởi một chuyên viên kiểm thử chuyên nghiệp trên
sản phẩm phần mềm đã hoàn thành trước khi nó được giới thiệu ra thị trường.
 ACCEPTANCE TESTING: thử nghiệm beta của sản phẩm được thực hiện bởi người dùng
thực tế cuối cùng
UNIT TESTING – HAY COMPONENT TESTING
Kiểm thử đơn vị là một loại kiểm thử phần mềm trong đó các đơn vị hoặc thành phần riêng lẻ
của phần mềm được kiểm thử. Mục đích là để xác nhận rằng mỗi đơn vị mã phần mềm hoạt
động như mong đợi.
Được thực hiện trong quá trình phát triển (giai đoạn code) của ứng dụng bởi dev. Kiểm tra đơn
vị tách biệt một phần mã và xác minh tính chính xác của nó. Một đơn vị có thể là một hàm
(function), phương thức (method), thủ tục (procedure), mô-đun hoặc đối tượng riêng lẻ
(object).
Trong SDLC, STLC, V Model, Kiểm thử đơn vị là cấp độ kiểm thử đầu tiên được thực hiện trước
khi kiểm thử tích hợp (Integration testing).
Why perform Unit Testing?
Kiểm thử đơn vị rất quan trọng vì các nhà phát triển phần mềm đôi khi cố gắng tiết kiệm thời
gian thực hiện kiểm thử đơn vị ở mức tối thiểu và điều này dẫn đến nguy cơ xảy ra lỗi, dẫn đến
chi phí sửa lỗi cao.
Dưới đây là những lý do chính để thực hiện kiểm thử đơn vị trong công nghệ phần mềm:
1. Kiểm thử đơn vị giúp sửa lỗi sớm trong chu kỳ phát triển và tiết kiệm chi phí.
2. Nó giúp các nhà phát triển hiểu cơ sở mã thử nghiệm và cho phép họ thực hiện các thay
đổi nhanh chóng.
3. Các thử nghiệm đơn vị tốt đóng vai trò là tài liệu dự án.
4. Các thử nghiệm đơn vị giúp sử dụng lại mã. Di chuyển cả mã và thử nghiệm của bạn
sang dự án mới. Tinh chỉnh mã cho đến khi chạy thử nghiệm lại.
How to execute Unit Testing?
Để thực hiện Kiểm tra đơn vị, viết một đoạn mã để kiểm tra một chức năng cụ thể trong ứng
dụng phần mềm.
Unit testing có hai loại: Manual và Automated
Nhà phát triển cũng có thể tách biệt chức năng để kiểm tra nó chặt chẽ hơn, bao gồm việc sao
chép và dán mã vào môi trường kiểm thử của chính nó thay vì môi trường tự nhiên.
Việc cô lập mã giúp phát hiện sự phụ thuộc không cần thiết giữa mã đang được kiểm tra và các
đơn vị hoặc không gian dữ liệu khác trong sản phẩm.
Thường sử dụng UnitTest Framework để phát triển các trường hợp kiểm thử tự động. Bằng
cách sử dụng khung tự động hóa, nhà phát triển mã hóa các tiêu chí vào thử nghiệm để xác
minh tính chính xác của mã. Trong quá trình thực hiện các trường hợp kiểm thử, khung sẽ ghi
lại các trường hợp kiểm thử bị lỗi. Tóm lại, nhiều khung cũng sẽ tự động gắn cờ và báo cáo các
trường hợp thử nghiệm không thành công này. Tùy thuộc vào mức độ nghiêm trọng của lỗi,
khung có thể tạm dừng thử nghiệm tiếp theo.
Quy trình làm việc của Unit Testing:
1) Tạo trường hợp kiểm thử (Test Cases)
2) Đánh giá/làm lại (Review/Rework)
3) Đường cơ sở (Baseline)
4) Thực hiện các trường hợp kiểm thử. (Execute Test Cases)

Unit Testing Techniques

Chủ yếu được phân loại thành ba phần đó là:
Kiểm thử hộp đen bao gồm kiểm tra giao diện người dùng cùng với đầu vào và đầu ra
Kiểm thử hộp trắng bao gồm kiểm tra hành vi chức năng của ứng dụng phần mềm
Kiểm thử hộp xám được sử dụng để thực hiện các bộ thử nghiệm, phương pháp thử nghiệm,
trường hợp thử nghiệm và thực hiện phân tích rủi ro.
Các kỹ thuật bao phủ mã được sử dụng trong Kiểm thử đơn vị được liệt kê dưới đây:

 Statement Coverage
 Decision Coverage
 Branch Coverage
 Condition Coverage
 Finite State Machine Coverage

Unit Testing Advantage

Các nhà phát triển muốn tìm hiểu chức năng nào được cung cấp bởi một đơn vị và cách sử dụng
nó có thể xem các thử nghiệm đơn vị để hiểu cơ bản về API đơn vị.
Cho phép lập trình viên cấu trúc lại mã sau này và đảm bảo mô-đun vẫn hoạt động chính xác
(tức là kiểm tra hồi quy).
Quy trình là viết các trường hợp kiểm thử cho tất cả các chức năng và phương thức để bất cứ
khi nào một thay đổi gây ra lỗi thì có thể nhanh chóng xác định và sửa lỗi đó.
Do tính chất mô-đun của thử nghiệm đơn vị nên có thể thử nghiệm các phần của dự án mà
không cần đợi những phần khác hoàn thành.
Unit Testing Disadvantages
Không thể bắt được mọi lỗi trong một chương trình. Không thể đánh giá tất cả các đường dẫn
thực thi ngay cả trong các chương trình tầm thường nhất.
Kiểm tra đơn vị về bản chất là tập trung vào một đơn vị mã. Do đó, nó không thể bắt được lỗi
tích hợp hoặc lỗi cấp hệ thống rộng.

Unit Testing Best Practices

Các trường hợp kiểm thử đơn vị phải độc lập. Trong trường hợp có bất kỳ cải tiến hoặc thay đổi
nào về yêu cầu, các trường hợp kiểm thử đơn vị sẽ không bị ảnh hưởng.
Mỗi lần chỉ kiểm tra một mã.
Thực hiện theo các quy ước đặt tên rõ ràng và nhất quán cho các bài kiểm thử đơn vị của bạn.
Trong trường hợp có thay đổi về mã trong bất kỳ mô-đun nào, hãy đảm bảo có một Trường hợp
Kiểm thử đơn vị tương ứng cho mô-đun đó và mô-đun đó đã vượt qua các test case trước khi
thay đổi cách triển khai.
Các lỗi được xác định trong quá trình kiểm thử đơn vị phải được loại bỏ. đã sửa trước khi
chuyển sang giai đoạn tiếp theo trong SDLC
Áp dụng phương pháp " test as your code". Bạn càng viết nhiều mã mà không kiểm tra thì bạn
càng phải kiểm tra nhiều đường dẫn để tìm lỗi.
SYSTEM TESTING
Kiểm thử hệ thống là một cấp độ kiểm thử xác nhận sản phẩm phần mềm hoàn chỉnh và được
tích hợp đầy đủ.
Mục đích: đánh giá các thông số kỹ thuật hệ thống end-to-end.
Thông thường, phần mềm chỉ là một yếu tố (element) của một hệ thống dựa trên máy tính lớn
hơn. Cuối cùng, phần mềm được giao tiếp với các hệ thống software/hardware khác.
Kiểm thử hệ thống được định nghĩa là một loạt các thử nghiệm khác nhau với mục đích duy
nhất là thực hiện toàn bộ hệ thống dựa trên máy tính.
System Testing is Blackbox - liên quan đến hoạt động bên ngoài của phần mềm theo quan điểm
của người dùng.
What do you verify in System Testing?
 Kiểm tra các ứng dụng tích hợp đầy đủ bao gồm các thiết bị ngoại vi bên ngoài để kiểm
tra cách các thành phần tương tác với nhau và với toàn bộ hệ thống. Đây còn được gọi
là kịch bản thử nghiệm End to End.
 Xác minh kiểm tra kỹ lưỡng mọi đầu vào trong ứng dụng để kiểm tra đầu ra mong muốn.
 Kiểm tra trải nghiệm của người dùng với ứng dụng.
Types of System Testing
Một số loại thường dùng:
Usability Testing - chủ yếu tập trung vào sự dễ sử dụng ứng dụng của người dùng, tính linh
hoạt trong việc xử lý các điều khiển và khả năng của hệ thống để đáp ứng các mục tiêu của nó
Load Testing - là cần thiết để biết rằng một giải pháp phần mềm sẽ hoạt động dưới tải thực tế.
Regression Testing  - liên quan đến việc kiểm thử được thực hiện để đảm bảo không có thay
đổi nào được thực hiện trong quá trình phát triển gây ra lỗi mới. Nó cũng đảm bảo không có lỗi
cũ nào xuất hiện từ việc bổ sung các mô-đun phần mềm mới theo thời gian.
Recovery Testing - được thực hiện để chứng minh một giải pháp phần mềm là đáng tin cậy,
đáng tin cậy và có thể thu hồi thành công từ các sự cố có thể xảy ra.
Migration Testing – được thực hiện để đảm bảo rằng phần mềm có thể được chuyển từ cơ sở
hạ tầng hệ thống cũ sang cơ sở hạ tầng hệ thống hiện tại mà không gặp bất kỳ sự cố nào.
Functional Testing - Còn được gọi là kiểm tra tính đầy đủ chức năng, Kiểm thử chức năng liên
quan đến việc cố gắng nghĩ về bất kỳ chức năng nào có thể bị thiếu. Người thử nghiệm có thể
lập danh sách các chức năng bổ sung mà sản phẩm có thể phải cải thiện nó.
Hardware/Software Testing - Tập trung vào các tương tác giữa phần cứng và phần mềm trong
quá trình kiểm thử hệ thống.

INTEGRATION TESTING
Kiểm thử tích hợp được định nghĩa là một loại kiểm thử trong đó các mô-đun phần mềm được
tích hợp một cách hợp lý và được kiểm thử dưới dạng một nhóm.
Tập trung vào việc kiểm tra giao tiếp dữ liệu giữa các mô-đun. Do đó, nó còn được gọi là 'I & T'
(Tích hợp và Kiểm tra), 'Thử nghiệm chuỗi' và đôi khi là 'Thử nghiệm luồng'.
Why do Integration Testing?
Mặc dù mỗi mô-đun phần mềm đều được kiểm thử đơn vị (unit testing), nhưng các lỗi vẫn tồn
tại vì nhiều lý do khác nhau, chẳng hạn như:

 Mô-đun A nói chung được thiết kế bởi một nhà phát triển phần mềm riêng lẻ mà cách
hiểu và logic lập trình của họ có thể khác với các lập trình viên khác.
 Để xác minh các mô-đun phần mềm hoạt động thống nhất.
 Tại thời điểm phát triển mô-đun, có rất nhiều thay đổi yêu cầu của khách hàng. Những
yêu cầu mới này có thể không được kiểm thử đơn vị và do đó Kiểm thử tích hợp hệ
thống trở nên cần thiết.
 Giao diện của mô-đun phần mềm với cơ sở dữ liệu có thể bị lỗi.
 Giao diện phần cứng bên ngoài, nếu có, có thể bị lỗi. Việc xử lý ngoại lệ không đầy đủ có
thể gây ra sự cố.

Example of Integration Test Case

Trường hợp kiểm thử tích hợp khác với các trường hợp kiểm thử khác ở chỗ nó tập trung chủ
yếu vào giao diện và luồng dữ liệu/thông tin giữa các mô-đun.
Ở đây ưu tiên dành cho các liên kết tích hợp hơn là các chức năng đơn vị đã được thử nghiệm.
Các trường hợp kiểm thử tích hợp mẫu cho kịch bản sau:
Ứng dụng có 3 mô-đun là 'Trang đăng nhập', 'Hộp thư' và 'Xóa email' và mỗi mô-đun đều được
tích hợp một cách hợp lý. Ở đây không tập trung nhiều vào việc kiểm tra Trang đăng nhập vì nó
đã được thực hiện trong Kiểm tra đơn vị. Nhưng hãy kiểm tra xem nó được liên kết như thế
nào với Trang Hộp Thư. Tương tự Hộp Thư: Kiểm tra sự tích hợp của nó với Mô-đun Xóa Thư.

Test
Test Case Objective Test Case Description Experted Result
Case ID
Check the interface link Enter login credentials
To be directed to the
1 between the Login and and click on the Login
Mail Box
Mailbox module button
 Check the interface link From Mailbox select the Selected email should
2 between the Mailbox and email and click a delete appear in the
Delete Mails Module button Deleted/Trash folder
Types of Integration Testing
Kỹ thuật phần mềm xác định nhiều chiến lược khác nhau để thực hiện Kiểm thử tích hợp:

 Phương pháp tiếp cận Big Bang:

 Phương pháp tiếp cận tăng dần: được chia thành các phương pháp
o Tiếp cận từ trên xuống
o Tiếp cận từ dưới lên
o Tiếp cận sandwich – Sự kết hợp giữa từ trên xuống và từ dưới lên

Big Bang Testing

Là một phương pháp Integration Testing trong đó tất cả các thành phần hoặc mô-đun được tích
hợp với nhau cùng một lúc và sau đó được thử nghiệm dưới dạng một đơn vị.
Tập hợp các thành phần kết hợp này được coi là một thực thể (entity) trong khi thử nghiệm.
Nếu tất cả các thành phần trong đơn vị chưa được hoàn thiện thì quá trình tích hợp sẽ không
được thực thi.
Ưu điểm: Thuận tiện cho các hệ thống nhỏ.
Nhược điểm:

 Khó định vị lỗi.

 Với số lượng lớn các giao diện cần được kiểm tra theo phương pháp này, một số liên kết
giao diện được kiểm tra có thể dễ dàng bị bỏ qua. Vì thử nghiệm Tích hợp chỉ có thể bắt
đầu sau khi "tất cả" các mô-đun được thiết kế nên nhóm thử nghiệm sẽ có ít thời gian
hơn để thực hiện trong giai đoạn thử nghiệm.
 Vì tất cả các mô-đun đều được kiểm tra cùng một lúc nên các mô-đun quan trọng có rủi
ro cao không bị cô lập và được ưu tiên kiểm tra.
 Các mô-đun ngoại vi xử lý giao diện người dùng cũng không bị cô lập và được ưu tiên
kiểm tra.
Incremental Testing
Trong phương pháp Kiểm thử tăng dần, kiểm thử được thực hiện bằng cách tích hợp hai hoặc
nhiều mô-đun có liên quan logic với nhau và sau đó kiểm tra xem ứng dụng có hoạt động đúng
chức năng hay không.
Sau đó, các mô-đun liên quan khác được tích hợp tăng dần và quá trình tiếp tục cho đến khi tất
cả các mô-đun liên quan đến logic được tích hợp và thử nghiệm thành công.
Phương pháp tiếp cận tăng dần được thực hiện bằng hai Phương pháp khác nhau:
  Từ dưới lên
 Từ trên xuống

Stubs and Drivers

Stubs and Drivers là các chương trình giả trong Kiểm thử tích hợp được sử dụng để hỗ trợ hoạt
động kiểm thử phần mềm.
Các chương trình này đóng vai trò thay thế cho các mô hình còn thiếu trong quá trình thử
nghiệm. Chúng không triển khai toàn bộ logic lập trình của mô-đun phần mềm nhưng chúng mô
phỏng giao tiếp dữ liệu với mô-đun gọi trong khi thử nghiệm.

 Stubs: Được gọi bởi Mô-đun đang được thử nghiệm.

 Driver: Gọi Module để kiểm tra.
Bottom-up Integration Testing
Kiểm tra tích hợp từ dưới lên: Các mô-đun cấp thấp hơn được kiểm tra trước tiên. Các mô-đun
đã thử nghiệm này sau đó được sử dụng tiếp để tạo điều kiện thuận lợi cho việc thử nghiệm
các mô-đun cấp cao hơn. Quá trình tiếp tục cho đến khi tất cả các mô-đun ở cấp cao nhất được
kiểm tra.
Khi các mô-đun cấp thấp hơn được kiểm tra và tích hợp thì cấp độ tiếp theo của các mô-đun sẽ
được hình thành.
Diagrammatic Representation:

Ưu điểm:

 Định vị lỗi dễ dàng hơn.

 Không lãng phí thời gian chờ đợi tất cả các mô-đun được phát triển không giống như
cách tiếp cận Big-bang
Nhược điểm:
  Các mô-đun quan trọng (ở cấp cao nhất của kiến trúc phần mềm) kiểm soát luồng ứng
dụng được kiểm tra lần cuối và có thể dễ bị lỗi.
 Một nguyên mẫu ban đầu là không thể
Top-down Integration Testing
Diễn ra từ trên xuống dưới theo luồng điều khiển của hệ thống phần mềm.
Các mô-đun cấp cao hơn được kiểm tra trước, sau đó các mô-đun cấp thấp hơn được kiểm tra
và tích hợp để kiểm tra chức năng phần mềm. Stubs được sử dụng để thử nghiệm nếu một số
mô-đun chưa sẵn sàng.
Diagrammatic Representation:

Ưu điểm:

 Xác định vị trí lỗi dễ dàng hơn.

 Khả năng có được một nguyên mẫu sớm. Các mô-đun quan trọng được kiểm tra theo
mức độ ưu tiên; những sai sót lớn trong thiết kế có thể được tìm thấy và sửa chữa trước
tiên.
Nhược điểm:

 Cần nhiều Stub.

 Các mô-đun ở mức thấp hơn được kiểm tra không đầy đủ.

Sandwich Testing
Mô-đun cấp cao nhất được thử nghiệm với
các mô-đun cấp thấp hơn, đồng thời các mô-
đun cấp thấp hơn được tích hợp với các mô-
đun cấp cao nhất và được thử nghiệm dưới
dạng hệ thống.
Nó là sự kết hợp giữa phương pháp Top-down và Bottom-up nên được gọi là Kiểm thử tích hợp
lai. Nó sử dụng cả Stubs cũng như Drivers.
How to do Integration Testing?
Quy trình kiểm thử tích hợp bất kể chiến lược kiểm thử phần mềm (đã thảo luận ở trên):
1. Chuẩn bị kế hoạch kiểm thử tích hợp
2. Thiết kế các kịch bản, trường hợp và tập lệnh kiểm thử.
3. Thực hiện các trường hợp thử nghiệm sau đó báo cáo các lỗi.
4. Theo dõi & kiểm tra lại các lỗi.
5. Bước 3 và 4 được lặp lại cho đến khi quá trình Tích hợp thành công.
Brief Description of Integration Test Plans
Nó bao gồm các thuộc tính sau:
Phương pháp/Phương pháp tiếp cận thử nghiệm (như đã thảo luận ở trên).
1. Phạm vi và các hạng mục ngoài phạm vi của Kiểm thử tích hợp.
2. Vai trò và trách nhiệm.
3. Điều kiện tiên quyết để kiểm tra tích hợp.
4. Môi trường thử nghiệm.
5. Kế hoạch rủi ro và giảm thiểu.
Entry and Exit Criteria of Integration Testing – Đầu vào/Đầu ra
Tiêu chí đầu vào và đầu ra cho giai đoạn thử nghiệm tích hợp trong bất kỳ mô hình phát triển
phần mềm nào:

Entry Criteria: Exit Criteria:

 Thành phần/Mô-đun đã được kiểm

tra đơn vị (Unit Tested)
 Tất cả các lỗi có mức độ ưu tiên cao
đã được sửa và đóng (fixed and
closed)
 Tất cả các Mô-đun được hoàn thành
mã (code) và tích hợp thành công
(integrated).
 Integration tests Plan, test case,
scenarios (kịch bản) sẽ được ghi lại.
 Môi trường thử nghiệm bắt buộc phải
được thiết lập để thử nghiệm tích
hợp
 Thử nghiệm thành công ứng dụng tích
hợp.
 Các trường hợp thử nghiệm đã thực
hiện được ghi lại
 Tất cả các lỗi có mức độ ưu tiên cao
đã được sửa và đóng.
 Tài liệu kỹ thuật phải được gửi sau đó
là Ghi chú phát hành. (Technical
documents to be submitted followed
by release Notes)
Best Practices/ Guidelines for Integration Testing
Đầu tiên, xác định Chiến lược kiểm thử tích hợp (Integration Test Strategy) có thể được áp
dụng và sau đó chuẩn bị các Test Case và Test Data phù hợp.

Nghiên cứu thiết kế Kiến trúc của Ứng dụng (Architecture design of the Application) và xác
định các Mô-đun quan trọng. Những điều này cần được ưu tiên kiểm tra.
Nhận các thiết kế giao diện từ nhóm Kiến trúc và tạo các Test case để xác minh chi tiết tất cả
các giao diện. Giao diện với cơ sở dữ liệu/phần cứng/phần mềm phải được kiểm tra chi tiết.
Sau các trường hợp thử nghiệm, dữ liệu thử nghiệm đóng vai trò quan trọng.
Luôn chuẩn bị sẵn dữ liệu mô phỏng trước khi thực hiện. Không chọn dữ liệu thử nghiệm trong
khi thực hiện các trường hợp thử nghiệm.

ACCEPTANCE TESTING - UAT

Kiểm thử chấp nhận người dùng (UAT) là một loại kiểm thử được thực hiện bởi người dùng cuối
hoặc khách hàng để xác minh/chấp nhận hệ thống phần mềm trước khi chuyển ứng dụng phần
mềm sang môi trường sản xuất. UAT được thực hiện trong giai đoạn kiểm thử cuối cùng sau khi
thực hiện kiểm thử chức năng, tích hợp và hệ thống.

Purpose of UAT
Mục đích chính của UAT là xác nhận luồng
kinh doanh từ đầu đến cuối. Nó không tập
trung vào lỗi thẩm mỹ, lỗi chính tả hoặc kiểm
tra hệ thống.
Kiểm thử chấp nhận người dùng được thực
hiện trong một môi trường thử nghiệm riêng
biệt với thiết lập dữ liệu giống như sản xuất.
Đây là loại thử nghiệm hộp đen nơi hai hoặc
nhiều người dùng cuối sẽ tham gia.
Need of User Acceptance Testing
Nhu cầu kiểm thử chấp nhận người dùng phát sinh khi phần mềm đã trải qua kiểm thử đơn vị,
tích hợp và hệ thống vì các nhà phát triển có thể đã xây dựng phần mềm dựa trên tài liệu yêu
cầu bằng sự hiểu biết của chính họ và các thay đổi cần thiết hơn nữa trong quá trình phát triển
có thể không được truyền đạt hiệu quả cho họ, vì vậy để kiểm tra xem sản phẩm cuối cùng có
được khách hàng/người dùng cuối chấp nhận hay không, kiểm thử chấp nhận người dùng là cần
thiết.
Acceptance Testing and V-Model
Trong VModel, AUT tương ứng với giai đoạn
yêu cầu (requirement phase) của Vòng đời
phát triển phần mềm (SDLC).

Prerequisites of User Acceptance Testing –

Điều kiện tiên quyết
 Business Requirements must be
available.
 Application Code should be fully
developed
 Unit Testing, Integration Testing & System Testing should be completed
 No Showstoppers, High, Medium defects in System Integration Test Phase –
 Only Cosmetic error is acceptable before UAT
 Regression Testing should be completed with no major defects
 All the reported defects should be fixed and tested before UAT
 Traceability matrix for all testing should be completed
 UAT Environment must be ready
 Sign off mail or communication from System Testing Team that the system is ready for
UAT execution

How to execute UAT Tests

UAT được thực hiện bởi người dùng dự định của hệ thống hoặc phần mềm. Loại Kiểm thử phần
mềm này thường xảy ra tại vị trí khách hàng được gọi là Thử nghiệm Beta. Sau khi đáp ứng các
tiêu chí đầu vào cho UAT, người kiểm tra cần thực hiện các nhiệm vụ sau:

 Analysis of Business
Requirements
 Creation of UAT test plan
 Identify Test Scenarios
 Create UAT Test Cases
 Preparation of Test
Data(Production like Data)
 Run the Test cases
 Record the Results
 Confirm business objectives
Step 1) Analysis of Business Requirements
Một trong những hoạt động quan trọng nhất trong UAT là xác định và phát triển các kịch bản
thử nghiệm. Các kịch bản thử nghiệm này được lấy từ các tài liệu sau:

 Project Charter
 Business Use Cases
 Process Flow Diagrams
 Business Requirements Document(BRD)
 System Requirements Specification(SRS)

Step 2) Creation of UAT Plan

Kế hoạch kiểm tra UAT phác thảo chiến lược sẽ được sử dụng để xác minh và đảm bảo một ứng
dụng đáp ứng các yêu cầu kinh doanh của nó. Nó ghi lại các tiêu chí vào và ra cho UAT, kịch bản
kiểm thử và cách tiếp cận trường hợp kiểm thử và thời gian thử nghiệm.
Step 3) Identify Test Scenarios and Test Cases
Xác định các kịch bản kiểm thử liên quan đến quy trình kinh doanh cấp cao và tạo các trường
hợp kiểm thử với các bước kiểm thử rõ ràng. Test Cases nên bao gồm đầy đủ hầu hết các kịch
bản UAT. Các trường hợp sử dụng nghiệp vụ là đầu vào để tạo các trường hợp kiểm thử.
Step 4) Preparation of Test Data
Tốt nhất nên sử dụng dữ liệu trực tiếp cho UAT. Dữ liệu nên được xáo trộn vì lý do riêng tư và
bảo mật. Tester nên làm quen với luồng cơ sở dữ liệu.
Step 5) Run and record the results
Thực hiện các trường hợp thử nghiệm và báo cáo lỗi nếu có. Kiểm tra lại lỗi sau khi đã sửa.
Công cụ quản lý kiểm thử có thể được sử dụng để thực hiện.
Step 6) Confirm Business Objectives met
Nhà phân tích kinh doanh hoặc Người kiểm tra UAT cần gửi thư đăng xuất sau khi kiểm tra UAT.
Sau khi ký kết, sản phẩm là tốt để đi sản xuất. Các sản phẩm phân phối cho kiểm thử UAT là
Test Plan, UAT Scenarios và Test Cases, Test Results và Defect Log
Exit criteria for UAT:
 Không có khiếm khuyết nghiêm trọng nào mở
 Quy trình kinh doanh (Business process) hoạt động tốt
 UAT Ký kết cuộc họp với tất cả các bên liên quan
Best Practices
 Chuẩn bị kế hoạch UAT sớm trong vòng đời dự án
 Chuẩn bị checklist trước khi UAT bắt đầu
 Tiến hành phiên Pre-UAT trong giai đoạn Kiểm thử hệ thống
 Đặt kỳ vọng và xác định phạm vi của UAT rõ ràng
 Kiểm tra quy trình kinh doanh từ đầu đến cuối và tránh kiểm tra hệ thống
 Kiểm tra hệ thống hoặc ứng dụng với các kịch bản và dữ liệu trong thế giới thực
 Hãy suy nghĩ như một người dùng không xác định đối với hệ thống
 Thực hiện kiểm tra usability
 Tiến hành Feedback và cuộc họp trước khi chuyển sang sản xuất