การทดสอบซอฟต์แวร์ - คู่มือฉบับย่อ

การทดสอบคืออะไร?

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

ตามมาตรฐาน ANSI / IEEE 1059 การทดสอบสามารถกำหนดเป็น - กระบวนการวิเคราะห์รายการซอฟต์แวร์เพื่อตรวจจับความแตกต่างระหว่างเงื่อนไขที่มีอยู่และเงื่อนไขที่จำเป็น (นั่นคือข้อบกพร่อง / ข้อผิดพลาด / ข้อบกพร่อง) และเพื่อประเมินคุณสมบัติของรายการซอฟต์แวร์

ใครทดสอบ?

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

• เครื่องทดสอบซอฟต์แวร์
• นักพัฒนาซอฟต์แวร์
• หัวหน้าโครงการ / ผู้จัดการ
• ผู้ใช้

บริษัท ต่างๆมีการกำหนดที่แตกต่างกันสำหรับผู้ที่ทดสอบซอฟต์แวร์โดยอาศัยประสบการณ์และความรู้เช่น Software Tester, Software Quality Assurance Engineer, QA Analyst เป็นต้น

ไม่สามารถทดสอบซอฟต์แวร์ได้ตลอดเวลาในระหว่างรอบการทำงาน สองส่วนถัดไประบุว่าควรเริ่มการทดสอบเมื่อใดและเมื่อใดควรสิ้นสุดในระหว่าง SDLC

จะเริ่มทดสอบเมื่อใด

การเริ่มต้นการทดสอบจะช่วยลดต้นทุนและเวลาในการทำงานซ้ำและผลิตซอฟต์แวร์ที่ปราศจากข้อผิดพลาดซึ่งส่งมอบให้กับลูกค้า อย่างไรก็ตามใน Software Development Life Cycle (SDLC) การทดสอบสามารถเริ่มต้นได้จากขั้นตอนการรวบรวมความต้องการและดำเนินการต่อไปจนถึงการปรับใช้ซอฟต์แวร์

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

การทดสอบจะทำในรูปแบบที่แตกต่างกันในทุกขั้นตอนของ SDLC -

• ในระหว่างขั้นตอนการรวบรวมความต้องการการวิเคราะห์และการตรวจสอบความต้องการถือเป็นการทดสอบด้วย

• การทบทวนการออกแบบในขั้นตอนการออกแบบโดยมีจุดประสงค์เพื่อปรับปรุงการออกแบบถือเป็นการทดสอบเช่นกัน

• การทดสอบที่ดำเนินการโดยนักพัฒนาเมื่อโค้ดเสร็จสมบูรณ์ยังจัดประเภทเป็นการทดสอบ

ควรหยุดทดสอบเมื่อใด

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

• กำหนดเวลาการทดสอบ

• เสร็จสิ้นการดำเนินการกรณีทดสอบ

• ความครอบคลุมของฟังก์ชันและโค้ดจนถึงจุดหนึ่ง

• อัตราบั๊กต่ำกว่าระดับหนึ่งและไม่มีการระบุจุดบกพร่องที่มีลำดับความสำคัญสูง

• การตัดสินใจของผู้บริหาร

การตรวจสอบและการตรวจสอบความถูกต้อง

คำศัพท์ทั้งสองนี้สร้างความสับสนให้กับคนส่วนใหญ่ซึ่งใช้แทนกันได้ ตารางต่อไปนี้เน้นความแตกต่างระหว่างการตรวจสอบและการตรวจสอบความถูกต้อง

ซีเนียร์	การยืนยัน	การตรวจสอบ
1	การยืนยันช่วยแก้ปัญหา: "คุณสร้างถูกต้องหรือไม่"	การตรวจสอบความถูกต้องกล่าวถึงข้อกังวล: "คุณกำลังสร้างสิ่งที่ถูกต้องหรือไม่"
2	ตรวจสอบให้แน่ใจว่าระบบซอฟต์แวร์ตรงตามฟังก์ชันการทำงานทั้งหมด	ตรวจสอบให้แน่ใจว่าฟังก์ชันตรงตามลักษณะการทำงานที่ตั้งใจไว้
3	การยืนยันจะเกิดขึ้นก่อนและรวมถึงการตรวจสอบเอกสารรหัส ฯลฯ	การตรวจสอบจะเกิดขึ้นหลังจากการตรวจสอบและส่วนใหญ่เกี่ยวข้องกับการตรวจสอบผลิตภัณฑ์โดยรวม
4	ทำโดยนักพัฒนา	ทำโดยผู้ทดสอบ
5	มีกิจกรรมคงที่เนื่องจากรวมถึงการรวบรวมบทวิจารณ์บทสรุปและการตรวจสอบเพื่อตรวจสอบซอฟต์แวร์	มีกิจกรรมแบบไดนามิกเนื่องจากรวมถึงการเรียกใช้ซอฟต์แวร์ที่ขัดต่อข้อกำหนด
6	เป็นกระบวนการที่มีวัตถุประสงค์และไม่จำเป็นต้องมีการตัดสินใจแบบอัตนัยเพื่อตรวจสอบซอฟต์แวร์	เป็นกระบวนการที่เป็นอัตวิสัยและเกี่ยวข้องกับการตัดสินใจแบบอัตนัยว่าซอฟต์แวร์ทำงานได้ดีเพียงใด

ด้านล่างนี้เป็นตำนานที่พบบ่อยที่สุดเกี่ยวกับการทดสอบซอฟต์แวร์

ความเชื่อที่ 1: การทดสอบมีราคาแพงเกินไป

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

ความเชื่อที่ 2: การทดสอบใช้เวลานาน

Reality- ในระหว่างขั้นตอน SDLC การทดสอบไม่เคยเป็นกระบวนการที่ใช้เวลานาน อย่างไรก็ตามการวินิจฉัยและแก้ไขข้อผิดพลาดที่ระบุระหว่างการทดสอบที่เหมาะสมเป็นกิจกรรมที่ใช้เวลานาน แต่ได้ผล

ความเชื่อที่ 3: เฉพาะผลิตภัณฑ์ที่พัฒนาเต็มที่เท่านั้นที่ได้รับการทดสอบ

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

ความเชื่อที่ 4: การทดสอบที่สมบูรณ์เป็นไปได้

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

ความเชื่อที่ 5: ซอฟต์แวร์ที่ผ่านการทดสอบแล้วไม่มีข้อผิดพลาด

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

ความเชื่อที่ 6: ข้อบกพร่องที่ไม่ได้รับเกิดจากผู้ทดสอบ

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

ความเชื่อที่ 7: ผู้ทดสอบต้องรับผิดชอบต่อคุณภาพของผลิตภัณฑ์

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

ความเชื่อที่ 8: ควรใช้การทดสอบอัตโนมัติทุกที่ที่ทำได้เพื่อลดเวลา

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

ความเชื่อที่ 9: ทุกคนสามารถทดสอบแอปพลิเคชันซอฟต์แวร์ได้

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

ความเชื่อที่ 10: ภารกิจเดียวของผู้ทดสอบคือการค้นหาจุดบกพร่อง

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

การทดสอบการประกันคุณภาพและการควบคุมคุณภาพ

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

การประกันคุณภาพ	ควบคุมคุณภาพ	การทดสอบ
QA รวมถึงกิจกรรมที่ทำให้มั่นใจว่ามีการดำเนินการตามกระบวนการขั้นตอนและมาตรฐานในบริบทของการตรวจสอบซอฟต์แวร์ที่พัฒนาและข้อกำหนดที่ตั้งใจไว้	รวมถึงกิจกรรมที่รับรองว่ามีการตรวจสอบซอฟต์แวร์ที่พัฒนาขึ้นตามข้อกำหนดที่บันทึกไว้ (หรือไม่ในบางกรณี)	รวมถึงกิจกรรมที่ทำให้มั่นใจได้ว่ามีการระบุจุดบกพร่อง / ข้อผิดพลาด / ข้อบกพร่องในซอฟต์แวร์
มุ่งเน้นไปที่กระบวนการและขั้นตอนมากกว่าการทดสอบจริงในระบบ	มุ่งเน้นไปที่การทดสอบจริงโดยการเรียกใช้ซอฟต์แวร์โดยมีจุดประสงค์เพื่อระบุจุดบกพร่อง / ข้อบกพร่องผ่านการดำเนินการตามขั้นตอนและกระบวนการ	เน้นการทดสอบจริง
กิจกรรมที่เน้นกระบวนการ	กิจกรรมที่มุ่งเน้นผลิตภัณฑ์	กิจกรรมที่มุ่งเน้นผลิตภัณฑ์
กิจกรรมป้องกัน.	มันเป็นกระบวนการแก้ไข	มันเป็นกระบวนการป้องกัน
เป็นชุดย่อยของ Software Test Life Cycle (STLC)	QC ถือได้ว่าเป็นส่วนย่อยของการประกันคุณภาพ	การทดสอบเป็นชุดย่อยของการควบคุมคุณภาพ

การตรวจสอบและการตรวจสอบ

Audit- เป็นกระบวนการที่เป็นระบบในการพิจารณาว่ากระบวนการทดสอบจริงดำเนินการอย่างไรภายในองค์กรหรือทีม โดยทั่วไปจะเป็นการตรวจสอบกระบวนการที่เกี่ยวข้องระหว่างการทดสอบซอฟต์แวร์โดยอิสระ ตาม IEEE เป็นการทบทวนกระบวนการที่เป็นเอกสารซึ่งองค์กรต่างๆนำไปปฏิบัติและปฏิบัติตาม ประเภทของการตรวจสอบ ได้แก่ การตรวจสอบการปฏิบัติตามกฎหมายการตรวจสอบภายในและการตรวจสอบระบบ

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

การประชุมการตรวจสอบอย่างเป็นทางการอาจรวมถึงกระบวนการต่อไปนี้: การวางแผนการเตรียมภาพรวมการประชุมการตรวจสอบการทำใหม่และการติดตามผล

การทดสอบและการดีบัก

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

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

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

ISO / IEC 9126

มาตรฐานนี้เกี่ยวข้องกับประเด็นต่อไปนี้เพื่อกำหนดคุณภาพของแอปพลิเคชันซอฟต์แวร์ -

• รุ่นคุณภาพ
• เมตริกภายนอก
• เมตริกภายใน
• เมตริกคุณภาพในการใช้งาน

มาตรฐานนี้นำเสนอคุณลักษณะคุณภาพบางอย่างสำหรับซอฟต์แวร์ใด ๆ เช่น -

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

คุณลักษณะด้านคุณภาพดังกล่าวข้างต้นยังแบ่งออกเป็นปัจจัยย่อย ๆ อีกซึ่งคุณสามารถศึกษาได้เมื่อคุณศึกษารายละเอียดมาตรฐาน

ISO / IEC 9241-11

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

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

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 เป็นที่รู้จักกันทั่วไปว่าเป็นมาตรฐานที่ให้แนวทางสำหรับข้อกำหนดและการประเมินคุณภาพซอฟต์แวร์ (SQuaRE) มาตรฐานนี้ช่วยในการจัดระเบียบและเสริมสร้างกระบวนการที่เกี่ยวข้องกับข้อกำหนดด้านคุณภาพซอฟต์แวร์และการประเมินผล ในความเป็นจริง ISO-25000 แทนที่มาตรฐาน ISO แบบเก่าสองมาตรฐานนั่นคือ ISO-9126 และ ISO-14598

SQuaRE แบ่งออกเป็นส่วนย่อย ๆ เช่น -

• ISO 2500n - กองบริหารคุณภาพ
• ISO 2501n - แผนกโมเดลคุณภาพ
• ISO 2502n - กองการวัดคุณภาพ
• ISO 2503n - กองข้อกำหนดคุณภาพ
• ISO 2504n - กองประเมินคุณภาพ

เนื้อหาหลักของ SQuaRE ได้แก่ -

• ข้อกำหนดและคำจำกัดความ
• โมเดลอ้างอิง
• คู่มือทั่วไป
• คู่มือการหารส่วนบุคคล
• มาตรฐานที่เกี่ยวข้องกับวิศวกรรมความต้องการ (ได้แก่ ข้อกำหนดการวางแผนกระบวนการวัดและประเมินผล)

ISO / IEC 12119

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

• ชุดข้อกำหนดสำหรับซอฟต์แวร์สำเร็จรูป
• คำแนะนำสำหรับการทดสอบแพคเกจซอฟต์แวร์ที่จัดส่งเทียบกับข้อกำหนดที่ระบุ

เบ็ดเตล็ด

มาตรฐานอื่น ๆ บางส่วนที่เกี่ยวข้องกับกระบวนการ QA และการทดสอบมีการระบุไว้ด้านล่าง -

ซีเนียร์ No	มาตรฐานและคำอธิบาย
1	IEEE 829 มาตรฐานสำหรับรูปแบบของเอกสารที่ใช้ในขั้นตอนต่างๆของการทดสอบซอฟต์แวร์
2	IEEE 1061 วิธีการในการกำหนดข้อกำหนดด้านคุณภาพการระบุการนำไปใช้การวิเคราะห์และการตรวจสอบความถูกต้องของกระบวนการและผลิตภัณฑ์ของเมตริกคุณภาพซอฟต์แวร์
3	IEEE 1059 คำแนะนำสำหรับแผนการตรวจสอบและตรวจสอบซอฟต์แวร์
4	IEEE 1008 มาตรฐานสำหรับการทดสอบหน่วย
5	IEEE 1012 มาตรฐานสำหรับการตรวจสอบและตรวจสอบซอฟต์แวร์
6	IEEE 1028 มาตรฐานสำหรับการตรวจสอบซอฟต์แวร์
7	IEEE 1044 มาตรฐานสำหรับการจำแนกความผิดปกติของซอฟต์แวร์
8	IEEE 1044-1 คำแนะนำสำหรับการจำแนกประเภทของความผิดปกติของซอฟต์แวร์
9	IEEE 830 คู่มือสำหรับการพัฒนาข้อกำหนดข้อกำหนดของระบบ
10	IEEE 730 มาตรฐานสำหรับแผนการประกันคุณภาพซอฟต์แวร์
11	IEEE 1061 มาตรฐานสำหรับเมตริกและระเบียบวิธีคุณภาพซอฟต์แวร์
12	IEEE 12207 มาตรฐานสำหรับกระบวนการวงจรชีวิตซอฟต์แวร์และข้อมูลวงจรชีวิต
13	BS 7925-1 คำศัพท์ที่ใช้ในการทดสอบซอฟต์แวร์
14	BS 7925-2 มาตรฐานสำหรับการทดสอบส่วนประกอบซอฟต์แวร์

ส่วนนี้อธิบายถึงการทดสอบประเภทต่างๆที่อาจใช้ในการทดสอบซอฟต์แวร์ระหว่าง SDLC

การทดสอบด้วยตนเอง

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

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

การทดสอบอัตโนมัติ

การทดสอบระบบอัตโนมัติหรือที่เรียกว่า Test Automation คือเมื่อผู้ทดสอบเขียนสคริปต์และใช้ซอฟต์แวร์อื่นเพื่อทดสอบผลิตภัณฑ์ กระบวนการนี้เกี่ยวข้องกับการดำเนินการด้วยตนเองโดยอัตโนมัติ Automation Testing ใช้เพื่อรันสถานการณ์การทดสอบที่ดำเนินการด้วยตนเองอย่างรวดเร็วและซ้ำ ๆ

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

จะทำอะไรโดยอัตโนมัติ?

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

นอกจากนี้รายการ GUI ทั้งหมดการเชื่อมต่อกับฐานข้อมูลการตรวจสอบความถูกต้องภาคสนามและอื่น ๆ สามารถทดสอบได้อย่างมีประสิทธิภาพโดยการดำเนินการด้วยตนเองโดยอัตโนมัติ

เมื่อใดที่จะทำให้เป็นอัตโนมัติ?

ควรใช้ Test Automation โดยพิจารณาด้านต่อไปนี้ของซอฟต์แวร์ -

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

วิธีการทำงานอัตโนมัติ

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

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

เครื่องมือทดสอบซอฟต์แวร์

เครื่องมือต่อไปนี้สามารถใช้สำหรับการทดสอบอัตโนมัติ -

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• ทดสอบได้ทุกที่
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR

มีวิธีการต่างๆที่สามารถใช้สำหรับการทดสอบซอฟต์แวร์ บทนี้อธิบายสั้น ๆ เกี่ยวกับวิธีการที่มี

การทดสอบกล่องดำ

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

ตารางต่อไปนี้แสดงข้อดีและข้อเสียของการทดสอบกล่องดำ

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

การทดสอบกล่องขาว

การทดสอบกล่องขาวเป็นการตรวจสอบตรรกะภายในและโครงสร้างของโค้ดโดยละเอียด เรียกอีกอย่างว่าการทดสอบกล่องขาวglass testing หรือ open-box testing. เพื่อที่จะดำเนินการwhite-box การทดสอบแอปพลิเคชันผู้ทดสอบจำเป็นต้องทราบการทำงานภายในของรหัส

ผู้ทดสอบจำเป็นต้องดูภายในซอร์สโค้ดและค้นหาว่าหน่วย / ส่วนใดของโค้ดทำงานไม่เหมาะสม

ตารางต่อไปนี้แสดงข้อดีและข้อเสียของการทดสอบกล่องขาว

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

การทดสอบกล่องสีเทา

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

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

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

การเปรียบเทียบวิธีการทดสอบ

ตารางต่อไปนี้แสดงจุดที่แยกความแตกต่างของการทดสอบกล่องดำการทดสอบกล่องสีเทาและการทดสอบกล่องสีขาว

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

มีระดับที่แตกต่างกันในระหว่างขั้นตอนการทดสอบ ในบทนี้มีคำอธิบายสั้น ๆ เกี่ยวกับระดับเหล่านี้

ระดับของการทดสอบรวมถึงวิธีการต่างๆที่สามารถใช้ได้ในขณะที่ทำการทดสอบซอฟต์แวร์ ระดับหลักของการทดสอบซอฟต์แวร์คือ -

• การทดสอบการทำงาน

• การทดสอบแบบไม่ใช้งาน

การทดสอบการทำงาน

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

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

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

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

การทดสอบหน่วย

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

เป้าหมายของการทดสอบหน่วยคือการแยกแต่ละส่วนของโปรแกรมและแสดงให้เห็นว่าแต่ละส่วนถูกต้องในแง่ของข้อกำหนดและฟังก์ชันการทำงาน

ข้อ จำกัด ของการทดสอบหน่วย

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

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

การทดสอบการผสานรวม

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

ซีเนียร์	วิธีการทดสอบการรวม
1	Bottom-up integration การทดสอบนี้เริ่มต้นด้วยการทดสอบหน่วยตามด้วยการทดสอบการรวมหน่วยในระดับที่สูงขึ้นไปเรื่อย ๆ ที่เรียกว่าโมดูลหรือการสร้าง
2	Top-down integration ในการทดสอบนี้โมดูลระดับสูงสุดจะได้รับการทดสอบก่อนและต่อเนื่องโมดูลระดับล่างจะถูกทดสอบหลังจากนั้น

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

การทดสอบระบบ

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

การทดสอบระบบมีความสำคัญเนื่องจากเหตุผลดังต่อไปนี้ -

• การทดสอบระบบเป็นขั้นตอนแรกในวัฏจักรการพัฒนาซอฟต์แวร์ซึ่งจะทดสอบแอปพลิเคชันโดยรวม

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

• แอปพลิเคชันได้รับการทดสอบในสภาพแวดล้อมที่ใกล้เคียงกับสภาพแวดล้อมการใช้งานจริงที่จะนำแอปพลิเคชันไปใช้งาน

• การทดสอบระบบช่วยให้เราสามารถทดสอบตรวจสอบและตรวจสอบความถูกต้องของข้อกำหนดทางธุรกิจตลอดจนสถาปัตยกรรมแอปพลิเคชัน

การทดสอบการถดถอย

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

การทดสอบการถดถอยมีความสำคัญเนื่องจากสาเหตุต่อไปนี้ -

• ลดช่องว่างในการทดสอบเมื่อต้องทดสอบแอปพลิเคชันที่มีการเปลี่ยนแปลง

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

• ลดความเสี่ยงเมื่อทำการทดสอบการถดถอยบนแอปพลิเคชัน

• ความครอบคลุมของการทดสอบจะเพิ่มขึ้นโดยไม่กระทบต่อระยะเวลา

• เพิ่มความเร็วในการทำตลาดผลิตภัณฑ์

การทดสอบการยอมรับ

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

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

ทีมทดสอบจะลดการทำงานของแอปพลิเคชันในการผลิต นอกจากนี้ยังมีข้อกำหนดทางกฎหมายและสัญญาสำหรับการยอมรับระบบ

การทดสอบอัลฟ่า

การทดสอบนี้เป็นขั้นตอนแรกของการทดสอบและจะดำเนินการระหว่างทีม (ผู้พัฒนาและทีม QA) การทดสอบหน่วยการทดสอบการรวมและการทดสอบระบบเมื่อรวมเข้าด้วยกันเรียกว่าการทดสอบอัลฟา ในช่วงนี้จะมีการทดสอบประเด็นต่อไปนี้ในแอปพลิเคชัน -

• สะกดผิดพลาด

• ลิงค์เสีย

• ทิศทางที่มีเมฆมาก

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

การทดสอบเบต้า

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

• ผู้ใช้จะติดตั้งเรียกใช้แอปพลิเคชันและส่งข้อเสนอแนะไปยังทีมโครงการ

• ข้อผิดพลาดในการพิมพ์โฟลว์แอปพลิเคชันที่สับสนและถึงขั้นขัดข้อง

• ทีมงานโครงการสามารถแก้ไขปัญหาได้ก่อนปล่อยซอฟต์แวร์ให้กับผู้ใช้งานจริง

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

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

การทดสอบแบบไม่ใช้งาน

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

ประเภทการทดสอบที่ไม่ใช้งานที่สำคัญและใช้กันทั่วไปบางประเภทจะกล่าวถึงด้านล่าง

การทดสอบประสิทธิภาพ

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

• เครือข่ายล่าช้า

• การประมวลผลฝั่งไคลเอ็นต์

• การประมวลผลธุรกรรมฐานข้อมูล

• โหลดบาลานซ์ระหว่างเซิร์ฟเวอร์

• การแสดงผลข้อมูล

การทดสอบประสิทธิภาพถือเป็นหนึ่งในประเภทการทดสอบที่สำคัญและจำเป็นในแง่ต่อไปนี้ -

• ความเร็ว (เช่นเวลาตอบสนองการแสดงข้อมูลและการเข้าถึง)

• Capacity

• Stability

• Scalability

การทดสอบประสิทธิภาพสามารถเป็นได้ทั้งเชิงคุณภาพหรือเชิงปริมาณและสามารถแบ่งออกเป็นประเภทย่อยต่างๆเช่น Load testing และ Stress testing.

โหลดการทดสอบ

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

โดยส่วนใหญ่แล้วการทดสอบโหลดจะดำเนินการโดยใช้เครื่องมืออัตโนมัติเช่น Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test เป็นต้น

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

การทดสอบความเครียด

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

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

• การปิดหรือรีสตาร์ทพอร์ตเครือข่ายแบบสุ่ม

• การเปิดหรือปิดฐานข้อมูล

• การรันกระบวนการต่างๆที่ใช้ทรัพยากรเช่น CPU หน่วยความจำเซิร์ฟเวอร์เป็นต้น

การทดสอบการใช้งาน

การทดสอบการใช้งานเป็นเทคนิคกล่องดำและใช้เพื่อระบุข้อผิดพลาดและการปรับปรุงซอฟต์แวร์โดยการสังเกตผู้ใช้ผ่านการใช้งานและการทำงาน

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

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

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

นอกเหนือจากคำจำกัดความที่แตกต่างกันของการใช้งานแล้วยังมีมาตรฐานและแบบจำลองคุณภาพและวิธีการบางอย่างที่กำหนดความสามารถในการใช้งานในรูปแบบของคุณลักษณะและคุณลักษณะย่อยเช่น ISO-9126, ISO-9241-11, ISO-13407 และมาตรฐาน IEEE 610.12 เป็นต้น

UI เทียบกับการทดสอบการใช้งาน

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

ในทางกลับกันการทดสอบการใช้งานทำให้มั่นใจได้ว่า GUI ที่ดีและใช้งานง่ายซึ่งสามารถจัดการได้อย่างง่ายดาย การทดสอบ UI ถือได้ว่าเป็นส่วนย่อยของการทดสอบการใช้งาน

การทดสอบความปลอดภัย

การทดสอบความปลอดภัยเกี่ยวข้องกับการทดสอบซอฟต์แวร์เพื่อระบุข้อบกพร่องและช่องว่างจากมุมมองด้านความปลอดภัยและช่องโหว่ ด้านล่างนี้เป็นประเด็นหลักที่การทดสอบความปลอดภัยควรตรวจสอบ -

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• ซอฟต์แวร์มีความปลอดภัยจากช่องโหว่ที่ทราบและไม่รู้จัก

• ข้อมูลซอฟต์แวร์มีความปลอดภัย

• ซอฟต์แวร์เป็นไปตามกฎระเบียบด้านความปลอดภัยทั้งหมด

• การตรวจสอบอินพุตและการตรวจสอบความถูกต้อง

• การโจมตีการแทรก SQL

• ข้อบกพร่องในการฉีด

• ปัญหาการจัดการเซสชัน

• การโจมตีด้วยสคริปต์ข้ามไซต์

• บัฟเฟอร์ล้นช่องโหว่

• การโจมตีแบบข้ามผ่านไดเรกทอรี

การทดสอบการพกพา

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

• การถ่ายโอนซอฟต์แวร์ที่ติดตั้งจากคอมพิวเตอร์เครื่องหนึ่งไปยังอีกเครื่องหนึ่ง

• การสร้างไฟล์ปฏิบัติการ (.exe) เพื่อเรียกใช้ซอฟต์แวร์บนแพลตฟอร์มต่างๆ

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

• ซอฟต์แวร์ควรได้รับการออกแบบและเข้ารหัสโดยคำนึงถึงความต้องการในการพกพา

• มีการทดสอบหน่วยกับส่วนประกอบที่เกี่ยวข้อง

• ทำการทดสอบการผสานรวมแล้ว

• สร้างสภาพแวดล้อมการทดสอบแล้ว

เอกสารประกอบการทดสอบเกี่ยวข้องกับเอกสารของสิ่งประดิษฐ์ที่ควรพัฒนาก่อนหรือระหว่างการทดสอบซอฟต์แวร์

เอกสารสำหรับการทดสอบซอฟต์แวร์ช่วยในการประมาณค่าความพยายามในการทดสอบความครอบคลุมของการทดสอบการติดตาม / การติดตามความต้องการ ฯลฯ ส่วนนี้จะอธิบายถึงสิ่งประดิษฐ์ที่เป็นเอกสารที่ใช้กันทั่วไปซึ่งเกี่ยวข้องกับการทดสอบซอฟต์แวร์เช่น -

• แผนการทดสอบ
• สถานการณ์ทดสอบ
• กรณีทดสอบ
• เมทริกซ์การตรวจสอบย้อนกลับ

แผนการทดสอบ

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

แผนการทดสอบมีดังต่อไปนี้ -

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

สถานการณ์ทดสอบ

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

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

กรณีทดสอบ

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

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

• รหัสกรณีทดสอบ
• โมดูลผลิตภัณฑ์
• รุ่นผลิตภัณฑ์
• ประวัติการแก้ไข
• Purpose
• Assumptions
• Pre-conditions
• Steps
• ผลที่คาดว่าจะได้รับ
• ผลลัพธ์ที่แท้จริง
• Post-conditions

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

เมทริกซ์การตรวจสอบย้อนกลับ

Traceability Matrix (หรือที่เรียกว่า Requirement Traceability Matrix - RTM) เป็นตารางที่ใช้ในการติดตามข้อกำหนดระหว่างวงจรชีวิตการพัฒนาซอฟต์แวร์ สามารถใช้สำหรับการติดตามไปข้างหน้า (เช่นจากข้อกำหนดสู่การออกแบบหรือการเข้ารหัส) หรือย้อนกลับ (เช่นจากการเข้ารหัสเป็นข้อกำหนด) มีเทมเพลตที่ผู้ใช้กำหนดเองมากมายสำหรับ RTM

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

• ตรวจสอบให้แน่ใจว่าซอฟต์แวร์ได้รับการพัฒนาตามข้อกำหนดที่กล่าวถึง
• ช่วยในการค้นหาสาเหตุของจุดบกพร่องใด ๆ
• ช่วยในการติดตามเอกสารที่พัฒนาในช่วงต่างๆของ SDLC

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

การวิเคราะห์จุดทำงาน

วิธีนี้ขึ้นอยู่กับการวิเคราะห์ความต้องการของผู้ใช้ที่ใช้งานได้ของซอฟต์แวร์ตามประเภทต่อไปนี้ -

• Outputs
• Inquiries
• Inputs
• ไฟล์ภายใน
• ไฟล์ภายนอก

การวิเคราะห์จุดทดสอบ

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

วิธี Mark-II

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

• กำหนดทัศนะ
• วัตถุประสงค์และประเภทของการนับ
• กำหนดขอบเขตของการนับ
• ระบุธุรกรรมเชิงตรรกะ
• ระบุและจัดประเภทประเภทเอนทิตีข้อมูล
• นับประเภทองค์ประกอบข้อมูลอินพุต
• นับขนาดการทำงาน

เบ็ดเตล็ด

คุณสามารถใช้เทคนิคการประมาณอื่น ๆ ที่เป็นที่นิยมเช่น -

• เทคนิคเดลฟี
• การประมาณตามการเปรียบเทียบ
• การประมาณค่าตามการแจงนับกรณีทดสอบ
• การประมาณการตามงาน (กิจกรรม)
• วิธี IFPUG