การทดสอบหน่วยอัตโนมัติการทดสอบการรวมหรือการทดสอบการยอมรับ [ปิด]

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

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

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

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

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

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

ขอบคุณล่วงหน้า.

ปัจจัยหนึ่งที่สำคัญที่ทำให้การทดสอบหน่วยที่มีประโยชน์มากคือการตอบรับอย่างรวดเร็ว

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

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

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

ในขณะที่การทดสอบหน่วย (TDD)

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

ทั้งหมดนี้เกิดขึ้นในเรื่องของการนาที

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

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

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

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

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

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

นั่นเป็นคำถามเชิงทฤษฎีและฉันคิดว่ามันไร้ประโยชน์ การทดสอบทุกประเภทมีการใช้งานในกล่องเครื่องมือของวิศวกร SW ที่ดีและทั้งหมดนี้มีสถานการณ์ที่ไม่สามารถถูกแทนที่ได้

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

นี่คือประเภท / ประโยชน์ของการทดสอบที่เราทำ:

• การทดสอบหน่วย - ทำให้มั่นใจได้ว่าหน่วยกำลังทำงานตามที่เราคาดหวัง เราทดสอบทั้งผู้ให้บริการและสัญญาของผู้บริโภคสำหรับทุกอินเทอร์เฟซ - และนี่เป็นเรื่องง่ายโดยอัตโนมัติ นอกจากนี้เรายังตรวจสอบเงื่อนไขขอบเขตของเรา ฯลฯ
• การทดสอบการรวม - ทำให้แน่ใจว่าหน่วยทำงานร่วมกันในคอนเสิร์ต นี่คือการทดสอบการออกแบบของเราเป็นหลัก หากมีสิ่งใดเกิดขึ้นที่นี่เราต้องปรับการทดสอบหน่วยของเราเพื่อให้แน่ใจว่าจะไม่เกิดขึ้นอีก
• การทดสอบระบบ - รับรองว่าระบบตรงตามข้อกำหนด / ข้อกำหนด โดยปกติคนทำการทดสอบประเภทนี้
• การทดสอบการยอมรับ - ลูกค้าทำสิ่งนี้เพื่อตรวจสอบว่าผลิตภัณฑ์สุดท้ายทำในสิ่งที่โฆษณาไว้

การทดสอบเสริม แต่แนะนำ:

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

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

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

เครื่องมือเหล่านี้ต่างกันโดยมีเป้าหมายที่แตกต่างกัน:

• การทดสอบหน่วยเป็นเครื่องมือออกแบบ (TDD) และเป็นข้อกำหนดเบื้องต้นสำหรับการปรับโครงสร้างใหม่

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

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

ฉันใช้ซีลีเนียมอย่างกว้างขวางเพื่อตรวจสุขภาพจิต

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

สิ่งที่ดีเกี่ยวกับซีลีเนียมคือคุณสามารถผูกมันไว้กับกรอบการทดสอบหน่วยเช่น XUnit, TestNG หรือ MSTest

จากประสบการณ์ของฉันมันมีค่ามาก แต่การตั้งค่าบางอย่างเช่นนั้นขึ้นอยู่กับโครงการและทีมของคุณดังนั้น ROI จะแตกต่างกันอย่างแน่นอน

ROI ที่ดีที่สุดคือการทดสอบที่เร็วที่สุดที่สามารถพบข้อผิดพลาดประเภทนั้นได้

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

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

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

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

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

ฉันรู้สึกว่าการทดสอบการยอมรับเป็นสิ่งสำคัญในสถานการณ์นี้

หากกระทำการทดสอบการยอมรับยอมรับจะต้องมีการแยกออก

การทดสอบการยอมรับจะบอกคุณว่าซอฟต์แวร์ของคุณอยู่ที่ไหนการทดสอบหน่วยไม่ได้

ดังนั้นการทดสอบหน่วยสามารถให้ความปลอดภัยที่ผิดพลาดได้

คำถามไม่ได้มีอะไรสำคัญมากไปกว่าสิ่งที่สามารถเป็นไปโดยอัตโนมัติและทำงานได้อย่างรวดเร็ว

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

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

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