7 หลักการทดสอบซอฟต์แวร์พร้อมตัวอย่าง

บทช่วยสอนนี้จะแนะนำหลักการทดสอบซอฟต์แวร์พื้นฐานเจ็ดประการที่ผู้ทดสอบซอฟต์แวร์และผู้เชี่ยวชาญด้าน QA ทุกคนควรรู้

มาเรียนรู้หลักการทดสอบด้วยสิ่งต่อไปนี้ ตัวอย่างวิดีโอ-

คลิก Good Farm Animal Welfare Awards หากไม่สามารถเข้าถึงวิดีโอได้

พื้นหลัง

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

เพื่อให้เข้าใจถึงสิ่งนี้ ให้พิจารณาสถานการณ์สมมติที่คุณกำลังย้ายไฟล์จากโฟลเดอร์ A ไปยังโฟลเดอร์ B

ลองคิดถึงวิธีที่เป็นไปได้ทั้งหมดที่คุณสามารถทดสอบสิ่งนี้ได้

นอกเหนือจากสถานการณ์ปกติแล้ว คุณยังสามารถทดสอบเงื่อนไขต่อไปนี้ได้อีกด้วย

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

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

นี่คือหลักการ 7 ประการ:

1) ไม่สามารถทำการทดสอบแบบละเอียดถี่ถ้วนได้

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

และคำถามล้านดอลลาร์ก็คือ คุณจะระบุความเสี่ยงนี้ได้อย่างไร

เพื่อตอบคำถามนี้ เรามาทำแบบฝึกหัดกัน

ในความคิดของคุณ การดำเนินการแบบใดมีแนวโน้มที่จะทำให้คุณ Operaระบบ ting ล้มเหลว?

ฉันแน่ใจว่าพวกคุณส่วนใหญ่คงเดาได้ กำลังเปิดแอปพลิเคชั่นที่แตกต่างกัน 10 รายการพร้อมกัน

ดังนั้นหากคุณกำลังทดสอบสิ่งนี้ Operaระบบ ting คุณจะรู้ว่าข้อบกพร่องนั้นมีแนวโน้มที่จะพบได้ในกิจกรรมแบบมัลติทาสก์ และจำเป็นต้องได้รับการทดสอบอย่างละเอียด ซึ่งนำเราไปสู่หลักการต่อไปของเรา ข้อบกพร่อง Clusterไอเอ็นจี

2) ข้อบกพร่อง Clusterไอเอ็นจี

ข้อบกพร่อง Clusterซึ่งระบุว่ามีโมดูลจำนวนเล็กน้อยที่มีข้อบกพร่องส่วนใหญ่ที่ตรวจพบ นี่คือการประยุกต์ใช้หลักการพาเรโตในการทดสอบซอฟต์แวร์: ประมาณ 80% ของปัญหาพบใน 20% ของโมดูล

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

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

3) Paradox สารกำจัดศัตรูพืช

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

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

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

คุณคิดว่าบริษัทอย่าง MICROSOFT จะไม่ทดสอบระบบปฏิบัติการของตนเองอย่างละเอียดถี่ถ้วน และยอมเสี่ยงต่อชื่อเสียงเพียงเพื่อพบว่าระบบปฏิบัติการของตนเองขัดข้องเมื่อเปิดตัวสู่สาธารณะ!

4) การทดสอบแสดงการมีอยู่ของข้อบกพร่อง

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

แต่จะเป็นอย่างไรหากคุณทำงานหนักเป็นพิเศษ ปฏิบัติตามมาตรการป้องกันทั้งหมด และทำให้ผลิตภัณฑ์ซอฟต์แวร์ของคุณปราศจากข้อผิดพลาด 99% และซอฟต์แวร์ไม่ตรงตามความต้องการและความต้องการของลูกค้า

สิ่งนี้นำเราไปสู่หลักการต่อไปของเรา ซึ่งระบุว่า- การไม่มีข้อผิดพลาด

5) การขาดข้อผิดพลาด – การเข้าใจผิด

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

เพื่อแก้ปัญหานี้ หลักการทดสอบถัดไประบุว่าการทดสอบล่วงหน้า

6) การทดสอบในช่วงต้น

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

7) การทดสอบขึ้นอยู่กับบริบท

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

ตำนาน: “หลักการมีไว้เพื่อการอ้างอิงเท่านั้น ฉันจะไม่ใช้มันในทางปฏิบัติ”

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

แต่หลักการเรียนรู้การทดสอบก็เหมือนกับการเรียนรู้การขับรถเป็นครั้งแรก

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

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