การทดสอบซอฟต์แวร์ - เอกสาร
เอกสารประกอบการทดสอบเกี่ยวข้องกับเอกสารของสิ่งประดิษฐ์ที่ควรพัฒนาก่อนหรือระหว่างการทดสอบซอฟต์แวร์
เอกสารสำหรับการทดสอบซอฟต์แวร์ช่วยในการประมาณค่าความพยายามในการทดสอบความครอบคลุมของการทดสอบการติดตาม / การติดตามความต้องการ ฯลฯ ส่วนนี้จะอธิบายถึงสิ่งประดิษฐ์ที่เป็นเอกสารที่ใช้กันทั่วไปซึ่งเกี่ยวข้องกับการทดสอบซอฟต์แวร์เช่น -
- แผนการทดสอบ
- สถานการณ์ทดสอบ
- กรณีทดสอบ
- เมทริกซ์การตรวจสอบย้อนกลับ
แผนการทดสอบ
แผนการทดสอบจะแสดงกลยุทธ์ที่จะใช้ในการทดสอบแอปพลิเคชันทรัพยากรที่จะใช้สภาพแวดล้อมการทดสอบที่จะดำเนินการทดสอบและข้อ จำกัด ของการทดสอบและกำหนดการของกิจกรรมการทดสอบ โดยปกติหัวหน้าทีมประกันคุณภาพจะรับผิดชอบในการเขียนแผนการทดสอบ
แผนการทดสอบมีดังต่อไปนี้ -
- บทนำสู่เอกสารแผนการทดสอบ
- สมมติฐานขณะทดสอบแอปพลิเคชัน
- รายชื่อกรณีทดสอบที่รวมอยู่ในการทดสอบแอปพลิเคชัน
- รายการคุณสมบัติที่จะทดสอบ
- วิธีการประเภทใดที่จะใช้ในขณะทดสอบซอฟต์แวร์
- รายการส่งมอบที่ต้องทดสอบ
- ทรัพยากรที่จัดสรรสำหรับการทดสอบแอปพลิเคชัน
- ความเสี่ยงใด ๆ ที่เกี่ยวข้องระหว่างกระบวนการทดสอบ
- กำหนดการของงานและเหตุการณ์สำคัญที่จะบรรลุ
สถานการณ์ทดสอบ
เป็นคำสั่งบรรทัดเดียวที่แจ้งว่าจะทดสอบพื้นที่ใดในแอปพลิเคชัน สถานการณ์การทดสอบใช้เพื่อให้แน่ใจว่าโฟลว์กระบวนการทั้งหมดถูกทดสอบตั้งแต่ต้นจนจบ พื้นที่เฉพาะของแอปพลิเคชันสามารถมีได้มากถึงหนึ่งสถานการณ์ทดสอบไปจนถึงสองสามร้อยสถานการณ์ขึ้นอยู่กับขนาดและความซับซ้อนของแอปพลิเคชัน
คำว่า 'สถานการณ์ทดสอบ' และ 'กรณีทดสอบ' ใช้แทนกันได้อย่างไรก็ตามสถานการณ์ทดสอบมีหลายขั้นตอนในขณะที่กรณีทดสอบมีขั้นตอนเดียว เมื่อมองจากมุมมองนี้สถานการณ์ทดสอบเป็นกรณีทดสอบ แต่รวมถึงกรณีทดสอบหลายกรณีและลำดับที่ควรดำเนินการ นอกเหนือจากนี้การทดสอบแต่ละครั้งจะขึ้นอยู่กับผลลัพธ์จากการทดสอบครั้งก่อน
กรณีทดสอบ
กรณีทดสอบเกี่ยวข้องกับชุดของขั้นตอนเงื่อนไขและอินพุตที่สามารถใช้ได้ในขณะดำเนินการทดสอบ วัตถุประสงค์หลักของกิจกรรมนี้คือเพื่อให้แน่ใจว่าซอฟต์แวร์ผ่านหรือล้มเหลวในแง่ของการทำงานและด้านอื่น ๆ กรณีทดสอบมีหลายประเภทเช่นฟังก์ชันเชิงลบข้อผิดพลาดกรณีทดสอบเชิงตรรกะกรณีทดสอบทางกายภาพกรณีทดสอบ UI เป็นต้น
นอกจากนี้ยังมีการเขียนกรณีทดสอบเพื่อติดตามความครอบคลุมการทดสอบของซอฟต์แวร์ โดยทั่วไปไม่มีเทมเพลตที่เป็นทางการที่สามารถใช้ระหว่างการเขียนกรณีทดสอบได้ อย่างไรก็ตามส่วนประกอบต่อไปนี้จะพร้อมใช้งานเสมอและรวมอยู่ในทุกกรณีการทดสอบ -
- รหัสกรณีทดสอบ
- โมดูลผลิตภัณฑ์
- รุ่นผลิตภัณฑ์
- ประวัติการแก้ไข
- Purpose
- Assumptions
- Pre-conditions
- Steps
- ผลที่คาดว่าจะได้รับ
- ผลลัพธ์ที่แท้จริง
- Post-conditions
กรณีการทดสอบหลายกรณีได้มาจากสถานการณ์การทดสอบเดียว นอกจากนี้ในบางครั้งกรณีการทดสอบหลายกรณีถูกเขียนขึ้นสำหรับซอฟต์แวร์ตัวเดียวซึ่งเรียกรวมกันว่าชุดทดสอบ
เมทริกซ์การตรวจสอบย้อนกลับ
Traceability Matrix (หรือที่เรียกว่า Requirement Traceability Matrix - RTM) เป็นตารางที่ใช้ในการติดตามข้อกำหนดระหว่างวงจรชีวิตการพัฒนาซอฟต์แวร์ สามารถใช้สำหรับการติดตามไปข้างหน้า (เช่นจากข้อกำหนดสู่การออกแบบหรือการเข้ารหัส) หรือย้อนกลับ (เช่นจากการเข้ารหัสเป็นข้อกำหนด) มีเทมเพลตที่ผู้ใช้กำหนดเองมากมายสำหรับ RTM
ข้อกำหนดแต่ละข้อในเอกสาร RTM เชื่อมโยงกับกรณีทดสอบที่เกี่ยวข้องเพื่อให้การทดสอบสามารถทำได้ตามข้อกำหนดที่กล่าวถึง นอกจากนี้ยังรวม Bug ID และเชื่อมโยงกับข้อกำหนดที่เกี่ยวข้องและกรณีทดสอบ เป้าหมายหลักสำหรับเมทริกซ์นี้คือ -
- ตรวจสอบให้แน่ใจว่าซอฟต์แวร์ได้รับการพัฒนาตามข้อกำหนดที่กล่าวถึง
- ช่วยในการค้นหาสาเหตุของจุดบกพร่องใด ๆ
- ช่วยในการติดตามเอกสารที่พัฒนาในช่วงต่างๆของ SDLC