จะทำอย่างไรกับข้อบกพร่องที่ไม่ได้ทำซ้ำ?

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

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

คุณทำอะไรในสถานการณ์เช่นนี้

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

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

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

อย่างไรก็ตามระยะเวลาที่คุณไปถึงจุดนั้นนั้นเป็นที่ถกเถียงกัน

บางคนอาจโต้แย้งว่าหากไม่สามารถทำซ้ำได้ในทันทีควรปิดทันที

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

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

คำแนะนำเพิ่มเติม:

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

2. สแกนข้อผิดพลาด "no repro" ที่เหลือในฐานข้อมูล (หรืออะไรก็ตามที่คุณใช้สำหรับการติดตามบั๊ก) บ่อยครั้งที่ flukes กอรวมกันในพื้นที่หนึ่งของผลิตภัณฑ์ หากดูเหมือนว่าองค์ประกอบหนึ่งมีข้อผิดพลาดรหัสจะตรวจสอบองค์ประกอบเพื่อหาความไม่แน่นอนที่อาจเกิดขึ้นเพิ่มการบันทึกเพิ่มเติมไปยังองค์ประกอบนั้น - หรือทั้งสองอย่าง

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

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

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

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

มีข้อผิดพลาดสองประเภทที่ไม่สามารถทำซ้ำได้:

1) สิ่งที่ผู้ทดสอบ (หรือผู้ใช้) ได้เห็นครั้งเดียว แต่ไม่สามารถทำซ้ำหรือไม่พยายามทำซ้ำ

ในสถานการณ์เหล่านี้คุณควร:

• ตรวจสอบหลักสูตรพื้นฐานของการกระทำสั้น ๆ อย่างมากซึ่งแสดงว่ามีข้อบกพร่องเพื่อให้แน่ใจว่าไม่สามารถทำซ้ำได้

• พูดคุยกับผู้ทดสอบ / ผู้ใช้เพื่อดูว่ามีข้อมูลอื่นใดที่อาจช่วยได้

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

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

2) ผู้ที่พวกเขาไม่สามารถทำซ้ำได้อย่างน่าเชื่อถือ แต่มีหลักฐานเพียงพอ (ในแง่ของเหตุการณ์ที่เกิดขึ้นซ้ำ ๆ ) เพื่อแนะนำว่ามีข้อบกพร่องอยู่แล้วฉันมักจะเห็นว่าสิ่งเหล่านี้เป็นปัญหาของนักพัฒนาและนักพัฒนา - สนับสนุนโดยผู้ทดสอบ / user - จำเป็นต้องตรวจสอบ

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

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

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

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

โดยทั่วไปฉันทราบว่ามันไม่สามารถทำซ้ำได้ แต่เปิดทิ้งไว้จนกว่าชุดการทดสอบหรือการทำซ้ำนั้นจะเสร็จสมบูรณ์

หากยังไม่ได้ทำซ้ำโดยจุดนั้นจะถูกปิด แต่สามารถเปิดใหม่ได้หากพบอีกครั้ง

ติด keylogger บนเวิร์กสเตชันของผู้ทดสอบนี้!

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

มีเงื่อนไขสามข้อต่อไปนี้:

• ไบนารีเดียวกัน
• ขั้นตอนเดียวกัน
• เครื่องเดียวกัน

หากข้อผิดพลาดปรากฏขึ้นพร้อมกับเงื่อนไข 3 ข้อข้างต้นให้เริ่มแยกเพิ่มเติม พิจารณาแต่ละระดับของระบบสแต็กและการกำหนดค่า

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

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

ก่อนอื่นคุณควรมีขั้นตอนการทดสอบอย่างเข้มงวด (แต่ฉันเข้าใจคุณใน บริษัท ของฉันสิ่งที่คุณอธิบายเกิดขึ้นบ่อยครั้ง)

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