จะจัดการกับการทดสอบที่ล้มเหลวจำนวนมากได้อย่างไร [ปิด]

ฉันกำลังทำงานในการพัฒนาโครงการเก่าที่เขียนใน Java เรามีมากกว่า 10 ล้าน LOC และยิ่งกว่านั้นมากกว่า 4,000 ทดสอบการทำงาน

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

เราทำอะไรได้บ้าง วิธีดำเนินการกับการทดสอบแบบดั้งเดิมจำนวนเท่าใด

ละทิ้งพวกเขา

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

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

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

ไปและแก้ไขการทดสอบ

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

การตรวจสอบความล้มเหลวในการทดสอบ - หากเป็นปัญหาในผลิตภัณฑ์หรือในการทดสอบใช้เวลาเป็นเดือน เราไม่สามารถลบการทดสอบเก่าออกได้เพราะเราไม่รู้ว่ามันคือการทดสอบอะไร!

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

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

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

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

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

ปิดใช้งานการทดสอบที่ล้มเหลวชั่วคราว

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

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

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

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

คุณอาจย้ายการทดสอบไปยังทรีต้นทางซึ่งปกติจะไม่รวมอยู่ในบิลด์

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

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

ทำการทดสอบที่เกี่ยวข้อง

แก้ไขเพื่อเพิ่มการทดสอบใหม่ในขณะที่คุณเพิ่มหรือแก้ไขรหัสและมุ่งมั่นที่จะทำให้การทดสอบผ่านที่ผ่านมาทั้งหมด

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

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

กำหนดเจตนาสำหรับการทดสอบแต่ละครั้ง

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

• มันทดสอบคุณสมบัติที่ถูกลบออกจากฐานรหัสโดยมีวัตถุประสงค์หรือไม่? จากนั้นคุณสามารถลบได้

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

• มันล้มเหลวหรือไม่เนื่องจากเป็นข้อสันนิษฐานที่ไม่ได้รับการยอมรับ (เช่นสมมติว่าข้อความบนปุ่มเป็นภาษาอังกฤษเสมอ แต่ตอนนี้คุณได้แปลใบสมัครของคุณเป็นหลายภาษา) จากนั้นหาวิธีทำให้การทดสอบมุ่งเน้นไปที่สิ่งเดียวและแยกออกจากการเปลี่ยนแปลงที่ไม่เกี่ยวข้องอย่างดีที่สุดเท่าที่จะทำได้

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

• สถาปัตยกรรมของแอพเปลี่ยนไปกว่าการจดจำดังนั้นการทดสอบจึงไม่มีประโยชน์อีกต่อไป? ลบมัน.

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

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

การทดสอบกว่า 4,000 รายการเป็นปัญหาที่แก้ยากไม่ได้ การทดสอบ 40 รายการสามารถใช้การได้ง่ายขึ้น สุ่มเลือกจำนวนการทดสอบที่จัดการได้เพื่อเรียกใช้และวิเคราะห์ จัดประเภทผลลัพธ์เป็น:

1. การทดสอบที่ไร้ประโยชน์
2. การทดสอบที่มีประโยชน์ที่จะทำความสะอาด
3. การทดสอบที่มีประโยชน์ที่ล้มเหลว

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

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

หากข้อความนี้เป็นจริง

การทดสอบ ... ล้มเหลวอย่างบ้าคลั่งกับการเปลี่ยนแปลงรหัสที่ใหญ่กว่าทุกครั้ง

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

ทำซ้ำจนกว่าคุณจะมีฐานรหัสล่าสุด

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

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

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

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

กล่าวโดยย่อ - หากการทดสอบเก่าของคุณล้มเหลวเมื่อคุณทำการเปลี่ยนแปลงการเปลี่ยนแปลงรหัสของคุณไม่ดี ใช้การทดสอบเหล่านั้นเป็นวิธีการศึกษาในการทำงานของระบบ

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

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

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

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

เราไม่สามารถลบการทดสอบเก่าออกได้เพราะเราไม่รู้ว่ามันคือการทดสอบอะไร!

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