Kiểm Thử Phần Mềm

KIỂM THỬ PHẦN MỀM
2021
NỘI DUNG
Tổng quan kiểm thử phần mềm
Quy trình và kế hoạch
Các cấp độ KT
Phương pháp & Kỹ thuật
Quản lý việc kiểm thử
Công cụ
Nhập môn lập trình 2014

TỔNG QUAN
Kiểm thử là gì?
Vì sao phải kiểm thử
Nguyên tắc
Khía cạnh tâm lý học
Các khái niệm
Nhập môn lập trình 2014

Trường ĐH Công Nghệ Sài Gòn
KHOA CÔNG NGHỆ THÔNG TIN
Kiểm thử PM là gì ?
• Là quá trình thực thi một chương trình với mục
đích là tìm ra lỗi
Glen Myers
• Là quy trình phân tích phần mềm để tìm sự khác
biệt giữa các điều kiện hiện có và điều kiện bắt
buộc và để đánh giá các tính năng của phần mềm
ANSI/IEEE 1059
4
Kiểm thử PM là gì ?
• Kiểm thử PM giúp tìm ra được sự hiện diện của lỗi
nhưng không thể chỉ ra sự vắng mặt của lỗi
Dijkstra
• Mọi phương pháp kiểm thử được dùng để ngăn

ngừa hoặc tìm ra lỗi đều sót lại những lỗi khó phát
hiện hơn
Beizer
5
VÌ SAO PHẢI TEST

“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng
ta dù cố gắng đến mức nào thì thực tế là ngay cả những lập
trình viên xuất sắc nhất cũng không có thể lúc nào cũng viết
được những đoạn mã không có lỗi. Tính trung bình, ngay cả
một lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100
dòng lệnh. Người ta ước lượng rằng việc kiểm tra để tìm ra
các lỗi này chiếm phân nửa khối lượng công việc phải làm để
có được một phần mềm hoạt động được”.
(Software Testing Techniques, Second Edition, by Boris

Beizer, Van Nostrand Reinhold, 1990, ISBN 1850328803)
6
BUG
7
BUG
8
BUG
9
BUG
• Bug ngân hàng ở Mỹ lộ 823 tài khoản,
920.000.000$
10
VAI TRÒ CỦA KIỂM THỬ
11
12
13
TEST vs DEBUG
• Test
– Tìm khiếm khuyết
– Tester ?
• Debug
– Tìm nguyên nhận
– Developer?
14
KIỂM THỬ BAO NHIÊU LÀ ĐỦ?

• Dựa vào
– Tính quan trọng của PM
– Độ bao phủ code/chức năng
– Thời gian
– Ngân sách
15
Các hoạt động của việc kiểm thử

• Lên kế hoạch và xử lý
• Lựa chọn các điều kiện kiểm thử
• Thiết kế các trường hợp kiểm thử (testcase)
• Kiểm tra kết quả
• Đánh giá các tiêu chuẩn hoàn thành
• Báo cáo quá trình kiểm thử
• Hoàn thành các hoạt động kiểm kết thúc kiểm thử
sau một giai đoạn kiểm thử đã hoàn thành
16
NGUYÊN TẮC
• KT chỉ ra sự hiện diện của những khiếm khuyết,
không chỉ ra được là PM không có khiếm khuyết
• KT toàn bộ (Exhaustive testing) là không thể
• Kiểm thử càng sớm càng tiết kiệm được thời gian
và tiền bạc
• Sự tập trung của các lỗi
• Pesticide paradox
• KT phụ thuộc vào ngữ cảnh
• Ngụy biện không có lỗi
17
KHÍA CẠNH TÂM LÝ HỌC

• Tính độc lập
• Đoán lỗi
• KT thường được cọi là 1 hành động phá hoại?
• Test leader và tester cần có kỹ năng giao tiếp tốt để
truyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro
• Khách quan, tập trung vào thực tế mà ko có sự thù
ghét cá nhận
• Mục tiêu chung là giúp hệ thống đạt chất lượng tốt
hơn
18
CÁC KHÁI NIỆM

• Error: là một sự nhầm lẫn hay một sự hiểu sai trong
quá trình phát triển phần mềm của developer
• Fault hay defect: xuất hiện trong phần mềm như là
kết quả của một sai sót
• Failure: là kết quả của một lỗi xuất hiện làm cho
chương trình không hoạt động được hay hoạt động
nhưng cho kết quả không như mong đợi
19
CÁC KHÁI NIỆM

• Dữ liệu thử (test data): dữ liệu vào cần cung cấp
cho phần mềm trong khi thực thi
• Kịch bản kiểm thử (test scenario): các bước thực
hiện khi khi kiểm thử
• Phán xét kiểm thử (test oracle)
Đánh giá kết quả của kiểm thử
- tự động: chương trình
- thủ công: con người
20
CÁC KHÁI NIỆM

• Verification: là quy trình xác định xem sản phẩm của một công đoạn
trong quy trình phát triển phần mềm có thỏa mãn các yêu cầu đặt ra
trong công đoạn trước haykhông?(Ta có đang xây dựng đúng sản
phẩm mà được đăc tả không?)
• Xác minh quan tâm tới việc ngăn chặn lỗi giữa các công đoạn
• Xác minh thường là hoạt động kỹ thuật và nó có sử
• dụng các kiến thức về các yêu cầu, các đặc tả rời rạc của phần mềm
• Các hoạt động của xác minh bao gồm: Kiểm thử
• (Testing) và Rà soát loại (Review)
21
CÁC KHÁI NIỆM

VALIDATION
• Là tiến trình nhằm chỉ ra toàn bộ hệ thống đã phát
triển xong phù hợp với tài liệu mô tả yêu cầu.
• Là quá trình kiểm chứng chúng ta xây dựng phầm
mềm có đúng theo yêu cầu khách hàng không?
• Chỉ quan tâm đến sản phẩm cuối cùng không còn
lỗi
22
QUY TRÌNH và KẾ HOẠCH
Mô hình kiểm thử
Kế hoạch KT
KT thành phần
KT tích hợp
KT hệ thống
Kiểm thử phần mềm

Mô hình thác nước

Chia quá trình phát triển PM
thành những giai đoạn tuần tự
Mỗi giai đoạn có 1 mục đích
nhất định
Kết quả giai đoạn này sẽ là
đầu vào cho giai đoạn sau
24
Mô hình thác nước

• Ưu điểm
- Các giai đoạn được định nghĩa, đầu vào rõ ràng 
dễ phân công
- Quá trình phát triển đơn giản  dự án ít thay đổi
- Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế
• Khuyết điểm
- Tốn nhiều thời gian để thực hiện
- Sữa lỗi tốn nhiều chi phí (đặc biệt là lỗi trong giai
đoạn đầu)
25
Mô hình chữ V
26
Mô hình chữ V
• ƯU ĐIỂM
– Các pha tương thích nhau, hỗ trợ cho nhau
– Khuyến thích các hoạt động liên quan đến kế
hoạch kiểm thử
– Kiểm thử từ giai đoạn đầu
• KHUYẾT ĐIỂM
– Pha sau chỉ được thực hiện khi pha trước kết
thúc
– Chỉ phù hợp các dự án có đầy đủ thông tin và
ít thay đổi.
27
MÔ HÌNH SCRUM-AGILE
28
KT TRONG MÔ HINH SCRUM
29
Sơ đồ tổ chức phổ biến của đội kiểm thử
30
QUY TRÌNH KIỂM THỬ
31

• Phân tích yêu cầu
Xác định các chức năng cần kiểm tra
Tài liệu chứa các câu hỏi và câu trả lời liên quan đến
nghiệp vụ của hệ thống, tài liệu báo cáo tính khả thi,
phân tích rủi ro của việc kiểm thử phần mềm
• Lập kế hoạch kiểm thử
• Xác định phạm vi dự án
• Xác định phương pháp tiếp cận
• Xác định các nguồn lực
Test plan
• Lên kế hoạch thiết kế công việc test
32

• Thiết kế kịch bản
– Đầu vào là test plan
– Review tài liệu
– Viết test case/ check list
– Chuẩn bị data test
– Review test case/ check list
=>test design, test case, check list, test data, test
automation script
33

• Thiết lập môi trường
– Đầu vào: test plan, test case, test data
– Phụ thuộc vào đặc thù của PM và yêu cầu của KH
– VD: dựng server, mạng, …
34

• Thực hiện
– Đầu vào: test plan, test design, test case, check list, test
data, test automation script
– Thực thi test case
– Đưa các bug lên hệ thống quản lý lỗi để theo dõi
– Re-test
– KT hồi qui
– Theo dõi và phân tích tiến độ
– Lập báo cáo
35
Quy trình thực hiện
36
Quy trình xử lý lỗi
37

• Kết thúc
– Đầu vào là tất cả các tài liệu, báo cáo có liên quan
– Thực hiện tổng kết, báo cáo kết quả về việc thực thi test
case
– Đánh giá các tiêu chí hoàn thành
– Thảo luận tất cả những điểm tốt, điểm chưa tốt và rút ra
bài học kinh nghiệm
38
Các hoạt động chính trong giai đoạn kết thúc KT

1. Kiểm tra các sản phẩm thực tế được bàn giao so với kế hoạch. Đảm bảo
các lỗi được giải quyết hay có kế hoạch giải quyết cho các lần bàn giao sau
2. Đóng các báo cáo về sự cố hoặc ghi chép các thay đổi cho bất cứ vấn đề
nào còn đang để mở
3. Viết biên bản chấp nhận phần mềm
4. Lưu trữ các sản phẩm kiểm thử, môi trường kiểm thử và cơ sở hạ tầng cho
các lần sử dụng sau
5. Bàn giao các sản phẩm kiểm thử cho các bộ quản lý dữ liệu và bảo trì sản
phẩm
6. Phân tích các bài học để xác định những điểm cần thay đổi cho dự án sau
7. Sử dụng các thông tin thu thập được để cải tiến công việc kiểm thử một
cách định kỳ.
39
KẾ HOẠCH
Người thực
Hành động Đầu vào Đầu ra
hiện
Xác định các yêu cầu kiểm thử:
– Yêu cầu từ khác h hàng, đặc tả Danh sách các
yêu cầu người sử dụng, tiêu chí yêu cầu cần test,
Test lead, Tài liệu
được chấp nhận, thiết kế chi tiết gồm cả chức
Tester, yêu cầu
(nếu có), những ràng buộc của năng và phi chức
khách hàng năng
– Xác đinh những gì cần phải test
Xác định phương thức, loại kiểm Phương thức kiểm
thử cần thực hiện, tiêu chí đầu ra thử, tiêu chí đầu
Test lead
Những vấn đề lưu ý đặc biệt, điều ra, điều kiện tiến
kiện thực hiện test hành kiểm thử
40
KẾ HOẠCH
Người thực
hiện
Xác định nguồn lực và môi trường thực hiện
Khi xác định
kiểm thử:
được các yêu
– Số lượng người, kỹ năng cần có
Test lead cầu kiểm thử Danh sách tài nguyên
– Yêu cầu về phần cứng, phần mềm
dự án phầm
– Công cụ hỗ trợ (nếu có)
mềm
– Loại dữ liệu
Khi xác định
Bảng thời gian cụ thể
được tài
Lập thời gian cho các giai đoạn kiểm thử Test lead cho từng giai đoạn
nguyên, nhân
kiểm thử
lực
41
KẾ HOẠCH
Người thực
hiện
Đánh giá kế hoạch
Trưởng dự án sẽ cùng những người liên quan
Khi các yêu
tham gia đánh giá xem bản kể hoạch kiểm
Test lead cầu bên trên Tài liệu Test Plan
thử có phù hợp với yêu cầu của dự án chưa.
đã rõ ràng
Nếu chưa thì test lead sẽ phải thực hiện sửa
lại theo yêu cầu.
Tạo base line:
Khi đã xây
Khi kế hoạch test đã được duyệt thì bản kế Tài liệu testplan được
Test lead dựng xong
hoạch này sẽ được đánh baseline và chuyển duyệt.
test plan
vào thư mục baseline được tạo
Test lead sẽ gửi thông báo qua mail tới toàn
bộ những người trong dự án có liên quan về Test lead
tài liệu Test Plan này.
42
QUY TRINH XÂY DỰNG KH KT
43
Các thành phần chính trong KHKT

1. Giới thiệu
2. Điều kiện chấp nhận
3. Yêu cầu để KT
4. Chiến lược
5. Nguồn lực
6. Test milestone
7. Deliverables of test: Test Plan, Test Case, Test Reports
44
1. Giới thiệu
• Mục đích: Trình bày ngắn gọn về mục đích và tổ chức của tài liệu
• Các định nghĩa, từ viết tắt, thuật ngữ: cung cấp các định nghĩa của các thuật ngữ, từ viết
tắt cần thiết để giải thích đúng các kế hoạch kiểm thử
• Tài liệu tham khảo: Liệt kê tất cả những tài liệu dùng để tạo ra bản kế hoạch
• Thông tin cơ bản: Mô tả ngắn gọn về dự án
• Phạm vi kiểm thử:
– Danh mục các giai đoạn kiểm thử
– Danh sách các loại hình kiểm thử
– Danh sách các giả định
– Các khiểm khuyết theo dự kiến
• Danh mục các rủi ro: Liệt kê các rủi ro có thể ảnh hưởng đến việc thiết kế hoặc thực thi
các KT
• Nhu cầu đào tạo: Liệt kê các nhu cầu đào tạo của các thành viên trong nhóm để thực
thi việc KT
45
2. Các tiêu chí chấp nhận

• Danh sách các tiêu chí nhằm xác định mức độ chất
lượng kiểm thử đủ để bàn giao cho khách hàng
hoặc đủ để sang pha tiếp theo
• Các tiêu chí có thể là:
– Tỷ lệ bao phủ của kiểm thử
– Tỷ lệ bao phủ thành công
– Số lượng ca kiểm thử
– Tỷ lệ lỗi tìm được
– Tỷ lệ bỏ qua lỗi
– …
46
3. Yêu cầu cần KT

• Liệt kê các yêu cầu kiểm thử
– Yêu cầu chức năng
– Yêu cầu phi chức năng
• Liệt kê các đặc tính và chức năng không cần KT
47
4. Chiến lược
• Mô tả việc kiểm thử sẽ được thực hiện như thế nào.
Gồm có
– Các loại kiểm thử: mỗi loại kiểm thử cụ thể cho từng loại
yêu cầu của phần mềm
– Các cấp độ kiểm thử: cấp độ kiểm thử nào sẽ được thực
hiện và loại kiểm thử nào sẽ được thực hiện ở mỗi cấp
độ
• Công cụ kiểm thử: liệt kê đầy đủ các công cụ hỗ trợ
kiễm thử
48
4. Chiến lược
Có 2 chiến lược kiểm thử cơ bản:
• Kiểm thử Big bang(kiểm thử vụ nổ lớn): là chiến lược kiểm
thử tích hợp hệ thống một lần duy nhất để được module
chức năng (hay hệ thống hoàn chỉnh)
• Kiểm thử gia tăng: chiến lược kiểm thử từ thấp tới cao,bao
gồm 4 mức:
– Kiểm thử đơn vị
– Kiểm thử tích hợp
– Kiểm thử hệ thống
– Kiểm thử chấp nhận
49
5. Nguồn lực
• Nguồn lực hỗ trợ cho hoạt động kiểm thử gồm 2
loại:
– Nhân lực: khi liệt kê phải chỉ rõ người nào làm công việc
gì
– Nguồn lực hệ thống: liệt kê các phần mềm phần cứng
để đáp ứng cho việc kiểm thử
50
6. Test milestone
• Một milestone là một sự kiện, một thành tích KT
quan trọng đạt được hay cần đạt được của dự án.
• Mỗi cột mốc kiểm thử phải bao gồm ít nhất một
hoạt động kiểm thử và đạt được một hoặc nhiều
sản phẩm kiểm thử.
51
7. Deliverables of test
• Liệt kê tên sản phẩm cần bàn giao
• Ngày bàn giao
• Người bàn giao
• Bàn giao cho ai
52
CẤP ĐỘ KIỂM THỬ
KT UNIT
KT Module
KT tích hợp
KT hệ thống
KT chấp nhận

KT UNIT
• Mức độ KT thấp nhất
• KT các đơn vị/thành phần độc lập
• Mục đích là để đánh giá mỗi đơn vị của PM thực
hiện đúng như thiết kế
• Được thực hiện bởi các LTV
54
KT UNIT
• Các vấn đề quan tâm trong UNIT test
– Sự hoàn chỉnh và đúng đắn của các chức năng
– Xử lý lỗi
– Kiểm tra giá trị đầu vào
– Tính đúng đắn của giá trị đầu ra
– Tối ưu thuật toán
55
KT UNIT
• Để thực hiện KT unit hiệu quả cần:
– Các đơn vị KT phải độc lập
– Thực hiện lặp đi lặp lại
– Test tự động
– Phải dễ viết
– Dễ thực hiện
– Đo được
56
LỢI ÍCH CỦA KT UNIT

• Giúp LTV điều chỉnh code sau này nhưng vẫn đảm
bảo tinh đúng đắn của đơn vị
• KT các giai đoạn sau sẽ nhanh hơn
• Phát hiện bug sớm => ít tốn kinh phí hơn
57
Kỹ thuật áp dụng trong KT UNIT

• KT hộp trắng
– KT statement, branch, path, condition
• KT hộp đen
– Input domain
– Giá trị biên
– Phân vùng tương đương
58
KT Module
• Còn gọi là component testing
• Được thực hiện bởi tester
• Được thực hiện sau UNIT Testing
• Xác nhận các yêu cầu kiểm thử
59
Quy trình KT Module

• Mỗi module mã nguồn không phải là một chương
trình hoàn chỉnh và đôi khi phải gọi các module
chưa được kiểm thử khác => có thể phải thiết lập
driver và/hoặc stub: phí tổn khá lớn (70%)
• Driver là một chương trình chính có nhiệm vụ
nhận dữ liệu kiểm thử, chuyển dữ liệu đó xuống cho
module để kiểm tra và in ra các kết quả kiểm tra
tương ứng.
• Stub thay thế các module được gọi bởi module
đang kiểm tra
60
61

BEGIN
Module
Test Planning
Module
Test Specification
Module
Test Execution
Module
Test Recording
Checking for
Module END
Test Completion
62
• Có 2 phương án để KT Module
– Kiểm tra thành phần ở quy mô nhỏ (CTIS)
Kiểm thử các module chức năng độc, tách biệt với các
thành phần khác.
– Kiểm tra thành phần ở dạng lớn (CTIL)
Được thực hiện mà không bị cô lập với các thành phần
khác của phần mềm
63
KT Tích hợp
• Kiểm thử tích hợp nhằm nhận được một bộ phận
chức năng hay một hệ con tốt
• Là một kỹ thuật có tính hệ thống để xây dựng cấu
trúc của chương trình
• Từ các module đã qua kiểm thử đơn vị, xây dựng
cấu trúc chương trình đảm bảo tuân theo thiết kế
•
64
• Có hai cách tích hợp:

• Tích hợp từng bước. Theo cách này có 3 chiến
lược:
– Tích hợp từ dưới lên (bottom-up testing)
– Tích hợp từ trên xuống (top-down testing)
– Kết hợp 2 chiến lược trên (sandwich testing)
• Tích hợp đồng thời: kiểm thử vụ nổ lớn (big bang
testing)
65
KT top-down
• Bắt đầu từ module gốc ở trên cùng của cây cấu trúc
chương trình.
• Sau khi kiểm thử xong module hiện hành, ta chọn
module kế tiếp theo ý tưởng :
– Module kế tiếp phải được dùng trực tiếp bởi module
được kiểm thử rồi.
– Vì có nhiều module cùng thỏa mãn điều kiện trên, nên
ta chọn module thực hiện nhiều hoạt động I/O trước.
– Rồi chọn module "critical", là module dùng thuật giải
phức tạp, tiềm ẩn nhiều lỗi và/hoặc lỗi nặng nhất.
66
KT top-down
67
KT top-down
• Testcase cho module A
– Ví dụ chỉ có B cung cấp thông tin cho A
Xây dựng stub B
• Sau khi kiểm thử xong module hiện hành, ta chọn
1 trong các Stub và thay thế nó bằng module thật
rồi kiểm thử module thật này
68
KT top-down
• ABCDEFGHIJKL • ADHIKLCGBFJE
• ABEFJCGKDHLI • ABFJDIECGKHL
• ...
69
Ưu điểm của phương pháp top-down

• Phát hiện sớm các lỗi thiết kế: dễ dàng phát hiện
các lỗi như phát triển nhầm, thiếu chức năng so với
đặc tả, do đó làm giảm chi phí cho việc thiết kế và
cài đặt lại.
• Chương trình khung sườn sớm hình thành để demo
và tiếp thêm sức mạnh tinh thần cho những người
phát triển phần mềm.
70
Khuyết điểm của phương pháp top-down

• Tạo stub thường phức tạp
• Nếu module nhập/xuất xa với module cần test =>
rất khó cung cấp dữ liệu
71
KT bottom-up
• Bắt đầu từ 1 hay nhiều module lá : module mà
không gọi module nào khác.
• Module kế tiếp phải dùng trực tiếp 1 hay nhiều
module được kiểm thử rồi.
• Chọn module thực hiện nhiều hoạt động I/O trước.
• Kế đến là module "critical“: module dùng thuật giải
phức tạp, tiềm ẩn nhiều lỗi
72
KT bottom-up
• Các module E, J, G, K, L
và I ₫ược kiểm thử trước
• Để kiểm thử 1 module,
ta phải viết driver
• Driver dễ tạo ra hơn
stub
73
KT bottom-up
• Nếu D và F là 2 module critical nhất, thì ta nên
kiểm thử theo trình tự của hình vẽ dưới đây
74
Ưu điểm KT bottom-up
• Nếu các lỗi xảy ra có khuynh hướng nằm trong các
module mức thấp thì phương pháp bottom-up sẽ
giúp phát hiện sớm chúng.
• Việc tạo các điều kiện kiểm thử sẽ dễ dàng hơn.
• Việc quan sát các kết quả kiểm thử cũng dễ dàng
hơn.
75
Khuyết điểm KT bottom-up

• Phải viết các module driver, mặc dù việc viết các
module này khá dễ dàng.
• Chương trình khung sườn chưa tồn tại 1 thời gian
dài cho đến khi module cuối cùng được tích hợp
vào hệ thống.
76
KT hệ thống
• Kiểm thử hệ thống:
– Tìm kiếm các lỗi, nhưng 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
– Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện
lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài,
chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm
dụng bộ nhớ
– Đòi hỏi nhiều thời gian, công sức, thiết bị…
– Mục đích: kiểm thử thiết kế và toàn bộ hệ thống có thỏa
mãn yêu cầu đặt ra hay không tìm.
77
KT hệ thống
• Khi nào có thể thực hiện KT hệ thống?
– Hệ thống cần kiểm thử đã hoàn thiện
– Kiểm thử tích hợp và đơn vị đã hoàn thành
– Sản phẩm được tích hợp đúng thiết kế
– Các tài liệu đặc tả đã là bản cuối cùng
– Các tài liệu hỗ trợ kiểm thử như test plan, test case đã
hoàn thành.
78
KT hệ thống
Installation
Testing Functionality
Usability Testing
Testing
Interoperability
Security Testing
Testing
Document System Testing Recoverability

Testing Testing
Regression Performance
Testing Testing
Reliability Load & Stability

Testing Scalability Testing
Testing
79
PP và KT KIỂM THỬ
Phương
pháp KT
Kỹ thuật KT

Phương pháp KT
• Hộp đen
• Hộp trắng
• Hộp
81
KT hộp đen
• Coi hệ thống là một hộp đen,
không thể thấy được cấu trúc
logic bên trong
• Tập trung vào các yêu cầu
chức năng của phần mềm
dựa trên các dữ liệu lấy từ đặc
tả
82
KT hộp đen
• Đặc trưng của KT hộp đen
– Kiểm tra xem PM có đủ chức năng chưa
– Các chức năng có đúng không
– Thực hiện các phép thử qua giao diện
• Một vài kỹ thuật được áp dụng trong KT hộp đen
– Phân vùng tương đương
– Phân tích giá trị biên
– Bảng hỗ trợ quyết định
83
Phân vùng tương đương

• Chia miền đầu vào của một chương trình thành các
lớp dữ liệu
• Lớp tương đương biểu thị cho tập các trạng thái hợp
lệ hay không hợp lệ đối với điều kiện vào
• Các lớp tương đương được xác định bằng cách lấy
mỗi trạng thái đầu vào (thường là 1 câu hay 1 cụm
từ trong đặc tả) và phân chia nó thành 2 hay nhiều
nhóm
84

• Ví dụ
85

• Nguyên tắc xác định lớp tương đương
– Nếu điều kiện đầu vào định rõ giới hạn của một mảng,
hoặc một giá trị xác định thì chia vùng tương đương
thành:
• Một lớp tương đương hợp lệ
• Hai lớp không hợp lệ
• Một lớp đặc biệt (nếu có)
86

• Nguyên tắc xác định lớp tương đương
– Nếu điều kiện đầu vào chỉ định là một tập giá trị, hoặc
xác định là một kiểu đúng sai thì chia vùng tương đương
thành :
• Một lớp tương đương hợp lệ.
• Một lớp tương đương không hợp lệ.
• Một lớp đặc biệt (nếu có)
87

• Ví dụ:Khi cấp số thẻ thành viên clb, 3 số đầu của
số thẻ phải nằm trong khoảng [111, 222], nếu sai
sẽ có thông báo yêu cầu nhập lại, 2 số cuối phải
thuộc khoảng [11,99].
• Các lớp tương đương:
– Đối với 3 số đầu:
• >= 111 và <= 222: hợp lệ
• > 222: không hợp lệ
• <111 : không hợp lệ
• Để trống : trường hợp đặc biệt thuộc không hợp lệ
88

• Đối với 2 số đầu:
– >= 11 và <= 99: hợp lệ
– 99: không hợp lệ
– Để trống : trường hợp đặc biệt thuộc không hợp lệ
89
Phân tích giá trị biên

• Tập trung phân tích các giá trị biên của miền dữ
liệu để xây dựng dữ liệu kiểm thử
• Nguyên tắc : đối với một biến, kiểm thử các dữ liệu
vào gồm:
– Giá trị nhỏ nhất: min
– Giá trị gần kề lớn hơn giá trị nhỏ nhất: min+1
– Giá trị gần kề nhỏ hơn giá trị nhỏ nhất: min -1
– Giá trị lớn nhất : max
– Giá trị gần kề lớn hơn giá trị lớn nhất: max+1
– Giá trị gần kề nhỏ hơn giá trị lớn nhất: max-1
90

• Ví dụ phân tích giá trị biên của trường hợp sau:
20<= Nhiệt độ <=40
– Các giá trị biên có thể:
• Nhiệt độ =20 độ
• Nhiệt độ = 21độ
• Nhiệt độ= 19 độ
• Nhiệt độ = 40 độ
91

• Đối với 2 đầu vào x1, x2 có điều kiện x1∈ [a,b],
x2∈[c,d]
92

• Ví dụ: Khi cấp số thẻ thành viên clb, 3 số đầu của
số thẻ phải nằm trong khoảng [111, 222], nếu sai
sẽ thông báo yêu cầu nhập lại, 2 số cuối phải thuộc
khoảng [11,99].
• Ca kiểm thử các trường hợp đúng: (111,11),
(111,99), (222,11),(222,99)
• Ca kiểm thử các trường hợp sai: (111,10),
(111,100), (222,10), (222,100), (223,99),
(223,11),(110,11),(110,99)
93

• Các ca kiểm thử
94
Bảng hỗ trợ quyết định
95
Bảng hỗ trợ quyết định
96
97
98
Kiểm thử hộp trắng

• Kiểm tra các đoạn mã chương
trình xem nó có vận hành
đúng như thiết kế hay không.
• Kiểm thử hộp trắng dựa trên
việc xem xét cấu trúc bên
trong của chương trình theo
cấu trúc điều khiển và hoạt
động của chúng
99
Kiểm thử hộp trắng

• Đường thi hành (Execution path):
– Là 1 kịch bản thi hành đơn vị phần mềm tương ứng
– Là danh sách có thứ tự các lệnh được thi hành ứng với 1
lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm
nhập của đơn vị phần mềm đến điểm kết thúc của đơn
vị phần mềm.
100
Đường thi hành
101
Các ký hiệu đồ thị dòng điều khiển
102
VÍ DỤ SƠ ĐỒ DÒNG ĐIỀU KHIỂN
103
Xác định đường thi hành

• Dựa vào sơ đồ dòng điều khiển
• Xác định độ phức tạp cyclomatic
V(G)=E-N+2
//E là số cạnh, N là số đỉnh
• Xác định số đường thi hành tuyến tính
• Tạo test case cho từng đường thi hành
• Kiểm thử trên từng test case
• So sánh kết quả có được với kết quả kỳ vọng
• Lập báo cáo
104
Các cấp độ phủ

• Phủ cấp 0: kiểm những gì có thể kiểm thử được,
phần còn lại để người dùng phát hiện và báo lại sau
• Phủ cấp 1: kiểm thử sao
cho mỗi lệnh được thực
thi ít nhất 1 lần
105

• Phủ cấp 2: sao cho mỗi điểm quyết định luận lý
đều được thực hiện ít nhất 1 lần cho trường hợp
TRUE lẫn FALSE nên còn được gọi là Phủ các
nhánh (Branch Coverage)
Với hàm foo trên thì cần bao nhiêu test case?
106

• Phủ cấp 3: Mỗi điều kiện luận lý con của từng điểm
quyết định thực hiện 1 lần
? ?
107

• Phủ cấp 4: Kết hợp phủ cấp 2 và cấp 3
• Với những test case trong trường hợp phủ cấp 3 có
phủ luôn cấp 4 không?
•
108
KT hộp xám
109
KT hộp trắng
• Lợi ích của KT hộp trắng:
– Thử nghiệm hộp xám cung cấp các lợi ích kết hợp của
cả thử nghiệm hộp trắng và hộp đen
– Nó dựa trên đặc tả chức năng, Sơ đồ UML, Sơ đồ Cơ sở
dữ liệu hoặc kiến trúc
– Tester có thể thiết kế kịch bản KT phức tạp một cách
thông minh hơn
110
KT TỰ ĐỘNG
Tổng quan
Quy trình
Ưu, khuyết điểm
Công cụ

Tổng quan KT tự động

• Áp dụng các công cụ giúp thực hiện việc kiểm
thử phần mềm.
• Nên sử dụng công cụ tự động khi:
– Không đủ tài nguyên
– Kiểm thử hồi quy
– Kiểm tra khả năng vận hành của phần mềm trong
môi trường đặc biệt.
• Test script: nhóm mã lệnh đặc tả kịch bản
dùng để tự động hóa một trình tự kiểm thử.
• Test scipt: có thể tạo thủ công hoặc tạo tự
động dùng công cụ kiểm thử tự động
112
Quy trình kiểm thử tự động
113

1. Tạo test script
Giai đoạn này ta dùng test tool để ghi lại các thao tác
lên PM cần kiểm tra và tự động sinh ra test script
2. Chỉnh sửa test script

Chỉnh sửa lại test script thực hiện kiểm tra theo đúng
yêu cầu đặt ra, cụ thể là làm theo test case cần thực
hiện
114

3. Chạy test script để kiểm thử tự động
Giám sát hoạt động kiểm tra phần mềm của test script
4. Đánh giá kết quả

Kiểm tra kết quả thông báo sau khi thực hiện kiểm thử
tự động. Sau đó bổ sung, chỉnh sửa những sai sót
115
Ưu điểm kiểm thử tự động

• Kiểm thử phần mềm không cần can thiệp của
tester
• Giảm chi phí thực hiện kiểm tra số lượng lớn các
test case hoặc test case lặp lại nhiều lần
• Giả lập tình huống khó có thể thực hiện bằng tay
116
Khuyết điểm kiểm thử tự động

• Mất chi phí tạo các script để thực hiện kiểm thử tự
động
• Tốn chi phí dành cho bảo trì các script
• Đòi hỏi tester phải có kỹ năng tạo và thay đổi script
cho phù hợp test case
• Không áp dụng tìm được các lỗi mới cho phần mềm
117
Một vài framework dùng

• PHPUnit
• JUnit
• NUnit
• …
118
PHPUnit
• Cài đặt
• Assertion &Annotations
• Test Dependencies
• Data Providers
• Testing Exceptions
• Testing PHP Errors
• Testing Output
• Incomplete and skip test
• Test Doubles
119
CÀI ĐẶT PHPUNIT

• Cách 1
– Tạo 1 thư mục (VD: C:\phpunit) để chứa file
https://phar.phpunit.de/phpunit-|version|.phar
– Vào cmd và chuyển đến C:\phpunit
– Gõ lệnh echo @php "%~dp0phpunit.phar" %* >
phpunit.cmd
– Gõ lệnh exit
– Test phpunit bằng lệnh phpunit --version
120
CÀI ĐẶT PHPUNIT

• Cách 2
– Cài composer
– Mở cmd
– Vào thư mục chứa project
– composer require --dev phpunit/phpunit ^|version|
– Xác định cấu trúc thư mục project trong file composer.json
– Cấu hình phpunit.xml
– Chạy: đứng tại thư mục chứa project gõ
vendor\bin\phpunit
121
ASSERTIONS
• Xác nhận 1 khẳng định
– Ví dụ: assertTrue($v) muốn xác nhận rằng $v có phải mang gí trị
là true không
• Một vài assertion thông dụng
– assertTrue($v)
– assertFalse($v)
– assertEquals($expectedResult, $result);
– assertNotEquals($expectedResult, $result);
– assertEmpty($array); assertNotEmpty($array);
– assertArrayHasKey($expectedKey,$array);
– assertContains($expectedValue,$array)
122
VÍ DỤ ASSERTION
• $this->assertEquals(1,1); //OK
• $this->assertEquals(1,0); //Fail
• $this->assertContains(10,array(1,2,3,4,5));//OK
• $this->assertContains(10,array(1,2,3,4,5));//Fail
•
assertThat(mixed $value, PHPUnit\Framework\Con
straint $constraint[, $message = ''])
123
ANNOTATIONS
• Thông tin mô tả của 1 codeblock
• Phải được đặt trong /** ... */
• Một vài assertion
– @after
– @before
– @depends
– @dataProvider
– @expectedException
– @test
124
TEST DEPENDENCES
• Thể hiện mối quan hệ giữa các phương thức
• Khai báo
• @depends anotherFunction
• Một function có thể có nhiều @depends
• Kết quả từ các hàm producer thành tham số cho
các hàm consumer
125
DATA PROVIDERS
• Một hàm có thể sinh ra dữ liệu test cho các hàm khác. Ví dụ:
/** public function additionProvider()
* @dataProvider additionProvider {
*/ return [
[0, 0, 0],
public function testAdd($a, $b, $expected)
[0, 1, 1],
{
[1, 0, 1],
$this->assertSame($expected, $a + $b); [1, 1, 3]
} ];
}
126
DATA PROVIDERS
• Phương thức data provider phải là public
• Kết quả trả về là 1 mảng 2 chiều
• Có thể đặt tên cho các bộ dữ liệu test
– VD: 'adding zeros' => [0, 0, 0]
• Dữ liệu dùng để test có thể được lưu trong file csv
127
DEPENDS & DATA PROVIDER

• Khi 1 hàm nhận dữ liệu đầu vào từ dataProvider và
kể cả depends thì thứ tự nhận vào là data provider
trước.
• Có thể sử dụng nhiều dataProvider cho 1 hàm
• Nếu hàm a phụ thuộc vào hàm b mà hàm b sử
dụng dataProvider. Nếu có 1 data set sai thì hàm a
có chạy không?
128
TESTING EXCEPTIONS
• Sử dụng hàm expectException()
public function testException()
{
$this->expectException(InvalidArgumentException::class);
}
• Hoặc sử dụng annotation

/**
* @expectedException ExpectedException
*/
129
PHP ERRORS
• PHPUnit chuyển errors, warnings, and notices
sang exception.
130
INCOMPLETE TEST
• Đánh dấu 1 hàm test chưa hoàn thành:
Thêm $this->markTestIncomplete ();
Hoặc thêm $this->markTestIncomplete (‘message’);
• Nếu thểm maskTestIncomplete vào hàm setup thì

ra sao?
131
SKIPPED TEST
• Vì lý do nào đó mà bạn muốn bỏ qua 1 hàm test thì
có 2 cách để thực hiện
– C1: Thêm $this->markTestSkipped();
– Hoặc $this->markTestSkipped(‘message’);
– C2: Thêm annotation @requires
Any PHP version @requires PHP @requires PHP
PHP
identifier 5.3.3 7.1-dev
Any PHPUnit @requires @requires
PHPUnit
version identifier PHPUnit 3.6.3 PHPUnit 4.6
A regexp
@requires OS @requires OS
OS matching PHP_O
Linux WIN32|WINNT
S
132
TEST DOUBLES
• Nếu test class A có gọi đến class B mà class B
chưa có thì sao?
• Làm sao để mô phỏng 1 object khác?
• Các loại test doubles
– Dummy
– Stubs
– Spy
– Mocks
133
DUMMY OBJECT
• Dummy Object là đối tượng chỉ cần cho có để đủ số
lượng, không làm gì
class Ab class AbTest extends TestCase
{ {
public $a;
public function testProcessBCorrectly()
public $b;
public function __construct(A $a,B $b) {
{ $a=$this->getMockBuilder('A')->getMock();
$this->a=$a; $b=$this->getMockBuilder(‘B')->setMethods(['process'])-
$this->b=$b; >getMock();
} $b->expects($this->once())->method('process')
public function processA()
->will($this->returnValue(true));
{
return $this->a->process(); $ab=new Ab($a,$b);
} $this->assertTrue($ab->processB());
public function processB() }
{
}
return $this->b->process();
}
}
134
STUBS
• Stub object chứa các phương thức mà có kết quả
do ta định trước
• Không giả lập phương thức private và protected
• VD như $b trong ví dụ trước
135
MOCK OBJECT
• Quan tâm có chạy hay chưa hơn là kết quả trả về
• Thường được sử dụng khi test các đối tượng có liên
quan với nhau.
• VD:
– Có class Subject, trong class có phương thức attach.
Tham
$obj = $this->createMock(‘Class_Name);
$obj->expects($this->exactly(3))
->method('debug');
136
MOCKING
• Thường được sử dụng khi test các đối tượng có liên
quan với nhau.
• Quan tâm có chạy hay chưa hơn là kết quả trả về
137
QUẢN LÝ VIỆC KT
Tổ chức
Lập kế hoạch và đánh giá
Định lượng tiến triển
Quản lý cấu hình
Quản lý lỗi và sự cố

Tổ chức kiểm thử

• Công việc nhóm
• Tổ chức nhóm
• Vai trò các thành viên
139
Công việc của nhóm kiểm thử

• Điều khiển chất lượng/kiểm thử
– Quản lý rủi ro
– Đánh giá chất lượng
• Bảo đảm chất lượng
– Quản lý Test/QC
– Đảm bảo chất lượng sản phẩm thông qua quy trình
140
Vai trò của test manager

• Đưa ra chiến lược kiểm thử và lập kế hoạch
• Viết và rà soát lại chính sách kiểm thử
• Tư vấn kiểm thử cho các dự án khác
• Đánh giá kiểm thử
• Thu nhận tài nguyên kiểm thử
• Lãnh đạo đặc tả, chuẩn bị hiện thực và thực thi
kiểm thử
• Theo dõi và điều khiển kiểm thử
•
141

• Bố trí kế hoạch kiểm thử dựa trên các kết quả kiểm
thử sao cho thích hợp
• Đảm bảo cấu hình quản lý của testware
• Đảm bảo tiến độ
• Theo dõi tiến trình kiểm thử, đánh giá chất lượng
của kiểm thử và sản phẩm
• Dự kiến mọi sự tự động hóa kiểm thử
142

• Chọn công cụ và tổ chức đào tạo nhân viên.
• Đảm bảo việc hiện thực môi trường kiểm thử
• Lập lịch các kiểm thử
• Viết báo cáo tóm tắt
143
Vai trò của tester

• Xem xét và góp ý cho kế hoạch kiểm thử
• Phân tích, cân nhắc và ước định các yêu cầu của
người dùng, các đặc tả.
• Tạo ra các bộ kiểm thử, các mẫu, dữ liệu và các thủ
tục cho kiểm thử
• Cài đặt môi trường kiểm thử.
• Thực hiện đầy đủ các kiểm thử trên các cấp độ
kiểm thử
144

• Thực thi và ghi nhận các kiểm thử, đánh giá kết quả
và lập tài liệu các “lỗi”tìm thấy
• Giám sát quá trình kiểm tra sử dụng các công cụ
thích hợp
• Kiểm thử tự động
• Đo lường sự thi hành cùa các thành phần và hệ
thống
• Duyệt các kiểm thử lẫn nhau
145

• Kỹ sư kiểm thử
– Cùng chuyên môn với người lập trình
– Chọn kiểm thử như một chuyên ngành
– Viết TC, tổ chức bộ kiểm thử
– Tạo, tùy biến và sử dụng
– Công cụ kiểm thử tiên tiến
– Có các kỹ năng riêng biệt
146

• Chuyên viên kiểm thử
– Là Tester có kỹ năng và kinh nghiệm
– Thực hiện kiểm thử
– Lập báo cáo lỗi
– Cập nhật trạng thái kiểm thử
– Hỗ trợ kỹ sư kiểm thử
147

• Thành viên khác
– Quản trị csdl, hệ thống
– Nhân viên cấu hình, xuất xưởng
– Quản trị các công cụ kiểm thử
148
Lập kế hoạch và đánh giá

• Phát triển kế hoạch kiểm thử
• Các hoạt động
• IEEE 829 Test Plan
• Tiêu chuẩn thực hiện
• Tiêu chuẩn thực hiện tiếp
• Tiêu chuẩn kết thúc
• Lượng giá
149
Phát triển kế hoạch kiểm thử

• Tại sao cần viết hay cập nhật bản kế hoạch ?
– Các mối đe dọa/thách thức, kết tinh quá trình suy nghĩ,
thích nghi với thay đổi
– Truyền thông kế hoạch với tester, đồng nghiệp, người
quản lý.
• Xem xét nhiều phương án khi kiểm thử có
– Giai đoạn - thời gian khác nhau
– Phương pháp và công cụ khác nhau
– Mục tiêu khác nhau
– Thành phần khác nhau
150
Phát triển kế hoạch kiểm thử

• Phổ biến bản phác thảo
– Thúc đẩy sớm phản hồi và tranh luận
– Ngăn ngừa mất thời gian với các sai lầm trước
151
Các hoạt động

• Định nghĩa các tiếp cận và mức kiểm thử
– Tích hợp, phối hợp kiểm thử vào trong chu kỳ phát triển
– Quyết định ai, cái gì, khi nào và kiểm thử như thế nào
– Chỉ định tài nguyên cho công việc kiểm thử
– Định nghĩa tài liệu kiểm thử
– Thiết lập mức chi tiết cho TC, thủ tục kiểm thử để đủ
thông tin hỗ trợ chuẩn bị, thực hiện kiểm thử
– Chọn cách theo dõi, điều khiển, lập báo cáo, …
152
Tiêu chuẩn thực hiện

• Kiểm tra hệ thống có thể bắt đầu khi:
– Các hệ thống lần vết đã có.
– Tất cả các thành phần dựa trên việc sử dụng chính thức,
điều khiển quản lý cấu hình và xuất xưởng tự động
– Nhóm vận hành đã câu hình hệ thống chủ kiểm thử hệ
thống bao gồm tất cả các thành phần phần cứng, cung
cấp truy xuất thích hợp
– Nhóm phát triển đã hoàn tất các đặc tính, việc sửa lỗi và
chuẩn bị cho xuất xưởng
– Hoàn tất kiểm thử đơn vị và sửa lỗi
153
Tiêu chuẩn kết thúc

• Đánh giá khi hệ thống kiểm thử thành công
– Độ bao phủ code,
– Chức năng
– Rủi ro
– Ước lượng mật độ khiếm khuyết, đánh giá độ tin cậy
– Chi phí
– Các rủi ro còn lại
– Khiếm khuyết chưa sửa, miền bao phủ chưa chắc chắn
– Lịch biểu đến thời điểm tung ra thị trường
154
Lượng giá
• Hai cách tiếp cận tổng quát
– Lượng giá công việc của chính từng cá nhận hoặc của
chuyên gia (bottom-up via workbreakdown-structure)
– Lượng giá dựa trên các dự án đã thực hiện hoặc tương
tự
155
Các nhân tố ảnh hưởng lượng giá

• Kiểm thử thì phức tạp, ảnh hưởng bởi:
– Các nhân tố về quy trình: Kiểm thử rộng, thay đổi, tính
thuần thục, qui trình, …
– Nhân tố “tài nguyên”: Công cụ, hệ thống, môi trường, tài
liệu, …
– Nhân tố con người: Kỹ năng, kỳ vọng, hỗ trợ, quan hệ
– Nhân tố trễ hạn: Tính phức tạp, nhiều người ký kết,
nhiều cái mới, phân bố địa lý, …
156
Nhân tố ảnh hưởng kiểm soát kiểm thử

• Tỷ lệ hoàn tất chuẩn bị
• Tỷ lệ hoàn tất chuẩn bị môi trường
• Thực thi TC
• Thông tin khiếm khuyết
• Bao phủ yêu cầu, rủi ro mã bởi kiểm thử
• Mức tin tưởng của Tester vào sản phẩm
• Mốc thời gian quan trọng
• Chi phí kiểm thử
157
Báo cáo kiểm thử

• Tổng kết, phân tích kết quả kiểm thử
– Sự kiện chính: đáp ứng tiêu chuẩn kết thúc
• Phân tích (đề nghị, hướng dẫn)
– khiếm khuyết còn lại
– chi phí/lợi ích của nhiều kiểm thử
– rủi ro tồn đọng
– mức tin tưởng
• Ấn định:
– Mục tiêu kiểm thử đủ cho mức kiểm thử
– Cách tiếp cận thích hợp
– Mức hiệu lực kiểm thử trên mục tiêu
158
Kiểm soát kiểm thử

• Các hoạt động hướng dẫn và chỉnh sửa thực hiện
theo thông tin và nhân tố kiểm thử
• Ví dụ:
– Lập lại mức độ ưu tiên,rủi ro
– Lịch biểu điều chỉnh theo mức độ sẵn sàng của môi
trường kiểm thử
– Thiết lập tiêu chuẩn yêu cầu kiểm tra lại
159
Quản lý cấu hình

• Quản lý kiểm thử và cấu hình
• Nhiệm vụ chính
• Quản lý kiểm thử phát hành
160
Quản lý kiểm thử và cấu hình

• Thiết lập, bảo trì toàn vẹn các mục tạo lên phần
mềm hay hệ thống
• Với kiểm thử:
– Cho phép quản lý testware và kết quả
– Đảm bảo mối phần tử giữ mối liên hệ với thành phần hệ
thống
– Hỗ trợ chuyển kiểm thử hoàn chỉnh tới phòng kiểm thử
• Thông qua lập kế hoạch dự án và kiểm thử, các thủ
tục và hạ tầng quản lý cấu hình nên được chọn, lập
tài tiệu, hiện thực, …
161
Quản lý rủi ro
• Kiểm thử cũng tạo lên một phần rủi ro
• Rủi ro là khả năng của một tác đông ngược:
– Trễ phát hành bản kiểm thử, có rắc rối về môi trường
kiểm thử
• Phát hiện rủi ro tới nỗ lực kiểm thử
– Cái gì có thể dẫn đến lỗi trong dự án ? Dẫn tới trễ hạn
hoặc sai lầm
– Loại nào của kiểm thử không chấp nhận tác động tới
162
Quản lý lỗi và sự cố
• Thường có các mục tiêu sau:
– Cung cấp thông tin chi tiết về sự cố hoặc lỗi cho những ai cần đến
– Là phần dữ liệu tập hợp để phân tích
– Hướng dẫn cải tiến quy trình phát triển và kiểm thử
• Người liên quan:
– Người phát triển
– Người quản lý: Quyết định tài nguyên, cấp phát, ưu tiên
• Nhân viên hỗ trợ kỹ thuật: người cần nắm bắt thông tin thực
hiện, chuẩn bị
• Testers: Cần biết trạng thái của hệ thống hiện tại
163
CÔNG CỤ
Công cụ tạo testcase
Công cụ thực thi

testcase
Công cụ quản lý

Công cụ tạo testcase

• TestCaseGenerator
165
Pairwise testing
• N-wise (N-way) Testing
• Kết hợp n đầu vào với nhau.
– Kết hợp 2 đầu vào với nhau được gọi là 2-wise
– Kết hợp 3 đầu vào với nhau được gọi là 3-wise
• Còn được gọi là n-way testing
– 2-wise: 9 test case (PICT)
– 3-wise: 18 test case (PICT)
166
2-WISE TESTING
167
3-WISE TESTING
168
SELENIUM IDE
169
SELENIUM IDE
170
SELENIUM IDE
171
SELENIUM IDE
172
SELENIUM IDE
173
SELENIUM IDE
174
SELENIUM IDE
175
SELENIUM IDE
176
SELENIUM IDE
177
SELENIUM IDE
178
Công cụ quản lý lỗi Bugzilla
179
Tạo mới 1 bug trong bugzilla
180
Cập nhật 1 bug trong bugzilla
181
Cập nhật 1 bug trong bugzilla
182
Xem bug trong Bugzilla
183
184
185
186
Tìm bug trong Bugzilla
187
Kết quả tìm bug trong Bugzilla
188

Kiểm Thử Phần Mềm

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Kiểm Thử Phần Mềm

Uploaded by

Copyright:

Available Formats

KIỂM THỬ PHẦN MỀM

Tổng quan kiểm thử phần mềm

Quy trình và kế hoạch

Phương pháp & Kỹ thuật

Quản lý việc kiểm thử

Nhập môn lập trình 2014

Kiểm thử là gì?

Vì sao phải kiểm thử

Khía cạnh tâm lý học

Các khái niệm

Nhập môn lập trình 2014

• Mọi phương pháp kiểm thử được dùng để ngăn

VÌ SAO PHẢI TEST

(Software Testing Techniques, Second Edition, by Boris

VAI TRÒ CỦA KIỂM THỬ

VAI TRÒ CỦA KIỂM THỬ

VAI TRÒ CỦA KIỂM THỬ

KIỂM THỬ BAO NHIÊU LÀ ĐỦ?

Các hoạt động của việc kiểm thử

KHÍA CẠNH TÂM LÝ HỌC

CÁC KHÁI NIỆM

CÁC KHÁI NIỆM

CÁC KHÁI NIỆM

CÁC KHÁI NIỆM

Mô hình kiểm thử

Kiểm thử phần mềm

Mô hình thác nước

Mô hình thác nước

KT TRONG MÔ HINH SCRUM

Sơ đồ tổ chức phổ biến của đội kiểm thử

QUY TRÌNH KIỂM THỬ

QUY TRÌNH KIỂM THỬ

QUY TRÌNH KIỂM THỬ

QUY TRÌNH KIỂM THỬ

QUY TRÌNH KIỂM THỬ

Quy trình thực hiện

Quy trình xử lý lỗi

QUY TRÌNH KIỂM THỬ

Các hoạt động chính trong giai đoạn kết thúc KT

QUY TRINH XÂY DỰNG KH KT

Các thành phần chính trong KHKT

2. Các tiêu chí chấp nhận

3. Yêu cầu cần KT

Kiểm thử phần mềm

LỢI ÍCH CỦA KT UNIT

Kỹ thuật áp dụng trong KT UNIT

Quy trình KT Module

Quy trình KT Module

Quy trình KT Module

• Có hai cách tích hợp:

Ưu điểm của phương pháp top-down

Khuyết điểm của phương pháp top-down

Khuyết điểm KT bottom-up

Document System Testing Recoverability

Reliability Load & Stability

Kiểm thử phần mềm

Phân vùng tương đương

Phân vùng tương đương

Phân vùng tương đương

Phân vùng tương đương

Phân vùng tương đương

Phân vùng tương đương

Phân tích giá trị biên

Phân tích giá trị biên