กลยุทธ์การทดสอบ

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

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

• ตรวจหาปัญหาตั้งแต่เนิ่นๆ
• ทำงานอย่างรวดเร็ว
• ระบุอย่างชัดเจนเมื่อต้องทำการแก้ไข

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

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

พีระมิดที่ใช้ทดสอบ

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

*ความสอดคล้องหมายถึงความคล้ายคลึงกันของสภาพแวดล้อมรันไทม์ของการทดสอบกับสภาพแวดล้อมที่ใช้งานจริง

ภาพที่ 1 โดยทั่วไปแล้ว การแจกแจงจํานวนการทดสอบตามขอบเขตจะแสดงเป็นภาพพีระมิด

แอปส่วนใหญ่ควรมีการทดสอบเล็กๆ จำนวนมากและการทดสอบขนาดใหญ่ค่อนข้างน้อย การแจกแจงการทดสอบในแต่ละหมวดหมู่ควรเป็นรูปพีระมิด โดยให้การทดสอบขนาดเล็กจำนวนมากเป็นฐาน และการทดสอบขนาดใหญ่จํานวนน้อยเป็นยอด

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

ลดต้นทุนของข้อบกพร่อง

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

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

รูปที่ 2 กลยุทธ์ยอดนิยมที่มีการทดสอบจำนวนมากด้วยตนเอง โดยจะทำการทดสอบอุปกรณ์ทุกคืนเท่านั้น

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

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

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

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

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

กลยุทธ์การทดสอบที่รองรับการปรับขนาด

เดิมทีพีระมิดทดสอบแบ่งออกเป็น 3 หมวดหมู่ ดังนี้

• การทดสอบ 1 หน่วย
• การทดสอบการผสานรวม
• การทดสอบจากต้นทางถึงปลายทาง

อย่างไรก็ตาม แนวคิดเหล่านี้ไม่มีคำจำกัดความที่แน่นอน ทีมจึงอาจต้องการกำหนดหมวดหมู่ของตนแตกต่างกันไป เช่น ใช้ 5 ชั้น ดังนี้

รูปที่ 3 พีระมิดการทดสอบ 5 ชั้น

• การทดสอบหน่วยจะทำงานบนเครื่องโฮสต์และยืนยันตรรกะการทำงานแบบฟังก์ชันเดียวที่ไม่ขึ้นอยู่กับเฟรมเวิร์ก Android
  • ตัวอย่าง: การยืนยันข้อผิดพลาดทีละข้อในฟังก์ชันทางคณิตศาสตร์
• การทดสอบคอมโพเนนต์จะยืนยันฟังก์ชันการทำงานหรือลักษณะที่ปรากฏของโมดูลหรือคอมโพเนนต์หนึ่งๆ โดยแยกจากคอมโพเนนต์อื่นๆ ในระบบ พื้นที่ผิวของการทดสอบคอมโพเนนต์จะขยายไปถึงการแยกแยะระดับสูงขึ้นเหนือเมธอดและคลาสแต่ละรายการ ซึ่งแตกต่างจากการทดสอบหน่วย
  • เช่น การทดสอบภาพหน้าจอของปุ่มที่กำหนดเอง
• การทดสอบฟีเจอร์จะยืนยันการโต้ตอบของคอมโพเนนต์หรือโมดูลอิสระอย่างน้อย 2 รายการ การทดสอบฟีเจอร์มีขนาดใหญ่และซับซ้อนกว่า และมักจะทำงานที่ระดับฟีเจอร์
  • ตัวอย่าง: การทดสอบลักษณะการทํางานของ UI ที่ยืนยันการจัดการสถานะในหน้าจอ
• การทดสอบแอปพลิเคชันจะยืนยันฟังก์ชันการทํางานของแอปพลิเคชันทั้งหมดในรูปแบบไบนารีที่ติดตั้งใช้งานได้ ซึ่งเป็นการทดสอบการผสานรวมขนาดใหญ่ที่ใช้ไบนารีที่แก้ไขข้อบกพร่องได้ เช่น บิลด์สำหรับนักพัฒนาซอฟต์แวร์ที่มีฮุกการทดสอบ เป็นตัวระบบทดสอบ
  • ตัวอย่าง: การทดสอบลักษณะการทํางานของ UI เพื่อยืนยันการเปลี่ยนแปลงการกําหนดค่าในการทดสอบแบบพับได้ การแปลภาษา และการช่วยเหลือพิเศษ
• การทดสอบรุ่นที่อาจได้รับการเผยแพร่จะยืนยันฟังก์ชันการทำงานของรุ่นที่เผยแพร่ การทดสอบเหล่านี้คล้ายกับการทดสอบแอปพลิเคชัน ยกเว้นว่าไบนารีของแอปพลิเคชันจะได้รับการย่อขนาดและเพิ่มประสิทธิภาพ โดยเป็นการทดสอบการผสานรวมขนาดใหญ่จากต้นทางถึงปลายทาง ซึ่งเรียกใช้ในสภาพแวดล้อมที่ใกล้เคียงกับเวอร์ชันที่ใช้งานจริงมากที่สุด โดยไม่ทำให้แอปแก่บัญชีผู้ใช้สาธารณะหรือแบ็กเอนด์สาธารณะ
  • ตัวอย่าง: เส้นทางของผู้ใช้ที่สําคัญ การทดสอบประสิทธิภาพ

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

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

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

เลือกหมวดหมู่การทดสอบ

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

เช่น ลองดูวิธีทดสอบการติดตั้งใช้งานฟีเจอร์นี้: UI ของขั้นตอนการลงชื่อเข้าใช้ คุณจะต้องเลือกหมวดหมู่ต่างๆ ดังนี้ โดยขึ้นอยู่กับสิ่งที่ต้องทดสอบ

เรื่องที่ทดสอบ	คำอธิบายของสิ่งที่กำลังทดสอบ	หมวดหมู่การทดสอบ	ตัวอย่างประเภทการทดสอบ
ตรรกะโปรแกรมตรวจสอบแบบฟอร์ม	คลาสที่ตรวจสอบอีเมลเทียบกับนิพจน์ทั่วไปและตรวจสอบว่าป้อนช่องรหัสผ่านแล้ว เนื่องจากไม่มีทรัพยากร Dependency	การทดสอบ 1 หน่วย	การทดสอบ 1 หน่วย JVM ในเครื่อง
ลักษณะการทํางานของ UI แบบฟอร์มการลงชื่อเข้าใช้	แบบฟอร์มที่มีปุ่มที่เปิดใช้เฉพาะเมื่อแบบฟอร์มได้รับการตรวจสอบแล้วเท่านั้น	การทดสอบคอมโพเนนต์	การทดสอบลักษณะการทํางานของ UI ที่ทํางานบน Robolectric
ลักษณะ UI ของแบบฟอร์มการลงชื่อเข้าใช้	แบบฟอร์มที่เป็นไปตามข้อกำหนด UX	การทดสอบคอมโพเนนต์	เขียนการทดสอบภาพหน้าจอตัวอย่าง
การผสานรวมกับเครื่องมือจัดการสิทธิ์	UI ที่ส่งข้อมูลเข้าสู่ระบบไปยังเครื่องมือจัดการการตรวจสอบสิทธิ์และรับการตอบกลับที่อาจมีข้อผิดพลาดที่แตกต่างกัน	การทดสอบฟีเจอร์	การทดสอบ JVM ด้วยข้อมูลจำลอง
กล่องโต้ตอบลงชื่อเข้าใช้	หน้าจอที่แสดงแบบฟอร์มการลงชื่อเข้าใช้เมื่อกดปุ่มเข้าสู่ระบบ	การทดสอบแอปพลิเคชัน	การทดสอบลักษณะการทํางานของ UI ที่ทํางานบน Robolectric
เส้นทางของผู้ใช้ที่สำคัญ: การลงชื่อเข้าใช้	ขั้นตอนการลงชื่อเข้าใช้ที่สมบูรณ์โดยใช้บัญชีทดสอบกับเซิร์ฟเวอร์ที่ใช้ทดสอบ	รุ่นที่อาจได้รับการเผยแพร่	การทดสอบลักษณะการทํางานของ UI ของ Compose แบบครบวงจรที่ทํางานบนอุปกรณ์

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

โปรดทราบว่าหมวดหมู่การทดสอบไม่ได้กำหนดประเภทการทดสอบ และบางฟีเจอร์ไม่จำเป็นต้องทดสอบในทุกหมวดหมู่

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

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

โครงสร้างพื้นฐานการทดสอบ

กลยุทธ์การทดสอบต้องได้รับการสนับสนุนจากโครงสร้างพื้นฐานและเครื่องมือที่จะช่วยให้นักพัฒนาแอปทำการทดสอบอย่างต่อเนื่องและบังคับใช้กฎที่รับประกันว่าการทดสอบทั้งหมดจะผ่าน

คุณสามารถจัดหมวดหมู่การทดสอบตามขอบเขตเพื่อกำหนดเวลาและตำแหน่งที่จะทำการทดสอบ ตัวอย่างเช่น การทำตามโมเดล 5 เลเยอร์

หมวดหมู่	สภาพแวดล้อม (ตำแหน่ง)	ทริกเกอร์ (เมื่อ)
หน่วย	[Local][4]	ทุกคอมมิต
คอมโพเนนต์	ในพื้นที่	ทุกคอมมิต
ฟีเจอร์	ในเครื่องและโปรแกรมจำลอง	ก่อนผสาน ก่อนผสานหรือส่งการเปลี่ยนแปลง
แอปพลิเคชัน	อุปกรณ์จำลองในเครื่อง โทรศัพท์ 1 เครื่อง แบบพับได้ 1 เครื่อง	หลังการผสาน หลังจากการผสานหรือส่งการเปลี่ยนแปลง
ตัวเลือกถอนการอ้างสิทธิ์	โทรศัพท์ 8 เครื่อง, พับได้ 1 เครื่อง, แท็บเล็ต 1 เครื่อง	ก่อนเปิดตัว

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

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

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