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

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

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

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

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

android skills add testing-setup

พีระมิดการทดสอบ

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

*ความเที่ยงตรงหมายถึงความคล้ายคลึงกันของสภาพแวดล้อมรันไทม์ของการทดสอบกับสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์

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

ลดค่าใช้จ่ายของข้อบกพร่อง

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

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

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

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

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

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

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

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

• การทดสอบหน่วย
• การทดสอบการผสานรวม
• การทดสอบตั้งแต่ต้นจนจบ

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

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

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

กำหนดหมวดหมู่การทดสอบ

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

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

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

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

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

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

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

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

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

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