tìm hiểu về kỹ thuật kiểm thử phần mềm
TRANSCRIPT
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
Mục lụcLời nói đầu.....................................................................................................................................................5PHẦN I: TỔNG QUAN LÝ THUYẾT KIỂM THỬ.....................................................................................6
I. GIỚI THIỆU.................................................................................................................................61. Vòng đời kiểm thử........................................................................................................................62. Các tiêu chí đánh gíá kiểm thử.....................................................................................................63. Mô hình phát triển chữ V.............................................................................................................7II. KIỂM THỬ UNIT........................................................................................................................81. Tiến trình kiểm thử Unit...............................................................................................................8
a. Kế hoạch kiểm thử Unit.............................................................................................8b. Thiết kế kiểm thử.......................................................................................................8c. Thực hiện và đánh giá kiểm thử unit.........................................................................9
2. Kế hoạch kiểm thử unit................................................................................................................93. Kiểm thử hộp đen.......................................................................................................................104. Kiểm thử hộp trắng.....................................................................................................................10
a. KIểm thử nhánh cơ bản (Basis Path Testing)..........................................................115. Các trường hợp kiểm thử và dữ liệu kiểm thử...........................................................................13III. KIỂM THỬ TÍCH HỢP.............................................................................................................141. Tạo dữ liệu và file kiểm thử.......................................................................................................142. Các chiến thuật và kĩ nghệ kiểm thử...............................................................................................14
a. Kiểm thử tích hợp không tăng tiến..............................................................................14b. Kiểm thử tích hợp tăng tiến.....................................................................................15Kiểm thử Sandwich...........................................................................................................17c. Tiêu chí để hoàn thành.............................................................................................17d. Các lời bình về kiểm thử môđun..............................................................................17e. Đề nghị phương pháp luận kiểm thử tích hợp.........................................................18
IV. KIỂM THỬ HỆ THỐNG...........................................................................................................18V. KIỂM THỬ XÁC NHẬN..........................................................................................................19VI. KIỂM THỬ HỔI QUY...............................................................................................................19VII. LỖI DỮ LIỆU..........................................................................................................................201. Vòng đời của lỗi.........................................................................................................................202. Lỗi dữ liệu..................................................................................................................................213. Dạng của lỗi................................................................................................................................234. Lỗi nguy hại................................................................................................................................255. Trạng thái lỗi..............................................................................................................................256. Xử lý nguồn gốc.........................................................................................................................26
7. Ưu tiên lỗi...................................................................................................................................28PHẦN II: PHƯƠNG PHÁP KIỂM THỬ GAME.......................................................................................29
I. GIỚI THIỆU TỔNG QUAN......................................................................................................29II. KIỂM THỬ CHIẾN LƯỢC.......................................................................................................29
1. Mục tiêu và định nghĩa............................................................................................292. Lập bảng kế hoạch và các yêu cầu kiểm thử - Testing plan and Testing requirement........................................................................................................................313. Kiểm thử game và công nghệ kiểm thử - Game testing and testing technique.......32
a. Các thành phần và cấu trúc chi tiết của game......................................................32b. GAME TESTING TECHNIQUES AND “TIPS-N-HINTS”..............................34c. SPECIAL CONSIDERATIONS FOR GAME TESTING...................................36
4. Test plan development for game testing..................................................................365. Software testing and testing techniques...................................................................37
6. Testing considerations for software testing.........................................................397. Kiểm thử toàn chu trình...........................................................................................40
PHẦN III: QUY TRÌNH KIỂM THỬ TRONG CÔNG NGHIỆP........................................................41I. GIỚI THIỆU VỀ CÔNG TY......................................................................................................41
PHẦN IV: VẬN DỤNG VÀO VIỆC KIỂM THỬ GAME CỜ TƯỚNG...................................................48I. TỔNG QUAN HỆ THỐNG VÀ MODULE KIỂM THỬ..........................................................48
1. Mô tả bài toán..........................................................................................................482. Mô tả hệ thống.........................................................................................................483. Các thành phần chính...............................................................................................494. Mô hình thiết kế tổng thể.........................................................................................50
II. TIẾN HÀNH KIỂM THỬ..........................................................................................................581. Mục đích.................................................................................................................582. Yêu cầu giao diện....................................................................................................583. Tình huống kiểm thử và kết quả..............................................................................59
PHÂN CÔNG CÔNG VIỆC TRONG NHÓM............................................................................................62PHẦN IV: TỔNG KẾT...............................................................................................................................63Các tài liệu tham khảo..................................................................................................................................64
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!
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ử.
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 .
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Ử UNITKiể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ử:
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
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ệ.
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
Độ 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.
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.
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ị
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
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
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
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ử,
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ẬNKiể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.
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:
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ỳ
chọn
1 Project Code Dự án hay sản phẩm bị mắc
một lỗiB
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
16 Assigned to Người chịu trách nhiệm sửa lỗi, T
thường là tác giả
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
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
IntegrityVấ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ụ
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ư
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
Management01-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
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
Management
10-QT Lựa chọn nhà thầu phụ không
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
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ĩaKiể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
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.
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
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
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.)
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…
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
đò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 testingCó 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ả.
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 techniquesa. 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
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
Game Tester and love of the game
Burning CDs
6. Testing considerations for software testinga. 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
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ìnhMụ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).
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
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 Tool test đã và đang
được phát triển sau:
STT Tên chương Mã Mô tả OS Phân loại
trình nguồn1 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 SysTrayTimer
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
7 Intel Thread Thương Kiểm tra các vấn đề khi chạy Multi Win & Analysis
Checker mại Thread như truy cập bộ nhớ, không đồng bộ, deadlock, etc.
Linux
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=0 hoặ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òn 1 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 stability
Win Others
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, chỉ cần bấm vào icon tương ứng để chuyển cấu hình mạng. Các thông
Win Management
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 quan trọng Bookmark các OID cần thiết
Win & Linux
Management
26 AutoIT 27 Doxygen 28 InstallJamm
erMiễ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
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ánCờ 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ốngChế độ 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.
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ờ…
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ínhstruct 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
để 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ứcstatic 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 PheXá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
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ínhpublic 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
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
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 DangChoiTrạ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)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 DanhDauQuâ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 ChapXác định có mở chức năng chấp cờ hay
không(chấp => Chap=True)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 NhacNenBật, tắt nhạc nền (bật =>
NhacNen=true)
public static bool TinhThoiGianThiế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 Ocopublic static void DatQuanCo(Object sender,
QuanCo q, int i, int j)Đặt quân cờ q vào vị trí [i,j]
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,
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 đíchKiể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
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
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
Xin đi lại nước Khi mới mở ván cờ, Thông báo không Bug:
nhấn nút xin đi lại
nước
thành công 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 con cờ đượ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
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ế
Ok
chiếu bí hay không ,
nếu có hiện thông báo
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
PHẦN IV: TỔNG KẾTKiể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.
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