วิธีแก้ปัญหาหรือทดสอบรหัสใหม่อย่างมีประสิทธิภาพเมื่อการตั้งค่าฮาร์ดแวร์เพื่อสร้างข้อบกพร่องเป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะได้รับ?

ฉันทำงานที่ บริษัท ขนาดกลาง (พนักงาน 150 คน, ทีมวิศวกรขนาด 10 ~ คน) และโครงการส่วนใหญ่ของฉันเกี่ยวข้องกับการเชื่อมต่อกับอุปกรณ์ห้องปฏิบัติการ (oscilloscopes, เครื่องวิเคราะห์สเปกตรัมแบบออปติคอล ฯลฯ ) เพื่อวัตถุประสงค์ในการทดสอบแบบกึ่งอัตโนมัติ ฉันพบสถานการณ์ที่แตกต่างกันสองสามอย่างซึ่งฉันไม่สามารถแก้ไขปัญหาหรือทดสอบรหัสใหม่ได้อย่างมีประสิทธิภาพเพราะฉันไม่ได้ตั้งค่าฮาร์ดแวร์ให้ฉันอีกต่อไป

ตัวอย่าง 1:การตั้งค่าที่กระบวนการ 10-20 "เบิร์นอิน" ทำงานอย่างอิสระโดยใช้เซ็นเซอร์ประเภทท็อปบัลลังก์ - ฉันสามารถรับเซ็นเซอร์หนึ่งตัวสำหรับการทดสอบและสามารถขโมยวินาทีในการจำลองการเชื่อมต่อทั้งหมดเพื่อจำลอง อุปกรณ์หลายอย่าง (การค้นหาการเชื่อมต่อการสตรีม ฯลฯ )

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

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

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

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

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

ฉันเคยเขียนซอฟต์แวร์ราคา $ 60 ล้านเครื่องบิน เห็นได้ชัดว่ามีความน่าเชื่อถือในระดับสูงและพวกเขาก็ลังเลที่จะให้นักพัฒนาทุกคนสำหรับโต๊ะทำงานของพวกเขา โดยทั่วไปเรามีสภาพแวดล้อมการทดสอบ 5 ระดับโดยมีฮาร์ดแวร์จริงมากขึ้นในแต่ละระดับจนถึงเครื่องบินเต็ม ฉันประมาณ 95% ของซอฟต์แวร์ของเราสามารถพัฒนาและดีบั๊กได้เฉพาะกับอีมูเลเตอร์และการทดสอบหน่วย 95% ของฟีเจอร์ที่เหลือสามารถใช้งานได้ในระดับต่อไปเป็นต้น

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

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

ตัวอย่างเช่นคุณอาจมีข้อบกพร่องและคุณสามารถคิดถึงสาเหตุที่เป็นไปได้ 10 ข้อ หากครั้งเดียวที่คุณสามารถขึ้นเครื่องได้คือ 15 นาทีในขณะที่ผู้ปฏิบัติงานหยุดพักให้เขียนย่อ, บรรจุเอง, ถูกต้อง (คอมไพล์ได้), ตัวอย่างที่ทริกเกอร์บั๊กและเขียนการทดสอบอัตโนมัติ 10 รายการโดยใช้ SSCCE เพื่อทดสอบทฤษฎีของคุณ และบันทึกมัดข้อมูล หลังจากกลับมาที่โต๊ะทำงานของคุณคุณสามารถใช้เวลานานเท่าที่คุณต้องการกลั่นกรองข้อมูลสำหรับความพยายามครั้งต่อไป แนวคิดคือการใช้ประโยชน์สูงสุดจากเวลาที่ จำกัด ด้วยฮาร์ดแวร์

คุณกำลังพยายามแก้ปัญหาที่ไม่ใช่ของคุณที่จะแก้ไข

ฝ่ายบริหารจำเป็นต้องจัดลำดับความสำคัญการเข้าถึงอุปกรณ์ นั่นอาจหมายถึงคุณท้ายด้วยการเข้าถึงที่มากขึ้น แต่ก็อาจหมายความว่าคุณท้ายด้วยน้อย

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

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

คุณเข้ารหัสคนตาบอดได้อย่างมีประสิทธิภาพ

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

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

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

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

• คุณคาดหวังความพยายามในการพัฒนาเท่าไหร่สำหรับการเขียนโปรแกรมจำลองอุปกรณ์? (โปรดทราบว่าตัวจำลองอุปกรณ์ไม่สามารถแทนที่ฮาร์ดแวร์ดั้งเดิมได้ 100% โดยเฉพาะอย่างยิ่งเมื่อฮาร์ดแวร์มีข้อผิดพลาดที่ไม่คาดคิด)

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

• ฮาร์ดแวร์เพิ่มเติมสำหรับการทดสอบราคาเท่าไหร่

• คุณคาดหวังเวลาเท่าไหร่ที่คุณจะต้องปิดกั้นฮาร์ดแวร์เพื่อการทดสอบ?

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

นำเสนอผลลัพธ์ให้ผู้บริหารของคุณอภิปรายทางเลือกแล้วให้พวกเขาตัดสินใจ