TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN.pdf

ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN
Tel. (84-511) 736 949, Fax. (84-511) 842 771
Website: itf.ud.edu.vn, E-mail: cntt@edu.ud.vn
LUẬN VĂN TỐT NGHIỆP KỸ SƯ
NGÀNH CÔNG NGHỆ THÔNG TIN
MÃ NGÀNH : 05115
ĐỀ TÀI :
TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ
ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT
ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN
Mã số : 06T2 – 49
06T1 – 67
Ngày bảo vệ : 14 - 15/ 06 /2011
SINH VIÊN : NGUYỄN TÙNG 06T2
NGUYỄN ĐĂNG QUYỀN 06T1
CBHD : K.S VÕ ĐỨC HOÀNG
ĐÀ NẴNG, 06/2011

LỜI CẢM ƠN
Chúng tôi xin được gửi lời cảm ơn tới các thầy cô trong khoa công nghệ thông
tin trường Đại học Bách Khoa Đà Nẵng và công ty Logigear đã tạo điều kiện và
mang lại những kiến thức quý báu để chúng tôi có thể thực hiện đề tài này.
Xin cảm ơn thầy giáo Võ Đức Hoàng đã tận tình hướng dẫn và chỉ bảo chúng
tôi trong suốt quá trình làm đồ án để chúng tôi có thể hoàn thành tốt đề tài này.
Cuối cùng chúng tôi xin cảm ơn các bạn trong khoa công nghệ thông tin,
những người đã giúp đỡ, chia sẽ những kiến thức, kinh nghiệm, tài liệu…trong suốt
quá trình nghiên cứu thực hiện đề tài.
Chúng tôi xin chân thành cảm ơn!
Nhóm sinh viên thực hiện
Nguyễn Tùng
Nguyễn Đăng Quyền

LỜI CAM ĐOAN
Tôi xin cam đoan :
1 Những nội dung trong báo cáo này là do chúng tôi thực hiện dưới
sự hướng dẫn trực tiếp của thầy Võ Đức Hoàng.
2 Mọi tham khảo dùng trong báo cáo này đều được trích dẫn rõ ràng
tên tác giả, tên công trình, thời gian, địa điểm công bố.
3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá,
chúng tôi xin chịu hoàn toàn trách nhiệm.
Nhóm Sinh Viên
Nguyễn Tùng
Nguyễn Đăng Quyền

NHẬN XÉT CỦA CÁN BỘ HƯỚNG DẪN
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
Đà Nẵng ngày … tháng … năm 2011
Cán bộ hướng dẫn
K.s. Võ Đức Hoàng

Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
NHẬN XÉT CỦA CÁN BỘ PHẢN BIỆN
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
Đà Nẵng, ngày … tháng … năm 2011
Cán bộ phản biện
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1 Trang 5

TÓM TẮT ĐỒ ÁN
Đồ án gồm những nội dung chính sau:
- Khái quát về kiểm thử phần mềm:
o Khái niệm kiểm thử phần mềm
o Một số phương pháp kiểm thử phần mềm
o Các giai đoạn kiểm thử phần mềm
o Các lỗi thường gặp khi kiểm thử
- Sơ lược về Test Tool và kiểm tra tự động
- Giới thiệu chương trình kiểm thử phần mềm TestArchitect
- Thực hành kiểm thử Ứng dụng web cộng đồng Dolphin bằng công cụ
TestArchitect

DANH SÁCH HÌNH SỬ DỤNG TRONG ĐỒ ÁN
Hình 1: Mô hình thác nước......................................................................12
Hình 2: Mô hình Agile..............................................................................14
Hình 3: Luồng điều khiển của lập trình theo cấu trúc.............................21
Hình 4: Đồ thị chương trình của bài toán tam giác.................................22
Hình 5: Mô hình kiểm thử hộp đen...........................................................23
Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b.......................24
Hình 7: Kiểm thử theo giá trị biên với hai biến x1 và x2.........................25
Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b...............25
Hình 9: Kiểm thử theo giá trị biên đầy đủ với 2 biến x1 và x2................26
Hình 10: Kiểm thử theo phân hoạch tương đương - lỗi đơn...................27
Hình 11: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp...............28
Hình 12: Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ........28
Hình 13: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ...29
Hình 14: Mối tương quan giữa KTTĐ và chu trình KTPM......................51
Hình 15: So sánh 3 loại kiểm thử.............................................................54
Hình 16 : Mô hình ABT...........................................................................54

MỤC LỤC
LỜI NÓI ĐẦU.................................................................................................10
VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM........................................................11
I.1. Vòng đời phát triển phần mềm............................................................11
I.2. Mô hình thác nước..............................................................................11
I.3. Mô hình Agile:...................................................................................13
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM.................................................15
II.1. Kiểm thử phần mềm.....................................................................15
II.1.1. Khái niệm..............................................................................15
II.1.2. Lý do cần kiểm thử................................................................15
II.1.3. Vai trò....................................................................................15
II.1.4. Mục tiêu................................................................................16
II.1.5. Lợi ích...................................................................................16
II.2. Các giai đoạn kiểm thử và điểm xác định:........................................16
II.3. Tổng Quan Về Kiểm Thử Phần Mềm...............................................17
II.3.1 Tìm hiểu Testing, QA, QC........................................................17
II.3.2 Nhóm kiểm thử.........................................................................17
II.3.2.1. Mục tiêu.............................................................................17
II.3.2.2. Trách nhiệm của Tester......................................................17
II.3.3. Mục tiêu của kiểm thử...........................................................18
II.3.3.1. Lớp tương đương và phân tích giá trị biên.........................18
II.3.3.2. Thiết kế kiểm thử...............................................................18
II.3.4. Các phương pháp kiểm thử.......................................................18
II.4. Các giai đoạn kiểm thử...................................................................31
II.4.1. Kiểm thử đơn vị.....................................................................31
II.4.2. Kiểm thử tích hợp..................................................................31
II.4.3. Kiểm thử hệ thống.................................................................32
II.4.4. Kiểm thử thẩm định...............................................................32
ĐỊNH NGHĨA TEST REQUIREMENT (TR) VÀ TEST CASE (TC).............33
III.1. Test Requirement (TR).................................................................33
III.1.1. Định nghĩa.............................................................................33
III.1.2. Thuộc tính của TR.................................................................33
III.2. Test case.......................................................................................33
III.2.1. Giới thiệu.................................................................................33
III.2.2. Yêu cầu của test case...............................................................34
III.2.3. Bản chất test case....................................................................34
III.2.4. Cú pháp test case....................................................................34
III.3. Phương thức kiểm thử và kỹ thuật thiết kế Test case....................35
III.3.1. Phương thức kiểm thử và một vài loại kiểm thử....................35
III.3.2. Một vài kỹ thuật thiết kế test case..........................................36

III.3.2.1.Phân vùng tương đương: (đã tìm hiểu ở chương trên).....37
III.3.2.2. Phân tích giá trị biên: (đã tìm hiểu ở chương trên)......37
III.3.2.3. Điều kiện ràng buộc:...................................................37
III.3.2.4. Quan hệ dữ liệu:..........................................................37
III.3.2.5. Chuyển trạng thái:.......................................................37
III.3.2.6. Điều kiện kết hợp:.......................................................37
III.4. Các lỗi thường gặp khi kiểm thử..................................................37
III.4.1. Các lỗi dữ liệu vào ra.............................................................37
III.4.2. Các lỗi logic..........................................................................38
III.4.3. Các lỗi tính toán....................................................................38
III.4.4. Các lỗi giao diện....................................................................39
III.4.5. Các lỗi dữ liệu.......................................................................39
ỨNG DỤNG LÝ THUYẾT ĐỂ THIẾT KẾ TEST REQUIREMENTS VÀ
TEST CASE.....................................................................................................40
IV.1. Ví dụ về thiết kế TR và TC cho Gmail web và ứng dụng Evernote.40
IV.1.1. TR và TC cho 1 số chức năng gmail.........................................40
IV.1.2. TR và TC cho ứng dụng Evernote............................................43
IV.2. Ví dụ về Bug và cách viết Bug...........................................................46
SƠ LƯỢC VỀ TEST TOOL.............................................................................50
V.1. Test Tool.......................................................................................50
V.2. Kiểm thử tự động.........................................................................51
TÌM HIỂU VÀ GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG TEST
ARCHITECT...................................................................................................53
VI.1. Giới thiệu về nền tảng Action Based Testing................................53
VI.1.1. Action based testing là gì ?....................................................53
VI.1.2. Cách làm việc của ABT là gì ?..............................................54
VI.2. GIỚI THIỆU VỀ TOOL TESTARCHITECT...............................56
VI.2.1. Giới thiệu...............................................................................56
VI.2.2. Chức năng cơ bản..................................................................58
VI.2.2.1.Automation Engineers....................................................60
VI.2.2.2.Software Testers..............................................................60
VI.2.2.3.Managers........................................................................62
VI.2.2.4.Revision Control.............................................................63
VI.2.2.5.Built-In Platform Support...............................................63
VI.2.2.6.Action Recording............................................................64
VI.2.2.7.Control Flow, Variables & Expressions..........................65
VI.2.2.8.Debugging......................................................................65
VI.2.3. Mô hình hoạt động.................................................................66
ỨNG DỤNG TESTARCHITECT ĐỂ KIỂM THỬ ỨNG DỤNG WEB
DOLPHIN........................................................................................................68
VII.1. Giới thiệu.....................................................................................68
VII.2. Kiểm thử ứng dụng với TestArchitect..........................................72
Những kết quả nhận được................................................................................87
Hướng phát triển..............................................................................................87

LỜI NÓI ĐẦU
Ngày nay tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích
thường rất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên ưu
điểm chung nhất của việc ứng dụng tự động hoá vẫn là giảm nhân lực, thời
gian và sai sót. Ngành công nghệ thông tin nói chung và cụ thể là phát triển
phần mềm cũng không ngoại lệ. Như chúng ta đã biết, để tạo ra một sản phẩm
công nghệ thông tin hay phần mềm có chất lượng thì hoạt động kiểm tra phần
mềm đóng vai trò rất quan trọng, trong khi đó hoạt động này lại tiêu tốn và
chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án. Do vậy, nhu cầu
tự động hoá qui trình kiểm tra phần mềm đã được đặt ra.
Qua thực tế cho thấy việc áp dụng kiểm thử tự động hợp lý sẽ mang lại
thành công cho hoạt động kiểm tra phần mềm. Kiểm thử tự động giúp giảm bớt
công sức thực hiện, tăng độ tin cậy, giảm sự nhàm chán và rèn luyện kỹ năng
lập trình cho kiểm thử viên. Nhận thấy tầm quan trọng đó của kiểm thử phần
mềm trong việc phát triển phần mềm hiện nay, chúng em đã chọn đề tài: “Tìm
hiểu các phương pháp kiểm thử phần mềm và ứng dụng công cụ kiểm tra tự
động TestArchitect để kiểm thử tự động cho ứng dụng Dolphin” làm đề tài
cho đồ án tốt nghiệp. Nội dung đồ án sẽ giới thiệu khái quát về kiểm thử phần
mềm, Test Tool, kiểm tra tự động và giới thiệu một công cụ kiểm tra tự động
khá mạnh hiện nay là TestArchitect của Logigear.
Mặc dù đã có nhiều cố gắng trong quá trình làm bài, nhưng do thời gian
và kinh nghiệm còn hạn chế nên bài làm không thể tránh được thiếu sót, vì vậy
chúng tôi rất mong nhận được sự chỉ bảo của thầy cô và sự đóng góp ý kiến của
các bạn để đồ án được hoàn thiện hơn.
Chúng tôi xin chân thành cảm ơn!

CHƯƠNG I
VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM
I.1. Vòng đời phát triển phần mềm
Quy trình phát triển phần mềm là tập hợp các thao tác và các kết quả tương
quan để sản xuất ra một sản phẩm phần mềm. Hầu hết các thao tác này được tiến
hành bởi các kỹ sư phần mềm. Các công cụ hỗ trợ máy tính về kỹ thuật phần mềm có
thể được dùng để giúp trong một số thao tác.
Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:
1. Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt
động phải được định nghĩa.
2. Sự phát triển phần mềm: Để phần mềm được đặc tả thì phải có quy trình
phát triển này.
3. Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng
nó làm những gì mà khách hàng muốn.
4. Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay
đổi các yêu cầu của khách hàng.
I.2. Mô hình thác nước
Là 1 mô hình phát triển phần mềm tuần tự.
Chuyển đổi giữa các giai đoạn được thực hiện bằng một đánh giá chính thức.
Đánh giá là một điểm kiểm tra để xác nhận là bạn có đi đúng hướng hay không.
Trong mô hình này giai đoạn test bắt đầu sau giai đoạn code.

Hình 1: Mô hình thác nước
Mô hình này làm cho ý nghĩa việc sản xuất được rõ hơn.
1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục
tiêu được hình thành bởi sự trợ giúp của hệ thống người tiêu dùng. Sau
đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả
người phát triển và người tiêu dùng.
2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ
phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như
tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào
việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển
đổi thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần
mềm phải được chứng thực như là một tập hợp nhiều chương trình hay
nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm việc xác minh rằng
mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay
các chương trình được tích hợp lại và thử nghiệm như là một hệ thống
hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn.
Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.
5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là giai
đoạn lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt
và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa
được phát hiện trong các giai đọan trước của chu kì sống; nâng cấp sự
thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là
các phát hiện vê yêu cầu mới.
Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra
thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không
dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô

hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây vẫn là mô hình cơ
sở cho đa số các hệ thống phát triển phần mềm - phần cứng.
I.3. Mô hình Agile:
I.3.1. Giới thiệu của mô hình
Phương pháp Agile (phát triển phần mềm linh hoạt) bắt đầu ra đời vào giữa
những năm 90 với mục tiêu là phần mềm có khả năng mở rộng hay tiến hoá
theo thời gian mà không cần phải làm lại từ đầu. Phần mềm này tập trung vào:
Tạo ra một phần mềm đơn giản có thể đáp ứng nhu cầu khách hàng hiện tại và
có khả năng mở rộng, sẵn sàng thay đổi đáp ứng cho nhu cầu trong tương lai.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mền
trong những khung thời gian ngắn. Mỗi bước lặp giống như phát triển một phần
mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test,
viết tài liệu. Tuy mỗi bước lặp có thể không bổ sung đủ chức năng để đảm bảo
sự ra đời của sản phẩm cuối cùng, nhưng nó nhằm cho ra đời một sản phẩm
phần mềm mới sau mỗi bước lặp kết thúc. Cuối mỗi bước lặp bất kể kết quả thế
nào, nhóm phát triển cũng đánh giá lại các ưu tiên của dự án.
Phương pháp Agile nhấn mạnh tầm quan trọng của giao tiếp thời gian thực,
giao tiếp mặt đối mặt được đánh giá cao hơn là các tài liệu viết. Hầu hết các đội
phát triển theo kiểu Agile đều được tập trung trong một môi trường có điều
kiện thuận lợi cho việc giao tiếp và các đội này phải bao gồm các lập trình viên
và các khách hàng của họ.
I.3.2. Đặc điểm của mô hình
- Chu kỳ giao hàng ngắn. Phát triển rất tập trung
- Mô hình, uses case, user stories, index card, hay đặc tả chức năng được
sử dụng như tài liệu để test.
- Dự án thực hiện với mô hình Agile thường có rất nhiều test unit được
thực hiện bởi những người phát triển.
- Do cấu trúc năng động của mô hình này nên việc phát triển cũng cần sử
dụng phương pháp kiểm thử hồi quy.
- Mô hình phát triển phần mềm này rất hoan nghênh sự thay đổi cho ứng
dụng đến từ khách hàng.

Priorized
FEATURE LIST
Hình 2: Mô hình Agile
ITERATION
FEATURES
Plan &
Dev
Evauate
Learn
New Product

CHƯƠNG II
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
II.1. Kiểm thử phần mềm
1 Khái niệm
Kiểm thử phần mềm là quá trình xác minh và thẩm định động tức là quá
trình thực hiện kiểm tra, kiểm soát ngay khi thực hiện chương trình (thường
làm được khi có mã nguồn của chương trình) để tìm ra các lỗi có thể. Hiện nay
đây cũng là kỹ thuật được phổ biến nhất.
- Kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chương
trình để tìm ra lỗi.
- Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất và chi phí
(thời gian, công sức) ít nhất?
II.1.1. Lý do cần kiểm thử
- Để đánh giá chất lượng sản phẩm
- Để phát hiện ra các vấn đề
- Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này (hiệu
quả)
- Có kế hoạch tốt nâng cao chất lượng cho suốt quá trình phát triển (giải
pháp).
II.1.2. Vai trò
- Chi phí của kiểm thử chiếm:
 40% tổng công sức phát triển
 ≥ 30% tổng thời gian phát triển
 Với các phần mềm có ảnh hưởng tới sinh mạng, chi phí có thể
gấp từ 3 đến 5 lần tổng các chi phí khác cộng lại.
- Kiếm thử tốt sẽ:
 Giảm chi phí phát triển
 Tăng độ tin cậy của phần mềm

II.1.3. Mục tiêu
- Cố gắng tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm được xây
dựng
- Có một chương trình tốt, chi phí ít.
II.1.4. Lợi ích
- Thuyết minh rằng các chức năng phần mềm tương ứng với đặc tả (xác
minh).
- Yêu cầu thực thi là phù hợp (thẩm định),
- Cung cấp thêm các chỉ số độ tin cậy và chỉ số chất lượng phần mềm
nói chung (thẩm định).
- Tuy nhiên, kiểm thử không thể khẳng định rằng phần mềm không có
khiếm khuyết
II.2. Các giai đoạn kiểm thử và điểm xác định:
Giai đoạn phát triển: là một lượng thời gian trong vòng đời của việc phát
triển phần mềm với một số các hoạt động phải làm trong lượng thời gian này.
Mốc phát triển: Đánh dấu một sự kiện trong tiến trình phát triển phần mềm,
khi phần mềm di chuyển từ giai đoạn này qua giai đoạn khác. Mốc phát triển
này cho chúng ta biết ứng dụng phá triển đang ở vị trí nào trong vòng đời phát
triển của phần mềm
Các giai đoạn kiểm thử và mốc:
Bảng 1
Test
Phase
Pre- Alpha Alpha Beta GM/Release
Unit
(Đơn vị)
Intergration
(Tích hợp)
System
(Hệ thống)
User
Acceptance
(chấp nhận
sản phẩm)
Thực hiện Developer Developer/
Technical Tester
Tester User
Định
nghĩa
Kiểm thử một
đơn vị code
trong 1 thời
gian
Lặp đi lặp lại 1 hệ
thống hoàn chỉnh.
Kiểm tra các đơn
vị code khi nó
làm việc chung
môi trường với
nhau.
Là mức độ
kiểm thử toàn
bộ chức năng
hệ thống. Kiểm
tra như sản
phẩm được đưa
ra sử dụng.
Đánh giá phần
mềm có đáp
ứng được các
yêu cầu của
người dùng đã
đề ra hay
không? Có thể
triển khai cho
công việc thực

tế hay không
Kết quả Ít lỗi Tìm lỗi Tìm lỗi/QC QC
Mục đích Xác nhận giá
trị các modun
độc lập
Tìm lỗi và biết về
sản phẩm, xác
nhận giá trị các
yêu cầu tích hợp
Tìm lỗi, xác
nhận giá tri hệ
thống, luồng dữ
liệu…
Xác nhận các
yêu cầu của
người sử dụng.
Tùy thuộc vào ứng dụng dự kiến, mà chúng ta sẽ chọn mô hình phát triển phần
mềm cho phù hợp.
Có nhiều giai đoạn trong SLDC. Trong từng giai đoạn, có các mốc và tiêu chí
của từng cột mốc. Tiêu chí, mốc và những giai đoạn giúp phát triển ứng dụng
đúng phù hợp, tiếc kiệm thời gian và hiệu quả cao.
II.3. Tổng Quan Về Kiểm Thử Phần Mềm
II.3.1 Tìm hiểu Testing, QA, QC
- Testing : Tiến trình thực thi chương trình để tìm ra những thiếu sót của
chương trình.
- Quality Assurance (QA): Tập hợp các hoạt động được lập ra để đảm bảo
tiến trình phát triển và duy trì là phù hợp để chắc chắn một hệ thống sẽ
đáp ứng các mục tiêu của nó.
- Quality Control (QC): Tập hợp các hoạt động được tạo ra để đánh giá
sản phẩm đang được tiến hành.
II.3.2 Nhóm kiểm thử
II.3.2.1. Mục tiêu
- Tìm và viết báo cáo lỗi.
- Xác định các vùng yếu của chương trình.
- Xác định các vung nguy cơ cao của chương trình.
- Giải thích những gì vừa tìm được.
II.3.2.2. Trách nhiệm của Tester
- Tìm những vấn đề .
 Tìm lỗi.
 Tìm vấn đề về thiết kế.
 Tìm nhiều cách hiệu quả để tìm lỗi.
- Vấn đề về giao tiếp.
 Báo cáo lỗi và thiết kế lại vấn đề
 Báo cáo về tiến trình kiểm thử.
 Đánh giá và báo cáo tính ổn định của chương trình.
- Trách nhiệm của quản lý và team leader.

 Sửa chữa kế hoạch và lịch trình kiểm thử
 Dự toán công việc kiểm thử, thời gian, và tiền của ứng dụng.
 Xác nhận và báo cáo tiến trình kiểm thử qua các giai đoạn các cột mốc.
 Dạy cho các tester khác để tìm lỗi.
II.3.3. Mục tiêu của kiểm thử
II.3.3.1. Lớp tương đương và phân tích giá trị biên
- Lớp tương đương : hai lớp được gọi là tương đương nếu kết quả dự kiến của
hai lớp này là như nhau.
- Biên: Điểm đánh dấu hay vùng chuyển tiếp từ 1 lớp tương đương đến 1 lớp
khác gọi là biên.
Kiểm thử điều kiện biên có ưu điểm vượt trội khi lớp tương đương được sử
dụng.
II.3.3.2. Thiết kế kiểm thử
Các bước chung:
- Xác định các lớp
- Xác định giá trị biên
- Xác định dự kiến đầu vào đầu ra
- Xác định dự kiến các lỗi với giá trị vào không phù hợp.
- Tạo bảng kiểm thử.
a.Mục tiêu của kiểm thử
- Mục tiêu của kiểm thử không phải là xác minh chương trình làm việc
đúng.
- Mục tiêu của kiêm thử chương trình là tìm ra các vấn đề trong phần
mềm.
- Mục đích của việc tìm ra vấn đề là để sửa lại chúng cho phù hợp.
b. Bạn không thể kiểm thử mọi thứ , vì thế:
- Chúng ta tập trung và sử dụng thời gian test để tìm nhiều lỗi nhất có thể.
- Chúng ta cần bao phủ hết vùng của ứng dụng với thời gian xác định.
- Tìm các lỗi nghiêm trọng 1 cách nhanh nhất có thể.
II.3.4. Các phương pháp kiểm thử
 Hai phương pháp phổ biến:
 Kiểm thử hộp trắng (white box)
 Kiểm thử hộp đen (black box)
II.3.4.1. Kiểm thử hộp trắng
II.3.4.1.1 Khái niệm kiểm thử hộp trắng

Kiểm thử hộp trắng (kiểm thử theo cấu trúc) là kiểm thử được thực hiện
trực tiếp trên mã nguồn, khám xét các chi tiết thủ tục; các con đường logic, các
trạng thái của chương trình.
Kiểu kiểm thử này thường sử dụng công thức toán học và lý thuyết đồ
ử dụng công thức toán học và lý thuyết đồ
thị
thị và được thực hiện ở cấp độ kiểm thử đơn vị
được thực hiện ở cấp độ kiểm thử đơn vị. Việc xác định các trường hợp
Việc xác định các trường hợp
kiểm thử không dễ dàng
kiểm thử không dễ dàng
- Số đường lôgíc là rất lớn. Một chương trình nhỏ:
+ với 100 dòng PASCAL
+ với một vòng lặp
 số con đường logic có thể tới: 1014.
 cần 3170 năm để kiểm thử tất mọi con đường và
mọi ràng buộc lôgic trên nó!
II.3.4.1.2 Đối tượng kiểm thử hộp trắng
- Cách thức: Sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình
thành các ca kiểm thử
- Kiểm thử cái gì?
 Mọi lệnh được thực hiện
 Mọi điều kiện được kiểm tra
 Mọi chu trình được duyệt qua
 Mọi cấu trúc dữ liệu được dùng
 Mọi tiến trình được lần vết
II.3.4.1.3 Yêu cầu kiểm thử hộp trắng
- Yêu cầu đặt ra:
+ Mọi con đường độc lập trong một module cần được thực hiện ít nhất một
lần.
+ Mọi ràng buộc logic được thực hiện cả hai phía: phía đúng & phía sai
+ Tất cả các vòng lặp ở biên của nó và cả các biên vận hành phải được thực
hiện.
+ Mọi cấu trúc dữ liệu nội tại được dùng để bảo đảm tính hiệu lực của nó
II.3.4.1.4 Lý do kiểm thử hộp trắng
- Vì sao cần tốn tiền cho kiểm thử hộp trắng?
+ Các lỗi logic & giả thiết không đúng đắn tỷ lệ nghịch với xác suất để
một con đường logic được thi hành.

+ Thực tế: mọi con đường lôgic đều có thể được thi hành trên 1 cơ sở
nhất định (ta cho rằng 1con đường logic nào đó là không thể được thi hành).
+ Có những sai sót chính tả có thể là ngẫu nhiên trên đường ta không
kiểm tra.
II.3.4.1.5 Kiểm thử theo đường dẫn
- Các đường dẫn được xác định bằng việc xây dựng
- Các đường dẫn được xác định bằng việc xây dựng đồ thị chương trình
đồ thị chương trình
- Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn
- Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn
* Đồ thị chương trình:
* Đồ thị chương trình:
- Đồ thị chương trình là một đồ thị có hướng trong đó:
- Đồ thị chương trình là một đồ thị có hướng trong đó:
+ Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự, hoặc thay
cho điểm hội tụ các đường điều khiển.
+ Mỗi cạnh nối hai nút biểu diễn dòng điều khiển.
Nghĩa là, có một cạnh từ đỉnh i đến đỉnh j nếu câu lệnh tương ứng với
Nghĩa là, có một cạnh từ đỉnh i đến đỉnh j nếu câu lệnh tương ứng với
đỉnh j có thể được thực thi ngay lập tức sau câu lệnh tương ứng với đỉnh i
đỉnh j có thể được thực thi ngay lập tức sau câu lệnh tương ứng với đỉnh i
+ Kết quả: đồ thị dòng
 Chia mặt phẳng thành nhiều miền.
 Có nút vị từ biểu thị sự phân nhánh hoặc hội nhập của các cung.
* Cách xây dựng đồ thị chương trình:
+ IF
+ IF
+ IF-Then-Else
+ IF-Then-Else
+ For
+ For
+ While
+ While
+ Do-While
+ Do-While
+ Case
+ Case

Hình 3: Luồng điều khiển của lập trình theo cấu trúc
Ví dụ: Vẽ đồ thị chương trình của bài toán tam giác có chương trình như
sau:
Pretest
Loop
Posttest
Loop
If
Then
IfThen
Else
Cas
e
Sequence
ee

Hình 4: Đồ thị chương trình của bài toán tam giác
* Kết luận:
* Kết luận:
Kiểm thử theo đường dẫn dựa vào phương pháp của Tom McCabe được
Kiểm thử theo đường dẫn dựa vào phương pháp của Tom McCabe được
sử dụng cho cấp độ kiểm thử đơn vị. Nó có nhược điểm là yêu cầu người kiểm
sử dụng cho cấp độ kiểm thử đơn vị. Nó có nhược điểm là yêu cầu người kiểm
thử phải có kỹ năng lập trình đủ tốt để có thể hiểu được mã nguồn và luồng
thử phải có kỹ năng lập trình đủ tốt để có thể hiểu được mã nguồn và luồng
điều khiển trong chương trình
điều khiển trong chương trình
II.3.4.2. Kiểm thử hộp đen
II.3.4.2.1 Khái niệm
- Kiểm thử hộp đen dựa trên việc xem xét một chương trình như là một
hàm ánh xạ miền giá trị dữ liệu vào thành miền kết quả ra
- Còn được gọi là kiểm thử theo chức năng
- Phương pháp kiểm thử này chỉ dựa vào các chức năng trong chương
trình, bỏ qua cấu trúc bên trong của mã lệnh
- Đặc trưng:
+ Nhằm thuyết minh: các chức năng phần mềm đủ & vận hành đúng
+ Thực hiện các phép thử qua giao diện

- Cơ sở: đặc tả, các điều kiện vào/ra và cấu trúc dữ liệu
+ Ít chú ý tới cấu trúc logic nội tại của nó
* Ưu điểm:
Chúng độc lập với cách thức mà phần mềm được cài đặt, vì vậy, nếu ta
thay đổi cách cài đặt thì vẫn có thể sử dụng được các trường hợp kiểm thử,
chúng ta có thể thực hiện kiểm thử song song với quá trình cài đặt phần mềm,
làm giảm thời gian phát triển dự án.
Hình 5: Mô hình kiểm thử hộp đen
* Các kỹ thuật kiểm thử hộp đen:
- Kiểm thử theo giá trị biên
- Kiểm thử theo các lớp tương đương
- Kiểm thử dựa vào bảng quyết định
- Kiểm thử dựa vào đồ thị nguyên nhân-kết quả
II.3.4.2.2 Mục tiêu
- Kiểm thử hộp đen nhằm tìm ra các loại sai:
+ Chức năng thiếu hoặc không đúng đắn.
+ Sai về giao diện.
+ Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài.
+ Sai thực thi chức năng.
+ Sai khởi đầu hoặc kết thúc module.

- Kiểm thử hộp đen tập trung trả lời các câu hỏi:
+ Hiệu lực chức năng (chức năng, hiệu suất) được kiểm thử đến đâu?
+ Lớp đầu vào nào cho các ca kiểm thử tốt?
+ Sự nhạy cảm của module với giá trị vào nào?
+ Các biên của lớp dữ liệu được cô lập chưa?
+ Dung thứ lỗi đối với các nhịp điệu/khối lượng dữ liệu như thế nào?
+ Tổ hợp dữ liệu đặc biệt ảnh hưởng gì đến hoạt động hệ thống.
II.3.4.2.3 Tiêu chuẩn
Áp dụng kỹ thuật kiểm thử hộp đen, cần tìm ra các ca kiểm thử thoả
mãn các tiêu chuẩn:
+ Rút gọn (ít, đơn giản).
+ Cho biết về sự tồn tại hoặc vắng mặt của một lớp sai (không phải về
một sai cụ thể gắn với một kiểm thử riêng biệt)
II.3.4.2.4 Kiểm thử theo giá trị biên
Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong
Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong
chương trình, các biến đầu vào x1 và x2 sẽ có các giới hạn:
chương trình, các biến đầu vào x1 và x2 sẽ có các giới hạn:

 a<=x1<=b
a<=x1<=b

 c<=x2<=d
c<=x2<=d

 Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2
Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2
Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến
Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến
đầu vào tại giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá
đầu vào tại giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá
trị lớn nhất, và nhỏ hơn giá trị lớn nhất
trị lớn nhất, và nhỏ hơn giá trị lớn nhất
Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b
x
a b
X(min) X(min+) X(nom) X(max-) X(max)

Hình 7: Kiểm thử theo giá trị biên với hai biến x1 và x2
* Kiểm thử theo giá trị biên đầy đủ
- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ
- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ
hơn giá trị nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)
hơn giá trị nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)
- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực
- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực
hiện như thế nào nếu dữ liệu vào có lỗi
hiện như thế nào nếu dữ liệu vào có lỗi
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc
kiểu
kiểu
Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b
x2
a b
c
d
x1
x
a b
x1
x2
a b
c
d

Hình 9: Kiểm thử theo giá trị biên đầy đủ với 2 biến x1 và x2
* Số lượng trường hợp kiểm thử:
* Số lượng trường hợp kiểm thử:
- Kiểm thử theo giá trị biên: 4n+1
- Kiểm thử theo giá trị biên: 4n+1
- Kiểm thử theo giá trị biên đầy đủ: 6n+1
- Kiểm thử theo giá trị biên đầy đủ: 6n+1
Với n là số lượng các biến
* Nhược điểm của kiểm thử theo giá trị biên
* Nhược điểm của kiểm thử theo giá trị biên
- Các biến phải độc lập với nhau
- Các biến phải độc lập với nhau
- Không áp dụng được cho các biến thuộc kiểu logic
- Không áp dụng được cho các biến thuộc kiểu logic
II.3.4.2.5 Kỹ thuật phân hoạch tương đương (kiểm thử theo
các lớp tương đương)
+ Nguyên tắc: chia miền vào của chương trình thành các lớp dữ liệu để
lập ra các ca kiểm thử cho mỗi lớp đó.
+ Cơ sở: dữ liệu trong 1 lớp tương đương tác động như nhau lên chương
trình, tạo ra cùng một trạng thái: đúng hay sai của chương trình
+ Mục tiêu: tìm ra 1 ca kiểm thử để bộc lộ 1 lớp sai, từ đó rút gọn số ca
kiểm thử cần phát triển.
- Ca kiểm thử được thiết kế cho từng lớp tương đương
* Các trường hợp kiểm thử theo kỹ thuật phân hoạch tương đương:
+ Kiểm thử theo phân hoạch tương đương- lỗi đơn
+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp
+ Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ
+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ
* Ví dụ:
- Hãy xem xét một hàm F với các biến đầu vào x1, x2 có giá trị được
giới hạn và nằm trong các khoảng sau:
 a<= x1<=d với các khoảng giá trị là [a b), [b c), [c d]
 e<=x2<=g với các khoảng giá trị là [e f), [f g]
 Các giá trị không đúng là x1< a, x1>d and x2<e, x2>g
* Kiểm thử theo phân hoạch tương đương – lỗi đơn (hình 10)
- Sử dụng một biến từ mỗi lớp tương đương (hay một khoảng giá trị)
trong một trường hợp kiểm thử

- Dựa trên giả thiết lỗi đơn
- Số lượng trường hợp kiểm thử bằng số lượng nhiều nhất các khoảng
giá trị đúng mà một biến có thể nhận
Hình 10: Kiểm thử theo phân hoạch tương đương - lỗi đơn
* Kiểm thử theo phân hoạch tương đương- lỗi kết hợp
+ Không sử dụng giả thiết lỗi đơn
+ Mỗi trường hợp kiểm thử tương ứng với một phần tử của tích Đề các
của các lớp tương đương
a b c d
e
f
g
x1
x2

Hình 11: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp
* Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ: Xem xét
cả các giá trị không đúng với giả thiết lỗi đơn
Hình 12: Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ
* Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ: Xem
xét cả các giá trị không đúng với giả thiết lỗi đơn.
a b c d
e
f
g
x1
x2
a b c d
e
f
g
x1
x2

Hình 13: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ
II.3.4.2.6 Kiểm thử dựa vào bảng quyết định
Bảng quyết định được dùng để biểu diễn và phân tích các mối quan hệ
logic phức tạp
Chúng thường được dùng để mô tả các tình huống mà một số các hành
động sẽ được thực hiện khi một số điều kiện nhất định được thoả mãn.
* Cấu trúc bảng quyết định gồm 4 phần:
+ Tên điều kiện
+ Giá trị điều kiện
+ Tên hành động
+ Giá trị hành động
Bảng quyết định trong đó các điều kiện chỉ có thể nhận giá trị True hoặc
False được gọi là bảng quyết định với giá trị giới hạn. Nếu các điều kiện có thể
nhận nhiều giá trị khác nhau được gọi là bảng quyết định với giá trị mở rộng.
* Cách lập bảng quyết định:
- Lập bảng gồm 4 phần: Tên điều kiện, Giá trị điều kiện, Tên hành động,
Giá trị hành động
- Dữ liệu vào (input) đóng vai trò là các điều kiện của bảng quyết định
- Dữ liệu ra (output) đóng vai trò là các hành động của bảng quyết định
II.3.4.2.7 Kỹ thuật đồ thị nhân quả
a b c d
e
f
g
x1
x2

- Đồ thị nhân quả là một kỹ thuật thiết kế ca kiểm thử. Nó cung cấp một
biểu diễn chính xác các điều kiện logic và các hành động tương ứng.
- Kỹ thuật đồ thị nhân quả gồm 4 bước:
+ Lập danh sách các nguyên nhân (ĐK vào) và kết quả (hành động thực
hiện) cho từng module và gán định danh cho chúng.
+ Phát triển một đồ thị nhân quả.
+ Chuyển đồ thị đó thành bảng quyết định.
+ Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử.
* Ngoài hai phương pháp phổ biến trên ta cũng có thể tìm hiểu thêm về
phương pháp kiểm thử hộp xám (Gray – Box Test)
II.3.4.3. Kiểm thử hộp xám (Gray-Box Test)
Kiểm thử hộp xám là sự kết hợp giữa kiểm thử hộp đen và kiểm thử hộp
trắng. Mục đích của việc kiểm thử này là tìm ra những nhược điểm có liên
quan tới lỗi thiết kế, hoặc lỗi thi hành của hệ thống.
Trong kiểm thử hộp xám, người kiểm thử cần phải có những hiểu biết về
hệ thống và thiết kế các testcase hoặc dữ liệu kiểm thử dựa trên những kiến
thức về hệ thống.
Ví dụ, giả sử bạn phải test một ứng dụng web. Chức năng của ứng dụng
này rất đơn giản, bạn chỉ cần nhập các thông tin chi tiết về cá nhân bạn như
email và các trường quan trọng trên form web và submit form này. Server sẽ
lấy được thông tin này và dựa trên các trường quan trọng thu được và mail tới
email của bạn. Việc xác thực email xảy ra nơi client sử dụng Java Scripts.
Trong trường hợp này, không biết chi tiết sự thực thi , bạn phải test form
với những ID hợp lệ/không hợp lệ và các trường khác nhau để chắc chắn chức
năng đó là đúng.
Nhưng nếu bạn biết chi tiết việc thực hiện, bạn biết rằng hệ thống thực
hiện các giả định sau:
+ Server sẽ không bao giờ lấy mail không hợp lệ
+ Server sẽ không bao giờ gửi mail tới ID không hợp lệ
+ Server sẽ không bao giờ nhận các khai báo lỗi cho mail này.
Với mục đích của kiểm thử hộp xám, trong ví dụ trên bạn sẽ có một
testcase trên các client, nơi mà Java Scripts không hoạt động. Nó có thể xảy ra
với bất kỳ lí do nào và nếu nó xảy ra, việc xác thực có thể không thực hiện ở
site client. Trong trường hợp này, giả định hệ thống bị xâm phạm và:
+ Server sẽ lấy mail không hợp lệ

+ Server sẽ gửi mail tới những địa chỉ mail không hợp lệ
+ Server sẽ nhận những thông báo lỗi.
II.4. Các giai đoạn kiểm thử
- Trừ hệ thống nhỏ nói chung không nên kiểm thử nguyên cả khối, quá
trình kiểm thử có thể chia là các giai đoạn: kiểm thử đơn vị, tích hợp, hệ thống
và thẩm định .
II.4.1. Kiểm thử đơn vị
Kiểm thử đơn vị tập trung nỗ lực kiểm chứng vào đơn vị nhỏ nhất của
thiết kế phần mềm module. Bằng việc dùng mô tả thiết kế chi tiết làm hướng
dẫn các đường điều khiển quan trọng được kiểm thử và phát hiện ra lỗi trong
biên giới của module.
Kiểm thử đơn vị có các nội dung sau :
 Kiểm thử giao diện
 Khám nghiệm cấu trúc dữ liệu cục bộ.
 Kiểm thử với các điều kiện biên.
 Các đường Độc lập.
 Các đường xử lý sai.
II.4.2. Kiểm thử tích hợp
Là một kỹ thuật hệ thống để xây dựng cấu trúc chương trình trong khi
đồng thời tiến hành các kiểm thử để phát hiện lỗi liên kết với việc giao tiếp.
Mục đích là lấy các module đã kiểm thử đơn vị xong và xây dựng nên một cấu
trúc chương trình được quy định bởi thiết kế.
- Tích hợp từ trên xuống là cách tiếp cận tăng dần tới việc xây dựng cấu
trúc chương trình. Các modul được tích hợp bằng cách đi dần xuống qua cấp
bậc điều khiển, bắt đầu với module điều khiển chính (chương trình chính).
- Tích hợp từ dưới lên: bắt đầu xây dựng và kiểm thử với các module
nguyên tử (tức là các module ở mức thấp nhất trong cấu trúc chương trình), vì
các module này từ dưới lên nên việc xử lý yêu cầu với các module phụ thuộc
vào mức nào đó.
- Kiểm thử tích hợp nhằm nhận được một phần hay toàn bộ hệ thống
như mong đợi. Khi tích hợp các thành phần có thể gặp các sai:
 Dữ liệu bị mất khi đi qua một giao diện.
 Hiệu ứng bất lợi 1 module vô tình gây ra đối các module khác.

 Sự kết hợp các chức năng phụ có thể không sinh ra chức năng
chính mong muốn.
 Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấp
nhận được.
 Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra .
II.4.3. Kiểm thử hệ thống
Là một loạt các bước kiểm thử khác nhau có mục đích chính là thử đầy
đủ hệ thống dựa trên máy tính. Mặc dù mỗi kiểm thử đều có một mục tiêu khác
nhau, tất cả các việc nên kiểm thử lại rằng mọi phần tử hệ thống đều được tích
hợp đúng đắn và thực hiện chức năng được cấp phát.
Mỗi giai đoạn kiểm thử đều được thực hiện thông qua một loạt các kỹ
thuật kiểm thử có hệ thống, đều trợ giúp cho việc thiết kế các trường hợp kiểm
thử.
II.4.4. Kiểm thử thẩm định
Phần mềm được lắp ráp hoàn toàn thành một chương trình hoàn chỉnh,
các lỗi giao tiếp đã được phát hiện, sửa chữa và loạt kiểm thử phần mềm cuối
cùng - kiểm thử thẩm định - có thể bắt đầu.
Mục tiêu thẩm định: xem phần mềm có đáp ứng được yêu cầu khách
hàng không?
Việc thẩm định có thể được xác định theo nhiều cách, nhưng một định
nghĩa đơn giản là ở chỗ việc thẩm định thành công khi các chức năng phần
mềm theo một cách thức nào đó chính là cái khách hàng trông đợi một cách
hợp lý.

CHƯƠNG III
ĐỊNH NGHĨA TEST REQUIREMENT (TR)
VÀ TEST CASE (TC)
III.1. Test Requirement (TR)
III.1.1. Định nghĩa
Test requirement là một trình bày về những gì cần phải được kiểm thử trong
quá trình kiểm thử ứng dụng đó.
Yêu cầu chức năng: Yêu cầu về chức năng mà ứng dụng phải làm.
Yêu cầu phi chức năng : Yêu cầu về đặc tính mà chức năng phải có hay là
có thể được nhìn thấy. Ở đây có 3 loại: Look n feel, Boundary, Negative.
III.1.2. Thuộc tính của TR
 Mục tiêu nền tảng của TR
 Yêu cầu về hệ thống
 Sự mô tả về chức năng.
 Dự kiến vùng có vấn đề.
Thuộc tính và yêu cầu của TR:
 TR phải được viết ra
 TR phải rõ ràng và đặc trưng
 TR phải hoàn chỉnh
 TR phải chính xác
 TR phải phù hợp và nhất quán
 TR phải có dộ ưu tiên
 TR không được tối nghĩa
 TR có thể xác minh được
 TR phải xúc tích
 TR dung ngôn ngữ phải hiểu được
Tài liệu của 1 ứng dụng gồm có 3 loại: yêu cầu, đặc tả kỹ thuật, và thiết kế.
1 TR có thể được viết như 1 user story hay từ nguồn khác của phần mềm.
Người kiểm thử có thể sử dụng TR để thi hành, cài đặt test case
III.2. Test case
III.2.1. Giới thiệu
Định nghĩa: Là 1 tình huống kiểm tra, được thiết kế để kiểm tra 1 đối tượng
có thoả yêu cầu đặt ra hay không

Mục đích của test case:
- Tạo sự tin tưởng
- Thực thi lặp để tạo kết quả
- Lưu trữ kết quả test từ testcases
- Tự động
- Để tìm lỗi
- Để xác định rằng kiểm thử đang thực hiện đúng
- Sử dụng như công cụ để training kiểm thửu viên mới
- Xác nhận kiểm thử bao phủ
III.2.2. Yêu cầu của test case
- Phải có khả năng băt được lỗi
- Không được quá đơn giản cũng không được quá phức tạp
- Không thừa
- Làm cho sự sai lệch của chương trình trở nên rõ ràng
* 1 test case tốt:
Nhận biết được đối tượng đang kiểm thử
Có tiêu chí đánh giá pass hay fail
Phải chi tiết để bất cứ tester nào với những hiểu biết về hệ thống có thể thực
hiện được test case này.
* 1 test case không tốt:
Để người dung tự tìm dữ liệu test
Đưa ra những ý tưởng quá cao
Không xem xét như 1 người kiểm thử có kinh nghiệm
Đưa ra những bước khó xác định pass hay fail
III.2.3. Bản chất test case
Những thứ quan trọng trong 1 test case:
 Test case ID
 Test Description
 purpose/object/title
 Product/ Steps
 Script
 Expected result
 Obseved result.
III.2.4. Cú pháp test case
Hành động + Chức năng + Điều kiện
Chức năng có thể là : chức năng, tính năng, điểm xác định.

Điều kiện có thể là dữ liệu
Hành động :
 Xác định
 Kiểm thử
 Giá trị
 Thực thi
 Chạy
 Tính toán
…
Điểm xác định là là dự kiến kết quả.
Nó phải được viết ra.
III.3. Phương thức kiểm thử và kỹ thuật thiết kế Test
case
Tìm hiểu một vài loại kiểm thử
- Kiểm thử yêu cầu (Requirement testing)
- Kiểm thử thăm dò (Exploratory)
- kiểm thử smoke (Smoke testing)
- Kiểm thử hồi quy (Regresstion)
Test case:
- Tiêu chuẩn test case
- Bản chất test case
- Cú pháp test case
Một vài kỹ thuật thiết kế test case:
- Phân vùng tương đương
- Phân tích giá trị biên
III.3.1. Phương thức kiểm thử và một vài loại kiểm
thử
III.3.1.1. Phương thức kiểm thử
Một định nghĩa xây dựng để xác định, và đánh giá một sản phẩm , hệ thống,
hay 1 hệ thống mà sản xuất ra một kết quả kiểm thử.
III.3.1.2. Các loại kiểm thử
III.3.1.2.1. Kiểm thử yêu cầu cơ sở
- Kiểm thử yêu cầu
- Kiểm thử đặc tả phần mềm
- Kiểm thử sản phẩm dựa trên thông tin yêu cầu và tài liệu đặc tả kỉ thuật.

- Mục đích chính của kiểm thử này là xác định lại yêu cầu(Requirement
Validation ).
- Các bước xây dựng kiểm thử này:
+ Phân tích những yêu cầu cơ sở
+ Tập hợp thật nhiều thông tin
+ Bảo đảm chức năng đó hoạt động
+ Thực thi test case
III.3.1.2.2. Kiểm thử thăm dò
- Mục đích của kiểm thử thăm dò là để phát hiện ra những khiếm khuyết trong
sản phẩm mới.
- Nhiệm vụ là tìm cách để thiết kế thử nghiệm, khám phá từ những vùng đã biết
đến những vùng chưa biết.
-Kiểm thử thăm dò là loại kiểm thử mạnh, mục đích là thăm dò những vùng
yếu của chương trình.
- Một vài điều kiện lỗi phải đựơc kiểm tra:
- Ngoài giá trị biên
- Giá trị vào null và quá tải.
- Lỗi phần cứng và bộ nhớ.
- Kiểm thử thăm dò có thể xây dựng với số lỗi cao nhất.
III.3.1.2.3. Kiểm thử hồi quy
- Là loại kiểm thử chung của công việc
- Thực hiện re-run
- Kiểm định chất lượng không testing , không thực hiện tìm lỗi.
- Hao phí thời gian lớn
Kiểm thử hồi quy thì được thực hiện sau khi đã tạo thêm chức năng hay chỉnh
sửa lại chương trình.
Mục đích:
- Chạy lại những test case để xác định rằng những sửa đổi không gây
hỏng kết quả và hệ thống kia luôn đáp ứng yêu cầu với những chi tiết kỹ
thuật.
- Chạy lại test case để chắc chắn rằng những cái lỗi kia đã được sữa và
thật sự đã được sữa bởi những người lập trình.
III.3.1.2.4. Kiểm thử Smoke
- Kiểm thử smoke được biết đến như môt kiểm thử xác nhận.
- Kiểm thử này tiếp cận ứng dụng theo kiểu “rộng và sâu”
III.3.2. Một vài kỹ thuật thiết kế test case
- Phân vùng tương đương

- Phân tích giá trị biên
- Phân tích ràng buộc
- Quan hệ dữ liệu
- Chuyển trạng thái
- Điều kiện kết hợp
III.3.2.1. Phân vùng tương đương: (đã tìm hiểu ở chương
trên)
III.3.2.2. Phân tích giá trị biên: (đã tìm hiểu ở chương trên)
III.3.2.3. Điều kiện ràng buộc:
Là quan hệ giữa các biến khác nhau
Các bước chung để thiết kế kiểm thử sử dụng điều kiện rang buộc
- Xác định các biến độc lập và tìm quan hệ của chúng
- Xác định tất cả các giá trị vào ra cho các biến
- Danh sách các biến với dữ liệu vào ra và quan hệ của chúng
III.3.2.4. Quan hệ dữ liệu:
Những dữ liêu có quan hệ rang buộc với nhau.
Ví dụ: Chương trình kiểm tra “end day” với ngày “start day” thì start day
không thể sau “end day” được và “end day” thì không thế trước “start day”.
“end day”được định nghĩa bởi “start day”
III.3.2.5. Chuyển trạng thái:
Liên quan đến một phân tích mối quan hệ trong những giai đoạn, sự kiện
hay hành động mà gây ra chuyển trạng thái từ trạng thái này sang trạng thái
khác.
Các bước chung:
Xác định tất cả các giai đoạn hổ trợ
Định nghĩa kiểm thử
- Trạng thái băt đầu
- Sự kiện vào mà gây ra chuyển trạng thái
- Kết quả ra khi chuyển trạng thái
- Giai đoạn kết thúc
Người kiểm thử phải bao phủ hết cả khẳng đinh và phủ định
III.3.2.6. Điều kiện kết hợp:
Liên quan đến phân tích quan hệ kết hợp của các biến. Quan hệ đại diện
cho một điều kiện để kiêm thử.
Bước thực hiện;
- Xác định các biến
- Xác định các giá trị có thể của các biến
- Tạo bảng quan hệ điều kiện cho các biến
III.4. Các lỗi thường gặp khi kiểm thử

III.4.1. Các lỗi dữ liệu vào ra
I. Kiểu II. Thể hiện
III. Dữ liệu vào
IV. Dữ liệu vào đúng nhưng không được chấp
nhận
VI. Chấp nhận dữ liệu vào không đúng
VIII. Mô tả sai hoặc thiếu
X. Tham số sai hoặc thiếu
XI. Dữ liệu ra
XII. Định dạng sai
XIV. Kết quả sai
XVI. Dữ liệu đúng thể hiện vào thời điểm không
đúng
XVIII. Không hoàn thành hoặc thiếu kết quả
XX. Kết quả sai
XXII. Lỗi chính tả/ngữ pháp
III.4.2. Các lỗi logic
• Thiếu trường hợp
• Lặp trường hợp
• Điều kiện rườm rà không cần thiết
• Hiểu sai
• Thiếu điều kiện
• Điều kiện không liên quan đến công việc
• Kiểm tra sai biến
• Vòng lặp không đúng
• Sai toán tử
III.4.3. Các lỗi tính toán
• Thuật toán sai
• Thiếu sự tính toán
• Toán hạng sai

• Phép toán không đúng
• Lỗi trong dấu ngoặc đơn
• Thiếu độ chính xác
• Hàm có sẵn bị sai
III.4.4. Các lỗi giao diện
• Bắt lỗi dừng chương trình không đúng
• Thời gian vào ra dữ liệu
• Gọi đến thủ tục sai
• Gọi đến thủ tục không tồn tại
• Thiếu tham số
• Kiểu dữ liệu không thích hợp
• Sự bao gồm không cần thiết
III.4.5. Các lỗi dữ liệu
 Khởi tạo không đúng
• Lưu trữ/Truy cập không đúng
• Giá trị cờ/chỉ số sai
• Sử dụng biến sai
• Tham chiếu dữ liệu không đúng
• Kích thước dữ liệu không đúng
• Kiểu dữ liệu không đúng
• Phạm vi dữ liệu không đúng
• Dữ liệu không nhất quán

CHƯƠNG IV
ỨNG DỤNG LÝ THUYẾT ĐỂ THIẾT KẾ
TEST REQUIREMENTS VÀ TEST CASE
IV.1.Ví dụ về thiết kế TR và TC cho Gmail web
và ứng dụng Evernote
IV.1.1. TR và TC cho 1 số chức năng gmail
Từ những kiến thức đã học, thiết kế test requirement và test case cho một chức
năng trong gmail. Và chức năng được thực hiện trong ứng dụng này là “Thiết
kế test requirement và test case cho chức năng attachments trong Gmail”
Mục tiêu:
Biết cách để tạo test reuirement và test case cho một ứng dụng.
Thiết kế test requirement và test case theo chuẩn .
Test requirement:
TR-ID Test Requirements
Stat
us
Resoluti
on
TR Type Traceability
Requirements For Attachments
TR-
001
Verify that user can attach a file by choose
"Attach A File " link.
Ne
w
New
Function
al http://mail.google.com
TR-
002
Verify that user can remove file they attached by
choose "Remove"button
Ne
w
New
Look n
Feel
http://mail.google.com
TR-
003
Verify that user can't attach a file larger than 25Mb
Ne
w
New
Negative
l
TR-
004
Verify that user can download attachments are
sent.
Ne
w
New Function http://mail.google.com
TR-
006
Verify that user will get advice when
download attachments file types .exe.
Ne
w
New
Look n
Feel
TR-
007
Verify that user can attach multiple files at a
time by choose "Attach More File" link.
Ne
w
TR-
008
Verify that user can choose path for multiple
files need attach after choose "Attach More
File" link
Ne
w

TR-
009
Verify that user can see size file after
attached successful.
Ne
w
New
Look n
Feel
TR-
010
Verify that user can choose file want to send after
attached successful by tick on check box.
New New
Look n
Feel http://mail.google.com
Test case:
Step Type Description Data
Expected
Result
TC-0001
Verify user can
attach a file
Pre-
Conditio
ns
User login gmail
with abc account
create a file
test.doc
1 step
Go to compose mail
screen by click
compose
2 step
Click Attach a file
under the subject
field
Dialog box to
choose file
appaer
3 step
Browse through file
would like to
attach(test.doc)
file
test.doc
File need to
attach is selected
4 step Click Open
Screen attached
appear.
5 VP
User can see link
file has just
attached on
screen(test.doc).
6 step
click on link file
test.doc on screen
User can
download this
file, and this file
is same file
attached(test.doc
).
Post-
Conditio
ns
log out
TC-0002 Verify that user
can remove file

they attached by
choose
Remove"button
Pre-
Conditio
ns
User login gmail
with abc account
create a file
test.doc
1 step
Go to compose mail
screen
send mail screen
display
2 step
Click browse button
dialog box to
choose file display
3 Step
Choose file to
attach
test.doc choose file success
4 Step
Click open attach file success
6 Step Attach success
7 VP
Make sure exits a
attached file
8 Step
user can see file
attached(test.doc)
on scren.
9 Step Click Remove
file test.doc
disappeared
Post-
Conditio
ns
Logout
TC-0003
Verify that user
can't attach a file
larger than
25Mb .
Pre-
Conditio
ns
User login gmail
with abc account
Create file with size
30Mb name is
test.rar
1 Step
Go to compose mail
screen by click
compose
send mail screen
display
2 Step
Click Attach a file
under the subject
field
dialog box to
choose file
appear
3 Step
Choose path to file
want to attach
test.rar find file success
4
Step
click open
dialog box
error,user can't
attach file larger
25Mb appear

Post-
Conditio
ns
close dialog
TC-0004
Verify that user
can view the
attachment as
HTML with file
doc, xls, txt.
Pre-
Conditio
ns
User login gmail
with abc account
Make and send an
email with contents
sent from "xyz"
account:
Subject: test view
Content: hi every.
attachment :
test.doc
1 Step Go to Inbox screen
2 VP
Make sure exist an
email with following
contents sent from
"xyz" account:
Subject: test view
Content: hi every.
attachment :
test.doc
test.doc
3 Step
select "test view"
email sent from
"xyz" account
"Test view" email
was selected
4 Step
click view at
attachment
file appear with
docs google
5
VP
make sure file can
reading
view attachment
success
Post-
Conditio
ns
close file
Logout
IV.1.2. TR và TC cho ứng dụng Evernote
Ví dụ thiết kế test requirement và test case cho phần mềm Evernote.
Save
searc
h
Type Summary Steps Expected Results
SS001 Functionality Save search :
Verify that
user can
create saved
seaches for a
node
Pre-condition:
Login with account is
"tungnguyen259"
A note with name "School"
created.
Steps:
at the step 2 : A dialog to
fill name appear.
at the step 8 :A saved
searches created, with
name is "morning" and
content has note name is

1.Right click on "saved
searches" label.
2.Choose "create savea
searches".
3.Fill name : "Morning"
4.Click "OK" button
5.Right click on "Morning"
saved searches
6. Choose properties in
contact menu item.
7. Fill "school" into query
field.
8. Click "OK" button
Post-condition:
Delete saved search
Sign out
"school"
Verify that
user can
create saved
seaches with
all notebook
value
Pre-condition:
"tungnguyen259"
Create note with name:
"Hello"
Steps:
1. Open all notebook
seaches"label
3.Fill name "Allnote"
4.Click "OK"
Post-condition:
Delete saved search
Sign out
At step 4: A saved
searches with name
"allnote" created.
And saved search
"allnote" will appear all
note in all notebook.
Save search :
Verify that
user can
create saved
seaches with
notebook
value
Pre-condition:
"tungnguyen259"
Created notebook name:
"Home"
Created note in "Home"with
name: "Hello"
Steps:
1. Open notebook "Home"
seaches"label
3.Fill name ""Hoho"
4.Click "OK"
Post-condition:
Delete saved search
Sign out
At step 4: A saved
searches with name
"Hoho" created.
Saved searches "Hoho"
will appear all note in
"Home" notebook.
Tải bản FULL (88 trang): https://bit.ly/3Mc1wf5

Verify that
user can
rename
saved search
by pressing
"F2" key
Pre-condition:
"tungnguyen259"
A note name "school"
created.
A saved searches with
name "Morning" created.
Steps:
1.Click on "Morning" saved
search at list saved
searches.
2.Pressing "F2".
3.Fill new name : "Evening"
4.Pressing "Enter"
Post-condition:
Delete saved search
Sign out
At step 1: a Saved search
with name "Morning"
created.
At step 5: Saved
searches name "Morning"
changed with new name
is "Evening"
Verify that
user can
delete saved
search by
right click on
saved search
name choose
delete.
Pre-condition:
"tungnguyen259"
A note with name "School"
created.
A saved searches with
name is "morning" created.
Steps:
1.Right click on "Morning"
saved searches at list saved
searches.
2.Choose "delete saved
search" at contact menu
item.
3.Click "OK" button
Post-condition:
Delete saved search
Sign out
At step 1: A saved search
with name "Morning"
created.
At step 4: Saved
searches with name is
"Morning" deleted.
Clipping
text
Type Summary Steps Expected Results
CT001 Functionali
ty
Clipping
text :
verify that
User can
add file pdf
note
Pre-conditions:
login with account
"tungnguyen259"
Created a pdf file with name
is "Evernote-Windows-
Guide_3.5"
Steps:
1. Click on file pdf "Evernote-
Windows-Guide_3.5".
2. Right click on evernote
icon on taskbar
3. Choose "Clip current
selection" on contact menu
item.
4. Swich to evernote
5. Click on "Evernote-
Windows-Guide_3.5.pdf" in
interface evernote.
Post-conditions:
Delete file added
Sign out
At step 4: A clipper with
name "Evernote-
Windows-
Guide_3.5"appear at
interface evernote.
At step 5: User can view
content file "Evernote-
Windows-Guide_3.5.pdf"

CT002 Functionali
ty
Clipping
text :
verify that
A small
notification
window wil
appear
when
successfull
y added.
Pre-conditions:
Login with account
"tungnguyen259"
Created a pdf file with name
is "Today"
Steps:
1. Click on file pdf "Today".
icon on taskbar
item.
Post-conditions:
Delete saved searches.
Sign out
At step3:
A notification "1 note
added" appear.
CT003 Functionali
ty
Clipping
text :
Verify that
User can
add file jpg
note
Pre-conditions:
Login with account
"tungnguyen259"
Created a file with name is
"image.jpg"
Steps:
1. Click on file "image.jpg".
icon on taskbar
item.
4. Swich to evernote
5.Click on image.jpg in
interface evernote
Post-conditions:
Delete file created.
Delete file added
Sign out
At step 3: A notification
"1 notes added" apeear.
At step 4: A clipper with
name "image.jpg"appear
at interface evernote.
At step 5: user can view
file image.jpg
IV.2.Ví dụ về Bug và cách viết Bug
Mô tả bug trong phần mềm Minibank
Lổi chức năng “Account”:
bug ID 1
Summary:
User can create an account which balance is
negative number
Decription:
User can create an account which balance can be
negative number
Steps: 1. Open MiniBank.
2. Click "Accounts" button.
3. Fill number: 1010; firstname: "tung"; lastname:
"nguyen"; balance: -1500.
Tải bản FULL (88 trang): https://bit.ly/3Mc1wf5

4. Click "Process" button.
Obsevered: balance is -1500
Expected Result:
An error message will display and inform user can't
use negative number in balance.
Reproducible: Yes
Priority: High
Bug id 2
Sumary
User can create an account without name and
balance.
Decription:
When user create account, user must have
informations about account but this application user
can create an account is not name and balance.
Steps: 1. Open minibank
2. Click account
fill number: "0123"
fill lastname empty
fill firstname empty
fill balance empty
3. Click process
Observed Resultf
account create with number 0123, another fields
empty.
Expected Result: dialog box error appear
Reproducible: Yes
Priority: High
Bug id 3
Sumary Acount: user can create accounts same.
Decription: user can create accounts same number
2. Click account button
fill number textbox :"1234"
fill Lastname textbox: "Tung"
fill Firstname textbox:"Nguyen"
fill balance textbox:"1000"
3. Click process
4. Click account button
fill number textbox :"1234"
fill Lastname textbox: "Tung"
fill Firstname textbox:"Nguyen"
fill balance textbox:"1000"
5. Click process
Observed Resultf
two accounts created.
information same.
Expected Result: dialog error data input appear.
Reproducible: Yes
Priority: High
bug ID 4
Summary:
Account form: user can create an account with
invalid name.
Decription:
User can fill "firstname" and "lastname" textbox with
numeric character or special character
2. Click Account
3. Fill information in textboxes
6721802

TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN.pdf

Recommended

Recommended

More Related Content

Similar to TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN.pdf

Similar to TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN.pdf (20)

More from TieuNgocLy

More from TieuNgocLy (20)

Recently uploaded

Recently uploaded (20)

TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN.pdf