(123doc) Nghien Cuu Va Ung Dung Ky Thuat Kiem Thu Hop Den Trong Kiem Thu Website Thi Dua Khen TH Ong

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT HÀ NỘI
NGUYỄN THỊ VÂN
1221050117
ĐỒ ÁN TỐT NGHIỆP
NGÀNH CÔNG NGHỆ THÔNG TIN
ĐỀ TÀI
NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG
KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG
Hà Nội, 2017
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT
ĐỒ ÁN TỐT NGHIỆP
CHUYÊN NGÀNH TIN HỌC TRẮC ĐỊA
ĐỀ TÀI
NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG
KIỂM THỬ WEBSITE PHẦN MỀM THI ĐUA KHEN THƢỞNG
SINH VIÊN THỰC HIỆN GIÁO VIÊN HƢỚNG DẪN
NGUYỄN THỊ VÂN ThS. NGUYỄN TUẤN ANH

Lớp Tin học trắc địa K57 Bộ môn Tin học trắc địa
Hà Nội, 2017
Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa
MỤC LỤC
DANH MỤC CÁ C HÌ
NH VẼ .................................................................................. 6
DANH MỤC CÁ C BẢNG BIỂU ............................................................................ 7
KÝ HIỆU THUẬT NGỮ ......................................................................................... 8
LỜI CẢM ƠN......................................................................................................... 10
THÔNG TIN NGHIÊN CỨU ................................................................................ 11
1. Thông tin chung .............................................................................................. 11
2. Mục tiêu .......................................................................................................... 11
3. Nội dung chính................................................................................................ 11
MỞ ĐẦU ................................................................................................................ 12
1. Giới thiệu tổng quan ...................................................................................... 12
2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài ............................... 13
CHƢƠNG 1: TỔNG QUAN VỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ
PHẦN MỀM ........................................................................................................... 15
1.1. Định nghĩa chất lƣợng phần mềm ............................................................... 15
1.2. Định nghĩa đảm bảo chất lƣợng phần mềm ................................................ 15
1.3. Lỗi phần mềm .............................................................................................. 15
1.3.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm ......................... 15
1.3.2. Các nguyên nhân gây lỗi phần mềm .................................................... 15
1.3.3. Chi phí cho việc sửa lỗi phần mềm ...................................................... 17
1.3.4. Quy trình xử lý lỗi phần mềm .............................................................. 17
1.4. Kiểm thử phần mềm .................................................................................... 17
1.4.1. Khái niệm kiểm thử phần mềm ............................................................ 17
1.4.2. Lý do cần kiểm thử phần mềm ............................................................. 18
1.4.3. Mục tiêu của kiểm thử phần mềm ........................................................ 18
1.4.4. Các nguyên tắc cơ bản của kiểm thử phần mềm .................................. 18
1.4.5. Các phƣơng pháp kiểm thử .................................................................. 19
1.4.5.1. Kiểm thử tĩnh – Static testing ............................................................ 19
1.4.5.3. Kiểm thử hộp đen - Black box testing .............................................. 20
1.5. Quy trình kiểm thử phần mềm .................................................................... 21
Nguyễn Thị Vân 3 Lớp Tin Trắc Địa K57

1.5.1. Các bƣớc trong một quy trình kiểm thử phần mềm ............................. 21
1.5.2. Mô hình phát triển và kiểm thử phần mềm hình chữ V ........................ 22
1.5.3. Nhân lực kiểm thử phần mềm .............................................................. 25
1.5.4. Quy trình xây dựng kế hoạch kiểm thử ................................................ 25
1.6. Các cấp độ kiểm thử phần mềm. ................................................................. 28
1 .6.1. Kiểm thử đơn vị – Unit test ................................................................. 29
1.6.2. Kiểm thử tích hợp – Intergration Test .................................................. 30
1.6.3. Kiểm thử hệ thống – System Test ........................................................ 31
1.6.4. Kiểm thử chấp nhận sản phẩm – Acceptance Test............................... 34
1.6.5. Một số cấp độ kiểm thử khác ............................................................... 34
1.7. Nguyên tắc kiểm thử phần mềm.................................................................. 35
CHƢƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN ..................................... 36
2.1. Giới thiệu ..................................................................................................... 36
2.2 Quy trình kiểm thử hộp đen tổng quát ......................................................... 36
2.3. Equivalence Partitioning – Kỹ thuật phân lớp tƣơng đƣơng ...................... 37
2. 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên ....................... 39
2.5. Decision Tables – Kỹ thuật sử dụng bảng quyết định................................. 39
2.6 Pairwise Testing – Kỹ thuật kiểm thử các bộ n thần kỳ............................... 42
2.7. State Transition/Diagram Testing - Kỹ thuật biểu đồ chuyển trạng thái .... 47
2.8. Use case Testing – Kỹ thuật sử dụng use case ............................................ 47
2.9. Cause-Effect Diagram – Kỹ thuật dùng đồ thị nhân quả ............................ 48
2.10. Kỹ thuật đoán lỗi ....................................................................................... 52
2.11. Kết luận ..................................................................................................... 53
CHƢƠNG 3: TRIỂN KHAI KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG54
3.1. Kiểm thử ứng dụng Website........................................................................ 54
3.2. Kiểm thử website thi đua khen thƣởng tỉnh thanh hóa ............................... 55
3.2.1 Giới thiệu bài toán ................................................................................. 55
3.2.2. Biểu đồ mô tả các chức năng sẽ đƣợc thực hiện kiểm thử hộp đen ..... 56
3.2.3. Thiết kế định hƣớng trƣờng hơp kiểm thử ........................................... 57
3.3 Thiết kế bộ các test case ............................................................................... 61

3.3.1. Test case kiểm thử chức năng đăng nhập, thay đổi mật khẩu, đăng
xuất. ................................................................................................................ 61
3.3.2. Test case kiểm thử chức năng đăng kí ................................................. 67
3.3.3. Testcase kiểm thử chức năng Quản lý đợt thi đua ............................... 69
3.3.4. Test case kiểm thử chức năng Hồ sơ lƣu ............................................. 79
3.3.5. Test case sử dụng kỹ thuật use case ..................................................... 84
3.3.6. Testcase kiểm thử Giao diện ................................................................ 88
3.4 Thực thi test và báo cáo kết quả . ................................................................. 89
TÀI LIỆU THAM KHẢO ...................................................................................... 92

DANH MỤC CÁC HÌ

NH VẼ
Hình 1-1. Mô hình phát triển và kiểm thử phần mềm hình chữ V ..................................21
Hình 1-2. Sơ đồ nhân lực kiểm thử phần mềm............................................................... 22
Hình 1- 3. Xây dựng kế hoạch kiểm thử ....................................................................... 23
Hình1- 4. Sơ đồ các cấp độ kiểm thử .............................................................................26
Hình 2-1. Quy trình kiểm thử hộp đen tổng quát ............................................................34
Hình 2-2. Giao diện đăng nhập hệ thống. ...................................................................... 36
Hình 2-3. Cấu trúc bảng quyết định .............................................................................. 38
Hình 2-4. Giao diện PictMaster Tool............................................................................. 44
Hình 2-5. Đồ thị nhân – quả cho bài toán tính thuế thu nhập ...................................... 48
Hình 3-1. Giao diện phần mềm thi đua khen thƣởng .....................................................53
Hình 3-2. Biểu đồ quản lý testcase ...............................................................................54
Hình 3-3. Màn hình đăng nhập thi đua khen thƣởng...................................................... 58
Hình 3-4. Màn hình chức năng đăng kí ......................................... .............................. 64
Hình 3-5. Màn hình quản lý đợt thi đua ........................................................................ 66
Hình 3-6. Màn hình quản lý hồ sơ ................................................................................. 75
Hình 3-7. Biểu đồ use case thi đua khen thƣởng ........................................... .......... 80

DANH MỤC CÁC BẢNG BIỂU
Bảng 1-1. Kiểm thử giao diện ngƣời sử dụng ................................................................30
Bảng 2-1. Bảng quyết định bài toán kiểm tra thẻ đƣờng sắt ...........................................39
Bảng 2-2. Bảng các trƣờng hợp kiểm thử sử dụng kỹ thuật pairwise testing ................ 43
Bảng 2-3. Khuôn mẫu đặc tả use case theo Alistair Cockburn .................................... 46
Bảng 2-4. Bảng các ký hiệu sử dụng trong đồ thị nguyên nhân – hệ quả ..................... 46
Bảng 2-5. Bảng quyết định cho đồ thị nhân – quả bài toán tính thuế thu nhập............ 49
Bảng 2-6. Bảng testcase sử dụng kỹ thuật dùng đồ thị nhân – quả.............................. 50
Bảng 3-1. Bảng thiết kế quy trình kiểm thử.................................................................. 58
Bảng 3-2. Test case đăng nhập – đăng xuất – thay đổi mật khẩu phần mềm thi đua khen
thƣởng ............................................................................................................................ 59
Bảng 3-3. Bảng dùng kỹ thuật quyết định chức năng đăng kí ....................................... 64
Bảng 3-4. Testcase đăng kí thi đua .............................................................................. 66
Bảng 3-5. Testcase đợt thi đua .......................................................................................68
Bảng 3-6. Testcase quản lý hồ sơ ................................................................................. 76
Bảng 3-7. Testcase giao diện ....................................................................................... 78
Bảng 3-8. Mô tả use case ...............................................................................................82
Bảng 3-9. Testcase sử dụng kỹ thuật use case .................................................. .......... 82
Bảng 3-10. Bảng báo cáo .............................................................................................. 85

KÝ HIỆU THUẬT NGỮ
Ký hiệu/ Thuật ngữ Ý nghĩa
Static testing Kiểm thử tĩnh
Dynamic testing Kiểm thử động
Blackbox Testting Kiểm thử hộp đen
White box testing Kiểm thử hộp trắng
Unit Tests Kiểm thử đơn vị
Intergration Tests Câu hỏi và trả lời
System Tests Kiểm thử hệ thống
Acceptance Tests Kiểm thử chấp nhận
Test case Trƣờng hợp kiểm thử
Test suite Tập hợp các trƣờng hợp kiểm thử trong Selenium
Test script Tập hợp các trƣờng hợp kiểm thử
Selenium RC Selenium Remote Control
Test Manager Ngƣời quản lí kiểm thử
Test Leader Quản lí nhóm kiểm thử
Test Analyst Phân tích kiểm thử
Test Designer Thiết kế kiểm thử
Test Executing Thi hành kiểm thử

Test Report Báo cáo kiểm thử
QC team Đội kiểm tra chất lƣợng
Developers Lập trình viên
PM Quản lídự án
Customer Khách hàng
Test Analyst Phân tích kiểm thử
Test Designer Thiết kế kiểm thử
Project Leader Quản lí dự án
API Application Programming Interface

LỜI CẢM ƠN
Đồ án tốt nghiệp này đƣợc thực hiện tại Trƣờng đại học Mỏ - Địa chất. Em xin
cảm ơn các thầy cô giáo Bộ môn Tin học trắc địa và khoa Công nghệ thông tin Trƣờng
đại học Mỏ - Địa chất đã tạo mọi điều kiện thuận lợi về mặt thủ tục trong quá trình em
làm đồ án.
Em xin chân thành cảm ơn thầy giáo Ths. Nguyễn Tuấn Anh đã trực tiếp tận tình
hƣớng dẫn, giúp đỡ, tạo mọi điều kiện thuận lợi trong suốt quá trình em làm đồ án, luôn
theo sát và đƣa ra những lời khuyên, động viên kịp thời giúp em hoàn thành đồ án một
cách suất sắc nhất; cảm ơn các thầy cô giáo đã trực tiếp giảng dạy trong suốt thời gian
học tập tại trƣờng.
Để thực hiện đƣợc các thử nghiệm trong nghiên cứu này, em xin chân thành cảm
ơn Công ty cổ phẩn đầu tƣ và phát triển Tâm Việt đã tạo điều kiện thuận lợi cho em
đƣợc thực tập tốt nghiệp tại công ty. Đặc biệt em xin gửi lời cảm ơn tới Giám Đốc
Lƣơng Thanh Bình – đảm bảo chất lƣợng phần mềm đã trực tiếp hƣớng dẫn, giúp đỡ tận
tình để em có thể nắm bắt công việc, nghiên cứu kiến thức về kiểm thử phần mềm và
vận dụng những kiến thức đƣợc học vào thực hành dự án.
Bên cạnh đó, con xin gửi lời cảm ơn tới bố mẹ chị gái và em trai đã giúp đỡ, sát
cánh bên con trong những hoàn cảnh khó khăn nhất. Và con cũng xin gửi lời cảm ơn tới
các bác, các anh chị đã và luôn động viên tinh thần giúp con có thêm nghị lực phấn đấu
trong học tập và cuộc sống.
Mặc dù đã hết sức cố gắng hoàn thành đồ án với toàn bộ nỗ lực của bản thân,
nhƣng với năng lực kiến thức bản thân còn hạn chế nên đồ án không tránh khỏi những
thiếu sót. Kính mong thầy cô và các bạn góp ý, giúp đỡ em để em có thể hoàn thiện kiến
thức của bản thân nhiều hơn và phát triển đồ án, định hƣớng mới hơn trong tƣơng lai.
Một lần nữa, em xin trân trọng gửi lời cảm ơn tới tất cả mọi ngƣời và em mong sẽ
nhận đƣợc nhiều sự góp ý quý báu của các thầy cô và các bạn. Em xin chân thành cảm
ơn!

THÔNG TIN NGHIÊN CỨU

1. Thông tin chung
- Tên đề tài: Nghiên cứu và ứng dụng kiểm thử hộp đen trong kiểm thử website
phần mềm thi đua khen thƣởng
- Sinh viên thực hiện: Nguyễn Thị Vân
- Mã sinh viên 1221050117
- Lớp: Tin học Trắc Địa – K57
- Hệ đào tạo: Chính quy
- Điện thoại: 01679826134
- Email: nguyenvan021194@gmail.com
- Đồ án tốt nghiệp đƣợc thực hiện tại: Hà Nội
- Thời gian thực hiện: 2017
2. Mục tiêu
Mục tiêu chính của đề tài là đƣa ra cái nhìn tổng quan về các kỹ thuật kiểm thử và đi
sâu vào việc tìm hiểu các kỹ thuật kiểm thử hộp đen đã và đang đƣợc sử dụng. Đồng
thời áp dụng đƣợc các kỹ thuật đó vào quy trình kiểm thử cho phần mềm Thi đua khen
thƣởng
3. Nội dung chính

- Xác định mục tiêu đề tài
- Nghiên cứu các vấn đề kiểm thử
- Tìm hiểu phân tích các kỹ thuật kiểm thử hộp đen
- Tìm hiểu quy trình nghiệp vụ của phần mềm
- Lựa chọn các kỹ thuật kiểm thử thích hợp
- Thiết kế test case cho phần mềm
- Thực hiện kiểm thử
- Đƣa ra kết quả kiểm thử và kết luận
4. Kết quả chính đạt đƣợc
 Hoàn thành tìm hiểu về kiểm thử, nắm đƣợc các kỹ thuật kiểm thử hộp đen cơ
bản, áp dụng vào các bài toán cụ thể.
 Hoàn thành việc tìm hiểu về dự án, chức năng của phần mềm cần kiểm thử tại
đơn vị phụ trách.
 Hoàn thành việc nghiên cứu quy trình kiểm thử, vận dụng các kỹ thuật đã nghiên
cứu vào việc thiết kế bộ các trƣờng hợp kiểm thử.

MỞ ĐẦU
1. Giới thiệu tổng quan
Tổng quan tình hình nghiên cứu thuộc lĩnh vực của đề tài. Trong giai đoạn phát triển
của công nghệ thông tin, ngành công nghệ phần mềm đang ngày chiếm một vị trí quan
trọng trong xu hƣớng phát triển kinh tế công nghiệp hóa hiện đại hóa của đất nƣớc ta.
Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất lƣợng phần mềm
luôn là thách thức với bản thân ngành phần mềm khi thực tế đã chứng minh, kiểm thử
phần mềm là giai đoạn chiếm đến hơn 40% thời gian, kinh phí và nguồn nhân lực phát
triển dự án phần mềm hiện nay.
Bên cạnh đó số lƣợng kỹ sƣ kiểm thử phần mềm Việt Nam hiện nay vẫn chƣa đáp
ứng đƣợc nhu cầu thị trƣờng. Các dự án lập trình phần mềm trên thế giới, trung bình cứ
3 lập trình viên có1 kiểm thử viên trong khi đó ở Việt Nam số lƣợng đó là 5 : 1. Tại hội
nghị quốc tế kiểm thử tự động năm 2011 tại TP.HCM cho biết với đà phát triển của
ngành công nghiệp phần mềm nhƣ hiện nay thìViệt Nam trong thời gian tới sẽ thiếu
khoảng 10.000 tester. Chúng ta đã và đang chứng kiến sự tăng trƣởng đáng kinh ngạc
của ngành công nghiệp phần mềm trong vài thập kỷ qua. Nếu nhƣ trƣớc đây phần mềm
máy tính chỉ đƣợc sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu thìngày nay
nó đã đƣợc ứng dụng vào mọi mặt của của đời sống hàng ngày của con ngƣời, từ các
ứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình đến các ứng dụng lớn hơn
nhƣ trợ giúp điều khiển các phƣơng tiện và hệ thống giao thông, trả tiền cho các hoá
đơn, quản lý và thanh toán về tài chính, v.v...Vìthế con ngƣời ngày càng phụ thuộc chặt
chẽ vào các sản phẩm phần mềm và do vậy đòi hỏi về chất lƣợng của các sản phẩm phần
mềm ngày càng cao, tức là các phần mềm phải đƣợc sản xuất với giá thành hạ, dễ dùng,
an toàn và tin cậy đƣợc. Kiểm thử có phƣơng pháp là một hoạt động không thể thiếu
trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lƣợng nêu trên của các
sản phẩm phần mềm. Kiểm thử phần mềm là đề tài đang ngày càng nhận đƣợc sự quan
tâm, nghiên cứu lớn bởi tầm quan trọng của nó. Các kỹ thuật kiểm thử đã và đang đƣợc
nghiên cứu phát triển trong ngành phần mềm trên khắp thế giới, nổi bật nhƣ ISTQB
(International Software Testing Quanlifications Board) là một tổ chức phi lợi nhuận
cung cấp chứng chỉ thẩm định chất lƣợng của kiểm thử phần mềm có giá trị toàn cầu đã
đƣa ra hệ thống một loạt các tài liệu, sách cung cấp kiến thức về lý thuyết kiểm thử và
kỹ thuật kiểm thử phần mềm. Ở nƣớc ta, trong khoa Công nghệ thông tin thuộc các
trƣờng đại học đã đặt kiểm thử phần mềm thành một môn học chính thức và xây dựng
giáo trình, bài giảng riêng cho môn học này, ví dụ nhƣ bài giảng điện tử môn học kiểm
thử và bảo đảm chất lƣợng phần mềm của tác giả Thạc Bình Cƣờng, Khoa Công nghệ
thông tin, Trƣờng đại học Bách khoa Hà Nội đã trình bày khá chi tiết về lý thuyết các kỹ
thuật kiểm thử. Ngoài ra là các đề tài nghiên cứu đi sâu vào một kỹ thuật kiểm thử riêng.

Tuy nhiên, trong quá trình tìm hiểu làm đồ án thì chƣa có đề tài cụ thể nào về việc vận
dụng tất cả các kỹ thuật kiểm thử vào việc phân tích, kiểm thử cho một sản phẩm phần
mềm thực tế nào mà phần lớn mới chỉ dừng lại ở việc chỉ ra những ví dụ demo đơn lẻ
cho từng kỹ thuật. Đặc biệt kiểm thử phần mềm thi đua đua khen thƣởng là một lĩnh vực
kiểm thử khá mới mẻ và đang thu hút các công ty phát triển phần mềm thì đề tài về vấn
đề này hiện chƣa đƣợc nghiên cứu cụ thể trong một đề tài nào.
2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài
Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bƣớc đệm giữa giai đoạn
xây dựng phần mềm và sử dụng phần mềm, trƣớc khi giao sản phẩm hoàn chỉnh cho
khách hàng. Mặc dù công việc kiểm thử phần mềm không xa lạ song những khái niệm
và kỹ thuật lại khá rắc rối. Ở mỗi loại và mỗi miền ứng dụng riêng biệt lại có các đặc thù
riêng và cần đƣợc bổ trợ bởi các kỹ thuật kiểm thử riêng cho chúng. Ngƣời kiểm thử có
thể hiểu và tự phát triển các kỹ thuật kiểm thử thích hợp cho các hệ thống phức tạp và
chuyên dụng hơn dựa trên các kỹ thuật cơ bản. Phần mềm đã và đang đƣợc ứng dụng
vào trong tất cả mọi mặt của cuộc sống hàng ngày, trong đó thi đua khen thƣởng là lĩnh
vực đƣợc cho là cơ hội lớn đối với ngành phần mềm trong nƣớc khi mà các dự án về
giáo dục, hành chính luôn đƣợc chú trọng. Để giải quyết việc thủ tục hồ sơ khen thƣởng
giấy tờ cồng kềnh phức tạp. Việc tạo ra một sản phẩm có thể bán đƣợc trên thị trƣờng
đòi hỏi sự nỗ lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên. Số lƣợng
dòng mã lên đến hàng triệu. Và để tạo ra một sản phẩm thìkhông phải chỉ do một tổ
chức đứng ra làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản
phẩm, thƣ viện lập trình,...của nhiều tổ chức khác nhau...Từ đó đòi hỏi việc kiểm thử
phần mềm càng ngày càng trở nên rất quan trọng.
Sự ra đời của phần mềm thi đua khen thƣởng mang đến hàng loạt các giải pháp cho
thủ tục hồ sơ hành chính đi kèm mang lại những hiệu quả to lớn trong công tác quản lý
hồ sơ, mặt khác còn là công cụ giúp Lãnh đạo, cán bộ giám sát kiểm soát hoạt đông thi
đua khen thƣởng tỉnh giám sát, kiểm soát hoạt động thi đua khen thƣởng ở các đơn vị cơ
sở .Điều này mở ra một thời cơ lớn cho ngành công nghệ phần mềm đồng thời với đó là
sự cạnh tranh về hiệu quả, chất lƣợng phần mềm của các đơn vị thực hiện. Quản lý chất
lƣợng phần mềm là vấn đề không mới nhƣng theo một số đánh giá là còn yếu của các
công ty phần mềm Việt Nam. Kiểm thử là một hoạt động mang tính sống còn trong các
dự án sản xuất hoặc gia công phần mềm. Ngƣời làm phần mềm đều hiểu rõ vai trò quan
trọng của nó, tuy nhiên không phải ai (trong ngành và ngoài ngành) cũng đều hiểu rõ
hoạt động này. Bản thân công việc kiểm thử phần mềm cũng là một lĩnh vực hoạt động
độc lập và khá “hấp dẫn”.Song song với sự phát triển các công nghệ lập trình, các ngôn
ngữ lập trình...thìcác công nghệ và kỹ thuật kiểm thử phần mềm ngày càng phát triển và
mang tính khoa học. Mỗi một cơ quan, đơn vị lại có yêu cầu riêng về kỹ năng đối với

ngƣời phụ trách kiểm thử. Đứng trƣớc một phần mềm cần kiểm thử mà ngƣời kiểm thử
không có kiến thức hay thông tin nào về thông tin hiện thực phần mềm nhƣ mã nguồn
của phần mềm, giải thuật đƣợc dùng, các dữ liệu xử lý...thìkiểm thử hộp đen là chính
chiến lƣợc cho vấn đề này. Việc hiểu và nắm vững các kỹ thuật kiểm thử hộp đen là yêu
cầu cơ bản, quan trọng hàng đầu đối với một ngƣời thực hiện công việc kiểm thử. Từ
những phân tích trên, xác định đƣợc việc nắm rõ các kỹ thuật kiểm thử là yêu cầu tiên
quyết của một ngƣời thực hiện công việc kiểm thử. Trong báo cáo đồ án này đƣợc chia
thành 3 chƣơng với nội dung nhƣ sau:
Chƣơng 1: Tổng quan về Chất lƣợng phần mềm và Kiểm thử phần mềm:
Chƣơng này trình bày về những định nghĩa cơ bản về phần mềm, ngành công
nghệ phần mềm, lỗi phần mềm, và qui trình xử lý lỗi phần mềm. Kiến thức cơ
bản về kiểm thử phần mềm nhƣ các nguyên tắc kiểm thử, các phƣơng pháp kiểm
thử, các giai đoạn kiểm thử phần mềm, kiểm thử hộp đen, kiểm thử hộp trắng.
Chƣơng 2: Trình bày các kỹ thuật kiểm thử hộp đen: Kỹ thuật phân lớp tƣơng
đƣơng, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật
kiểm thử n bộ, kỹ thuật dùng lƣợc đồ trạng thái, kỹ thuật dùng use case, kỹ thuật
dùng đồ thị nhân quả và kỹ thuật đoán lỗi
Chƣơng 3: Kiểm thử giao diện ứng dụng Website.
Chƣơng này trình bày khái quát về Kiểm thử ứng dụng Website, đặc điểm về chất
lƣợng của một ứng dụng Website, áp dụng viết kịch bản và thực thi kiểm thử cho
một số chức năng cơ bản của ứng dụng website Thi đua khen thƣởng.

CHƢƠNG 1: TỔNG QUAN VỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM

THỬ PHẦN MỀM
1.1. Định nghĩa chất lƣợng phần mềm
Có rất nhiều định nghĩa về chất lƣợng phần mềm đƣợc đƣa ra bởi các tổ chức, cá
nhân khác nhau. Trong phạm vi của đồ án này trình bày một số định nghĩa tiêu biểu.
Định nghĩa theo IEEE (1991):
- Định nghĩa 1: Chất lƣợng phần mềm là một mức độ mà một hệ thống, thành phần
hệ thống hay tiến trình đáp ứng đƣợc yêu cầu đã đƣợc đặc tả.
- Định nghĩa 2: Chất lƣợng phần mềm là mức độ mà một hệ thống, thành phần hệ
thống hay tiến trình đáp ứng đƣợc yêu cầu và sự mong đợi của khách hàng hay
ngƣời sử dụng.
1.2. Định nghĩa đảm bảo chất lƣợng phần mềm

Định nghĩa theo Daniel Galin: Đảm bảo chất lƣợng phần mềm (Soft are Quality
Assure) là một tập hợp các hành động cần thiết đƣợc lên kế hoạch một cách hệ thống để
cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các
yêu cầu chức năng kỹ thuật cũng nhƣ các yêu cầu quản lý theo lịch trình và hoạt động
trong giới hạn ngân sách.
1.3. Lỗi phần mềm
1.3.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm
- Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhƣng có thể
hiểu và phát biểu một cách đơn giản thì"Lỗi phần mềm là sự không khớp giữa
chƣơng trình và đặc tả của nó".
- Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:
+ Lỗi sai: Sản phẩm phần mềm đƣợc xây dựng khác với đặc tả.
+ Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhƣng
lại không có trong sản phẩm thực tế.
+ Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc
tả.
1.3.2. Các nguyên nhân gây lỗi phần mềm

Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả các nguyên
nhân chủ quan và các nguyên nhân khách quan. Dƣới đây là chín nguyên nhân chủ yếu
gây ra lỗi phần mềm:

- Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu thƣờng nằm
ở phía khách hàng.
- Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này thƣờng
xuất hiện trong giai đoạn đầu của dự án. Một số lỗi hay gặp phải: hiểu sai chỉ dẫn
trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trình bày bằng lời nói và
tài liệu, hiểu sai về phản hồi và thiếu quan tâm đến những đề cập của khách hàng.
 Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và nhà cung cấp để
tránh lỗi trong giao tiếp. Ủy ban do quản trị dự án đứng đầu và khách hàng phải
giới thiệu những ngƣời hiểu về mặt nghiệp vụ vào ủy ban đó.
- Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trƣờng hợp các nhà
phát triển cố tình làm sai lệch các yêu cầu trong tài liệu đặc tả. Nguyên nhân của
việc này đến từ các áp lực thời gian, ngân sách, hay cố tình sử dụng lại các mô-
đun từ các dự án trƣớc mà chƣa phân tích đầy đủ những thay đổi để thích nghi
với các yêu cầu mới.
 Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải pháp nhƣ
thế nào, sắp xếp ƣu tiên xem bỏ đƣợc yêu cầu nào hay sử dụng lại đƣợc mô-đun
nào.
- Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia thiết
kế hệ thống, các kiến trúc sƣ hệ thống, kỹ sƣ phần mềm, các nhà phân tích xây
dựng phần mềm theo yêu cầu. Các lỗi điển hình bao gồm:
+ Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai.
+ Quy trình định nghĩa có chứa trình tự lỗi.
+ Sai sót trong các định nghĩa biên nhƣ > 3 hay ≥ 3.
+ Thiếu sót các trạng thái hệ thống phần mềm đƣợc yêu cầu.
+ Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên gây ra
các lỗi lập trình. Những lý do này bao gồm: Sự hiểu sai các tài liệu thiết
kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sót trong việc áp dụng
các công cụ phát triển; sai sót trong lựa chọn dữ liệu...
+ Không tuân thủ theo các tài liệu hƣớng dẫn và tiêu chuẩn lập trình: Các lỗi
phần mềm có thể đến từ việc không tuân thủ các tài liệu và tiêu chuẩn lập
trình của các tổ chức phát triển phần mềm.
+ Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ chính quá
trình kiểm thử khi mà ngƣời kiểm thử để lọt lỗi.
 Những lỗi này đến từ các nguyên nhân sau đây:
+ Kế hoạch kiểm thử chƣa hoàn chỉnh, để sót yêu cầu cần kiểm thử.
+ Lỗi trong tài liệu và báo cáo kiểm thử.
+ Việc sửa chữa các lỗi đƣợc phát hiện không hoàn chỉnh do áp lực thời gian
hay do thiếu cẩn thận.

 Giải pháp khắc phục: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu của dự án.
- Các lỗi thủ tục: Các thủ tục hƣớng dẫn cho ngƣời sử dụng tại từng bƣớc của tiến
trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phức tạp
mà các tiến trình đƣợc thực bằng nhiều bƣớc, mỗi bƣớc có thể có nhiều kiểu dữ
liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có thể đến từ việc viết
các thủ tục.
- Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo trì
đôi khi có những sai sót trong các tài liệu liên quan. Những lỗi này có thể là
nguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì.
1.3.3. Chi phí cho việc sửa lỗi phần mềm

Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của
vòng đời phần mềm.Tuy nhiên công việc này nên đƣợc thực hiện càng sớm càng tốt vì
càng về giai đoạn sau của vòng đời phần mềm, chi phícho việc tìm và sửa lỗi càng tăng,
đặc biệt là đến giai đoạn đã triển khai phần mềm thìchi phícho sửa lỗi sẽ trở nên rất lớn
và ảnh hƣởng trực tiếp đến uy tín của tổ chức phát triển phần mềm.
1.3.4. Quy trình xử lý lỗi phần mềm

- Quy trình xử lý lỗi có thể bao gồm 6 bƣớc chính:
Bƣớc 0: Bắt đầu: Phát hiện phần mềm có lỗi.
Bƣớc 1: Đƣa lỗi lên hệ thống quản lý lỗi.
Bƣớc 2: Gán lỗi cho nhân viên phát triển.
Bƣớc 3: Xử lý lỗi.
Bƣớc 4: Kiểm thử lại.
Bƣớc 5: Đóng lỗi.
1.4. Kiểm thử phần mềm
1.4.1. Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là quy trình đƣợc sử dụng để đánh giá, kiểm tra chất lƣợng
phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của ngƣời sử dụng đối với
sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trong các môi trƣờng, các
trƣờng hợp khác nhau.
Có thể định nghĩa một cách dễ hiểu nhƣ sau:

Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế
để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và
không thực hiện bất cứ thứ gìkhông mong muốn. Đây là một pha quan trọng trong quá
trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ
thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
1.4.2. Lý do cần kiểm thử phần mềm

 Phần mềm nào cũng có lỗi bởi vì nó do con ngƣời làm ra.
 Kiểm thử độ tin cậy của phần mềm.
 Các lỗi đang dùng trong thực tế có thể rất tốn chi phí cũng nhƣ gây nguy hiểm
đến con ngƣời.
 Tránh kiện tụng của khách hàng.
 Phát triển doanh nghiệp.
 Lỗi phát hiện càng sớm thìchi phíkhắc phục càng nhỏ.
1.4.3. Mục tiêu của kiểm thử phần mềm

 Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm đƣợc kiểm thử.
 Tiến hành sửa lỗi ở các phần mềm đƣợc kiểm thử và kiểm thử lại cho đến khi đạt
một mức độ chất lƣợng phần mềm chấp nhận đƣợc.
 Thực thi những trƣờng hợp kiểm thử một cách hiệu quả trong một giới hạn ngân
sách và lịch trình cho phép.
1.4.4. Các nguyên tắc cơ bản của kiểm thử phần mềm
Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc đó là:
 Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điều ngƣợc lại:
Kiểm thử có thể cho thấy sự có mặt của lỗi nhƣng không thể chứng minh điều
ngƣợc lại là chƣơng trình không có lỗi. Việc kiểm thử giảm nguy cơ không tìm
thấy lỗi trong phần mềm nhƣng ngay cả khi không tìm thấy lỗi thì cũng không thể
chứng minh đƣợc sản phẩm phần mềm đƣợc phát triển hoàn toàn chính xác.
 Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện đƣợc cho tất mọi
trƣờng hợp kiểm thử. Do vậy thay vì kiểm thử mọi khía cạnh, ta phải tập trung
vào kiểm thử những yếu tố quan trọng và nhiều rủi ro.
 Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong
vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểm thử nhất
định.
 Phân cụm lỗi: Một số lƣợng nhỏ các mô-đun phần mềm có thể chứa hầu hết các
lỗi đƣợc phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết các lỗi
vận hành.

 Kiểm thử ngƣợc: Nếu một phƣơng pháp kiểm thử đƣợc lặp đi lặp lại nhiều lần,
các trƣờng hợp kiểm thử giống nhau sẽ không phát hiện đƣợc triệt để lỗi mới. Để
khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngƣợc", các trƣờng
hợp kiểm thử cần phải đƣợc xem xét và duyệt lại một cách đều đặn, và việc kiểm
thử mới cần phải đƣợc viết lại để thực thi những phần khác của phần mềm hay hệ
thống để tìm ra nhữ ng lỗi tiềm ẩn.
 Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử đƣợc thực hiện trong những
hoàn cảnh khác nhau thì khác nhau.
 Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp đƣợc gì nếu hệ
thống không dùng đƣợc hoặc không đáp ứng đƣợc yêu cầu và sự mong đợi của
khách hàng.
1.4.5. Các phƣơng pháp kiểm thử

Phân loại dựa vào các yếu tố: Chiến lƣợc kiểm thử; Phƣơng pháp kiểm thử; Kỹ thuật
kiểm thử.
 Chiến lƣợc kiểm thử

+ Kiểm thử thủ công
+ Kiểm thử tự động
 Phƣơng pháp tiến hành kiểm thử

+ Kiểm thử tĩnh
+ Kiểm thử động
 Kỹ thuật kiểm thử

+ Kiểm thử hộp đen
+ Kiểm thử hộp trắng
+Kiểm thử hộp xám
1.4.5.1. Kiểm thử tĩnh – Static testing

Là phƣơng pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả
bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không
cần chạy chƣơng trình. Kiểu kiểm thử này thƣờng đƣợc sử dụng bởi chuyên viên thiết kế
ngƣời mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể đƣợc tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao
gồm các chƣơng trình đƣợc phân tích bởi một trình thông dịch hoặc biên dịch mà xác
nhận tính hợp lệ về cú pháp của chƣơng trình.

1.4.5.2. Kiểm thử động – Dynamic testing
Là phƣơng pháp thử phần mềm thông qua việc dùng máy chạy chƣơng trình để
điều tra trạng thái tác động của chƣơng trình. Đó là kiểm thử dựa trên các ca kiểm thử
xác định bằng sự thực hiện của đối tƣợng kiểm thử hay chạy các chƣơng trình. Kiểm thử
động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý
từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm
phải thực sự đƣợc biên dịch và chạy. Kiểm thử động thực sự bao gồm làm việc với phần
mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có nhƣ mong muốn hay
không. Các phƣơng pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử
tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận
sản phẩm – Acceptance Tests…
1.4.5.3. Kiểm thử hộp đen - Black box testing
Một trong những chiến lƣợc kiểm thử quan trọng là kiểm thử hộp đen, hƣớng dữ
liệu, hay hƣớng vào/ra. Kiểm thử hộp đen xem chƣơng trình nhƣ là một “Hộp đen”. Mục
đích của bạn là hoàn toàn không quan tâm về cách cƣ xử và cấu trúc bên trong của
chƣơng trình không thực hiện theo đặc tả của nó.
Theo hƣớng tiếp cận này, dữ liệu kiểm tra đƣợc lấy chỉ từ các đặc tả.
Các phƣơng pháp kiểm thử hộp đen:
 Phân lớp tƣơng đƣơng – EQUIVALENCE PARTITIONING.

 Phân tích giá trị biên BOUNDARY VALUE ANALYSIS.
 Kiểm thử mọi cặp ALL-PAIRS TESTING .
 Kiểm thử Fuzz FUZZ TESTING .
 Kiêm thử dựa trên mô hình – MODEL-BASED TESTING .
 Ma trận dấu vết TRACEABILITY MATRIX .
 Kiểm thử thăm dò EXPLORATORY TESTING .
 Kiểm thử dựa trên đặc tả SPECIFICATION -BASE TESTING .
Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo
những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra
từ đối tƣợng kiểm thử. Mức kiểm thử viên mà khi đó có thể xác minh là đối tƣợng với
dữ liệu đầu vào đã cho, giá trị đầu ra (cách thức hoạt động) có giống với giá trị mong
muốn đã đƣợc xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần
thiết, nhƣng không đủ để ngăn chặn những rủi ro chắc chắn.
 Ƣu, nhƣợc điểm
Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất
đơn giản tâm niệm là một mã lệnh phải có lỗi, sử dụng nguyên tắc “Hãy đòi hỏi và bạn
đƣợc nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không

tìm ra. Nhƣng mặt khác, ngƣời cũng nói kiểm thử hộp đen “Giống nhƣ là đi trong bóng
tối mà không có đen vậy” Bởi vìkiểm thử viên không biết các phần mềm đƣợc kiểm tra
thực sự đƣợc xây dựng nhƣ thế nào. Đó là lí do mà có nhiều trƣờng hợp mà một kiểm
thử duy nhất, và/hoặc một số phần mềm của chƣơng trình không đƣợc kiểm tra chút nào.
Do vậy, kiểm thử hộp đen có ƣu điểm của “Một sự đánh giá khách quan”, mặt khác nó
lại có nhƣợc điểm của “Thăm dò mù”.
1.4.5.4. Kiểm thử hộp trắng – White box testing
Là một chiến lƣợc kiểm thử khác, trái ngƣợc hoàn toàn với kiểm thử hộp đen, kiểm
thử hộp trắng hay kiểm thử hƣớng logic cho phép bạn khảo sát cấu trúc bên trong của
chƣơng trình. Chiến lƣợc này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic
của chƣơng trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong
chƣơng trình (và cả mã lệnh thực hiện chúng).
 Các phƣơng pháp kiểm thử hộp trắng:
 Kiểm thử giao diện lập trình ứng dụng - API testing (application programming
interface): là phƣơng pháp kiểm thử của ứng dụng sử dụng các API công khai và
riêng tƣ.
 Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn
về bao phủ mã lệnh.
 Các phương pháp gán lỗi – Fault injection.
 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
 Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.
 Phƣơng pháp kiểm thử hộp trắng cũng có thể đƣợc sử dụng để đánh giá sự hoàn
thành của một bộ kiểm thử mà đƣợc tạo cùng với các phƣơng pháp kiểm thử hộp
đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của một hệ thống
ít khi đƣợc kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã
đƣợc kiểm tra.
1.5. Quy trình kiểm thử phần mềm
1.5.1. Các bƣớc trong một quy trình kiểm thử phần mềm
Thuật ngữ: Software Test Process là 1 chuỗi các hoạt động, phƣơng thức thực hiện
mà con ngƣời phải làm để thực hiện kiểm thử cho hệ thống phần mềm.
 Quy trình kiểm thử phần mềm bao gồm các bƣớc:
 Lập kế hoạch kiểm tra.
 Phân tích, thiết kế test case.
 Thực hiện test.
 Đánh giá kết quả test.
 Tổng kết quá trình kiểm thử.
a) Lập kế hoạch :

Nhiệm vụ quan trọng trong phần lập kế hoạch kiểm thử là xác định đƣợc các yếu tố sau:
 Các giai đoạn kiểm thử áp dụng cho dự án
 Các phƣơng pháp kiểm thử
 Các công cụ kiểm thử
 Nguồn lực kiểm thử
 Tài nguyên môi trƣờng kiểm thử, bao gồm các tài nguyên phần cứng và phần
mềm
 Mốc bàn giao các tài liệu kiểm thử
 Nhằm chỉ định và mô tả các loại kiểm tra sẽ đƣợc triển khai và thực hiện. Kết
quả của bƣớc lập kế hoạch là bản tài liệu kế hoạch KTPM bao gồm nhiều chi
tiết từ các loại kiểm tra, chiến lƣợc kiểm tra, cho đến thời gian và phân định
lực lƣợng kiểm tra viên, xác định tiêu chíkết thúc kiểm thử.
b) Phân tích và thiết kế test
Nhằm chỉ định các testcase và các bƣớc kiểm tra chi tiết cho mỗi phiên PM. Giai
đoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểm tra hết tất
cả các yêu cầu
Các bƣớc thiết kế test :
 Xác định và mô tả test case
 Mô tả các bƣớc chi tiết để kiếm tra
 Xem xét và khảo sát độ bao phủ của việc kiểm tra
 Xem xét testcase và các bƣớc kiểm tra
c) Thực hiện test
Mục đích thực hiện các bƣớc kiểm tra đã thiết kế và ghi nhận kết quả
d) Đánh giá test
Mục đích: Đánh giá toàn bộ quá trình kiểm tra bao gồm xem xét và đánh giá kết
quả kiểm tra lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan, đến quá
trình kiểm tra.
e) Tổng kết quá trình kiểm thử
Viết báo cáo tổng kết.
1.5.2. Mô hình phát triển và kiểm thử phần mềm hình chữ V

 Các tính chất cần ghi nhận trên mô hình chữ V:
Requirements Preparation
Acceptance
Preparation
Preparation Integration
Unit/Component
Specification
Hình 1-1 Mô hình phát triển và kiểm thử phần mềm hình chữ V
 Bƣớc 1: Requirements Definition (Xác định yêu cầu): Đóng vai trò xác định
yêu cầu bài toán, tính chất công việc, khi bƣớc này hoàn thành thi đƣợc đƣa
vào bƣớc kiểm thử Acceptance Test (kiểm thử chấp nhận).
 Bƣớc 2: Functional system design (Thiết kế chức năng hệ thống): Bƣớc này
đƣợc xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bƣớc mức độ cao vìthời
điểm này, nó phải cung cấp đƣợc tổng quan về giải pháp xử lý, nền tảng xây
dựng, hệ thống sản phẩm, và các dịch vụ. Sau khi bƣớc này đƣợc hoàn thành nó
chuyển sang mức System Test(kiểm thử hệ thống)
 Bƣớc 3: Technical system design (Thiết kế kỹ thuật hệ thống): Sau khi
hoàn thành bƣớc này chuyển sang mức test: Integration (tich hợp).
 Bƣớc 4: Component Specification (Đặc tả thành phần): Đây là bƣớc mức độ
thấp của thiết kế, là giai đoạn mà sản phẩm phần mềm đã đƣợc tiến hành thiết
kế thực tế, bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi
phƣơng thức, mối liên quan giữa các lớp, giai đoạn này có thể phát sinh các
mâu thuẫn, sự phùhợp hay không phùhợp….Sau khi bƣớc này đƣợc thực hiện
thành công thì đƣợc chuyển đến công đoạn test gọi là Unit/Component Test
(kiểm thử đơn vị, thành phần).
 Ƣu điểm và Nhƣợc Điểm.
 Ƣu điểm.

- Đơn giản dễ sử dụng.

- Có hoạt động, kế hoạch cụ thể cho quá trình test.
- Tiết kiệm đƣợc thời gian, và có cơ hội thành công cao hơn waterfall.
- Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bƣớc đầu.
 Nhược điểm.
- Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi
step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức
tạp và dễ hiểu, thì việc thực hiện nhiều công đoạn test nhƣ vậy là tốn thời
gian.
- Giống với waterfall, sản phẩm của dự án chỉ đƣợc xuất hiện khi tất cả các
bƣớc đƣợc hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không
đáp ứng đƣợc yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản
phẩm.
- Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bƣớc
đầu tiên, thực hiện lại, update lại tài liệu.
 Áp dụng cho những dự án nhƣ thế nào.
 Dự án có kích thƣớc nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định.
 Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn
có để đảm bảo đƣợc yêu cầu, đọc nhanh, test nhanh và coding nhanh.
 Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít
dao động) thì V model là lựa chọn cần thiết.
Các hoạt động hiện thực và các hoạt động kiểm thử đƣợc tách biệt nhƣng độ quan trọng
là nhƣ nhau. Chữ V minh họa các khía cạnh của hoạt động Verification và Validation.
Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thử trên mức
phát triển phần mềm tƣơng ứng.
Mô hình phát triển tăng tiến - tƣơng tác :
 Qui trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệ thống
phần mềm đƣợc thực hiện nhƣ 1 chuỗi các chu kỳ phát triển ngắn hơn.
 Hệ thống có đƣợc từ một bƣớc lặp đƣợc kiểm thử ở nhiều cấp trong việc phát triển
hệ thống đó.
 Kiểm thử hồi quy có độ quan trọng tăng dần theo các bƣớc lặp (không cần trong
bƣớc đầu tiên).
 Thanh kiểm tra và kiểm định có thể ₫ƣợc thực hiện theo kiểu tăng dần trên từng
bƣớc lặp.
Các tính chất của qui trình kiểm thử tốt :
 Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm.
 Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu đặc
thùcủa mình.

 Việc phân tích và thiết kế test case cho 1 mức độ kiểm thử nên bắt đầu sớm nhất
nhƣ có thể có.
 Các tester nên xem xét các tài liệu sớm nhƣ có thể có, ngay sau khi các tài liệu
này đƣợc tạo ra trong chu kỳ phát triển phần mềm.
 Số lƣợng và cƣờng độ của các mức kiểm thử đƣợc điều khiển theo các yêu cầu
đặc thùcủa project phần mềm đó.
 Sơ đồ tổ chức phổ biến của đội kiểm thử.
1.5.3. Nhân lực kiểm thử phần mềm
1.5.4. Quy trình xây dựng kế hoạch kiểm thử

Ghi chú quan trọng:
Sau khi xây dựng xong kế hoạch kiểm thử, ta có thể thay đổi nó nhƣng phải tuân
thủ quy trình yêu cầu thay đổi.
Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử:
- Định nghĩa mục đích, phạm vi, chiến lƣợc, cách tiếp cận, các điều kiện chuyển,
các rủi ro, kế hoạch giảm nhẹ và tiêu chíchấp thuận.
- Định nghĩa cách thức thiết lập môi trƣờng và các tài nguyên đƣợc dùng cho việc
kiểm thử.
- Thiết lập cơ chế theo dõi lỗi phát hiện.
- Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm.
- Báo cáo trạng thái kiểm thử.

- Phát hành leo thang (Escalating Issues).

- Raising Testing related PIR (Process Improvement Request)/ PCR (Process
Change Request).
- Các thành phần chính trong kế hoạch kiểm thử.
 Xây dựng kế hoạch kiểm thử Test Planning (Kế hoạch kiểm
Gồm có 4 bƣớc sau: thử)
Bƣớc 1: Kế hoạch Kiểm thử.

Test Analysis – Design (Phân
Bƣớc 2: Phân tích & thiết kế kiểm thử. tích & thiết kế kiểm thử)
Bƣớc 3: Thi hành kiểm thử.
Bƣớc 4: Báo cáo kiểm thử.

Test Executing (Thi hành kiểm
thử)
Test Report – Evaluation
(Báo cáo kiểm thử)
Hình 1-3 Xây dựng kế hoạch kiểm thử
Bƣớc 1
 Kế hoạch kiểm thử: Test Planning

Test Manager (Ngƣời quản lí kiểm thử) hoặc Test Leader (Quản lí nhóm kiểm thử sẽ
xây dựng kế hoạch ban đầu về kiểm thử.
- Định nghĩa phạm vi kiểm thử.

- Định nghĩa các chiến lƣợc kiểm thử.
- Nhận dạng các rủi ro và yếu tố bất ngờ.
- Nhận dạng các hoạt động kiểm thử nào là thủ công, kiểm thử nào là tự động hay
cả hai.
- Ƣớc lƣợng chi phíkiểm thử và xây dựng lịch kiểm thử.
- Nhận dạng môi trƣờng kiểm thử.
Kế hoạch kiểm thử cần đƣợc:

- Xem lại bởi QC team (đội kiểm tra chất lƣợng), Developers (lập trình viên),
Business Analysis (Phân tích Kinh doanh), TA (if need), PM (quản lí dự án) and
Customer (khách hàng).
- Chấp thuận bởi: Project Manager (Quản lídự án) and Customer (khách hàng).
- Hiệu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết.
Nhiệm vụ của Test Plan (Kế hoạch kiểm thử):
- Xác định phạm vi kiểm thử, các rủi ro, mục tiêu.
- Xác định cách tiếp cận (đối tƣợng kiểm thử, độ bao phủ, số ngƣời tham gia, các
tài liệu liên quan).
- Thực thi chính sách, chiến lƣợc kiểm thử.
- Xác định nguồn lực tham gia kiểm thử (con ngƣời, phần cứng, phần mềm, thiết
bị, công cụ hỗ trợ).
- Lên kế hoạch phân tích, thiết kế, thực thi, đánh giá.
- Xác định tiêu chíkết thúc kiểm thử.
Bƣớc 2
 Phân tích & thiết kế kiểm thử (Test Analysis – Design )

Test Analyst (Phân tích kiểm thử) hoặc Test Designer (Thiết kế kiểm thử) sẽ thiết kế
(định nghĩa) các testcase từ các yêu cầu liên quan (thídụ từ thông tin trong usecase)
- Sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu chức năng và các yêu cầu
không chức năng của phần mềm.
- Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu phần mềm.
- Các testcase cần bao phủ tất cả yêu cầu trong các chiến lƣợc kiểm thử.
- Nếu cần kiểm thử tự động, Test Designer (Nhân viên thiết kế kiểm thử) sẽ xây
dựng các kịch bản dựa trên các testcase/Test procedures.
Các testcase cần đƣợc:
- Xem xét lại bởi Project Leader (Quản lí dự án), Developer (Lập trình viên) có
liên quan, các Testers (nhân viên kiểm thử) khác, Test Leader (Quản lí nhóm
test), Business Analysis và Customer (Khách hàng).
- Chấp thuận bởi Test Leader (quản línhóm test) hoặc Customer (Khách hàng).
- Hiệu chỉnh/cập nhật nếu Tester đã tìm đƣợc những lỗi mà không nằm trong các
testcase hiện có.
Bƣớc 3
 Thi hành kiểm thử (Test Executing)

- Tester sẽ đƣợc bố trí công việc bởi Test Leader (Quản lí nhóm kiểm thử) để thi
hành kiểm thử.

-
Thi hành kiểm thử theo từng testcase.
Thực hiện kiểm thử đặc biệt .
-
Thực hiện kịch bản kiểm thử mà không đƣợc định nghĩa trong testcase.
-
Kiểm thử lại các lỗi đã đƣợc sửa.
-
-
Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng
cho đến khi chúng đã đƣợc xử lý.
- Ở công đoạn kiểm thử độ chấp thuận, Customer sẽ thi hành kiểm thử để kiểm
định xem hệ thống phần mềm có thỏa mãn các nhu cầu ngƣời dùng không .
Bƣớc 4
 Báo cáo kiểm thử (Test Report and Evaluation)

Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống theo dõi các lỗi.
- Tạo các báo cáo lỗi.

- Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi.
- Tính và phân phối các thông tin đo lƣờng hoạt động kiểm thử.
- Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi.
- Xác định xem đã đạt tiêu chí thành công và để hoàn thành kiểm thử chƣa.
Nhiệm vụ
- Kiểm tra sản phẩm thực tế so với kế hoạch.

- Đó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ở.
- Viết biên bản chấp nhận phần mềm.
- Lƣu lại các sản phẩm kiểm thử, môi trƣờng kiểm thử, cơ sở hạ tầng để sử dụng lần
sau (Đặc biệt kiểm thử bảo trì).
- Phân tích các bài học.
- Sử dụng tài liệu thu thập đƣợc để sử dụng định kì.
1.6. Các cấp độ kiểm thử phần mềm.

Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm
thử hệ thống và Kiểm thử chấp nhận sản phẩm.
Các kỹ thuật đƣợc dùng cho mỗi kiểu kiểm thử trong project:
 Kiểm thử tích hợp (Integration Testing).

 Kiểm thử hệ thống (System Testing).
 Kiểm thử độ chấp thuận (Acceptance Testing).
 Kiểm thử chức năng của ngƣời dùng (Functionality Testing).
 Kiểm thử hồi qui (Regression Testing).

 Kiểm thử việc phục hồi sau lỗi (Failover and Recovery Testing).
 Kiểm thử việc kiểm soát an ninh và truy xuất (Security and Access Control
Testing).
 Kiểm thử việc cấu hình và cài đặt (Configuration and Installation Testing).
 Kiểm thử đặc biệt (Ad-hoc Testing).
 Kiểm thử hiệu suất (Performance Testing).
Hình 1-4. Sơ đồ các cấp độ kiểm thử.
1 .6.1. Kiểm thử đơn vị – Unit test

Kiểm thử đơn vị hỗ trợ tìm lỗi nhanh hơn, giúp thiết kế tốt hơn, giảm chi phí. Kiểm
thử đơn vị đƣợc chia ra làm 4 loại chính:
- Kiểm thử câu lệnh

- Kiểm thử rẽ nhánh
- Kiểm thử điều kiện
- Kiểm thử đƣờng đi
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử đƣợc. Ví
dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phƣơng thức (Method) đều
có thể đƣợc xem là Unit.
Vì Unit đƣợc chọn để kiểm tra thƣờng có kích thƣớc nhỏ và chức năng hoạt động
đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích

kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng
tƣơng đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một
nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ đƣợc đền bùbằng việc tiết
kiệm rất nhiều thời gian và chi phícho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau
đó.
Unit Test thƣờng do lập trình viên thực hiện. Công đoạn này cần đƣợc thực hiện
càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.
Thông thƣờng, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của
chƣơng trình. Mục đích của Unit Test là bảo đảm thông tin đƣợc xử lý và xuất (khỏi
Unit) là chính xác, trong mối tƣơng quan với dữ liệu nhập và chức năng của Unit. Điều
này thƣờng đòi hỏi tất cả các nhánh bên trong Unit đều phải đƣợc kiểm tra để phát hiện
nhánh phát sinh lỗi. Một nhánh thƣờng là một chuỗi các lệnh đƣợc thực thi trong một
Unit.Vídụ: chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh. Thực
tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết Unit đòi hỏi phải
có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.
Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trƣớc các
ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu
đầu vào, các bƣớc thực hiện và dữ liệu đầu ra mong muốn. Các Test case và Test script
này nên đƣợc giữ lại để tái sử dụng.
1.6.2. Kiểm thử tích hợp – Intergration Test

Kiểm thử tích hợp đảm bảo tích hợp các chức năng, các module tuân theo thiết
kế của sản phẩm, đảm bảo giao tiếp, liên kết giữa các chức năng module hoạt động
đƣợc, đúng theo yêu cầu.
Integration test kết hợp các thành phần của một ứng dụng và kiểm thử nhƣ một
ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ
thìIntgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
Hai mục tiêu chính của Integration Test:
- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là
nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống
(System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và
cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với
các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự

đƣợc kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration
Test.
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã đƣợc
kiểm tra cẩn thận trƣớc đó bằng Unit Test, và tất cả các lỗi mức Unit đã đƣợc sửa chữa.
Một số ngƣời hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả
lập thìkhông cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các
Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lƣợc cần quan tâm trong Integration Test là nên tích hợp dần từng
Unit. Một Unit tại một thời điểm đƣợc tích hợp vào một nhóm các Unit khác đã tích hợp
trƣớc đó và đã hoàn tất các đợt Integration Test trƣớc đó. Lúc này, ta chỉ cần kiểm thử
giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trƣớc đó, điều này sẽ
làm cho số lƣợng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.
Có 4 loại kiểm thử trong Integration Test:
- Kiểm thử cấu trúc (Structure Test): Tƣơng tự White Box Test, kiểm thử cấu
trúc nhằm bảo đảm các thành phần bên trong của một chƣơng trình chạy đúng
và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chƣơng
trình chẳng hạn các câu lệnh và nhánh bên trong.
- Kiểm thử chức năng (Functional Test): Tƣơng tự Black Box Test, kiểm thử
chức năng chỉ chú trọng đến chức năng của chƣơng trình, mà không quan tâm
đến cấu trúc bên trong, chỉ khảo sát chức năng của chƣơng trình theo yêu cầu
kỹ thuật.
- Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ
thống.
- Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.
1.6.3. Kiểm thử hệ thống – System Test

a. Mục đích của Kiểm thử hệ thống
+ Nhằm đảm bảo chức năng, các đặc tính của sản phẩm được đúng và đủ của
sản phẩm phầm mềm đó.
+ Môi trường thực hiện gần giống với môi trường người dùng cuối.
Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có
thỏa mãn yêu cầu đặt ra hay không.
System Test bắt đầu khi tất cả các bộ phận của phần mềm đã đƣợc tích hợp thành
công. Thông thƣờng loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều
trƣờng hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc

thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở
mức độ hệ thống, ngƣời kiểm thử cũ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.
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú
trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp
giữa các đơn thể hoặc đối tƣợng khi chúng làm việc cùng nhau. Thông thƣờng ta phải
thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tƣơng tác giữa chúng
hoạt động chính xác trƣớc khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã đƣợc hình thành
cùng với các thành phần đã đƣợc kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc
kiểm thử viên bắt đầu kiểm thử phần mềm nhƣ một hệ thống hoàn chỉnh. Việc lập kế
hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu.
System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về
chất lƣợng nhƣ độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. 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ớ. Sau giai
đoạn System Test, phần mềm thƣờng đã sẵn sàng cho khách hàng hoặc ngƣời dùng cuối
cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thƣờng
đƣợc thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự
án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm:
Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn
đúng yêu cầu thiết kế.
Việc kiểm thử chức năng chú trọng đến 2 phần chính là kiểm thử giao diện ngƣời dùng
(User interface) và kiểm thử luồng nghiệp vụ (Bussiness Flow Testing).
b) Kiểm thử giao diện người sử dụng
Kiểm thử giao diện ngƣời sử dụng gọi tắt kiểm thử giao diện là việc kiểm tra các
tƣơng tác của ngƣời dùng với phần mềm. Mục tiêu của kiểm thử giao diện là để đảm bảo
rằng giao diện ngƣời dùng cung cấp cho ngƣời sử dụng cách truy cập và sử dụng các
chức năng của hệ thống một cách thích hợp. Ngoài ra, kiểm thử giao diện còn để đảm
bảo rằng các đối tƣợng trên giao diện giống nhƣ thiết kế và phù hợp với tổ chức hoặc
chuyên ngành.

Bảng 1-1. Kiểm thử giao diện ngƣời sử dụng
Mục đích kiểm thử Kiểm tra:

Việc sử dụng thông qua mục tiêu kiểm thử phản ánh
đúng các chức năng và yêu cầu nghiệp vụ, bao gồm
màn hình đến màn hình, trƣờng đến trƣờng và sử
dụng các phƣơng pháp truy cập (phím tabs, di chuột,
tổ hợp phím).
Các đối tƣợng và thuộc tính màn hình nhƣ menus,
size, posittion, state.
Cách thức thực hiện Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn
hình để kiểm tra việc sử dụng đúng cách và tình
trạng các đối tƣợng cho mỗi màn hình và đối tƣợng
của ứng dụng.
Điều kiện hoàn thành Mỗi màn hình đƣợc kiểm tra thành công đúng phiên
các vấn đề bản kiểm tra hoặc phạm vi chấp nhận đƣợc
Không phải toàn bộ các thuộc tính của các đối tƣợng
đều có thể chấp nhận đƣợc.
- Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ƣu việc phân bổ tài nguyên
hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng
câu truy vấn...
- Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận
hành đúng dƣới áp lực cao (vídụ nhiều ngƣời truy xuất cùng lúc). Stress Test tập
trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thƣờng nhƣ
đang giao dịch thìngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị nhƣ POS,
ATM...)...
- Kiểm thử cấu hình (Configuration Test).
- Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và
của hệ thống.
- Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng
khôi phục trạng thái ổn định trƣớc đó trong tình huống mất tài nguyên hoặc dữ
liệu; đặc biệt quan trọng đối với các hệ thống giao dịch nhƣ ngân hàng trực
tuyến...
Nhìn từ quan điểm ngƣời dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo
đảm hệ thống đủ khả năng làm việc trong môi trƣờng thực.

Lƣu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu
cầu và đặc trƣng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi
lập kế hoạch, ngƣời Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.
1.6.4. Kiểm thử chấp nhận sản phẩm – Acceptance Test

Thông thƣờng, sau giai đoạn System Test là Acceptance Test, đƣợc khách hàng
thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance
Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng
chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trƣờng
hợp, các phép kiểm thử của System Test và Acceptance Test gần nhƣ tƣơng tự, nhƣng
bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trƣờng cho nhiều ngƣời sử dụng,
thông thƣờng sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm
thử Beta – Beta Test. Với Alpha Test, ngƣời dùng kiểm thử phần mềm ngay tại nơi phát
triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa
chữa. Với Beta Test, phần mềm sẽ đƣợc gửi tới cho ngƣời dùng để kiểm thử ngay trong
môi trƣờng thực, lỗi hoặc phản hồi cũng sẽ gửi ngƣợc lại cho lập trình viên để sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình
phát triển phần mềm thìkết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm
đã trải qua tất cả các kiểm thử trƣớc đó. Sự sai lệch này liên quan đến việc hiểu sai yêu
cầu cũng nhƣ sự mong chờ của khách hàng. Vídụ đôi khi một phần mềm xuất sắc vƣợt
qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhƣng khách
hàng khi kiểm thử sau cùng vẫn thất vọng vìbố cục màn hình nghèo nàn, thao tác không
tự nhiên, không theo tập quán sử dụng của khách hàng v.v...
Kết luận
Kiểm thử phần mềm là một ngành mới, có rất nhiều những quan điểm, khái niệm về
kiểm thử đã đƣợc đƣa ra. Việc xác định và nắm chắc nội dung cơ bản về kiểm thử là nền
tảng để tìm hiểu và có những hƣớng phát triển rộng hơn, sâu hơn. Chƣơng 1 đã giới
thiệu những kiến thức cơ bản nhất về kiểm thử phần mềm, xác định đƣợc tầm quan
trọng và đƣa ra những mặt còn hạn chế của việc kiểm thử.
1.6.5. Một số cấp độ kiểm thử khác

Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác nhƣ:
- Kiểm thử hồi quy – Regression Testing

- Kiểm thử tính đúng – Correctness testing

- Các phương pháp kiểm thử con người
1.7. Nguyên tắc kiểm thử phần mềm

Để kiểm thử đạt hiệu quả thìkhi tiến hành kiểm thử phần mềm cần phải tuân thủ
một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của một ca kiểm thử là định nghĩa của đầu ra hay kết
quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chƣơng trình của mình.
Quy tắc 3: Nhóm lập trình không nên kiểm thử chƣơng trình của chính họ.
Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.
Quy tắc 5: Các ca kiểm thử phải đƣợc viết cho các trạng thái đầu vào không hợp lệ và
không mong muốn, cũng nhƣ cho các đầu vào hợp lệ và mong muốn.
Quy tắc 6: Khảo sát một chƣơng trình để xem liệu chƣơng trình có thực hiện cái mà nó
cần thực hiện chỉ là một phần, phần còn lại là xem liệu chƣơng trình có thực hiện cái mà
nó không cần phải thực hiện hay không.
Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chƣơng trình thực sự là một chƣơng
trình bâng quơ.
Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy
lỗi.
Quy tắc 9: Xác suất tồn tại lỗi trong một đoạn chƣơng trình là tƣơng ứng với số lỗi đã
tìm thấy trong đoạn đó.
Quy tắc 10: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách trítuệ.

CHƢƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN

2.1 Giới thiệu
Kiểm thử hộp đen là một kỹ thuật kiểm thử động nổi bật nhất, quan trọng và cần
thiết nhất. Kỹ thuật này thích hợp cho mọi mức độ kiểm thử từ kiểm thử đơn vị, kiểm
thử tích hợp, kiểm thử hệ thống, hay kiểm thử độ chấp nhận của ngƣời dùng. Đây là
chiến lƣợc kiểm thử theo góc nhìn từ ngoài vào, ngƣời tham gia kiểm thử khi dùng kỹ
thuật này không cần có kiến thức về mã nguồn hay giải thuật đƣợc dùng. Có nhiều kỹ
thuật kiểm thử hộp đen đã và đang đƣợc phát triển, công nhận mang lại hiệu quả cho
việc kiểm thử, chƣơng 2 sẽ trình bày 8 kỹ thuật cơ bản, bao gồm: Kỹ thuật phân lớp
tƣơng đƣơng, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật
kiểm thử n bộ, kỹ thuật dùng lƣợc đồ trạng thái, kỹ thuật dùng use case, kỹ thuật dùng
đồ thị nhân quả và kỹ thuật đoán lỗi. Đây là 8 kỹ thuật luôn luôn đƣợc sử dụng trong
suốt quá trình kiểm thử phần mềm.
2.2 Quy trình kiểm thử hộp đen tổng quát
Hình 2-1. Quy trình kiểm thử hộp đen tổng quát
Testcase (trƣờng hợp kiểm thử) là một tập hợp các giá trị nhập, các điều kiện tiên
quyết thực thi, các kết quả mong đợi và các điều kiện kết thúc, đƣợc xây dựng cho mục
đích hoặc điều kiện kiểm thử riêng biệt, nhƣ thực hiện một đƣờng dẫn chƣơng trình
riêng hoặc để kiểm tra lại có đúng với một yêu cầu cụ thể hay không. (Trích “Hƣớng
dẫn phƣơng pháp xác định chi phíkiểm thử chất lƣợng phần mềm”
Kèm theo Công văn số 3787 /BTTT-THH ngày 26/12/2014 của Bộ Thông tin và Truyền
thông) testcase mô tả một dữ liệu gồm:

- Đầu vào (input)

- Hành động (action)
- Sự kiện (event)
- Một kết quả mong đợi (expected result)
Để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.
Một testcase có thể có các phần đặc thù khác nhau nhƣ mã testcase, tên testcase, các
bƣớc thực hiện, mục tiêu kiểm thử, các điều kiện kiểm thử, các yêu cầu dữ liệu vào và
các kết quả mong đợi. Mức chi tiết có thể đƣợc định nghĩa khác nhau dựa vào ngữ cảnh
của dự án và quy mô của công ty sản xuất phần mềm.
Một testcase đƣợc cho là hiệu quả:
- Testcase hiệu quả là testcase mà tìm thấy bug.

- Tìm đƣợc nhiều bug khó.
- Chỉ ra những điểm ban đầu mà khi thực hiện test không tìm ra vấn đề.
- Tuân theo đúng các con số thống kê bug.
- Theo dõi các lỗi theo các trƣờng hợp đã đƣợc tìm thấy.
- Đáp ứng đƣợc các kỹ thuật kiểm thử.
Vì chiến lƣợc kiểm thử hộp đen thích hợp cho mọi mức độ kiểm thử nên nhiều
ngƣời đã nghiên cứu tìm hiểu và đƣa ra nhiều kỹ thuật kiểm thử khác nhau. Nắm vững
các kỹ thuật cơ bản là yêu cầu tiên quyết của một ngƣời thực hiện công việc kiểm thử
phần mềm.
2.3. Equivalence Partitioning – Kỹ thuật phân lớp tƣơng đƣơng

Tinh thần của kỹ thuật này là cố gắng phân các testcase ra thành nhiều nhóm khác
nhau. Các test case trong mỗi nhóm sẽ kích hoạt thành phần phần mềm thực hiện cùng
một hành vi. Mỗi nhóm testcase thỏa mãn tiêu chuẩn trên đƣợc gọi là một lớp tƣơng
đƣơng.
Chỉ cần xác định một testcase đại diện cho nhóm và dùng testcase này để kiểm thử,
từ đó giảm đƣợc rất nhiều testcase cần định nghĩa và kiểm thử nhƣng chất lƣợng kiểm
thử không bị giảm sút. Điều này dựa vào các kỳ vọng sau:
- Nếu một testcase trong lớp tƣơng đƣơng nào đó gây lỗi thìcác testcase trong lớp
này cũng sẽ gây lỗi nhƣ vậy.
- Nếu một testcase trong lớp tƣơng đƣơng nào đó không gây lỗi thìcác testcase
trong lớp này cũng sẽ không gây lỗi.

Việc xác định các lớp tƣơng đƣơng đầu vào cần:
- Dựa vào các điều kiện vào/ra trong đặc tính kỹ thuật/mô tả kỹ thuật.
- Định nghĩa các lớp tƣơng đƣơng đại diện các testcase chứa các giá trị đầu vào
hợp lệ (valid) và không hợp lệ (invalid).
- Dựa vào chuẩn đoán (heuristics) và chuyên gia.
Xét bài toán kiểm thử chức năng đăng nhập vào phần mềm Thi đua khen thƣởng với
yêu cầu “tên đăng nhập” là ô text chỉ cho phép ngƣời dùng nhập vào số ký tự từ 6-20.
Hình 2-2. Giao diện đăng nhập hệ thống
Á p dụng kỹ thuật phân lớp tƣơng đƣơng, dữ liệu cho “tên đăng nhập” sẽ đƣợc phân
thành 3 lớp:
- Nhập vào số ký tự thuộc khoảng [6-20] ký tự

- Nhập vào số ký tự < 6
- Nhập vào số ký tự >20
- Nhập vào ký tự không phải là chữ và để trống không nhập gì
 Có 4 test case
ết kế test case kiểm thử cho yêu cầu trên:
Test case 1: Nhập giá trị từ 6 → 20 ký tự => pass.
Test case 2: Nhập giá trị < 6 ký tự => hiển thị lỗi “Bạn chỉ đƣợc phép nhập chuỗi từ 6
=> 20 ký tự”.
Test case 3: Nhập giá trị > 20 ký tự => hiển thị lỗi “Bạn chỉ đƣợc phép nhập chuỗi từ 6
=> 20 ký tự”.

Test case 4: Để trống không nhập gì=> hiển thị lỗi “Chƣa điền tên đăng nhập”.
2. 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên

Không phải bài toán nào cũng đều có thể áp dụng kỹ thuật phân lớp tƣơng đƣơng,
bởi có thể bị thiếu lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tƣơng đƣơng.
Kinh nghiệm trong cuộc sống đời thƣờng cũng nhƣ trong lập trình các giải thuật lặp cho
chúng ta biết rằng lỗi thƣờng nằm ở biên của một khoảng liên tục nào đó.
Kiểm thử giá trị biên là một trong những kỹ thuật đƣợc áp dụng phổ biến nhất trong
kiểm thử hộp đen. Chúng ta sẽ coi một chƣơng trình là một hàm toán học với đầu vào
của chƣơng trình tƣơng ứng với các tham số của hàm và đầu ra của chƣơng trình là giá
trị trả về của hàm. Vìhàm toán học là ánh xạ từ miền xác định của hàm đến miền giá trị
của hàm. Chúng ta sẽ tập trung vào các giá trị biên và cạnh biên của hai miền đầu vào và
đầu ra này của hàm để xây dựng các ca kiểm thử. Khi chúng ta dùng biên đầu ra tức là
chúng ta cho các kết quả mong đợi nằm ở trên biên và cạnh biên đầu ra bao gồm: [biên
nhỏ, biên lớn, biên nhỏ -1, biên lớn + 1].
Á p dụng cho bài toán đăng nhập vào phần mềm Thi đua khen thƣởng (Mục 2.3), số
ký tự cho kiểm tra “tên đăng nhập” thỏa mãn từ 6 đến 20 ký tự. Ta sẽ có các trƣờng hợp
kiểm thử giá trị biên sau:
- Tên đăng nhập = 6 ký tự => Pass
- Tên đăng nhập = 20 ký tự => Pass
- Tên đăng nhập = 5 ký tự => Fail
- Tên đăng nhập = 21 ký tự => Fail
2.5. Decision Tables – Kỹ thuật sử dụng bảng quyết định
Kỹ thuật kiểm thử phân lớp tƣơng đƣơng và kiểm thử dựa vào phân tích giá trị biên
thích hợp cho các hàm có các biến đầu vào không có quan hệ ràng buộc với nhau. Kỹ
thuật kiểm thử sử dụng bảng quyết định phù hợp cho các thành phần phần mềm có các
hành vi khác nhau dựa trên tính chất của bộ giá trị đầu vào.
Kiểm thử sử dụng bảng quyết định là phƣơng pháp chính xác nhất trong các kỹ thuật
kiểm thử chức năng. Bảng quyết định là phƣơng pháp hiệu quả để mô tả các sự kiện,
hành vi sẽ xảy ra khi một số điều kiện thỏa mãn.
Là công cụ rất hữu ích để đặc tả các yêu cầu phần mềm / bảng thiết kế hệ thống phần
mềm. Miêu tả các quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dƣới dạng
dễ đọc và dễ kiểm soát. Cấu trúc của một bảng điều kiện có dạng:

Hình 2-3. Cấu trúc bảng quyết định
- Trong đó:
- Condition 1 tới condition n miêu tả điều kiện dữ liệu nhập khác nhau có thể có.
- Rule mô tả giá trị điều kiện nhập: T (true) / F (false), Y (yes) / N (no)...
- Action 1 tới action n miêu tả n hoạt động khác nhau mà hệ thống có thể thực hiện
phụ thuộc vào tổ hợp điều kiện dữ liệu nhập vào. Mỗi cột miêu tả một luật cụ thể:
tổ hợp điều kiện nhập cụ thể và các hoạt động cụ thể cần thực hiện.Các hoạt động
cần thực hiện không phụ thuộc vào thứ tự các điều kiện nhập, nó chỉ phụ thuộc
vào giá trị các điều kiện nhập.Để xác định các ca kiểm thử dựa vào bảng quyết
định, ta dịch các điều kiện thành các đầu vào và các hành động thành các đầu ra.
Đôi khi các điều kiện sẽ đƣợc xác định các lớp tƣơng đƣơng của đầu vào và các
hành động tƣơng ứng ở các mô- đun xử lý chức năng đang kiểm thử.
Vídụ: Á p dụng kỹ thuật sử dụng bảng quyết định để xây dựng các trƣờng hợp kiểm thử
cho bài toán với đề là:
Nếu bạn có thẻ đƣờng sắt over 60s thì đƣợc giảm giá 34% trên tất cả các vé bạn
mua.Nếu bạn đi cùng trẻ em (dƣới 16 tuổi), thìbạn sẽ đƣợc giảm 50% nến bạn có thẻ
family rail card, ngƣợc lại bạn sẽ đƣợc giảm 15%. Bản chỉ đƣợc sử dụng một loại thẻ
đƣờng sắt.

Bảng 2-1. Bảng quyết định bài toán kiểm tra thẻ đƣờng sắt
Điều kiện 1 2 3 4 5 6 7 8
Có thẻ over 60s y y y y n n n n
Đi cùng trẻ em
dƣới 16t y y n n y y n n
Có thẻ family rail
card y n y n y n y n
Kết
quả
Giảm 34% x x x
Giảm 50% x x
Giảm 15% x
Không đƣợc giảm x x
Bảng sau khi gộp
Điều kiện 1 2 3 4 5 6
Có thẻ over 60s y y y n n
Đi cùng trẻ em dƣới
16t y y n n y n
Có thẻ family rail card y n - y -
Kết
quả
Giảm 34% x x x
Giảm 50% x x
Giảm 15% x
Không đƣợc giảm
Trên thực tế không phải tổ hợp đầu vào nào cũng là hợp lệ, do đó khi sử dụng
bảng quyết định thƣờng ta phải bổ sung thêm một giá trị đặc biệt “-” (không quan tâm)
có thể hiểu là luôn sai, không hợp lệ để đánh dấu các điều kiện không thể cùng xảy ra
này. Nếu các điều kiện chỉ là T/F hay Y/N ta có 2n cột quy tắc. Mỗi giá trị “-” sẽ đại
diện cho 2 cột. Khi tổng số cột ứng với giá trị “-” bằng 2n cho ta biết số quy tắc đã đủ.

Kết quả kiểm tra số rule bài toán kiểm tra tam giác thể hiện ở dòng Rules.
 Từ bảng quyết định, tiến hành xây dựng 6 trƣờng hợp kiểm thử cho bài toán:
o TH1: Có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => Đƣợc
giảm 50%
o TH2: Có thẻ Over 60s và không có thẻ Family Raul Card và đi cùng trẻ em =>
đƣợc giảm 34%
o TH3: Có thẻ Over 60s và không đi cùng trẻ em => đƣợc giảm 34%
o TH4: Không có thẻ Over 60s và có thẻ Family Raid Card và đi cùng trẻ em
=>đƣợc giảm50%
o TH5: Không có thẻ Over 60s và không có thẻ Family Raid Card và đi cùng trẻ
em =>đƣợc giảm 15%
o TH6: Không có thẻ Over 60s và không đi cùng trẻ em => không đƣợc giảm.
2.6 Pairwise Testing – Kỹ thuật kiểm thử các bộ n thần kỳ

Trong kiểm thử chất lƣợng phần mềm, giả thuyết thông thƣờng là kiểm tra càng
nhiều càng tốt, và thử nghiệm các trạng thái của một biến, cũng nhƣ kiểm tra tất cả các
khả năng có thể kết hợp đƣợc của các biến với các trạng thái khác nhau, đảm bảo là tìm
thấy tất cả các lỗi. Tuy nhiên, trong thực tế chúng ta sẽ không có đủ thời gian để có thể
kiểm tra đƣợc tất mọi trƣờng hợp trên. Hơn nữa khi kiểm thử một phần mềm, không bao
giờ chúng ta có thể tìm ra đƣợc tất cả các lỗi của nó, chúng ta chỉ có thể cố gắng tìm ra
đƣợc nhiều nhất những lỗi có thể xảy ra trong những điều kiện đƣợc cho phép về thời
gian và chi phí.
Vídụ chúng ta cần kiểm thử một Form có 10 đối tƣợng và mỗi đối tƣợng đó có thể
nhận giá trị trong bộ 10 giá trị khác nhau. Vậy nếu để test toàn diện hết các trƣờng hợp
thìchúng ta sẽ cần phải test (1010) = 10 tỷ tổ hợp khác nhau. Trong trƣờng hợp này,
việc kiểm tra toàn diện nhƣ vậy là không thể thực hiện đƣợc.Câu hỏi đặt ra là vậy làm
thế nào để chúng ta có thể xác nhận rằng sản phẩm của mình đã đƣợc đảm bảo chất
lƣợng và sẵn sàng để bàn giao cho khách hàng mà không cần phải thực hiện kiểm tra tất
cả mọi tổ hợp test case nhƣ trên? Làm thế nào để đảm bảo đƣợc chất lƣợng của sản
phẩm trong điều kiện thời gian và chi phícho sản phẩm bị giới hạn?
Xét bài toán kiểm thử có một trang Web có các đối tƣợng cần kiểm tra với các giá trị
tƣơng ứng sau:
+ List Box: 0;1;2;3;4;5;6;7;8;9 = 10 giá trị.

+ Check Box: Checked hoặc Unchecked = 2 giá trị
+ Radio Button: On hoặc Off = 2 giá trị,
+ Text Box: Bất kỳ giá trị nào từ 1 đến 100= 100 giá trị.

=>Nếu kiểm tra đủ các trƣờng hợp thìchúng ta sẽ có 10*2*2*100 = 4000 test cases cần
phải tạo và thực hiện test. Thời gian để hoàn thành việc kiểm tra đầy đủ nhƣ vậy là rất
lớn.
Vậy làm thế nào để chúng ta có thể xác nhận rằng sản phẩm của mình đã đƣợc đảm
bảo chất lƣợng và sẵn sàng để bàn giao cho khách hàng mà không cần phải thực hiện
kiểm tra tất cả mọi tổ hợp test case nhƣ trên? Làm thế nào để đảm bảo đƣợc chất lƣợng
của sản phẩm trong điều kiện thời gian và chi phícho sản phẩm bị giới hạn?
Ta có thể đặt ra nhiều chiến lƣợc kiểm thử khác nhau cho bài toán:
1. Không kiểm thử bộ n nào cả (vìáp lực số lƣợng quá lớn).

2. Kiểm thử tất cả bộ n, nhƣ vậy sẽ phải delay dự án quá lâu và làm mất thị trƣờng.
3. Kiểm thử một hay hai bộ n và hi vọng là đủ.
4. Chọn các bộ n đã kiểm thử rồi cho project khác.
5. Chọn các bộ n dễ dàng tạo ra và kiểm thử nhất, mà không để ý đến chất lƣợng
của chúng ra sao
6. Tạo tất cả bộ n và chọn một ít bộ n đầu tiên trong danh sách.
7. Tạo tất cả bộ n và chọn 1 ít bộ n theo cơ chế ngẫu nhiên
8. Chọn 1 tập con đủ nhỏ bộ n mà tạo đƣợc điều kỳ diệu là chất lƣợng kiểm thử
không bị giảm sút. Bằng cách nào nếu có?
Một giải pháp đó là sử dụng các phƣơng pháp test, cùng với các công cụ hỗ trợ để
giúp chúng ta có thể tối ƣu hóa việc kiểm tra chất lƣợng sản phẩm với số lƣợng testcase
là ít nhất. Và một trong các phƣơng pháp giảm thiểu số testcase mà vẫn đảm bảo đƣợc
chất lƣợng của sản phẩm là sử dụng Pairwise testing. Pairwise testing (hay còn gọi là
All-pairs testing) là một phƣơng pháp test kết hợp mỗi cặp 2 tham số đầu vào của 1 bộ
các đối tƣợng có liên quan đến nhau, tạo ra bộ giá trị kiểm thử: Ta sẽ kiểm tra tất cả các
khả năng có thể kết hợp các giá trị của cặp 2 tham số đó với nhau. Thực hiện kiểm tra
theo cặp nhƣ vậy sẽ giúp làm giảm thời gian hơn rất nhiều so với việc phải kiểm tra đầy
đủ mọi khả năng kết hợp của tất cả các giá trị của bộ nhiều các thông số với nhau. Số
testcase phát triển từ kỹ thuật này đƣợc tính bằng tích của số lƣợng giá trị lớn nhất của
các biến số và số lƣợng vùng giá trị lớn thứ 2 trong số các biến.Tiến hành phân tích và
xây dựng test case cho bài toán trên qua các bƣớc:
Bước 1: Sử dụng các kỹ thuật kiểm thử thông thƣờng để chia các vùng cần kiểm tra cho
từng biến:
1. List Box: 0,1,2,3,4,5,6,7,8,9 - chia thành 2 vùng kiểm tra: "0" và các giá trị khác
("others")
2. Check Box: Checked hoặc Unchecked - giữ nguyên 2 giá trị

3. Radio Button: ON hoặc OFF - giữ nguyên 2 giá trị

4. Text Box: Bất kỳ value nào từ 1 đến 100 - kiểm tra 3 vùng giá trị: số nguyên nằm
trong khoảng 1 đến 100, số nguyên ngoài khoảng, ký tự không phải dạng số
nguyên (Valid Integer, Invalid Integer, Alpha-Special Character)
Nhƣ vậy số test case giảm xuống còn 2*2*2*3 = 24 test case.
Bước 2: Ứng dụng kỹ thuật Pairwise testing để làm giảm sự kết hợp các vùng kiểm tra
với nhau theo cách sau:
Xác định số testcase = 3*2 = 6 testcase và thực hiện:
1) Sắp xếp các biến theo thứ tự giảm dần số lƣợng vùng giá trị: biến có nhiều
vùng giá trị nhất sắp xếp đầu tiên. Biến có số lƣợng vùng giá trị ít nhất để ở
cuối cùng. =>tạo thành 1 bảng có các cột tƣơng ứng với các biến.
Text Box List Box Check Box Radio Button
2) Điền các vùng giá trị tƣơng ứng vào bảng lần lƣợt theo các cột. Bắt đầu từ cột
thứ 2: "List Box". Cột này có thể lấy 2 giá trị là "0" hoặc "others".
0
others
0
others
0
others
3) Điền vùng giá trị cho cột tiếp theo: "Check box": có thể nhận đƣợc 2 giá trị:
"check" và "uncheck" đồng thời kiểm tra để đảm bảo rằng chúng ta đã cover
đƣợc hết các trƣờng hợp kết hợp các vùng giá trị của "List box" và "Check
box".
0 check
others uncheck
0 uncheck
others check

0 check
others uncheck
4) Tiếp tục điền giá trị cho cột "Radio button" theo cách tƣơng tự nhƣ trên.
"Radio button" có thể lấy 2 giá trị: "on" hoặc "off".
0 check on
others uncheck off
0 uncheck off
others check on
0 check off
others uncheck on
5) Kiểm tra nhằm đảm bảo rằng tất cả các cặp giá trị đều đƣợc cover nhƣ trong
bảng kết quả sau:
Valid int 0 check on
Valid int others uncheck off
Invalid int 0 uncheck off
Invalid int others check on
AlphaSpecialCharacter 0 check off
AlphaSpecialCharacter others uncheck on
Các trƣờng hợp kiểm thử:
Bảng 2-2. Bảng các trƣờng hợp kiểm thử sử dụng kỹ thuật pairwise testing
1 0 check on
50 1 uncheck off
-1 0 uncheck off
1,5 5 check on
Kytu 0 check off
!@#$%^&*<>/\ 9 uncheck on
Nhận xét: Kỹ thuật Pairwise Testing giúp giảm đi một lƣợng khá lớn các test
case mà vẫn đảm bảo hiệu quả của các testcase tạo ra. Tuy nhiên với một lƣợng lớn
số lƣợng các điều kiện cần kiểm thử cộng với mỗi điều kiện lại có một số lƣợng lớn
các giá trị cần kiểm thử thì việc thực hiện thủ công cũng gây tốn thời gian và rất có

thể xảy ra trƣờng hợp bỏ sót hoặc trùng test case.

Vấn đề đặt ra là tìm kiếm một công cụ tự động sinh ra các ca kiểm thử đầy đủ
và tối ƣu cho kỹ thuật này. PICTMASTER – Pairwise Independent Combinatorial
Testing Tool (© IWATSU System & Software Co., Ltd.) là một công cụ tạo test
case hàng dọc tự động, giúp cho việc tạo ra bộ test case với số lƣợng hợp lý mà vẫn
không bị sót trƣờng hợp test.
PictMaster là một công cụ viết bằng excel macro, yêu cầu máy tính đã cài đặt
môi trƣờng pict33.msi.
Hình 2-4 .Giao diện PictMaster Tool

Trong đó:
- Parameters: Thông tin về các parameters sẽ kiểm tra

- Value hierarchy: Thông tin về các giá trị của parameters
- Execute: Chạy tạo test case tự động từ các parameter và value đã nhập vào
- Edit: Thực hiện chỉnh sửa format của test case sau khi đã tạo tự động
- Settings: Thiết lập môi trƣờng để tạo test case
Sau khi nhập đầy đủ thông tin về các parameters với giá trị tƣơng ứng, chọn Build,
chƣơng trình sẽ xử lý và tự động cho ra một sheet mới chứa các test case kết quả.

Bảng 2-3 .Bảng các trƣờng hợp kiểm thử sử dụng PictMaster Tool
2.7. State Transition/Diagram Testing - Kỹ thuật biểu đồ chuyển trạng thái

Biểu đồ trạng thái là một loại sơ đồ đƣợc sử dụng trong khoa học máy tính và các
lĩnh vực liên quan để mô tả hành vi của hệ thống. Biểu đồ trạng thái đòi hỏi hệ thống
đƣợc mô tả bao gồm một hữu hạn các trạng thái.
Cũng giống nhƣ bảng quyết định, lƣợc đồ chuyển trạng thái là công cụ hữu ích để
đặc tả các yêu cầu phần mềm hoặc để đặc tả bảng thiết kế hệ thống phần mềm. Thay vì
miêu tả quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dƣới dạng dễ đọc và dễ
kiểm soát nhƣ bảng quyết định, lƣợc đồ chuyển trạng thái ghi nhận các sự kiện xảy ra,
rồi đƣợc hệ thống xử lý cũng nhƣ những đáp ứng của hệ thống.
Khi hệ thống phải nhớ trạng thái trƣớc đó của mình, hay phải biết trình tự các
hoạt động nào là hợp lệ, trình tự các hoạt động nào là không hợp lệ thìáp dụng kỹ thuật
dùng lƣợc đồ chuyển trạng thái là rất thích hợp.
Đặc điểm của lƣợc đồ trạng thái:
- Là sơ đồ mô hình hóa hành vi của hệ thống chứ không phải là sơ đồ mô tả

các câu lệnh trong code.
- Cho phép các Tester xem sự phát triển phần mềm trong một số điều kiện
nhập đầu vào và các sự kiện kích hoạt thay đổi trạng thái.
- Bổ sung các ca kiểm thử để phát hiện ra lỗi mà không thể phát hiện đƣợc
bằng điều kiện input, output bởi các phƣơng pháp khác.
2.8. Use case Testing – Kỹ thuật sử dụng use case

Trong quy trình phát triển phần mềm phải thực hiện nhiều workflows khác nhau:
nắm bắt yêu cầu phần mềm, phân tích từng yêu cầu, thiết kế chi tiết để giải quyết từng
yêu cầu, hiện thực từng phần bảng thiết kế, kiểm thử kết quả.

Về nguyên tắc, khi kiểm thử một thành phần phần mềm, ta có thể vận dụng bất kỳ
thông tin nào trong bất kỳ mô hình nào. Kỹ thuật kiểm thử dùng thông tin trong use case
là kỹ thuật định nghĩa các test case dựa vào các kịch bản thực hiện usecase.
o Use case là gì?

o Use case là một danh sách các bƣớc để giúp đạt đƣợc một mục đích nào đó trong
hệ thống.
o Các bƣớc này xác định sự tƣơng tác giữa actor với hệ thống.
o Use case “nắm bắt” đƣợc các yêu cầu về chức năng của hệ thống.
o Use case cũng định nghĩa các hệ quả gây ra bởi các lỗi trong suốt quá trình hệ
thống hoạt động.
o Use case xác định các kịch bản chính và các mong đợi của kịch bản đó.
Mô hình use case miêu tả hệ thống phần mềm theo góc nhìn bên ngoài: nó cung cấp
những chức năng nào cho những user nào. Thành phần thiết yếu nhất của mô hình use
case là các lƣợc đồ use case.
Mỗi lƣợc đồ use case thể hiện một bộ phận nhỏ của phần mềm bao gồm nhiều chức
năng và mỗi chức năng tƣơng tác với actor nào.
Trong cuốn “Writing Effect Use Cases” Alistair Cockburn đã đề nghị khuôn mẫu chi
tiết để đặc tả use case nhƣ sau:
Bảng 2-4 .Khuôn mẫu đặc tả use case theo Alistair Cockburn
Main Succcess Scenario Step Action
1 A (Actor):
S
(System):
2
…
Extensions Các kịch bản phát sinh từ các lỗi khi có những yêu cầu
biến thể khác.
2.9 Cause-Effect Diagram – Kỹ thuật dùng đồ thị nhân quả
Trong nhiều trƣờng hợp, việc cố gắng chuyển một chính sách hoặc một thủ tục trong
ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn đề khó hiểu. Đồ thị
nhân - quả là một phƣơng pháp thiết kế trƣờng hợp kiểm thử trên cơ sở đƣa ra một mô tả
súc tích các điều kiện logic và các hành vi kèm theo.

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả
cho thành phần phần mềm. Mỗi nguyên nhân đƣợc biểu diễn nhƣ một điều kiện (đúng
hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả đƣợc biểu diễn nhƣ là
một biểu thức Bool biểu diễn một kết một kết quả tƣơng ứng cho những thành phần vừa
thực hiện.
Dƣới đây là bảng các ký hiệu đƣợc đơn giản hóa sử dụng trong đồ thị nhân- quả:
Bảng 2-5. Bảng các ký hiệu sử dụng trong đồ thị nguyên nhân – hệ quả
STT Ký hiệu Ý Giải thích
nghĩ
Identity(Tƣơng
1 đƣơng)a Nếu a đúng thì b đúng
2 Not Nếu a sai thì b đúng
3 And Nếu a đúng và b đúng thì c đúng
4 Or Nếu a đúng hoặc b đúng thì c đúng
Exclusive (Loại Nếu a đúng thì b sai hoặc nếu a sai thì b
5 trừ) đúng
Inclusive (Bao a hoặc b hoặc c đúng; cả a, b, c không

6 hàm) đồng thời sai
Only one (Duy

7 nhất) Chỉ a hoặc b đúng

Requires (Yêu
8 cầu) Nếu a đúng thì b phải đúng
Mask (Mặt nạ)

9 Nếu a đúng thì b phải sai
Quy trình định nghĩa các testcase dùng kỹ thuật đồ thị nhân - quả gồm các bƣớc
sau:
o Bƣớc 1: Đặc tả của phần mềm đƣợc chia nhỏ ra nhiều phần để có thể làm
việc dễ dàng (nếu không, đồ thị nhân - quả sẽ rất phức tạp).
o Bƣớc 2: Nhận dạng các nguyên nhân và hệ quả của phần nhỏ đang xử lý.
o Bƣớc 3: Tìm mối quan hệ giữa các nguyên nhân và hệ quả, mỗi mối quan hệ
đƣợc vẽ thành 1 đƣờng nối.
o Bƣớc 4: Xác định các ràng buộc giữa các nguyên nhân và chú thích vào đồ
thị.
o Bƣớc 5: Chuyển đồ thị nhân quả về bảng quyết định.
o Bƣớc 6: Từ bảng quyết định chuyển thành các
testcase.
Ví dụ: Bài toán tính thuế thu nhập dựa vào mô tả sau:
Ngƣời vô gia cƣ nộp 4% thuế thu nhập.
Vídụ: Bài toán tính thuế thu nhập dựa vào mô tả sau:
- Ngƣời vô gia cƣ nộp 4% thuế thu nhập.
- Ngƣời có nhà ở nộp thuế theo quy định sau:
+ Thu nhập ≤ 5.000.000 nộp 4% thuế
+ Thu nhập > 5.000.000 nộp 6% thuế
Xác định đồ thị nhân - quả cho bài toán:

Hình 2-5 Đồ thị nhân – quả cho bài toán tính thuế thu nhập.
 Từ đồ thị nhân quả xây dựng bảng quyết định:
Bảng 2-6. Bảng quyết định cho đồ thị nhân – quả bài toán tính thuế thu nhập.
Trƣờng hợp
Nguyên nhân 1 2 3 4
Ngƣời có nhà ở N Y Y -
Có tổng thu nhập ≤ 5.000.000 - Y N Y
Có tổng thu nhập > 5.000.000 - N Y -
Hệ quả - - - -
Nộp thuế 4% X X - X
Nộp thuế 6% - - X -
 Từ bảng quyết định chuyển thành các testcase:

Bảng 2-6. Bảng test case sử dụng kỹ thuật dùng đồ thị nhân – quả
Điều kiện
ID Tên Testcase Quy trình thực hiện Kết quả mong đợi tiền đề
Kiểm tra mức thuế cho Chọn đối tƣợng: Thông báo mức thuế
1 ngƣời vô gia cƣ Ngƣời vô gia cƣ phải nộp là 4% -
Kiểm tra mức thuế cho Chọn đối tƣợng
2 ngƣời có nhà ở, thu Ngƣời có nhà ở, chọn Thông báo mức thuế -
nhập ≤ 5.000.000 thu nhập ≤ 5.000.000 phải nộp là 4%
Kiểm tra mức thuế cho Chọn đối tƣợng
3 ngƣời có nhà ở, thu Ngƣời có nhà ở, chọn Thông báo mức thuế -
nhập > 5.000.000 thu nhập > 5.000.000 phải nộp là 6%
Kiểm tra mức thuế Chọn đối tƣợng có
4 cho ngƣời có thu nhập mức thu nhập ≤ Thông báo mức -
≤ 5.000.000 5.000.000 thuế phải nộp là 4%

Nhận xét về kỹ thuật:

- Đồ thị nhân - quả yêu cầu chuyển một đặc tả thành một mạng logic Boolean,
nó cung cấp một triển vọng và sự hiểu biết sâu về đặc tả. Trên thực tế, sự
phát triển của một đồ thị nhân - quả là cách hay để khám phá sự mơ hồ và
chƣa đầy đủ trong các đặc tả.
- Mặc dùviệc vẽ đồ thị nhân - quả tạo ra tập các ca kiểm thử hữu dụng, nhƣng
thông thƣờng nó không tạo ra đƣợc tất cả các ca kiểm thử hữu dụng, ngoài
ra đồ thị nhân - quả không khảo sát thỏa đáng các điều kiện giới hạn. Dĩ
nhiên ngƣời kiểm thử có thể cố gắng bao phủ các điều kiện giới hạn trong
suốt quá trình. Tuy nhiên, vấn đề này làm cho đồ thị rất phứ tạp và dẫn đến
số lƣợng lớn các ca kiểm thử.
2.10. Kỹ thuật đoán lỗi

Tester đƣợc đƣa cho một chƣơng trình đặc biệt, họ phỏng đoán cả bằng trực giác và
kinh nghiệm, các loại lỗi có thể và sau đó viết các trƣờng hợp kiểm thử để đƣa ra các lỗi.
Thật khó để đƣa ra một quy trình cho kỹ thuật đoán lỗi vìnó là một quy trình có tính
trực giác cao và không thể dự đoán trƣớc. Ý tƣởng cơ bản là liệt kê một danh sách các
lỗi có thể hay các trƣờng hợp để dễ xảy ra lỗi và sau đó viết các trƣờng hợp kiểm thử
dựa trên danh sách đó.
Một ý tƣởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập
trình viên có thể đã thực hiện khi đọc đặc tả (tức là những thứ bị bỏ sót khỏi đặc tả hoặc
là do tình cờ, hoặc là vì ngƣời viết có cảm giác những đặc tả đó là rõ ràng). Nói cách
khác, tester liệt kê các trƣờng hợp đặc biệt mà có thể đã bị bỏ xót khi chƣơng trình đƣợc
thiết kế.
Vídụ: Trong quá trình làm việc của mình, tester gặp nhiều quy trình xử lý công việc nên
khi gặp một dự án mới, một phần mềm mới, tester sẽ biết đƣợc dạng phần mềm hay loại
màn hình này thì thƣờng gặp những loại lỗi gì, hoặc sau khi thực hiện một vài thao tác
thìkết quả phải xảy ra nhƣ thế nào…
Đối với màn hình tìm kiếm:

 Thƣờng xảy ra với lỗi tìm kiếm cả những bản ghi đã bị xóa. Vìvậy khi thiết
kế testcase và test màn hình tìm kiếm thìnên thêm vào testcase này - nếu
những bản ghi này đƣợc hiển thị thìmàn hình sai.
 Danh sách sau khi tìm kiếm phân trang bị lỗi: Nhiều khi lập trình viên quên
không xử lý phân trang thìkhi tìm kiếm đƣợc nhiều hơn số bản ghi chứa
trong một trang thìbị lỗi hoặc hiển thị tất cả trên một trang.
Đối với màn hình đăng nhập:

 Lỗi đôi khi lập trình viên khi code gán user là “admin” và password rỗng
hoặc để bằng “123”.
 Lỗi không xử lý action enter (Không login đƣợc khi nhấn enter mà phải click
button login.
 Đối với những website có tính bảo mật cao, khi user đang đăng nhập trên một
trình duyệt thìkhi copy link trình duyệt này sang trình duyệt khác không thể
vào đƣợc nếu chƣa đăng nhập. Trƣờng hợp thực hiện testcase này mà paste
link đăng nhập trình duyệt khác thành công tức là lỗi.
Đối với màn hình Thêm/Sửa/Xóa:
 Ở loại màn hình này thƣờng xảy ra lỗi là khi thêm mới vào lần thứ hai trở đi
thìbáo lỗi exception. Lý do là do cách xử lý ID khi thêm mới, thêm mới lần
hai bị trùng với ID với lần trƣớc nên Database Server không cho insert thêm
dẫn đến lỗi – nguyên tắc là sau mỗi lần thêm mới thìload lại dữ liệu).
 Nếu chƣơng trình có yêu cầu xử lý deadlock thì thƣờng xảy ra lỗi khi hai
ngƣời ngồi trên hai máy tính khác nhau cùng sửa trên 1 bàn ghi cùng lúc.
2.11. Kết luận

Chƣơng 2 đã nêu ra 8 kỹ thuật thiết kế testcase kiểm thử cơ bản và cũng là quan
trọng, hay sử dụng nhất trong các bài toán kiểm thử áp dụng kỹ thuật kiểm thử hộp đen.
Ứng với mỗi kỹ thuật là một bài toán cụ thể để demo quy trình thực hiện kỹ thuật kiểm
thử tƣơng ứng. Mỗi một yêu cầu cụ thể sẽ áp dụng một kỹ thuật hoặc kết hợp nhiều kỹ
thuật để mang lại hiệu quả nhất, bao quát tối ƣu các lỗi của sản phẩm kiểm thử.
Chƣơng 3 của đồ án sẽ tiến hành phân tích, lựa chọn áp dụng kỹ thuật kiểm thử
hộp đen tƣơng ứng để kiểm website phần mềm “Thi đua khen thƣởng” tƣơng ứng.

CHƢƠNG 3: TRIỂN KHAI KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG
3.1. Kiểm thử ứng dụng Website

Kiểm thử ứng dụng Website là một trƣờng hợp trong kiểm thử phần mềm, ở chƣơng
này sẽ đi sâu nghiên cứu loại ứng dụng kiểm thử Website về khái niệm, các loại kiểm
thử ứng dụng Website, chất lƣợng của một ứng dụng web cần đạt đƣợc, các công việc
khi kiểm thử một ứng dụng website và sẽ giới thiệu một số công cụ hỗ trợ kiểm thử cho
ứng dụng website.
Bởi có rất nhiều chức năng quan trọng cho ngƣời sử dụng ứng dụng nhƣ: tính hiệu
năng, tính dễ sử dụng, độ tin cậy và tính bảo mật cần đƣợc xem xét. Những yêu cầu và
mong đợi của ngƣời sử dụng, những vấn đề về nền tảng và cấu hình, mô hình nghiệp
vụ, sự phát triển và chi phí cho việc kiểm thử là những vấn đề thƣờng hay gặp phải và
thay đổi liên tục đổi xuyên suốt chu trình của một ứng dụng Website.
Ngƣời sử dụng không chỉ mong đợi chƣơng trình của họ sẽ vận hành một cách ổn
định, chính xác mà họ còn yêu cầu một số chức năng nào đó phải luôn sẵn sàng trên 24
giờ trong một ngày và bảy ngày trong tuần. Hơn nữa, ngƣời sử dụng còn mong đợi ở
chƣơng trình những ƣu điểm sau: tính dễ sử dụng, độ tin cậy, tốc độ, tƣơng thích với các
hệ thống khác nhau và tƣơng thích với các phiên bản trong tƣơng lai. Còn với một ứng
dụng Website, thìnhững yêu cầu về chất lƣợng bao gồm:
- Yêu cầu về chức năng: sự hiện diện của các chức năng đáp ứng những yêu cầu
đƣợc xác định. Các yêu cầu cần có nữa là tính phù hợp, chính xác, khả năng
tƣơng tác, tuân thủ và bảo mật.
- Yêu cầu về độ tin cậy: khả năng của một ứng dung để duy trìsự hiệu quả của nó
trong một điều kiện cụ thể và trong một khoảng thời gian xác định.
- Yêu cầu về khả năng sử dụng: Tính dễ sử dụng và hiệu quả của một ứng dụng.
Vấn đề này có thể đƣợc thẩm định bởi một nhóm ngƣời dùng giả định.
- Yêu cầu về hiệu quả: Tỷ lệ giữa mức độ hiệu quả của một ứng dụng và các tài
nguyên mà nó sử dụng trong các điều kiện cụ thể.
Các yêu cầu về chất lƣợng đóng một vai trò thiết yếu khi thử nghiệm các ứng dụng
Website. Mặc dù nhìn chung thì chúng tƣơng tự nhƣ những yêu cầu về chất lƣợng cho
các hệ thống phần mềm truyền thống. Tuy nhiên, chúng có thể có mức độ đòi hỏi cao
hơn về chiều sâu.
Do ý nghĩa quan trọng của các đặc điểm về chất lƣợng và sự khác biệt ở cách mà chúng
đƣợc kiểm thử, nhiều phƣơng pháp để kiểm thử một ứng dụng Website tập trung vào
một vài đặc điểm.

3.2. Kiểm thử website thi đua khen thƣởng tỉnh thanh hóa
3.2.1 Giới thiệu bài toán

Là sản phẩm của Đề tài KHCN cấp tỉnh của Ban Thi đua Khen thƣởng tỉnh Thanh
Hóa. Hệ thống giúp Ban Thi đua Khen thƣởng tỉnh, các đơn vị cơ sở Quản lý, lƣu trữ,
khai thác các hồ sơ đề nghị khen thƣởng từ đó tổ chức quản lý theo dõi thông tin hồ sơ
cá nhân, tổ chức đƣợc trình khen thƣởng dựa trên các thành tích đã đạt đƣợc.
Nhờ việc lƣu trữ lại tất cả các thông tin dữ liệu trong quá trình làm việc nên phần
mềm có thể thống kê tổng hợp kết quả khen thƣởng theo nhiều mẫu biểu khác nhau để
phục vụ cho công tác quản lý và các mục đích nghiên cứu.
Hình 3-1 Giao diện phần mềm thi đua khen thƣởng
 Nghiệp vụ Quản lý Thi đua khen thƣởng tỉnh thanh hóa:

+ Quản trị hệ thống; Quản lý thông tin cán bộ (thông tin chung; quá trình công tác;
Quá trình khen thƣởng; kỷ luật…).
+ Quản lý thi đua (quản lý phong trào thi đua, đăng ký thi đua, tổ chức thực hiện thi
đua, đánh giá, xét tặng thi đua…); Quản lý khen thƣởng (quản lý khen thƣởng
thƣờng xuyên, quản lý loại hình khen thƣởng ngoài ngành, cập nhật thông tin lịch
sử khen thƣởng, tổng kết khen thƣởng…).
+ Danh sách đề nghị xét duyệt.
+ Danh sách đƣợc khen thƣởng, lịch sử khen thƣởng…).
+ Đồng thời, trợ giúp các hoạt động nghiệp vụ thi đua, khen thƣởng gồm:
Công tác thi đua (tổ chức, phát động, đăng ký thi đua, tổ chức thực hiện phong trào
thi đua), tổ chức công tác kiểm tra, giám sát; tổng hợp, đánh giá kết quả phong trào thi
đua (tổng kết, chấm điểm, bình xét thi đua).

Công tác khen thƣởng: hồ sơ xét thƣởng (báo cáo tổng kết thi đua, điểm thi đua, đề
nghị khen thƣởng); Báo cáo thành tích khen thƣởng; Hỗ trợ quy trình thẩm.
3.2.2. Biểu đồ mô tả các chức năng sẽ đƣợc thực hiện kiểm thử hộp đen
Từ việc phân tích tài liệu mô tả yêu cầu mức cao và tài liệu đặc tả chức năng, áp
dụng các kỹ thuật kiểm thử hộp đen đã nghiên cứu tại Chƣơng 2 tiến hành xây dựng bộ
các testcase cho quản lý đăng kí thi đua.
 Xác định quy trình kiểm thử phần mềm
Hình 3-2a Quy trình kiểm thử phần mềm thi đua khen thƣởng
 Mô hình quản lý testcase
Hình 3-2b. Biểu đồ quản lý testcase mo-đun phần mềm thi đua khen thƣởng

3.2.3 Thiết kế định hƣớng trƣờng hơp kiểm thử
Bảng 3-1. Bảng thiết kế trƣờng hợp kiểm thử
PHƢƠNG
STT DANH MỤC PHƢƠNG ÁN TEST
THỨC TEST
TEST CHỨC
I
NĂNG
- Kiểm thử thông báo khi không
nhập các trƣờng yêu cầu bắt buộc.
- Kiểm thử thông báo khi nhập đúng,
sai định dạng của trƣờng nhập.
- Kiểm thử độ dài tối đa của từng
trƣờng cho phép nhập
- Kiểm thử tình trạng của các nút
bấm (Nhấp nhiều hơn 1 lần khi cập
Tạo tài khoản
nhật)
ngƣời dùng,
- Kiểm tra nội dung các trƣờng theo
đơn vị.
thông tin hiện tại đang có (tên địa
danh, danh mục nghề nghiệp ....
các thông tin có thể thay đổi theo
thời gian).
Chức năng của - Kiểm thử trang đƣợc chuyển
I.1
tài khoản hƣớng khi thêm thành công tài
khoản.
- Kiểm thử thông báo khi thêm tài
khoản thất bại
- Xác định các trƣờng đƣợc sửa, các
trƣờng không đƣợc sửa
- Kiểm thử thông báo khi chọn chỉnh
Sửa tài khoản sửa trƣờng không đƣợc chỉnh sửa.
ngƣời dùng, - Kiểm thử thông báo khi chọn chỉnh
đơn vị. sửa trƣờng cho phép chỉnh sửa.
- Kiểm thử hiển thị khi chỉnh sửa
thành công một trƣờng dữ liệu
- Kiểm thử hiển thị khi làm mới
trang nhƣng chỉnh sửa chƣa đƣợc
cập nhật.

- Kiểm thử thƣ viện của trang "SỬA

TÀI KHOẢN NGƢỜI DÙNG" và
trang "TẠO TÀI KHOẢN NGƢỜI
DÙNG" có đồng nhất.
- Kiểm thử hiển thị của danh sách tài
khoản khi chọn tài khoản bất kỳ để
chỉnh sửa
- Kiểm thử thông báo khi xóa ngƣời
dùng đang có hoạt động.
- Xác định xóa ngƣời dùng là khóa
Xóa tài khoản
vĩnh viễn hoặc xóa tạm thời.
ngƣời dùng,
- Trang đƣợc chuyển tiếp khi xóa
đơn vị
ngƣời dùng thành công.
- Trang đƣợc chuyển tiếp khi xóa
ngƣời dùng không thành công
- Nhập phạm vi 6-12 kí tự(user
name)
- Phần mềm cho phép đăng nhập
nhiều tài khoản cùng 1 thiết bị.
- Đăng nhập có yêu cầu token
- Cơ chế kiểm tra khi đăng nhập sai
Đăng nhập nhiều lần (5-10-15 lần).
- Kiểm thử thông báo khi đăng nhập
nhiều thiết bị cùng 1 tài khoản.
- Kiểm thử thao tác của tài khoản từ
các thiết bị khác nhau.
- Kiểm thử user, pass có khoảng
trống trƣớc, sau, giữa.
- Cho phép đăng xuất 1 lần từ tất cả
các thiết bị.
- Thời gian đăng xuất khỏi phần
mềm.
- Tắt ứng dụng nhƣng chƣa đăng
Đăng xuất
xuất, khi mở lại có cho phép tiếp
tục phiên đăng nhập
- Chuyển hƣớng trang web khi đăng
xuất.
- Kiểm thử sử dụng nút BACK-

FORWARD của trình duyệt sau

khi đăng xuất
- Kiểm thử lấy lại mật khẩu nhiều

lần
- Kiểm thử thông báo khi nhập sai
Lấy lại mật email
khẩu - Kiểm thử thông báo từ 1 thiết bị
gửi nhiều lần lấy lại mật khẩu
- Kiểm thử thông tin phản hồi từ
mail ->nhập mã lấy lại mật khẩu
- Đổi mật khẩu của từng tài khoản
theo ý muốn (thay đổi mới so với
mật khẩu mặc định).
- Kiểm thử khi không nhập xác nhận
pass mới.
- Kiểm thử khi pass mới và pass cũ
trùng nhau.
Thay đổi mật - Kiểm thử thay đổi mật khẩu thành
khẩu công nhƣng đăng nhập pass cũ.
- Kiêm thử khi nhập pass mới quá
ngắn.
- Kiểm thử đồng bộ kí tự giữa đăng
nhập và thay đổi mật khẩu.
- Kiểm thử thông báo khi đang đăng
nhập và tài khoản đƣợc đổi mật
khẩu ở thiết bị khác
- Kiểm thử khi không điền tên hoặc
một số trƣờng bắt buộc.
- Kiểm thử đăng kí khi không trong
đợt đăng kí.
I.2 BTĐKT Đăng kí - Kiểm thử đăng kí trong đợt đăng
kí.
- Kiểm thử đăng kí khi chƣa đăng kí
lần nào.
- Kiểm thử đăng kí khi đã đăng kí

- Kiểm thử Thêm mới đợt thi đua

(thành công, không thành công).
- Kiêm thử Sửa đợt thi đua.
- Kiểm thử Không nhập các trƣờng
Quản lý đợt bắt buộc khi thêm mới đợt thi đua
đăng kí thi đua. - Kiểm thử Tự chấm điểm đợt thi
đua
- Kiểm thử chức năng tạo tên khi
chấm điểm
- Kiểm thử Xóa đợt thi đua.
- Kiểm thử Tìm kiếm đợt thi đua
- Kiểm thử tìm kiếm hồ sơ
- Kiểm thử Thêm mới hồ sơ với đối
tƣợng chƣa biên chế.
- Kiểm thử Thêm mới, sửa, xóa
Kiểm thử hồ sơ Danh hiệu đối tƣợng chƣa biên
lƣu chế.
- Kiểm thử Thêm, sửa, xóa Quyết
đinh.
- Kiểm thử khi không điền đủ thông
tin.
- Màu sắc hài hoà hợp lý, font: Time
a. Menus, size,
New Roman.
position, state,
- Trên các list ở hình phải sort đƣợc
màu sắc, font
theo các cột thông tin: <chèn hình
b. Zoom to nhỏ,
> Thời gian Order mới nhất.
Sai lỗi chính tả,
- Size: 13 vừa tầm mắt.
ảnh, mẫu in
- Đảm bảo có thể zoom to nhỏ.
c. Textbox,
- Kiểm thử mắc lỗi chính tả.
III.3 Interface option (radio
- Ảnh yêu cầu nhìn rõ 2D, 3D.
button), check
- Mẫu in hiển thị chính xác thông
boxes,
tin, không lặp từ sai lỗi chính tả.
command
- Ngôn từ sử dụng tế nhị.
button, combo
- Kiểm thử phân trang (khi list quá
boxes list
dài )
boxes, Label,
- Kiểm thử hiển thị thông tin đúng
Icon
với từng chức năng

3.3 Thiết kế bộ các testcase
3.3.1 Testcase kiểm thử chức năng đăng nhập, thay đổi mật khẩu, đăng xuất.
Hình 3-3. Màn hình đăng nhập Thi đua khen thƣởng
Tài khoản đƣợc phép đăng nhập vào hệ thống là tài khoản Ban thi đua khen thƣởng
đã đƣợc tạo thành công tại hệ thống phía trung tâm. User không nhập sai tên đăng nhập
và mật khẩu, thay đổi mật khẩu phải đúng với thông tin tài khoản.
Mỗi tài khoản đăng nhập thỏa mãn:
- Tên đăng nhập: Từ 6 đến 12 ký tự không chứa ký tự trắng bao gồm các ký tự
chữ và số.
- Mật khẩu: Từ 6 đến 12 ký tự.
Á p dụng kỹ thuật giá trị biên cho các trƣờng hợp của tên đăng nhập và mật khẩu:
- Đăng nhập thành công: Nhập đúng [Tên đăng nhập] và [Mật khẩu].
- Đăng nhập không thành công: Nhập sai thông tin một trong hai trƣờng [Tên
đăng nhập] / [Mật khẩu] hoặc không nhập thông tin đăng nhập, nhập thông
tin đăng nhập nhƣng không đăng nhập.
- Tên đăng nhập và mật khẩu sai.
- Nhập sai mật khẩu cũ và không nhập xác nhận mật khẩu hoặc nhập xác nhận
mật khẩu không đúng.
- Hình thành bộ testcase cho chức năng đăng nhập hệ thống với tài khoản đăng
nhập chuẩn là btdkt/123456:

Bảng 3-2 Testcase Đăng nhập – đăng xuất – thay đổi mật khẩu phần mềm thi đua khen thƣởng
Inter-test
Test Case Test Case Expected case
ID
Description Procedure Output Dependen
ce
Test Function
Check Login
Van_Account _logout_
successfully
Check login User have
Van_login_01 1. Start Open form
successfully account
Check form
have enough
Van_login_02 component 1. Start up Display true
(Texbox,submit
...)
1. Start
2.Input username login User have
Van_login_03 Check login
3.Input password successful account
4.Click login
1. Start
2.Input space last
Check space login User have
Van_login_05 username
last username successfull account
3.Input password
4.Click login
Start
Check "Forget Receive User have
Van_login_06 2.Input phone
pass" new pass account
3.Input Mã hóa
Van_logout_0 1. start login User have

Check logout
1 2.click logout successfull login
Check
Login_logout
unsuccessfully

1. Start
2.Input html
Check input
username login
space User have
Van_login_07 3.Input space unsuccessful
before,after account
before,after l
password
password
4.Click login
1. Display
1. Start
error
2.Input wrong
Check wrong message User have
Van_login_08 username
user name "input account
3.Input password
wrong
4.Click login
username "
1. Display
1. Start
error
2.Input username
Check wrong message User have
Van_login_09 3.Input wrong
password "Input account
password
wrong
4.Click login
password"
1. Start
2.Not Input 1. Display
Check not input username error User have
Van_login_10
anything 3.Not Input message account
password "...... "
4.Click login
1. Start
Display
Check input 2.Input username
message"pa User have
Van_login_11 password <6 3.Input password
ssword 6-12 account
character <6 character
character"
4.Click login
1. Start
Display
Van_login_12 password =6 3.Input password
ssword 6-12 account
character =6 character
character"
4.Click login

1. Start
Display
Van_login_13 password >12 3.Input password
ssword 6-12 account
character >12 character
character"
4.Click login
1. Start
Display
Van_login_14 password =12 3.Input password
ssword 6-12 account
character =12 character
character"
4.Click login
1. Display
1. Start error
Check 2.Input username message
User have
Van_login_15 password have 3.Input password "Input
account
space at mid\ have space wrong
4.Click login password
"
Van_change Van_change
password_ password
successful
1. Click [Thay đổi
mật khẩu ]button
2.Input old pass
Van_Change_ 3.Input new pass
Start successful
pass_01 4.Xác nhận lại
newpass
5.Click[Save]
6.Relogin
2.Input old pass
Check change 3.Input new pass=
Van_Change_
oldpass = oldpass successful
pass_02
newpass 4.Xác nhận lại
newpass
5.Click[Save]
6.Relogin

Van_change
password
unsuccessful
Van_Change_ 1. Click [Thay đổi
pass_02 mật khẩu ]button
Check not
2.Input old pass
input newpass 1. Display
3.Not Input new
but input message" User have
pass
confirm please input account
4.Input confirm
password this field"
newpass
Vídụ (pass : 1 )
5.Click[Save]
6.Relogin
pass_03 mật khẩu ]button
2.Input old pass
Check input 1. Display
3.Input new pass
newpass max message" User have
max short
short input pass account
4.Xác nhận lại
Vídụ (pass : 1 ) not safe "
newpass
5.Click [Save]
6.Relogin
1. Display
message"
2.Input old pass
Check have input wrong
3.Input new pass
Van_Change_ change pass pass or pass User have
Xác nhận lại
pass_04 .but login old have change account
newpass
pass before "
5.Click [Save]
2.unsuccessf
6.Relogin= old
ul
pass
1. Display
message"
2.Input wrong old
input old
Van_Change_ Check input pass User have
pass not true
pass_05 wrong old pass 3.Input new pass account
"
4.Xác nhận lại
2.unsuccessf
newpass
ul
5.Click [Save]

6.Relogin

mật khẩu] button 1. Display
2.Input old pass message"Co
Check Not
3.Not Input new nfirm
Van_Change_ input newpass User have
pass password
pass_06 but confirm account
4.Xác nhận lại not true "
password mới
newpass 2.unsuccessf
5.Click [Save] ul
6.Relogin
mật khẩu ]button 1. Display
Check input 2.Input old pass message"Co
newpass khác 3.Input new pass nfirm
Van_Change_ User have
với new max short password
pass_07 account
confirm 4.Xác nhận lại not true "
password mới newpass 2.unsuccessf
5.Click [Save] ul
6.Relogin
mật khẩu] button 1. Display
2.Input old pass message"
Check input 3.Input new pass input old
Van_Change_ User have
have space mix max short pass not true
pass_08 account
old pass 4.Xác nhận lại "
newpass 2.unsuccessf
5.Click [Save] ul
6.Relogin
pass_09 mật khẩu] button
2.Input old pass.
Check input old
3.Input new pass
pass and new 1.unsuccessf User have
max short
pass. ul account
4.Xác nhận lại
Click cancel
newpass
5.Click [Save]
6.Relogin

3.3.2 Testcase kiểm thử chức năng đăng kí

Mục đích : Đăng kí
Mô tả :
 Ngƣời sử dụng có thể xem đợt đăng kí.
 Đăng kí
 Chấm điểm
 Duyệt chấm điểm
 Duyêt lại chấm điểm
Luồng sự kiện
 Phải nằm trong đợt đăng kí và chƣa đăng kí
Hình 3-4: Màn hình chức năng đăng kí
Từ mô tả và luồng sự kiện đƣa kỹ thuật áp dụng kiểm thử chức năng đăng kí: Sử dụng
kỹ thuật kiểm thử bảng quyết định.

Điều kiện 1 2 3 4
Trong đợt đăng kí y y n n
Chƣa đăng kí y n y n
Kết Đƣợc đăng kí x
quả
Không đƣợc đăng kí x x x
Bảng sau khi gộp
Điều kiện 1 2 3
Trong đợt đăng kí y y n
Chƣa đăng kí y n y
Kết
Đƣợc đăng kí x
quả
Không đƣợc đăng kí x x
Bảng 3-3. Bảng testcase dùng kỹ thuật quyết định chức năng
đăng kí
Đăng kí thi Đăng kí thi đua

đua successful
1. Click [Đăng kí thi đua]
2. Click [Cá nhân].
Check[Đăng kí thi 3. Click [Đợt thi đua]
DKTD_01 successful
đua]cá nhân 4. Click [Danh hiệu]
5. Click [Hình thức]
6. Click [Cập nhật]
2. Click [Tập thể].
DKTD_02 successful
đua]tập thể 4. Click [Danh hiệu]


2. Click [Danh sách cá nhân].
DKTD_03 successful
đua]danh sách cá nhân 4. Click [Danh hiệu]
Check time on[Thời
3. Click [Đợt thi đua]
DKTD_04 gian đăng kí] and successful
4. Click [Danh hiệu]
havent resgister
Check [thời gian diễn
DKTD_06 ra ]=[thời gian hiện successful
tại]
Đăng kí thi đua
unsƣccessful
1. Click [Đăng kí thi đua] Display
Check [Đăng kí ] tỉme
2. Click [Danh sách cá nhân]. message
havent [Thời gian
DKTD_09 "Have nt
đăng kí] and havent
on time
resgister
register"
1. Click [Đăng kí thi đua] Display
Check [Đăng kí ] time
2. Click [Danh sách cá nhân]. message
DKTD_08 on [thời gian đăng kí]
3. Click [Đơt thi đua] "Haven
and registed
register"
Bảng 3- 4. Testcase Đăng kí thi đua.
3.3.3. Testcase kiểm thử chức năng Quản lý đợt thi đua
Mục đích : Quản lý đợt thi đua
Mô tả :
 Ngƣời sử dụng có thể xem list đợt thi đua
 Thêm, sửa, xóa đợt thi đua
 Đăng kí đợt thi đua
 Chấm điểm đợt thi đua
Luồng sự kiện
 View đợt thi đua

 Thêm mới, sửa xóa đợt thi đua.

 Chấm điểm thi đua: STT là số cho tiêu chí, STT là chữ /số La Mã cho
nhóm.
Hình 3-5 Màn hình quản lý đợt thi đua
 Lớp tương đương cho trƣờng Ngày diễn ra, ngày đăng kí, ngày chấm điểm lại,
ngày duyệt. Theo đó, ngày không thể chọn đƣợc ngày thuộc lớp các ngày lớn
hơn hoặc nhỏ hơn ngày hiện tại, hoặc ngày diễn ra không đƣợc nhỏ hơn ngày
đăng kí.
 Các testcase khác sẽ phụ thuộc vào việc đặc tả chức năng và tuân thủ theo quy
định về giao diện màn hình, quy định về font chữ riêng đƣợc quy định trong tài
liệu đặc tả chức năng.
 Dùng bảng quyết định để kiểm thử Chấm điểm cá nhân, chấm điểm tập thể:
STT là số cho tiêu chí, STT là chữ /số La Mã cho nhóm.
Bảng 3-6 Testcase Đợt thi đua

[Đợt thi đua]
Đợt thi đua
successful
1. Click [Thêm mới đợt
thi đua]
2. Click [Cấp phát
User
Check [Thêm động]
Van_ĐTĐ_01 successful have
mới] 3. Click [Đơn vị phát
account
động]
4. Click [Ngày bắt đầu]
5. Input [Tên đợt thi

đua]
6. Click [Trạng thái]
7. Input [Kế hoạch]
1. Click [Đăng kí thi
đua]
2. Click [Danh sách cá
nhân].
7. Click [Thời gian
diễn ra]
User
Check [Danh hiệu 8. Click [Thời gian
đã đƣợc đăng kí] đăng kí]
account
9. Click [Thời gian tự
chấm điểm]
chấm điểm lại]
xét tặng]
12. Click [Danh hiệu
đã đƣợc tặng]
13. Click button [Danh
hiệu]
đua]
nhân].
4. Click [Danh hiệu] User
Check[Hình thức
Van_ĐTĐ_03 5. Click [Hình thức] successful have
đã đƣợc đăng kí]
6. Click [Cập nhật] account
diễn ra]
đăng kí]

chấm điểm]
xét tặng]
12. Click [Danh hiệu
đã đƣợc tặng]
13. Click button [Danh
hiệu]
14.Click button[Hình
thức đã đƣợc đăng kí]
15. Click [Ghi lại]
1. Click [Đợt thi đua] User
Van_ĐTĐ_04 Check [Sửa] 2. Click [Sửa] successful have
3. Click [Ghi lại] account
1. Click [Đợt thi đua] User
Van_ĐTĐ_05 Check [Xóa] 2. Click [Xóa] successful have
account
đua]
Check [kế hoach] nhân].
after [Thêm mới 3. Click [Đợt thi đua] User
Van_ĐTĐ_06 4. Click [Danh hiệu] successful have
đợt thi đua]
5. Click [Hình thức] account
successful
7. Click [Kế hoạch]
1. Click [Quản lý thi

User
Check [Chấm đua]
điểm cá nhân] 2. Click [Chấm điểm cá
account
nhân]
User
Check [Chấm đua]
điểm tập thể ] 2. Click [Chấm điểm
account
tập thể ]
Van_ĐTĐ_09 Check[Duyệt kết 1. Click [Quản lý thi successful User

quả chấm] đua] have

2. Click [Duyệt kết quả account
chấm]
User
Check [Chấm đua]
điểm lại] 2. Click [Chấm điểm
account
lại]
User
Check [Thi đua đua]
tập thể] 2. Click [Thi đua tập
account
thể]
User
Check [Thi đua cá đua]
nhân] 2. Click [thi đua cá
account
nhân]
1. Click [Quản lý thi User
Check [Duyệt
Van_ĐTĐ_13 đua] successful have
điểm ]
2. Click [Duyệt điểm ] account
[ Đợt thi đua]
unsuccessful
thi đua]
động] Display
Check [Thêm mới
3. Click [Đơn vị phát message " User
đợt thi đua ] but
Van_ĐTĐ_14 động] Please have
not input [Tên đợt
4. Click [Ngày bắt đầu] input this account
thi đua]
5. Not Input [Tên đợt field"
thi đua]
thi đua] Display
Check [Thêm mới
2. Click [Hình thức message " User
Van_ĐTĐ_15 phát động] Please have
not input [Tên đợt
3. Click [Cấp phát input this account
thi đua]
động] field"
4. Click [Đơn vị phát

động]
6. Not Input [Tên đợt
thi đua]
thi đua]
2. Not Click [Hình thức
phát động]
3. Click [Cấp phát Display
Check [Thêm mới
động] message " User
Van_ĐTĐ_16 4. Click [Đơn vị phát Please have
not click[Hình
động] input this account
thức phát động]
5. Click [Ngày bắt đầu] field"
đua]
thi đua]
2. Click [Hình thức
phát động]
3. Not Click [Cấp phát Display
Check [Thêm mới
động] message " User
Van_ĐTĐ_17 4. Click [Đơn vị phát Please have
not click [Cấp
động] input this account
phát động]
5. Click [Ngày bắt đầu] field"
đua]
1. Click [Tiêu chíchấm
Check [Tiêu chí điểm] Cann’t
User
chấm điểm] input 2. Input STT = A and input
Van_ĐTĐ_18 have
"string" but input [Tên] = Tên tiêu chí continue
account
[tên tiêu chí] 3. Click [Cấp phát field
động]

4. Click [Đơn vị phát

động]
đua]
1. Click [Tiêu chíchấm
điểm]
2. Input STT = A and
[Tên] = Tên tiêu chí
Check [Tiêu chí Cann’t
động] User
chấm điểm] input input
Van_ĐTĐ_19 4. Click [Đơn vị phát have
"number " but continue
động] account
input [tên nhóm field
đua]
đua]
nhân].
4. Not Click [Danh
hiệu] Display
5. Click [Hình thức] message "
Check [Đợt thi User
6. Click [Cập nhật] Please
Van_ĐTĐ_20 đua] not click have
7. Click [Thời gian choose
[Danh hiệu ] account
diễn ra] [danh
8. Click [Thời gian hiệu]"
đăng kí]
chấm điểm]

xét tặng]

đua]
nhân].
5. Not Click [Hình
Display
thức]
message "
Check [Đợt thi 6. Click [Cập nhật] User
Please
Van_ĐTĐ_21 đua] not click 7. Click [Thời gian have
choose
[Hình thức] diễn ra] account
[hình thức]
"
đăng kí]
chấm điểm]
xét tặng]
đua]
nhân].
5. Click [Hình thức] Display
Check [Đăng kí
6. Click [Cập nhật] message " User
thi đua] not click
Van_ĐTĐ_22 7. Not Click [Thời gian Please have
[Thời gian diễn
diễn ra] input this account
ra]
8. Click [Thời gian field"
đăng kí]
chấm điểm]

xét tặng]

đua]
nhân].
Display
Ceck [Đợt thi 6. Click [Cập nhật]
message " User
đua] not click 7. Click [Thời gian
Van_ĐTĐ_23 Please have
[Thời gian tự diễn ra]
input this account
chấm điểm] 8. Click [Thời gian
field"
đăng kí]
9. Not Click [Thời gian
tự chấm điểm]
xét tặng]
đua]
nhân].
Display
Check [Đợt thi 6. Click [Cập nhật]
message " User
đua] not click 7. Not Click [Thời gian
[Thời gian chấm diễn ra]
input this account
điểm lại] 8. Click [Thời gian
field"
đăng kí]
chấm điểm]
xét tặng]


đua]
nhân].
Display
Check [Đợt thi 6. Click [Cập nhật]
message " User
đua] not click 7. Not Click [Thời gian
[Thời gian đăng diễn ra]
input this account
xét tặng] 8. Click [Thời gian
field"
đăng kí]
chấm điểm]
11. Not Click [Thời
gian xét tặng]
đua]
nhân].
5. Click [Hình thức] Display "
Check [Đợt thi 6. Click [Cập nhật] [Thời gian
User
đua] [Thời gian 7. Not Click [Thời gian diễn ra ]
Van_ĐTĐ_26 have
diễn ra ] <[thời diễn ra] not < [Thời
account
gian hiện tại] 8. Click [Thời gian gian hiện
đăng kí] tại]
chấm điểm]
xét tặng]


đua]
nhân].
5. Click [Hình thức] Display "
Check [Đợt thi 6. Click [Cập nhật] [Thời gian
User
đua] [Thời gian 7. Not Click [Thời gian diễn ra ]
Van_ĐTĐ_27 have
diễn ra ] <[thời diễn ra] not < [Thời
account
gian đăng kí] 8. Click [Thời gian gian đăng
đăng kí] kí]
chấm điểm]
xét tặng]
3.3.4. Testcase kiểm thử chức năng Hồ sơ lƣu.

Mục đích : Quản lý hồ sơ
Mô tả :
 Ngƣời sử dụng có thể quản lý, xem hồ sơ cá nhân, hồ sơ tập thể.
 Thêm, sửa, xóa khen thƣởng, danh hiệu.
 Cập nhật danh sách khen thƣởng
 Tra cứu thông tin
Luồng sự kiện
 View hồ sơ
 Nhập dữ liệu hồ sơ: Yêu cầu không để trống các trƣờng bắt buộc, các
trƣờng giới hạn 6-16 kítự.

Hình 3-6. Màn hình quản lý hồ sơ.
Bảng 3-7. Testcase Quản lý hồ sơ.
Quản lý hồ Quản lý hồ sơ
sơ successful
1. Click [Quản lý hồ sơ]
Van_Ql_01 Check view [Hồ sơ ]
2. Click view hồ sơ
2. Click [Thêm hình thức khen
thƣởng]
3. Click [Khen thƣởng] Display
Check [Thêm hình 4. Input [Quyết định] message
Van_Ql_02
thức khen thƣởng] 5. Click [Ngày quyết định] "Update
6. Input [Cấp quyết định] successful"
7. Input [Tên quyết định]
8. Click [file]
2. Click view [hinh thức khen Display
Check[Sửa hình thức thƣởng] message
Van_Ql_03
khen thƣởng] 3. Click [Sửa hình thức khen "Update
thƣởng] successful"

1. Click [Quản lý hồ sơ] Display

Check [Xóa hình thức 2. Click [Xóa hình thức khen message
Van_Ql_04
khen thƣởng] thƣởng] "Delete
successful"
2. Click [Thêm danh hiệu]
3. Click [Khen thƣởng]
Display
4. Input [Quyết định]
Check [Thêm danh message
Van_Ql_05 5. Click [Ngày quyết định]
hiệu]] "Update
6. Input [Cấp quyết định]
successful"
8. Click [file]
Van_Ql_06 Check[ơTra cứu] 2. Click [Tra cứu] successful

Check [Xóa danh
Van_Ql_07 2. Click [Xóa danh hiệu] successful
hiệu]
Quản lý hồ sơ
unsuccessful
thƣởng]
Check [Tthêm hình 3.Not Click [Khen thƣởng] Display
thức khen thƣởng] 4. Input [Quyết định] message
Van_Ql_08
not click [Khen 5. Click [Ngày quyết định] "Please click
thƣởng] 6. Input [Cấp quyết định] this field"
8. Click [file]


thƣởng]
Check [Thêm hình 3. Click [Khen thƣởng] Display
thức khen thƣởng] 4. Not Input [Quyết định] message
Van_Ql_09
not input [Quyết 5. Click [Ngày quyết định] "Please input
định] 6. Input [Cấp quyết định] this field"
8. Click [file]
2. Click[Thêm hình thức khen
thƣởng]
3. Click [Khen thƣởng].
Check [Thêm hình Display
4. Input [Quyết định].
thức khen thƣởng] message
Van_Ql_10 5. Not Click [Ngày quyết
not click [Ngày quyết "Please input
định].
định] this field"
6. Input [Cấp quyết định].
7. Input [Tên quyết định].
8. Click [file].
thƣởng]
Check [Tthêm hình 3. Click [Khen thƣởng] Display
Van_Ql_11
not input [Cấp quyết 5. Click [Ngày quyết định] Please input
định] 6. Not Input [Cấp quyết định] this field"
8. Click [file]


thƣởng]
Check [Thêm hình 3. Click [Khen thƣởng] Display
Van_Ql_12
not input [Tên quyết 5. Click [Ngày quyết định] "Please input
định] 6. Input [Cấp quyết định] this field"
7. Not Input [Tên quyết định]
8. Click [file]
thƣởng]
Display
3. Click [Khen thƣởng]
Check [Thêm hình message
4. Input [Quyết định]
thức khen thƣởng], "[Cant occur
Van_Ql_13 5. Click [Ngày quyết định] <
[Ngày quyết định]< [Ngày quyết
Ngày hiện tai]
[Ngày hiện tại] đinh]< [Ngày
6. Input [Cấp quyết định]
hiện tại]"
8. Click [file]

3.3.5. Testcase sử dụng kỹ thuật use case.
Hình 3-7. Biểu đồ use case Ban thi đua khen thƣởng
Bảng 3-9. Các bƣớc mô tả use case
Step Action
1 BTĐ: Thực hiện đăng nhập
2 BTĐ: Chọn Thêm đợt thi đua mới
3 HT: Lƣu đợt thi đua
4 BTĐ: Chọn Đăng kí đợt thi đua
Các kịch bản thành công 5 HT: Kiểm tra điều kiện
chính 6 BTĐ: Chọn quản lý hồ sơ
BTĐKT:Ban thi đua khen HT: Kiểm tra hiển thị thông tin hồ sơ
7
thƣởng 8 BTĐ: Chọn thêm quyết định, danh hiệu
9 HT: Lƣu vào hệ thống

HT : Hệ 10 BTĐ: Quyết định khen thƣởng chƣa biên chế

thống 11 HT : Lƣu thông tin, in
12 BTĐ : Tra cứu
13 HT : Đƣa thông tin
Mất kết nối tới cơ sở dữ liệu
Mở rộng 1a HT: Thông báo kiểm tra lại kết nối tới cơ sở
dữ liệu
Sai thông tin tài khoản

1b HT: Thông báo tài khoản không đúng yêu
cầu đăng nhập lại
Nhấp thiếu trƣờng bắt buộc
HT: Thông báo trƣờng này bắt buộc
2a
Nhập nhƣng click [Hủy]
2b HT : Quay lại trang chủ và đợt thi đua
không đƣơc lƣu
Không trong đợt thị đua
4a HT : Khộng có đợt thi đua nào
4b
Đợt thi đua đã bị xóa
HT: Thông báo không có đợt thi đua nào
Đợt thi đua đã đƣợc đăng kí
4c HT: Thông báo đợt thi đua đã đƣợc đăng kí
Quyết định bị lặp
8a HT: Thông báo “Quyết định đã tồn tại”
Click khen thƣởng nhƣng không chọ danh
9a sách cá nhân đƣợc khen thƣởng
HT : Thông báo” Chƣa có cá nhân đƣợc
khen thƣởng “
9b Click danh sách khen thƣởng nhƣng nhập
thiếu thông tin quyết định
HT : Thông báo khen thƣởng không thành
công
12 Tra cứu những hồ sơ đã bị xóa
HT :Hồ sơ đã bị xóa

Bảng 3-10.Testcase sử dụng kỹ thuật use case
Use case Successful
Van_UC User have

Login successful start up successful
_01 account
Van_UC User have
Add [Đợt đăng kí] start up successful
_02 account
Van_UC User have
[Đăng kí thi đua] start up successful
_03 account
[Quản lý hồ sơ lƣu(cá
Van_UC User have
nhân tổ chức chƣa start up successful
_04 account
biên chế]
Van_UC User have
[Lƣu] start up successful
_05 account
Van_UC User have
[Tra cứu] start up successful
_06 account
Unsuccessful
Display
Van_UC Check Lost network message " User have
start up
_07 database Lost account
netwwork"
1. Click
[Đăng nhâp] Display
Van_UC Check Wrong 2. Input message User have
_08 information account wrong "wrong account
information information"
account
1. Click
Display
[Đăng nhâp]
message
Van_UC Check Input not 2. Input Input User have
"please
_09 enough field [Đăng kí] not enough account
input this
field [Đăng
field"
kí]

1. Click
Display
[Đăng nhâp]
message "
2. Input
Van_UC Check Input enough Cancel User have
enough field
_10 field but click [Hủy] successful" account
[Đăng kí]
and save
3. Click
unsuccessful
[Hủy]
1. Click [Đợt Display
thi đua] message
Van_UC Check [Đợt thi đua ] 2. Delete[Đợt "Have not User have
_11 deleted thi đua] anything account
3.Clik [Đăng [Đợt thi
kí] đua]"
thi đua] message
Van_UC Check Have not [Đợt 2. Click "Have not User have
_12 thi đua] [Đăng kí] anything account
[Đợt thi
đua]"
1. Click [Đợt
thi đua]
2. Click Display
Check Not click list
[Đăng kí] message
Van_UC [Danh sách cá nhân] User have
3. Click [Cá "Please
_13 click input [Quyết account
nhân] click
định khen thƣởng]
4. Input personal "
[Quyết định
khen thƣởng]

Van_UC Check [Tra cứu] thi đua] message User have
_14 information deleted 2. Delete [Đợt "wrong account
thi đua] information"
3. [Tra cứu]

3.3.6. Testcase kiểm thử Giao diện
Bảng 3-8 Testcase Giao diện
Interface Interface
1. Click interface Giao diện đẹp , màu
chung sắc hợp mắt , bố tri
Van_UI_01 Giao diện chung 2. Click login logic đẹp mắt,đồng
Admin nhất,font =13,style:
3. Click Account time new roman
Vừa, không quá to or
nhỏ, màu sắc ổn, độ
Van_UI_02 Check box,button start up
dài kítự đúng với tiêu
chuẩn
Thuộc list đƣợc phân
Van_UI_03 Phân trang start up
trang
Check [Ngày Ngày tháng hiển thị
Van_UI_04 start up
/tháng] field đúng yêu cầu
Van_UI_05 Check [số] number start up
Vừa, không quá to or
nhỏ, màu sắc ổn, độ
Van_UI_06 Check [text/email] start up
dài kítự đúng với tiêu
chuẩn
Đúng chức năng tiếp
Van_UI_06 Continue button start up
theo
Van_UI_07 Ngôn từ start up Tế nhị, đúng chính tả

3.4 Thực thi test và báo cáo kết quả.
TEST REPORT
Project Nguyễn Thị Vân
Name thi đua khen thưởng Creator
Project
Code thi đua khen thưởng Reviewer/Approver
Document
Code Issue Date
No Module code Pass Fail Untested N/A Number of test cases

1 0 78 5 19 0 102
Sub total 78 5 19 0 102
Test coverage 81.37 %

Test successful coverage 76.47 %
Bảng 3-11 Bảng báo cáo

Kết luận và kiến nghị

Kiểm thử phần mềm hiện này vẫn là vấn đề hết sức quan trọng với các tổ chức
phát triển phần mềm. Trong khuôn khổ đồ án của mình do thời gian và kinh nghiệm còn
hạn chế nên có những phần của đồ án chƣa đƣợc đào sâu nghiên cứu.
Sau một thời gian thực hiện đồ án, dƣới sự hƣớng dẫn của ..., đồ án của em đã thực hiện
tốt các mục tiêu đề ra và đạt đƣợc kết quả nhƣ sau:
1. Kết luận
a. Kết quả đạt đƣợc:
Đồ án đã hoàn thành đƣợc mục tiêu đề ra bao gồm việc nghiên cứu tổng quan về
kiểm thử phần mềm, đi sâu vào phân tích các kỹ thuật kiểm thử hộp đen, tại mỗi kỹ
thuật đã đƣa ra đƣợc các vídụ cụ thể về việc vận dụng kỹ thuật đó ra nhƣ thế nào. Cuối
cùng, kết hợp các kỹ thuật phù hợp với từng chức năng sản phẩm và tài liệu đặc tả về
yêu cầu phần mềm để hình hành nên bộ testcase kiểm thử cho một chức năng phần mềm
Thi đua khen thƣởng.
Để hoàn thành đƣợc đồ án em đã trải qua thời gian học tập, nghiên cứu tài liệu
(tiếng Anh, tiếng Việt, tài liệu online) và áp dụng trên sản phẩm thực tế với vai trò sinh
viên thực tập trong thời gian 3 tháng tại Công ty cổ phẩn đầu tƣ và phát triển Tâm Việt.
Trong quá trình thực tập làm đồ án em đã chủ động tham gia vào dự án của công ty,
nghiên cứu tài liệu sản phẩm và trao đổi với các anh chị trong phòng kiểm thử và lập
trình để hiểu chính xác, chặt chẽ về sản phẩm và áp dụng vào đồ án.
b. Hạn chế của đồ án:

Phần mềm thi đua khen thƣởng là bản quyền của công ty nơi sinh viên đã đăng ký
thực tập, sinh viên chỉ đƣợc tiến hành kiểm thử tại công ty do đó để khái quát sản phẩm
và tổng hợp kết quả kiểm thử sinh viên chỉ có thể thông qua hình ảnh của sản phẩm với
tài khoản đƣợc cấp riêng phục vụ cho quá trình quản lý lỗi. Cũng bởi vậy mà việc phản
ánh nội dung chƣơng trình chƣa thực sự đƣợc chi tiết.
Mặc dù đã cố gắng hết sức trong thời gian thực hiện đề tài nhƣng với kinh
nghiệm còn hạn chế nên đồ án không tránh khỏi những thiếu sót:
- Mới tập trung nghiên cứu kiểm thử hộp đen trên website
- Nghiên cứu thêm về kiểm thử giao diện
- Chƣa nghiên cứu phần test hiệu năng
- Chƣa nghiên cứu sâu test bảo mật, tƣơng thích.
c. Kết luận chung:
Đồ án đã hoàn thành mục tiêu:

- Trình bày tổng quan về phần mềm, công nghệ phần mềm, lỗi phần mềm và
các vấn đề liên quan đến kiểm thử phần mềm.
- Giới thiệu kiểm thử hộp đen.
- Tổng quan về kiểm thử hộp đen
- Nắm đƣợc kiến thức cơ bản nhất về kiểm thử phần mềm, những mặt còn hạn
chế của công việc kiểm thử.
- Nắm đƣợc các mức độ trong kiểm thử, các chiến lƣợc của kiểm thử và đặc
biệt là những kỹ thuật kiểm thử.
- Á p dụng các kiến thức đã nghiên cứu thƣc hiện kiểm thử các chức năng cơ
bản của ứng dụng website Thi đua khen thƣởng.
- Đồ án là một tài liệu súc tích tổng hợp đƣợc các vấn đề chính của kiểm thử
phần mềm nói riêng và cũng có thể coi là tài liệu hƣớng dẫn sử dụng kiểm thử
hộp đen.
2. Hƣớng phát triển của đề tài:

Trong thời gian tới em sẽ tiếp tục nghiên cứu sâu hơn về các vấn đề của kiểm thử
phần mềm, và đặc biệt áp dụng kiểm thử hộp đen, để có thể vận dụng vào kiểm thử các
ứng dụng lớn hơn trong thực tế công việc trong tƣơng lai nhằm góp một phần nhỏ bé
vào công cuộc chuyên nghiệp hóa kiểm thử phần mềm ở Việt Nam.
Khi nghiên cứu về kiểm thử phần mềm nói chung và kiểm thử hộp đen nói riêng, em đã
hiểu đƣợc kiểm thử rất quan trọng trong quá trình sản xuất phần mềm, đảm bảo chất
lƣợng phần mềm. Sự áp dụng với kiến thức tìm hiểu đƣợc mới chỉ dừng lại ở một hệ
thống nhỏ. Hƣớng phát triển tiếp theo của nhóm em trong tƣơng lai là:
 Thực hiện kiểm thử trên mô hình phần mềm rộng hơn, phức tạp hơn.
 Tìm hiểu và nghiên cứu thêm về các công cụ kiểm thử tự động, kiểm thử bảo
mật, kiểm thử hộp trắng, tƣơng thích, kiểm thử cơ sở dữ liệu…

TÀI LIỆU THAM KHẢO

Các tài liệu Tiếng Việt
[1]. Trƣơng Anh Hoàng, Phạm Ngọc Hùng, Đặng Văn Hƣng. Giáo trình kiểm thử phần
mềm, Đại học Công nghệ - Đại học Quốc gia Hà Nội. Hà Nội, tháng 11 năm 2013.
[2]. Thạc Bình Cƣờng. Bài giảng điện tử môn học Kiểm thử và bảo đảm chất lƣợng
phần mềm. Khoa CNTT – Trƣờng đại học Bách khoa Hà Nội.
Các tài liệu Tiếng Anh
[3]. Dorothy Graham, Erik Van Veenendaal, Isabel Evans, Rex Black.
Foundations_of_Software_TestingISTQB Certification, 2012
[4]. Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software Testing. A
Context-Driven Approach, John Wiley & Sons, 2001.
[5]. Thomas Muller, Debra Friedenberg. International Software Testing Qualifications
Board. ISTQP Foundation Level Syllabus, 2011.
Các tài liệu từ Internet
[6]. Kiểm thử phần mềm, Wikipedia, https://goo.gl/Xko3nn
[7]. Software-Testing-and-Quality-Assurance_group-55, https://goo.gl/ShMH8U
[8]. Tìm hiểu về các loại kiểm thử phần mềm, https://goo.gl/PwTPyh
[9]. Pairwise testing in the real world, https://goo.gl/oO36Cp
[10]. Functional Testing Simplified, http://goo.gl/ngygUJ

[11]. Black box testing, http://goo.gl/wUS6Fi
[12]. How to design test cases using state transition testing technique?,
http://goo.gl/s89bxa
[13]. Black box-Documents, http://goo.gl/rwMaJa.
[14]. The Test Management Guide – A to Z and FAQs, http://goo.gl/Vi97YB

(123doc) Nghien Cuu Va Ung Dung Ky Thuat Kiem Thu Hop Den Trong Kiem Thu Website Thi Dua Khen TH Ong

Uploaded by

Document Information

Original Title

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

(123doc) Nghien Cuu Va Ung Dung Ky Thuat Kiem Thu Hop Den Trong Kiem Thu Website Thi Dua Khen TH Ong

Uploaded by

Copyright:

Available Formats

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT HÀ NỘI

NGUYỄN THỊ VÂN

TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT

SINH VIÊN THỰC HIỆN GIÁO VIÊN HƢỚNG DẪN

NGUYỄN THỊ VÂN ThS. NGUYỄN TUẤN ANH

Nguyễn Thị Vân 3 Lớp Tin Trắc Địa K57

Nguyễn Thị Vân 4 Lớp Tin Trắc Địa K57

Nguyễn Thị Vân 5 Lớp Tin Trắc Địa K57

DANH MỤC CÁC HÌ

Hình 1-2. Sơ đồ nhân lực kiểm thử phần mềm............................................................... 22

Hình 1- 3. Xây dựng kế hoạch kiểm thử ....................................................................... 23

Hình1- 4. Sơ đồ các cấp độ kiểm thử .............................................................................26

Hình 2-2. Giao diện đăng nhập hệ thống. ...................................................................... 36

Hình 2-3. Cấu trúc bảng quyết định .............................................................................. 38

Hình 2-4. Giao diện PictMaster Tool............................................................................. 44

Hình 3-2. Biểu đồ quản lý testcase ...............................................................................54

Hình 3-4. Màn hình chức năng đăng kí ......................................... .............................. 64

Hình 3-5. Màn hình quản lý đợt thi đua ........................................................................ 66

Hình 3-6. Màn hình quản lý hồ sơ ................................................................................. 75

Nguyễn Thị Vân 6 Lớp Tin Trắc Địa K57

DANH MỤC CÁC BẢNG BIỂU

Bảng 1-1. Kiểm thử giao diện ngƣời sử dụng ................................................................30

Bảng 3-1. Bảng thiết kế quy trình kiểm thử.................................................................. 58

Bảng 3-4. Testcase đăng kí thi đua .............................................................................. 66

Bảng 3-5. Testcase đợt thi đua .......................................................................................68

Bảng 3-6. Testcase quản lý hồ sơ ................................................................................. 76

Bảng 3-7. Testcase giao diện ....................................................................................... 78

Bảng 3-8. Mô tả use case ...............................................................................................82

Bảng 3-9. Testcase sử dụng kỹ thuật use case .................................................. .......... 82

Bảng 3-10. Bảng báo cáo .............................................................................................. 85

Nguyễn Thị Vân 7 Lớp Tin Trắc Địa K57

KÝ HIỆU THUẬT NGỮ

Ký hiệu/ Thuật ngữ Ý nghĩa

Static testing Kiểm thử tĩnh

Dynamic testing Kiểm thử động

Blackbox Testting Kiểm thử hộp đen

White box testing Kiểm thử hộp trắng

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

Intergration Tests Câu hỏi và trả lời

System Tests Kiểm thử hệ thống

Acceptance Tests Kiểm thử chấp nhận

Test case Trƣờng hợp kiểm thử

Test script Tập hợp các trƣờng hợp kiểm thử

Selenium RC Selenium Remote Control

Test Manager Ngƣời quản lí kiểm thử

Test Leader Quản lí nhóm kiểm thử

Test Analyst Phân tích kiểm thử

Test Designer Thiết kế kiểm thử

Test Executing Thi hành kiểm thử

Nguyễn Thị Vân 8 Lớp Tin Trắc Địa K57

Test Report Báo cáo kiểm thử

QC team Đội kiểm tra chất lƣợng

Developers Lập trình viên

Customer Khách hàng

Test Analyst Phân tích kiểm thử

Test Designer Thiết kế kiểm thử

Project Leader Quản lí dự án

API Application Programming Interface

Nguyễn Thị Vân 9 Lớp Tin Trắc Địa K57

Nguyễn Thị Vân 10 Lớp Tin Trắc Địa K57

THÔNG TIN NGHIÊN CỨU

3. Nội dung chính