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

Nhập môn Công nghệ phần mềm - Chương 2: Các khái niệm cơ bản trong kiểm thử phần mềm trình bày các nội dung: quy trình kiểm tra phần mềm, kế hoạch kiểm tra (Test plan), tình huống kiểm tra (Test case), dữ liệu kiểm tra (Test Data), lỗi (Bug), báo cáo kiểm tra (Test Report), các vai trò của kiểm thử phần mềm.

Kiểm thử Phần mềm – Software 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

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.

Chuẩn bị dữ liệu test với bộ dữ liệu testChạy ứng dụng

Test Report

Test Results

Test Data/S Test Case

Test plan

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

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

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

• Username = “admin”, pass = “admin”

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

Test case – Test step

Username =

“ hienlth ” Password = “ abc ”

Hiển thị thông báo

“Username và password không hợp lệ”

4 Nhập Username ,

password và ấn nút OK

Username = “ abc ” Password =

“ hienlth ”

Hiển thị thông báo

“Username và password không hợp lệ”

5 Nhập Username,

password và ấn nút OK

Username = “ abc ” Password = “ abc ” Hiển thị thông báo “Username và password

không hợp lệ”

6 Nhập Username,

password và ấn nút OK

Username =

“ hienlth ” Password =

Username =

“ admin ” 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

– 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

– 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ò

• 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

• IE, FireFox, Netscape, Mozilla

• Test Database, Test data

– Viết test case

– Thực hiện test các test case trong từng môi trường khác nhau

– Mô tả Bug và chi tiết các bước để tạo ra bug

– Theo dõi quá trình Fix Bug

– Báo cáo kết quả test

• Tester Role

– Workflow

• Tester Role

Cảm ơn

• Bài giảng này tham khảo và hiệu chỉnh từ:

– Slide Công nghệ Phần mềm, Trần Ngọc Bảo,

Câu hỏi và thảo luận

?

Thank you!!!