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

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

ปัญหาสำหรับฉันคือการเห็นการเปลี่ยนแปลงเล็กน้อยทำให้การทดสอบแตกหัก - การเปลี่ยนแปลงใด ๆ กับ div, id หรือหมายเลข autoid บางส่วนที่ช่วยระบุวิดเจ็ตทำให้การทดสอบแตกหักจำนวนเท่าใดก็ได้ - ดูเหมือนว่าจะเปราะบางมาก

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

testing selenium

— สามเจ
แหล่งที่มา

หากการเปลี่ยนแปลงเล็กน้อยกำลังทำลายการทดสอบดังนั้นการทดสอบจะไม่ถูกเรียกใช้หลังจากทำการเปลี่ยนแปลง - ซึ่งเป็นจุดรวมของการทดสอบ นอกจากนี้การรับรู้ของนักพัฒนาเกี่ยวกับการทดสอบ (มีอยู่) ดูเหมือนว่ายังขาด

— talonx

@talonx - ยังไม่เพียงพอที่จะทำการทดสอบแบบนี้หากการเปลี่ยนแปลงเล็กน้อยส่งผลให้เกิดการเปลี่ยนแปลงครั้งใหญ่ในห้องสวีทก็จะเป็นปัญหาโดยไม่คำนึงว่าพวกเขาดำเนินการโดยนักพัฒนากล่อง ci หรือผู้ทดสอบ

— FinnNk

@FinnNK: เห็นด้วย - การเปลี่ยนแปลงเล็กน้อยไม่ควรทำให้เกิดการเปลี่ยนแปลงครั้งใหญ่ นั่นหมายถึงกรณีทดสอบถูกเขียนโดยคนที่ไม่ได้ติดต่อกับนักพัฒนาที่ทำการเปลี่ยนแปลง - กลิ่นเหมือนช่องว่างการสื่อสาร

— talonx

@talonx: การทดสอบ UI มีความเปราะและใช้เวลานานกว่าการทดสอบหน่วย พวกเขาเป็นความท้าทายพิเศษดังนั้นฉันจะไม่ข้ามไปยังข้อสรุปเกี่ยวกับนักพัฒนาในองค์กรของ @ Sam

— azheglov

ฉันได้เปลี่ยนชื่อ - หวังว่าจะเป็นตัวแทนของคำถามอีกเล็กน้อยและลบน้อยกว่าเล็กน้อย

— Jon Hopkins

คำตอบ:

วัตถุประสงค์ของซีลีเนียมคือการสร้างการทดสอบการรวม UI ขับเคลื่อน

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

การทดสอบที่ใช้ UI นั้นเปราะบางแม้ว่า Selenium และ Watir จะเพิ่มขึ้นจากเครื่องมือบันทึกและเล่นในวันแรก ๆ มีหลายวิธีในการจัดการกับปัญหานี้ - นี่คือการรวบรวมคำแนะนำจากผู้เชี่ยวชาญระดับโลก:

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

ได้รับส่วนใหญ่ของความคุ้มครองการทดสอบจากการทดสอบระดับหน่วยและการยอมรับ ค้นหาลิงก์ไปยังบทความของ Gojko Adzic ในคำตอบของFinnNk Adzic ได้ถกเถียงกันซ้ำ ๆ เกี่ยวกับการทดสอบตรรกะทางธุรกิจผ่านการทดสอบการยอมรับและการเลี่ยงผ่าน UI

แต่ยังต้องมีการเขียนการทดสอบที่ขับเคลื่อนด้วย UI จำนวนหนึ่ง นี่คือที่ที่คุณต้องการคำแนะนำที่เป็นประโยชน์เพิ่มเติมจาก "อย่าทดสอบตรรกะทางธุรกิจของคุณผ่าน UI" ฉันขอแนะนำบล็อกของ Patrick Wilson-Welshเป็นจุดเริ่มต้น

— azheglov
แหล่งที่มา

ลิงค์สำหรับpatrickwilsonwelsh.comนั้นใช้งานไม่ได้อีกแล้วและทรัพยากรอื่น ๆ สำหรับสิ่งนั้น .. !!

— MarmiK

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

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

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

Gojko Adzic มีคำแนะนำที่ดีมากมายในบล็อกของเขาเมื่อพูดถึงการทดสอบประเภทนี้ - ลองดูSine of Deathและวิธีหลีกเลี่ยงโดยเฉพาะ

— FinnNk
แหล่งที่มา

คำแนะนำที่ดี FinnNk - ฉันได้สรุปวิธีการทั่วไป (เข้าสู่ระบบค้นหาวิดเจ็ตแถบด้านข้าง ฯลฯ ) - ดังนั้นความเสียหายจะลดลงเมื่อการทดสอบเปลี่ยนแปลง น่าเสียดายที่เราใช้ระบบความเหมาะสมที่สร้างวิดเจ็ตบางส่วนและสร้าง id สำหรับวิดเจ็ตตามตำแหน่งของพวกเขาในโดมดังนั้นเมื่อใดก็ตามที่มีการเคลื่อนไหวการทดสอบจะไม่ทำงาน

— Sam J

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

— FinnNk

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

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