การทดสอบอัตโนมัติของเกม [ปิด]


54

มีวิธีทดสอบเกมอัตโนมัติหรือไม่

ประสบการณ์ที่เฉพาะเจาะจงได้รับการชื่นชมพร้อมกับข้อมูลที่เกี่ยวข้องเกี่ยวกับโครงการเช่นแพลตฟอร์มและประเภทของเกมหากมีส่วนช่วยในการชี้แจง

คำตอบ:


74

เกมอิสระหนึ่งคน มันเป็นเกมรถถังที่มีผู้เล่นหลายคนพร้อมภูมิประเทศที่สามารถทำลายได้และภูมิประเทศที่สามารถทำลายได้และรหัสการชนพิสูจน์ได้ว่าค่อนข้างไม่สม่ำเสมอ

ฉันลงเอยด้วยการตั้งค่าพื้นฐาน AIs แบบใบ้ (โดย "โง่" ฉันหมายถึง "งี่เง่าอย่างแน่นอน" - พวกเขาจะสุ่มเลือก "ขับไปยังรถถังศัตรู", "ขับออกจากถังศัตรู" และ "ขับในทิศทางสุ่ม "ในขณะที่ยิงอาวุธหลักแบบสุ่ม) และเล่นเกมด้วยอัตราเฟรมสูงสุดขณะบันทึกปุ่มกด ฉันได้เวลาจริงประมาณ 10-15 เท่า รหัสถูกยืนยันอย่างหนักดังนั้นหากมีสิ่งใดผิดพลาดมันจะทิ้งบันทึกการกดคีย์ทั้งหมดไปยังดิสก์พร้อมกับรายงานข้อผิดพลาดและการสุ่มเริ่มต้น จากนั้นฉันสามารถไปและเล่นบันทึกการกดแป้นซ้ำเพื่อทำซ้ำสถานะอย่างแน่นอนหรือเพียงแค่ดีบักจากรายงานข้อผิดพลาด

ฉันปล่อยให้มันทำงานอย่างต่อเนื่องเป็นเวลาหลายเดือน ในตอนแรกมันแทบจะไม่ได้ชั่วโมงเลยโดยไม่ต้องหยุดทำ - ฉันต้องนั่งที่นั่นและดูแลมันเป็นเวลาหนึ่งสัปดาห์ฆ่าแมลงที่คลุมเครือหลายครั้งต่อวัน ในที่สุดมันก็มาถึงจุดที่มันใช้งานเป็นเวลาหนึ่งสัปดาห์ระหว่างความล้มเหลวซึ่งแปลว่าประมาณ 1,500 ชั่วโมงผู้เล่นต่อความผิดพลาด

มันมีค่ามากและฉันก็แนะนำอย่างเต็มที่


1
ลื่นจริงๆ! คีย์ล็อกคือชัยชนะที่แท้จริง
David McGraw

1
ฉันสับสน: "การเพิ่มค่า AIs แบบใบ้พื้นฐาน" และ "การบันทึกการกดแป้นพิมพ์" - ใครคือผู้กดปุ่ม ฉันคิดว่าคุณปล่อยให้ AI ของคุณเล่นด้วยตัวเองโดยไม่มีมนุษย์คนใด? คุณปล่อยให้ AI ของคุณเล่นเกมโดยจำลองปุ่มกดแทนการเรียกฟังก์ชั่น API หรือไม่ ตอนนี้มันจะลื่น!
Dave O.

4
@ Dave ใช่ฉันจะยอมรับว่ามันอาจทำให้สับสน AIs ได้รับการออกแบบมาเพื่อให้ผลลัพธ์ทั้งหมดผ่านตัวควบคุมแบบจำลอง พวกเขาใช้สถานะเกมเป็นอินพุต แต่ไม่ได้แก้ไขสถานะของเกมในแบบใด ๆ นี่อาจเป็นความคิดที่น่ากลัวด้วย UI ของเมาส์ แต่อินเทอร์เฟซทั้งหมดทำกับ gamepads ดังนั้นมันจึงน่าเกลียดเล็กน้อย แต่ใช้งานได้ ฉันบันทึกการกดแป้นพิมพ์เสมือนจริงของ AIs และนอกจากนี้รหัสเดียวกันบันทึกการกดแป้นจริงเมื่อทดสอบกับเพื่อน ๆ
ZorbaTHut

32

สำหรับ MMO ที่ฉันทำงาน (นักพัฒนา 100ish เน้นไปที่พีซี) เราพยายามเพิ่มการทดสอบอัตโนมัติที่หลากหลายด้วยความสำเร็จที่แตกต่างกัน นี่คือสิ่งที่ทำงาน:

  • การทดสอบขั้นพื้นฐานระหว่างกระบวนการสร้างอัตโนมัติของเรานั้นเป็นชัยชนะครั้งใหญ่ สิ่งนี้รวมถึงงานต่าง ๆ เช่นการสร้างตัวละครการถ่ายโอนแผนที่การทดสอบ UI แบบสคริปต์ได้และค้นหาพฤติกรรมที่คาดหวัง สิ่งนี้จับข้อผิดพลาดจำนวนมากก่อนที่พวกเขาจะไปถึง บริษัท ที่เหลือ
  • ในตอนท้ายของโครงสร้างพื้นฐานเซิร์ฟเวอร์เราได้พัฒนาการทดสอบอัตโนมัติที่แตกต่างกันมากมายซึ่งจำลองการทำธุรกรรมเซิร์ฟเวอร์ MMO ทั่วไป จากนั้นเราสามารถเล่นสิ่งเหล่านี้ภายใต้สถานการณ์ที่หลากหลายเพื่อเปรียบเทียบประสิทธิภาพหรือเพื่อความปลอดภัย เมื่อเวลาผ่านไปการทดสอบเหล่านี้มีความแม่นยำมากขึ้นเรื่อย ๆ จนกระทั่งกลายเป็นการเล่นข้อมูลสดที่บันทึกไว้
  • เราเขียน "ผู้เล่นปลอม" ที่จะสุ่มท่องไปทั่วโลกกระโดดฆ่าและพูดแบบสุ่มในการแชท พบปัญหาฟิสิกส์และโครงสร้างพื้นฐานจำนวนมาก

สิ่งที่ไม่ทำงาน:

  • เราพยายามที่จะเพิ่มการทดสอบอัตโนมัติที่มุ่งเน้นการต่อสู้ไปยังเครื่องมือสร้างอัตโนมัติ แต่สิ่งนี้ไม่ได้ผล มันจะใช้งานได้ประมาณ 3 วันหลังจากนำไปใช้งานจนกว่าผู้ออกแบบหรือศิลปินจะเปลี่ยนแปลงบางสิ่งและการทดสอบจะล้มเหลว 90% ของเวลาไม่ใช่ปัญหาจริง การทดสอบเหล่านี้มีความเปราะบางเกินไปและการทดสอบการเล่นเกมที่เฉพาะเจาะจงบนแผนที่เฉพาะที่มีพลังเฉพาะสามารถทำให้ไม่สามารถทำลายได้
  • เราพยายามใช้การทดสอบประสิทธิภาพอัตโนมัติที่จะเปรียบเทียบประสิทธิภาพของไคลเอ็นต์ (ค่าเฉลี่ย FPS และอื่น ๆ ) กับประสิทธิภาพที่บันทึกไว้เมื่อสัปดาห์ที่แล้ว นี่เป็นเรื่องที่ค่อนข้างบอบบางเนื่องจากการสาธิตที่เราใช้ในการทดลองนี้มักจะเน่าค่อนข้างบ่อยและเป็นการยากที่จะตรวจสอบว่าการชะลอตัวเกิดจากการสูญเสียประสิทธิภาพจริงหรือผลข้างเคียงบางส่วนของกระบวนการทดสอบ

18

ทำงานในเกมกลยุทธ์ 4x พร้อมการต่อสู้ 3 มิติ (คิดว่าโฮมเวิร์ลดพบกับ Masters Of Orion) ที่น่าเสียดายที่ไม่เคยเห็นแสงสว่างของวันเมื่อ บริษัท หมดเงินทุน ..

ฉันมั่นใจเสมอว่าคุณสามารถเล่นเกมได้โดยไม่ต้องมีผู้เล่นที่เป็นมนุษย์ดังนั้นเราจึงสามารถออกจากเกมได้ในชั่วข้ามคืน

เราสามารถปิดการต่อสู้ 3 มิติ (ลดความซับซ้อนลงเป็นผลการสุ่ม) และเราออกจากเครื่องมือกลยุทธ์ AI ที่เล่นด้วยตัวเอง พบข้อบกพร่องและปัญหามากมาย ไม่เพียง แต่แสดงข้อบกพร่องของตัวหยุด แต่ข้อผิดพลาดด้านกลยุทธ์ที่กลยุทธ์ AI (เช่น) จะได้รับการหยุดชะงักและใช้จ่าย 1,000 รอบของการไม่ทำ "สิ่งที่ถูกต้อง" การเรียงลำดับของข้อบกพร่องเหล่านี้ยากที่จะมองเพียงแค่ "เล่นเกม"


อืมฉันคงไม่คิดว่านี่เป็นการทดสอบอัตโนมัติ - แต่ฉันคิดว่าคุณพูดถูก ฉันทำสิ่งเดียวกันมาสองสามปีแล้วไม่เคยคิดแบบนั้น
mmyers

13

สำหรับนักกีฬาคนแรกที่ฉันทำงาน (Descent 3 - linux / mac / windows, ประมาณ 30 คนในทีมในปี 1999) ความสามารถในการบันทึก / สาธิตการเล่นกลายเป็นประโยชน์อย่างมาก ฉันสร้างตัวเลือกที่คุณสามารถเล่นการสาธิตได้อย่างเร็วที่สุดเท่าที่เกมจะทำการเรนเดอร์เฟรมและนั่นก็เป็นวิธีที่ยอดเยี่ยมในการตรวจสอบประสิทธิภาพหลังจากสิ่งต่าง ๆ เปลี่ยนไป

นอกจากนี้ยังใช้รหัสจำนวนมากนอกเหนือจากระบบการแสดงผลดังนั้นจึงเป็นการตรวจสอบที่ดี หลังจากทำการเปลี่ยนแปลงมากมายฉันก็สามารถเล่นการสาธิตการเล่นเกม 10 นาทีของการเล่นเกม หลายครั้งที่มันจะจับแมลงในบริเวณที่ฉันไม่คิดว่าจะตรวจสอบตัวเอง


8

เรามีปืน openworld (x360, PS3, PC) ที่ใช้ smoketest อย่างรวดเร็วบน build server - มันโหลดเกมก้าวผ่านส่วนหน้าวิ่งไปทางด้านหน้าส่งภาพหน้าจอแล้วออก หาก cctray ตรวจพบว่าการออกจากระบบอย่างสมบูรณ์การสร้างนั้นสำเร็จ

เราวิ่งมาประมาณปีสุดท้ายของโครงการและมีขนาดทีมประมาณ 100 devs

มันมีประสิทธิภาพในการจับบั๊ก showstopping แต่มันง่ายที่จะสร้างบิลด์ที่ผ่าน smoketest แต่ล้มเหลวในระดับ "ของจริง" ส่วนใหญ่หรือใช้งานไม่ได้กับผู้เล่นหลายคนหรือเป็น AI ที่ยอดเยี่ยมดังนั้นจึงไม่สมบูรณ์ มันคุ้มค่าที่จะทำอย่างแน่นอน

ฉันได้ยินมาตั้งแต่ฉันออกจากพวกเขาเริ่มใช้ smoketests ขนาดใหญ่ออกไปทำไร่ไถนากับพีซีหลายเครื่อง เห็นได้ชัดว่าการบำรุงรักษา smoketests เป็นปัญหาและมีทีมเล็ก ๆ ที่ทุ่มเทให้กับการสร้างเซิร์ฟเวอร์และซอฟต์แวร์ที่ได้รับการดูแลดังนั้นฉันไม่สามารถบอกได้ว่ามันประสบความสำเร็จหรือไม่


6

ประสบการณ์ของฉันกับการทดสอบอัตโนมัติในระหว่างการพัฒนา Crysis 2 มีให้ที่นี่: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

สรุป:

  • การทดสอบอัตโนมัติปรับปรุงเสถียรภาพของการส่งมอบเพิ่มประสิทธิภาพการผลิตสำหรับทั้งผู้สร้างเนื้อหาและวิศวกร
  • การทดสอบอัตโนมัติเป็นเครื่องมือที่มีประสิทธิภาพในการปรับปรุงคุณภาพรหัสและลดโอกาสในการทำงานล่วงเวลา
  • อุตสาหกรรมเกมโดยรวมนั้นค่อนข้างมีปฏิกิริยาตอบสนองโดยทั่วไปการทดสอบอัตโนมัติตรงตามข้อโต้แย้งที่ไม่สมเหตุสมผลหลายประการ
  • อย่าเรียกว่าการทดสอบเรียกมันว่าอย่างอื่นเกือบทุกอย่าง (ดูที่พฤติกรรมขับเคลื่อนการพัฒนา)
  • มีความยืดหยุ่นการเขียนการทดสอบที่ดีนั้นยากและต้องใช้ทักษะที่ไม่สามารถใช้ได้อย่างกว้างขวางในอุตสาหกรรมเกม

2

การพัฒนาเกมเป็นจริงหนึ่งในกรณีที่การทดสอบหน่วยดูเหมือนจะเหมาะสมสำหรับฉันเพราะปฏิสัมพันธ์ระหว่างระบบแยกเป็นเรื่องธรรมดา แน่นอนการออกแบบโดยสัญญาเป็นส่วนหนึ่งของเรื่องนี้และควรได้รับการวางแผนตั้งแต่วันแรกของการพัฒนา แต่ฉันไม่เห็นว่าทำไมมันไม่สามารถนำมาใช้ในภายหลังได้โดยสมมติว่าสิ่งที่มีอยู่นั้นมีอยู่จริง

ส่วนที่ยากคือการทดสอบบูรณาการ มีเกมจำนวนมากที่สามารถทดสอบได้โดยสาธิตการวนลูปหรืออะไรบางอย่าง แต่สิ่งนั้นเป็นแนวคิดที่ค่อนข้างง่ายในการแก้ไขข้อบกพร่อง - ที่ฉันสนใจมากขึ้นในการใช้เวลาของฉันคือการเปิดเผยข้อบกพร่องที่จะเกิดขึ้นเมื่อผู้เล่นทำอะไรบางอย่าง ด้วยความคิดที่ว่าบั๊กที่ผู้เล่นไม่เคยเห็นนั้นมีความสำคัญน้อยกว่าบั๊กที่ผู้เล่นทำ

ซึ่งค่อนข้างยากแน่นอน กลยุทธ์ที่ใช้กับแอปพลิเคชั่นอื่น ๆ (fuzzing, คาดการณ์ผ่าน / คาดหวังล้มเหลว ฯลฯ ) ทำงานได้ไม่ดีที่นี่ ในระบบที่ใช้สคริปต์ดูเหมือนว่าการสร้างชุดทดสอบสคริปต์เพื่อจำลองผู้เล่นเป็นวิธีที่จะไป (ดูคำตอบของ JZig) แต่การทดสอบเป็นพิเศษสำหรับสิ่งที่ผู้เล่นอาจพบได้โดยตรงทำให้ฉันเป็นสถานที่ที่ดีที่สุดในการมุ่งเน้นเวลาของคุณสำหรับการทดสอบทั้งแบบมนุษย์และแบบอัตโนมัติ


9
แต่ผู้เล่นไม่เคยทำในสิ่งที่คุณคาดหวังว่าคนที่มีสติจะทำ นั่นเป็นเหตุผลที่คุณไม่เห็นสิ่งต่าง ๆ เช่นลิฟท์บกพร่องใน Call of Duty จนกระทั่งหลังจากปล่อย เพราะมีผู้ชายหลายพันคนทำทุกอย่างที่นักพัฒนาและผู้ทดสอบไม่เคยคิดที่จะลอง ทันทีที่มีคนสร้างแบบจำลองที่สมบูรณ์แบบของนักเล่นเกมอายุ 16 ปีซึ่งครอบงำจิตใจเราจะมาถึงการพัฒนาเกมที่เป็นเอกเทศ :)
Casey Wagner
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.