4 Chapter04 Software Testing

Chương 4:
Kiểm thử phần mềm

(Software testing)
Nội dung chính
 4.1 Kiểm thử - giới thiệu

 4.2 Các mức độ kiểm thử
 4.3 Các chiến lược kiểm thử
 4.4 Phân loại kiểm thử
 4.5 Quá trình kiểm thử
 4.6 Phần mềm phục vụ kiểm thử
4.1 Kiểm thử - giới thiệu
 Kiểm thử - Tầm quan trọng

 Các ví dụ:
 Vụ thất bại của tên lửa Patriot (xảy ra tại trận chiến
vùng vịnh Dharan, Saudi Arabia, 25/2/ 1991; do mất
quyền kiểm soát, làm chết 28 ngườii thương 100 người)
=> do không phát hiện lỗi làm tròn (rounding error)
 Vụ phát nổ tên lửa Ariane 5 (do Cơ quan Vũ trụ Châu
Âu phóng lên tại Kourou, Guiana thuộc Pháp đã phát nổ
khi cất cánh chỉ sau bốn mươi giây → thiệt hại 500 triệu
USD, nguyên nhân do không phát hiện lỗi tràn số.
 Khái niệm kiểm thử:

 Theo Myers’ (1979):
 “Testing is the process of executing a program with intention of finding errors.”
 Mục đích chính của kiểm thử

 Bắt được nhiều nhất lỗi có thể (độ bao trùm cao) với kinh phí thấp nhất
 Thẩm định phần mềm đã đáp ứng các yêu cầu đặt ra
 Yêu cầu chức năng,
 Yêu cầu phi chức năng
=> Kiểm thử luôn gắn kèm với gỡ rỗi. Kiểm thử thành công ~ phần mềm vận hành đúng
như mong đợi.
 Nguồn gốc lỗi:

 Đặc tả (Specification): đặc tả lỗi, không đầy đủ, không
nhất quán.
 Thiết kế (Design): lỗi cơ bản trong thiết kế phần mềm.
 Cài đặt (Code): lỗi lập trình, mã độc (malicious code).
 Khác:
 Hệ thống hỗ trợ: Ngôn ngữ lập trình nghèo nàn, trình
biên dịch có lỗi...
 Kiểm thử không đầy đủ: kiểm thử chưa xong, kiểm
chứng nghèo nàn,...
Nội dung chính

 4.2 Các cấp độ kiểm thử
 4.3 Các chiến lược kiểm thử
4.2 Các mức độ kiểm thử
 Mô hình chữ V
 Kiểm thử đơn vị →
kiểm thử chấp thuận
a. Kiểm thử đơn vị - Unit Testing
 ~ Áp dụng trên các mô đun riêng lẻ (các hàm, lớp, thủ tục, phương thức, ...)
 Thực hiện bởi Lập trình viên (không phải kiểm thử viên)
 Có thể áp dụng kỹ thuật kiểm thử hộp đen và hộp trắng.
b. Kiểm thử tích hợp - Integration Testing
 Mục đích:
 Tích hợp các thành phần &
 Phát hiện lỗi giao tiếp xảy ra giữa các thành phần trong/sau khi tích hợp
 Các chiến lược kiểm thử tích hợp?
b. Kiểm thử tích hợp - Integration Testing
 Kiểm thử tích hợp: 2 chiến lược chính:

1. Big bang testing,
2. Tích hơp và kiểm thử tăng dần:
 Bottom-up: The lowest level modules are tested first, with the main module tested last.
 Top-down: the main module (the highest level module in the software structure) is tested
first, the last modules to be tested are the lowest level modules.
Þ Figure 9.1 illustrates top-down and bottom-up testing of a software composed of 11 modules
 See Figure 9.1 (below)
c. Kiểm thử hệ thống - System Testing
 Mục đích:
 Đánh giá phần mềm (sau khi tích hợp/đóng gói)
 Các hình thức test hệ thống:
1. Kiểm thử chức năng (Functional Test)
2. Kiểm thử hiệu năng (Performance Test)
3. Kiểm thử sức căng (stress testing)
4. Kiểm thử khả năng phục hồi (Recovery Test)
5. Kiểm thử quá tải (overload testing)
6. ...
d. Kiểm thử chấp nhận - Acceptance Testing
 Mục tiêu:
 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ấp
nhận sản phẩm.
 Khách hàng thực hiện (hoặc ủy quyền cho bên thứ ba thực hiện – vd: QA).
d. Kiểm thử chấp nhận - Acceptance Testing
 2 loại test chấp thuận:

 Alpha Test:
 Người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận
các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.
 Beta Test:
 Phần mềm sẽ vận hành trên môi trường sản phẩm (môi trường người dùng cuối), người dùng
phản hồi các lỗi phát hiện để lập trình viên sửa chữa.
Nội dung chính

 4.3 Phân loại kiểm thử theo cách tiếp cận hộp
4.4 Phân loại kiểm thử theo cách tiếp cận hộp
4.4.1 Kiểm thử hộp trắng – Apply?
 From Table 9.1, White box testing can be applied for:

1. Data processing and calculations correctness tests
 By run test cases (“paths”).
2. Software qualification tests

 ~ Examination of software code (including comments) compliance with coding standards
and work instructions.
3. Maintainability tests
 ~ Detect failures caused by modules that supports software adaptations and software
improvements, ...
4. Reusability tests
 Examine the software/components that can be reusable for future software packages.
4.4.1 Kiểm thử hộp trắng – Evaluate?
 White box testing - Evaluation: 2 criteria:

 “Path coverage”: phủ mọi lộ trình
 “Line coverage”: phủ mọi cung.
i. Path coverage
 Path coverage of a test is measured by the percentage of all possible program

paths included in planned testing.
 Different paths in a software module are created by the choice in conditional
statements, such as IF–THEN–ELSE or DO WHILE or DO UNTIL
 Need testing all its possible paths, but it can’s because there are a vast of paths
 See Example (below)
i. Path coverage
 Examples of a vast of paths:

 Example 1:
 A module containing 10 conditional statements, each allowing for only two options (e.g., IF–
THEN–ALSO or DO WHILE).
=> Contains 2^10= 1024 different paths => to obtain full path coverage for this module (probably
25–50 lines of code) one should prepare at least 1024 test cases, one for each possible path.
 Example 3:
 A software package contains 100 modules => The number of test cases: 102 400 test cases,
very vast of paths !!! => An alternative weaker coverage concept – line coverage.
The line coverage requires far fewer test cases but leaves most of the possible paths untested.
ii. Line coverage
 Line coverage:
 Measure the percentage of program code lines indeed executed
 A full line coverage: requires every line of code be executed at least once during the process
of testing (~ basic path testing of a program)
 Example: Line & path coverage
 Xét Mô đun tính giá vé cho dịch vụ taxi nội thành: ITS - The Imperial Taxi Services taximeter
Example – ITS
 ITS: Serves one-time passengers & regular clients (identified by a taxi card).
 For one-time passengers are calculated as follows:
1. Minimal fare: $2. This fare covers the distance traveled up to 1000 yards and waiting time
(stopping for traffic lights or traffic jams, etc.) of up to 3 minutes.
2. For every additional 250 yards or part of it: 25 cents.
3. For every additional 2 minutes of stopping or waiting or part thereof: 20 cents.
4. One suitcase: 0 change; each additional suitcase: $1.
5. Night supplement: 25%, effective for journeys between 21.00 and 06.00 Regular clients
are entitled to a 10% discount and are not charged the night supplement.
Example – ITS
 ITS - The flow chart &

program flow graph:
 See Fig 9.3
 Each figure
represents a
calculation process
that includes five
decisions (above).
Example – ITS
1. Full path coverage: phủ mọi lộ trình

 Requires that all the possible paths be executed at least once.
 From the ITS flow chart (Figure 9.3) → Need 2^4+8=24 different paths (~ at
least 24 test cases) to achieve full path coverage (see Table 9.3 (below))
1
Charge the minimal fare
D > 1000 D ≤ 1000

2
3 Distance 4
WT > 3 WT ≤ 3
5
6 Waiting time 7
S >1 8 S≤1
9 No.of suitcases 10
Yes 11 No
12 Regular 13
client?
14
Night
Yes journey? No
15
16
17
Print receipt.
Example – the Imperial Taxi Services (ITS)
taximeter
2. Full line coverage: phủ mọi cung

 From the program flow graph → the 1
minimum number of paths – a total of
three – as listed in Table 9.4. 2
R1 4
3
5
R2 7
6
8
R6
9 R3 10
11
12 13
R4 14
15
R5 16
17
Example – the Imperial Taxi Services (ITS)
taximeter
 Test cases required by full line coverage (basic path testing) versus full path
coverage is 3:24 = 1:8!
 This ratio grows rapidly with program complexity.
 McCabe’s cyclomatic /chu kỳ complexity metrics: Support for the basic path testing
strategy by:
 Providing the software complexity metrics &
 Giving an upper limit to the number of test cases needed for full line coverage.
=> McCabe’s cyclomatic complexity metrics?
McCabe’s cyclomatic complexity metrics
 Developed by McCabe (1976)

 Goals:
1. Measures the complexity of a program or module/testability
2. Determines the maximum number of independent paths needed to achieve full
line coverage of the program.
 An independent path: “Any path on the program flow graph that includes at least one
edge that is not included in any of the former independent paths”
1) Determines the maximum number of independent paths needed to achieve

full line coverage of the program – V(G)
 V(G) is expressed in three different ways:
1. V(G) = R
2. V(G) = E – N + 2
3. V(G) = P + 1
 Trong đó:
 R is the number of regions in G (vùng ~ vùng đóng của G & 1 vùng bao quanh G (vùng bổ
sung)
 E: Số cạnh của G; N: số nút của G; P: số quyết định của G (số node có >1 cung đi ra)
 Ví dụ: Xét mô đun tính giá vé taxi (below)
1) Tính (V(G))=?
 Ví dụ: Xét mô đun tính giá vé taxi (ITS):
1
ta có:
 R=6; E=21; N=17; P=5 2
R1 4
Þ Thay vào công tính tính V(G): 3
5
 (1) V(G) = R = 6
R2 7
6
 (2) V(G) = E – N + 2 = 21 – 17 + 2 = 6
8
 (3) V(G) = P + 1 = 5 + 1 = 6 R6
9 R3 10
11
=> maximal set of six independent paths is
12 13
shown in Table 9.6.
R4 14
15
R5 16
17
1
2
R1 4
3
5
R2 7
6
8
R6
9 R3 10
11
12 13
R4 14
15
R5 16
17
=> V(G) - The upper limit to the number of test cases needed for
full line coverage
2) Measures the complexity of a program or module

 From V(G) → the quality &testability characteristics of the modun/program:
 Nếu V(G) <5: Chương trình/mô đun là đơn giản & dễ hiểu
 Nếu V(G) ≤ 10: Chương trình/mô đun không quá khó
 Nếu V(G) ≥ 20: Chương trình/mô đun có độ phức tạp cao
 Nếu V(G) >50: Chương trình/mô đun không thể test
4.4.1 Kiểm thử hộp trắng – Discussion?
 SV thực hành:
1. Measures the complexity (the quality &testability characteristics) of a program or
module apply McCabe’s cyclomatic complexity metrics
2. Sử dụng công cụ để đánh giá độ bao phủ dòng code (line coverage) của các test case
đã thiết kế
 Ví dụ: Sử dụng JUnit để test đơn vị & một số công cụ tìm code bugs, đánh giá độ báo
phủ code &tính hiệu quả của các test case đã thiết kế
 See (below)
4.4.1 Kiểm thử hộp trắng – Examples
 Các ví dụ:
a. Unit Test: Maven + Junit:
b. Đánh giá độ bao phủ code (Code Coverage) và tính hiệu quả
(effectiveness) của các test case
 Maven – JaCoCo code coverage example
 Maven – PITest mutation testing example
c. Phân tích mã nguồn tĩnh (Static Code Analysis) để tìm code bugs
 Maven – SpotBugs example
 Maven – PMD example
a. Unit Test: Maven + Junit:
 Example: xét dự án Java: maven-unit-test
 Run:
$ git clone https://github.com/mkyong/maven-examples.git
$ cd maven-examples/maven-unit-test
$ mvn test
a. Unit Test: Maven + Junit

b. Code Coverage
c. Static Code Analysis

b. Code Coverage: Maven + Code coverage
report integration.
 Maven – JaCoCo code coverage
 JaCoCo Maven plugin is used to measure how many code lines are tested (the code
coverage ) for a Java project
 How to use it?
=> Steps:
Maven – JaCoCo code coverage
 Step1: Khai báo JaCoCo plugin

trong file POM:
 See Fig
 More details: See here
=> It will run the JaCoCo ‘report’

goal during the Maven test phase.
 Step 2. Unit Test

 Create a simple Java code:
 See: beside
 More details:
 See here
 Step 2. Unit Test

 Create a Unit test for
above class
 See Fig
 More details:
 See here
 Step 3. Run:
 cd maven-code-coverage
 mvn clean test
=> JaCoCo code coverage report will be generated at target/site/jacoco/*
 Open target/site/jacoco/index.html file, to see results:
Results:
• Green – Code is tested or covered.
• Red – Code is not tested or covered.
• Yellow – Code is partially tested or covered.
 Step 4: Improving the Unit Test

 Adding one more test for the red line:
 Review the report again: mvn clean test

Þ result: index.html
Þ See Fig (below):
Yellow – Code is
partially tested or
covered.
 Add one more test for the yellow line:
 Review the report again: mvn clean test

 Results:
 See Fig (below):
Test cases bao
phủ toàn bộ các
nhánh và các
lệnh (100%
coverage)

b. Code Coverage
c. Static Code Analysis (for finding bugs in code)

b. Code Coverage: Maven + Code
coverage report integration.
 The mutation testing is used to measure the effectiveness of the test.
 It use mutators (switching math operators, change the return type, remove call and etc) to mutate /
change the code into different mutations (create new code based on mutators ~ virus), and
check if the unit test will fail for the new mutations (mutation is killed - virus is detected).
 The effectiveness of the tests is measured by “how many mutations are killed”.
b. Code Coverage: Maven + Code coverage
report integration.
 Maven PIT mutation testing plugin
 Measure the effectiveness of the test &to generate a mutation test coverage report for a
Java project?
 ≠ JaCoCo: just measures the tested/covered code line.
<plugin>
<groupId>org.pitest</groupId>
PITest mutation
<artifactId>pitest-maven</artifactId>
<version>1.4.3</version>
testing <executions>
<execution>
<id>pit-report</id>

<phase>test</phase>
<goals>
 To enable PIT mutation <goal>mutationCoverage</goal>
</goals>
testing, put pitest-maven in </execution>
POM file: </executions>
 See the POM file (below): 


 POM file (more details: <dependencies>
<dependency>
see here) <groupId>org.pitest</groupId>
<artifactId>pitest-junit5-plugin</artifactId>
<version>0.8</version>
</dependency>
</dependencies>
<configuration>
<targetClasses>
<param>com.mkyong.examples.*</param>
</targetClasses>
<targetTests>
<param>com.mkyong.examples.*</param>
</targetTests>
</configuration>
</plugin>
Maven – PITest mutation testing
 Run the PITest:
 $ mvn clean test
Þ Results: Report will be generated at: /target/pit-reports/202010021010/*
Þ View results by open the index.htlm
->Maven – PITest mutation testing
 Examples: this code:
public boolean isPositive(int number) {

boolean result = false;
if (number >= 0) {
result = true;
}
return result;
}
 By default, PITest will use different mutators to transform the above code into different mutations (new
code) :
 See (below):
#1 Mutation – Changed conditional boundary (mutator)
Code after
public boolean isPositive(int number) { changing
if (number > 0) {// mutator - changed conditional boundary
result = true;
}
return result; if (number >= 0) {
} result = true;
}
return result;
#2 Mutation – Negated conditional (mutator) }

Old
if (false) { // mutator - negated conditional code
result = true;
}
return result;
}
#3 Mutation – Replaced return of integer sized value with (x == 0 ? 1 : 0) (mutator)

if (number > 0) {
result = true;
}
return !result; // mutator - (x == 0 ? 1 : 0)
}
 A Good unit test:

 Should fail (kill) all the mutations #1,#2,#3
@Test
public void testPositive() {
CalculatorService obj = new CalculatorService();
assertEquals(true, obj.isPositive(10));
}
=> This unit test will kill the mutation #2 and #3 (unit test is failed), but the mutation #1 is
survived (unit test is passed)
 Run the PITest:

$mvn clean test
=> Results:
 To fail (kill) this test (mutation)

Þ We need improving the unit test by testing the number zero:
@Test
public void testPositive() {
CalculatorService obj = new CalculatorService();
//kill mutation #1
}
=> Result of run: $mvn clean test

 See index.htlm file => Fig (below)

 How to run unit test with Maven
b. Code Coverage

c. Static Code Analysis: Maven + Static code
analysis report
 Static Code Analysis: to find code bugs
 Bugs ? ~ coding mistakes
 Bug Categories:
1. Correctness: lỗi code xuất hiện → mã nguồn không như ý developers
2. Bad practice: vi phạm các khuyến cáo viết mã/practice tồi
3. Performance: các vấn đề về lỗi thực thi, hiệu năng
4. Multithreaded correctness: xử lý bất đồng bộ & các vấn đề trong môi trường đa luồng.
5. Internationalization: các vấn đề liên quan đến áp dụng chuẩn quốc tế hóa (internationalization).
6. Malicious code vulnerability: Lỗ hổng mã độc hại
7. Security: các lỗi bảo mật liên quan đến giao thức (protocols), SQL Injection, …
8. Dodgy (phong cách): mã khó hiểu, bất thường, mập mờ hoặc được viết theo cách tự dẫn đến lỗi
9. ..
analysis report
 Static Code Analysis: tools?
 Example: Findbugs & spotBugs, codacy, ...
 See link on GitHUb: review code
 https://github.com/marketplace/category/code-review
 SpotBugs (for Java): can detect >400 bug patterns (Java, Spotbugs tool)
=> See link:
 https://spotbugs.readthedocs.io/en/latest/bugDescriptions.html
 How to use SpotBugs -Maven -Pluginto find bugs in Java code?

Þ Steps?
Maven – SpotBugs
 Step 1: Define the spotbugs-maven-plugin in the reporting tag of

the POM.xlm file:
<reporting>
<plugins>
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
 More details: See here

 Step 2: Run: mvn compile site
=> The SpotBugs report: will be generated
Maven – SpotBugs
 Example:
 A simple Java code with:
 An unused field ‘abc’ &
 A performance issue in the “+ string” loop.
Þ SpotBugs will detect it & showing it on the report
Þ See Java code:
Fig (below):
package com.mkyong.examples;
public class StaticCodeExample {
private int abc; //Unused field
private String ip = "127.0.0.1";
public void test() {
String[] field = {"a", "b", "c", "s", "e"};
// nối các strings sử dụng dấu “+” trong vòng lặp

String s = "";
for (int i = 0; i < field.length; ++i) {
s = s + field[i];
}
System.out.println(ip);
}
}
Maven – SpotBugs
 Run: $ mvn compile site

 SpotBugs report will be generated and integrated into the Maven site automatically
 Review the report at target/site/soptbugs.html

 How to run unit test with Maven
b. Code Coverage

analysis report
 Maven – PMD example
 How to use Maven PMD Plugin to analyze the Java code and display the issues in a
report?
 Steps:
 Step1: Define the maven-pmd-plugin in the reporting tag:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
</plugin>
</plugins>
</reporting>
Maven – PMD example
 Steps:
 Step 2: Run: mvn compile site
Þ The PMD report will be generated and integrated into the Maven site automatically
 Review the report at target/site/pmd.html
 Example: java code (above)
=> Result: Fig 2 (below)

analysis report
 List of tools for static code analysis
 For various program languages
 See Fig (below)
 More details:
 See link:
 https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Java
 List of more 400 bug pattern used by SpotBugs: see link:
 https://spotbugs.readthedocs.io/en/latest/bugDescriptions.html
4.4.2 Kiểm thử hộp đen – Apply?
 Allows us to perform output

correctness tests and most classes of
tests as shown in Table 9.2 (below)
Từ Bảng 9.2 => Kiếm thử hộp trắng chỉ đảm nhiệm một phần nhỏ trong các nhiệm vụ test (ở trên), hầu hết các test đều là
hộp đen → Tầm quan trọng của kiểm thử hộp đen.
4.4.2 Kiểm thử hộp đen – Example?
 Example:
 Black box of testing the output
correctness using Equivalence
classes partitioning (EC)?
Equivalence classes partitioning (EC) for
output correctness tests
 EC:
 is based on software specification documentation, not on the code.
 A Equivalence class: set of input variable values that produce the same output results
 An EC that contains only valid states is defined as a "valid EC," whereas an EC that contains only
invalid states is defined as the "invalid EC."
 In cases where a program's input is provided by several variables, valid and invalid ECs should be
defined for each variable.
Equivalence classes for output correctness
tests
 Example 1:
Equivalence classes (EC) for output
correctness tests
 Example 2 – the Golden Splash Swimming Center
 Aim: calculates entrance ticket prices for the Golden Splash Swimming Center. The
Center’s ticket price depends on four variables:
1) day (weekday, weekend),
2) visitor’s status (OT = one time, M = member),
3) entry hour (6.00–19.00, 19.01–24.00), and
4) visitor’s age (up to 16, 16.01–60, 60.01–120).
Þ The entrance ticket price table is shown in Table 9.7 (below).
Þ The equivalence classes and the corresponding test case values (EC: weak) are
presented in Tables 9.8 and 9.9.
Þ A total of 15 test cases cover all the defined ECs.
Þ EC: is applied mainly with correctness tests, but it may be used for testing revision & transition factors.
Nội dung chính

 4.3 Các chiến lược kiểm thử tích hợp
 4.5 Tiến trình kiểm thử
4.5 Tiến trình kiểm thử
 Tiến trình kiểm thử chung:

 Tùy vào từng tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro của phần mềm mà quy trình
kiểm thử phần mềm có thể gồm nhiều bước khác nhau.
từ FPT
4.5 Quá trình kiểm thử
1. Lập kế hoạch test: cần 2. Chuẩn bị test: 4. Báo cáo và phân tích
x.định rõ:  Tìm hiểu nghiệp vụ của hệ thống dữ liệu kiểm thử:
phải kiểm thử.
 Các giai đoạn kiểm thử áp  Lập báo cáo kiểm thử.
 Xây dựng kịch bản kiểm thử.
dụng cho dự án phần mềm.  Phân tích nguyên
 Chuẩn bị dữ liệu kiểm thử. nhân và đề xuất các
 Các phương pháp kiểm thử. hành động khắc phục.
 Xem xét phê duyệt các tài liệu kiểm
 Các công cụ kiểm thử. thử.
 Nguồn lực kiểm thử. 3. Thực thi test:
 Môi trường kiểm thử bao  Thực hiện kiểm thử dựa trên các
gồm tài nguyên phần cứng kịch bản kiểm thử, test case, thủ tục,
và phần mềm. dữ liệu có sẵn từ bước chuẩn bị kiểm
thử.
 Mốc bàn giao các tài liệu  Thực hiện quá trình quản lí lỗi: báo
kiểm thử. lỗi, sửa lỗi.
4.5 Tiến trình kiểm thử
 Một số mẫu biểu test – Templates

 Test Plan
 Test Evaluation Summary
 Ví dụ: SCR project
 Test artifacts:
 Test Plan for iteration E1
 Test Results E1
 Test Plan for iteration C2_C3
 Test Results C2
 Comparison of automated & manual testing by phase:
Testing process phase Automated testing Manual testing
Test planning M M
Test design M M
Preparing test cases M M
Performance of the tests A M
Preparing the test log and test reports A M
Regression tests A M
Preparing the tests log & test reports M M
Test planning M M
Test design A M
M = phase performed manually, A= phase performed

automatically
Nội dung chính

 4.3 Các chiến lược kiểm thử tích hợp
4.6 Phần mềm phục vụ kiểm thử
 Các phần mềm phục vụ kiểm thử là các phần mềm được sử dụng trong suốt quá
trình kiểm thử:
 Từ giai đoạn lên kế hoạch kiểm thử → giai đoạn tổng hợp báo cáo kết quả kiểm thử.
 Dựa vào mục đích sử dụng → phần mềm phục vụ kiểm thử chia thành 3 nhóm chính:
1. Phần mềm hỗ trợ viết tài liệu:
2. Phần mềm quản lý lỗi
3. Công cụ kiểm thử tự động.
i. Phần mềm hỗ trợ viết tài liệu
 Vi dụ: Các bộ soạn thảo thông dụng:

 Microsoft Office Word.
 Microsoft Office Exel.
 Microsoft Office Project.
 Microsoft Office Power Point.
=> Dùng để lập kế hoạch test.
ii. Phần mềm quản lý lỗi
 CSDL lưu trữ các thông tin về lỗi được phát hiện như:
 Thời gian phát hiện lỗi
 Mức độ nghiêm trọng của lỗi
 Các khắc phục lỗi, ...
 Ví dụ:
 Bugzilla (http://www.bugzilla.org/)
 Redmine (phần mềm nguồn mở, http://www.redmine.org/),
 Atlassian JIRA (http://www.atlassian.com)
 ...
iii. Công cụ kiểm thử tự động
 Mỗi test tool hỗ trợ một khía cạnh test riêng → Phân loại theo mục đích sử dụng
gồm:
1) Unit Testing Tools
2) Regression Testing Tools,
3) Functional Testing Tools,
4) Performance Testing Tools,
5) …
1) Unit Testing Tools
 JUnit.
 Jtest
 Kiểm thử ứng dụng Java:
 kiểm tra mức đơn vị, phân tích tĩnh, kiểm tra hồi quy, phát hiện lỗi thời gian chạy, và xem
xét mã, ...
 link: http://www.parasoft.com
 Sonar:
 Nền tảng quản lý chất lượng nguồn mở Java, dành riêng cho liên tục phân tích và đo
lường chất lượng mã nguồn
 link: http://www.sonatype.com/
...
2) Regression Testing Tools
 Selenium IDE.
 SilkTest:
 Link: http://www.borland.com/products/silktest/
 QA WIZARD:
 Áp dụng các ứng dụng Web và các ứng dụng Windows
 Link: http://www.qawizard.com/
 ...
3) Functional Testing Tools
 Selenium HQ.
 ActiWATE:
 Mô phỏng hành động dựa trên Brower, tạo ra các kịch bản dựa trên hành động / kết
quả.
 Hỗ trợ HTTP, HTTPS & Ajax.
....
4) Performance Testing Tools
 Hỗ trợ:
 Load testing; Volume testing, Stress testing, performance testing, reliability testing
 Các công cụ:
 Loadrunner;
 Pylot,
 Apache JMeter,
 ...
5) Các nhóm test tools tự động khác
 Công cụ quản lý sự cố – Incident Management Tools.

 Công cụ quản lý cấu hình – Configuration Management Tools.
 Công cụ bảo hiểm đo lường – Coverage Measurement Tools.
 Công cụ giám sát – Monitoring Tools.
 Công cụ kiểm thử cơ sở dữ liệu – Database Testing Tools.
 Công cụ kiểm thử bảo mật – Security Testing Tools.
 Công cụ kiểm thử tĩnh – Static Testing Tools.
Tổng kết chương

4.2 Các mức độ kiểm thử
4.3 Các chiến lược kiểm thử tích hợp
4.4 Phân loại kiểm thử
4.6 Phần mềm phục vụ kiểm thử

4 Chapter04 Software Testing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4 Chapter04 Software Testing

Uploaded by

Copyright:

Available Formats

Chương 4:

Kiểm thử phần mềm

 4.1 Kiểm thử - giới thiệu

 Kiểm thử - Tầm quan trọng

 Khái niệm kiểm thử:

 Mục đích chính của kiểm thử

 Nguồn gốc lỗi:

 4.1 Kiểm thử - giới thiệu

 Kiểm thử tích hợp: 2 chiến lược chính:

 2 loại test chấp thuận:

 4.1 Kiểm thử - giới thiệu

 From Table 9.1, White box testing can be applied for:

2. Software qualification tests

 White box testing - Evaluation: 2 criteria:

 Path coverage of a test is measured by the percentage of all possible program

 Examples of a vast of paths:

 ITS - The flow chart &

1. Full path coverage: phủ mọi lộ trình

D > 1000 D ≤ 1000

2. Full line coverage: phủ mọi cung

 Developed by McCabe (1976)

1) Determines the maximum number of independent paths needed to achieve

2) Measures the complexity of a program or module

a. Unit Test: Maven + Junit

c. Static Code Analysis

 Step1: Khai báo JaCoCo plugin

=> It will run the JaCoCo ‘report’

 Step 2. Unit Test

 Step 2. Unit Test

 Step 4: Improving the Unit Test

 Review the report again: mvn clean test

 Add one more test for the yellow line:

 Review the report again: mvn clean test

a. Unit Test: Maven + Junit

c. Static Code Analysis (for finding bugs in code)

 See the POM file (below):

 Examples: this code:

public boolean isPositive(int number) {

public boolean isPositive(int number) {

#3 Mutation – Replaced return of integer sized value with (x == 0 ? 1 : 0) (mutator)

 A Good unit test:

 Run the PITest:

 To fail (kill) this test (mutation)

=> Result of run: $mvn clean test

a. Unit Test: Maven + Junit

c. Static Code Analysis (for finding bugs in code)

 How to use SpotBugs -Maven -Pluginto find bugs in Java code?

 Step 1: Define the spotbugs-maven-plugin in the reporting tag of

 More details: See here

public class StaticCodeExample {

private int abc; //Unused field

private String ip = "127.0.0.1";

public void test() {

String[] field = {"a", "b", "c", "s", "e"};

// nối các strings sử dụng dấu “+” trong vòng lặp

 Run: $ mvn compile site

a. Unit Test: Maven + Junit

c. Static Code Analysis (for finding bugs in code)

=> Result: Fig 2 (below)

 Allows us to perform output

 4.1 Kiểm thử - giới thiệu

 Tiến trình kiểm thử chung:

 Một số mẫu biểu test – Templates

M = phase performed manually, A= phase performed