Nhập môn Công nghệ phần mềm: Chương 2 - Lương Trần Hy Hiến

Kiểm
Kiểm thử
thử Phần
Phần mềm
mềm –– Software
Software Testing
Testing

Chương 2: Các khái niệm cơ bản trong kiểm thử Phần
mềm

Lương Trần Hy Hiến, Khoa CNTT, ĐH Sư phạm TpHCM

1


Nội dung
2.1. Quy trình kiểm tra phần mềm
2.2. Kế hoạch kiểm tra (Test plan)
2.3. Tình huống kiểm tra (Test case)
2.4. Dữ liệu kiểm tra (Test Data)
2.5. Lỗi (Bug)
2.6. Báo cáo kiểm tra (Test Report)
2.7. Các vai trò


2.1 Qui trình kiểm thử PM

•

Kiểm thử thành phần

–
–
–

•

Kiểm thử của các từng thành phần chương trình;
Thường là trách nhiệm của lập trình viên tạo ra thành phần đó;
Các test được tạo ra từ kinh nghiệm của lập trình viên.

Kiểm thử hệ thống

–
–
–

Kiểm thử một nhóm các thành phần được kết hợp lại để tại ra hệ thống hay hệ thống con;
Trách nhiệm của một đội test độc lập;
Các test được tạo ra dựa trên bản đặc tả hệ thống.


2.1 Qui trình kiểm thử PM
Bắt đầu

Lập
Lập kế
kế

Phân

Phân tích,
tích,

Chuẩn
Chuẩn bị
bị dữ
dữ

Chạy
Chạy ứng
ứng dụng
dụng

hoạch
hoạch test
test

Thiết
Thiết kế
kế test
test

liệu
liệu test
test

với
với bộ
bộ dữ
dữ liệu

liệu test
test

Test Data/S
Test plan

Test Case

Test Results

So
So sánh
sánh kết
kết quả
quả
Kết thúc

Test Report

test
test với
với test
test case
case


2.2. Kế hoạch kiểm tra (Test plan)

•

Cấu trúc chung của một test plan

–
–
–
–
–
–
–
–

Tên project
Danh sách các Module cần test
Ngày bắt đầu, ngày kết thúc
Danh sách các Test case
Nhân sự tham gia
Tài nguyên sử dụng (Servers, Workstations, Printers,…)
Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch)
…


2.3. Tình huống kiểm tra (Test case)

•

Cấu trúc chung của một test case:

–
–
–

–
–
–
–
–
–
–

Tên project, module
Màn hình, chức năng
Mã số
Tài liệu tham khảo (SRS)
Mục đích
Dữ liệu test
Mơ tả các bước (Test step)
Trạng thái
Ngày tạo
…


Test case

•

Ví dụ: kiểm tra màn hình đăng nhập


Test case

•

Ví dụ: kiểm tra màn hình đăng nhập

– Project: Web testing application
– Module: Testing
– Màn hình: Đăng nhập hệ thống
– Chức năng: đăng nhập
– Mã số: TC001
– Dữ liệu test
•
•

Username = “hienlth”, pass = “123456”
Username = “admin”, pass = “admin”

– Các bước thực hiện kiểm tra


Test case – Test step
Step

Steps

Data

Expected result

no
1

results
Nhập Username và ấn nút OK

Username = “hienlth”

Hiển thị thơng báo “Vui lịng nhập username
và password”

2

Nhập Password và ấn nút OK

Password = “123456”

Hiển thị thông báo “Vui lòng nhập username
và password”

3

4

5

6

7

8

…

Actual

Nhập Username , password và ấn

Username = “hienlth”

Hiển thị thông báo “Username và password

nút OK

Password = “abc”

không hợp lệ”

Nhập Username , password và ấn

Username = “abc”

Hiển thị thông báo “Username và password

nút OK

Password = “hienlth”

không hợp lệ”

Nhập Username, password và ấn

Username = “abc”

Hiển thị thông báo “Username và password

nút OK

Password = “abc”

không hợp lệ”

Nhập Username, password và ấn

Username = “”

Hiển thị thông báo “Username và password

nút OK

Password = “”

không hợp lệ”

Nhập Username, password và ấn

Username = “hienlth”

Hiển thị trang chính của user “hienlth”

nút OK

Password = “123456”

Nhập Username, password và ấn

Username = “admin”

nút OK

Password = “admin”

Hiển thị trang chính của user “admin”


2.4. Dữ liệu kiểm tra (Test Data)

•

Test Data là gì?

Test Data là bộ dữ liệu được xây dựng để chạy thử các test case. Dữ liệu trong Test
Data gồm có hai loại là dữ liệu thường (normal data) và dữ liệu bắt buộc (Initial Data).
Xây dựng Test Data là một khâu rất quan trọng trong tiến trình test, vì kết quả test phụ
thuộc rất lớn vào dữ liệu trong Test Data.


2.4. Dữ liệu kiểm tra (Test Data)

•

Initial Data là gì?

Initial Data là các trường dữ liệu dùng để khởi tạo chương trình, bắt buộc cần phải có
để hệ thống có thể làm việc được. Initial Data là một bộ phận của Test Data.


2.4. Dữ liệu kiểm tra (Test Data)

•

Test Data do ai thực hiện?

Test Data thường do Test Leader và Developer xây dựng, sau khi có tài liệu phân tích
thiết kế mức chi tiết.  Dữ liệu khởi tạo (Initial Data) là phần bắt buộc cần phải có để hệ
thống có thể hoạt động được, thường do lập trình viên tạo lập sau khi hoàn chỉnh từng
bộ phận của hệ thống.
Test Leader chịu trách nhiệm xây dựng bộ dữ liệu Test Data thông thường. Sau đó,
Tester sẽ dùng các dữ liệu này để thực hiện Test Case.


2.5. Lỗi (Bug)

•

Cấu trúc chung của Bug:

–
–
–
–
–
–

–
–
–

Tên bug
Mã số, mức độ
Test case tương ứng (nếu có)
Màn hình, chức năng
Dữ liệu
Mơ tả các bước thực hiện
Hình chụp màn hình/quay phim các thao tác.
Trạng thái
Ngày tạo

–…


2.5 Bug (tt)
Bug và vòng đời của bug :

-

Bug (bọ): là thuật ngữ của những người làm công việc kiểm tra phần
mềm gọi các lỗi của phần mềm, là bug.

-

Vòng đời của bug: Là thời gian của 1 bugs tồn tại từ lúc phát sinh cho
tới lúc bug được sửa.

2.5 Bug (tt)


Các trạng thái của bug

a. NEW.
-. Trạng thái này bug mới được post lên hệ thống. Ngay lập tức
Bugzilla sẽ gửi mail tới thành viên liên quan (Developer, PJ
Leader...)

-.

Từ New có thế chuyển qua trạng thái khác: ASSIGNED hoặc
RESOLVED .


Các trạng thái của bug
b. ASSIGNED.

-

Trạng thái này bug được phân công cho DEV fix, ở trạng thái
này, bug chưa được fix.

-

Từ trạng thái này, có thể chuyển qua: NEW (chuyển cho người
khác fix), RESOLVED (đã fix xong bug).

Các trạng thái của bug
c. RESOLVED.

-

Trạng thái này bug đã được fix xong. Kết quả có thể là FIXED,
INVALID, WONTFIX, DUPLICATE, LATER hoặc REMIND.

-

Từ trạng thái này, bug có thể chuyển qua: REOPEN, VERIFIED,
CLOSED hoặc UNCONFIRMED


Các trạng thái của bug
c. RESOLVED (2).

-

FIXED : Bug đã fix xong.
INVALID : Vấn đề khơng phải bug.
WONTFIX : Vì lý do nào đó, bug nào sẽ khơng fix.
DUPLICATE : Post bị trùng với một bug nào đó đã post.
WORKSFORME :
LATER : bug tạm chưa fix được.
REMIND : Giống LATER.


Các trạng thái của bug

d. REOPENED.

-

Trạng thái này do TESTER/QC chuyển từ trạng thái RESOLVED sang. Do
fix rồi mà vẫn bị lỗi hoặc gây ra lỗi khác nữa.

-

Trạng thái này có thể chuyển sang trạng thái RESOLVED hoặc
ASSIGNED.


Các trạng thái của bug
e. VERIFIED

-

Trạng thái này do TESTER đã test lại xong và xác nhận đã fix bug này.
Trạng thái này có thể chuyển sang trạng thái UNCONFORMED, REOPEN
hoặc CLOSED.


Các trạng thái của bug
f. CLOSED

-

Trạng thái này bug đã fix xong và được test lại xong. Kết thúc 1 vịng đời
của một bug.

-

Ngoại lệ bug đã đóng rồi mà khi fix bug khác, gây ra lỗi bug này nữa thì
sẽ chuyển từ trạng thái CLOSED sang REOPEN.


2.6. Báo cáo kiểm tra (Test Report)

•

Cấu trúc chung của Test report:

– Test plan ?
– Tên người thực hiện
– Ngày thực hiện
– Môi trường test
– Bảng mô tả module/chức năng/test case và kết quả tương ứng
– Kết luận, đề xuất (nếu có)
– ….


2.7. Các vai trò


Tester

•

Vai trị

– Kiểm lỗi phần mềm
– Kiểm lỗi bản đóng gói
– Kiểm lỗi tài liệu
•
•
•
•

User guide
Installation Guide
Release Notes
Troubleshooting