ข้อเสียของการทดสอบอัตโนมัติคืออะไร

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

นี่คือบางส่วนที่ฉันได้รับ:

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

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

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

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

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

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

• ความต้องการด้านเครื่องมือ: คุณอยู่ที่นั่น ไม่มากที่จะเพิ่มไปนี้

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

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

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

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

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

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

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

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

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

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

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

แน่นอนว่ามุมมองของฉันมาจากแอปพลิเคชันที่เก่ากว่าการทดสอบหน่วย

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

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

แม้ว่าการทดสอบระบบอัตโนมัติมีข้อดีหลายประการ แต่ก็มีข้อเสียของตัวเองเช่นกัน ข้อเสียบางประการคือ:

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

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

ฉันเพิ่งถามคำถามเกี่ยวกับการทดสอบในการพัฒนาเกม - นี่คือ BTW ที่ฉันรู้เกี่ยวกับสิ่งนี้ คำตอบมีชี้ให้เห็นข้อเสียที่เฉพาะเจาะจงอยากรู้อยากเห็น:

1. มันเป็นค่าใช้จ่ายที่ต้องทำเมื่อรหัสของคุณควรจะคู่สูง
2. เป็นการยากที่จะทำเมื่อคุณต้องระวังแพลตฟอร์มฮาร์ดแวร์ต่าง ๆ เมื่อคุณควรวิเคราะห์ผลลัพธ์ไปยังผู้ใช้และผลลัพธ์ของรหัสจะเหมาะสมในบริบทที่กว้างขึ้นเท่านั้น
3. UI และ UX ทดสอบเป็นเรื่องยากมาก
4. การทดสอบอัตโนมัติอาจมีราคาแพงกว่าและมีประสิทธิภาพน้อยกว่าการทดสอบเบต้าที่มีต้นทุนต่ำ (หรือฟรี)มาก

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

• การทดสอบอัตโนมัติอาจทำให้คุณรู้สึกว่าการควบคุมคุณภาพและการทดสอบนั้นไม่สำคัญ

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

ในที่สุดปัญหาที่ฉันพบในบางครั้ง: การทดสอบอัตโนมัติอาจขึ้นอยู่กับเครื่องมือและเครื่องมือเหล่านั้นอาจเขียนได้ไม่ดี ฉันเริ่มโครงการโดยใช้ XUL เมื่อไม่นานมานี้และมนุษย์นี่เป็นเพียงความเจ็บปวดในการเขียนการทดสอบหน่วยสำหรับแพลตฟอร์มดังกล่าว ฉันเริ่มต้นแอปพลิเคชันอื่นโดยใช้ Objective-C, Cocoa และ Xcode 3 และรูปแบบการทดสอบในนั้นเป็นวิธีแก้ปัญหามากมาย

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

สองที่ไม่ได้กล่าวถึงคือ:

• ระยะเวลาของนาฬิกาอาจใช้เวลานานในการรันชุดทดสอบขนาดใหญ่

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

• ความอ่อนแอของวิธีทดสอบการเขียนบางอย่าง

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

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

ฉันต้องการเพิ่มอีกหนึ่งความปลอดภัยที่ผิดพลาด

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

เป็นการยากที่จะโน้มน้าวผู้บริหาร / ผู้ร่วมทุน

• testautomation เพิ่มต้นทุนล่วงหน้า
• การทดสอบอัตโนมัติเพิ่มเวลาในการทำตลาด
• ประโยชน์ของ testautomation มาในกลางและ logterm การแข่งขันที่รุนแรงมุ่งเน้นไปที่ผลประโยชน์ระยะสั้น

ดูตลาดขับเคลื่อนการทดสอบหน่วยสำหรับรายละเอียด

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