KIỂM THỬ PHẦN MỀM - SOFTWARE TESTING

XÂY DỰNG
TEST DESIGN - TEST CASE

Đỗ Thị Thu Trang - FIT.UTEHY

1
NỘI DUNG
 Thiết kế kiểm thử (Test design)
 Trường hợp kiểm thử (Test case)
 Các yếu tố đảm bảo chất lượng phần mềm

2
NỘI DUNG
 Thiết kế kiểm thử (Test design)
 Trường hợp kiểm thử (Test case)
 Các yếu tố đảm bảo chất lượng phần mềm

3
Vòng đời kiểm thử phần mềm

4
TEST DESIGN - Example

 Chức năng đăng nhập hệ thống:

 Yêu cầu User, Pass không được để
trống. Trong đó User có length(50),
Password là [6,25].
 Nếu User, Pass hợp lệ và tồn tại trong
CSDL: đóng màn hình login, chuyển
đến màn hình chính.
 Nếu User, Pass hợp lệ nhưng không
tồn tại trong CSDL: hiển thị lable
“Thông tin tài khoản hoặc mật khẩu
không chính xác” OK/Cancel, click [OK]
con trỏ focus tại User.
 Nếu User, Pass không hợp lệ: hiển thị
lable “Tài khoản không hợp lệ” dưới
textbox tài khoản nếu user không hợp
lệ, hiển thị lable “Mật khẩu không hợp
lệ” dưới textbox mật khẩu nếu Pass
không hợp lệ.

5
TEST DESIGN - Problems?

 Cần bao nhiêu test case?

 Là những test case nào?
 Làm thế nào để xác định các test case?

6
TEST DESIGN - What? When?

 What?
 Là tài liệu liệt kê tất cả các trường hợp kiểm
thử - test cases, sẽ được sử dụng để kiểm thử
hệ thống phần mềm.
 Giống như tài liệu thiết kế mức cao (HLD),
nhưng dùng cho kiểm thử.
 When
 Trong giai đoạn Solution của vòng đời phát
triển phần mềm - SDLC

7
TEST DESIGN - Objective

 Mục đích:
 Xác định số lượng test case từ các yêu cầu của đặc tả.
 Đảm bảo các test case bao phủ các yêu cầu phần mềm.
 Từ đó ước lượng thời gian viết test case và thực hiện
kiểm thử.
 Căn cứ phân công công việc cho các tester.

8
TEST DESIGN - Process

• Đặc tả yêu cầu

• Use case (optional) Tài liệu thiết
Thiết kế test
kế test
•Thiết kế chi tiết

9
Define Test case List

 Liệt kê tất cả các test case có thể cho mỗi

yêu cầu kiểm thử:
 Dựa trên đặc tả yêu cầu
 Dựa trên thiết kế chi tiết
 Dựa trên kỹ thuật kiểm thử
 Các test case được đánh số và quản lý

10
TEST DESIGN - Requirement for test

 Liệt kê các đối tượng tạo Test cases:

 Các module hoặc chức năng

 Các đối tượng chính

 GUI

 Các yêu cầu về chức năng

 Các yêu cầu về phi chức năng

 Tham khảo mô hình chất lượng Mc Call’s

11
Test Design - Xác định test case

 Kiểm thử cho một chức năng/ UC bao gồm:

 Kiểm thử giao diện người dùng (GUI)
 Kiểm thử xác nhận dữ liệu đầu vào, đầu ra (Data validation)
 Kiểm thử chức năng/ nghiệp vụ (Bussiness Logic)
 Kiểm thử vai trò/quyền và sự cho phép các test case (Role)
 Kiểm tra luồng công việc/ dịch vụ thứ 3

12
User Interface Test Cases - GUI

 Dựa trên thiết kế màn hình/ nguyên mẫu.

 Kiểm tra giao diện người dùng:
 Giao diện: kích thước, vị trí, màu sắc, menu, căn lề các trường,
nhìn và cảm nhận (look and feel).
 Các đối tượng trên trang: buttons, checkbox, text box, list box,
links, combo box
 Object/control type
 Editable
 Mandatory
 Default value
 Hide/Un-hide
 Broken links
 Các phương thức truy cập: phím tab, di chuyển chuột, phím tắt,
chú giải công cụ.

13
Field Validation Test Cases

 Trường dữ liệu dạng Combo box

 Trường dữ liệu dạng văn bản
 Dòng văn bản đơn
 Nhiều dòng văn bản
 Trường dữ liệu dạng ngày tháng
 Trường dữ liệu dạng số
 Trường dữ liệu dạng đính kèm
 …

14
Field Validation Test Cases

Đối với dữ liệu dạng văn bản

Khi nhập dữ liệu:
 Kiểm tra có cho phép trường dữ liệu null, không null?
 Kiểm tra maxlength của ký tự nhập vào
 Kiểm tra có cho phép nhập các ký tự đặc biệt: trong
trường name, địa chỉ email, password, nội dung…
 Các ký tự trắng ở đầu hoặc cuối xâu có được cắt
không?

15
Field Validation Test Cases

Khi tìm kiếm:

Dữ liệu nhập vào là chữ hoa hoặc không có ảnh
hưởng đến việc tìm kiếm không?
Các kí tự trắng ở đầu hoặc cuối có được cắt đi
không?
Chú ý: hãy cẩn thận, bạn có thể kiểm thử thiếu
nếu hệ thống yêu cầu hỗ trợ Unicode

16
Field Validation Test Cases

Đối với dữ liệu dạng ngày tháng

 Khi nhập dữ liệu
Kiểm tra tính bắt buộc nhập dữ liệu
Kiểm tra định dạng (inputted date, chuyển đổi
kiểu dữ liệu ngày tháng nhập vào)
So sánh giá trị nhập vào với ngày hiện tại (nếu
được yêu cầu)
So sánh ngày dựa trên quy tắc nghiệp vụ

17
Field Validation Test Cases

Đối với dữ liệu dạng ngày tháng

 Khi tìm kiếm dữ liệu:
Kiểm tra định dạng
So sánh ngày đi và ngày đến
Tìm kiếm trong các trường lưu trữ giá trị kiểu
date and time
Chú ý: Khi hiển thị kết quả tìm kiếm/ bản ghi mới
kiểm tra nếu định dạng ngày tháng là đúng và độc
lập với thiết lập ngày tháng ở regional

18
Field Validation Test Cases

Đối với dữ liệu dạng số

 Khi nhập dữ liệu:
 Kiểm tra có cho phép null hay không
 Kiểm tra giá trị lớn nhất/nhỏ nhất
 Kiểm tra số nguyên/số thực
 Kiểm tra số âm/số dương
 Kiểm tra chuyển đổi định dạng (ký hiệu số thực, ký hiệu
nhóm số, biểu diễn số 0)
 Khi hiển thị:
 Hiển thị kí hiệu số thực, kí hiệu nhóm các số, kí hiệu số 0
ở đầu
19
Functional Test Cases

 Xây dựng test case với dữ liệu hợp lệ/ luồng nghiệp vụ
chính.
 Xây dựng test case cho quy tắc nghiệp vụ được xác
định trong SRS/ Các luồng thay thế.
 Sử dụng các kỹ thuật kiểm tra hộp đen:
 Phân vùng tương đương (Equivalent Partition)
 Phân tích giá trị biên (Boundary Value Analysis)
 Bảng quyết định (Decision Table)
 Chuyển đổi trạng thái (State Transition)

20
Functional Test Cases

Kiểm tra nghiệp vụ:

 Xác định đầu vào
 Xác định quy trình nghiệp vụ

 Luồng cơ bản: Dữ liệu hợp lệ

 Các luồng khác: hợp lệ với các loại khác của dữ
liệu

21
Role & Permission Test Cases

 Dựa trên yêu cầu phân quyền/ yêu cầu bảo mật của một
sản phẩm.
 Thiết kế các test case để đảm bảo:
 Mỗi vai trò có đặc quyền cụ thể được kiểm tra
 Người dùng với vai trò kết hợp được kiểm tra

22
System testing

Kiểm tra mức hệ thống (System testing):

 Kiểm tra giao diện/ hoạt động trên các hệ thống
khác nhau (Phần cứng, hệ điều hành)
 Kiểm tra giao diện/ hoạt động trên các trình duyệt
khác nhau.

23
TEST DESIGN - Xác định yêu cầu

 Non-Function requirement:
 Chất lượng mà hệ thống cần phải có:
 Hiệu năng

 Bảo mật

 Tính khả dụng

 Khả năng bảo trì

 Ràng buộc với qui trình phát triển PM

24
TEST DESIGN - Xác định test case

 Define test case list- Example

25
TEST DESIGN - Xác định test suite

 Luồng kiểm thử

 Xác định tiền điều kiện (pre-condition)
 Xác định phụ thuộc (inter-case )
 Xác định các test case thuộc bộ (test suite)

26
TEST DESIGN – Xác định test suite

 Define test suites- Example

27
TEST DESIGN - Benefit

 Tránh trường hợp bị thừa, thiếu test case.

 Test design ngắn gọn, dễ hiểu giúp dễ dàng quản lý,
rà soát các test case.
 Trong trường hợp ko đủ thời gian, có thể sử dụng
luôn test design để kiểm thử mà ko cần viết test
case.

28
TEST DESIGN - Exercise

 Tạo tài liệu test design cho dự án “Quản lý sinh viên”

 Chia thành 4 nhóm

 Nhóm 1: Quản lý đăng nhập

 Nhóm 2: Quản lý sinh viên

 Nhóm 3: Quản lý thi

 Nhóm 4: Quản lý điểm danh

29
NỘI DUNG
 Thiết kế kiểm thử (Test design)
 Trường hợp kiểm thử (Test case)
 Các yếu tố đảm bảo chất lượng phần mềm

30
Vòng đời kiểm thử phần mềm

31
TEST CASE PROCESS

•Detail design •Test case

•SRS Test •Test script
Implementation
•Test Plan •Test data

32
TEST CASE - What?

 Là một tập hợp các yếu tố đầu vào, điều kiện thực thi, các
hành động (action) /sự kiện (event), kết quả quả mong đợi và
các điều kiện thực thi tiên quyết, được phát triển cho một
mục tiêu cụ thể / điều kiện kiểm thử.
 Đầu vào:
 Đặc tả yêu cầu phần mềm (SRS)
 Thiết kế chi tiết
 Kế hoạch kiểm thử
 Phạm vi:
 Test case mức cao
 Test case mức thấp

33
TEST CASE - Why?

 Chi tiết hóa tài liệu test design, mô tả cách triển

khai thực hiện kiểm thử
 Dự đoán kết quả mong đợi
 Giúp các KTV mới làm quen/ ít kinh nghiệm có
thể biết các việc cần làm để kiểm thử phần mềm
mà không phải “bơi” trong bản đặc tả SRS.

34
TEST CASE - Good?

 Có xác suất cao cho việc tìm kiếm lỗi

 Rõ ràng về mục tiêu
 Tổ chức tốt
 Có khả năng rà soát
 Có khả năng bảo trì và nâng cấp
 Hữu ích cho các KTV khác

35
TEST CASE - Structure?

 Thông tin chung: cover sheet

 Thông tin dự án

 Thông tin thay đổi

 GUI: Liệt kê tất cả các thông tin trên màn hình để dễ dàng kiểm tra

 [Module Name] test cases

 Pictures: liệt kê tất cả các thiết kế màn hình cần được kiểm tra. Các

màn hình này phải được chấp thuận bởi khách hàng.

 Test Report

36
TEST CASE - Structure?

37
TEST CASE - Elements

 Các yêu cầu chính:

 Test Case ID
 Test Case Title/ Test Item
 Test Case Proceduces/ Test Case Description
 Expected Output
 Test Result/ Status
 Các thành phần khác:
 Test Condition / Req_ID/ UC Name
 Pre-Condition/Inter-Test Case Dependence
 Test Data
 Actual Output
 Priority…

38
Test Case - Test Case Title

 Là một câu ngắn mô tả khía cạnh của hệ thống cần

kiểm thử. Nếu nội dung quá dài thì hãy đưa nội dung
vào test case hoặc đưa thêm thông tin vào mô tả tính
năng.

39
Test Case - Example

 Ví dụ:
 Thêm user thành công  Nhập Username đã tồn tại
 Nhập ký tự đặc biệt trong  Thêm user, không thêm địa
trường Username chỉ email

40
Test Case Proceduces/ Steps

 Là một tập các bước/ các hành động cần thiết để thực
thi một test case.
 Ví dụ:
1. Trên màn hình đăng nhập, nhập Username: “test”
2. Nhập Password: “test@123”
3. Nhấn nút [Login]

41
Test Case - Expected Output

 Là một tập các đầu ra/ kết quả mong đợi sau thực hiện
các bước trong test description.
 Ví dụ:
1. Hiển thị thông báo lỗi
2. Đăng nhập không thành công

42
Test Case Result/ Status

 Trạng thái của một test case thực thi. Nó có thể là:
 Passed/OK: Kết quả thực tế đáp ứng yêu cầu (kết quả mong
đợi)
 Failed/NOK/NG: Kết quả thực tế không đáp ứng yêu cầu (kết
quả mong đợi).
 Blocked: Không thể thực hiện được vì các điều kiện tiên quyết
đã không thành công.
 NA/Skipped: Không kiểm tra được, bỏ qua.
 Not Tested: Chưa kiểm tra.

43
Test Case - Other consider Elements

 Test condition: điều kiện kiểm tra.

 Pre-condition/ Pre-requisite: Các điều kiện tiên quyết
cần thiết để thực hiện các test case (Các giả định cần
phải đáp ứng trước khi có thể chạy test case.
 Ví dụ: "đã đăng nhập", “đang ở trang chủ", "người sử dụng tồn
tại“
 Inter-test case Dependence: một hoặc nhiều các test
case là đầu vào cho những test case khác. Nếu chúng bị
blocked, thì không thể chạy được các test case tiếp
theo.

44
Test Case - Other consider Elements

 Test data:
 Danh sách các biến và giá trị có thể sử dụng cho test case.
 Có thể liệt kê các giá trị cụ thể hoặc mô tả phạm vi giá trị.
 Test case được thực thi với mỗi giá trị.
 Các giá trị này được viết bằng ký hiệu.
 Ví dụ: loginID = {Valid loginID , invalid loginID , valid email,
invalid email, empty} ; password = {valid, invalid, empty}
 Actual output: kết quả thực tế khi chạy các test case.

45
Tips for good Test case

 Một test case tốt có một số đặc điểm như sau:

 Test case phải chính xác và kiểm tra đúng những gì nó được dự
kiến.
 Bước kiểm tra và kết quả mong đợi nên thể hiện từng bước một
trong test case.
 Loại bỏ các bước thừa, không cần thiết.
 Nó có thể tái sử dụng, duy trì.
 Nó có thể theo dõi được yêu cầu.
 Nó phải đơn giản và rõ ràng, người kiểm thử nào cũng có thể
hiểu nó bằng cách đọc một lần.

46
Terms

 High level test case/logical test case/ abstract test case:

 Test case không có giá trị cụ thể (mức triển khai) cho dữ liệu đầu
vào và kết quả mong đợi.
 Toán tử logic được sử dụng; trường hợp của các giá trị thực tế
chưa được xác định và / hoặc có sẵn.
 Low level test case/concrete test case:
 Test case với các giá trị cụ thể (mức độ thực hiện) cho dữ liệu
đầu vào và kết quả mong đợi.
 Các toán tử logic từ các trường hợp kiểm thử mức cao được
thay thế bởi các giá trị thực tế tương ứng với các mục tiêu của
các toán tử logic.

47
TEST CASE -[Function]

Example

48
TEST CASE -[Non_Function]

Example

49
TEST CASE - Note?

 Viết đúng bố cục

 Viết ngắn gọn, mạch lạc, rõ ràng, chia thành các bước,
tránh văn xuôi, theo một style nhất định.
 Viết các bước thực hiện: Bắt đầu bằng một động từ
 Viết PreCondition: Nêu các điều kiện cần thiết để thực
hiện test case này

50
TEST CASE – Note?

 Viết Procedure: nên theo thứ tự các bước

 Viết Expected result: nên nêu rõ kết quả mong đợi tương
ứng với bước nào của cột Test case Procedure
 Chú ý: phải có sự kiện/ hành động tác động thì mới có
kết quả mong chờ
 Test data: dữ liệu dùng để kiểm thử nên mô tả cụ thể
tương ứng với từng test case

51
TEST CASE – Ví dụ

52
Exercise

Viết test case giao diện, chức năng cho module quản lý
sinh viên dựa trên tài liệu thiết kế:
 Account management
 Student management

53
NỘI DUNG
 Thiết kế kiểm thử (Test design)
 Trường hợp kiểm thử (Test case)
 Các yếu tố đảm bảo chất lượng phần
mềm

54
Mô hình chất lượng McCall’s
 Các tiêu chí đảm
bảo chất lượng
phần mềm:
 Vận hành sản
phẩm (Product
operation)
 Sửa đổi sản phẩm
(Product revision)
 Chuyển giao sản
phẩm (Product
transition)

55
Vận hành sản phẩm(Product operation)
 Correctness (Tính đúng đắn): thể hiện mức độ hoàn
thành, mức độ hoạt động chính xác của hệ thống so
với đặc tả của nó.
 Reliability (Tính tin cậy): Đề cập tới khả năng không
hỏng, không lỗi, không sai của HT trong quá trình sử
dụng.
 Efficiency (Tính hiệu quả): Đề cập tới việc dùng tài
nguyên trong thực hiện và lưu trữ các chức năng của
phần mềm.
 Integrity (Tính toàn vẹn): Tính bảo mật của HT với việc
ngăn chặn truy cập trái phép, khả năng phục hồi.
 Usability (Tính khả dụng): Đề cập tới khả năng dễ dùng
của HT. 56
Sửa đổi sản phầm (Product revision)
 Maintainability (Tính bảo trì): Mức công sức cần để bảo
trì PM khi có lỗi, kiến trúc các module như thế nào
 Flexibility (Tính khả chuyển): Đề cập tới khả năng thay
đổi của HT khi chuyển HT từ môi trường này sang môi
trường khác.
 Testability (Khả năng kiểm thử): Có dễ dàng kiểm thử
được hay không để đảm bảo nó không lỗi và đáp ứng
đặc tả.

57
Chuyển giao sản phẩm (Product
transition)
 Portability (Tính thích ứng): Tính thích ứng của hệ
thống khi được cài đặt trong môi trường mới, phần
cứng, hệ điều hành...
 Reusability (Tính tái dụng): Khả năng tái sử dụng các
module, tài liệu của hệ thống nhằm rút ngắn thời gian
xây dựng hệ thống mới.
 Interoperability (Khả năng tương tác): Khả năng phát
triển, tích hợp hệ thống với các hệ thống/ thiết bị khác.

58
TEST DESIGN

TÓM LẠI
Nội dung bài học gồm

1. Test design 2. Test case 3.Test suite 4. Practice

Thiết kế kiểm Tình huống Bộ kiểm thử Thực hành
thử kiểm thử

59
Tài liệu tham khảo

 Bộ môn CNPM - Khoa CNTT, Đề cương Kiểm thử phần mềm, Đại
học Sư phạm Kỹ Thuật Hưng Yên.

 http://istqbexamcertification.com/what-is-fundamental-test-
process-in-software-testing/

60
TỔNG KẾT

QUESTION/ ANSWER

61
TEST CASE - [Unit]

• Condition: đưa ra các điều kiện để thực hiện các test case
 Precondition: Liệt kê các yêu cầu cần phải có trước khi kiểm thử
 Input: Liệt kê các dữ liệu đầu vào.

• Confirm: đưa ra các kết quả mong đợi tương ứng với từng
test case
 Return: Liệt kê các kết quả trả về tương ứng với từng test case
 Exception: Liệt kê các trường hợp ngoại lệ
 Log message: Liệt kê các câu thông báo nếu có

63
TEST CASE - [Unit]

• Result: đưa ra kết quả

 Type: đưa ra kiểu kết quả trả về (N : Normal, A : Abnormal, B :
Boundary)
 Passed/Failed
 Executed Date: ngày thực hiện
 Defect ID: mã quản lý lỗi (nếu có)

64
TEST CASE - [Unit]

Example

65
Tài liệu tham khảo

 Bộ môn CNPM - Khoa CNTT, Đề cương Kiểm thử phần mềm, Đại
học Sư phạm Kỹ Thuật Hưng Yên.

 https://www.slideserve.com/woody/software-quality-models

68
TỔNG KẾT

QUESTION/ ANSWER

69