รูปแบบ UI อัตโนมัติและแนวปฏิบัติที่ดีที่สุดสำหรับแอปพลิเคชันเดสก์ท็อป

9

พื้นหลัง

ฉันกำลังทำการทดสอบปลั๊กอินสำหรับ MS Office โดยอัตโนมัติ เรากำลังสร้างการทดสอบ Coded UI ใน VS 2010 ฉันคิดว่าฉันสามารถใช้เครื่องมือ " Coded UI test builder " แต่มันไม่เหมาะกับกรณีของฉัน

ด้วยเหตุนี้ฉันจึงสร้างคลาส UI Map ของฉันเองและวิธีการขยายสำหรับแต่ละ UI Control / Map ที่ฉันเพิ่มฟังก์ชันการทำงานที่แตกต่างกัน ตัวอย่างเช่นกดปุ่มหรือยืนยันค่า UI บางอย่าง

สถานการณ์ของกรณีทดสอบอยู่ในคลาสทดสอบ

ฉันใหม่ในพื้นที่นี้และฉันยังใหม่ในการทำงานเป็นผู้ทดสอบระบบอัตโนมัติ

คำถาม

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

programming-practices testing architecture

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

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

— Sparr

@Sparr ฉันแก้ไขคำถามเพื่อให้สามารถเข้าถึงได้มากขึ้น หวังว่ามันจะยังเหมาะกับความต้องการ

— Gary Rowe

6

แนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบการทำงานอัตโนมัติของ UI คือทำน้อยที่สุดเท่าที่จะทำได้ UIs เปลี่ยนบ่อยซึ่งหมายความว่าคุณต้องอัปเดตระบบอัตโนมัติของคุณอย่างต่อเนื่อง โดยทั่วไปแล้วดีกว่าการจัดโครงสร้างรหัสผลิตภัณฑ์ในลักษณะที่ช่วยให้การทดสอบอัตโนมัติโดยไม่มี UI Automation

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

1) ดูห้องสมุด UIAutomation ซึ่งเปิดตัวใน. Net 3.0 มีไลบรารีที่กว้างขวางและใช้งานง่ายสำหรับระบบอัตโนมัติ (http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) ดาวน์โหลด UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) ทำให้ UIs ของผลิตภัณฑ์เป็นแบบอัตโนมัติ

3a) ถ้าเป็น WPF ให้ใส่ AutomationIDs กับทุกสิ่ง

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

4) หลีกเลี่ยงคำสั่ง Thread.Sleep () ลองใช้ Waiters (ดู UIAutomation เอกสาร) แทน

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

6) ลงทะเบียนผู้ฟังสำหรับกิจกรรม UI เสมอก่อนที่จะดำเนินการซึ่งจะทำให้เหตุการณ์เริ่มทำงาน ในทางปฏิบัติหมายความว่าคุณจะทำงานกับเธรด

6a) ตัวอย่าง: อย่าเริ่มรอเหตุการณ์ Window Opened หลังจากคุณคลิกปุ่มเพื่อเปิดหน้าต่าง หน้าต่างอาจเปิดก่อนที่บริกรจะลงทะเบียนและไม่เคยได้รับเหตุการณ์

7) อย่าถือว่าหน้าต่างที่เพิ่งเปิดเป็นหน้าต่างที่คุณต้องการ หน้าต่างทุกประเภทอาจเปิดขึ้นโดยไม่คาดหมายใน Windows

ฉันสามารถไปต่อได้มากกว่านี้ แต่มันก็ใช้เวลาค่อนข้างนาน

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

1) - 3) สำหรับผู้ที่เขียนใบสมัครภายใต้การทดสอบ 6) ฉันก็เรียนรู้อย่างหนักเช่นกัน :)

— Andreas Reiff

2

สร้างการทดสอบการใช้งานจากกรณีใช้งานที่สามารถใช้ซ้ำได้

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

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

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

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

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

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

— Gary Rowe
แหล่งที่มา