Tìm hiểu về kỹ thuật Kiểm thử phần mềm

1. TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
BÀI TẬP LỚN
KỸ THUẬT PHẦN MỀM
Nội dung : Tìm hiểu về kỹ thuật Kiểm thử phần mềm
Giáo viên hướng dẫn TS. Vũ Thị Hương Giang
Sinh viên thực hiện :
1. Nguyễn Lan Anh - 20080063
2. Bùi Văn Trường - 20082818
3. Ngô Đăng Trung - 20082780
Lớp : Công nghệ phần mềm K53
HÀ NỘI 10 – 2011

2. Mục lục
Lời nói đầu.........................................................................................................................................4
PHẦN I: TỔNG QUAN LÝ THUYẾT KIỂM THỬ..............................................................................5
I. GIỚI THIỆU......................................................................................................................5
1. Vòng đời kiểm thử..............................................................................................................5
2. Các tiêu chí đánh gíá kiểm thử.............................................................................................5
3. Mô hình phát triển chữ V ....................................................................................................6
II. KIỂM THỬ UNIT..............................................................................................................7
1. Tiến trình kiểm thử Unit......................................................................................................7
a. Kế hoạch kiểm thử Unit ............................................................................................ 7
b. Thiết kế kiểm thử ...................................................................................................... 7
c. Thực hiện và đánh giá kiểm thử unit ........................................................................ 8
2. Kế hoạch kiểm thử unit .......................................................................................................8
3. Kiểm thử hộp đen...............................................................................................................9
4. Kiểm thử hộp trắng.............................................................................................................9
a. KIểm thử nhánh cơ bản (Basis Path Testing) ......................................................... 10
5. Các trường hợp kiểm thử và dữ liệu kiểm thử .....................................................................12
III. KIỂM THỬ TÍCH HỢP....................................................................................................13
1. Tạo dữ liệu và file kiểm thử...............................................................................................13
2. Các chiến thuật và kĩ nghệ kiểm thử .......................................................................................13
a. Kiểm thử tích hợp không tăng tiến.............................................................................. 13
b. Kiểm thử tích hợp tăng tiến .................................................................................... 14
Kiểm thử Sandwich........................................................................................................... 16
c. Tiêu chí để hoàn thành............................................................................................ 16
d. Các lời bình về kiểm thử môđun............................................................................. 16
e. Đề nghị phương pháp luận kiểm thử tích hợp ........................................................ 17
IV. KIỂM THỬ HỆ THỐNG..................................................................................................17
V. KIỂM THỬ XÁC NHẬN .................................................................................................18
VI. KIỂM THỬ HỔI QUY .....................................................................................................18
VII. LỖI DỮ LIỆU................................................................................................................19
1. Vòng đời của lỗi...............................................................................................................19
2. Lỗi dữ liệu .......................................................................................................................20
3. Dạng của lỗi.....................................................................................................................22
4. Lỗi nguy hại.....................................................................................................................24
5. Trạng thái lỗi....................................................................................................................24
6. Xử lý nguồn gốc ...............................................................................................................25

3. 7. Ưu tiên lỗi........................................................................................................................27
PHẦN II: PHƯƠNG PHÁP KIỂM THỬ GAME................................................................................28
I. GIỚI THIỆU TỔNG QUAN .............................................................................................28
II. KIỂM THỬ CHIẾN LƯỢC ..............................................................................................28
1. Mục tiêu và định nghĩa............................................................................................ 28
2. Lập bảng kế hoạch và các yêu cầu kiểm thử - Testing plan and Testing
requirement ....................................................................................................................... 30
3. Kiểm thử game và công nghệ kiểm thử - Game testing and testing technique....... 31
a. Các thành phần và cấu trúc chi tiết của game ..................................................... 31
b. GAME TESTING TECHNIQUES AND “TIPS-N-HINTS”.............................. 33
c. SPECIAL CONSIDERATIONS FOR GAME TESTING.................................. 35
4. Test plan development for game testing ................................................................. 35
5. Software testing and testing techniques.................................................................. 36
6. Testing considerations for software testing......................................................... 38
7. Kiểm thử toàn chu trình .......................................................................................... 39
PHẦN III: QUY TRÌNH KIỂM THỬ TRONG CÔNG NGHIỆP ...................................................40
I. GIỚI THIỆU VỀ CÔNG TY.............................................................................................40
PHẦN IV: VẬN DỤNG VÀO VIỆC KIỂM THỬ GAME CỜ TƯỚNG..............................................47
I. TỔNG QUAN HỆ THỐNG VÀ MODULE KIỂM THỬ.....................................................47
1. Mô tả bài toán ......................................................................................................... 47
2. Mô tả hệ thống ........................................................................................................ 47
3. Các thành phần chính.............................................................................................. 48
4. Mô hình thiết kế tổng thể ........................................................................................ 49
II. TIẾN HÀNH KIỂM THỬ.................................................................................................57
1. Mục đích ................................................................................................................ 57
2. Yêu cầu giao diện.................................................................................................... 57
3. Tình huống kiểm thử và kết quả ............................................................................. 58
PHÂN CÔNG CÔNG VIỆC TRONG NHÓM....................................................................................62
PHẦN IV: TỔNG KẾT.....................................................................................................................63
Các tài liệu tham khảo.......................................................................................................................64

4. Lời nói đầu
Nói đến công nghệ phần mềm là nói đến quá trình, công cụ và các chiến
lược xây dựng một cách hiệu quả một hệ thống phần mềm. Hiện nay, quá trình xây
dựng phần mềm không đơn giản chỉ là ngồi viết mã nguồn rồi đem bán. Mà cả giai
đoạn phía sau mới thực sự chiếm rất nhiều công sức của người làm phần mềm, đó
là quá trình kiểm thử và bảo trì phần mềm.
Trong vòng đời phát triển phần mềm thường có các giai đoạn là nghiên cứu
sơ bộ, phân tích yêu cầu, thiết kế, cài đặt, kiểm thử và bảo trì phần mềm. Cụ thể
hơn, thì hai giai đoạn đầu là đặt vấn đề và phân tích các yêu cầu của hệ thống, giai
đoạn tiếp theo là quá trình xây dựng trên lý thuyết các modul, các thành phần cần
có của phần mềm, giai đoạn tiếp nữa là đi hiện thực hóa các lý thuyết đó. Hai giai
đoạn cuối luôn yêu cầu sự chuẩn xác và rõ ràng của các giai đoạn trên, để có thể
làm việc dễ dàng.
Theo IEEE thì tổng quan về kiểm thử phần mềm là như sau:
Kiểm thử là một hoạt động thực hiện để đánh giá chất lượng sản phẩm, để cải thiện
nó, bằng cách định ra các nhược điểm và vấn đề của nó. Kiểm thử bao gồm các xác
minh về sự đáp ứng của phần mềm trước một tập các test case, được lựa chọn phù
hợp từ các modul thực thi phổ biến của phần mềm, so sánh với các đáp ứng đáng
mong đợi.
Chúng em chọn đề tài Tìm hiểu về các kỹ thuật kiểm thử phần mềm để làm
bài tập lớn môn học Kỹ thuật phần mềm nhằm mục đích tìm hiểu về các kỹ thuật
kiểm thử, các kỹ thuật kiểm thử tại công ty trên thực tế. Tuy đã cố gắng hết sức
nhưng còn nhiều sai sót, mong cô góp ý để chúng em hoàn thiện hơn bài tập lớn
của mình!

5. PHẦN I: TỔNG QUAN LÝ THUYẾT KIỂM THỬ
I. GIỚI THIỆU
1. Vòng đời kiểm thử
Vòng đời của kiểm thử bắt đầu từ việc lập kế hoạch kiểm thử. Sau đó là ghi
ra các ý tưởng các trường hợp kiểm thử. Từ các trường hợp kiểm thử này đưa ra tất
cả các trường hợp kiểm thử và các kịch bản kiểm thử. Sử dụng các thủ tục/ hay
kịch bản kiêm rthử này, tester có thể phác hoạ toàn bộ kiểm thử hệ thống/ kiểm thử
tích hợp. Kết quả kiểm thử sẽ được đánh giá bởi các tiêu chí kiểm thử đặt ra ban
đầu. Mô hình kiểm thử là một dãy các kế hoạch, các trường hợp kiểm thử và các
thủ tục kiểm thử. Trong tiến trình bảo trì và nâng cấp dự án, thì kiểm thử đóng một
vai trò quan trọng
2. Các tiêu chí đánh gíá kiểm thử
Tiêu chí đánh giá kiểm thử là độ bao phủ và chất lượng của kiểm thử:
 Sự bao phủ của kiểm thử là một tiêu chí quan trọng trong tiến trình kiểm
thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử và các trường hợp
kiểm thử hay toàn bộ đoạn chương trình.
 Chất lượng của kiểm thử là một tiêu chí quan trọng để đánh giá độ tin cậy,
tính hiệu năng, sự ổn định của chương tmrình. Chất lượng của kiểm thử phụ
thuộc vào việc đánh giá, phân tích để phát hiện ra lỗi của chương trình trong
suốt tiến trình kiểm thử.

6. 3. Mô hình phát triển chữ V
Kiểm thử và bảo trì là một pha quan trọng trong quá trình phát triển
phần mềm. Sau đây là mô hình chữ V trong kiểm thử:
The Software Development V-Model
Bên trái chữ V là quá trình phát triển phần mềm, và bên phải là kiểm thử.
Tại mỗi một mức trong tiến trình phát triển thì có một pha kiểm thử tương ứng .
Các mức kiểm thử có thể được lập kế hoạch và thiết kế song song. Sau đó
chúng ta thực hiện kiểm thử từ đáy tháp chữ V nên tương ứng với từng mức phát
triển .
Kế hoạch kiểm thử hệ thống cần phải sớm hơn khi trước khi pha kiểm thử bắt đầu:
 Kế hoạch kiểm thử hệ thống là phải khớp với các yêu cầu phần mềm .

7.  Các trường hợp kiểm thử cần phải hoàn thành khi mà các thiết kế chi tiết đã
xong.
 Kiểm thử hệ thống bắt đầu từ ngay sau khi lập trình .
II. KIỂM THỬ UNIT
Kiểm thử unit ứng dụng ở mức môđun. Thường là được thực hiện bới nhà
phát triển trước khi các môđun được tích hợp với các mô đun khác .
Kiểm thử unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng
phương pháp kiểm thử hộp trắng .
Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự
án.
1. Tiến trình kiểm thử Unit
a. Kế hoạch kiểm thử Unit
Lập kế hoạch cho kiểm thử khác nhau (như kiểm thử hệ thống, kiểm thử tích
hợp). Quyết định xem dặc điểm nào cần phải kiểm thử. Các hướng tiếp cận để
kiểm thử unit
 Phương thức phân tích kiểm thử.
 Kĩ thuật kiểm thử (hộp đen hay hộp trắng).
 Các công cụ dùng trong kiểm thử.
b. Thiết kế kiểm thử
 Tạo các trường hợp kiểm thử
 Thiết kế các thủ tục kiểm thử:

8.  Thủ tục làm thế nào để thực thi một trường hợp kiểm thử
 Một thủ tục có thể áp dụng cho một vài trường hợp kiểm thử khác
 Triển khai chương trình kiểm thử:
 Kiểm thử gốc(stub): Kiểm thử lần lượt từ gốc của chương trình, sau
khi xong thì tiếp tục kiểm thử Stub tiếp theo ở bên dưới.
 Kiểm thử driver : Driver là một trình điều khiển kiểm thử unit .
c. Thực hiện và đánh giá kiểm thử unit
 Chuẩn bị kiểm thử môi trường.
 Thực hiện kiểm thử unit.
 Phát hiện ra lỗi trong kiểm thử unit.
 Làm báo cáo ghi lại toàn bộ sự thành công hay thất bại trong từng
unit một dựa theo các kết quả yêu cầu.
2. Kế hoạch kiểm thử unit
Để thực hiện một kiểm thử có hiệu quả, thì cần thiết phải có một kế hoạch
kiểm thử có hiệu quả. Cần phải lập kế hoạch thật chi tiết, càng chi tiết càng tốt.
Kế hoạch kiểm thử unit cần phải đưa ra các tài liệu chỉ dẫn việc thực hiện
kiểm thử trên từng môđun như thế nào. Mục tiêu là mỗi mô đun sau khi dược kiểm
thử thì phải thoả mãn tất các yêu cầu đặt ra về chức năng
Kế hoạch kiểm thử cần phải đưa ra một danh sách các đầu vào cho môđun
và một danh sách các đầu ra phù hợp với các mô đun đó. Mộ môđun dược gọi là
đạt nếu tất cả các đầu vào đều có đầu ra tương ứng. Mỗi một sự sai trệch nào của
đầu ra đều phải cần xem xét cụ thể. Danh sách các đầu vào phải thoả mãn yêu cầu
của phần mềm, tối thiểu là lần đầu tiên. Kế hoạch kiểm thử giúp cho các nhà phát

9. triển có thể đảm bảo chắc chắn rằng mỗi dòng mà, và mỗi câu lệnh điều kiện đều
phải thực hiện được tối thiểu một lần
3. Kiểm thử hộp đen
 Hướng vào các đặc tả bên ngoài
 Chủ yếu là kiểm tra giao diện của các hàm vào ra
 Các kỹ thuật thường dùng:
Lược đồ nguyên nhân kết quả.
Phân đoạn tương đương.
Phân tích giá trị biên.
4. Kiểm thử hộp trắng
 Thực hiện bên trong chương trình.
 Sử dụng các đặc tả chi tiết.
 Bao gồm các thứ sau:.
Các chỉ dẫn bao quát.
Bao quát toàn bộ các câu lệnh điều kiện đơn.
Các điều kiện, đa điều kiện.
Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúc của thiết kế chi tiêt.
Sử dụng thiết kế chi tiết người sử dụng có thể đảm bảo rằng:
 Bảo đảm rằng tất cả các đường dẫn độc lập ở bên trong môđun đều được thử
tối thiểu một lần.
 Thử nghiệm tất các các trường hợp lôgic trong các câu lệnh điều kiện.
 Thực hiện tất cá các vòng lặp tới giá trị biên của chúng.
 Thử nghiệm tất cả các giá trị biên bên trong đảm bảo chúng hợp lệ.

10. a. KIểm thử nhánh cơ bản (Basis Path Testing)
Là một cách kiểm thử hộp trắng. Trường hợp kiểm thử bắt nguồn từ các đặc
tả yêu cầu độc lập. Một tập các trường hợp kiểm thử có thể được phát sinh bởi các
tập kiểm thử cơ bản.
Đây là một cái tên đến từ thực tế rằng các kiểm thử nầy đều kiểm thử từ tất
cả các hướng có thể thông qua chương trình.
Tóm tắt Basis Path Testing
Bước 1
Vẽ biểu đồ luồng chương tình cho một đoạn mã được lựa chọn nào đó
If -then - else loop - while case - of
 Thực hiện từng câu lệnh một.
 Bỏ qua các dòng lệnh liên tục.
 Thêm một nút cho mỗi một nhánh hay câu lệnh quyết định.
 Triển khai các nút phù hợp với sự thể hiện của nó.
Bước 2

11. Độ phức tạp tính toán từ lưu đồ luồng tính như sau
C = # Edges - # Nodes + 1
Bước 3
Tìm C cho mỗi trường hợp kiểm thử
 Chọn một trường hợp kiểm thử để bắt đầu.
 Trường hợp sau giống cái đầu chỉ thay đổi một sô thông số cho phù
hợp thôi.
 Tiếp tục cho đên 'C' xuất phát.
Bước 4
Thu được các kết quả dự đoán cho mỗi trường hợp kiểm thử
 Sử dụng các đặc tả của chương trình dể quyết định xem loại dữ liệu
nào nên làm(tốt nhất là việc này nên làm bởi các nhà phân tích)
Bước 5
Confirm that actual results match expected results
So sánh kết quả giữa thực tế và lí thuyết
 Thực hiện đi bộ qua chương trình
Hiệu quả của kiểm thử nhánh cơ bản ( Basis Path Testing )
Hiệu quả
 Bao phủ hầu hết toàn bộ các vấn đề.
 Sẽ phát hiện ra hầu hết các lỗi.

12.  Hầu hết các loại lỗi.
 Là một phương tiện hay để xem lại toàn bộ mã nguồn và đi bộ qua
giải thuật.
 Có thể ứng dụng cho các mức lôgic cao hơn hay các đoạn mã giả.
Hiệu lực
 Là một qui trình xác định tốt.
 Hiệu quả trong việc sử dụng tài nguyên máy và thời gian thiết kế.
 Phát sinh đơn giản và dễ thực thi các trường hợp kiểm thử.
 Giá cả thì chấp nhận được trong thương mại.

5. Các trường hợp kiểm thử và dữ liệu kiểm thử
 Kiểm tra các toán tử ở mức giá trị thông thường.
 Kiểm tra với các giá trị giới hạn.
 Kiểm tra ngoài vùng giá trị.
 Kiểm tra các lỗi ở trong vòng lặp.
 Kiểm tra các kết thúc không bình thường trong vòng lặp.
 Kiểm tra các kết thúc không bình thường trong đệ quy.
 Kiểm tra tất các các cấu trúc dữ liệu được truy nhập bởi hàm.
 Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên.
 Kiểm tra tất cả các lỗi điều kiện.
 Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết.
 Đảm bảo rằng mọi câu lệnh đều được thực hiện.
 Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả các
nhánh.

13. III. KIỂM THỬ TÍCH HỢP
1. Tạo dữ liệu và file kiểm thử
Các hoạt động chính:
 Xác định nội dung của kiểm thử dữ liệu và file.
 Tạo dữ liệu kiểm thử, dữ liệu kiểm thử có thể tạo ra bằng một trong
các phương pháp luận sau.
 Vào thủ công.
 Phần mềm sinh dữ liệu kiểm thử.
 Giúp ra từ cơ sở dữ liệu sống.
 Điền đầy các dữ liệu kiểm thử với sự giúp đỡ của các chương trình
quản lí cơ sở dữ liệu.
 Kiểm tra xem có khớp với các yêu cầu đặt ra không
2. Các chiến thuật và kĩ nghệ kiểm thử
a. Kiểm thử tích hợp không tăng tiến
Big Bang là một kiểm thử tích hợp không tăng tiến
 Tất cả các mô đun đều được phối hợp ngay từ đầu.
 Phần mềm được kiểm thử toàn bộ - kết quả ban đầu thường là lộn
xộn.
 Để đúng được là rất khó vì một dãy các lỗi gặp phải.
 Khi một lỗi được sửa thì lại bắt gặp một lỗi khác chỉ cho tới khi nào
vòng lặp dừng thì thôi.
Cho nên phương pháp này không được đề nghị

14. b. Kiểm thử tích hợp tăng tiến
Là một kiểm thử trái ngược lại với kiểm thử Big Bang
 Phần mềm được xây dựng và kiểm thử từng đoạn một.
 Lỗi dễ bị cô lập và xử lí.
 Giao diện dễ kiểm thử hơn và có thể áp dụng kiểm thử hệ thống.
 Kiểm thử tích hợp hệ thống bao gồm các phương pháp luận sau:
 Kiểm thử tích hợp Top-Down.
 Kiểm thử tích hợp Bottom-up.
 Kiểm thử Sandwich.
Kiểm thử tích hợp Top-Down:
 Hàm Main là nút gốc còn tất cả cá môđun ở bên dươic là các gốc
con(bới vì sau khi kiểm thử xong nút gốc này thì tất cả cá nút gốc
con sẽ được kiểm thử).
 Stubs are replaced with actual modules one at a time, depending on
the integration approach selected (depth/breadth first).
 Nút gốc sẽ được thay thế bằng các môđun cụ thể, phụ thuộc vào
hướng kiểm thử tích hợp được lựa chọn.
 Cứ tiếp tục quá trình như vậy cho đến khi nào kết thúc chương trình
thì thôi.
Thuật tiện
 Không cầm có driver kiểm thử.
 Lỗi giao diện được phát hiện sớm.
Bất tiện

15.  Cần gốc (stubs).
 Làm chậm tiến trình kiểm thử.
 Lỗi ở trong các môđun ở mức thấp khó tìm ra.
Chú thích
 Chương trình làm việc đầu tiên nâng lên tinh thần.
 Rất khó để có thế duy trì thuần top-down trong thực tế.
Tích hợp Bottom-Up
 Mô đun ở mức thấp nhất sẽ được kiểm thử đầu tiên
 Mỗi một driver được viết để theo dõi các đầu vào và đầu ra
 Kiểm thử từng khối
 Driver sẽ bị xoá đi và các cụm sẽ được kết hợp lại, sau đó di chuyển
nên trên trong cấu trúc chương trình
Thuận tiện
 Không cần đến gốc
 Rất dễ điều chỉnh số lượng người cần thiết
 Lỗi quyết định sớm được tìm thấy
Sự bất tiện
 Các driver kiểm thử là cần thiết
 Rất nhiều môđun phải được tích hợp trước khi làm việc
 Lỗi giao diện khám phá muộn

16. Chú thích
 Phải kiểm tra nhiều các đoạn mã hơn là so với Top-Down
 Bottom-up là một cách mang tính trực giác nhiều hơn
Kiểm thử Sandwich
Là một phương pháp kiểm thử kết hợp cả top-down và bottom-up
 Tất cả các môđun và giao diện đều phải kiểm thử bằng phương pháp
Top-Down
 Cả driver và stub đều được sử dụng khi cần thiết
 Tất cả các môđun đều được xây dựng và kiểm thử unit bắt đầu từ
mức thấp nhất, sử dụng chiến thuật Bottom-Up
c. Tiêu chí để hoàn thành
Một tester phải biết khi nào kiểm thử là đủ. Kiểm thử có thể dừng khi:
 Nó không phát sinh lỗi
 Nó đã bao phủ gần như hoàn toàn
 Nó phát hiện ra một số lượng lỗi
 Kế hoạch kiểm thử kết thúc
d. Các lời bình về kiểm thử môđun
 Đúng với các yêu cầu phần mềm
 Có mức điều khiển cao
 Có phức tạp hay ẩn chứa lỗi hay không

17.  Có các yêu cầu hiệu năng xác định hay không
Các bình luận nên càng sớm càng tốt
e. Đề nghị phương pháp luận kiểm thử tích hợp
 Lựa chọn một nhóm các môđun không quá phức tạp để kiểm thử.
 Kết nối các nhóm môđun vào chương trình.
 Kiểm thử tích hợp trên bộ khung của hệ thống.
 Thử nghiệm tất cả các môđun.
 Thử nghiệm tất cả các lựa chọn của chương trình với các tiện ích
của nó.
 Thực thi kiểm thử trên bộ khung của chương trình.
 Nạp kiểm thử.
 Kiểm thử hiệu năng của chương trình.
 Cố gắng phá vỡ bộ khung.
 Lặp lại bốn bước trên nhiều lầm nếu thấy cần thiết để xây dựng một
mức hoàn chỉnh.
IV. KIỂM THỬ HỆ THỐNG
Mỗi lần kiểm thử thủ tục hỗ trợ kiểm thử hệ thống được thực hiện, đội kiểm
thử so sánh kết quả mong đợi của mỗi kiểm thử thủ tục với kết quả thực tế. Nếu kết
quả thực tế khác so với kết quả mong đợi, sự khác nhau này phải được xem xét lại
kỹ hơn.
Kiểm thử hệ thống thường thực hiện sau tất cả các môđun, kiểm thử tích hợp
và kiểm thử unit được chấp nhận một cách thành công.
Đội kiểm thử cần có thể tái tạo lại vấn đề và phải chắc chắn là vấn đề này
không phải gây ra do lỗi kiểm thử, lỗi thiết lập môi trường, lỗi thủ tục kiểm thử,

18. hay lỗi kiểm thử kịch bản. Nếu báo cáo lỗi bởi vì những lỗi được xác định trong lỗi
kiểm thử, lỗi thiết lập môi trường, lỗi kiểm thử thủ tục, hay lỗi kiểm thử kịch bản,
hành động thích hợp để hiệu chỉnh nên được thực hiện và thực hiện lại kiểm thử.
Nhược điểm của sản phẩm nên được ghi lại trong DMS.
V. KIỂM THỬ XÁC NHẬN
Kiểm thử kiểm nhận chứng minh cho khách hàng rằng tiêu chuẩn kiểm nhận xác
định trước đã được xác định bởi hệ thống.
Điển hình nó được sử dụng như một kỹ thuật để bàn giao hệ thống.
VI. KIỂM THỬ HỔI QUY
Thực hiện kiểm thử hồi quy thông thường mất rất nhiều nỗ lực cố gắng. Vì thế,
kiểm thử hồi quy có thể được thực hiện sau một giai đoạn. Tuy nhiên, kiểm thử hồi
quy phải được thực hiện khi:
 Tổng số những yêu cầu thay đổi xảy ra từ bản cơ sở cuối cùng với kiểm
thử hồi quy lớn hơn 10% tổng số những yêu cầu trong cơ sở đó.
 Tỉ lệ tổng số lỗi được phát hiện sau kiểm thử kiểm nhận hay trong trong
thao tác chia tổng số man-months của dự án lớn hơn 1.
Với những dự án bảo trì, khởi động cho kiểm thử hồi quy phải được xác định trong
kế hoạch kiểm thử. Leader kiểm thử phải xác định khi nào đội dự án kiểm soát
kiểm thử hồi quy và phạm vi kiểm thử hồi quy. Lập biểu của kiểm thử hồi quy phải
được xác định trong lập biểu của dự án.

19. VII. LỖI DỮ LIỆU
1. Vòng đời của lỗi
Một lỗi trong phần mềm là một cái gì đó mà gây ra cho phần mềm chạy theo cách
mà nó không nhất quán với những yêu cầu hay sự cần thiết của khách hàng hay
những chuẩn liên quan. Để có phần mềm chất lượng cao, sản phẩm cuối cùng nên
có vài lỗi có thể.
 Một lỗi được tìm thấy và phải được ghi lại trong DMS bởi một một
nhân viên. Lỗi được vào trong DMS với trạng thái “Error” và thông tin
khác.
 Lãnh đạo dự án phải xem lại dữ liệu của một lỗi (như là dạng lỗi, nguồn
gốc,tính nguy hại,..), sửa nó và giao cho người sửa lỗi. Thông thường
thành viên được giao là tác giả của văn bản hay đoạn mã nguồn mà lỗi
được tìm thấy trong đó. Trạng thái của lỗi được thay đổi thành
“Assigned”.
 Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành thành “Pending”
 Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhật trạng thái
thành “Tested” nếu lỗi được sửa một cách hài lòng, hay thành “Error”.
 Nếu một lỗi với trạng thái “Error” có thể được chấp nhận mà không có
một hành động hiệu chỉnh nào, lãnh đạo dự án cần đổi trạng thái thành
“Accepted”.
Vòng đời của lỗi được mô hình hoá trong flowchart sau đây:

20. LOG DEFECT
Defect status: ERROR
ASSIGN DEFECT
ASSIGNED
CORRECT DEFECT
Defect status: PENDING
Analyse Defect
ACCEPT DEFECT
ACCEPTED
Retest Defect
CLOSE DEFECT
TESTED
Error
Corrected
Defect status:
Defect status:
Defect status:
Quá trình bắt lỗi
2. Lỗi dữ liệu
Thông tin quan trọng của lỗi của lỗi bao gồm:
# Dữ liệu Mô tả dữ liệu Bắt
buộc/Tuỳ

21. chọn
1 Project Code Dự án hay sản phẩm bị mắc
một lỗi
B
2 Defect ID Tên của lỗi B
3 Title Miêu tả ngắn gọn của lỗi B
4 Description Miêu tả đầy đủ của lỗi B
5 Severity Tính nguy hại của lỗi B
6 Type Phân loại của lỗi B
7 Status Trạng thái hiện tại của lỗi B
8 Stage detected Phạm vi hoạt động của dự án
xác định vòng đời khi lỗi được
phát hiện
T
9 QC activity Hoạt động phát hiện ra lỗi B
10 QC activity type Dạng của hoạt động QC như là
xem lại, kiểm tra.......
B
11 Stage injected Phạm vi hoạt động trong dự án
xác định vòng đời mà từ đó lỗi
được gây ra
T
12 Process origin Tên hay mã nguồn của đoạn
phần mềm mà trong đó lỗi là
nguồn gốc
B
13 Priority Mức ưu tiên sửa lỗi T
14 Creator Người phát hiện lỗi, người
kiểm thử hay người xem lại
B
15 Create date Ngày ghi lại lỗi trong dữ liệu
lỗi
B

22. 16 Assigned to Người chịu trách nhiệm sửa lỗi,
thường là tác giả
T
17 Due date Hạn chót mà việc sửa lỗi phải
hoàn thành
T
18 Work product Trong sản phẩm mà lỗi được
tìm thấy.
B
19 Module Phần của sản phẩm mà lỗi
được tìm thấy trong đó. Nó là
mức CI cao như bình thường.
T
20 Corrective action Hành động để sửa lỗi T
21 Close date Ngày mà lỗi được đóng. B
22 Reference Tài liệu tham khảo hay miêu tả
về lỗi
T
23 History Thông tin về lỗi. Tất cả những
phần như hiệu chỉnh,.....của lỗi
được thể hiện.
T
24 Attached picture Ảnh minh hoạ lỗi T
3. Dạng của lỗi
Sau đây là một số dạng chung của lỗi:
# Dạng lỗi Ví dụ
1 Functionality Chức năng được chỉ ra không làm
việc

23. Requirement
misunderstanding
Những yêu cầu đầu vào không được
hiểu rõ
Feature missing Một phần của đặc tính hay đặc tính
không hoàn thành
Coding logic Kỹ năng kỹ thuật, đánh giá dữ liệu...
hay những lý do khác không được
xác định như là vấn đề viết code
Business logic không theo luồng công việc
2 User Interface Lỗi trong giao diện, bố cục
3 Performance tôc độ xử lý chậm hay lỗi hệ thống
do cấu hình; vấn đề bộ nhớ
4 Design issue Thiết kế được chỉ rõ liên quan vấn
đề
5 Coding standard Vấn đề với chuẩn viết mã nguồn
6 Document Lỗi phát hiện trong khi xem lại văn bản:
Kế hoạch dự án, SRS, Kế hoạch kiểm
thử,… liên quan tới chuẩn văn bản (mẫu,
phiên bản, header/footer,...)
7 Data and Database
Integrity
Vấn đề với xử lý dữ liệu hay luồng dữ
liệu: vào/ra
8 Security and Access
Control
Vấn đề với đặc quyền người dùng,
vấn đề bảo mật
9 Portability Mã nguồn không độc lập với
platform
10 Other không như những dạng trên
11 Tools Lỗi gây ra bởi sử dụng công cụ

24. 4. Lỗi nguy hại
# Dạng nguy hại Giải thích
1 Fatal Lỗi không cho người sử dụng tiếp tục sử
dụng hệ thống, có lẽ hệ thống bị tấn
công
2 Serious Hệ thống không thể làm việc tốt
3 Medium Lỗi này không ngăn người sử dụng xử
lý, nhưng gây ra sự bất tiện
4 Cosmetic Một lỗi mà không có cách nào ảnh
hưởng đến hiệu năng của sản phẩm. Nó
có lẽ là một lỗi ngữ pháp.
5. Trạng thái lỗi
Một lỗi có một vài trạng thái sau đây trong vòng đời của nó:
# Status Description
1 ERROR Lỗi không được sửa hay sửa nhưng
không được hài lòng như mong muốn
2 ASSIGNED Lỗi được xem lại và được giao sửa nó
3 PENDING Lỗi được sửa xong và được kiểm thử lại
4 TESTED Lỗi được sửa một cách hài lòng như

25. mong muốn
5 ACCEPTED Lỗi không được sửa một cách hài lòng
như mong muốn, nhưng nó được chấp
nhận bởi sự nhượng bộ của tác giả hay
khách hàng.
6 CANCELLED Nó không là một lỗi hay lỗi được loại bỏ bởi
những hành động khác với sửa lỗi
6. Xử lý nguồn gốc
Xử lý nguồn gốc là xử lý mà trong nó bị nhiễm lỗi. Xác định rằng những phân tích
yêu cầu của xử lý này là của một lỗi. Nó được đánh giá từ độ tự nhiên của lỗi và
những thông tin khác về lỗi.
# Tên Code Ví dụ lỗi
1 Contract
Management
01-QT Những thủ tục không thích hợp;
những thông tin khách hàng
thiếu; những yêu cầu khách hàng
không hiểu; quản lý thay đổi yêu
cầu khách hàng không chặt chẽ
2 Requirements 02-QT Giả định không đúng; đặc tả giao
diện không hoàn hảo; luồng xử
lý không rõ ràng; yêu cầu không
có đặc tả, nhập nhằng, không
hoàn hảo

26. 3 Design 03-QT Yêu cầu không được thực thi đầy
đủ; lôgic vấn đề; vấn đề liên
quạn đến chuẩn.
4 Coding 04-QT Vấn đề với viết code, logic, xử
lý dữ liệu, vào/ra
5 Deployment 05-QT Sự triển khai kế hoạch không
thích hợp, giải pháp; những vấn
đề môi trường
6 Customer support 06-QT Kế hoạch hỗ trợ không rõ ràng
7 Test 07-QT Sự cố gắng không thích hợp hay
lịch biểu cho kiểm thử; sự không
hoàn hảo của yêu cầu kiểm thử
hay vạch kế hoạch; kiểm thử
case sai; kiểm thử dữ liệu thích
hợp không xác định; tiêu chuẩn
kiểm thử không thích hợp.
8 Configuration
management
08-QT cấu trúc quản lý cấu hình không
thích hợp; những vấn đề trong
đặt tên và quản lý cấu trúc; quản
lý thay đổi trong kế hoạch CM
còn thiếu.
9 Project management 09-QT Nỗ lực hay đánh giá lập biểu
không thích hợp; những vấn đề
trong đánh giá rủi ro; sự không
hoàn hảo của kế hoạch dự án
10 Subcontract 10-QT Lựa chọn nhà thầu phụ không

27. Management thích hợp; quản lý chất lượng
nhà thầu phụ không chặt chẽ
7. Ưu tiên lỗi
PL hay tác giả có thể dựa vào ưu tiên lỗi để sửa nó
# Ưu tiên Miêu tả
1 Immediately Lỗi phải được sửa ngay lập tức
2 High priority Lỗi nên được đưa lên mức chú ý cao
hơn
3 Normal priority
4 Low priority

28. PHẦN II: PHƯƠNG PHÁP KIỂM THỬ GAME
I. GIỚI THIỆU TỔNG QUAN
Để việc kiểm thử có hiệu quả nhất cần có phương pháp kiểm thử và
tiếp cận các vấn đề một cách quy mô và hoàn hảo nhất nhằm nâng cao chất
lượng của sản phẩm. Ngược lại, khi không có phương pháp và cách tiếp cận
đúng sẽ làm kéo dài quá trình kiểm thử gây nên những sự trì hoãn và không
kiểm soát hết các lỗi.
Mục tiêu là đưa ra 1 phương pháp chung cho việc test game để cover
được hết tất cả các thành phần ở các mức độ khác nhau nhằm đảm bảo chất
lượng phần mềm và đưa ra các chiến lược (testing strategy), quy trình
(testing processes), kỹ thuật (techniques), và tiêu chuẩn (test coverage
criteria) cho việc test game, ngoài ra, còn có yêu cầu kiểm thử, kế hoạch
kiểm thử rõ nét, Tài liệu đặc tả và “Kiểm thử toàn chu trình”.
Hiện tại có rất ít các tài liệu cũng như quy định cho việc test game và
các tài liệu hầu hết đều tập chung vào việc đề xuất, đưa ý tưởng để nâng cao
chất lượng các game.
II. KIỂM THỬ CHIẾN LƯỢC
1. Mục tiêu và định nghĩa
Kiểm thử là việc tìm ra các lỗi của game và loại bỏ các lỗi này ra khỏi
chương trình. Có nhiều hình thức test khác nhau với cùng 1 sản phẩm và
được phân loại thành black-box, clear-box(white-box). Mục tiêu của kiểm
thử là kiểm tra tổng thể chương trình (e.g: test planning, test design, testing

29. execution, regression testing and bug reporting) tuy nhiên cần phải chú
ý nhấn mạnh vào khía cạnh khác nhau của trò chơi.
Black-box – Kiểm thử hộp đen: tập trung chủ yếu và việc kiểm thử
chức năng và hiệu năng của trò chơi: test giao diện: menu, menu actions; các
cảm nhận (look and feek): giao diện, các đối tượng và cách thức chơi game
thực tế. Để kiểm thử hộp trắng, tester cần nắm được logic game, và có khả
năng chơi game cũng như những rule cần thiết cho game đó.
Clear-box – Kiểm thử hộp trắng: tập trung vào việc kiểm thử cấu trúc
của game, sự tương thích của game và tính nhất quán trong game: database,
tính tương thích, các thành phần, công cụ: âm thanh, actions.. Đối với clear-
box, tester cần hiểu về code, và các công cụ debug lỗi cũng như môi trường
của dev, đầu vào, đầu ra của các đoạn code.
Kiểm tra chất lượng phần mềm không phải là công việc của một cá
nhân và chất lượng của game hay phần mềm không chỉ phụ thuộc vào tester.
Chất lượng dự án phụ thuộc vào tất cả các thành viên trong nhóm và mỗi
thành viên phải đảm bảo cũng như chịu trách nhiệm cao nhất về chất lượng
công việc mà mình đang làm.
Nguyên tắc của việc kiểm thử game
Quy trình kiểm thử không phải là một quy trình độc lập và không thể
bị tách thành một quy trình độc lập mà phải được coi là một phần không thể
thiếu được của quy trình sản xuất game.
Trên thực tế thì chưa một tester nào có thể hoàn thành 100% công
việc test cho một game. Việc kết hợp giữa đội phát triển và đội test sẽ giảm
thiểu được các rủi ro và cover được hết các lỗi có thể xảy ra với hệ thống.

30. 2. Lập bảng kế hoạch và các yêu cầu kiểm thử - Testing plan and Testing
requirement
a. Tài liệu xác định yêu cầu kiểm thử game
Tài liệu xác định yêu cầu kiểm thử cần đưa ra được những
mục tiêu mà game phải đáp ứng. Và việc kiểm thử game là đảm
bảo chương trình sẽ đáp ứng được các mục tiêu đó. Tester cần phải
hiểu về yêu cầu của game và đưa chúng thành các yêu cầu mục
tiêu, các thuật ngữ và đã được hiện thực hóa bởi các dev.
Khi yêu cầu kiểm thử đã được thông qua, tester base trên đó
để làm tài liệu test plan và testcase. Các test case và test plan sau
khi hoàn thành sẽ được đội dev thông qua để có thể xác định đầu
ra, đầu vào của dữ liệu và các trường hợp break của game.
Tài liệu test TESTING REQUIREMENTS thường được hoàn
thành trong giai đoạn khởi tạo của dự án sau khi đã có tài liệu thiết
kế tổng quan. Tài liệu yêu cầu kiểm thử không chỉ bao gồm yêu
cầu test của game mà sẽ bao gồm tất cả các thành phần của dự án:
(specific features and the major game functionality). Các tài liệu
này sẽ được thông qua bởi người chịu trách nhiệm kỹ thuật của dự
án.
b. Xác định yêu cầu về mốc thời gian thực hiện
Hoàn thành việc test các bug đã được fix, đóng các bug đã
fix. Hoàn tất việc test tất cả các thành phần có liên quan và ảnh

31. hưởng đến chương trình: sự kiện, môi trường, cấp độ, đối tượng,
phiên bản…
Hoàn thành việc test và phải đạt được yêu cầu với 1 số điểm
ngưỡng và các điều lệ cũng như các yêu cầu trong tài liệu yêu cầu
đã được đưa ra bởi nhà sản xuất hoặc PM của dự án.
3. Kiểm thử game và công nghệ kiểm thử - Game testing and testing
technique
a. Các thành phần và cấu trúc chi tiết của game
 Systematic: Kiểm tra hệ thống nghĩa là kiểm tra toàn bộ các
thành phần của game. Bao gồm:
 The menu and the menu functions,
 Art (character model, texture, terrain or world, crowd, objects,
etc.),
 Animation (hình ảnh) (the like and feel of the movement,
realism, frame rate),
 sound and the sound effect (hiệu ứng âm thanh)(in conjunction
with the facial animation, e.g. lip sync, and the animation
sequence)
 music
 camera (cinematic view, zoom in and out, replay),
 game flow and logic,
 world/level/scene
 the player attributes,
 the action attributes

32.  the condition to advance to the next level (what are the rules?)
(các điều kiện trong game, các rule của game)
 the use of environmental objects (các đối tượng trên các môi
trường khác nhau),
 the event/object triggers, and
 the scoring
 progressive levels of difficulty (độ khó ở các cấp độ khác
nhau),
 the game pad: game stream,
 the use of multi-button actions (also called button mashing),
 the ease of use of the button functions,
 the AI logic (logic giao diện) (for both defensive play and
offensive play; player movement and positioning),
 Statistics (thống kê) (pre-game and in-game like player
statistics and high score),
 title screens
 NIS (Non-Interactive Sequence: tương tác màn hình),
 SFX (Special effect: hiệu ứng đặc biệt)
 any movie clip,
 the shock/vibration effect of the game pad: hiệu ứng rung,
chuông…,
 the use of digital and analog mode: chế độ máy khác nhau
 legal text: quy định về text, and
 the game options: các chế độ tùy chọn của game (game
start/menu selection, hints, game pause, pause menu options
 scrolling, i.e. cycling through the available options on the
screen, etc.)

33. b. GAME TESTING TECHNIQUES AND “TIPS-N-HINTS”
Dưới đây là một số kỹ thuật chi tiết và các kỹ thuật test:
Kiểm tra tỷ mỷ toàn bộ màn hình
 Nắm bắt được các rules của game và có thể chơi game để kiểm
tra các rule này.
 Test for clipping
 Examine the overlap: Kiểm tra việc ngắt các ứng dụng (thực
hiện chồng chéo nhiều action khi đang chơi game) check action
game khi overload
 Test với các trường hợp dữ liệu sai, dữ liệu trùng lặp
 Kiểm tra follow, logic của game thông qua việc chơi ở
tất cả các cấp độ khác nhau và ở các điều kiện khác
nhau
 Kiểm tra màu sắc các đối tượng và hiệu ứng các đối
tượng khi có hoặc không có action.
 Test loading/saving from a game save device
 Đảm bảo quy trình load game or load data và các
message thông báo cho các quy trình này và hiển thị
chúng lên màn hình
 Đảm bảo việc thời gian load và kết nối giữa các action
nằm trong giới hạn chấp nhận được.
 Tìm kiếm các trường hợp bất thường khi đang chơi
game và ảnh hưởng đến tốc độ, logic, màn hình, level…

34. hoặc các yếu tố ảnh hưởng đến toàn bộ follow của
game.
 Thử nghiệm chế độ multi-player, multi-actions để
check game.
 Kiểm tra các lỗ hổng về bộ nhớ, dung lượng bộ nhớ
(quá tải) việc tải game bằng cách duy trì chơi game
trong 1 thời gian dài hoặc việc thoát ra và đăng nhập
vào game nhiều lần trong 1 thời gian ngắn
 Kiểm tra các ràng buộc (dữ liệu, môi trường, hệ
thống…)
 Kiểm tra tính tương thích của game trên các platform
khác nhau ví dụ:
 Trên PC: game cần tương thích với tất cả các hệ
điều hành: windows, linux…
 Hay việc chơi game online trên các trình duyệt
khác nhau, kết nối của các nhà mạng khác nhau,
tốc độ kết nối mạng khác nhau..
 Kiểm tra việc tương thích cấu hình của game trên
môi trường của người dùng thực và điều kiện thực
tế của người dùng sở tại
 Kiểm tra việc nội địa hóa của game nếu cần thiết
Đây là một số kỹ thuật cần có và cơ bản cho 1 game tester để
kiểm thử game thông thường. Đối với các game đặc thù khác nhau

35. đòi hỏi tester cần phải có những ứng dụng kỹ thuật khác nhau để
đảm bảo chương trình hoàn thiện nhất trên khả năng có thể của dự
án.
c. SPECIAL CONSIDERATIONS FOR GAME TESTING
 Với các tester khi test game việc phân chia được thứ tự ưu tiên và các
lỗi của hệ thống theo cấp độ là việc rất quan trọng. Điều này sẽ ảnh
hưởng trực tiếp đến tiến trình dự án và chất lượng của phần mềm.
 Trong test game có 2 khái niệm cần quan tâm: crack bugs và
Placeholder
 Crack bugs: là 1 lỗi mà trên thực tế nó không hề tồn tại nhưng
được phát hiện ra bởi các action trong quá trình chơi game
(tưởng tượng)
 Placeholder: là 1 action giả lập được hiển thị khi chương trình
xảy ra các sự cố (ví dụ: màn hình loading khi đang load dữ
liệu..)
4. Test plan development for game testing
Có 2 kiểu test case cho việc test game:
 Test case để kiểm tra chức năng của game: thường được biết đến và sử dụng
trong công nghiệp phần mềm như 1 cách kiểm tra tích cực và hiệu quả.

36.  Một trong những cách kiểm tra khác đó là kiểm tra độ bền và cấp độ, độ khó
cũng như khả năng của hệ thống với game (tolerance resistance) được biết đến
như là Negative Testing (Stress Testing or Load Testing).
 Các trường hợp nagative thường được tets với các điều kiện bất thường và
check các action của hệ thống đưa ra với trường hợp này. Ví dụ:
 Load game mà không có thẻ nhớ, thẻ nhớ không đủ dung lượng hoặc load game
vào bộ nhớ trong của máy và kéo thẻ nhớ ra khi đang load.
 Chơi game trong khoảng time dài (trên 48h) để kiểm tra việc cấp phát và quản
lý bộ nhớ
 Check khả năng tương thích với người chơi: game có thể chơi 1 người, theo đội
hoặc nhiều hơn nữa..
 Định nghĩa Smoke Testing: test việc biên dịch game trên các môi trường khác
nhau và các cấu hình khác nhau
5. Software testing and testing techniques
a. SOFTWARE TESTING PROCESSES
 Kiểm tra code (Code Inspection): tập chung vào cấu trúc của code, các
chuẩn trong code, các comment, các cấu trúc định nghĩa…
 Incremental Focus Testing (tăng cường việc kiểm tra)
 Data Analysis (phân tích dữ liệu)
 Path and Flow testing

37.  Algorithm-Specific testing: cài đặt và chạy ứng dụng trên 1 môi trường
khác để test các tính năng và khả năng tương thích của game trên các môi
trường
 Artificial Intelligence Analysis: tạo ra các số liệu thống kê về các actions đã
được hệ thống định dạng sẵn trên các môi trường khác nhau (kiểm tra tính
ổn định của game)
b. SOFTWARE TESTING TECHNIQUES AND “TIPS-N-HINTS”
 File structures
 Make Files
 Memory management
 Debugger and Code inspection
 Test Programs
 Sound Testing
 P3D and pipelines
 Database and Game Statistics
 Overlays
 Front End
 Bug Tracking Software

38.  Game Tester and love of the game
 Burning CDs
6. Testing considerations for software testing
a. TESTING COVERAGE
Với một tester khi kiểm thử phần mềm không thể cover được toàn bộ
chương trình. Cũng tương tự như vậy đối với 1 game tester. Các tester cần phải
nắm bắt được toàn bộ hệ thống, focus vào những điểm quan trọng và phải đưa
ra quyết định test như thế nào là đủ và đạt yêu cầu trong 1 khoảng thời gian
nhất định (best effort in time box).
b. TESTING VS. DEBUGGING
Việc nắm bắt và phân tích được các lỗi cũng như nguyên nhân gây lỗi
sẽ giúp đơn giản hóa được quá trình fix bug. Tuy nhiên không phải tất cả các
tester đều có thể nắm rõ nguyên nhân gây ra lỗi và điều này cần sự phối kết
hợp giữa tester và dev. Dựa vào 1 số yếu tố có thể làm rõ thêm các lỗi:
- Mỗi một vấn đề (issue) chỉ được mô tả 1 lỗi duy nhất. Việc cô lập lỗi
và mô tả chi tiết tiến trình gây lỗi giúp minh bạch hóa lỗi khi fix.
- Mô tả chi tiết quá trình gây lỗi và các bước để tái hiện lỗi: bao gồm cả
môi trường, cấu hình, thiết bị…
- Kiểm tra xem chương trình đã đạt mức tới hạn chưa??
- Giao (Assign) lỗi phù hợp nhất với trình độ của dev để giải quyết vấn
đề nhanh nhất là tốn ít effort nhất.
c. TOOLS SUPPORT FOR TESTING

39. Việc test game đòi hỏi cần phải có một môi trường thực và chuyên
nghiệp cho các tester. Môi trường test của tester cần gần với môi trường
người dùng hơn so với môi trường của dev. Môi trường test cần hỗ trợ tối
đa được giao diện, các thành phần, các công cụ hỗ trợ và kiến thức nền tảng.
7. Kiểm thử toàn chu trình
Mục tiêu của full cycle testing là tìm và fix bug của hệ thống ngay từ giai
đoạn đầu và đảm bảo chất lượng dự án sẽ hoàn thiện vào giai đoạn cuối cùng
của dự án.
Các kỹ thuật được sử dụng cho “Kiểm thử toàn chu trình”:
- validation for accuracy and correctness: xác nhận tính chính xác và
đúng đắn (hợp lệ).
- verification for completeness: xác minh tính đầy đủ.
TESTING FOR DIFFERENT PROJECT STAGES
 Giai đoạn Development – coding and implementation/ integration of various
pipelines and work by the teams that are integrated to make up the game.
“Clear box” testing will encompass module/component testing, testing of
coverage and flow, data integrity, algorithm-specific testing (e.g. debug
code is in the game code), path testing, and various levels of functional
regression testing. This is more an incremental testing.
 Giai đoạn Review – Focus Group, and a “big bang” testing both Clear
Box and Black Box Testing, in a structured manner.
 Giai đoạn Regression Testing – it will be the game testing (Alpha, Beta, and
Final).

40. PHẦN III: QUY TRÌNH KIỂM THỬ TRONG
CÔNG NGHIỆP
I. GIỚI THIỆU VỀ CÔNG TY
Công ty VTC Mobile
 Công ty có trụ sở tại 18 Tam Trinh, Q.Hoàng Mai, Hà Nội
 Website : http://www.mobile.vtc.vn
Tổng công ty Truyền thông Đa phương tiện VTC (tên giao dịch quốc tế là VTC
- Multimedia Corporation) được thành lập từ tháng 2/1988, trực thuộc Bộ
Thông tin và Truyền thông. Tổng công ty Truyền thông Đa phương tiện sở hữu
một trường Đại học và 3 khối kinh doanh là: Truyền thông, Viễn thông, Công
nghệ và nội dung số với tổng số CBCNV là 4500 người.
II. Qui trình làm phần mềm
Công ty sử dụng qui trình phát triển phần mềm khá thông dụng, cũng đi
từ các bước nhận hợp đồng, khảo sát đến phân tích thiết kế, lập trình, quá trình
test sẽ song hành với các quá trình trên cho đén khi bàn giao cho khách hàng
và cuối cùng là bảo trì.
III. Qui trình kiểm thử phần mềm
Qui trình kiểm thử :
 Đầu tiên đội test sẽ tham gia vào quá trình nghiên cứu yêu cầu của khách
hàng, tham gia vào đặc tả chi tiết của bản design. Phân tích trao đổi với
đội developer và cả leader

41.  Sau đó khi leader lên được plan chi tiết về công việc của toàn đội, tester
sẽ dựa trên plan công việc của leader để lên plan cho mình và cho test
team
 Trong quá trình đội developer coding thì tester bắt đầu viết scenario, lập
test case.
 Khi dev đã hoàn thành và yêu cầu tester thực hiện việc test, thì tester sẽ
tiến hành test dựa trên test case đã được lập. Sau đó log các bug tìm
được lên DMS và giao cho dev tương ứng fix.
 Sau khi dev fix xong sẽ request test thực hiện việc test lại sản phẩm tới
khi nào free bug thì thôi.
 Sau đó test cứng sẽ tiến hành test tích hợp các module và toàn bộ hệ
thống, không quan tâm nhều tới logic của hệ thống, chủ yếu tập trung
free test dể tìm ra lỗi một cách random (system test).
 Nếu tiếp tục tìm ra bug sẽ đưa lại cho dev để fix lại, khi fix xong sẽ
deliver sản phẩm cho khách hàng
 Trong quá trình phát triển sản phẩm, tester sẽ lập test report báo cáo kết
quả thực hiện test của mình trong tuần.
IV. Các phần mềm hỗ trợ quá trình kiểm thử và bảo trì
Hiện tại công ty đang nghiên cứu về các test tool để ứng dụng cho tương
lai, còn hiện tại chưa sử dụng phần mềm nào hỗ trợ quá trình này.
Trong thời gian qua chúng em đã tìm hiểu được các Tooltest đã và đang
được phát triển sau:

42. STT
Tên chương
trình
Mã
nguồn
Mô tả OS Phân loại
1 Slower Miễn
phí
Làm chậm một chương trình khác,
khiến cho chương trình khác chạy
như rùa. Nguyên lý: khiến chương
trình bị hại phải delay định kỳ. Sau
khi chạy, Slow sẻ quét Task
Manager để user chọn 1 chương
trình trong số đó. Sau đó, user chọn
2 tham số:thời gian làm chậm-
suspend time và thời gian giữa 2
lần làm chậm-resume time.
Win Stress
2 SysTrayTim
er
Miễn
phí
Định kỳ kích hoạt một chương
trình khác.
Win Attack
3 TestLink
Export
Tự phát
triển
Đọc database của site quản lý
testcase TestLink, sau đó xuất ra
báo cáo Excel theo template của
AI&T. Chương trình sẽ chạy trên
máy Client của QA, sau đó nhập
đường dẫn... vào file cấu hình và
chạy. Yêu cầu phải có JRE
Win &
Linux
Export
4 Source
Monitor
Miễn
phí
Mở một dự án, thống kê xem các
hàm sử dụng, tính số dòng code,
comment, độ phức tạp của hàm, số
lệnh rẽ nhan... xuất ra dạng biểu
đồ, daskboard, rất là trực quan.
Win Analysis
5 Bound
Checker
Thương
mại
Kiểm tra truy cập bộ nhớ, phân tích
hiệu xuất sử dụng function, kiểm
tra khi đang chạy runtime. Được
cài đặt thành một Add-ins trong
Visual Studio, tương thích với
VS2005 và VS6.
Win Analysis
6 Packet
Tracer
Miễn
phí
Giả lập tất cả các thiết bị mạng của
Cisco, chính xác và cực kì chi tiết,
như thật. Được Cisco hỗ trợ phát
triển để làm công cụ giảng dạy và
thi cử. Cho phép tạo môi trường
mạng ảo, cấu hình mạng ảo và xem
các gói tin di chuyển trên mạng.
Win Simulation

43. 7 Intel Thread
Checker
Thương
mại
Kiểm tra các vấn đề khi chạy Multi
Thread như truy cập bộ nhớ, không
đồng bộ, deadlock, etc.
Win &
Linux
Analysis
8 HTML Tidy Miễn
phí
Kiểm tra HTML để phát hiện lỗi cú
pháp, thông báo và tự sửa lỗi. Bao
gồm gói giao diện và gói chương
trình độc lập nhau. Có thể sử dụng
trực tiếp gói chương trình bằng
command-line.
Win Analysis
9 Max CPU Miễn
phí
Khiến cho CPU Load tăng 100%,
nhưng không làm giảm hiệu năng.
Chương trình sẽ khiến cho 1 cpu
core tăng tối đa, tức là nếu PC
dùng chip single core thì chỉ cho
phép cpu=0hoặc 100%. Nếu PC là
dure core thì sẽ cpu=0%, 50%,
100%. Tuy nhiên với trường hợp
50%, đây là giá trị trung bình, thực
tế là luôn có 1 core = 100% còn1
core = 0%
Win Stress
10 CPU Killer
3
Thương
mại
Khiến cho CPU Load tăng 100%,
và làm giảm hiệu năng xử lý. Nếu
CPU Load = 100% thì PC chạy
như treo. Độ hiệu chỉnh thay đổi ở
mức 1% nhưng thực tế lệch nhiều.
Win Stress
11 Quick Test Thương
mại
Win Automation
12 WinRunner Thương
mại
Win Automation
13 Window
Tester
Thương
mại
for Swing, SWT java apps
14 QF-Test Thương
mại
for Swing, SWT java apps
15 XML Viwer Miễn
phí
Xem, sửa file XML, tổ chức dữ
liệu dạng tree. Nhưng không cho
copy
Win Analysis
16 Tgrab Thương
mại
Chụp ảnh màn hỉnh định kỳ hoặc
bằng tay. Có thể dùng để theo dõi
màn hình của chương trình chạy
Win Others

44. stability
17 Win Errors Miễn
phí
Hiển thị chi tiết các lỗi do
Windows thông báo. Các thông báo
lỗi Windows chỉ có mỗi ID.
Chương trình này sẽ cho biết ID đó
cụ thể là lỗi về cái gì. Error Code
từ 0-->658. OLE Error có 896 lỗi
Win Library
18 Error
Message for
Windows
Miễn
phí
Hiển thị chi tiết các lỗi do
Windows thông báo. Các thông báo
lỗi Windows chỉ có mỗi ID.
Chương trình này sẽ cho biết ID đó
cụ thể là lỗi về cái gì. Error Code
từ 0 --> 10112.
Win Library
19 Fast Fake Miễn
phí
Tạo các link, các lệnh thực hiện
một yêu cầu nào đó trong OS. Ví
dụ, 1 link ứng với 1 lệnh mở
notepad, enable chức năng
screensaver, đóng tất cả cửa sổ trên
màn hình, hibernate PC, tắt PC…
Rất tốt để test máy tính, gọi một
phần mềm nào đó định thời
Win Others
20 Mib
Browser
Miễn
phí
Đọc, hiện thị và tìm kiếm thông tin
trong mib file dưới dạng cây. Các
MIB file dùng để quản lý OID
trong giao thức SNMP. Sau khi
người dùng tải các file mib liên
quan tới thiết bị được yêu cầu về,
sử dụng chương trình này để hiện
thì các thông tin bên trong
Win Management
21 Net Profile
Switch
Thương
mại
Quản lý nhiều cấu hình mạng trên
cùng một máy tính. Thông thường,
một máy tính có thể dùng để giả
lập các máy khác nhau, Mỗi máy
có 1 cấu hình mạng khác nhau.
Thay vì phải nhập đi nhập lại, sử
dụng tool này sẽ lưu các cấu hình
mong muốn thành một file. Mỗi
khi người dùng muốn chuyển từ
cấu hình này sang cấu hình khác,
Win Management

45. chỉ cần bấm vào icon tương ứng để
chuyển cấu hình mạng. Các thông
số thay đổi được như Proxy, card
mạng, địa chỉ IP, subnet, máy in
mạng mặc định, VPN, smtp, server
address... Ứng dụng cho giả lập
máy PTE của Photonic.
22 Net Set Man Miễn
phí
Tương tự Net Profile Switch nhưng
chỉ quản lý được 6 nhóm thông tin
cấu hình mạng.
Win Management
23 Project Diff Thương
mại
So sánh 2 file plain text, có chức
năng loại bỏ so sánh dấu trắng, dấu
tab, comment, tùy theo loại ngôn
ngữ. Cho phép ghi xóa sửa ngay
trong lúc comment. Ngoài ra, có
nút bấm để merge nội dung từ file
này sang file kia,. Có bôi màu xanh
đỏ, trực quan. Sử dụng để review
tài liệu.
Win Analysis
24 Virtual
Serial Port
Thương
mại
Tạo driver cổng com ảo, để có thể
chạy 2 chương trình giao tiếp cổng
com với nhau trên cùng một máy
tính. Sử dụng để test giao tiếp cổng
com trên cùng một máy, không
phải dùng thêm thiết bị ngoài. Com
ảo trong suốt với người dùng, với
người lập trình. Có 2 loại com ảo:
tạo 1 com ảo tự nối localhost với
RxD=TxD, tạo 2 cặp com ảo bắt
chéo tín hiệu với nhau.
Win Simulation
25 ireasoning Miễn
phí
Đọc, hiện thị và tìm kiếm thông tin
trong mib file dưới dạng cây. Các
MIB file dùng để quản lý OID
trong giao thức SNMP. Sau khi
người dùng tải các file mib liên
quan tới thiết bị được yêu cầu về,
sử dụng chương trình này để hiện
thì các thông tin bên trong. Khả
năng tìm kiếm OID mạnh hơn Mib
Browser, thêm đó là chức năng
Win &
Linux
Management

46. quan trọng Bookmark các OID cần
thiết
26 AutoIT
27 Doxygen
28 InstallJamm
er
Miễn
phí
Tạo chương trình cài đặt giao diện
đồ họa cho nhiều OS khác nhau (có
Linux). Hỗ trợ ngôn ngữ TCL
Win &
Linux
Others
29 Screen Miễn
phí
Tạo Terminal ảo trên Linux giúp
log lại các thao tác trên terminal.
Linux Others

47. PHẦN IV: VẬN DỤNG VÀO VIỆC KIỂM THỬ
GAME CỜ TƯỚNG
I. TỔNG QUAN HỆ THỐNG VÀ MODULE KIỂM THỬ
1. Mô tả bài toán
Cờ tướng hay còn gọi là cờ Trung Quốc, vì nó có nguồn gốc từ Trung
Quốc ( Nhưng theo người phương tây thì nó có nguồn gốc Ấn Độ). Đây là
một trò chơi trí tuệ dành cho hai người, phổ biến trên thế giới cùng với cờ
vua. Người ta thường chơi cờ tướng là quân gỗ hoặc nhựa.
Ngày nay, bộ cờ bằng gỗ hay nhựa cũng không còn tiện dụng để mang
đến văn phòng làm việc chơi, đồng thời công nghệ thông tin phát triển. Bài
toán đặt ra là xây dựng trò chơi cờ tướng dành cho hai người chơi với nhau
trong một máy, trong mạng LAN và phát triển chơi trên mạng Internet.
Vì đây là bài tập lớn Môn Đồ họa nên chúng em mới chỉ xây dựng
được game cờ tướng dành cho hai người cùng chơi với nhau trong cùng một
máy.
2. Mô tả hệ thống
Chế độ chơi: Game cờ tướng dành cho 2 người chơi, có thể chọn chế
độ Chấp cờ để chấp cờ cho đối phương, có thể chọn Tính thời gian hoặc
không Tính thời gian. Nếu tính thời gian, cả 2 người chơi sẽ được giới hạn
tổng thời gian suy nghĩ và đi của tất cả các nước, nếu ai hết thời gian trước
thì xem như người đó thua.

48. Cách chơi: Dùng chuột để click chọn quân cờ và click vào vị trí
muốn đi đến để di chuyển quân cờ. Trong suốt quá trình chơi, người chơi có
thể dùng chứ năng Undo để xin đi lại nước cờ vừa đi. Người chơi có thể lưu
lại ván cờ đang chơi, mở ván cờ đã lưu để chơi tiếp, tùy chỉnh tiếng động,
nhạc nền.
3. Các thành phần chính
Cấu trúc game được chia làm 4 phần chính:
- Nhóm class giao diện tương tác: Gồm có các form ChessBoard,
NewGame, Open, Sound_Options, FlashScreen dùng để tương tác trực tiếp
với người chơi.
- Nhóm class lưu trữ dữ liệu: Gồm có lớp BanCo dùng để ghi nhận trạng
thái của bàn cờ và lớp NguoiChoi dùng để lưu thông tin, trạng thái các quân
cờ của người chơi.
- Nhóm class quân cờ:Gồm có Tuong, Sy, Tinh, Xe, Phao, Ma, Chot, là các
lớp dẫn xuất từ lớp QuanCo, chứa các thuộc tính thiết lập thông tin về quân
cờ và các phương thức của quân cờ đó.
- Class quản lý chung: là class VanCo chứa các thuộc tính được static, thiết
lập thông số cho một ván cờ như bộ đếm thời gian mỗi nước đi, âm
thanh…và các phương thức kiểm tra, thông báo các trạng thái của ván cờ
như chiếu tướng, kiểm tra hết cờ…

49. 4. Mô hình thiết kế tổng thể
A. Nhóm lưu trữ dữ liệu:
1. Lớp BanCo: Các thuộc tính của lớp BanCo được khai báo static để tiện xử lý
trong các lớp khác
Thuộc tính
struct Oco
chứa các thông tin của 1 ô cờ, gồm
có: Hàng, Cột, Trống, Phe, Tên,
Thứ tự, picturebox CanMove(dùng

50. để thông báo quân cờ có thể đi đến
vị trí này được không, nếu đi được
=> CanMove.Visible=True)
static OCo[,] ViTri = new OCo[10, 9]
Mảng lưu 90 vị trí, tương ứng với
[10x9] vị trí trên bàn cờ, mỗi phần
tử của mảng là 1 Oco
Phương thức
static BanCo() Constructor khởi tạo bàn cờ trống
public static void ResetBanCo() Trả lại bàn cờ trống
public static void ResetCanMove()
Tắt thông báo những vị trí mà quân
cờ có thể di chuyển đến
2. Lớp NguoiChoi:
Thuộc tính
public int Phe
Xác định phe của người chơi
(0 hoặc 1)
public Tuong qTuong = new Tuong()
Tạo thể hiện qTuong từ lớp
Tuong(quân Tướng của người
chơi)
public Sy[] qSy = new Sy[2]
Tạo thể hiện qSy[0] và qSy[1] từ
lớp Sy(2 quân Sỹ của người chơi)
public Tinh[] qTinh = new Tinh[2]
Tạo thể hiện qTinh[0] và qTinh[1]
từ lớp Tinh(2 quân Tịnh của người
chơi)
public Xe[] qXe = new Xe[2]
Tạo thể hiện qXe[0] và qXe[1] từ
lớp Xe(2 quân Xe của người chơi)
public Phao[] qPhao = new Phao[2]
Tạo thể hiên qPhao[0] và qPhao[1]
từ lớp Pháo(2 quân Pháo của người

51. chơi)
public Ma[] qMa = new Ma[2]
Tạo thể hiện qMa[0] và qMa[1] từ
lớp Ma(2 quân Mã của người chơi)
public Chot[] qChot = new Chot[5]
Tạo thể hiện qChot[0] đến
qChot[4] từ lớp Chot(5 quân Chốt
của người chơi)
Phương thức
public NguoiChoi(int x)
Constructor khởi tạo người chơi
với Phe=x và đặt vị trí ban đầu cho
các quân cờ tương ứng với Phe
B. Nhóm class quân cờ:
1. Lớp cơ sở QuanCo:
Thuộc tính
public int Hang Giá trị Hàng của quân cờ
public int Cot Giá trị Cột của quân cờ
public string Ten Tên quân cờ
public int Phe Phe 0 hoặc 1
public string ThuTu
Thứ tự Trái hoặc Phải(vd: Pháo
trái, Pháo phải), đối với chốt thì
Thứ Tự sẽ là 0 đến 4
public int TrangThai
Trạng thái của quân cờ (còn
sống => TrangThai=1, đã bị ăn
=> TrangThai=0)
public PictureBox picQuanCo = new PictureBox()
PictureBox chứa hình ảnh của
quân cờ
public bool Khoa Thuộc tính Khóa, không cho

52. người dùng tương tác vào quân
cờ để di chuyển (Khoa=false =>
quân cờ có thể di chuyển được)
Phương thức
public QuanCo()
Constructor thiết lập các giá trị
mặc định khi quân cờ được tạo ra:
Hang=10,Cot=10(vị trí [10x10]
không có trên bàn cờ), Ten=” ”,
Phe=2(ngoài 2 giá trị 0,1),
ThuTu=” ”, TrangThai=0,
Khoa=True
public void KhoiTao(int phe, string name, string thutu,
int stt, bool khoa, int x, int y)
Khởi tạo quân cờ với các giá trị
tương ứng
public void draw()
Phương thức vẽ quân cờ vào vị trí
[Hang,Cot]
public virtual int KiemTra(int i,int j)
Kiểm tra quân cờ có thể di
chuyển đến vị trí [i,j] theo đúng
luật mà 2 tướng không đối mặt
nhau hay không, trả về 0 nếu
không đi được, trả về 1 nếu có thể
đi, phương thức này sẽ được
Override lại ở các lớp quân cờ
dẫn xuất cụ thể
public virtual int TuongAnToan(int i, int j)
Kiểm tra nếu quân cờ di chuyển
đến vị trí [i,j] thì tướng phe mình
có an toàn không(không bị chiếu)
private void picQuanCo_MouseClick(Object sender,
MouseEventArgs e)
Thao tác click chuột chọn quân
cờ để đi

53. 2. Các lớp dẫn xuất từ lớp QuanCo:
Gồm có lớp Tuong, Sy, Tinh, Xe, Phao, Ma, Chot với phương thức
KiemTra(i,j) và TuongAnToan(i,j) được override lại tương ứng với đặc điểm di
chuyển của từng loại quân.
C. Class quản lý chung:
Lớp VanCo: Các thuộc tính của lớp VanCo được khai báo static để tiện xử lý
trong các lớp khác
Thuộc tính
public static NguoiChoi[] NguoiChoi=new
NguoiChoi[2]
Tạo ra 2 người chơi: NguoiChoi[0] và
NguoiChoi[1]
public static string TenNguoiChoi1 Tên NguoiChoi[0]
public static string TenNguoiChoi2 Tên NguoiChoi[1]
public static bool DangChoi
Trạng thái của ván cờ: Ván cờ đang
được chơi => DangChoi=True
public static PictureBox ThongBaoChieuTuong =
new PictureBox()
PictureBox chứa picture thông báo
tướng đang bị chiếu
public static Panel ChieuBi = new Panel()
Panel thông báo nước chiếu bí, bao gồm
2 picturebox con có nhiệm vụ như 2
button là DiLai(xin đi lại) và
ChiuThua(chịu thua)
public static Panel KetQua = new Panel()
Panel thông báo kết quả của ván cờ, bao
gồm Label NguoiThang ghi tên của
người thắng, 2 picturebox con có nhiệm
vụ như 2 button là ChoiLai(Chơi lại) và
Thoat(thoát)

54. public static Panel ChapCo = new Panel();
Panel hiển thị thông báo chọn quân cờ
muốn chấp (trong trường hợp người
chơi chọn chấp cờ), gồm có 1
picturebox con có nhiệm vụ như 1
button là ChapXong(bắt đầu chơi khi
người chơi chấp xong)
public static bool Marked
Xác định đã có quân cờ nào được click
chọn để đi chưa(quân cờ được click =>
Marked=True)
public static QuanCo DanhDau
Quân cờ DanhDau tham chiếu đến quân
cờ được chọn để đi
public static int LuotDi
Kiểm tra đến lượt đi của NguoiChoi[0]
hay NguoiChoi[1](lượt đi của
NguoiChoi[0] => LuotDi=0)
public static int winner
Xác định người thắng ván cờ
(NguoiChoi[0] thắng => winner=0,
NguoiChoi[1] thắng => winner=1), nếu
chưa có người nào thắng thì winner=2
public static NuocDi[] GameLog;
Mảng GameLog, nhật ký các nước đi,
phục vụ cho chức năng Undo, với mỗi
phần tử là một nước đi (struct NuocDi
gồm có vị trí đầu, vị trí cuối, và các
quân cờ tương ứng với vị trí đầu, cuối)
public static QuanBiAn[] QuanDoBiAn
public static QuanBiAn[] QuanDenBiAn
Mảng lưu các quân cờ đã bị ăn của 2
người chơi (struct QuanBiAn bao gồm
hàng, cột, tên của quân bị ăn)
public static bool Chap
Xác định có mở chức năng chấp cờ hay
không(chấp => Chap=True)

55. public static bool AmThanh
Trạng thái của tùy chọn tiếng động khi
di chuyển quân cờ
public static bool NhacNen
Bật, tắt nhạc nền (bật =>
NhacNen=true)
public static bool TinhThoiGian
Thiết lập chức năng tính thời gian cho
ván cờ (TinhThoiGian=True)
Phương thức
static VanCo()
Constructor khởi tạo 2 người chơi và
các giá trị ban đầu
public static void NewGame()
Tạo ván cờ mới, vẽ các quân cờ lên bàn
cờ trong lần chơi đầu tiên, đưa các quân
cờ về vị trí ban đầu trong những lần
chơi sau…
public static void DoiLuotDi()
Đổi lượt đi của người chơi bằng cách
Khóa tất cả các quân cờ của phe vừa đi,
mở Khóa tất cả các quân cờ của phe
chuẩn bị đi
public static void Undo()
Thực hiện thao tác Undo lại nước cờ
gần nhất trong ván cờ đó
public static void Save()
Lưu ván cờ vào file bằng cách kiểm tra
tất cả các vị trí của bàn cờ, nếu
Trong=false thì lấy dữ liệu của quân cờ
tại vị trí đó ghi vào file
public static void Open()
Mở lại ván cờ đã lưu bằng cách đọc
thông tin từ file
public static void OCoTrong(int i, int j)
Trả về ô cờ trống cho vị trí [i,j] bằng
cách reset các giá trị của struct Oco
public static void DatQuanCo(Object sender,
QuanCo q, int i, int j)
Đặt quân cờ q vào vị trí [i,j]

56. public static bool ChieuTuong(QuanCo tuong)
Kiểm tra quân Tướng được đưa vào làm
tham số có bị chiếu không bằng cách
kiểm tra từng quân cờ của đối phương
có di chuyển đến vị trí của quân tướng
được không, trả về True nếu bị chiếu,
trả về False nếu không bị chiếu
public static void KiemTraChieuTuong()
Kiểm tra và thông báo quân tướng phe
nào bị chiếu nếu là nước đi chiếu tướng
public static void AnQuanCo(QuanCo q)
Thiết lập quân cờ q thành quân cờ đã bị
ăn(TrangThai=0) và đưa vào mảng các
quân cờ bị ăn
public static void KiemTraChieuBi()
Kiểm tra và thông báo nếu là nước đi
chiếu bí bằng cách duyệt lần lượt các
quân cờ của phe bị chiếu xem có quân
cờ nào còn nước đi hợp lệ không(đúng
luật đi của loại quân đó, không chống
tướng, nước đi không dâng tướng cho
đối phương)
public static void ClickSound(string s)
Phát ra tiếng động khi quân cờ di
chuyển hoặc ăn quân đối phương
public static void PlayNhacNen(bool nhacnen)
Kiểm tra giá trị của nhacnen,
nhacnen=True => play nhạc nền,
nhacnen=False => stop nhạc nền
D. Nhóm giao diện tương tác
1. Form ChessBoard: Form chính, dùng cho 2 người chơi tương tác với game
như các menu để thực hiện các chức năng NewGame, Undo, Save, Open,

57. Options, Exit, hiển thị tên người chơi, thời gian còn lại của từng người chơi,
các quân cờ bị ăn…
2. Form NewGame: Form lấy thông tin cho một ván cờ mới, gồm có tên 2 người
chơi, tùy chọn tính thời gian, chấp cờ. Khi form được submit thì các giá trị
tương ứng với thông tin sẽ truyền cho các thuộc tính static tương ứng trong lớp
VanCo để quản lý ván cờ đó.
3. Form Open: Khi form đươc gọi thì tương ứng, phương thức Open của lớp
VanCo được thực thi, phương thức này sẽ thực hiện thao tác duyệt các file
trong thư mục Save và đưa vào 1 listbox để người chơi chọn và chơi tiếp, sau
khi người chơi chọn và click Chơi, thì file tương ứng với phần tử được chọn
trong listbox sẽ được lấy thông tin và đưa vào các thuộc tính của lớp VanCo và
lớp BanCo.
4. Form Sound_Options: Form lấy thông tin về tùy chọn âm thanh của người
chơi. Gồm có tiếng động và nhạc nền. Khi form được Submit thì các giá trị
tương ứng với các thông tin này sẽ được truyền vào thuộc tính tương ứng trong
lớp ván cờ là VanCo.AmThanh và VanCo.Nhacnen.
II. TIẾN HÀNH KIỂM THỬ
1. Mục đích
Kiểm tra các chức năng của đối tượng có đúng yêu cầu không, xem
giao diện có đúng thiết kế hay không.
2. Yêu cầu giao diện
STT Yêu cầu kiểm thử Yêu cầu kết quả KQ
1 Chức năng xếp bàn cờ Khi bắt đầu ván cờ, bàn cờ phải
được xếp đúng theo luật.
ok

58. 2 Các quân cờ đi đúng luật Các quân cờ chỉ được đi theo các
luật đã định, không được đến các vị
trí nó không được phép
3 Chức năng lưu/ Mở lại ván cờ Lưu lại ván cờ đã đánh dở dang, lần
sau mở lại nó tiếp tục trạng thái lúc
lưu
4 Chức năng tùy chỉnh âm thanh Có thể bật/tắt nhạc nền, tiếng động
5 Chức năng xin đi lại Quay lại trạng thái của ván cờ trước
lúc đi quân vừa rồi
6 Chức năng báo thắng/thua Khi có một người thắng, thông báo
vãn cờ kết thúc đồng thời thông báo
người thắng người thua
7 Chức năng đếm thời gian Giới hạn thời gian đi một quân cờ
8 Chức năng gợi ý Khi một quân cờ được chọnđể đi thì
xuất hiện các gợi ý các vị trí có thể
đi
9 Chức năng Reset Có thể chơi lại ván cờ từ đầu
10 Chức năng giới hạn thời gian
chơi một ván cờ
Bạn có thể giới hnaj thời gian chơi
một ván cờ, khi thời gian kết thúc
mà vãn cờ chưa kết thúc thì có
thông báo
3. Tình huống kiểm thử và kết quả
Tình huống Dữ liệu kiểm thử Yêu cầu kết quả KQ
Kiểm tra bước đi
của từng quân cờ
Kiểm tra tất cả cac
bước đi của các quân
Đi đúng luật OK

59. cờ
Tạo mới ván cờ Nhấn vào nút Tạo
mới ván cờ
Các quân cờ xanh đỏ
được xếp mới theo
đúng quy định, trạng
thái người chơi được
bắt đầu tính
Ok
Lưu ván cờ Khi ván cờ mới được
tạo, nhấn lưu ván cờ
Ván cờ không được
lưu
Bug:Thông
báo ván cờ
được lưu.
Lưu ván cờ Khi ván cờ đang
được chơi dở dang,
nhấn lưu ván cờ
Ván cờ được lưu vào OK
Thoát Khi ván cờ chưa lưu,
nhấn thoát
Hiện thông báo có lưu
ván cờ hay không
ok
Thoát Khi ván cờ vừa lưu,
nhấn thoát
Thoát, không hiện
thông báo
Bug: Hiện
thông báo
có lưu ván
cờ hiện tại
không
Mở ván cờ đã lưu Khi khởi chạy
chương trình, nhấn
mở ván cờ đã lưu
Mở lại ván cờ đúng
trạng thái lúc lưu
OK
Đổi nhạc nền Nhấn Setting, chọn/
bỏ chọn Nhạc nền,
chọn đường dẫn đến
file nhạc
Khởi chạy chương
trình sẽ có nhạc nền
bật/ tắt.
ok

60. Xin đi lại nước Khi mới mở ván cờ,
nhấn nút xin đi lại
nước
Thông báo không
thành công
Bug:
Thông báo
đi lại thành
công
Xin đi lại nước Khi đang chơi ván
cờ, người chơi có thể
xin đi lại nước
Thông báo thành công OK
Không nhập tên
người chơi
Khi tạo ván cờ mới,
không nhập tên
người chơi
Thông báo nhập tên Ok
Cờ chấp Khi khởi tạo ván mới
có chức năng chọn
Cờ chấp, chọn các
con cờ muốn chấp
Các concờ được chấp
biến mất khỏi bàn cờ
ok
Tính thời gian Khi khởi tạo ván mới
có chức năng tính
thời gian, sau
hết thời gian quy định
có thông báo
Ok
Chức năng chiếu bí Hai người đang chơi,
khi có một người
chiếu tướng hết cờ
Xuất hiện thông báo
“Chiếu bí” với hai
chức năng Xin hang –
Xin đi lại
ok
Chức năng kiểm tra
chiếu tướng
Khi một quân được
chọn để di chuyển
Nó phải được xét xem
khi nó di chuyển bàn
cờ có rơi vào trạng
thái chiếu tướng hay
không
ok

61. Chức năng kiểm tra
chiếu bí
Khi một quân cờ di
chuyển
Nó được kiểm tra xem
ván cờ có rơi vào thế
chiếu bí hay không ,
nếu có hiện thông báo
Ok

62. PHÂN CÔNG CÔNG VIỆC TRONG NHÓM
STT Họ và tên Công việc cần làm Đánh giá
1 Nguyễn Lan Anh Tìm hiểu quy trình kiểm
thử tại công ty
Vận dụng vào việc kiểm
thử game Cờ tướng
Đã hoàn thành nhưng còn
thiếu sót
2 Bùi Văn Trường Tìm hiểu các kỹ thuật kiểm
thử phần mềm
Đã hoàn thành nhưng còn
thiếu sót
3 Ngô Đăng Trung Tìm hiểu về kỹ thuật kiểm
thử game
Đã hoàn thành nhưng còn
thiếu sót

63. PHẦN IV: TỔNG KẾT
Kiểm thử phần mềm là bước không thể thiếu trong quá trình sản xuất phần
mềm, đặc biệt với một game thì việc kiểm thử được đặt lên hang đầu và phải rất
coi trọng trước khi giao cho khách hang hay trước khi phổ biến người dung. Trong
việc xây dựng phần mềm không thể nào tránh được lỗi, việc Kiểm thử không phải
chỉ là để tìm lỗi mà nó có mục đích nâng cao chất lượng phần mềm, giảm thiểu tối
đa các lỗi có thể mắc.
Bài báo cáo chúng em đã tìm hiểu về vai trò, chức năng và các kỹ thuật kiểm
thử phần mềm, kiểm thử game trong công nghiệp. Áp dụng vào kiểm thử game Cờ
tướng – Bài tập lớn môn Đồ họa. Chúng em đã cố gắng hết sức nhưng vẫn còn
nhiều sai sót, mong cô thông cảm và góp ý để bài tập lớn của chúng em hoàn thiện
hơn.

64. Các tài liệu tham khảo
1. Sommerville I., Software engineering - 4th, Addison Wesley, 1995.
2. Lê Đức Trung, Công nghệ phần mềm, Nhà xuất bản Khoa học và Kỹ
thuật, 2002.
3. Tài liệu nhập môn công nghệ phần mềm (ebook tại
http://www.slideshare.net/vn.zinki/gt-cng-ngh-phn-mm-se5)
4. File mô tả qui trình kiểm thử của công ty VTC Moblie