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

โปรดอธิบายว่าคุณมาถึงที่คำตอบของคุณได้อย่างไร (เพราะถ้าคุณเลือกเบอร์แล้วฉันก็ทำได้ด้วยตัวเอง;)

ร้อยแก้วโดยอัลแบร์โตซาโวยาตอบคำถามนี้อย่างแม่นยำ (ในลักษณะที่สนุกสนานอย่างที่!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus บนความคุ้มครองการทดสอบ

เช้าวันหนึ่งโปรแกรมเมอร์คนหนึ่งถามเจ้านายที่ยิ่งใหญ่:

“ ฉันพร้อมที่จะเขียนการทดสอบหน่วย ฉันควรตั้งรหัสความครอบคลุมสำหรับรหัสอะไร?”

อาจารย์ผู้ยิ่งใหญ่ตอบว่า:

“ ไม่ต้องกังวลกับการครอบคลุมแค่เขียนข้อสอบที่ดี”

โปรแกรมเมอร์ยิ้มโค้งคำนับและออกจาก

...

หลังจากวันนั้นโปรแกรมเมอร์คนที่สองถามคำถามเดียวกัน

อาจารย์ผู้ยิ่งใหญ่ชี้ไปที่หม้อต้มน้ำแล้วพูดว่า:

“ ฉันจะใส่ข้าวในหม้อได้กี่เม็ด?”

โปรแกรมเมอร์มองงงแล้วตอบกลับ:

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

“ แน่นอน” มหาปรมาจารย์กล่าว

โปรแกรมเมอร์คนที่สองยิ้มโค้งคำนับและออกไป

...

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

“ แปดสิบเปอร์เซ็นต์และไม่น้อย!” ตอบอาจารย์ด้วยเสียงที่ดุดันทุบกำปั้นของเขาบนโต๊ะ

โปรแกรมเมอร์คนที่สามยิ้มโค้งคำนับและจากไป

...

หลังจากคำตอบสุดท้ายนี้เด็กฝึกหัดคนหนึ่งได้พบกับเจ้านายผู้ยิ่งใหญ่:

“ เจ้านายที่ยิ่งใหญ่วันนี้ฉันได้ยินคุณตอบคำถามเดียวกันเกี่ยวกับการครอบคลุมโค้ดด้วยคำตอบที่ต่างกันสามคำ ทำไม?"

เจ้านายผู้ยิ่งใหญ่ยืนขึ้นจากเก้าอี้ของเขา:

“ มารับชาสด ๆ กับฉันแล้วพูดคุยกันเถอะ”

หลังจากที่พวกเขาเติมถ้วยชาเขียวที่ร้อนแรงจนเต็มแล้วเจ้านายผู้ยิ่งใหญ่ก็เริ่มตอบว่า:

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

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

“ ฉันเห็นแล้ว” เด็กฝึกงานพูด“ แต่ถ้าไม่มีคำตอบง่ายๆทำไมคุณตอบโปรแกรมเมอร์คนที่สามว่า 'แปดสิบเปอร์เซ็นต์และไม่น้อย'?”

ปรมาจารย์ผู้ยิ่งใหญ่หัวเราะอย่างหนักและดังจนท้องของเขาเป็นหลักฐานว่าเขาดื่มมากกว่าแค่ชาเขียวไหลลงมา

“ โปรแกรมเมอร์คนที่สามต้องการคำตอบง่ายๆ - แม้ว่าจะไม่มีคำตอบง่ายๆ…แล้วก็ไม่ติดตามพวกเขา”

เด็กฝึกงานและปรมาจารย์ผู้มีผมหงอกเป็นอันมากดื่มชาเสร็จในความเงียบครุ่นคิด

การครอบคลุมโค้ดเป็นตัวชี้วัดที่ทำให้เข้าใจผิดหากความครอบคลุม 100% เป็นเป้าหมายของคุณ (แทนที่จะทดสอบ 100% ของคุณสมบัติทั้งหมด)

• คุณสามารถได้รับ 100% โดยการกดปุ่มทุกครั้ง อย่างไรก็ตามคุณยังคงพลาดการทดสอบลำดับเฉพาะ (เส้นทางตรรกะ) ที่มีการเข้าชมบรรทัดเหล่านั้น
• คุณไม่สามารถได้รับ 100% แต่ยังคงทดสอบเส้นทางโค้ดที่ใช้ 80% / freq ทั้งหมดของคุณ มีการทดสอบที่ทดสอบ 'Throw ExceptionTypeX' หรือโปรแกรมป้องกันตัวอื่น ๆ ที่คล้ายกันที่คุณใส่ไว้คือ 'ดีที่มี' ไม่ 'ต้องมี'

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

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

ฉันไม่สนใจว่าฉันจะมีรหัสที่ไม่ได้ครอบคลุมในการทดสอบ แต่ฉันจะดูแลถ้าฉันจะ refactor รหัสของฉันและท้ายมีพฤติกรรมที่แตกต่างกัน ดังนั้นฟังก์ชั่นครอบคลุม 100% เป็นเป้าหมายเดียวของฉัน

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

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

เมื่อใดที่ต้องตั้งข้อกำหนดการครอบคลุมโค้ด

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

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

บางกรณีที่มีมาตรฐานเชิงประจักษ์สามารถเพิ่มมูลค่า:

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

ตัวชี้วัดที่จะใช้

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

ฉันจะใช้เมตริกทั่วไปสองชุดเป็นตัวอย่างว่าคุณจะใช้เพื่อกำหนดมาตรฐานเมื่อใด:

• รายงานความครอบคลุม : เปอร์เซ็นต์ของงบที่ได้ดำเนินการในระหว่างการทดสอบ? มีประโยชน์ในการรับรู้ถึงความครอบคลุมทางกายภาพของรหัสของคุณ: ฉันได้ทดสอบโค้ดจำนวนเท่าไหร่แล้ว
  • การครอบคลุมประเภทนี้สนับสนุนการโต้แย้งความถูกต้องที่อ่อนกว่า แต่ยังง่ายต่อการบรรลุ หากคุณเพียงแค่ใช้การครอบคลุมโค้ดเพื่อให้แน่ใจว่าสิ่งต่าง ๆ ได้รับการทดสอบ (และไม่เป็นตัวบ่งชี้คุณภาพการทดสอบเกินกว่านั้น) การครอบคลุมคำสั่งนั้นน่าจะเพียงพอ
• ครอบคลุมสาขา : เมื่อมีการแยกตรรกะ (เช่น an if), ทั้งสองสาขาได้รับการประเมิน? สิ่งนี้ให้ความรู้สึกที่ดีขึ้นเกี่ยวกับการครอบคลุมเชิงตรรกะของรหัสของคุณ: ฉันได้ทดสอบเส้นทางที่เป็นไปได้จำนวนเท่าใด
  • ความครอบคลุมประเภทนี้เป็นตัวบ่งชี้ที่ดีกว่ามากว่าโปรแกรมได้รับการทดสอบกับชุดอินพุตที่ครอบคลุม หากคุณใช้การครอบคลุมโค้ดเป็นค่าประมาณเชิงประจักษ์ที่ดีที่สุดของคุณเพื่อความมั่นใจในความถูกต้องคุณควรกำหนดมาตรฐานตามความครอบคลุมสาขาหรือคล้ายกัน

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

เปอร์เซ็นต์ที่ต้องมี

สุดท้ายกลับไปที่คำถามเดิม: หากคุณกำหนดมาตรฐานการครอบคลุมโค้ดหมายเลขนั้นควรเป็นเท่าใด

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

ตัวเลขบางตัวที่อาจเลือก:

• 100% คุณอาจเลือกสิ่งนี้เพราะคุณต้องการแน่ใจว่าทุกอย่างผ่านการทดสอบแล้ว สิ่งนี้ไม่ได้ทำให้คุณเข้าใจถึงคุณภาพการทดสอบ แต่บอกคุณว่าการทดสอบคุณภาพบางอย่างได้สัมผัสทุกข้อความ (หรือสาขา ฯลฯ ) อีกครั้งสิ่งนี้กลับมาถึงระดับความมั่นใจ: หากความคุ้มครองของคุณต่ำกว่า 100% คุณรู้ว่าเซตย่อยของรหัสของคุณยังไม่ได้ทดสอบ
  • บางคนอาจแย้งว่านี่มันงี่เง่าและคุณควรทดสอบเฉพาะส่วนของรหัสที่มีความสำคัญจริงๆ ฉันจะยืนยันว่าคุณควรรักษาส่วนของรหัสที่มีความสำคัญเท่านั้น รหัสความครอบคลุมสามารถปรับปรุงได้โดยการลบรหัสที่ยังไม่ทดลองเช่นกัน
• 99% (หรือ 95%, ตัวเลขอื่น ๆ ใน nineties สูง) เหมาะสมในกรณีที่คุณต้องการสื่อถึงระดับความเชื่อมั่นที่ใกล้เคียงกับ 100% แต่ปล่อยให้ตัวคุณเองไม่ต้องกังวลเกี่ยวกับมุมที่ยากต่อการทดสอบเป็นครั้งคราวของ รหัส.
• 80% ฉันเห็นว่ามีการใช้หมายเลขนี้สองสามครั้งและไม่รู้ว่าต้นกำเนิดมาจากที่ใด ฉันคิดว่ามันอาจเป็นการยักยอกที่แปลกของกฎ 80-20; โดยทั่วไปเจตนาที่นี่คือการแสดงให้เห็นว่าส่วนใหญ่ของรหัสของคุณผ่านการทดสอบ (ใช่ 51% จะเป็น "มากที่สุด" แต่ 80% สะท้อนความหมายของคนส่วนใหญ่ได้ดีกว่า) ซึ่งเหมาะสำหรับกรณีกลางซึ่ง "การทดสอบที่ดี" ไม่ใช่ลำดับความสำคัญสูง (คุณไม่ได้รับ ' ไม่ต้องการเสียความพยายามในการทดสอบที่มีค่าต่ำ) แต่มีความสำคัญเพียงพอที่คุณยังต้องการมีมาตรฐานอยู่

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

บันทึกอื่น ๆ

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

รหัสที่ฉันชอบคือ 100% พร้อมเครื่องหมายดอกจัน เครื่องหมายดอกจันเกิดขึ้นเพราะฉันต้องการใช้เครื่องมือที่อนุญาตให้ฉันทำเครื่องหมายบางบรรทัดเป็นบรรทัดที่ "ไม่นับ" ถ้าฉันครอบคลุม 100% ของบรรทัดที่ "นับ" ฉันก็เรียบร้อย

กระบวนการพื้นฐานคือ:

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

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

ฉันจะมีขั้วบวกอีกตัวในการครอบคลุมการทดสอบที่ฉันต้องการแชร์

เรามีโครงการขนาดใหญ่ที่ฉันพูดได้ว่าด้วยการทดสอบ 700 ครั้งเรามีรหัสครอบคลุม 20%เท่านั้น

Scott Hanselmanตอบด้วยถ้อยคำแห่งปัญญา :

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

อีกครั้งมันกลับไปที่Testivusของฉันในคำตอบการครอบคลุมรหัส คุณควรใส่ข้าวลงในหม้อเท่าไหร่ มันขึ้นอยู่กับ.

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

ง่ายต่อการยกเลิกคำถามนี้ด้วยสิ่งที่ชอบ:

• บรรทัดที่อยู่ในขอบข่ายไม่ได้เท่ากับตรรกะการทดสอบและไม่ควรอ่านมากเกินไปในเปอร์เซ็นต์

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

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

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

• Low Water Mark (LWM), จำนวนบรรทัดต่ำสุดที่ไม่เคยเห็นในระบบภายใต้การทดสอบ
• High Water Mark (HWM), เปอร์เซ็นต์การครอบคลุมโค้ดสูงสุดที่เคยเห็นสำหรับระบบภายใต้การทดสอบ

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

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

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

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

และอีกครั้งหากลูปข้อเสนอแนะยาวเกินไปอาจไม่ได้ผลอย่างสมบูรณ์ในการตั้งค่าบางอย่างเช่นนี้ในกระบวนการรวม

ฉันต้องการพูดถึงประโยชน์ทั่วไปเพิ่มเติมอีกสองประการของการวัดความครอบคลุมโค้ด

• การวิเคราะห์ความครอบคลุมของรหัสเป็นส่วนหนึ่งของการวิเคราะห์รหัสแบบไดนามิก (ตรงข้ามกับการวิเคราะห์แบบคงที่คือ Lint) ปัญหาที่พบในระหว่างการวิเคราะห์รหัสแบบไดนามิก (โดยเครื่องมือเช่นตระกูล purify, http://www-03.ibm.com/software/products/en/rational-purify-family ) เป็นสิ่งที่ต้องการหน่วยความจำที่ไม่ได้รับการอ่าน (UMR) การรั่วไหลของหน่วยความจำ ฯลฯปัญหาเหล่านี้สามารถพบได้ถ้ารหัสถูกปกคลุมด้วยกรณีการทดสอบดำเนินการ รหัสที่ยากที่สุดที่จะครอบคลุมในกรณีทดสอบมักจะเป็นกรณีที่ผิดปกติในระบบ แต่ถ้าคุณต้องการให้ระบบล้มเหลวอย่างสง่างาม (เช่นการติดตามข้อผิดพลาดแทนที่จะเกิดความผิดพลาด) คุณอาจต้องการใช้ความพยายามในการครอบคลุมกรณีที่ผิดปกติ ในการวิเคราะห์รหัสแบบไดนามิกเช่นกัน ด้วยความโชคร้ายเพียงเล็กน้อย UMR สามารถนำไปสู่ ​​segfault หรือแย่กว่านั้นได้

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

และลบเพื่อความสมบูรณ์

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

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

มุ่งเน้นการทดสอบของคุณไปที่ API เหล่านี้ ตรวจสอบให้แน่ใจว่า API เป็น 1) มีเอกสารที่ดีและ 2) มีกรณีทดสอบที่เขียนตรงกับเอกสาร หากผลลัพธ์ที่คาดหวังไม่ตรงกับเอกสารแสดงว่าคุณมีข้อบกพร่องในรหัสเอกสารของคุณหรือกรณีทดสอบ ทั้งหมดนี้เป็นการดีที่จะได้รับการรักษา

โชคดี!

ร้านค้าจำนวนมากไม่ได้ให้ความสำคัญกับการทดสอบดังนั้นหากคุณอยู่สูงกว่าศูนย์อย่างน้อยก็มีความซาบซึ้งในมูลค่า - ดังนั้นเนื้อหาที่ไม่ใช่ศูนย์ก็ไม่เลวเลย

ในโลกคน. net มักจะอ้างถึง 80% ว่ามีเหตุผล แต่พวกเขาพูดแบบนี้ในระดับโซลูชัน ฉันชอบที่จะวัดที่ระดับโครงการ: 30% อาจใช้ได้สำหรับโครงการ UI หากคุณมีซีลีเนียมหรือการทดสอบด้วยตนเอง 20% สำหรับโครงการเลเยอร์ข้อมูลอาจใช้ได้ แต่ 95% + อาจทำได้สำหรับธุรกิจ ชั้นกฎถ้าไม่จำเป็นทั้งหมด ดังนั้นความครอบคลุมโดยรวมอาจจะพูด 60% แต่ตรรกะทางธุรกิจที่สำคัญอาจสูงกว่านี้มาก

ฉันเคยได้ยินสิ่งนี้: ปรารถนาถึง 100% และคุณจะได้รับ 80%; แต่หวัง 80% และคุณจะได้ 40%

ที่บรรทัดด้านล่าง: ใช้กฎ 80:20 และให้การนับบั๊กของแอปของคุณแนะนำคุณ

การครอบคลุมโค้ดเป็นเพียงการวัดอื่น ในและของตัวเองมันอาจทำให้เข้าใจผิดมาก (ดูwww.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ) เป้าหมายของคุณไม่ควรให้ได้รหัสครอบคลุม 100% แต่เพื่อให้แน่ใจว่าคุณทดสอบสถานการณ์ที่เกี่ยวข้องทั้งหมดในใบสมัครของคุณ

85% จะเป็นจุดเริ่มต้นที่ดีสำหรับเกณฑ์การเช็คอิน

ฉันอาจเลือกแถบที่สูงกว่าสำหรับเกณฑ์การจัดส่งขึ้นอยู่กับความสำคัญของระบบย่อย / ส่วนประกอบที่กำลังทดสอบ

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

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

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

ถ้าฉันเพิ่มความครอบคลุมในการทดสอบหน่วย - ฉันรู้ว่าการทดสอบหน่วยนี้มีค่าบางอย่าง

รหัสนี้ไม่ครอบคลุมการครอบคลุม 50% หรือ 97% ที่ครอบคลุม

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

คำตอบนั้นขึ้นอยู่กับวิธีการใช้ภาษาและการทดสอบและเครื่องมือที่ครอบคลุม เมื่อทำ TDD ใน Ruby หรือ Python มันไม่ยากที่จะรักษาความคุ้มครอง 100% และคุ้มค่าที่จะทำเช่นนั้น การจัดการความครอบคลุม 100% ง่ายกว่าการจัดการความครอบคลุม 90 เปอร์เซ็นต์ นั่นคือมันง่ายกว่ามากในการเติมช่องว่างความครอบคลุมตามที่ปรากฏ (และเมื่อทำช่องว่างความคุ้มครอง TDD ที่ดีจะหายากและมักจะคุ้มค่ากับเวลาของคุณ) กว่าการจัดการรายการช่องว่างของความครอบคลุมที่คุณไม่ได้รับ การถดถอยเนื่องจากพื้นหลังคงที่ของรหัสที่ไม่ได้เปิด

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

หากคุณทำการทดสอบหน่วยในระยะเวลาที่เหมาะสมฉันไม่เห็นเหตุผลที่จะไม่เข้าใกล้ 95% + อย่างไรก็ตามอย่างน้อยฉันก็เคยทำงานร่วมกับ 80% ได้แม้ว่าจะเป็นเรื่องใหม่สำหรับการทดสอบ

หมายเลขนี้ควรมีรหัสที่เขียนในโครงการเท่านั้น (ไม่รวมกรอบงานปลั๊กอิน ฯลฯ ) และอาจยกเว้นบางคลาสที่ประกอบด้วยรหัสทั้งหมดที่เขียนจากการโทรไปยังรหัสภายนอก การโทรประเภทนี้ควรถูกเยาะเย้ย / ถูกขัดจังหวะ

โดยทั่วไปจากเอกสารการปฏิบัติที่เป็นเลิศทางวิศวกรรมที่ฉันได้อ่าน 80% สำหรับรหัสใหม่ในการทดสอบหน่วยเป็นจุดที่ให้ผลตอบแทนที่ดีที่สุด การดำเนินการที่สูงกว่า CC% ทำให้ได้ข้อบกพร่องน้อยลงสำหรับปริมาณความพยายาม นี่เป็นวิธีปฏิบัติที่ดีที่สุดที่ บริษัท ยักษ์ใหญ่หลายแห่งใช้

น่าเสียดายที่ผลลัพธ์เหล่านี้ส่วนใหญ่อยู่ภายใน บริษัท ดังนั้นจึงไม่มีเอกสารสาธารณะที่ฉันสามารถชี้ให้คุณเห็นได้

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

เราทำงานเพื่อให้ได้มาตรฐาน 80% ในบางครั้งอย่างไรก็ตามเราเพิ่งตัดสินใจที่จะละทิ้งสิ่งนี้และให้ความสำคัญกับการทดสอบของเราแทน มุ่งเน้นไปที่ตรรกะทางธุรกิจที่ซับซ้อน ฯลฯ

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

คำตอบสั้น ๆ : 60-80%

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

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

คำตอบสำหรับปริศนานี้คือการมีรหัสครอบคลุม 100% ของรหัสที่คุณสามารถทดสอบได้และความครอบคลุมของรหัส 0% ที่คุณไม่สามารถทดสอบได้

การปฏิบัติปัจจุบันของฉันใน Python คือการแบ่งโมดูล. py ของฉันออกเป็นสองโฟลเดอร์: app1 / และ app2 / และเมื่อเรียกใช้การทดสอบหน่วยคำนวณความครอบคลุมของทั้งสองโฟลเดอร์และตรวจสอบด้วยสายตา (ฉันต้องทำให้เป็นอัตโนมัติในสักวันหนึ่ง) app2 ได้รับความคุ้มครอง 0%

เมื่อ / ถ้าฉันพบว่าตัวเลขเหล่านี้แตกต่างจากมาตรฐานฉันตรวจสอบและปรับเปลี่ยนการออกแบบของรหัสเพื่อให้ความครอบคลุมเป็นไปตามมาตรฐาน

นี่หมายความว่าฉันสามารถแนะนำให้บรรลุความครอบคลุมบรรทัด 100% ของรหัสห้องสมุด

ฉันยังตรวจสอบเป็นครั้งคราว app2 / เพื่อดูว่าฉันสามารถทดสอบรหัสใด ๆ ที่เป็นไปได้หรือไม่และถ้าฉันสามารถย้ายมันไปที่ app1 /

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

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

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

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

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

ฉันมักจะปฏิบัติตามเกณฑ์หรือกฎต่อไปนี้:

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

2. การทดสอบหน่วยจะช่วยให้ฉันค้นพบว่าเกิดอะไรขึ้นถ้าเงื่อนไขที่ฉันอาจยังไม่ได้คิด (จะทำให้โค้ดของฉันเสถียรและแข็งแกร่งได้อย่างไร)

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

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

ฉันไม่คิดว่าจะมีกฎ B / W ดังกล่าว
ควรตรวจสอบรหัสโดยให้ความสำคัญเป็นพิเศษกับรายละเอียดที่สำคัญ
อย่างไรก็ตามหากยังไม่ได้ทดสอบมันมีข้อผิดพลาด!

ขึ้นอยู่กับความสำคัญของรหัสที่ใดก็ได้จาก 75% -85% เป็นกฎง่ายๆ ควรทดสอบรหัสการจัดส่งอย่างละเอียดมากกว่าในระบบสาธารณูปโภคภายในบ้านและอื่น ๆ

สิ่งนี้จะต้องขึ้นอยู่กับระยะเวลาของการพัฒนาแอปพลิเคชันของคุณ

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

ขึ้นอยู่กับโดเมนของคุณมันไม่สมเหตุสมผลที่จะยิง 95% แต่ฉันต้องบอกว่าโดยเฉลี่ยแล้วคุณจะดูกรณีทั่วไปที่ 85% ถึง 90%

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

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

เรากำหนดเป้าหมาย> 80% จนถึงไม่กี่วันกลับ แต่หลังจากเราใช้รหัสที่สร้างขึ้นจำนวนมากเราไม่สนใจ% อายุ แต่ให้ผู้ตรวจทานรับความคุ้มครองตามที่ต้องการ

จากการโพสต์ Testivus ฉันคิดว่าบริบทคำตอบควรเป็นโปรแกรมเมอร์ตัวที่สอง ต้องบอกว่าจากมุมมองการปฏิบัติเราต้องการพารามิเตอร์ / เป้าหมายเพื่อมุ่งมั่น ฉันคิดว่าสิ่งนี้สามารถ "ทดสอบ" ในกระบวนการ Agile โดยการวิเคราะห์รหัสที่เรามีสถาปัตยกรรมฟังก์ชันการทำงาน (เรื่องราวของผู้ใช้) และจากนั้นมากับตัวเลข จากประสบการณ์ของฉันในพื้นที่โทรคมนาคมฉันจะบอกว่า 60% เป็นค่าที่ดีในการตรวจสอบ