ตัวอย่างกรณีทดสอบสำหรับแอปพลิเคชันบนเว็บ (รายการตรวจสอบ)
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
รายการตรวจสอบการทดสอบเว็บแอปพลิเคชันแบบครบถ้วนครอบคลุมการตรวจสอบด้านการใช้งาน ฟังก์ชันการทำงาน ความเข้ากันได้ ฐานข้อมูล API ความปลอดภัย ประสิทธิภาพ และการเข้าถึง แต่ละส่วนด้านล่างมีสถานการณ์ทดสอบที่พร้อมใช้งาน ซึ่งทีมประกันคุณภาพสามารถคัดลอกไปยังเครื่องมือจัดการการทดสอบได้โดยตรง
ขณะทดสอบเว็บแอปพลิเคชัน ควรพิจารณาเทมเพลตที่กล่าวถึงด้านล่าง รายการตรวจสอบด้านล่างนี้ใช้ได้กับเว็บแอปพลิเคชันทุกประเภท โดยขึ้นอยู่กับข้อกำหนดทางธุรกิจ
แม่แบบด้านบนแสดงให้เห็นว่าแผ่นงานเดียวสามารถรองรับสถานการณ์ต่างๆ สำหรับทุกหัวข้อในรายการตรวจสอบได้ สำหรับข้อมูลเพิ่มเติม โปรดดูที่... การทดสอบแอปพลิเคชันเว็บ ภาพรวม
ตอนนี้เรามาดูรายละเอียดแต่ละรายการตรวจสอบ:
การทดสอบสมรรถนะ
การทดสอบการทำงานคืออะไร?
- การทดสอบคุณสมบัติและพฤติกรรมการทำงานของผลิตภัณฑ์เพื่อให้แน่ใจว่าสอดคล้องกับคุณลักษณะจำเพาะ
- การทดสอบที่ละเว้นกลไกภายในของระบบหรือส่วนประกอบ และมุ่งเน้นไปที่เอาต์พุตที่สร้างขึ้นเพื่อตอบสนองต่ออินพุตและเงื่อนไขการดำเนินการที่เลือกเท่านั้น
วัตถุประสงค์หรือเป้าหมายของการทดสอบฟังก์ชันคืออะไร?
- เป้าหมายของการ การทดสอบสมรรถนะ คือการตรวจสอบว่าผลิตภัณฑ์ของคุณมีคุณสมบัติตรงตามข้อกำหนดการทำงานที่ตั้งใจไว้ซึ่งระบุไว้ในเอกสารการพัฒนาของคุณหรือไม่
ตัวอย่างสถานการณ์การทดสอบฟังก์ชัน:
- ทดสอบช่องบังคับทั้งหมดควรได้รับการตรวจสอบความถูกต้อง
- ทดสอบเครื่องหมายดอกจันควรแสดงสำหรับช่องบังคับทั้งหมด
- ทดสอบระบบไม่ควรแสดงข้อความแสดงข้อผิดพลาดสำหรับฟิลด์ตัวเลือก
- ทดสอบว่าปีอธิกสุรทินได้รับการตรวจสอบอย่างถูกต้อง และไม่ทำให้เกิดข้อผิดพลาด/การคำนวณผิด
- ทดสอบช่องตัวเลขไม่ควรยอมรับตัวอักษรและควรแสดงข้อความแสดงข้อผิดพลาดที่เหมาะสม
- ทดสอบตัวเลขติดลบหากได้รับอนุญาตสำหรับช่องตัวเลข
- การแบ่งการทดสอบด้วยศูนย์ควรได้รับการจัดการอย่างเหมาะสมสำหรับการคำนวณ
- ทดสอบความยาวสูงสุดของทุกฟิลด์เพื่อให้แน่ใจว่าข้อมูลจะไม่ถูกตัดทอน
- ทดสอบข้อความป๊อปอัป (“ฟิลด์นี้จำกัดอยู่ที่ 500 ตัวอักษร”) ควรปรากฏขึ้นหากข้อมูลถึงขนาดสูงสุดของฟิลด์
- ทดสอบว่าข้อความยืนยันควรแสดงสำหรับการดำเนินการอัปเดตและลบ
- ทดสอบค่าจำนวนเงินที่ควรแสดงในรูปแบบสกุลเงิน
- ทดสอบช่องป้อนข้อมูลทั้งหมดเพื่อหาอักขระพิเศษ
- ทดสอบฟังก์ชันการหมดเวลา
- ทดสอบฟังก์ชันการเรียงลำดับ
- ทดสอบการทำงานของปุ่มต่างๆ ที่ใช้งานได้
- ทดสอบนโยบายความเป็นส่วนตัวและคำถามที่พบบ่อยได้รับการกำหนดไว้อย่างชัดเจนและควรมีให้สำหรับผู้ใช้
- ทดสอบว่าฟังก์ชันการทำงานใดๆ ล้มเหลวหรือไม่ที่ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังหน้าข้อผิดพลาดแบบกำหนดเอง
- ทดสอบว่าเอกสารที่อัพโหลดทั้งหมดเปิดอย่างถูกต้อง
- ทดสอบว่าผู้ใช้ควรจะสามารถดาวน์โหลดไฟล์ที่อัพโหลดได้
- ทดสอบฟังก์ชั่นอีเมล์ของระบบ
- ทดสอบไฟล์ Java สคริปต์ทำงานอย่างถูกต้องในเบราว์เซอร์ที่แตกต่างกัน (IE, Firefox, Chrome, ซาฟารี และ Opera).
- ทดสอบเพื่อดูว่าจะเกิดอะไรขึ้นหากผู้ใช้ลบคุกกี้ขณะอยู่ในไซต์
- ทดสอบเพื่อดูว่าจะเกิดอะไรขึ้นหากผู้ใช้ลบคุกกี้หลังจากเยี่ยมชมไซต์
- ทดสอบข้อมูลทั้งหมดภายในกล่องคอมโบ/รายการโดยจัดเรียงตามลำดับเวลา
เมื่อฟังก์ชันต่างๆ ทำงานได้อย่างถูกต้องแล้ว คำถามต่อไปคือ ผู้ใช้จริงสามารถใช้งานได้โดยไม่ต้องขอความช่วยเหลือหรือไม่
การทดสอบการใช้งาน
การทดสอบการใช้งานคืออะไร?
- การทดสอบการใช้งานนั้นไม่มีอะไรนอกจากการตรวจสอบความเป็นมิตรต่อผู้ใช้
- ในการทดสอบการใช้งาน (Usability testing) จะทำการทดสอบขั้นตอนการใช้งานแอปพลิเคชัน เพื่อให้ผู้ใช้ใหม่สามารถเข้าใจแอปพลิเคชันได้ง่าย
- โดยพื้นฐานแล้ว การนำทางของระบบจะถูกตรวจสอบในการทดสอบการใช้งาน
วัตถุประสงค์หรือเป้าหมายของการทดสอบการใช้งานคืออะไร?
การทดสอบการใช้งานจะกำหนดความสะดวกในการใช้งานและประสิทธิภาพของผลิตภัณฑ์โดยใช้แนวทางปฏิบัติในการทดสอบการใช้งานมาตรฐาน
ตัวอย่างกรณีทดสอบการใช้งาน
- เนื้อหาของหน้าเว็บควรถูกต้องโดยไม่มีข้อผิดพลาดในการสะกดหรือไวยากรณ์
- แบบอักษรทั้งหมดควรเหมือนกันตามความต้องการ
- ข้อความทั้งหมดควรได้รับการจัดแนวอย่างเหมาะสม
- ข้อความแสดงข้อผิดพลาดทั้งหมดควรถูกต้องโดยไม่มีข้อผิดพลาดในการสะกดหรือไวยากรณ์ และข้อความแสดงข้อผิดพลาดควรตรงกับป้ายกำกับฟิลด์
- ข้อความคำแนะนำเครื่องมือควรมีในทุกช่อง
- ฟิลด์ทั้งหมดควรได้รับการจัดแนวอย่างเหมาะสม
- ควรจัดให้มีช่องว่างเพียงพอระหว่างป้ายกำกับฟิลด์ คอลัมน์ แถว และข้อความแสดงข้อผิดพลาด
- ปุ่มทั้งหมดควรอยู่ในรูปแบบและขนาดมาตรฐาน
- ลิงค์หน้าแรกควรมีในทุกหน้า
- ฟิลด์ที่ถูกปิดใช้งานควรเป็นสีเทา
- ตรวจสอบลิงก์และรูปภาพที่เสียหาย
- ควรแสดงข้อความยืนยันสำหรับการอัปเดตและการลบข้อมูลทุกประเภท
- ตรวจสอบไซต์ด้วยความละเอียดต่างๆ (640 x 480, 600×800 ฯลฯ?)
- ตรวจสอบว่าผู้ใช้สามารถรันระบบได้โดยไม่หงุดหงิด
- ตรวจสอบว่าแท็บควรทำงานอย่างถูกต้อง
- แถบเลื่อนควรปรากฏเฉพาะเมื่อจำเป็นเท่านั้น
- หากมีข้อความแสดงข้อผิดพลาดในการส่ง ข้อมูลที่กรอกโดยผู้ใช้ควรจะอยู่ที่นั่น
- ชื่อเรื่องควรแสดงบนหน้าเว็บแต่ละหน้า
- ฟิลด์ทั้งหมด (กล่องข้อความ เมนูแบบดร็อปดาวน์ ปุ่มตัวเลือก ฯลฯ) และปุ่มต่างๆ ควรสามารถเข้าถึงได้โดยใช้แป้นพิมพ์ลัด และผู้ใช้ควรสามารถดำเนินการต่างๆ ทั้งหมดได้โดยใช้แป้นพิมพ์
- ตรวจสอบว่าข้อมูลแบบเลื่อนลงไม่ถูกตัดทอนเนื่องจากขนาดฟิลด์ นอกจากนี้ ให้ตรวจสอบว่าข้อมูลได้รับการฮาร์ดโค้ดหรือจัดการผ่านผู้ดูแลระบบหรือไม่
รูปแบบการแสดงผลที่อ่านได้ดีในเบราว์เซอร์หนึ่ง อาจแสดงผลผิดพลาดในอีกเบราว์เซอร์หนึ่ง ดังนั้นจึงควรทดลองแสดงหน้าจอเดียวกันในทุกสภาพแวดล้อมที่รองรับ
การทดสอบความเข้ากันได้
การทดสอบความเข้ากันได้คืออะไร?
- การทดสอบความเข้ากันได้ใช้เพื่อพิจารณาว่าซอฟต์แวร์ของคุณเข้ากันได้กับองค์ประกอบอื่น ๆ ของระบบที่ควรทำงานร่วมด้วยหรือไม่ เช่น เบราว์เซอร์ Operaระบบ Ting หรือฮาร์ดแวร์
วัตถุประสงค์หรือเป้าหมายของการทดสอบความเข้ากันได้คืออะไร?
- วัตถุประสงค์ของการทดสอบความเข้ากันได้คือเพื่อประเมินว่าซอฟต์แวร์ทำงานได้ดีเพียงใดในเบราว์เซอร์เฉพาะ Operaระบบ ฮาร์ดแวร์หรือซอฟต์แวร์
ตัวอย่างสถานการณ์การทดสอบความเข้ากันได้:
- ทดสอบเว็บไซต์ในเบราว์เซอร์ต่างๆ (IE, Firefox, Chrome, Safari และ Opera) และตรวจสอบให้แน่ใจว่าเว็บไซต์แสดงอย่างถูกต้อง
- ทดสอบเวอร์ชัน HTML ที่ใช้ว่าเข้ากันได้กับเวอร์ชันเบราว์เซอร์ที่เหมาะสม
- ทดสอบภาพที่แสดงอย่างถูกต้องในเบราว์เซอร์ต่างๆ
- ทดสอบแบบอักษรว่าสามารถใช้งานได้ในเบราว์เซอร์ต่างๆ
- ทดสอบโค้ดจาวาสคริปต์ว่าสามารถใช้งานได้ในเบราว์เซอร์ที่แตกต่างกัน
- ทดสอบ GIF แบบเคลื่อนไหวในเบราว์เซอร์ต่างๆ
การแสดงผลที่สม่ำเสมอไม่ได้พิสูจน์อะไรเกี่ยวกับข้อมูลที่อยู่เบื้องหลังหน้าจอเลย การทดสอบข้ามเบราว์เซอร์ เมทริกซ์ช่วยให้พื้นที่นี้จัดการได้ง่าย
การทดสอบฐานข้อมูล
การทดสอบฐานข้อมูลคืออะไร?
- In การทดสอบฐานข้อมูล บันทึกแบ็กเอนด์ได้รับการทดสอบซึ่งถูกแทรกผ่านแอปพลิเคชันเว็บหรือเดสก์ท็อป ข้อมูลที่แสดงในเว็บแอปพลิเคชันควรตรงกับข้อมูลที่จัดเก็บไว้ในฐานข้อมูล
ในการดำเนินการทดสอบฐานข้อมูล ผู้ทดสอบควรทราบประเด็นที่กล่าวถึงด้านล่าง:
- ผู้ทดสอบควรเข้าใจข้อกำหนดด้านการทำงาน ตรรกะทางธุรกิจ ขั้นตอนการสมัคร และการออกแบบฐานข้อมูลอย่างละเอียด
- ผู้ทดสอบควรทราบตาราง ทริกเกอร์ ขั้นตอนการจัดเก็บ มุมมอง และเคอร์เซอร์ที่ใช้สำหรับแอปพลิเคชัน
- ผู้ทดสอบควรเข้าใจตรรกะของทริกเกอร์ ขั้นตอนการจัดเก็บ มุมมอง และเคอร์เซอร์ที่สร้างขึ้น
- ผู้ทดสอบควรระบุตารางที่จะได้รับผลกระทบเมื่อดำเนินการแทรก อัปเดต และลบ (DML) ผ่านทางเว็บหรือแอปพลิเคชันเดสก์ท็อป
ด้วยความช่วยเหลือของประเด็นที่กล่าวมาข้างต้น ผู้ทดสอบสามารถเขียนสถานการณ์การทดสอบสำหรับการทดสอบฐานข้อมูลได้อย่างง่ายดาย
ตัวอย่างกรณีทดสอบสำหรับการทดสอบฐานข้อมูล:
- ตรวจสอบชื่อฐานข้อมูล: ชื่อฐานข้อมูลต้องตรงกับข้อกำหนด
- ตรวจสอบตาราง คอลัมน์ ประเภทคอลัมน์ และค่าเริ่มต้น: ทุกสิ่งควรตรงกับข้อกำหนด
- ตรวจสอบว่าคอลัมน์อนุญาตให้มีค่าว่างหรือไม่
- ตรวจสอบคีย์หลักและคีย์นอกของแต่ละตาราง
- ตรวจสอบขั้นตอนการจัดเก็บ:
- ทดสอบว่ามีการติดตั้ง Stored Procedure หรือไม่
- ตรวจสอบชื่อขั้นตอนที่เก็บไว้
- ตรวจสอบชื่อพารามิเตอร์ ประเภท และจำนวนพารามิเตอร์
- ทดสอบพารามิเตอร์ว่าจำเป็นหรือไม่
- ทดสอบขั้นตอนการจัดเก็บโดยการลบพารามิเตอร์บางตัว
- ทดสอบเมื่อเอาต์พุตเป็นศูนย์ เร็กคอร์ดศูนย์ควรได้รับผลกระทบ
- ทดสอบขั้นตอนการจัดเก็บโดยการเขียนอย่างง่าย SQL คำสั่ง
- ทดสอบว่ากระบวนงานที่เก็บไว้ส่งกลับค่าหรือไม่
- ทดสอบขั้นตอนการจัดเก็บด้วยข้อมูลอินพุตตัวอย่าง
- ตรวจสอบพฤติกรรมของแต่ละแฟล็กในตาราง
- ตรวจสอบว่าข้อมูลได้รับการบันทึกลงในฐานข้อมูลอย่างถูกต้องหลังจากส่งหน้าแต่ละหน้า
- ตรวจสอบข้อมูลหากมีการดำเนินการ DML (อัปเดต ลบ และแทรก)
- ตรวจสอบความยาวของทุกฟิลด์: ความยาวของฟิลด์ในส่วนหลังและส่วนหน้าจะต้องเท่ากัน
- ตรวจสอบชื่อฐานข้อมูลของ QA, UAT และการผลิต ชื่อไม่ควรซ้ำกัน
- ตรวจสอบข้อมูลที่เข้ารหัสในฐานข้อมูล
- ตรวจสอบขนาดฐานข้อมูล ทดสอบเวลาตอบสนองของแบบสอบถามแต่ละรายการที่ดำเนินการด้วย
- ตรวจสอบข้อมูลที่แสดงในส่วนหน้าและให้แน่ใจว่าข้อมูลในส่วนหลังเหมือนกัน
- ตรวจสอบความถูกต้องของข้อมูลโดยการแทรกข้อมูลที่ไม่ถูกต้องลงในฐานข้อมูล
- ตรวจสอบทริกเกอร์
รายการตรวจสอบการทดสอบ API
กฎทางธุรกิจส่วนใหญ่ในปัจจุบันทำงานอยู่เบื้องหลัง REST หรือ GraphQL endpoints ดังนั้นการตรวจสอบผ่านเบราว์เซอร์เพียงอย่างเดียวจึงไม่สามารถพิสูจน์ได้ว่าระบบทำงานได้ การทดสอบ endpoints โดยตรงจะเปิดเผยข้อบกพร่องtracตรวจพบข้อบกพร่องด้าน t และการอนุญาตได้เร็วกว่าที่ส่วนติดต่อผู้ใช้จะตรวจพบได้มาก
ตรวจสอบสถานการณ์ต่อไปนี้ก่อนที่จะอนุมัติปลายทาง:
ตัวอย่างสถานการณ์ทดสอบสำหรับการทดสอบ API:
- ตรวจสอบรหัสสถานะที่บันทึกไว้สำหรับความสำเร็จ ความล้มเหลวในการตรวจสอบ การเข้าถึงโดยไม่ได้รับอนุญาต และข้อผิดพลาดของเซิร์ฟเวอร์
- ตรวจสอบว่าข้อมูลที่ได้รับจากการตอบกลับตรงกับโครงสร้างข้อมูลที่เผยแพร่ไว้ รวมถึงชื่อฟิลด์และประเภทข้อมูลด้วย
- ตรวจสอบว่าพารามิเตอร์ที่ขาดหายหรือมีรูปแบบไม่ถูกต้องส่งคืนข้อความที่อ่านได้แทนที่จะเป็นสแต็ก trace.
- ตรวจสอบว่าโทเค็นการตรวจสอบสิทธิ์หมดอายุ รีเฟรชอย่างถูกต้อง และไม่สามารถนำกลับมาใช้ใหม่ได้หลังจากออกจากระบบ
- ตรวจสอบการอนุญาตตามบทบาท เพื่อให้บัญชีผู้ใช้ทั่วไปไม่สามารถเข้าถึงปลายทางของผู้ดูแลระบบได้โดยการเปลี่ยนแปลงตัวระบุ
- ตรวจสอบค่าขอบเขตของพารามิเตอร์ทุกตัว รวมถึงสตริงว่างและความยาวสูงสุด
- ตรวจสอบว่าการจำกัดอัตราการส่งข้อมูลส่งผลให้การตอบสนองการควบคุมถูกต้อง แทนที่จะล้มเหลวโดยไม่มีการแจ้งเตือนใดๆ
- ตรวจสอบให้แน่ใจว่าอุปกรณ์ปลายทางลดระดับการทำงานลงอย่างราบรื่นเมื่อบริการของบุคคลที่สามหมดเวลา
- ตรวจสอบให้แน่ใจว่าไม่มีรหัสผ่าน โทเค็น หรือเส้นทางภายในปรากฏในข้อความตอบกลับหรือข้อความแสดงข้อผิดพลาด
เรียกใช้รายการนี้ในทุกสภาพแวดล้อม เนื่องจากสภาพแวดล้อมทดสอบและสภาพแวดล้อมใช้งานจริงมักมีชุดสิทธิ์ที่แตกต่างกัน โปรดดูที่... การทดสอบ API ภาพรวมและ การทดสอบ REST API ด้วยตนเอง.
การตรวจสอบหลายอย่างนั้นซ้ำซ้อนกับงานด้านความปลอดภัย
การทดสอบความปลอดภัย
การทดสอบความปลอดภัย เกี่ยวข้องกับการทดสอบเพื่อระบุข้อบกพร่องและช่องว่างจากมุมมองด้านความปลอดภัย
ตัวอย่างสถานการณ์การทดสอบสำหรับการทดสอบความปลอดภัย:
- ตรวจสอบว่าหน้าเว็บที่มีข้อมูลสำคัญ เช่น รหัสผ่าน หมายเลขบัตรเครดิต คำตอบลับสำหรับคำถามด้านความปลอดภัย ฯลฯ ควรส่งผ่านทาง HTTPS (SSL)
- ตรวจสอบข้อมูลสำคัญเช่น รหัสผ่าน หมายเลขบัตรเครดิต ฯลฯ ควรแสดงในรูปแบบเข้ารหัส
- ตรวจสอบกฎรหัสผ่านที่ถูกนำมาใช้ในหน้าการรับรองความถูกต้องทั้งหมด เช่น การลงทะเบียน ลืมรหัสผ่าน เปลี่ยนรหัสผ่าน
- ตรวจสอบว่ารหัสผ่านมีการเปลี่ยนแปลงหรือไม่ ผู้ใช้ไม่ควรเข้าสู่ระบบด้วยรหัสผ่านเก่า
- ตรวจสอบว่าข้อความแสดงข้อผิดพลาดไม่ควรแสดงข้อมูลสำคัญใดๆ
- ตรวจสอบว่าผู้ใช้ออกจากระบบหรือเซสชันผู้ใช้หมดอายุ ผู้ใช้ไม่ควรสามารถนำทางไซต์ได้
- ตรวจสอบเพื่อเข้าถึงหน้าเว็บที่มีการรักษาความปลอดภัยและไม่ปลอดภัยโดยตรงโดยไม่ต้องเข้าสู่ระบบ
- ตรวจสอบว่าตัวเลือก "ดูซอร์สโค้ด" ถูกปิดใช้งานและไม่ควรปรากฏให้ผู้ใช้เห็น
- ตรวจสอบว่าบัญชีผู้ใช้ถูกล็อคหากผู้ใช้ป้อนรหัสผ่านผิดหลายครั้ง
- ตรวจสอบคุกกี้ไม่ควรเก็บรหัสผ่าน
- ตรวจสอบว่าฟังก์ชันการทำงานใดๆ ไม่ทำงาน ระบบไม่ควรแสดงข้อมูลแอปพลิเคชัน เซิร์ฟเวอร์ หรือฐานข้อมูลใดๆ แต่ควรแสดงหน้าข้อผิดพลาดแบบกำหนดเองแทน
- ตรวจสอบการโจมตีการฉีด SQL
- ตรวจสอบบทบาทของผู้ใช้และสิทธิ์ของพวกเขา ตัวอย่างเช่น ผู้ร้องขอไม่ควรสามารถเข้าถึงหน้าผู้ดูแลระบบได้
- ตรวจสอบให้แน่ใจว่าการดำเนินการที่สำคัญถูกบันทึกไว้ในไฟล์บันทึก และข้อมูลเหล่านั้นควรเป็นเช่นนั้น traceable.
- ตรวจสอบว่าค่าเซสชันอยู่ในรูปแบบที่เข้ารหัสในแถบที่อยู่
- ตรวจสอบว่าข้อมูลคุกกี้ถูกจัดเก็บในรูปแบบที่เข้ารหัส
- ตรวจสอบแอปพลิเคชันสำหรับการโจมตีแบบ Brute Force
หากวัสดุแข็งตัวจนโก่งงอเมื่อรับน้ำหนักแล้ว ก็ยังใช้งานไม่ได้ ดังนั้นขั้นตอนต่อไปคือการวัดขนาด
การทดสอบประสิทธิภาพ
การทดสอบประสิทธิภาพ ดำเนินการเพื่อประเมินความสอดคล้องของระบบหรือส่วนประกอบตามข้อกำหนดด้านประสิทธิภาพที่ระบุ
สถานการณ์การทดสอบทั่วไป:
- เพื่อกำหนดประสิทธิภาพ ความเสถียร และความสามารถในการปรับขนาดของแอปพลิเคชันภายใต้สภาวะโหลดที่แตกต่างกัน
- เพื่อตรวจสอบว่าสถาปัตยกรรมปัจจุบันสามารถรองรับแอปพลิเคชันในระดับผู้ใช้สูงสุดได้หรือไม่
- เพื่อกำหนดขนาดการกำหนดค่าที่ให้ระดับประสิทธิภาพที่ดีที่สุด
- เพื่อระบุจุดคอขวดของแอปพลิเคชันและโครงสร้างพื้นฐาน
- เพื่อตรวจสอบว่าซอฟต์แวร์เวอร์ชันใหม่ส่งผลเสียต่อเวลาตอบสนองหรือไม่
- เพื่อประเมินผลิตภัณฑ์และ/หรือฮาร์ดแวร์เพื่อพิจารณาว่าสามารถรองรับปริมาณโหลดที่คาดการณ์ไว้ได้หรือไม่
การทดสอบประสิทธิภาพทำอย่างไร? โดยการทดสอบด้วยตนเองหรือโดยระบบอัตโนมัติ
ในทางปฏิบัติแล้ว เป็นไปไม่ได้ที่จะทำการทดสอบประสิทธิภาพด้วยตนเอง เนื่องจากมีข้อเสียบางประการ เช่น:
- จะต้องมีทรัพยากรจำนวนมากขึ้น
- การดำเนินการพร้อมกันไม่สามารถทำได้
- ไม่มีการตรวจสอบระบบที่เหมาะสม
- ไม่ใช่เรื่องง่ายที่จะทำงานซ้ำๆ
ดังนั้นเพื่อเอาชนะปัญหาข้างต้น เราควรใช้เครื่องมือทดสอบประสิทธิภาพ ด้านล่างนี้คือรายการเครื่องมือทดสอบยอดนิยมบางส่วน
- Apache JMeter
- โหลดนักวิ่ง
- บอร์แลนด์ Silk Performer.
- Rational Performance Tester
- สวพ
- นีโอโหลด
ยังมีกลุ่มเป้าหมายอีกกลุ่มหนึ่งที่ยังขาดหายไป นั่นคือผู้ใช้งานที่เข้าถึงหน้าจอเหล่านี้ผ่านเทคโนโลยีช่วยเหลือ
รายการตรวจสอบการทดสอบการเข้าถึง
การทดสอบการเข้าถึงยืนยันว่าผู้ที่ใช้โปรแกรมอ่านหน้าจอ การนำทางด้วยแป้นพิมพ์เท่านั้น หรือการขยายภาพ สามารถดำเนินการตามขั้นตอนเดียวกันกับผู้ใช้รายอื่นได้ นอกจากนี้ยังเป็นข้อกำหนดในการจัดซื้อจัดจ้าง เนื่องจากองค์กรต่างๆ จำเป็นต้องทำการทดสอบนี้tracts มักหมายถึง WCAG 2.2 ระดับ AAข้อบกพร่องเหล่านี้เป็นปัญหาเชิงโครงสร้าง และการแก้ไขตั้งแต่เนิ่นๆ จะมีต้นทุนต่ำกว่ามาก
ตัวอย่างสถานการณ์ทดสอบสำหรับการทดสอบการเข้าถึง:
- ตรวจสอบให้แน่ใจว่าภาพที่มีความหมายมีข้อความอธิบาย (alt text) และภาพตกแต่งถูกซ่อนจากเทคโนโลยีช่วยเหลือผู้พิการ
- ตรวจสอบให้แน่ใจว่าทุกส่วนควบคุมในแบบฟอร์มมีป้ายกำกับที่เชื่อมโยงกันด้วยโปรแกรม ไม่ใช่แค่ข้อความตัวอย่างที่อยู่ติดกัน
- ตรวจสอบว่าหน้าเว็บทำงานได้ด้วยแป้นพิมพ์เพียงอย่างเดียว โดยมีตัวบ่งชี้การโฟกัสที่มองเห็นได้ในแต่ละจุด
- ตรวจสอบให้แน่ใจว่าข้อความและองค์ประกอบแบบโต้ตอบมีอัตราส่วนความคมชัดขั้นต่ำเมื่อเทียบกับพื้นหลัง
- ตรวจสอบว่าหัวข้อเรียงลำดับอย่างเป็นระบบโดยไม่ข้ามระดับ เพื่อให้โปรแกรมอ่านหน้าจอใช้งานได้
- ตรวจสอบว่ามีการแจ้งข้อความแสดงข้อผิดพลาดไปยังเทคโนโลยีช่วยเหลือ และระบุช่องข้อมูลที่มีปัญหา
- ตรวจสอบว่าหน้าเว็บยังคงใช้งานได้ที่ระดับการซูม 200 เปอร์เซ็นต์โดยไม่ต้องเลื่อนแนวนอน
- ตรวจสอบให้แน่ใจว่าวิดเจ็ตแบบกำหนดเอง เช่น โมดอล แท็บ และแอคคอร์เดียน แสดงบทบาทและสถานะที่ถูกต้อง
เครื่องสแกนอัตโนมัติตรวจจับปัญหาได้เพียงบางส่วนเท่านั้น ดังนั้นควรเพิ่มการตรวจสอบแป้นพิมพ์และการอ่านหน้าจอด้วยตนเองเข้าไปด้วย การทดสอบการเข้าถึง เอกสารอ้างอิงครอบคลุมถึงเครื่องมือต่างๆ
