คนรักษาชุดทดสอบอย่างไร

โดยเฉพาะฉันอยากรู้เกี่ยวกับประเด็นต่อไปนี้:

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

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

คำตอบสั้น ๆ : ใช้เครื่องมือที่รู้จักที่ช่วยรักษาคุณภาพของกรณีทดสอบเช่นการครอบคลุมรหัสต่อไปนี้และเครื่องมือคุณภาพของรหัส: Cobertura, PMD, Sonar ฯลฯ ที่จะช่วยให้คุณสังเกตเห็นเมื่อองค์ประกอบที่สำคัญของโปรแกรมไม่ได้ทดสอบอย่างเพียงพอ นอกจากนี้เขียนการทดสอบการรวมที่มีแนวโน้มที่จะทำลายก่อนเมื่อใดก็ตามที่มีอะไรผิดพลาด

คำตอบยาว:

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

• การใช้เครื่องมือครอบคลุมรหัสเช่นCoberturaคุณสามารถตรวจสอบกรณีทดสอบสำหรับคลาสที่กำหนดหรือวิธีการที่ซับซ้อนไม่เพียงพออีกต่อไป คุณไม่จำเป็นต้องมีรหัสครอบคลุม 100% ทุกที่และในกรณีส่วนใหญ่ยากที่จะบรรลุและไม่จำเป็นต้องมีประโยชน์ แต่การทดสอบสำหรับลักษณะที่สำคัญที่สุดของโปรแกรมควรได้รับการดูแลโดยมีเป้าหมายอย่างน้อย 80% ของการครอบคลุมโค้ด
• การใช้เครื่องมือสร้างและผนวกรวมอย่างต่อเนื่องเช่นJenkinsที่ฉันชื่นชอบมากเมื่อใช้ร่วมกับปลั๊กอินSonarคุณสามารถตั้งค่าทริกเกอร์ที่ส่งอีเมลและการแจ้งเตือนประเภทอื่น ๆ ให้กับผู้ที่รับผิดชอบการเปลี่ยนแปลงล่าสุด กราฟและสถิติต่างๆ (Sonar ยังใช้ Cobertura กับเครื่องมืออื่น ๆ อีกมากมาย) ช่วยผู้ตรวจสอบโค้ดและผู้พัฒนาเคสทดสอบเพื่อมุ่งเน้นสิ่งที่สำคัญ

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

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

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

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

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

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

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