ตัวชี้วัดการทดสอบซอฟต์แวร์: คืออะไร ประเภท และตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
ตัวชี้วัดการทดสอบซอฟต์แวร์ คือ การวัดเชิงปริมาณของความคืบหน้า คุณภาพ และประสิทธิภาพของกระบวนการทดสอบ คู่มือนี้ครอบคลุมตัวชี้วัดทั้งสามประเภท ความแตกต่างระหว่างค่าพื้นฐานและค่าที่คำนวณได้ วงจรชีวิตของตัวชี้วัด และคำศัพท์สูตรที่คุณสามารถนำไปใช้ได้โดยตรง
ตัวชี้วัดการทดสอบซอฟต์แวร์คืออะไร?
การวัดการทดสอบซอฟต์แวร์ เป็นมาตรการเชิงปริมาณที่ใช้ในการประเมินความคืบหน้า คุณภาพ ผลผลิต และความสมบูรณ์ของกระบวนการทดสอบซอฟต์แวร์ เป้าหมายของการวัดการทดสอบซอฟต์แวร์คือการปรับปรุงประสิทธิภาพและประสิทธิผลในกระบวนการทดสอบซอฟต์แวร์ และเพื่อช่วยตัดสินใจได้ดีขึ้นสำหรับกระบวนการทดสอบเพิ่มเติมโดยการให้ข้อมูลที่เชื่อถือได้เกี่ยวกับกระบวนการทดสอบ
ตัวชี้วัดแสดงถึงระดับที่ระบบ ส่วนประกอบ หรือกระบวนการมีคุณลักษณะที่กำหนดไว้ในเชิงปริมาณ ตัวอย่างง่ายๆ คือ อัตราการสิ้นเปลืองน้ำมันเชื้อเพลิงจริงของรถยนต์ต่อสัปดาห์เมื่อเทียบกับตัวเลขที่ผู้ผลิตระบุไว้
ตัวชี้วัดการทดสอบซอฟต์แวร์ – ปรับปรุงประสิทธิภาพและประสิทธิผลของกระบวนการทดสอบซอฟต์แวร์
การวัดการทดสอบซอฟต์แวร์หรือการวัดการทดสอบซอฟต์แวร์เป็นการบ่งชี้เชิงปริมาณของขอบเขต กำลังการผลิต มิติ จำนวน หรือขนาดของคุณลักษณะบางอย่างของกระบวนการหรือผลิตภัณฑ์
ตัวอย่างการวัดการทดสอบซอฟต์แวร์: จำนวนข้อบกพร่องทั้งหมด
เหตุใดตัวชี้วัดการทดสอบจึงมีความสำคัญ?
“เราไม่สามารถปรับปรุงสิ่งที่เราวัดไม่ได้” ตัวชี้วัดการทดสอบมีไว้เพื่อให้กระบวนการทดสอบสามารถวัดผลได้
- ตัดสินใจว่าขั้นตอนต่อไปควรเป็นอย่างไร
- แสดงหลักฐานสนับสนุนข้อกล่าวอ้างหรือการคาดการณ์เกี่ยวกับคุณภาพ
- ระบุว่าจำเป็นต้องมีการปรับปรุงในด้านใด
- ชี้แจงเหตุผลในการเปลี่ยนแปลงกระบวนการหรือเทคโนโลยี
อ่านเพิ่มเติมเกี่ยวกับมัน ความสำคัญของการวัดการทดสอบ
ประเภทของการวัดการทดสอบ
- ตัวชี้วัดกระบวนการ: สามารถใช้เพื่อปรับปรุงประสิทธิภาพกระบวนการของ SDLC (วงจรชีวิตของการพัฒนาซอฟต์แวร์)
- ตัวชี้วัดผลิตภัณฑ์: มันเกี่ยวข้องกับคุณภาพของผลิตภัณฑ์ซอฟต์แวร์
-
ตัวชี้วัดโครงการ: สามารถใช้วัดประสิทธิภาพของทีมงานโครงการหรืออื่นๆ เครื่องมือทดสอบ ถูกใช้โดยสมาชิกในทีม
การเลือกตัวชี้วัดที่เหมาะสมมีความสำคัญมากกว่าการรวบรวมตัวชี้วัดจำนวนมาก พิจารณาสิ่งต่อไปนี้ก่อนที่จะตัดสินใจเลือกชุดตัวชี้วัด:
- กำหนดกลุ่มเป้าหมายเพื่อเตรียมเมตริก
- กำหนดเป้าหมายสำหรับเมตริก
- แนะนำตัวชี้วัดที่เกี่ยวข้องทั้งหมดตามความต้องการของโครงการ
- พิจารณาต้นทุนและผลประโยชน์ของแต่ละตัวชี้วัด รวมถึงระยะของวงจรชีวิตโครงการที่ให้ผลลัพธ์ที่ดีที่สุด
การวัดการทดสอบด้วยตนเอง
In วิศวกรรมซอฟต์แวร์, การวัดการทดสอบด้วยตนเองแบ่งออกเป็นสองประเภท
- เมตริกพื้นฐาน
- ตัวชี้วัดจากการคำนวณ
หน่วยวัดพื้นฐานคือข้อมูลดิบที่รวบรวมโดยนักวิเคราะห์การทดสอบระหว่างการพัฒนาและดำเนินการกรณีทดสอบ (# กรณีทดสอบที่ดำเนินการ # กรณีทดสอบ- ในขณะที่เมตริกที่คำนวณได้มาจากข้อมูลที่รวบรวมในเมตริกพื้นฐาน โดยปกติแล้วผู้จัดการการทดสอบจะติดตามเมตริกที่คำนวณเพื่อวัตถุประสงค์ในการรายงานการทดสอบ (% เสร็จสมบูรณ์ % ความครอบคลุมของการทดสอบ).
โดยทั่วไปแล้ว ตัวชี้วัดที่สำคัญที่สุดจะขึ้นอยู่กับโครงการหรือรูปแบบธุรกิจ ดังนี้:
- เมตริกประสิทธิภาพการดำเนินการของกรณีทดสอบ
- ตัวชี้วัดประสิทธิภาพในการเตรียมกรณีทดสอบ
- ตัวชี้วัดข้อบกพร่อง
- ข้อบกพร่องตามลำดับความสำคัญ
- ข้อบกพร่องตามความรุนแรง
- อัตราส่วนการเลื่อนหลุดของข้อบกพร่อง
ตัวชี้วัดการทดสอบแบบแมนนวลเทียบกับแบบอัตโนมัติ
ตัวชี้วัดที่กล่าวมาข้างต้นนั้นตั้งอยู่บนสมมติฐานของการดำเนินการชุดทดสอบด้วยตนเอง แต่หากเป็นชุดทดสอบอัตโนมัติ วิธีการวัดจะแตกต่างออกไป เนื่องจากความพยายามในการดำเนินการไม่ใช่ข้อจำกัดอีกต่อไป
| หลักเกณฑ์ | ตัวชี้วัดการทดสอบด้วยตนเอง | ตัวชี้วัดการทดสอบอัตโนมัติ |
|---|---|---|
| โฟกัสหลัก | ความพยายามและความคืบหน้าในการดำเนินการ | ความครอบคลุม ความเสถียร และระยะเวลาการใช้งาน |
| การวัดทั่วไป | จำนวนเคสทดสอบที่ดำเนินการต่อวัน | เปอร์เซ็นต์ความครอบคลุมของระบบอัตโนมัติ |
| สัญญาณคุณภาพ | จำนวนข้อบกพร่องที่พบต่อชั่วโมงการทดสอบ | อัตราการทดสอบที่ไม่เสถียร สัดส่วนของการทดสอบที่ไม่เสถียร |
| การวัดต้นทุน | ชั่วโมงการทดสอบ | จำนวนชั่วโมงในการบำรุงรักษาสคริปต์ต่อการเผยแพร่แต่ละครั้ง |
| การวัดความเร็ว | ระยะเวลาของรอบ (วัน) | ระยะเวลาดำเนินการของชุดทดสอบ (นาที) |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
อัตราการทดสอบที่ไม่แน่นอนสมควรได้รับความสนใจเป็นพิเศษ เมื่ออัตรานี้เกินประมาณ 5 เปอร์เซ็นต์ ทีมงานจะเริ่มเพิกเฉยต่อเวอร์ชันทดสอบที่มีปัญหา และในจุดนั้น ชุดทดสอบจะหยุดให้ข้อมูลไม่ว่าอัตราการครอบคลุมจะสูงแค่ไหนก็ตาม
ทดสอบวงจรชีวิตของตัวชี้วัดในวิศวกรรมซอฟต์แวร์
| ระยะต่างๆ ของวงจรชีวิตของเมตริก | ขั้นตอนในแต่ละขั้นตอน |
|---|---|
| การวิเคราะห์ |
|
| สื่อสาร |
|
| การประเมินผล |
|
| การรับรอง |
|
วิธีการคำนวณตัวชี้วัดการทดสอบ
| ซีเนียร์# | ขั้นตอนในการทดสอบเมตริก | ตัวอย่าง |
|---|---|---|
| 1 | ระบุกุญแจ การทดสอบซอฟต์แวร์ กระบวนการที่จะวัด | ความคืบหน้าการทดสอบ tracกระบวนการของกษัตริย์ |
| 2 | ในขั้นตอนนี้ ผู้ทดสอบจะใช้ข้อมูลเป็นข้อมูลพื้นฐานในการกำหนดเมตริก | จำนวนกรณีทดสอบที่วางแผนจะดำเนินการต่อวัน |
| 3 | การกำหนดข้อมูลที่จะต้องปฏิบัติตาม ความถี่ของ tracกษัตริย์และผู้รับผิดชอบ | การดำเนินการทดสอบจริงต่อวันจะถูกบันทึกโดยผู้จัดการการทดสอบเมื่อสิ้นสุดวัน |
| 4 | การคำนวณ การจัดการ และการตีความตัวชี้วัดที่กำหนดไว้อย่างมีประสิทธิผล | กรณีทดสอบจริงที่ดำเนินการต่อวัน |
| 5 | ระบุพื้นที่ที่ต้องปรับปรุงโดยขึ้นอยู่กับการตีความตัวชี้วัดที่กำหนดไว้ | If กรณีทดสอบ หากผลการดำเนินงานต่ำกว่าเป้าหมายที่ตกลงไว้ ให้ตรวจสอบสาเหตุและเสนอมาตรการแก้ไข |
ตัวอย่างการคำนวณตัวชี้วัดการทดสอบ
ยกตัวอย่างเปอร์เซ็นต์ของกรณีทดสอบที่ดำเนินการแล้ว ในการแสดงสถานะการดำเนินการเป็นเปอร์เซ็นต์ ให้ใช้สูตร:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
ถ้าเขียนกรณีทดสอบ 250 กรณี และดำเนินการทดสอบไปแล้ว 175 กรณี ผลลัพธ์คือ (175 / 250) x 100 = ร้อยละ 70.
รูปแบบเดียวกันนี้ใช้ได้กับพารามิเตอร์การดำเนินการอื่นๆ ทั้งหมด ได้แก่ กรณีทดสอบที่ไม่ได้ดำเนินการ ผ่าน ล้มเหลว และถูกบล็อก แต่ละอย่างเป็นเพียงตัวเศษที่แตกต่างกันบนตัวส่วนเดียวกัน
ตัวชี้วัดการทดสอบที่สำคัญที่สุด Track
คำศัพท์ท้ายบทช่วยสอนนี้แสดงรายการสูตรที่ใช้กันทั่วไปทั้งหมด ในทางปฏิบัติ ชุดรายงานมักไม่ต้องการสูตรมากกว่าแปดสูตร สูตรเหล่านี้เป็นสูตรที่ช่วยในการตัดสินใจได้อย่างสม่ำเสมอ
| เมตริก | มันตอบคำถามอะไร | ระวัง |
|---|---|---|
| เปอร์เซ็นต์การดำเนินการกรณีทดสอบ | เราดำเนินการตามแผนการวิ่งมาถึงจุดไหนแล้ว? | ไม่ได้บอกอะไรเกี่ยวกับคุณภาพเลย บอกแค่เพียงความก้าวหน้าเท่านั้น |
| ความหนาแน่นของข้อบกพร่อง | จำนวนข้อบกพร่องต่อหน่วยขนาด ดังนั้นโมดูลใดจึงอ่อนแอที่สุด? | ขึ้นอยู่กับการวัดขนาดที่สม่ำเสมอ |
| ประสิทธิภาพการกำจัดข้อบกพร่อง | เราตรวจพบข้อบกพร่องก่อนวางจำหน่ายได้กี่เปอร์เซ็นต์? | จะสามารถสรุปผลได้ก็ต่อเมื่อได้รับข้อมูลการผลิตแล้วเท่านั้น |
| การรั่วไหลของข้อบกพร่อง | มีสินค้าชำรุดกี่ชิ้นที่ส่งถึงมือลูกค้า? | สัญญาณคุณภาพที่สำคัญที่สุดเพียงอย่างเดียว |
| ความคุ้มครองการทดสอบ | มีการปฏิบัติตามข้อกำหนดที่กำหนดไว้มากน้อยเพียงใด? | การครอบคลุมข้อมูลสูงแต่มีหลักฐานอ่อนแอพิสูจน์อะไรไม่ได้เลย |
| ดัชนีความรุนแรงของข้อบกพร่อง | แผลเปิดเหล่านั้นร้ายแรงหรือเป็นเพียงรอยตำหนิภายนอก? | การนับข้อบกพร่องโดยไม่ถ่วงน้ำหนักจะทำให้เข้าใจผิด |
| เวลาเฉลี่ยในการซ่อมแซม | ทีมสามารถแก้ไขปัญหาได้เร็วแค่ไหน? | บิดเบือนไปเนื่องจากข้อบกพร่องที่เกิดขึ้นมานานบางประการ |
| ประสิทธิภาพในการดำเนินการทดสอบ | ผู้ทดสอบทำการทดสอบได้กี่เคสต่อวัน? | ส่งเสริมการทดสอบแบบตื้นหากใช้เป็นเป้าหมาย |
มีสองสูตรที่ควรเพิ่มลงในคำศัพท์เฉพาะ เพราะเป็นสูตรที่ฝ่ายบริหารต้องการ:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
กับดักการวัด ตัวชี้วัดใดๆ ที่ใช้เป็นเป้าหมายจะไม่ใช่มาตรวัดที่ดีอีกต่อไป หากตั้งเป้าหมายด้านประสิทธิภาพการทำงานไว้ที่ 30 กรณีทดสอบต่อวัน ผู้ทดสอบก็จะเขียนกรณีทดสอบที่ง่ายๆ 30 กรณี ควรรายงานตัวชี้วัดเป็นชุด ไม่ใช่รายงานแยกส่วน และควรจับคู่ตัวเลขประสิทธิภาพการทำงานกับตัวเลขคุณภาพด้วย
คำศัพท์สูตรการวัดผลการทดสอบซอฟต์แวร์
- อัตราส่วนความพยายามในการทำใหม่ = (ความพยายามในการทำใหม่จริงที่ใช้ไปในระยะนั้น/ความพยายามจริงทั้งหมดที่ใช้ไปในระยะนั้น) X 100
- ความต้องการคืบ = (จำนวนข้อกำหนดที่เพิ่มทั้งหมด/จำนวนข้อกำหนดเริ่มต้น)X100
- ความแปรปรวนของกำหนดการ = (วันที่จัดส่งจริง – วันที่วางแผนจัดส่ง)
- ค่าใช้จ่ายในการค้นหาข้อบกพร่องในการทดสอบ = (ความพยายามทั้งหมดที่ใช้ในการทดสอบ/ข้อบกพร่องที่พบในการทดสอบ)
- กำหนดการเลื่อนหลุด = (วันที่สิ้นสุดตามจริง – วันที่สิ้นสุดโดยประมาณ) / (วันที่สิ้นสุดตามแผน – วันที่เริ่มต้นตามแผน) X 100
- ผ่านการทดสอบกรณีทดสอบร้อยละ = (จำนวนการทดสอบที่ผ่านการทดสอบ/จำนวนการทดสอบทั้งหมดที่ดำเนินการ) X 100
- เปอร์เซ็นต์กรณีทดสอบที่ล้มเหลว = (จำนวนการทดสอบที่ล้มเหลว/จำนวนการทดสอบทั้งหมดที่ดำเนินการ) X 100
- เปอร์เซ็นต์กรณีทดสอบที่ถูกบล็อก = (จำนวนการทดสอบที่ถูกบล็อก/จำนวนการทดสอบทั้งหมดที่ดำเนินการ) X 100
- เปอร์เซ็นต์ข้อบกพร่องคงที่ = (ข้อบกพร่องแก้ไข/ข้อบกพร่องที่รายงาน) X 100
- เปอร์เซ็นต์ข้อบกพร่องที่ยอมรับ = (ข้อบกพร่องที่ทีม Dev ยอมรับว่าถูกต้อง/ข้อบกพร่องทั้งหมดที่รายงาน) X 100
- ข้อบกพร่องรอการตัดบัญชีเปอร์เซ็นต์ = (ข้อบกพร่องที่เลื่อนออกไปสำหรับการเปิดตัวในอนาคต/ข้อบกพร่องทั้งหมดที่รายงาน) X 100
- เปอร์เซ็นต์ข้อบกพร่องที่สำคัญ = (ข้อบกพร่องร้ายแรง / ข้อบกพร่องรวมที่รายงาน) X 100
- เวลาเฉลี่ยสำหรับทีมพัฒนาในการซ่อมแซมข้อบกพร่อง = (เวลาทั้งหมดที่ใช้ในการแก้ไขข้อบกพร่อง/จำนวนข้อบกพร่อง)
- จำนวนการทดสอบที่ทำต่อช่วงเวลา = จำนวนการทดสอบที่ทำ/เวลาทั้งหมด
- ทดสอบประสิทธิภาพการออกแบบ = จำนวนการทดสอบที่ออกแบบ /เวลาทั้งหมด
- ทดสอบประสิทธิภาพการทบทวน = จำนวนการทดสอบที่ทบทวน /เวลาทั้งหมด
- อัตราการค้นพบข้อผิดพลาดหรือ จำนวนข้อบกพร่องต่อชั่วโมงการทดสอบ = จำนวนข้อบกพร่องทั้งหมด / จำนวนชั่วโมงการทดสอบทั้งหมด
