จะรู้ได้อย่างไรว่าเมื่อใดจะหยุดการทดสอบ?

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

หนังสือของ Glenford Myers Art of Software Testingมีกฎที่เรียบง่าย แต่มีหลักการสำหรับเรื่องนี้: การทดสอบเสร็จสมบูรณ์เมื่อคุณหยุดการค้นหาข้อบกพร่อง หรือในทางปฏิบัติมากขึ้นเมื่ออัตราที่คุณพบข้อบกพร่องใหม่ช้าลงอย่างมาก

บักมักจะ "จัดกลุ่ม" ในโมดูลและฟังก์ชั่นบางอย่าง: เมื่อคุณพบข้อบกพร่องในหนึ่งคุณรู้ว่าคุณควรตรวจสอบเพิ่มเติมเพื่อหาข้อบกพร่องมากขึ้น ในการค้นหาข้อบกพร่องคุณสามารถใช้เทคนิคการทดสอบ blackbox การทดสอบ whitebox และการทดสอบการกลายพันธุ์ ตราบใดที่คุณพบข้อบกพร่องคุณรู้ว่ากระบวนการทดสอบของคุณใช้งานได้!

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

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

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

นี่เป็นคำถามสำหรับผู้ทดสอบระบบที่ดี (และฉันไม่ใช่คนเดียว) แต่ฉันจะให้มันยิง

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

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

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

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

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

(ฉันคิดว่าสิ่งนี้เรียกว่าการสตริป แต่ไม่ได้อ้างอิงฉันในเรื่องนั้น)

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

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

"การทดสอบโปรแกรมสามารถใช้เพื่อแสดงสถานะของบั๊ก แต่ไม่แสดงว่าไม่มี!" - Edger Dijkstra

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

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

เป็นหลักคุณต้องการได้รับการคุ้มครองในสองสถานที่ใหญ่:

1. ซอฟต์แวร์ผ่านการทดสอบ BDD ที่แสดงว่าตรงตามข้อกำหนดที่ระบุหรือไม่ ซอฟต์แวร์ไม่สามารถเรียกได้ว่าทำได้หากไม่เป็นจริง

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

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

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

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

นี่เป็นตัวอย่างที่ดี

นักสถิติได้พิจารณาถึงปัญหานี้เช่นกันจริง ๆ แล้วในช่วงต้นทศวรรษ 1970-80 ให้ข้อสมมติฐานที่เหมาะสมในการค้นพบข้อบกพร่องพวกเขาพยายามที่จะประเมินจำนวนข้อบกพร่องจากข้อมูลการทดสอบ จากนั้นจะใช้ในการพิจารณาว่าเมื่อใดที่จะหยุดตามการปรับฟังก์ชั่นการสูญเสียให้เหมาะสม ดูตัวอย่างhttps://rpubs.com/hoehle/17920 ... เพื่อรับการรักษาสั้น ๆ หนึ่งในเอกสารเกี่ยวกับปัญหานี้รวมถึงรหัส R เกี่ยวกับวิธีการปฏิบัติในทางปฏิบัติ

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

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

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

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

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

นี่คือการทดสอบบางอย่างที่เกี่ยวข้องกับ "ตัวชี้วัดที่เสร็จสิ้น":

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

หากคุณสามารถตรวจสอบคะแนนเหล่านี้ได้คุณอาจพูดได้ว่าคุณได้ทดสอบแล้วพอ

ไม่ฉันคิดว่าคุณจะไม่มีวันทำการทดสอบในระบบ .. มีตัวแปรมากมายที่คุณไม่สามารถจัดการได้

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

• เมื่อความเสี่ยงที่เกี่ยวข้องกับการใช้งานซอฟต์แวร์ลดลงเป็นระดับที่ยอมรับได้ (ตามที่ @Graham Lee พูด)
• ใครคือผู้ใช้ระบบ? อาจเป็นคุณหรือประธานาธิบดีแห่งสหรัฐอเมริกา ในกรณีแรกคุณไม่สนใจมากหากมีข้อผิดพลาดปรากฏขึ้นเพราะคุณแก้ปัญหาและทำมัน ในกรณีที่สองคุณไม่ต้องการให้บั๊กใด ๆ ปรากฏขึ้น
• ความสัมพันธ์ของคุณกับลูกค้าของคุณคืออะไร บางทีลูกค้าเป็นพ่อของคุณดังนั้นมันจึงไม่แย่มากหรืออาจเป็น บริษัท ใหญ่
• ข้อบกพร่องร้ายแรงสำหรับผู้ใช้ระบบหรือไม่ มันจะทำให้เกิดสงครามโลกครั้งที่สามหรือเป็นเพียงข้อความที่น่าเกลียด?

เมื่อคนที่ต้องลงชื่อออกในการปรับใช้มีความพึงพอใจ

หรือในบางกรณีผู้มีหน้าที่รับผิดชอบส่วนใหญ่มีความพึงพอใจ