การวิเคราะห์การทดสอบและหลักการพื้นฐานในการทดสอบ
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การวิเคราะห์การทดสอบ หรือที่เรียกว่า พื้นฐานการทดสอบ คือการตรวจสอบอย่างเป็นระบบของข้อกำหนด เอกสารการออกแบบ และสิ่งประดิษฐ์อื่นๆ ที่ใช้ในการกำหนดเงื่อนไขที่สามารถทดสอบได้ บทความนี้จะอธิบายถึงแหล่งที่มา ขั้นตอนการทำงานทีละขั้นตอน และตำแหน่งของการวิเคราะห์การทดสอบในแบบจำลอง V-Model
การวิเคราะห์การทดสอบ หรือที่เรียกว่า พื้นฐานการทดสอบ อยู่ตรงจุดเริ่มต้นของวงจรชีวิตการทดสอบ เงื่อนไขการทดสอบและกรณีทดสอบทุกอย่างล้วนต้องอาศัยการวิเคราะห์การทดสอบเป็นสำคัญ tracกลับมาที่เรื่องนี้กันอีกครั้ง หัวข้อด้านล่างนี้จะนิยามคำศัพท์ อธิบายแหล่งที่มา อธิบายขั้นตอนการวิเคราะห์ และวางคำศัพท์นั้นไว้ในแบบจำลอง V-Model
การวิเคราะห์ผลการทดสอบคืออะไร?
การวิเคราะห์การทดสอบ ในการทดสอบซอฟต์แวร์นั้น กระบวนการทดสอบคือการตรวจสอบข้อมูลนำเข้าที่ใช้ในการกำหนดเงื่อนไขการทดสอบและกรณีทดสอบ ข้อมูลนำเข้าเหล่านี้ ได้แก่ ข้อกำหนด เงื่อนไขการใช้งาน เอกสารการออกแบบ เรื่องราวของผู้ใช้ และเอกสารส่งมอบอื่นๆ ที่คล้ายคลึงกัน ซึ่งโดยรวมเรียกว่า ข้อมูลนำเข้า สิ่งประดิษฐ์ทดสอบเป้าหมายของการวิเคราะห์การทดสอบคือการแสดงให้เห็นว่า...tracวัตถุประสงค์ของการทดสอบ t นั้นชัดเจนเพียงพอที่จะสามารถแปลงแต่ละข้อให้เป็นเงื่อนไขการทดสอบที่ไม่คลุมเครือได้ เนื่องจากวัสดุที่วิเคราะห์เป็นพื้นฐานที่ใช้ในการสร้างการทดสอบทั้งหมด จึงเรียกอีกอย่างว่า พื้นฐานการทดสอบ.
แหล่งข้อมูลทั่วไปที่ผู้ทดสอบใช้ในการรวบรวมข้อมูลสำหรับการทดสอบ ได้แก่:
- SRS — ข้อกำหนดซอฟต์แวร์
- BRS — ข้อกำหนดความต้องการทางธุรกิจ
- เอกสารการออกแบบฟังก์ชั่น
- เรื่องราวของผู้ใช้ เกณฑ์การยอมรับ และโครงร่างเว็บไซต์
ผู้ทดสอบยังสามารถสร้างเงื่อนไขการทดสอบได้โดยการสำรวจแอปพลิเคชันที่กำลังทดสอบโดยตรง หรือโดยอาศัยประสบการณ์ในอดีต แต่ส่วนใหญ่แล้ว กรณีทดสอบ ได้มาจากสิ่งประดิษฐ์จากการทดสอบเพื่อรักษาไว้ tracความสามารถ
👉 ลงทะเบียนเข้าร่วมโครงการทดสอบซอฟต์แวร์สดฟรี
เหตุใด Test Basis จึงมีความสำคัญ?
เกณฑ์การทดสอบเป็นปัจจัยสำคัญที่สุดที่กำหนดว่าชุดทดสอบจะตรวจจับข้อบกพร่องที่แท้จริงได้หรือไม่ หรือจะไล่ตามข้อบกพร่องที่ไม่มีอยู่จริง การมองข้ามเกณฑ์การทดสอบเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ข้อบกพร่องหลุดรอดไปถึงขั้นตอนการผลิต การวิเคราะห์การทดสอบที่ดีจะให้ประโยชน์ที่เป็นรูปธรรมสี่ประการ:
- Tracความสามารถ: กรณีทดสอบแต่ละกรณีสามารถเชื่อมโยงกลับไปยังข้อกำหนดเฉพาะได้ ซึ่งทำให้การวิเคราะห์ผลกระทบจากการเปลี่ยนแปลงทำได้อย่างรวดเร็ว และการตรวจสอบบัญชีเป็นไปอย่างราบรื่น
- ความชัดเจนของความคุ้มครอง: Revตรวจสอบช่องโหว่ของพื้นผิวพื้นฐาน — สถานะข้อผิดพลาดที่ไม่ระบุ, กรณีขอบเขตที่ขาดหายไป, เกณฑ์ที่ไม่ทำงานที่ไม่ได้กำหนดไว้ — ก่อนที่สิ่งเหล่านี้จะกลายเป็นปัญหาในการผลิต
- การจัดแนวผู้มีส่วนได้ส่วนเสีย: เมื่อทีมทดสอบกำหนดเงื่อนไขจากเอกสารเดียวกันกับที่ทีมพัฒนาใช้เป็นพื้นฐาน ทั้งสองฝ่ายจะมีนิยามของคำว่า “เสร็จสมบูรณ์” ที่ตรงกัน
- การตรวจจับข้อบกพร่องตั้งแต่เนิ่นๆ: ข้อบกพร่องด้านข้อกำหนดหลายอย่าง (ความคลุมเครือ ความขัดแย้ง เกณฑ์การยอมรับที่ขาดหายไป) มักถูกตรวจพบในระหว่างการวิเคราะห์การทดสอบ ซึ่งเกิดขึ้นก่อนที่จะมีการเขียนโค้ดใดๆ ซึ่งนับว่าเป็นวิธีที่ประหยัดที่สุดในการแก้ไขปัญหา
แหล่งที่มาทั่วไปของพื้นฐานการทดสอบ
เอกสารแต่ละประเภทใช้สำหรับการทดสอบในระดับที่แตกต่างกัน ใช้ตารางด้านล่างเป็นข้อมูลอ้างอิงอย่างรวดเร็วเมื่อตัดสินใจว่าจะดูเอกสารใดขณะเขียนกรณีทดสอบ
| สิ่งประดิษฐ์ต้นฉบับ | เหมาะที่สุดสำหรับ | สิ่งที่คุณเคยtract |
|---|---|---|
| ข้อกำหนดความต้องการทางธุรกิจ (BRS) | การทดสอบการยอมรับและการทดสอบระบบ | กฎเกณฑ์ทางธุรกิจแบบครบวงจร ข้อจำกัดด้านกฎระเบียบ เกณฑ์ความสำเร็จ |
| ข้อกำหนดข้อกำหนดซอฟต์แวร์ (SRS) | การทดสอบระบบ | ข้อกำหนดด้านการทำงานและด้านที่ไม่ใช่การทำงาน โดยมีเกณฑ์ที่สามารถวัดได้ |
| เอกสารการออกแบบเชิงฟังก์ชัน/ทางเทคนิค | การทดสอบบูรณาการ | อินเทอร์เฟซโมดูล การไหลของข้อมูล ข้อกำหนดการจัดการข้อผิดพลาด |
| เรื่องราวของผู้ใช้และเกณฑ์การยอมรับ | การทดสอบสปรินต์แบบ Agile | ความคาดหวังเชิงพฤติกรรมในรูปแบบ “กำหนดให้–เมื่อไร–แล้ว” |
| แบบร่างโครงร่างและแบบจำลอง UI | การทดสอบ UI / การใช้งาน | เค้าโครง, การนำทาง, กฎการตรวจสอบความถูกต้องของข้อมูลป้อนเข้า |
| แอปพลิเคชันอยู่ระหว่างการทดสอบ (เชิงสำรวจ) | การทดสอบเชิงสำรวจและการวิเคราะห์การถดถอย | พฤติกรรมที่ไม่ได้รับการบันทึกไว้ กระบวนการทำงานจริง กรณีพิเศษ |
ขั้นตอนการวิเคราะห์ผลการทดสอบทีละขั้นตอน
การวิเคราะห์ผลการทดสอบที่มีประสิทธิภาพนั้นต้องอาศัยขั้นตอนการทำงานห้าขั้นตอนที่ทำซ้ำได้ ไม่ว่าขนาดของโครงการหรือวิธีการจะเป็นอย่างไรก็ตาม
- รวบรวมและตรวจสอบรายการวัสดุสำหรับการทดสอบ รวบรวมเอกสารทั้งหมดที่อธิบายถึงพฤติกรรมที่ต้องการ เช่น SRS, BRS, เอกสารการออกแบบ, เรื่องราวของผู้ใช้, แบบจำลอง และจดบันทึกว่าเอกสารใดเป็นเจ้าของข้อกำหนดแต่ละข้อ tracความสามารถยังคงไม่เปลี่ยนแปลง
- Revมองในแง่ของความสามารถในการทดสอบ อ่านเอกสารแต่ละฉบับโดยคำนึงถึงคำถามสามข้อต่อไปนี้: ข้อความนี้วัดผลได้หรือไม่? มีความชัดเจนหรือไม่? และครบถ้วนหรือไม่? หากข้อกำหนดใดไม่ผ่านการตรวจสอบข้อใดข้อหนึ่ง ให้ทำเครื่องหมายไว้และแจ้งให้ผู้เขียนทราบก่อนที่จะเขียนการทดสอบ
- ระบุเงื่อนไขการทดสอบ สำหรับทุกข้อความที่สามารถทดสอบได้ ให้ระบุเงื่อนไขที่ต้องตรวจสอบ (เส้นทางบวก เส้นทางลบ ค่าขอบเขต การจัดการข้อผิดพลาด ความปลอดภัย ประสิทธิภาพ) เงื่อนไขการทดสอบคือค่าสัมบูรณ์tract “อะไร” — ตัวอย่างเช่น “ระบบปฏิเสธคำสั่งซื้อที่มีจำนวนสินค้าเป็นศูนย์” — ซึ่งแตกต่างจาก "วิธีการ" ที่เป็นรูปธรรมของกรณีทดสอบ
- จัดลำดับความสำคัญและจัดกลุ่มเงื่อนไขต่างๆ จำแนกเงื่อนไขแต่ละข้อตามความเสี่ยงและความถี่ในการใช้งาน เงื่อนไขที่มีความเสี่ยงสูงและความถี่ในการใช้งานสูงจะได้รับการดูแลอย่างละเอียด ในขณะที่เงื่อนไขที่มีความเสี่ยงต่ำสามารถนำมารวมกันหรือสุ่มตัวอย่างได้ นอกจากนี้ ในส่วนนี้คุณจะต้องตัดสินใจว่าเงื่อนไขใดบ้างที่เหมาะสมสำหรับการใช้ระบบอัตโนมัติ
- แปลงเงื่อนไขให้เป็นกรณีทดสอบ เงื่อนไขที่มีลำดับความสำคัญแต่ละข้อจะกลายเป็นหนึ่งหรือมากกว่านั้น กรณีทดสอบ โดยมีเงื่อนไขเบื้องต้น ขั้นตอน ข้อมูลทดสอบ และผลลัพธ์ที่คาดหวัง รักษาข้อกำหนดต่างๆ ไว้ tracเมทริกซ์ความน่าจะเป็นที่เชื่อมโยงกรณีทดสอบแต่ละกรณีเข้ากับข้อกำหนดดั้งเดิม
การทำตามลำดับขั้นตอนนี้จะช่วยหลีกเลี่ยงข้อผิดพลาดที่พบบ่อยที่สุดในการวิเคราะห์การทดสอบ ได้แก่ การเขียนกรณีทดสอบโดยไม่มีพื้นฐานที่ชัดเจน การมองข้ามสถานการณ์เชิงลบ และการสร้างการทดสอบที่ไม่สามารถเชื่อมโยงกลับไปยังข้อกำหนดในระหว่างการคัดแยกข้อบกพร่องได้
การวิเคราะห์การทดสอบในแบบจำลอง V
โมเดล V จับคู่กิจกรรมการพัฒนาทุกอย่างกับกิจกรรมการทดสอบที่สอดคล้องกัน การวิเคราะห์ผลการทดสอบจะเกิดขึ้นในแต่ละระดับ โดยใช้เอกสารใดก็ตามที่มีอยู่ในช่วงเวลานั้นของวงจรชีวิตผลิตภัณฑ์
รูปที่ 1: การวิเคราะห์การทดสอบในแต่ละขั้นตอน V-รุ่น.
กรณีศึกษา: การสร้างกรณีทดสอบจากข้อกำหนดของลูกค้า
ลองพิจารณาสถานการณ์ที่ลูกค้าส่งข้อกำหนดเพียงบรรทัดเดียวดังต่อไปนี้
Client requirement: Add search functionality to an eCommerce Store
แม้ว่าแอปพลิเคชันจะยังไม่ได้ถูกสร้างขึ้น แต่ผู้ทดสอบก็สามารถกำหนดเงื่อนไขการทดสอบหลายอย่างได้แล้ว โดยการวิเคราะห์สิ่งที่ข้อกำหนดบ่งบอก ทั้งพฤติกรรมที่ราบรื่นและโหมดความล้มเหลวที่ลูกค้าไม่ได้ระบุไว้อย่างชัดเจน ตัวอย่างบางส่วนได้แก่:
- ตรวจสอบผลการค้นหาเมื่อไม่ได้ป้อนคำหลัก
- ตรวจสอบผลการค้นหาอีกครั้งเมื่อไม่พบสินค้าที่ตรงกับคำค้นหาที่ป้อน
- ตรวจสอบผลการค้นหาเมื่อมีสินค้าหลายรายการที่ตรงกับคำหลักนั้น
- ตรวจสอบการทำงานเมื่อใช้ตัวอักษรพิเศษ ช่องว่างนำหน้า/ต่อท้าย และข้อมูลที่ป้อนยาวมาก
- ตรวจสอบการคำนึงถึงตัวพิมพ์ใหญ่-เล็ก และพฤติกรรมการจับคู่บางส่วน
- ตรวจสอบเวลาตอบสนองการค้นหาภายใต้ปริมาณผู้ใช้งานที่คาดการณ์ไว้
ผู้ทดสอบจะรับข้อกำหนดของลูกค้า (พื้นฐานการทดสอบ) วิเคราะห์ และแปลงเป็นเงื่อนไขการทดสอบ รูปแบบนี้จะเกิดขึ้นซ้ำในแต่ละขั้นตอนของโมเดล V — แผนการทดสอบและกรณีทดสอบจะถูกสร้างขึ้นโดยใช้เอกสารใดก็ตามที่มีอยู่ในช่วงเวลานั้นของวงจรชีวิต
วิดีโอ: คำอธิบายการวิเคราะห์ผลการทดสอบ
หากวิดีโอไม่โหลด โปรดดูโดยตรงที่ YouTube.
