การทดสอบแอปพลิเคชันคืออะไร?

การทดสอบแอปพลิเคชันคืออะไร?

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

ช่วยปรับปรุงคุณภาพของแอปพลิเคชันของคุณพร้อมทั้งลดต้นทุน เพิ่ม ROI สูงสุด และประหยัดเวลาในการพัฒนา

ในสาขาวิศวกรรมซอฟต์แวร์ การทดสอบแอปพลิเคชันสามารถทำได้ในหลายประเภท เช่น GUI ฟังก์ชันการทำงาน ฐานข้อมูล (แบ็กเอนด์) การทดสอบโหลด เป็นต้น

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

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

จะทดสอบแอปพลิเคชันได้อย่างไร?

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

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

• ขั้นที่ 1) ออกแบบแผนการทดสอบตามความต้องการของแอปพลิเคชัน
• ขั้นที่ 2) พัฒนากรณีทดสอบด้วยตนเองและสคริปต์ทดสอบอัตโนมัติ
• ขั้นที่ 3) ดำเนินการทดสอบการทำงานเพื่อตรวจสอบข้อกำหนดของแอปพลิเคชัน
• ขั้นที่ 4) ดำเนินการทดสอบโหลดและปรับแต่งประสิทธิภาพของแอปพลิเคชัน

ประเภทของการทดสอบที่ดำเนินการขึ้นอยู่กับประเภทของแอปพลิเคชันที่กำลังทดสอบ การทดสอบแอปพลิเคชันแบ่งออกเป็น 3 ส่วน

• การทดสอบแอปพลิเคชันเว็บ
• การทดสอบแอปพลิเคชันเดสก์ท็อป
• การทดสอบแอปพลิเคชันมือถือ

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

เปรียบเทียบการทดสอบแอปพลิเคชันบนเว็บ เดสก์ท็อป และมือถือ

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

จุดแตกต่าง	เว็บ	เดสก์ทอป	โทรศัพท์มือถือ
วิ่งบน	เบราว์เซอร์บนเครือข่าย	เครื่องที่ติดตั้งแล้วหนึ่งเครื่อง	โทรศัพท์มือถือหรือแท็บเล็ต
ตัวแปรหลัก	เบราว์เซอร์และเวอร์ชัน	Operaระบบและฮาร์ดแวร์	อุปกรณ์ เวอร์ชันระบบปฏิบัติการ และขนาดหน้าจอ
การพึ่งพาเครือข่าย	เชื่อมต่ออยู่เสมอ	มักจะออฟไลน์	เป็นช่วงๆ และต้องเอาชีวิตรอดจากการสูญเสีย
ความเสี่ยงที่ใหญ่ที่สุด	การแสดงผลและการโหลดข้ามเบราว์เซอร์	การติดตั้งและความเข้ากันได้	การกระจายตัวของอุปกรณ์ต่างๆ
การจัดการขัดจังหวะ	ไม่ค่อยเกี่ยวข้อง	ไม่ค่อยเกี่ยวข้อง	สายเรียกเข้า การแจ้งเตือน และแบตเตอรี่เหลือน้อย
อัปเดตเส้นทาง	ฝั่งเซิร์ฟเวอร์ รวดเร็วทันใจสำหรับทุกคน	ผู้ใช้ติดตั้งแพทช์	การตรวจสอบแอปใน App Store, การเปิดตัวแบบเป็นขั้นตอน

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

วิธีการทดสอบแอปพลิเคชัน

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

การทดสอบมีสามวิธี

• สีดำ Box การทดสอบ
• สีขาว Box การทดสอบ
• สีเทา Box การทดสอบ

สีดำ Box การทดสอบ

สีดำ Box การทดสอบ เทคนิคที่ใช้กันทั่วไปในการทดสอบ การทดสอบเชิงฟังก์ชัน การทดสอบแบบไม่เชิงฟังก์ชัน และการทดสอบการถดถอย ในการทดสอบแบบกล่องดำ กลยุทธ์ที่ใช้คือ

• การทดสอบระดับความเท่าเทียมกัน
• การทดสอบค่าขอบเขต
• การทดสอบตารางการตัดสินใจ
• ตารางการเปลี่ยนสถานะ

สีขาว Box การทดสอบ

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

• Code การวิเคราะห์ความครอบคลุม
• ความครอบคลุมเส้นทาง

สีเทา Box การทดสอบ

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

แผนการทดสอบสำหรับการทดสอบแอปพลิเคชัน

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

แผนการทดสอบมาตรฐานสำหรับการทดสอบแอปพลิเคชันควรจะกำหนดคุณลักษณะต่อไปนี้

• กำหนดขอบเขตของการทดสอบ
• กำหนดวัตถุประสงค์ของการทดสอบ
• แนวทางกิจกรรมการทดสอบ
• กำหนดการทดสอบ
• Bug tracกษัตริย์และการรายงาน

เกณฑ์การเข้าและออกสำหรับการทดสอบแอปพลิเคชัน

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

เกณฑ์การเข้า ต้องได้รับการอนุมัติก่อนจึงจะเริ่มดำเนินการได้

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

เกณฑ์การออก แสดงให้เห็นว่าขั้นตอนดังกล่าวบรรลุวัตถุประสงค์แล้ว

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

เครื่องมือทดสอบแอปพลิเคชัน

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

นี่คือบางส่วนของพวกเขา

• Selenium
• IBM Rational Functional Tester (อาร์เอฟที)
• โหลดรันเนอร์ (ตอนนี้ OpenText LoadRunner (เดิมคือ HP และ Micro Focus)
• Apache JMeter

💡 หมายเหตุ: IBM Rational Robot ซึ่งเคยอยู่ในรายชื่อผลิตภัณฑ์ร่วมกับ RFT ได้ถูกถอนออกจากตลาดแล้ว ปัจจุบัน Rational Functional Tester เป็นผลิตภัณฑ์ที่วางจำหน่ายอยู่ IBM ดังนั้นโครงการใหม่ไม่ควรวางแผนโดยยึดหุ่นยนต์เป็นหลัก

ตัวชี้วัดสำคัญสำหรับการทดสอบแอปพลิเคชัน

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

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

Tracควรพิจารณาแนวโน้มมากกว่าการอ่านค่าเพียงครั้งเดียว วัฏจักรเดียวเพียงอย่างเดียวบอกอะไรได้น้อยมาก

การทดสอบแนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบแอปพลิเคชัน

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

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

• กำหนดข้อกำหนดการทำงาน
• Revews และการตรวจสอบ
• เกณฑ์การเข้าและออกอย่างเป็นทางการ
• รูปแบบการทดสอบการทำงาน
• การทดสอบหลายแพลตฟอร์ม
• การดำเนินการทดสอบอัตโนมัติ

ความท้าทายในการทดสอบแอปพลิเคชัน

ในระหว่างการทดสอบแอปพลิเคชัน ผู้ทดสอบอาจพบกับความท้าทายหลายประการ

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

การทดสอบแอปพลิเคชันมือถือ

เช่นเดียวกับการทดสอบแอปพลิเคชันเว็บ โทรศัพท์มือถือ การทดสอบแอปพลิเคชันก็ใช้กลยุทธ์และวิธีการทดสอบแบบเดียวกัน ความแตกต่างอาจอยู่ที่เครื่องมือที่ใช้ในการทดสอบ เครื่องมือทั่วไปที่ใช้ในการทดสอบแอปพลิเคชันบนมือถือ ได้แก่ Appium, TestComplete, Robotiumและ Espresso.

ประเภทของแอปพลิเคชันบนมือถือแบ่งออกเป็นสามประเภท

• แอปพลิเคชันเว็บ - ผู้ใช้เข้าถึงได้ผ่านเครือข่ายเช่นอินเทอร์เน็ตหรืออินทราเน็ต
• Native Application- ได้รับการพัฒนาสำหรับแพลตฟอร์มเฉพาะและติดตั้งบนอุปกรณ์คอมพิวเตอร์
• แอปพลิเคชันไฮบริด - คือแอปพลิเคชันที่ผสมผสานองค์ประกอบของทั้งเว็บและแอปพลิเคชันเนทีฟ ตัวอย่างเช่น Facebook

สำหรับแพลตฟอร์มมือถือส่วนใหญ่ คุณสามารถใช้ CSS, HTML, JS ฯลฯ แบบธรรมดาได้

ตัวอย่างกรณีทดสอบสำหรับการทดสอบแอปพลิเคชันบนมือถือ

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

สำหรับ Mobile Application สิ่งที่ต้องทดสอบได้แก่

• การติดตั้ง
• OTA
• Wi-Fi
• สายเคเบิลข้อมูล
• บลูทู ธ
• ถอนการติดตั้ง
• โลโก้แอปพลิเคชัน
• สาด
• หน่วยความจำต่ำ
• คำติชมด้วยภาพ
• ออกจากแอปพลิเคชัน
• เริ่ม/รีสตาร์ทแอปพลิเคชัน

ความท้าทายในการทดสอบมือถือ

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

• ครอบคลุมการทดสอบที่ครอบคลุม
• การจัดการการกระจายตัว (เวอร์ชัน OS, โปรเซสเซอร์, หน่วยความจำที่แตกต่างกัน)
• ขาดแผนการทดสอบ
• ความกดดันด้านเวลา
• ขาดอุปกรณ์ทางกายภาพ
• ความหลากหลายในแพลตฟอร์มและระบบปฏิบัติการ

คำถามที่พบบ่อย