Cách tốt nhất để kiểm tra các trường hợp đơn giản trong trò chơi

Khi thiết kế và chơi thử một trò chơi mới, nhiều lúc, những người dùng thử chức năng đã quen với mọi thứ và không còn thử "những cách ngu ngốc" nữa. Vì vậy, nếu sự phát triển phá vỡ một cái gì đó, nó có thể là một tính năng chỉ người dùng mới sẽ cố gắng thử. Một số cách tốt nhất để đảm bảo rằng trò chơi của bạn có "trường hợp ngu ngốc" được thử nghiệm khi cuối cùng nó được phát hành, hoặc sau một bản cập nhật lớn? Phương pháp, hỗ trợ phần mềm, thậm chí có thể là các trang web nơi mọi người sẽ chơi thử nghiệm cho bạn, et ceteras.

Một vài điều tôi muốn nói là quan trọng:

Khuyến khích kiểm tra đơn vị lập trình

Điều này sẽ đảm bảo rằng một số lỗi ngu ngốc nhất định, nếu có một bài kiểm tra đơn vị cho chúng, sẽ không tái diễn, vì bài kiểm tra đơn vị sẽ thất bại nếu chúng xảy ra. Điều này đòi hỏi một sự thay đổi trong phương pháp lập trình, nhưng theo tôi nó hoàn toàn xứng đáng.

Tự động hóa bất cứ thử nghiệm nào bạn có thể

Ngoài kiểm thử đơn vị, tạo một tập hợp các chức năng tự động và kiểm tra chấp nhận được chạy trên mọi bản dựng để đảm bảo các bản dựng nhất định là tốt. Nếu bạn có các điều khiển theo kịch bản và trò chơi của bạn thường nhất quán, bạn có thể tự động kiểm tra rất nhiều lỗi.

Tạo một kế hoạch kiểm tra đa cấp

Hãy chắc chắn rằng người kiểm tra của bạn có một kế hoạch kiểm tra kiểm tra các lỗi quan trọng nhất. Điều này nên được đa cấp:

• Kiểm tra khói: Kiểm tra rằng trò chơi không gặp sự cố trong các trường hợp phổ biến nhất.
• Kiểm tra thường xuyên: Kiểm tra các trường hợp không phổ biến hơn.
• Kiểm tra ngâm: Chạy càng sâu càng tốt, hồi quy càng nhiều lỗi phổ biến càng tốt. Cũng kiểm tra rằng trò chơi có thể duy trì trong thời gian rất dài (ngày) mà không gặp sự cố.

Tạo kế hoạch kiểm tra này và làm theo nó trên mỗi bản dựng.

Một cách tiếp cận bảo hiểm mã cho các trường hợp thử nghiệm có thể được thực hiện bằng cách sử dụng các cờ đơn giản được ngắt ba lần khi khối mã được thực thi trong trò chơi. Hiển thị những lá cờ nào bị vấp và chưa được dán trên màn hình có thể cho phép người kiểm tra biết trường hợp nào đã được che và trường hợp nào không.

Đơn giản như vậy, nó vẫn hiệu quả miễn là các cờ có tên có ý nghĩa để người kiểm tra có thể tìm ra những gì cần phải làm.

Kỹ thuật này được ghi nhận cho Matthew Jack, người đã thực hiện nó ở Crysis.

Một số câu trả lời tốt ở đây về phía lập trình. Tôi sẽ thêm một cái theo định hướng thiết kế hơn.

Yêu cầu các nhà thiết kế hệ thống của bạn viết kế hoạch kiểm tra trường hợp cạnh cho người kiểm tra

Nếu họ biết những gì họ đang làm, người đứng sau thiết kế một hệ thống, hoặc viết kịch bản trong chuỗi trò chơi, rất có thể biết các trường hợp cạnh của hệ thống đó và nơi nó có thể bị hỏng. Họ cũng nên có một ý tưởng về nơi hệ thống tương tác với những người khác. Yêu cầu họ viết ra một kế hoạch kiểm tra, hoặc thảo luận với những người kiểm tra, nơi mọi thứ có thể sai, có thể tiết kiệm thời gian cho mọi người.

Bạn nên điều tra cái gọi là Thử nghiệm Khỉ. Nó có thể bắt được rất nhiều lỗi thuộc loại này:

https://secure.wik mega.org/wikipedia/en/wiki/Monkey_test

Bạn cũng cần tổ chức thử nghiệm trải nghiệm người dùng với "Kleenex testers", những người thử nghiệm lần đầu tiên nhìn thấy trò chơi của bạn và bạn sẽ không bao giờ sử dụng lại. Nó hơi tốn kém và phức tạp để tổ chức, nhưng cũng đáng nỗ lực. Nếu bạn làm như vậy, hãy quay mọi bài kiểm tra với 3 camera: một trên màn hình, một trên các điều khiển và một trên mặt của người kiểm tra để phát hiện sự thất vọng.

Câu hỏi tuyệt vời, mỗi phản hồi trong chủ đề này là một phản ứng xuất sắc. Một điều cần thêm:

Theo kinh nghiệm của tôi (30 năm phát triển phần mềm): các ứng dụng và trò chơi đáng tin cậy hơn nếu ít nhất một thành viên của nhóm thử nghiệm là một người thử nghiệm khỉ đột lành nghề , thành thạo kiểm tra đột xuất, lạm dụng các ứng dụng và cố tình sử dụng các trò chơi sai cách lỗi của các loại được mô tả bởi các poster ban đầu. Những người thử nghiệm Gorilla có một kỹ năng không phổ biến - khi bạn tìm thấy một người giỏi, hãy giữ họ trong đội của bạn.

Để biết ví dụ về thử nghiệm khỉ đột hiệu quả, hãy xem: www.youtube.com/watch?v=8C-e96m4730;)

Để tổng hợp các câu trả lời trong chủ đề này: các chiến lược chất lượng phần mềm hiệu quả là nhiều mặt , kết hợp nhiều cách tiếp cận để đạt được mức độ tin cậy cao về chất lượng chức năng và độ tin cậy của trò chơi của bạn.

Một mẹo thú vị tôi đã nghe từ một người bạn để kiểm tra đồ họa; trong một lần chạy tốt đã biết thông qua một số liệu thống kê hiệu suất kỷ lục từ GPU theo các khoảng thời gian đều đặn (ví dụ như màn hình trên màn hình). Sau đó, bạn có thể phát lại tuyến đường đó và nếu các số thay đổi ngoài dung sai cho trước, điều đó có thể có nghĩa là một cái gì đó không hiển thị chính xác nữa.

Một điều đơn giản dễ dàng giúp ích rất nhiều, đặc biệt là kiểm tra căng thẳng và kiểm tra mạng. Làm cho AI của bạn có thể chơi với AI khác. Nếu bạn có thể để trò chơi của mình chơi một mình, hoặc một nhóm nhỏ AI qua mạng vào cuối tuần, bạn có thể học được rất nhiều điều.

Tất nhiên đăng nhập mọi thứ.