KIỂM THỬ PHẦN MỀM

Giảng viên: LÊ TRUNG KIÊN

 Tester for
Base

Vòng đời phát triển PM

Tổng quan kiểm thử

Quy trình kiểm thử

 Tester for
Base

Software

Teteste
r
 Tester for
Base

VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM

 Tester for
Base
 Vòng đời phát triển phần mềm
Là thời kỳ tính từ khi phần mềm được sinh (tạo) ra
cho đến khi bị loại bỏ hoàn toàn.
 Mô hình vòng đời phát triển PM gồm:
- Pha yêu cầu - Pha kiểm thử
- Pha đặc tả - Pha bảo trì
- Pha thiết kế - Pha loại bỏ
- Pha lập trình
 Tester for
Base
Mô hình vòng đời phát triển phần mềm
Yêu cầu

Đặc tả

Thiết kế

Lập trình

Kiểm thử

Bảo trì

Loại bỏ
 Tester for
Base
 Pha xác định yêu cầu (Phase 1)
 Hay còn gọi là pha tìm hiểu khái niệm

 Là pha đầu tiên trong quá trình xây dựng PM

 Ở pha này, đại diện nhóm phát triển và khách hàng sẽ

gặp nhau, khách hàng nêu ra những yêu cầu và nhóm
phân tích yêu cầu, phát triển sẽ ghi chép lại.
 Tester for
Base
 Pha đặc tả (Phase 2)
 Pha này mục đích chính là phân tích yêu
cầu của khách hàng
 Mô tả các kết quả phân tích dưới dạng “Tài liệu đặc tả”
 Mô tả chi tiết quá trình phát triển PM
 Câu hỏi mà pha này cần trả lời là “Phần mềm sẽ làm gì ?”
 Tester for
Base
 Pha thiết kế (Phase 3)
 Chuyển các yêu cầu đã được đặc tả thành thiết kế cho
hệ thống, đưa ra kiến trúc vững chắc cho PM
 Mục đích của pha này “Phần mềm sẽ được làm như thế
nào?”
 Pha thiết kế chia làm 2 phần:

- Thiết kế cấu trúc: chia phần mềm thành các Module

- Thiết kế chi tiết: thiết kế từng Module một cách chi tiết
 Tester for
Base
 Pha lập trình (Phase 4)
 Xây dựng và phát triển PM đáp ứng các yêu cầu và tiêu
chuẩn đã xác định.
 Ở pha này các dev thực hiện viết chương trình PM theo
một ngôn ngữ lập trình cụ thể.
 Kết nối các Module đã viết của chương trình thành một
phần mềm thống nhất và chạy thử.
 Chỉnh sửa cho đến khi PM chạy tốt
Ví dụ:
Các phần mềm sử dụng trên Winform: C/C++, C#.NET, Java, trên
Webform: ASP.NET, PHP, JSP,…
 Tester for
Base
 Pha lập trình (Phase 4)
 Tester for
Base
 Pha kiểm thử (Phase 5)
 Thực hiện test phần mềm

 Liên tục cập nhật, báo cáo tình trạng phần mềm

 Chuẩn bị kiểm thử được tiến hành trong

môi trường khách hàng
 Tester for
Base
 Pha bảo trì (Phase 6)
 Trong một PM, việc còn sót lỗi là không tránh khỏi. Do đó
pha bảo trì này chia thành 2 loại:
- Software repair (bảo trì sửa lỗi)

- Software update (bảo trì cập nhật)

+ Bảo trì hoàn thiện: Sửa đổi PM theo ý KH
+ Bảo trì thích nghi: Sửa đổi để PM thích nghi với môi trường
mới
 Tester for
Base
 Pha loại bỏ (Phase 7)
 Do môi trường làm việc

 Chi phí bảo trì PM lớn hơn chi phí phát triển một PM
mới
 Cty, cơ quan sử dụng PM chưa đồng nhất ý kiến, còn xẩy
ra nhiều bất cập

 Lúc này, việc loại bỏ PM sẽ được thực hiện

 Tester for
Base

TỔNG QUAN VỀ KIỂM THỬ VIÊN

 Tester for
Base
 Tại sao phải kiểm thử PM
 Việc kiểm thử phần mềm là cần thiết
để xác định PM được tạo ra có đáp ứng đúng
các yêu cầu hay không?
 Tiết kiệm thời gian và chi phí bởi xác định những thiếu
sót sớm.
 Tránh và giảm bớt thời gian ngừng phát triển

 Biết rằng chúng ta đã thỏa mãn được những yêu cầu

của khách hàng.
 Tester for
Base
 Mục tiêu kiểm thử
 Phát hiện nhiều lỗi nhất (có thể) trong một khoảng thời
gian nhất định (deadline)
 Xác định xem một sản phẩm phần mềm có đáp ứng các
đặc tả yêu cầu của nó hay không?
 Đảm bảo chất lượng kiểm thử PM với chi phí thấp nhất
 Tạo ra các testcase có chất lượng cao, thực hiện các
Test có hiệu quả, đưa ra các báo cáo và có ích về vấn
đề xảy ra
 Tester for
Base
 Các quan niệm sai về công việc kiểm thử
 Kiểm thử là một công việc chán ngắt, buồn tẻ

 Kiểm thử có thể phát hiện ra tất

cả các lỗi và chứng
minh rằng một hệ thống không có bất cứ một lỗi nào
 Kiểm thử tốt nhất khi hệ thống đã đưa vào sử dụng

 Chỉ kiểm thử một lần

 Người lập trình (Dev) có thể làm tất

cả các công việc kiểm thử khi họ đã code xong
 Tester for
Base
 Tố chất của một Tester
 Tính cẩn thận

 Kiên trì

 Tư duy logic

 Làm việc theo nhóm

 Khả năng độc lập

 Khả năng hình dung và khái quát vấn đề

 Chủ động cập nhật và tìm hiểu các kiến thức mới
 Tester for
Base
 Tố chất của một
Tester
 Tester for
Base
 Vai trò của Tester
 Bảo đảm rằng PM bám sát và thỏa mãn các yêu cầu đặt
ra
 Phát hiện những lỗi cần sửa cũng như những đề xuất
để cải tiến PM.
 Một kiểm thử viên thì không có cơ hội để sửa sai, nhất
là khi ứng dụng đó được đưa vào sử dụng.
 Dù muốn hay không Tester vẫn sẽ là những người đầu
tiên bị “truy cứu” khi một sản phẩm PM vẫn còn tồn tại
hoặc phát sinh lỗi khi đưa ra thị trường.
 Tester for
Base
 Những thành phần tham gia sản xuất PM
Để đảm bảo chất lượng phần mềm được tiến hành và triển khai
theo suốt các giai đoạn trong vòng đời phát triển PM, từ giai
đoạn xác định yêu cầu đến khi triển khai gồm:
 Phân tích viên

 Thiết kế viên

 Lập trình viên

 Quản lý/Test leader/tester

 Tester for
Base
 Phân tích viên
 Đảm nhận vai trò xác minh và phân tích yêu cầu người
dùng
 Xác định yêu cầu, đảm bảo cho PM đáp ứng được yêu
cầu của khách hàng
 Có thể dựa trên sự hiểu biết và kinh nghiệm để trao đổi
với khách hàng cách thức xây dựng PM hợp lý chất
 Tester for
Base
 Phân tích viên

Analytics
 Tester for
Base
 Thiết kế viên
 Chuyển các yêu cầu đã được phân tích thành thiết kế cho
hệ thống.
 Thiết kế phù hợp với môi trường
lập trình và phát triển
sau này.
 Công việc thiết kế sẽ chi tiết hóa các yêu cầu khách hàng
thành các chức năng của phần mềm. Nếu thiết kế sai
hoặc thiếu có thể khi triển khai sẽ bị đổ vỡ.
 Tester for
Base
 Thiết kế viên
 Tester for
Base
 Lập trình viên
 Tester for
Base
 Lập trình viên
 Xây dựng và phát triển PM đáp ứng các yêu cầu và tiêu
chuẩn đã xác định
 Lập trình tốt sẽ tránh được các lỗi cơ bản, các lỗi phát
sinh khi triển khai và chất lượng PM tăng lên
 Tester for
Base
 Quản lý/ TestLeader/Tester
 Xác định được tối đa lỗi và xử lý trước khi triển khai.

 Đây là người có vai trò quan trọng nhất trong công tác
đảm bảo chất lượng PM.
 Nếu tester yếu kém sẽ dẫn tới một dự án thất bại ngay
khi triển khai.
 Trên thực tế, việc kiểm thử được lồng vào các giai đoạn
phát triển của PM để tăng độ chính xác và chất lượng
cho PM.
 Tester for
Base
 Quản lý/
TestLeader/Tester
 Tester for
Base

QUY TRÌNH KIỂM THỬ

 Tester for
Base

Lập kế

hoạch
Chuẩ
n bị
kiểm
thử
Quy trình kiểm thử PM

Thực thi Bàn giao

kiểm thử Sản phẩm
Báo cáo
 Tester for
Base
 Quy trình kiểm thử phần mềm
 Tester for
Base
Lập kế hoạch kiểm thử
 Các giai đoạn kiểm thử
o Thiết kế các trường hợp kiểm thử và các dữ liệu kiểm thử cho
các trường hợp

 Các phương pháp kiểm thử

o Các phương pháp hộp đen để kiểm thử dựa trên chức năng.

o Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong.

 Các công cụ kiểm thử

 Nguồn lực kiểm thử

 Mốc bàn giao các tài liệu kiểm thử

 Tester for
Base
 Chuẩn bị kiểm thử
 Tìm hiểu nghiệp vụ của hệ thống phải kiểm thử

 Xây dựng kịch bản kiểm thử (Testcase)

 Phát triển các thủ tục giữa bên A (nhận

hợp đồng xây dựng dự án) và bên B (Yêu cầu xây
dựng phần mềm)
 Xem xét, phê duyệt các tài liệu
 Tester for
Base
 Thực thi kiểm thử
 Dựa trên các kịch bản test (testcase) để thực thi việc
kiểm thử
 Trong quá trình tiến hành kiểm thử, tester luôn luôn cập
nhật những thay đổi của PM để thêm (bớt) số lượng
testcase trong chương trình.
 Tham gia quá trình quản lý lỗi
- Báo lỗi
- Kiểm tra trạng thái lỗi
- Yêu cầu (đề xuất) cải thiện PM
 Tester for
Base
 Thực thi kiểm thử
 Tester for
Base
 Báo cáo & phân tích dữ liệu kiểm thử
 Tài liệu hóa tất cả các trường hợp kiểm thử đã chạy, dữ
liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục
đích của kiểm thử,…
 Báo cáo kiểm thử (số lỗi hiện thời)

 Phân tích nguyên nhân (nếu biết)

 Đưa ra các giải pháp nhằm hạn chế số lỗi xảy ra

Lưu ý:
• Trong một dự án số lỗi tìm được <=15% testcase

• Đây là một tiêu chuẩn đánh giá PM đảm bảo chất lượng
 Tester for
Base
 Báo cáo & phân tích dữ liệu kiểm thử
 Ví dụ về báo cáo kiểm thử
STT Tester Tổng số lỗi gán cho Dev
01 Nguyễn Mai Anh 200 bug – Lê Hải Hà
02 Nguyễn Thị Hiền 125 bug – Nguyễn Văn Hùng
03 Đỗ Thị Thu Tuyền 121 bug – Trần Hạnh
04 Nguyễn Trà Giang 165 bug – Nguyễn Ngọc Minh
05 Vũ Lan Hương 285 bug – Lê Minh Huy
Nội dung

*Khái niệm cơ bản

• Kiểm thử hộp đen
• Kiểm thử hộp trắng
• Kiểm thử hệ thống
 Kiểm thử chương trình

• Có thể chỉ ra lỗi, không thể khẳng định không còn

lỗi
• Có thể khẳng định hết lỗi bằng kiểm thử vét cạn, nhưng
cách này không khả thi trên thực tế
• Một kiểm thử thành công là một kiểm thử phát
hiện ra lỗi

4
©Ian Sommerville
Các mức kiểm thử
• Đơn vị
—Tìm lỗi trong từng đơn vị
• Tích hợp
—Tìm lỗi khi ghép các đơn vị
• Hệ thống
—Tìm lỗi khi hệ thống đã tích hợp xong, trước khi phát
hành, chuyển giao
• Chấp thuận
-Người sử dụng dùng thử xem hệ thống đáp ứng đúng
mong muốn chưa.
-Còn gọi là kiểm thử alpha.
6
BUỔI 2:
CÁC MỨC KIỂM THỬ
Giảng viên: LÊ TRUNG KIÊN
 Tester for
Base

Kiểm thử phần mềm

Kiểm thử đơn vị Kiểm

thử tích hợp

Kiểm thử hệ thống

Kiểm thử nghiệm thu

 Tester for
Base

KIỂM THỬ PHẦN MỀM

 Tester for
Base
 Khái niệm kiểm thử phần mềm (KTPM)
 Tester for
Base
 Khái niệm kiểm thử phần mềm (KTPM)
 Kiểm thử phần mềm thường đồng nghĩa việc tìm
với
ra lỗi chưa được phát hiện.
Kiểm thử phần mềm là quá trình thực thi một hệ thống
phần mềm để xác định xem phần mềm đó có đúng với
đặc tả không và thực hiện trong môi trường như mong
đợi hay không.
 Tester for
Base
 Khái niệm kiểm thử phần mềm (KTPM)
 Tester for
Base
 Khái niệm kiểm thử phần mềm (KTPM)
 Công việc mà bất cứ người nào từng
tham gia phát
triển phần mềm (PTPM) đều biết và từng làm
 Việc kiểm tra này có thể thực hiện theo từng giai đoạn
PTPM
 KTPM thực hiện:
- Sau mỗi chức năng
- Module được phát triển
- Hoặc thực hiện sau cùng, khi PM đã được phát triển
hoàn tất
 Tester for
Base
 Khái niệm kiểm thử phần mềm (KTPM)
 KTPM đứng ở vị trí hết sức nhạy cảm, nó là bước đệm
giữa giai đoạn xây dựng PM và sử dụng PM
 Thực tế, KTPM không đơn giản như nhiều người
thường nghĩ. Công việc này có nhiều mức độ khác nhau
và có mối tương quan với các giai đoạn phát triển trong
dự án PTPM.
 Tester for
Base
 Mục đích của kiểm thử phần mềm
 Kiểm thử phần mềm thường đồng nghĩa với
việc tìm ra lỗi chưa được phát hiện.
 Kiểm thử phần mềm là quá trình thực thi một hệ thống
phần mềm để xác định xem phần mềm đó có đúng với
đặc tả không và thực hiện trong môi trường như mong
đợi hay không nếu trong bối cảnh kiểm thử không bộc lộ
ra lỗi.
 Tester for
Base
 Mô hình các giai đoạn kiểm thử
 Tester for
Base

KIỂM THỬ ĐƠN VỊ

 Tester for
Base
 Unit Test – Kiểm thử mức đơn vị
 Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm
tra được.
 Lớp (Class): Gồm các đối tượng khác nhau nhưng cùng
thuộc tính.
 Các hàm (Function)

 Thủ tục (Procedure)

 Phương thức (Method)

 Thực hiện các câu lệnh trong PM

 Tester for
Base
 Unit Test – Kiểm thử mức đơn vị
 Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục
cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn
thể Unit đang kiểm tra.
 Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit
Test tiết kiệm hơn rất nhiều thời gian ở các mức kiểm tra
sau đó.
 Chi phí cho việc kiểm tra và sửa lỗi là thấp nhất
 Tester for
Base

 Mục đích của Unit Test

 Bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính
xác.
 Kiểm soát tối đa số lỗi trước khi tiến hành tích hợp các
Unit
 Người thực hiện test đơn vị thường là
lập trình viên
(Đòi hỏi kiểm tra viên có kiến thức về
thiết kế và code)
 Tester for
Base
 Yêu cầu của Unit Test
 Đòi hỏi tất cả các nhánh bên trong Unit đều phải được
kiểm tra để phát hiện nhánh phát sinh lỗi.
 Phải chuẩn bị trước các tình huống kiểm thử trong đó
chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu
mong chờ sẽ xuất ra.

Chú ý: Các testcase này nên được giữ lại để tái sử dụng
 Tester for
Base

KIỂM THỬ TÍCH HỢP

 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Trong khi Unit Test kiểm tra các thành phần Unit riêng lẻ
thì Integration Test kết hợp chúng lại với nhau và kiểm
tra sự giao tiếp giữa chúng.
 Integration test kết hợp các thành phần
của một ứng
dụng và kiểm tra như một ứng dụng đã hoàn thành.
 Integration Test có 2 mục tiêu chính:
o Phát hiện lỗi giao tiếp xảy ra giữa các Unit

o Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và
cuối cùng là hoàn chỉnh hệ thống (system) để chuẩn bị cho kiểm
tra ở mức hệ thống (System Test)
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Ví dụ:

Unit 1 Thực hiện thao tác thêm hồ sơ

Unit 2 Cập nhật trạng thái hồ sơ

Tích hợp A & B ???

 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Một số người hiểu sai rằng Unit một khi đã qua giai đoạn
Unit Test với các giao tiếp giả lập thì không cần phải
thực hiện Integration Test nữa.
 Thực tế việc tích hợp giữa các Unit dẫn đến những tình
huống hoàn toàn khác.
Lưu ý:
- Kiểm thử tích hợp chỉ nên thực hiện sau khi đã kiểm tra
tất cả các đơn vị trước đó
- Tất cả các lỗi phát hiện ở mức kiểm thử đơn vị đều đã
được sửa chữa
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Tại sao nên tích hợp dần từng Unit ?
Một Unit khi được tích hợp vào một nhóm các Unit khác đã
tích hợp trước đó thì lúc này, ta chỉ cần kiểm tra giao tiếp
của Unit mới thêm vào với nhóm các Unit đã được tích hợp
trước đó.
 Điều này làm cho số lượng kiểm tra
sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.
 Người thực hiện test tích hợp thường là lập trình viên
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Có 4 loại kiểm tra trong Integration
Test
Kiểm thử cấu trúc
1
Kiểm thử chức năng
2

Kiểm thử hiệu năng

3

Kiểm thử khả năng chịu tải

4
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Có 4 loại kiểm tra trong Integration Test
1. Kiểm tra cấu trúc - structure
• Tương tự White Box Test
• Kiểm tra nhằm bảo đảm các thành phần bên trong của
một chương trình chạy đúng.
• Chú trọng đến hoạt động của các thành phần cấu trúc
của chương trình (chẳng hạn các lệnh và nhánh bên
trong).
1. Kiểm tra chức năng - functional
• Tương tự Black Box Test
• Kiểm tra chỉ chú trọng đến chức năng
của chương
trình.
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Có 4 loại kiểm tra trong Integration
Test
2. Kiểm tra chức năng - functional

Click
Nhập đầu vào Tạo Hồ Sơ Thực hiện
ntn?
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Có 4 loại kiểm tra trong Integration Test
3. Kiểm tra hiệu năng (performance)
- Kiểm tra các giới hạn (sử dụng tài nguyên) của hệ
thống
- Cách kiểm tra:

Click chuột phải vào Task

thanh công cụ Manager
 Tester for
Base
 Integration Test - Kiểm thử tích hợp
 Có 4 loại kiểm tra trong Integration
4. Test
Kiểm tra khả năng chịu tải (Stress Xem hệ thống
test)
Tức là kiểm tra việc vận hành của hệ xử lý ntn?
thống Thời gian?

Cùng nhấn nút thêm mới

 Tester for
Base

KIỂM THỬ MỨC HỆ THỐNG

 Tester for
Base
 System test - Kiểm thử hệ thống
 Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ
thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay
không?
 Phải thực hiện Unit Test và Integration Test để bảo
đảm mọi Unit và sự tương tác giữa chúng hoạt động
chính xác trước khi thực hiện System Test.
 Tester for
Base
 System test - Kiểm thử hệ thống
 Đặc điểm kiểm tra hệ thống
o Tốn rất nhiều công sức

o Mất nhiều thời gian

Bởi vì trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy
và các yêu cầu khác liên quan đến chất lượng của toàn hệ
thống
 Tester for
Base
 System test - Kiểm thử hệ thống
 Điểm khác nhau then chốt giữa Integration
Test và
System Test
o System Test: chú trọng các hành vi và lỗi trên toàn hệ thống

o Integration Test: chú trọng sự giao tiếp giữa các đơn thể (Unit)
khi chúng làm việc cùng nhau.

 Người thực hiện test hệ thống thường là kiểm thử viên

 Một hoặc nhóm kiểm thử viên test hoàn toàn độc lập so
với nhóm phát triển dự án.
 Tester for
Base
 Mô hình mô tả các loại kiểm thử hệ thống
 Tester for
Base
 System test - Kiểm thử hệ thống
1. Kiểm tra chức năng (Functional Test)
o Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu
cầu thiết kế
2. Kiểm tra hiệu năng (Performance Test)
o Hay còn gọi là kiểm tra khả năng vận hành

o Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống

 Tester for
Base
 System test - Kiểm thử hệ thống
3. Kiểm tra khả năng chịu tải (Stress test)
(Tham khảo slide 25)
4. Kiểm tra cấu hình (Configuration Test)
o Cùng một phần mềm nhưng mình sẽ kiểm tra trên các máy tính
(Laptop/Desktop) có cấu hình khác nhau
o Lúc này, kiểm tra xem phần mềm đó hoạt động như thế nào?
 Tester for
Base
 System test - Kiểm thử hệ thống
4. Kiểm tra cấu hình (Configuration Test)

Cấu hình Cấu hình

- Core i5 - pentum4
- RAM 4GB - RAM 1GB
- HDD 500GB - HDD 80GB

HDD: hard disk driver/ổ cứng (lưu trữ dữ liệu)

 Tester for
Base
 System test - Kiểm thử hệ thống
5. Kiểm tra khả năng phục hồi (Recovery Test)
o Bảo đảm hệ thống có khả năng khôi phục trạng thái
ổn định trước đó trong tình huống mất tài nguyên
hoặc dữ liệu
o Đặc biệt quan trọng đối với các hệ thống giao dịch
trực tuyến

6. Kiểm tra khả năng bảo mật (Security Test)

o Bảo đảm tính toàn vẹn,bảo mật của dữ liệu và của hệ
thống
 Tester for
Base
 System test - Kiểm thử hệ thống
6. Kiểm tra khả năng bảo mật (Security Test)

Đảm bảo phần mềm được bảo mật

 Tester for
Base
 System test - Kiểm thử hệ thống
 Tóm lại:
o Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng
nhằm bảo đảm hệ thống đủ khả năng làm việc trong môi trường
thực.
o Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách
hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận sản
phẩm (Acceptance Test).
 Tester for
Base
 System test - Kiểm thử hệ thống
 Lưu ý:
Không nhất thiết phải thực hiện tất cả các loại kiểm
tra nêu trên mà sẽ:
o Tùy yêu cầu và đặc trưng của từng hệ thống
o Tuỳ khả năng và thời gian cho phép của dự án, khi
lập kế hoạch, trưởng dự án sẽ quyết định áp dụng
những loại kiểm tra nào
 Tester for
Base

KIỂM THỬ NGHIỆM THU

 Tester for
Base
 Acceptance Test – Kiểm tra chấp nhận sản phẩm
 Hay còn gọi là kiểm thử nghiệm thu

 Acceptance Test có ý nghĩa hết sức quan trọng

 Giai đoạn này thường được khách hàng thực hiện (hoặc
ủy quyền cho một nhóm thứ ba thực hiện)
 Tester for
Base
 Acceptance Test – Kiểm tra chấp nhận sản phẩm
 Trong hầu hết mọi trường hợp, các phép kiểm tra của
System Test và Acceptance Test gần như tương tự,
nhưng bản chất và cách thức thực hiện lại rất khác biệt
 Thực tế cho thấy, nếu khách hàng không quan tâm và
không tham gia vào quá trình PTPM thì kết quả
Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải
qua tất cả các kiểm tra trước đó
 Tester for
Base
 Acceptance Test – Kiểm tra chấp nhận sản phẩm
 Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng
như sự mong chờ của khách hàng

Ví dụ:Một PM xuất sắc vượt qua các phép kiểm tra sau
cùng vẫn thất vọng vì:

+ Bố cục màn hình nghèo nàn

+ Thao tác không tự nhiên

+ Không theo tập quán sử dụng của khách hàng v.v...

 Tester for
Base
 Acceptance Test – Kiểm tra chấp nhận sản phẩm
 Gắn liền với giai đoạn Acceptance Test
o Thường là một nhóm những dịch vụ
o Tài liệu đi kèm
Ví dụ: Hướng dẫn cài đặt, hướng dẫn sử dụng phần mềm, tài
liệu hướng dẫn sử dụng phần mềm đúng với nghiệp vụ của
từng cá nhân (cán bộ)
Chú ý: Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra
chặt chẽ.
Thuật ngữ

• Lỗi (error)
• Con người mắc lỗi trong quá trình làm
• Sai sót, khiếm khuyết (fault/defect)
sai sót trên sản phẩm (tài liệu, mã nguồn), do con người
mắc lỗi làm ra.
• Trục trặc (failure)
• Trục trặc xảy ra khi chạy phải khiếm khuyết
• Sự cố (incident)
• Sự cố là triệu chứng của trục trặc mà con người nhận
biết được.
7
Thuật ngữ

*■
8
Các mức kiểm thử

9
Các mức kiểm thử (tiếp)
Kiểm thử và gỡ lỗi (debugging)

• Kiểm thử khiếm khuyết

• Khẳng định có lỗi
• Gỡ lỗi (debugging)
• Định vị và sửa lỗi

• Gỡ lỗi thông thường phải lập giả thuyết về hành vi

của chương trình và kiểm tra các giả thuyết này để
tìm lỗi

11
Ca kiểm thử tốt

• Chạy ca kiểm thử với chương trình P

• Bao phủ một số yêu cầu của P;
• Bao phủ một phần chức năng của P
• Bao phủ một phần trong cấu trúc của P
• => Tiêu chuẩn bao phủ sẽ định hướng thiết kế
kiểm thử

14
Kiểm thử hộp đen

• Còn gọi là kiểm thử hàm, kiểm thử chức năng

• Tập trung vào hành vi vào/ra. Với đầu vào đã biết
ra có thể đoán/tính đầu ra, rồi kiểm tra chương trình
có tạo kết quả như ta đoán/tính.
—Không thể kiểm thử hết các bộ dữ liệu đầu vào

• Bài toán đặt ra là giảm số lượng ca kiểm thử bằng

việc chia không gian đầu vào thành các miền tương
đương
—Sau đó chọn một ca kiểm thử từ mỗi miền tương đương này.

15
Kiểm thử hộp trắng
• Còn gọi là kiểm thử cấu trúc, kiểm thử logic
• Các tiêu chuẩn bao phủ
• Lệnh
• Mọi lệnh đều được thử
• Vòng lặp
• 0, 1, >1 lần
• Đường đi
• Tất cả các khả năng chạy của chương trình
• Nhánh (if, while, ..)
• Biểu thức điều kiện được thử với cả True và False
• Các nhánh đều được chạy ít nhất một lần

• 16
So sánh kiểm thử hộp trắng và hộp đen
• Hộp trắng
• Số đường đi nhiều khi là vô hạn
• Kiểm tra những gì đã làm, không phải
những gì cần được làm
• Không phát hiện được ca kiểm thử còn
thiếu
• thích hợp cho kiểm thử hệ thống và tích
hợp
• Hộp đen
• Dễ bùng nổ tổ hợp về số ca kiểm thử
(dữ liệu đúng và dữ liệu sai)
• Thường không chắc ca kiểm thử này có
phát hiện được lỗi cụ thể kia hay không
• Thích hợp cho kiểm thử đơn vị và tích
hợp.
• Cần cả hai
• Kiểm thử hộp trắng và hộp
đen là hai thái cực của kiểm
thử
• Việc lựa chọn ca kiểm thử
nằm giữa và phụ thuộc vào
• Số đường đi logic có thể
• Tính chất của dữ liệu đầu vào
• Khối lượng tính toán
• Độ phức tạp của cấu trúc dữ liệu
và giải thuật
• Hai kỹ thuật là bổ sung
cho nhau.
17
 Kiểm thử đơn vị
Mục đích: Tìm sự khác biệt giữa đặc tả và cài đặt của đơn vị
Đơn vị: các lớp, hàm, đối tượng, gói, mô-đun

Môi trường kiểm thử đơn vi:

18
Kiểm thử tích hợp
• Mục tiêu:
• Phát hiện vấn đề khi ghép các mô-đun/thành
phần với nhau
• Các vấn đề
—Bên trong: giữa các thành phần
• Gọi: call/message passing/...
• Tham số: kiểu, số lượng, thứ tự, giá trị
• Kết quả trả về: ai, kiểu, trình tự
-Bên ngoài:
• Ngắt (wrong handler?)
• Thời gian vào ra
• Tương tác 19
 Kiểm thử hệ thống

• Liên quan đến các yếu tố bên ngoài hệ thống

• Không chỉ là kiểm tra chức năng
• Khả dụng (usability)
• Giao diện, thông báo, dễ học, dễ nhớ..
• Hiệu năng
• Khả năng đáp ứng/Tìm khả năng đáp ứng
• Tài nguyên sử dụng

20
Khi nào nên dừng kiểm thử

• Hết thời gian, hết ngân sách

• Đạt mức độ bao phủ mong muốn
• Đạt tần suất hỏng hóc mong muốn

21
 Kiểm thử chấp thuận
• Có hai loại kiểm thử chấp nhận
• Bởi cơ quan phát triển gọi là BAT
• Bởi người dùng gọi là UAT
• Mục đích: kiểm tra sự hài lòng của người sử dụng
• Cơ sở: mong muốn của người dùng
(không xét đến tài liệu đặc tả)
• Môi trường: thật
• Người thực hiện: bởi và cho người sử dụng
• Các ca kiểm thử:
• Sử dụng lại từ kiểm thử hệ thống
• Do người dùng thiết kế • 22
Kiểm thử hồi qui
• Khi một hệ thống được chỉnh sửa (sửa lỗi,
thêm/bớt chức năng,..) toàn bộ bộ kiểm thử cần
phải chạy lại
• Đảm bảo các tính năng đang hoạt động tốt không bị ảnh
hưởng bởi chỉnh sửa
• Kiểm thử lại tự động trước khi lưu thay đổi vào
kho (repo.)
• Cần các chiến lược kiểm thử tăng dần với hệ thống
lớn

23
Nhiều công cụ hỗ trợ các loại kiểm thử

• Kiểm thử đơn vị: Achoo, JUnit, Pex/Moles, PyUnit

• Tự động kiểm thử: TestComplete
• Kiểm thử hiệu năng và tải: Jmeter, LoadRunner
• Kiểm thử giao diện đồ họa (GUI): Abbot, Guitar
• Kiểm thử tổ hợp: AETG, FireEye
• Kiểm thử dựa trên mô hình: Spec Explorer
• Phân tích bao phủ: Corbertura
• Quản lý lỗi (defects): Bugzilla

24
 Tester for
Base

Kiểm thử hộp đen

Kiểm thử hộp trắng

Kiểm thử hộp xám

Phân biệt kiểm thử Alpha &Beta

Khái niệm về Bug

 Tester for
Base

Tiến trình kiểm

thử
 Tester for
Base

Các phương pháp kiểm thử

1 2 3
Kiểm thử Kiểm thử Kiểm thử
hộp đen hộp trắng hộp xám
Tester for
Base
 Tester for
Base

KIỂM THỬ HỘP ĐEN

 Tester for
Base

 Kiểm thử hộp đen

 Người kiểm thử không quan tâm đến cấu trúc bên trong
của chương trình.
 Chỉ quan tâm tới dữ liệu đầu vào – đầu ra sau khi được
xử lý.
 Chỉ tập trung vào kiểm tra chức năng của PM
 Tester for
Base

 Kiểm thử hộp đen

 Kiểm thử viên không hiểu về mã lệnh nhưng có thể tìm
ra lỗi mà dev không phát hiện ra

 Dựa theo các tài liệu đặc tả, tài liệu phân thích thiết kế
để thực hiện test

 Kiểm thử hộp đen thường do các Tester thực hiện

 Tester for
Base

 Kiểm thử hộp đen

 Tester for
Base

 Kiểm thử hộp đen

 Tester for
Base

KIỂM THỬ HỘP TRẮNG

 Tester for
Base
 Kiểm thử hộp trắng
 Tester for
Base
 Kiểm thử hộp trắng
 Khi thiết kế test case và test, các tester truy cập thẳng
vào bên trong source code, cấu trúc và thuật toán của
chương trình để xác định xem đơn vị PM thực hiện như
thế nào?
 Người kiểm thử hộp trắng phải có kỹ năng nhất định để
thông hiểu chi tiết về đoạn code cần kiểm thử
 Kỹ thuật này chủ yếu được dùng để kiểm thử mức đơn vị
 Tester for
Base
 Kiểm thử hộp trắng
 Có những lỗi xảy ra trong quá trình gõ sai phím, hiểu sai,
cú pháp của ngôn ngữ lập trình chưa đúng nên bắt buộc
phải kiểm thử hộp trắng.
 Kỹ thuật kiểm thử hộp trắng thường được các dev thực
hiện trong quá trình viết code ở giai đoạn kiểm thử mức
đơn vị luôn.
 Nguyên nhân: Khi hệ thống được tích
hợp hoàn chỉnh
việc kiểm thử hộp trắng này rất phức tạp và mất thời gian
 Chú ý: Không phải dev nào cũng đồng ý cho phép tester
join vào cấu trúc dữ liệu để test.
 Tester for
Base
 Kiểm thử hộp trắng
 Tester for
Base
 Kiểm thử hộp trắng
 Tester for
Base
Kiểm thử hộp trắng
 Giải thích code xử lý:
• (1): Nếu người dùng không nhập tên đăng nhập thì đưa ra thông
báo và không thực hiện công việc tiếp theo
• (2): Nếu người dùng không nhập mật khẩu đăng nhập thì đưa ra
thông báo và không thực hiện công việc tiếp theo
• (3): Xử lý kiểm tra tài khoản và mật khẩu nhập trên giao diện với
thông tin tài khoản, mật khẩu lưu trữ trong cơ sở dữ liệu. Nếu
chính xác sẽ đăng nhập hệ thống ngược lại sẽ đưa ra thông báo
kiểm tra lại thông tin tài khoản, mật khẩu đăng nhập.
• (4): Nếu có lỗi xảy ra trong quá trình thực hiện thì đưa ra thông
báo cho người sử dụng biết.
 Tester for
Base

KIỂM THỬ HỘP XÁM

 Tester for
Base
 Kiểm thử hộp xám
 Là kỹ thuật kiểm thử kết hợp giữa kiểm thử hộp đen &
kiểm thử hộp trắng.
 Chúng ta quan tâm đến dữ liệu đầu vào và đầu ra song
đòi hỏi có sự truy cập tới cấu trúc dữ liệu.
Mục đích: Kiểm tra hộp xám nhằm tìm ra tối đa số lỗi về cấu
trúc dữ liệu của hộp trắng cũng như lỗi về chức năng của
hộp đen.
 Tester for
Base
 Kiểm thử hộp xám

False
Điều Kiện A

True

Lệnh thực hiện

 Tester for
Base

PHÂN BIỆT KIỂM THỬ ALPHA &

BETA
 Tester for
Base
 Kiểm thử Alpha
 Kiểm thử Alpha thực hiện ngay từ khi
phần mềm
được xây dựng.
 Khi một PM nào đó phát triển sắp hoàn thiện nhưng có
sự thay đổi dù là nhỏ trong thiết kế cũng có thể phát sinh
lỗi.
 Do đó, kiểm thử Alpha rất quan trọng nhằm hoàn thiện
PM trước khi bàn giao cho phía khách hàng.
 Thường là do tester đảm nhiệm kiểm thử Alpha
 Tester for
Base
 Kiểm thử Beta
 Là bước kiểm thử mà về cơ bản các bước phát triển cũng
như kiểm thử trước đó đã hoàn thành.
 Quá trình tiến hành kiểm thử lần cuối nhằm tìm ra lỗi
cũng như kiểm chứng các ràng buộc trước khi công bố và
tiến hành phân phối sản phẩm.
 Thường thì kiểm thử Beta do phía khách hàng sẽ kiểm
thử (có thể tester sẽ là người ghi nhận những lỗi đó để
dev xử lý).
 Tester for
Base

stanford.com.vn

Sử dụng
thực tế

c hiện

Tester & KH kiểm Sửa lỗi & Cập nhật Hoàn thiện
thử PM
Hình ảnh minh họa kiểm thử Alpha và
Beta
 Tester for
Base

BUG
 Tester for
Base
 Khái niệm Bug
 Tester for
Base
 Khái niệm Bug
 Trong phần mềm, bug dùng để chỉ một lỗi
nhỏ (lớn)
trong quá trình kiểm thử PM.
 Việc tìm ra bug khiến cho PM càng
được hoàn chỉnh,
tránh sai sót tối đa khi đưa PM ứng dụng vào thực tế.
 Bug phát hiện được cần phải liên hệ và phân công cho
DEV chịu trách nhiệm sửa lỗi này.
 Tester for
Base
 Khái niệm Bug
 Thông tin đầy đủ để DEV có thể hiểu được lỗi
 Tester cho ý kiến về mức độ nghiêm trọng của
lỗi
 Xác định được nó bị lỗi ở chỗ nào?

 Có thể tái hiện lỗi khi cần

 Mô tả các bước cần để tái hiện bug

 Tester for
Base
 Khái niệm Bug
 Bug là một khiếm khuyết trong một thành phần hoặc hệ
thống mà nó có thể làm cho thành phần hoặc hệ thống
này không thực hiện đúng chức năng yêu cầu của nó.
Ví dụ:
Thông báo sai hoặc định nghĩa dữ liệu không đúng
 Tester for
Base
 Khái niệm Bug
 Ví dụ:

Bạn chưa đăng kí

Bạn chưa đăng nhập

 Tester for
Base
 Khái niệm Bug
 Việc phát hiện ra Bug có thể xảy ra theo các trường
hợp sau:
 Phần mềm không thực hiện một số việc giống như mô tả trong
bản đặc tả phần mềm
Ví dụ: Khách hàng muốn PM thực hiện công việc phân loại hồ sơ
(Mới tạo, Chờ xét duyệt, Đã duyệt)

 Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó
không được thực hiện
Ví dụ: Khách hàng không muốn PM thực hiện công việc xác nhận
chữ ký xét duyệt hồ sơ đã hoàn thành
 Tester for
Base
Học sinh nhập thông
tin muốn nhận học Hồ sơ hợp lệ
bổng du học

Học sinh được

nhận học bổng

Sai Tạo chữ kí cho giám

đốc xác nhận hồ sơ
được nhận học bổng

Hồ sơ được in
ra file Đúng
Word, giám đốc kí
 Tester for
Base
 Khái niệm Bug
 Phần mềm thực hiện một số chức năng
mà bản đặc tả không đề cập tới.
Ví dụ: PM thực hiện chức năng ký xét duyệt hồ sơ nhận học
bổng

 Trong con mắt của người kiểm thử, phần

mềm là khó
hiểu, khó sử dụng, chậm đối với người sử dụng.
Ví dụ: Khi mở một chương trình, người dùng muốn quay lại
thư mục trước đó chỉ cần nhấn nút “Back” nhưng chức năng
này thao tác chưa đúng.
 Tester for
Base
 Tài liệu chuyên dụng
 Tài liệu phân tích yêu cầu của khách hàng

 Tài liệu đặc tả sản phẩm

 Tài liệu xây dựng kế hoạch làm việc

 Tài liệu phân tích thiết kế

 Dựa theo các tài liệu trên giúp tester viết testcase phục
vụ cho việc kiểm thử PM đạt hiệu quả cao nhất.
Bài tập

• Chọn, tìm hiểu cách sử dụng một số công cụ hỗ

trợ kiểm thử đã nêu
• Tìm thêm các công cụ mới, mạnh hơn khác

25