การทดสอบแบบ end-to-end และการรวมเข้าด้วยกันนั้นคุ้มค่าสำหรับสิ่งที่ไม่ใช่ภารกิจหรือไม่?


9

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

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

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


4
มีวิธีการคำนวณความเสี่ยง / ต้นทุนสำหรับสิ่งนี้หรือไม่? นอกเหนือจากการทำทั้งสองอย่างแล้วเปรียบเทียบไม่ใช่
Robbie Dee

4
คุณต้องพิจารณา ROI ของทุกสิ่งในกระบวนการพัฒนา การทดสอบหน่วยมีค่าหรือไม่ การทดสอบด้วยตนเองมีค่าหรือไม่ คุณภาพของรหัสคุ้มค่าหรือไม่ การสร้างซอฟต์แวร์ในครั้งแรกนั้นคุ้มค่าหรือไม่? นั่นคือคำถามทางธุรกิจที่สำคัญ หลักสูตรใดที่ไม่สามารถตอบได้โดยทั่วไป และพวกเขายังเกี่ยวกับการบริหารธุรกิจมากกว่าวิศวกรรมซอฟต์แวร์
Christian Hackl

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

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

คำตอบ:


12

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

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

  • ค่าใช้จ่ายสำหรับการทดสอบ E2E ด้วยตนเอง (หลาย ๆ ครั้งก่อนการเปิดตัวแต่ละครั้ง)

เมื่อเทียบกับ

  • ค่าใช้จ่ายสำหรับการสร้าง (และการบำรุงรักษา) การทดสอบ E2E อัตโนมัติ

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

โปรดทราบว่าอาจมีการทดสอบ E2E บางประเภทซึ่งสามารถนำไปใช้งานได้ง่ายโดยที่ ROI นั้นชัดเจนทันที แต่ยังมีการทดสอบ E2E หลายประเภทที่การพัฒนาและการบำรุงรักษาอาจมีราคาแพงกว่าที่ทำด้วยตนเองในช่วงเวลาหลายปี


ขอบคุณนี่เป็นคำตอบที่ดีมาก ตัวอย่างของการทดสอบ E2E ที่ใช้งานง่าย แต่นำไปสู่การพัฒนาและการบำรุงรักษาที่มากขึ้น?
Marc

2
@ Marc: ฉันคิดว่าคุณเข้าใจผิดประโยคสุดท้ายของฉันฉันกำลังพูดถึงการทดสอบที่แตกต่าง: คนที่ง่ายต่อการใช้ / บำรุงรักษาและคนที่ไม่ใช่
Doc Brown

ถูกต้องเวอร์ชันที่แก้ไขทำให้ชัดเจนยิ่งขึ้น
Marc

@ Marc: จากประสบการณ์ของฉันการทดสอบผ่านส่วนต่อประสานผู้ใช้ (โดยเฉพาะอย่างยิ่งซับซ้อน) มักจะเป็นตัวเลือกที่การทดสอบอัตโนมัตินั้นประหยัดค่าใช้จ่ายน้อยกว่าการทดสอบอื่น ๆ - แต่ขึ้นอยู่กับประเภทของซอฟต์แวร์เครื่องมือที่มีอยู่ เทคโนโลยีที่เกี่ยวข้อง
Doc Brown

7

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

แนวคิดก็คือการทดสอบมีส่วนร่วมในหลายระดับ

  1. รวบรวมความต้องการและข้อกำหนดที่เข้มงวด

    ทำให้มีผลกระทบอย่างมากต่อความเร็วของการพัฒนา ไม่กลับไปขอรายละเอียดเพิ่มเติมไม่เข้าใจผิดไม่มีฟีเจอร์ที่ไม่จำเป็น ฯลฯ

  2. นักพัฒนาทราบเมื่อคุณสมบัติเสร็จสมบูรณ์

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

  3. ข้อบกพร่องที่แนะนำโดยคุณสมบัติใหม่ที่ตรวจพบได้ทันที

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

  4. รอบการเปิดตัวเร็วขึ้น

    นี่หมายถึงรหัสน้อยลงในเที่ยวบินซึ่งหมายถึงการผสานน้อยลงซึ่งหมายถึงการทำงานน้อยลงและความซับซ้อนที่น้อยลงสำหรับนักพัฒนา

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

นอกจากนี้คุณประหยัดเวลาในการทดสอบด้วยตนเองรวมถึงคุณจะได้ผลิตภัณฑ์ที่ดีขึ้นในตอนท้าย


สำหรับฉันคำตอบนี้จะขึ้นอยู่กับว่า OP กำลังพูดถึงการทดสอบการรวมเข้าด้วยกันหรือไม่ ถ้ามีแล้วจะมีการทดสอบหน่วยแล้วคำตอบก็ดูเหมือนจะเก็งกำไรที่ดีที่สุด หากไม่มีการทดสอบหน่วยแล้วโดยธรรมชาติ - การทดสอบอัตโนมัติบางอย่างดีกว่าไม่มีเลย
Robbie Dee

ใช่ฉันคิดว่าเรามีการทดสอบหน่วย
Marc

1

คำตอบของฉัน? บางทีอาจจะไม่ได้

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

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

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

ส่วนใหญ่เราจะทำการทดสอบแทนการจับข้อบกพร่องจากผลลัพธ์ของพวกเขา ค้นพบต้นกำเนิดของข้อบกพร่องในการทดสอบแบบครบวงจรใช้เวลานาน นอกจากนี้เรายังจัดการกับการทดสอบ "false-negative" จำนวนมากและไม่กี่ครั้งในการทำความเข้าใจปัญหาและแก้ไข: ปัญหาการโหลด Java Applet, องค์ประกอบที่คาดหวังไม่พบในหน้า (รวมถึงปัญหาอื่น ๆ เกี่ยวกับความเร็วอัตโนมัติ), รักษารหัสแบบสอบถาม จะใช้ในการทดสอบหน่วยความจำฐานข้อมูล (เนื่องจากแบบสอบถามต้นฉบับใช้รหัสเฉพาะฐานข้อมูล) เป็นต้น

ทั้งหมดนี้ต้องการผู้คนในการดูแลและดำเนินการ ในตอนท้ายเราเริ่มลบการทดสอบ EOE และแทนที่ด้วยการทดสอบหน่วย / การรวมหลายอย่าง

ดังนั้นคำแนะนำเชิงอนุรักษ์ของฉันคือใช้ปิรามิดทดสอบจาก Google:

เป็นการคาดเดาที่ดีครั้งแรก Google มักจะแนะนำการทดสอบแบบแบ่งแบ่ง 70/20/10: การทดสอบหน่วย 70% การทดสอบการรวม 20% และการทดสอบแบบ end-to-end 10% การผสมที่แน่นอนจะแตกต่างกันไปสำหรับแต่ละทีม แต่โดยทั่วไปควรรักษารูปทรงปิรามิดนั้นไว้


0

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

การพัฒนาซอฟต์แวร์ทั้งหมดมักจะต้องจับตาดูการเมืองขององค์กร


0

"เป็นที่รู้จักกันดีว่าการทดสอบแบบครบวงจรและการรวมระบบมีราคาแพง"

ฉันคิดว่าฉันไม่เห็นด้วยกับการยืนยันนี้

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

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

ตำแหน่งที่การทดสอบ E2E มีแนวโน้มที่จะมีราคาแพง / ไม่เหมาะสมมากกว่านั้นอยู่ในการตั้งค่าเริ่มต้นและหากใช้เพื่อลองและทดสอบทุกอย่าง ในทางปฏิบัติฉันคิดว่าวิธีที่ดีที่สุดในการหลีกเลี่ยงกับดักนี้คือการจัดลำดับความสำคัญโดยอัตโนมัติในการทดสอบสิ่งต่าง ๆ ที่:

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

ใช้รูปแบบการทดสอบใด ๆ รวมถึง E2E ที่คุณคิดว่าเหมาะสม มุ่งเน้นไปที่เหล่านั้น


0

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

คุณควรถามสิ่งที่เป็นข้อบกพร่องกรณีที่เลวร้ายที่สุดซึ่งอาจจบลงด้วยการผลิตจริงเนื่องจากการขาดการทดสอบ E2E และจำกฎหมายของ Murphys


0

ฉันคิดว่าคำถามนี้เกี่ยวกับเว็บแอปพลิเคชันระดับองค์กร

คำแนะนำของฉันสำหรับสิ่งที่สำคัญปานกลาง:

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

ฉันคิดว่าการทดสอบส่วนใหญ่ควรอยู่ในระดับ API หรือระดับองค์ประกอบ ฉันไม่สนใจเกี่ยวกับการทดสอบหน่วยที่ใช้งานฟังก์ชันภายในบางอย่างเท่านั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.