การทดสอบอัตโนมัติในการพัฒนาเกมเป็นเรื่องธรรมดาแค่ไหน? [ปิด]

นักพัฒนาเกมเมอร์ใช้ในการเขียนการทดสอบหน่วยและการรวม? มันเป็นเรื่องธรรมดาในหมู่นักพัฒนาปริศนา? และในบรรดานักพัฒนาซอฟต์แวร์ MMORPG และ FPS

(ฉันไม่มีพื้นฐานในการพัฒนาเกมและฉันไม่คิดเกี่ยวกับการทำงาน - มันเป็นเพียงข้อสงสัยที่เกิดขึ้นกับฉันดังนั้นไม่จำเป็นต้องพยายามโน้มน้าวให้ฉันเขียนพวกเขาแม้ว่าฉันจะชอบเขียนแบบทดสอบอัตโนมัติ )

โดยทั่วไปการทดสอบหน่วยและการรวมเกมไม่ได้เป็นเรื่องปกติ นี่เป็นเพราะส่วนใหญ่การแสดงผลของเกมมักจะเชื่อมโยงอย่างใกล้ชิดกับส่วนที่เหลือของกลศาสตร์เกมที่มันยากมากที่จะเขียนการทดสอบหน่วยที่ใช้งานได้จริง

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

ในท้ายที่สุดแม้ว่าทั้งหมดนี้ขึ้นอยู่กับสตูดิโอ สตูดิโอบางแห่งจะทำการทดสอบอัตโนมัติในขณะที่บางแห่งอาจจ้างเด็กนักเรียนมัธยมปลาย 20 คนในช่วงฤดูร้อนเพื่อเล่นเกมของพวกเขาเป็นเวลาหลายชั่วโมงเมื่อสิ้นสุด

จากประสบการณ์ของฉันมันไม่ธรรมดา

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

ส่วนหนึ่งเป็นเพราะภาษาที่โดดเด่นในอุตสาหกรรมการพัฒนาเกมคือ C ++ และทำให้การทดสอบหน่วยยุ่งยากกว่าภาษาอื่นเล็กน้อย มีกรอบการทดสอบหน่วยอยู่ แต่ก็ไม่ได้ใช้งานง่ายเหมือนระบบที่คล้ายกันในภาษาที่ทันสมัยกว่าซึ่งสามารถใช้การไตร่ตรองและเทคนิคที่คล้ายกันเพื่อเร่งการตรวจจับกรณีทดสอบให้เร็วขึ้น

นอกจากนี้ยังเป็นเพราะเกมโดยทั่วไปไม่ให้ยืมตัวเองเพื่อทดสอบหน่วย - เหตุผลส่วนใหญ่ขึ้นอยู่กับแหล่งกึ่งกึ่งกำหนด (เช่นฮาร์ดแวร์กราฟิกการกำหนดเวลาอินพุตอัตราเฟรม) ผลลัพธ์ส่วนใหญ่ยากที่จะวัด (เช่น กราฟิกบนหน้าจอเอฟเฟกต์เสียง) และบางอันแทบไม่มีความหมายเลยนอกบริบทของการสร้างเกมเต็มรูปแบบ (เช่น AI ปฏิกิริยาที่ซับซ้อน, การจำลองทางฟิสิกส์) มีข้อยกเว้นมากมายถ้าคุณทำงานอย่างหนักเพื่อสร้างรหัสด้วยวิธีนั้น - แต่ในการทดสอบทั้งหมดนั้นมีราคาแพงกว่าในเกมมากกว่าซอฟต์แวร์ประเภทอื่น ๆ ส่วนใหญ่ดังนั้นอัตราส่วนค่าใช้จ่าย / ผลประโยชน์นั้นน่าสงสัยมาก

สำหรับการทดสอบการรวมฉันไม่เคยได้ยินคำศัพท์ที่ใช้อย่างชัดเจนในการพัฒนาเกม แต่นักพัฒนาหลายคนทำการทดสอบอัตโนมัติของระบบทั้งหมดหากเป็นไปได้ ฉันเดาว่าอาจเป็น 1 ใน 3 ของนักพัฒนามืออาชีพที่ทำสิ่งนี้เนื่องจากไม่ใช่เรื่องง่ายที่จะติดตั้งและเนื่องจากประโยชน์ที่ได้รับจะลดลงเนื่องจากความจริงที่ว่านักพัฒนาซอฟต์แวร์ขนาดกลางถึงขนาดใหญ่ทุกคน แผนกที่จะทำการทดสอบที่คล้ายกันด้วยตนเอง โดยทั่วไปแล้ว QA จะได้รับค่าตอบแทนน้อยกว่านักพัฒนาซอฟต์แวร์ดังนั้นจึงอาจถือว่าเป็นการประหยัดที่จะออกจากการทดสอบกับพวกเขาแทนที่จะลงทุนเวลาพิเศษของรหัส (ที่เป็นที่ถกเถียง.)

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

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

โดยทั่วไปการทดสอบ UI อัตโนมัติ (แม้ในโปรแกรมปกติ) นั้นยากกว่าระบบอัตโนมัติทั่วไป ดังนั้นแม้ว่าคุณสามารถเขียนการทดสอบหน่วยสำหรับเกมของคุณการทดสอบเกมจริงนั้นยากกว่า บริษัท ส่วนใหญ่ใช้ผู้ทดสอบมนุษย์ที่ใช้เวลาเล่นเกมครั้งแล้วครั้งเล่า

ตัวอย่างเช่นนี่คือบทความที่อธิบายวิธีที่พวกเขาทำใน Game Studio ขนาดเล็ก (2 devs) จากสิ่งที่ฉันอ่านดูเหมือนว่าการตรวจสอบความถูกต้องของพวกเขาไม่มีรายละเอียดมาก (ระบบอัตโนมัติเริ่มเกมและบันทึกข้อผิดพลาด / การยืนยัน)

อย่างไรก็ตามบาง บริษัท ประสบความสำเร็จอย่างมากกับระบบกึ่งอัตโนมัติ (เช่น Microsoft Test Studios) นั่นคือผู้พัฒนาหรือ SDET สร้างเครื่องมือที่ทำให้การทดสอบเกมง่ายขึ้นมาก มีการพูดถึง GameFest ที่พวกเขาหารือถึงวิธีการที่พวกเขาได้รับการทดสอบลงโทษสำหรับตัวอย่างหรือนิทาน ตัวอย่างเช่นพวกเขายังคงใช้ผู้ทดสอบที่ตรวจสอบว่าทุกวัตถุเป็นที่ที่ควรจะเป็น แต่พวกเขาใช้เครื่องมือที่ใช้ภาพรวมของสถานที่นั้นเพื่อให้สิ่งที่มนุษย์ทำคือตรวจสอบด้วยสายตาโดยไม่ต้องเล่นเกม

นี่คือการพูดคุยที่ดีเกี่ยวกับประเภทของเครื่องมือที่พวกเขาสร้าง / ใช้ในการทดสอบเกม เรียกว่า "Test Lead Gems: ออกไปข้างหน้าเพื่อเพิ่มความซับซ้อนของเกมของเรา"

ฉันจะเดิมพันว่า MMO และรหัสเซิร์ฟเวอร์แบบผู้เล่นหลายคนได้รับการทดสอบบ่อยขึ้นเล็กน้อย

อย่างน้อยที่สุดการทดสอบการถดถอยอัตโนมัติเป็นเรื่องปกติ ฉันเคยเห็นสิ่งเหล่านี้ถูกนำไปใช้เป็นการตรวจสุขภาพอย่างแท้จริงในระหว่างการเริ่มต้นเซิร์ฟเวอร์เพื่อให้แน่ใจว่าเซิร์ฟเวอร์ "คลาวด์" ใหม่ได้รับการกำหนดค่าอย่างถูกต้องก่อนที่จะเริ่มยอมรับผู้เล่น ชุดการถดถอยที่ค่อนข้างดีซึ่งสร้างมานานกว่า 3-4 ปีในกรณีนั้นวิ่งในเวลาประมาณ 4 วินาทีในขณะที่การนำโฮสต์เสมือน (จากภาพระบบปฏิบัติการว่างเปล่า) ใช้เวลาเกือบ 10 นาทีจึงคุ้มค่ากับเวลา เรารันการทดสอบเดียวกันกับ "tinderbox" (ระบบสร้างอย่างต่อเนื่อง) ในพื้นที่เก็บข้อมูล Subversion ของเราเพื่อตรวจสอบข้อผิดพลาดทั่วไปที่น่ารำคาญและเป็นธรรมที่ชอบคลานกลับโดยเฉพาะอย่างยิ่งฟังก์ชั่นหลายเซิร์ฟเวอร์มีนิสัยที่น่ารังเกียจในการพยายาม สร้างรายการที่ซ้ำกันของวัตถุที่ส่งผ่าน: การสร้างอินสแตนซ์ของวัตถุแคช และรหัสผ่านเครือข่ายใกล้ 100% ครอบคลุม; เราคิดอยู่เสมอว่าเราจะคิดถึงทุกสิ่งที่สามารถทดสอบได้จากนั้นค้นพบเคสใหม่ที่“ สนุก”

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

อย่างไรก็ตามการพัฒนา MMO โดยทั่วไปขึ้นอยู่กับปัญหาเหล่านี้มากขึ้นซึ่งอาจสะท้อนถึงสภาพแวดล้อม เมื่อฉันทำงานเกี่ยวกับระบบเกมฝังตัว“ การทดสอบ” นั้นแทบไม่เคยได้ยินอะไรเลยนอกจากรหัสวิดเจ็ตที่สามารถนำกลับมาใช้ใหม่ได้ (เช่นโปรแกรมแก้ไขข้อความ)

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

ผมมีส่วนร่วมในการอภิปรายโต๊ะกลมเกี่ยวกับการทดสอบอัตโนมัติที่GDC 2011 IIRC มีคนอยู่ในห้องประมาณ 60 คน จนถึงจุดหนึ่งผู้ดำเนินรายการได้ทำการสำรวจความครอบคลุมการทดสอบหน่วย มีคนคนหนึ่งที่อ้างว่าครอบคลุมโค้ดมากกว่า 90% คนอื่นหัวเราะเยาะความคิดของการที่เคยถึง1%ความคุ้มครอง หากกลุ่มนั้นเป็นตัวแทนที่เป็นธรรมของอุตสาหกรรมโดยรวมฉันจะบอกว่าการทดสอบอัตโนมัติโดยทั่วไปจะไม่เกิดขึ้นมากถ้าหากทั้งหมด

คำตอบอื่น ๆ ที่นี่ให้เหตุผลที่ดีว่าทำไม ฉันคิดว่ามันจะมีประโยชน์หากมีบัญชีมือแรก