กลยุทธ์การทดสอบเกม

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

เกมดังกล่าวได้มาถึงจุดที่มันเริ่มซับซ้อน มีสองโหมดที่แตกต่างกันสำหรับแต่ละเกมและเกมจะทำงานแตกต่างกันไปตามโหมด นอกจากนี้ยังมีธงต่าง ๆ ที่ส่งผลต่อการเล่นเกม

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

เมื่อพูดถึงเกมฉันหลงทาง ฉันจะทดสอบพวกเขาได้อย่างไร ฉันมีผู้ทดสอบให้ฉัน ฉันสามารถใช้เวลาเขียนแบบทดสอบหน่วย

ผู้ทดสอบ ... ไม่น่าเชื่อถือ พวกเขาไม่ได้ดีที่สุดในการขจัดปัญหาและฉันไม่ได้ให้ทิศทางที่ดีที่สุดแก่พวกเขา ใช้เวลาไม่นานในการทดสอบการปล่อยและการรวมกันของเกมทุกครั้งฉันจะใช้มันเป็นทรัพยากรได้อย่างไร

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

นั่นเป็นกลยุทธ์ที่ดีที่สุดเหรอ? บริษัท เกมทำการทดสอบเกมอย่างไร

ฉันได้อ่านคำถาม " ทดสอบการพัฒนาเพื่อรองรับเกมที่ซับซ้อน " (ท่ามกลางเกมอื่น ๆ ในไซต์) แต่ไม่ได้กล่าวถึงสิ่งที่ฉันกำลังมองหา ฉันขอกลยุทธ์ไม่ใช่ตัวอย่างเฉพาะของวิธีทดสอบ

ในโลกธุรกิจอัลกอริทึมจะทำหน้าที่ในลักษณะเดียวกันเสมอ ฉันจะเขียนการทดสอบหน่วยสำหรับอัลกอริทึมฉันจะคาดหวังค่า 42 และมันจะผิดพลาดถ้าฉันไม่ได้รับค่านั้น

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

ด้วยโหมดและค่าสถานะที่มากเกินไปเกมสามารถทดสอบได้อย่างรวดเร็วยากเนื่องจากจำนวนตัวแปรที่เป็นไปได้ เพื่อลดความเสี่ยงของการประสบปัญหานี้ แต่เนิ่นๆคุณควร:

• จำลอง / ต้นขั้วอย่างรุนแรง ทำให้ชิ้นส่วนที่ผ่านการทดสอบมีขนาดเล็กและจำลองทุกอย่างที่พวกเขาไว้

  หากพวกเขาพึ่งพาเวลาจำลองวัตถุเวลาเพื่อให้ผลลัพธ์ที่เฉพาะเจาะจงหรือชุดของผลลัพธ์ที่เฉพาะเจาะจงเป็นอิสระจากเวลาที่เกิดขึ้นจริง

  หากพวกเขาไว้วางใจrandom()ให้จำลองไปมาเพื่อให้ค่าคงที่ทุกครั้ง

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

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

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

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