Biết được quitrình kiểm tra phần 
mềm
GNGHỆPH GNGHỆPH
HASE
mềm
•Biết được một sốloại test cơbản
MÔN CÔNG MÔN CÔNG
TING P TING P
•Biết được một khái niệm liên quan 
NG NH NG NHẬP M ẬP M
TEST TEST
đến testing
BÀI GIẢN BÀI GIẢN
•Biết được côngviệc, côngcụthường
dùng của Tester
TRẦN NGỌC BẢO TRẦN NGỌC BẢO KHOA TOÁN KHOA TOÁN --TIN HỌC TIN HỌC ĐẠI HỌC SƯPHẠM TP.HCM ĐẠI HỌC SƯPHẠM TP.HCM TRẦN NGỌC BẢO TRẦN NGỌC BẢO KHOA TOÁN KHOA TOÁN --TIN HỌC TIN HỌC ĐẠI HỌC SƯPHẠM TP.HCM ĐẠI HỌC SƯPHẠM TP.HCM 3
dùng của Te
              
                                            
                                
            
 
            
                 44 trang
44 trang | 
Chia sẻ: Mr Hưng | Lượt xem: 1171 | Lượt tải: 0 
              
            Bạn đang xem trước 20 trang nội dung tài liệu Nhập môn công nghệ phần mềm - Giai đoạn kiểm tra (Testing), để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
P
H
H
A
S
E
H
A
S
E • Kiểm tra tất cả các mục khác có cùng chức năng 
trong hệ thống menu (Toolbar, Listbar, Dialog 
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
bar, Context Menu,)
• Kiểm tra cùng một chức năng với nhiều vai trò
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T 
khác nhau (đối với hệ thống có nhiều người 
ù
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
d ng)
• Kiểm tra tất cả các dữ liệu bắt buộc nhập trong 
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM35
các màn hình (hợp lệ/không hợp lệ)
• Vai trò
Tester
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
– Kiểm lỗi phần mềm
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E – Kiểm lỗi bản đóng gói
Kiể lỗi tài liệ
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
– m u
• User guide
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
• Installation Guide
• Release Notes
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
• Troubleshooting
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM36
Công việc
Tester
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
• 
– Chuẩn bị môi trường test
• Windows XP, 2000, 2003
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
• Linux
• IE, FireFox, Netscape, Mozilla
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P • Test Database, Test data
– Viết test case
– Thực hiện test các test case trong từng môi trường
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T 
khác nhau
– Mô tả Bug và chi tiết các bước để tạo ra bug
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
– Theo dõi quá trình Fix Bug
– Báo cáo kết quả test
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM37
• Phần mềm sử dụng
Tester
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
– Web testing
• Test Manager Role
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
• Tester Role
– Manual Test (Rational Manual Test, Test Complete)
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
– Automation Test (Rational Functional Test, Test 
Complete,)
L d t ti
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T – oa es ng
– Code Analysis
Project Management Tool
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N – 
• Tester Role
– Workflow
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM
• Tester role
• Testing Tools
Tài liệu tham khảo
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
– 
– 
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
01.ibm.com/software/awdtools/tester/functional/features/
index.html?S_TACT=105AGX15&S_CMP=LP
– 
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P 01.ibm.com/software/awdtools/test/manager/
• Testing Course
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
– 
– 
htt // f t / d t / i d t t ht l
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
– p: www.appper ec .com pro uc s w n ows es er. m
– 
do
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM39
HẦ
N
M
Ề
M
H
Ầ
N
M
Ề
M
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM40 40
HẦ
N
M
Ề
M
H
Ầ
N
M
Ề
M
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM
HẦ
N
M
Ề
M
H
Ầ
N
M
Ề
M
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM42
• White Box Testing are tests that are run an application with the knowledge 
White Box Testing
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
of the internal working of the code base. White box testing is used in three 
of the six basic types of testing: unit, integration, and regression testing. 
Unit testing is done on a small piece, or unit, of code. This unit is usually a 
class. When a unit is integrated into the main code base, it is more difficult 
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
to find a bug in that unit. Integration testing looks at how all components 
of an application interact. White box integration tests specifically look at 
the interfaces between the components. Regression testing verifies that 
modifications to the system have not damaged the whole of the system. 
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
Unit tests and integration tests can be rerun in regression testing to verify 
that modifications to the application work properly.
• White box test cases should test different paths, decision points (both true 
and false decisions), execute loops, and check internal data structures of
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T
the application. Basis path testing, equivalence partitioning, and boundary 
value analysis are all used to create white box tests. Basis path testing 
looks at the decision points in the application. Equivalence partitioning 
divides the set of possible input values into equivalence classes. Only a
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
value from each of the equivalence classes needs to be tested. Boundary 
value analysis looks at testing around a set boundary. A test case should be 
made for the boundary value, n, n-1, and n+1.
• The goal of white box testing is to cover testing as many of the statements
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM43
 , 
decision point, and branches in the code base as possible. 
• Black Box Testing treats an application as a black box and only looks at the 
Black Box Testing
H
Ầ
N
M
Ề
M
H
Ầ
N
M
Ề
M
outputs that are produced by specific inputs into the application. The black box 
tester does not need to understand why the code does what it does, and they 
should not have access to the source code of the application. Requirements are 
used to determine the correct outputs of black box testing, and these test cases 
d t lid t th t th i ht ft i b i b ilt i th t th
G
N
G
H
Ệ
P
H
G
N
G
H
Ệ
P
H
H
A
S
E
H
A
S
E
are use o va a e a e r g so ware s e ng u , .e. a e 
application does what the requirements say.
• Black box testing checks that required functionality exists and is correct, the 
interface works properly, data structures behind the interface work properly, the 
behavior and performance of the system are within proper bounds and that the
M
Ô
N
C
Ô
N
G
M
Ô
N
C
Ô
N
G
T
I
N
G
P
T
I
N
G
P
 , 
initialization and termination of the program are correct. Integration, functional 
and system, acceptance, beta, and regression testing all are forms of black box 
tests. 
• A minimal black box test suite should have one test case for every requirement
N
G
N
H
N
G
N
H
Ậ
P
M
Ậ
P
M
T
E
S
T
T
E
S
T 
of the application. To optimize testing beyond this minimal set of tests 
equivalence partitioning, boundary value analysis, decision tables, and diabolical 
test cases should be created. Equivalence partitioning divides the set of possible 
input values into equivalence classes. Only a value from each of the equivalence
B
À
I
G
I
Ả
N
B
À
I
G
I
Ả
N
classes needs to be tested. Boundary value analysis looks at testing around a set 
boundary. A test case should be made for the boundary value, n, n-1, and n+1. 
Decision tables looks at all decision points in the program and looks at the 
results of all decision paths in the scenario. Finally, diabolic tests investigate 
TRẦN NGỌC BẢO  KHOA TOÁN -TIN HỌC  ĐẠI HỌC SƯ PHẠM TP.HCM44
extreme use of the application. 
            Các file đính kèm theo tài liệu này:
 se_testing_6839_6222.pdf se_testing_6839_6222.pdf