ทำการทดสอบ 65.000.000.000 ที่จะเรียกใช้

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

คุณเคยทำงานในโครงการที่มีคุณสมบัตินี้หรือไม่?

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

คุณควรทดสอบคลาสที่เทียบเท่าแทน สิ่งนี้จะลดช่วงการทดสอบของคุณลงอย่างมาก

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

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

หากนี่เป็นชุดทดสอบจริงคุณไม่ต้องการทำงานใกล้ ๆ

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

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

คุณควรบอกผู้ที่กำลังคิดที่จะทำการทดสอบ 65 พันล้านชุดว่าพวกเขาจำเป็นต้องทดสอบการสรุปงานที่ดีขึ้นในคลาสที่เท่าเทียมกัน

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

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

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

คุณไม่สามารถแก้ปัญหานี้ได้ด้วยการเขียนการทดสอบ 3000 ครั้งต่อครั้งและผ่านการทดสอบ นั่นคือความวิกลจริต; โดยปกติแล้วการออกกำลังกายจะใช้เวลาระหว่างหนึ่งถึงสองชั่วโมงและคุณจะไปที่นั่นเพื่อทดสอบค่าแต่ละค่าของแต่ละวัน แต่คุณฉลาด คุณเริ่มต้นด้วยกรณีพื้นฐานที่ง่ายที่สุด (1 == "ฉัน") ใช้งานโดยใช้กลยุทธ์ "รหัสน้อย" ( return "I";) แล้วมองหาวิธีที่รหัสที่คุณมีจะทำงานไม่ถูกต้องในสถานการณ์ที่คาดหวังอีกครั้ง (2 == " ครั้งที่สอง ") ล้างและทำซ้ำ; มากกว่าที่เป็นไปได้คุณเปลี่ยนการใช้งานครั้งแรกของคุณด้วยบางสิ่งที่ทำซ้ำอักขระ "I" บ่อยครั้งเท่าที่จำเป็น (เช่นreturn new String('I',number);) นั่นจะผ่านการทดสอบ III อย่างชัดเจนดังนั้นคุณจึงไม่ต้องกังวล คุณเขียนข้อสอบแทน 4 == "IV" ซึ่งคุณรู้ว่าการใช้งานในปัจจุบันชนะ '

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

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

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

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

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

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

ลิงก์ arstechnicaนี้อาจหรืออาจไม่แสดงข้อมูลเชิงลึกเกี่ยวกับข้อควรพิจารณาในการทดสอบของคุณ โดยทั่วไปจะใช้กลุ่ม GPU สำหรับรหัสผ่านการถอดรหัสแบบเดรัจฉาน หนึ่งที่อ้างถึงในบทความสามารถcan cycle through as many as 350 billion guesses per secondเพื่อให้ชนิดของการทดสอบ 65B ของคุณในมุมมอง อาจเป็นโดเมนที่แตกต่างกัน แต่มันแสดงให้เห็นว่าการเข้าหางานจากมุมที่แตกต่างกันอาจให้ผลที่ได้

ผมไม่คิดว่ามันเป็นไปได้ที่จะรักษา 6.5e + 10 การทดสอบมันเป็นสถานที่แรกดังนั้นการทำงานพวกเขาอาจจะเป็นที่สงสัย แม้แต่โครงการที่ใหญ่ที่สุดเช่น Debian ที่มีแพ็คเกจทั้งหมดมีเพียง SLOCs หลายร้อยล้านเท่านั้น

แต่ถ้าคุณต้องทำการทดสอบจำนวนมากอยู่ดีมีกลยุทธ์เล็กน้อย

• อย่าเรียกใช้พวกเขาทั้งหมด ส่วนใหญ่อาจไม่ทุกการทดสอบขึ้นอยู่กับทุกเส้นทางรหัส กำหนดการอ้างอิงระหว่างระบบย่อยและการทดสอบและระหว่างชุดการทดสอบและคุณจะสามารถเรียกใช้การทดสอบหน่วยที่เกี่ยวข้องกับการเปลี่ยนแปลงเฉพาะเท่านั้นการทดสอบการรวมขึ้นอยู่กับการทดสอบหน่วยเหล่านี้ ฯลฯ

• เรียกใช้พวกเขาในแบบคู่ขนาน ด้วยรหัสฐานที่มากคุณอาจมีฟาร์มสร้างขนาดใหญ่ (ย้อนกลับไปที่ JetBrains การดำเนินการที่ค่อนข้างเล็กเราเคยมีตัวแทนสร้าง 40-50 ตัวที่ทำงานในฟาร์มสร้าง / รวมต่อเนื่อง IDEA เพียงอย่างเดียว) เนื่องจากการทดสอบหน่วยมีความเป็นอิสระและการทดสอบการรวมสามารถใช้รหัสที่สร้างขึ้นใหม่แล้วการทดสอบจึงค่อนข้างง่ายที่จะขนานกัน

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

คำเตือน: ฉันไม่ใช่วิศวกรทดสอบมืออาชีพ เอาเม็ดเกลือข้างบนไปด้วย

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

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