บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)

บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)

บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์
14.1 พื้นฐานการทดสอบซอฟต์แวร์ 14.2 การทดสอบกล่องดำและกล่องขาว 14.3 การทดสอบแบบกล่องขาว 14.4 การทดสอบเส้นทางมูลฐาน

14.5 การทดสอบโครงสร้างควบคุม 14.6 การทดสอบแบบกล่องดำ 14.7 วิธีทดสอบเชิงวัตถุ 14.8 การประยุกต์วิธีออกแบบ ณ ระดับคลาส

14.9 การออกแบบกรณีทดสอบระหว่างคลาส 14.10 การทดสอบสำหรับสภาพแวดล้อม สถาปัตยกรรม และ แอพพลิเคชั่นพิเศษ 14.11 แบบรูปการทดสอบ 14.12 สรุปท้ายบท

แนวคิดที่สำคัญ (Key Concepts)
การวิเคราะห์ค่าขอบเขต Boundary Values Analysis (BVA) ความซับซ้อนไซโคลแมติก Cyclomatic Complexity การแบ่งส่วนสมมูล Equivalence partitioning กราฟกระแสงาน Flow graphs การทดสอบได้ Testability การทดสอบ Testing เส้นทางมูลฐาน Basis path กล่องดำ Black-box ระดับคลาส Class-level โครงสร้างควบคุม Control-structure เชิงจับผิด Fault-based ลูป Loops เชิงวัตถุ Object-oriented เชิงฉากการใช้งาน Scenario-based กล่องขาว White-box

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

14.1 พื้นฐานการทดสอบซอฟต์แวร์ (SOFTWARE TESTING FUNDAMENTALS)

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

ความสามารถทดสอบได้ (Testability) James Bach ให้นิยามคำนี้ไว้ว่า คือ การที่โปรแกรมคอมพิวเตอร์สามารถูกทดสอบได้โดยง่าย ลักษณะต่อไปนี้นำไปสู่ซอฟต์แวร์ที่ทดสอบได้

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

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

ความสามารถในการควบคุม (Controllability) ยิ่งเราสามารถควบคุมซอฟต์แวร์ได้ดีเท่าไร เรายิ่งสามารถทดสอบโดยอัตโนมัติและเหมาะสมได้มากเท่านั้น สถานะและตัวแปรของซอฟต์แวร์และฮาร์ดแวร์ ควรสามารถควบคุมได้โดยตรงจากนักวิศวกรซอฟต์แวร์ การทดสอบต้องสามารถระบุเจาะจงได้ ทำโดยอัตโนมัติ

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

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

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

ความสามารถในการเข้าใจ (Understandability) ยิ่งเรารู้มากเท่าไหร่ เราก็ยิ่งทดสอบอย่างฉลาดได้มากเท่านั้น ความเข้าในในการออกแบบสถาปัตยกรรมและการขึ้นแก่กันระหว่างองค์ประกอบภายในและภายนอกที่ใช้ร่วมกัน เอกสารทางเทคนิคที่เข้าถึงได้ง่าย จัดเรียงมีระเบียบ มีรายละเอียดตรงตามจริง การเปลี่ยนแปลงการออกแบบที่สามารถสื่อสารกับผู้ทดสอบ

ลักษณะการทดสอบ (Test Characteristics) Kaner, Falk, และ Nguyen แนะนำคุณลักษณะของตัวทดสอบที่ดีไว้ดังต่อไปนี้ มีความน่าจะเป็นสูงในการหาความผิดพลาดพบ ไม่ซ้ำซ้อน ควรเป็นตัวคิดมาดีที่สุดในกลุ่ม ไม่ควรเป็นทั้งธรรมดาเกินไปหรือซับซ้อนเกินไป

14.2 การทดสอบกล่องดำและกล่องขาว (BLACK-BOX AND WHITE-BOX TESTING)

14.2 การทดสอบกล่องดำและกล่องขาว (Black-Box and White-Box Testing)
ผลิตภัณฑ์ต่างๆ อาจถูกทดสอบได้โดยวิธีต่อไปนี้ เมื่อรู้ว่าหน้าที่การงานที่กำหนดไว้มีอะไร ตัวทดสอบอาจออกแบบมาเพื่อสาธิตว่าแต่ละหน้าที่ทำได้ตามที่กำหนด โดยที่พยายามมองว่ามีหน้าที่การทำงานอะไรบกพร่องบ้าง เรียกว่า แบบทดสอบกล่องดำ เมื่อรู้รายละเอียดการทำงานภายในของผลิตภัณฑ์ ตัวทดสอบอาจพยายามดูว่า ทุกชิ้นส่วนภายในทำงานตามข้อกำหนดและพยายามทดสอบการทำงานของทุกๆ ชิ้นส่วนดู เรียกว่า แบบทดสอบกล่องขาว

14.2 การทดสอบกล่องดำและกล่องขาว (Black-Box and White-Box Testing)
การทดสอบแบบกล่องดำ (Black-Box Testing) ทำกับระดับของอินเตอร์เฟสซอฟต์แวร์ โดยจะทำการตรวจสอบแง่มุมพื้นฐานบางส่วนของระบบ โดยไม่คำนึงถึงโครงสร้างภายในซอฟต์แวร์ การทดสอบแบบกล่องขาว (White-Box Testing) จะตรวจตราอย่างใกล้ชิดถึงรายละเอียด กระบวนการทำงานภายใน เส้นทางผ่านตัวซอฟต์แวร์และความร่วมมือระหว่างองค์ประกอบ โดยใช้กรณีทดสอบที่วิ่งผ่านเงื่อนไขและลูปต่างๆ

14.3 การทดสอบแบบกล่องขาว (WHITE-BOX TESTING)

14.3 การทดสอบแบบกล่องขาว (White-Box Testing)
การทดสอบแบบกล่องขาว บางครั้งเรียกว่า การทดสอบแบบกล่องแก้ว (Glass-Box Testing) เป็นปรัชญาการออกแบบกรณีทดสอบที่ใช้โครงสร้างควบคุมอธิบายอยู่ในการออกแบบระดับองค์ประกอบเพื่อสร้างกรณีทดสอบ วิธีนักวิศวกรซอฟต์แวร์สร้างกรณีทดสอบที่ รับประกันว่าทุกเส้นทางการทำงานอิสระภายในโมดูลได้รับการทดสอบอย่างน้อย 1 ครั้ง ทดสอบการตัดสินใจทางตรรกะทั้งด้านจริงและด้านเท็จ ทดสอบลูปที่ขอบเขตและการทำงานภายใน ทดสอบโครงสร้างข้อมูลภายในเพื่อดูความถูกต้อง

14.4 การทดสอบเส้นทางมูลฐาน (BASIC PATH TESTING)

14.4 การทดสอบเส้นทางมูลฐาน (Basic Path Testing)
การทดสอบเส้นทางมูลฐาน เป็นเทคนิคการทดสอบแบบกล่องขาวที่นำเสนอโดย Tom Mcbabe วิธีนี้ช่วยนักออกแบบอิมพลีเมนต์แบบกรณีทดสอบตัววัดความซับซ้อนของโมดูลและใช้ค่าที่วัดได้เป็นเกณฑ์ในการกำหนดชุดมูลฐานของเส้นทางทำงาน กรณีทดสอบที่ได้รับประกันว่าจะทำงานทุกๆ ประโยคคำสั่งในโปรแกรมอย่างน้อยหนึ่งครั้งระหว่างการทดสอบ

สัญลักษณ์กราฟกระแสงาน (Flow Graph Notation) ก่อนที่จะกล่าววิธีเส้นทางมูลฐาน จำเป็นต้องรู้จักกับสัญลักษณ์ที่ใช้ในกระแสควบคุม (Control Flow) ที่เรียกว่า กราฟกระแสงาน (Flow Graph) หรือ กราฟโปรแกรม (Program Graph) กราฟกระแสงานแสดงให้เห็นการควบคุมทางตรรกะ แต่ละส่วนมีโครงสร้างสัญลักษณ์เฉพาะตัว

รูปที่ 14.1 สัญญาลักษณ์กราฟกระแสงาน

สัญลักษณ์กราฟกระแสงาน (Flow Graph Notation) ผังโครงสร้างโปรแกรมและกราฟกระแสงานที่คู่กับผังงานนี้ แต่ละวงกลมในกราฟเรียกว่า โหนดกราฟกระแสงาน (Flow Graph Node) ซึ่งแทนประโยคคำสั่งตั้งแต่หนึ่งประโยคขึ้นไป สำหรับกล่องประมวลผลและรูปเปียกปูนการตัดสินใจของผังงานสามารถแปลงโหนดหนึ่งโหนด และจะเรียกลูกศรบนกราฟกระแสงานว่า เส้นเชื่อม (Edge) หรือทางเชื่อม (Lines) แทนกระแสการควบคุม เช่นเดียวกันกับลูกศรของผังงาน เส้นเชื่อมต้องสิ้นสุดลง ณ โหนดหนึ่ง แม้ว่าโหนดนั้นจะไม่ได้แทนประโยคคำสั่งใดๆ

รูปที่ 14.2 (a) ผังงาน (b) กราฟกระแสงาน

สัญลักษณ์กราฟกระแสงาน (Flow Graph Notation) เงื่อนไขเชิงซ้อน ทำให้กราฟกระแสงานซับซ้อนขึ้นเล็กน้อย เงื่อนไขเชิงซ้อนขึ้นเมื่อตัวทำการบูลีน ได้แก่ OR, AND, NAND, NOR อยู่ร่วมในประโยคทดสอบเงื่อนไข โดยโหนดหนึ่งโหนดจะถูกสร้างมาสำหรับแต่ละเงื่อนไข เช่น ในประโยคทดสอบเงื่อนไข IF a OR b จะมีโหนดเงื่อนไข a และโหนดเงื่อนไข b เรียกโหนดทดสอบที่มีเงื่อนไขว่า โหนดทำนาย (Prediction Node) โดยทุกโหนดทำนายจะมีเส้นเชื่อมอย่างน้อย 2 เส้นออกมาจากโหนด

เส้นทางโปรแกรมอิสระ (Independent Program Paths) เส้นทางอิสระ (Independent Paths) คือ เส้นทางใดๆ ผ่านโปรแกรมที่มีประโยคคำสั่งหรือประโยคทดสอบเงื่อนไขใหม่อย่างน้อย 1 ประโยค เมื่อกล่าวถึงในกรณีกราฟกระแสงาน เส้นทางอิสระต้องวิ่งผ่านเส้นเชื่อมอย่างน้อย 1 เส้น ที่ยังไม่เคยผ่าน เส้นทางที่ เส้นทางที่ เส้นทางที่ เส้นทางที่

เส้นทางโปรแกรมอิสระ (Independent Program Paths) เส้นทางที่ ประกอบกันเป็นเซตมูลฐาน (Basis Set) ถ้าตัวทดสอบใดๆ ออกแบบมาให้ทำงานกับเซตมูลฐานนี้ได้หมด ก็สามารถรับประกันได้ว่าทุกๆ ประโยคในโปรแกรมที่ได้รับการทดสอบอย่างน้อยหนึ่งครั้ง และทุกๆ เงื่อนไขได้รับการทดสอบทั้งด้านจริงและด้านเท็จ

เส้นทางโปรแกรมอิสระ (Independent Program Paths) เราสามารถคำนวณเส้นทางได้โดยการคำนวณความซับซ้อนทางไซโคลแมติก (Cyclomatic Complexity) ความซับซ้อนไซโคลแมติกเป็นหน่วยวัดซอฟต์แวร์แบบหนึ่ง (Software Metric) ที่ให้ค่าคุณภาพของความซับซ้อนเชิงตรรกะของโปรแกรม

เส้นทางโปรแกรมอิสระ (Independent Program Paths) ความซับซ้อนไซโคลแมติกมีรากฐานมาจากทฤษฏีกราฟ คำนวณได้ 3 วิธี คือ จำนวนเขตของกราฟกระแสงาน ความซับซ้อนไซโคลแมติก หรือ V(G) ของกราฟกระแสงาน G มีนิยามดังนี้ V(G) = E-N+2 เมื่อ E เป็นจำนวนเชื่อม และ N เป็นจำนวนโหนดของกราฟกระแสงาน V(G) = P+1 เมื่อ P เป็นจำนวนโหนดทำนาย (Predicate Node) ในกราฟกระงาน G

รูปที่ 14.3 เงื่อนไขเชิงซ้อน

เส้นทางโปรแกรมอิสระ (Independent Program Paths) นอกจากนี้ V(G) ยังเป็นขอบเขตบนสำหรับจำนวนเส้นทางอิสระในเซ็ตมูลฐาน ซึ่งโดยนัยก็คือขอบเขตของจำนวนตัวทดสอบและทำการทดสอบ เพื่อรับประกันการครอบคลุมประโยคคำสั่งของโปรแกรม

การสร้างกรณีทดสอบ (Deriving Test case) วิธีทดสอบเส้นทางมูลฐานสามารถประยุกต์ใช้กับชิ้นงานออกแบบ (Procedural Design) หรือกับรหัสต้นฉบับ (Source Code) ขั้นตอนต่อไปนี้ประยุกต์เพื่อสร้างเพื่อสร้างเซ็ตมูลฐาน

14.5 การทดสอบโครงสร้างควบคุม (CONTROL STRUCTURE TESTING)

14.5 การทดสอบโครงสร้างควบคุม (Control Structure Testing)
การทดสอบเงื่อนไข (Condition Testing) การทดสอบเงื่อนไขเป็นวิธีการออกแบบกรณีทดสอบเงื่อนไขทางตรรกะในโปรแกรม เงื่อนไขเบื้องต้น คือตัวแปรบูลีน หรือนิพจน์เชิงสัมพันธ์ มีรูปแบบดังนี้ E1 < ตัวกระทำเชิงสัมพันธ์ > E2

การทดสอบเงื่อนไข (Condition Testing) เมื่อ E1 และ E2 เป็นนิพจน์คำนวณ และตัวกระทำเชิงสัมพันธ์อาจะเป็นหนึ่งในเครื่องหมายต่อไปนี้ คือ <, , , , > และเงื่อนไขตัวประกอบ (Compound Condition) จะประกอบด้วยเงื่อนไขเบื้องต้น 2 เงื่อนไขขึ้นไปโดยใช้ ตัวกระทำบูลีนและวงเล็บ ตัวกตะทำลูลีน (Boolean Operations) รวมถึง OR (|) , AND (&) และ NOT () เงื่อนไขที่ไม่มีนิพจน์เชิงสัมพันธ์ จะเรียกว่า นิพจน์บูลีน (Boolean Expression) ดั้งนนั้นองค์ประกอบที่เป็นไปได้ในเงื่อนไข ได้แก่ ตัวแระทำบูลีน ตัวแปรบูลีน วงเล็บ ตัวกระทำเชิงสัมพันธ์ หรือนิพจน์คำนวณ

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

การทดสอบกระแสข้อมูล (Data Flow Testing) วิธีการทดสอบกระแสข้อมูลจะเลือกเส้นทางทดสอบโปรแกรมตามจุดนิยามและจุดใช้ตัวแปรในโปรแกรม สมมติว่าแต่ละคำสั่งในโปรแกรมมีหมายเลขเฉพาะตัวและแต่ละฟังก์ชั่นไม่ได้เปลี่ยนแปลงค่าของพารามิเตอร์หรือตัวแปรส่วนกลางสำหรับประโยคคำสั่งหมายเลข S DEF(S) = {x | ประโยคคำสั่ง S มีนิยามของ x} USE(S) = {x | ประโยคคำสั่ง S มีการใช้งาน x}

การทดสอบกระแสข้อมูล (Data Flow Testing) ถ้าประโยคคำสั่ง S เป็นคำสั่ง if หรือ loop เซต DEF จะว่างเปล่า และเซ็ต USE จะขึ้นกับเงื่อนไขของคำสั่ง S เราจะเรียกนิยามของตัวแปร x ที่ประโยค S ว่ามีชีวิต ณ ประโยคคำสั่ง S ถ้ามีเส้นทางจริงจากประโยค S ถึงประโยค S ที่ไม่มีนิยามอื่นของ x โซ่ DU (Definition-Use Chain) ของตัวแปร x อยู่ในรูปแบบ [x, S, S’] เมื่อ S และ S’ เป็นเครื่องหมายเลขประโยคคำสั่งที่ x อยู่ใน DEF(S) และ x อยู่ใน USE(S’)

การทดสอบกระแสข้อมูล (Data Flow Testing) กลยุทธ์ง่ายๆ อย่างหนึ่งของการทดสอบกระแสข้อมูล คือ บังคับให้มีการครอบคลุมโซ่ DU ทุกอันอย่างน้อยหนึ่งครั้ง เรากล่าวถึงกลยุทธ์นี้ว่า กลยุทธ์การทดสอบ DU แม้ว่าจะมีการแสดงให้เห็นว่า การทดสอบ DU ไม่รับประกันว่าจะครอบคลุมทุกทางที่เป็นไปได้ของโปรแกรม แต่ก็เกิดขึ้นน้อยและเฉพาะกรณี เช่น if-then-else ในกรณีส่วน then ไม่มีนิยามของตัวแปรใดๆ และไม่มีส่วน else ในสถานการณ์เช่นนี้ ทางเลือกส่วน else ของประโยค if อาจไม่ครอบคลุมด้วยการทดสอบ DU

การทดสอบกระแสข้อมูล (Data Flow Testing) การทดสอบลูปเป็นเทคนิคการทดสอบแบบกล่องขาวที่ตรวจความถูกต้องของโครงสร้างลูป ลูปมี 4 รูปแบบ คือ ลูปอย่างง่าย (Simple Loops) ลูปต่อกัน (Concatenated Loops) ลูปซ้อนลูป (Nested Loops) ลูปไม่เป็นโครงสร้าง (Unstructured Loops)

14.7 วิธีทดสอบเชิงวัตถุ (OBJECT-ORIENTED TESTING METHOD)

14.7 วิธีทดสอบเชิงวัตถุ (Object-Oriented Testing Method)
นัยการออกแบบกรณีทดสอบแนวคิดเชิงวัตถุ (The Test Case Design Implications of OO Concepts) คลาสเป็นเป้าหมายของการทดสอบเชิงวัตถุ แต่เนื่องจากคุณสมบัติและตัวดำเนินการถูกปกปิดไว้ การทดสอบตัวดำเนินการจากภายนอกคลาสมักไม่เกิดผลใด แม้ว่าการปกปิดแนวคิดการออกแบบเชิงวัตถุที่สำคัญ แต่ก็อาจก่ออุปสรรคในการทดสอบ

นัยการออกแบบกรณีทดสอบแนวคิดเชิงวัตถุ (The Test Case Design Implications of OO Concepts) การสืบทอดคุณสมบัติ (Inheritance) เป็นปัญหาที่ท้าทายสำหรับนักออกแบบกรณีทดสอบ การใช้งานวัตถุภายใต้บริบทใหม่ๆ จำเป็นต้องได้รับการทดสอบ แม้ว่าจะเป็นการนำกลับมาใช้ใหม่ (Reuse) ยิ่งไปกว่านั้น การสืบทอดคุณสมบัติจากหลายคลาสก็อาจสร้างความซับซ้อนแก่การทดสอบมากขึ้น เนื่องจากจำนวนบริษทที่ต้องใช้ในการทดสอบจะเพิ่มมากขึ้น ในกรณีที่เราใช้งานซับคลาสและซูเปอร์คลาสใต้โดเมนปัญหาเดียวกัน เราก็อาจใช้ชุดกรณีทดสอบเดียวกันได้ แต่ถ้าซับคลาสถูกใช้ในบริษัทีที่แตกต่างออกไป เราจะต้องออกแบบชุดกรณีทดสอบใหม่เพิ่มเติม

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

การทดสอบเชิงจับผิด (Fault-Based Testing) เมื่อประยุกต์กับการทดสอบเชิงวัตถุ การทดสอบเชิงบูรณาการจะมองหาความล้มเหลวในการเรียกใช้ตัวกระทำการหรือการส่งข้อความ ความล้มเหลวสามชนิดที่อาจพบ ได้แก่ การได้ผลลัพธ์ที่ไม่คาดคิด การใช้งานตัวกระทำหรือข้อความที่ผิด และการเรียกใช้งานวัตถุที่ไม่ถูกต้อง เราต้องทำการเฝ้าตรวจดูพฤติกรรมของตัวกระทำเพื่อจะค้นหาความล้มเหลวจากการใช้งานตัวกระทำนั้นๆ

กรณีทดสอบกับลำดับชั้นของคลาส (Test Cases and Class Hierarchy) การสืบทอดคุณสมบัติไม่ได้ทำให้ความจำเป็นในการทดสอบคลาสลูกอย่างถี่ถ้วนหมดไป แม้ว่าคลาสจะถูกทดสอบอย่างถี่ถ้วนแล้ว คลาสที่สร้างจากคลาสฐานก็ยังจำเป็นต้องถูกทดสอบอยู่

การทดสอบเชิงฉากบรรยาย (Scenario-Based Testing) การทดสอบเชิงจับผิดจะไม่มีการตรวจสอบข้อผิดพลาดสองชนิดคือ ข้อกำหนดที่ผิดพลาด ปฏิสัมพันธ์ระหว่างระบบย่อย

การทดสอบเชิงฉากบรรยาย (Scenario-Based Testing) การทดสอบเชิงฉากบรรยายมุ่งทดสอบสิ่งที่ผู้ใช้งานทำ ไม่ใช่สิ่งที่ผลิตภัณฑ์ทำ โดยการดักจับงานย่อยผ่านยูสเคสที่ผู้ใช้งานกระทำกับระบบ สร้างตัวทดสอบและลองใช้กับระบบ ฉากบรรยายสามารถค้นถบความผิดพลาดด้านปฏิสัมพันธ์ โดยตัวทดสอบจะใช้งานหลายๆ ระบบย่อยในหนึ่งครั้ง ตัวอย่างเช่น การออกแบบการทดสอบเชิงฉากบรรายายสำหรับ text editor โดยพิจารณาจากยูสเคสต่อไปนี้

การทดสอบเชิงฉากบรรยาย (Scenario-Based Testing) Use-Case : ตรวจแก้ดราฟสุดท้าย Background : เป็นเรื่องปกติที่จะมีการพิมพ์ดราฟสุดท้ายมาอ่าน และแก้ไขสิ่งที่อาจะไม่พบบนหน้าจอ ขั้นตอนลำดับเหตุการณ์มีดังนี้ พิมพ์เอกสารทั้งหมด ตรวจสอบเอกสารและเปลี่ยนแปลงบางหน้า หน้าที่เปลี่ยนจะถูกพิมพ์ใหม่ บางครั้งจะมีการพิมพ์หลายหน้าติดต่อกัน

การทดสอบโครงสร้างเชิงผิว และโครงสร้างเชิงลึก (Testing Surface Structure and Deep Structure) โครงสร้างเชิงผิว (Surface Structure) หมายถึง โครงสร้างที่สังเกตได้จากภายนอกของโปรแกรมเชิงวัตถุอันเป็นโครงสร้างที่ผู้ใช้งานสุดท้ายเห็นได้ชัดเจน การทดสอบจะขึ้นกับงานย่อยของผู้ใช้งาน การออกแบบกรณีทดสอบโครงสร้างผิดควรใช้ทั้งวัตถุและตัวกระทำในการค้นหางานย่อยที่อาจมองข้ามไป

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

14.8 การประยุกต์วิธีทดสอบ ณ ระดับคลาส (TESTING METHODS APPLICABLE AT THE CLASS LEVEL)

14.8 การประยุกต์วิธีทดสอบ ณ ระดับคลาส (Testing Methods Applicable at the Class Level)
การทดสอบแบบสุ่มสำหรับคลาสเชิงวัตถุ (Random Testing for OO Classes) พิจารณาแอพพลิเคชั่นธนาคารที่มีคลาส Account และมีตัวกระทำการต่อไปนี้ คือ open(), setup(), deposit(), withdraw(), balance(), creditlimit(), และ close() โดยมีเงื่อนไขบางประการในการใช้งานคลาส Account เช่น บัญชีต้องถูกเปิดก่อนการกระทำอื่นจะใช้งานได้ และบัญชีจะถูกปิดหลังจากได้ทำทุกงานเสร็จแล้ว แม้ว่าจะได้คำนึงถึงเงื่อนไขทางธุรกิจเหล่านี้แล้ว จำนวนการจับคู่ประสมของตัวกระทำการยังมีจำนวนมากมาย พฤติกรรม

การทดสอบแบบสุ่มสำหรับคลาสเชิงวัตถุ (Random Testing for OO Classes) แม้ว่าจะได้คำนึงถึงเงื่อนไขทางธุรกิจเหล่านี้แล้ว จำนวนการจับคู่ประสมของตัวกระทำการยังมีจำนวนมากมาย พฤติกรรมระดับต่อสุดของบัญชี Account หนึ่งๆ ได้แก่ open  setup  deposit  withdraw  close อันเป็นลำดับการดสอบขั้นต่ำสุดสำหรับ Account

การทดสอบแบบสุ่มสำหรับคลาสเชิงวัตถุ (Random Testing for OO Classes) อย่างไรก็ตาม ยังมีพฤติกรรมอีกหลายหลากที่อาจเกิดขึ้นในลำดับการทำงานต่อไปนี้ open  setup  deposit  [deposit | withdraw | balance | summarize | creditlimit]n  withdraw  close

การทดสอบแบบสุ่มสำหรับคลาสเชิงวัตถุ (Random Testing for OO Classes) โดยเราอาจสร้างกรณีทดสอบขึ้นแบบสุ่มได้ ตัวอย่างเช่น กรณีทดสอบ r1: open.setup.deposit.deposit.balance.summarize.withdraw.close กรณีทดสอบ r2: open.setup.deposit.withdraw.deposit.balance.creditlimit.withdraw.close และกรณีทดสอบลำดับเหตุการณ์แบบสุ่มอื่นๆ เพื่อทดสอบการทำงานของประวัติชีวิตของตัวอย่างคลาสที่แตกต่างกันออกไป

การทดสอบแบบแบ่งชั้น ณ ระดับคลาส (Partition Testing at the Class Level) การทดสอบแบบแบ่งชั้นช่วยลดจำนวนกรณีทดสอบ โดยพิจารณาแบ่งประเภทของข้อมูลเข้าและออก แล้วออกแบบกรณีทดสอบเพื่อทำงานกับประเภทข้อมูลเหล่านั้น สำหรับโปรแกรมเชิงวัตถุ การแบ่งเชิงสถานะจัดกลุ่มตัวกระทำการของคลาสตามลักษณะสถานที่ของคลาสที่เปลี่ยนไป

การทดสอบแบบแบ่งชั้น ณ ระดับคลาส (Partition Testing at the Class Level) การแบ่งชั้นเชิงแอตทริบิวส์ (Attribute-based Partitioning) จัดประเภทตัวกระทำของคลาสตามแอตทริบิวส์ที่ใช้งาน การแบ่งชั้นตามประเภท (Category-based Partitioning) จะจัดแบ่งตัวกระทำของคลาสตามหน้าที่ทั่วไปที่ดี

14.9 การออกแบบกรณีทดสอบระหว่างคลาส (INTER CLASS TEST CASE DESIGN)

14.9 การออกแบบกรณีทดสอบระหว่างคลาส (Inter Class Test Case Design)
การทดสอบหลายคลาส (Multiple Class Testing) Kirani และ Tsai ได้แนะนำขั้นตอนในการสร้างกรณีทดสอบแบบสุ่มสำหรับทดสอบหลายๆ คลาสดังต่อไปนี้ สำหรับแต่ละคลาสลูกค้า ให้ใช้รายการของตัวกระทำการของคลาสในการสร้างชุดลำดับของตัวทดสอบแบบสุ่ม ตัวกระทำการจะส่งข้อความไปยังคลาสบริการอื่นๆ สำหรับแต่ละข้อความที่สร้างขึ้นมา ให้กำหนดคลาสที่ร่วมมือทำงานและตัวกระทำที่ร่วมทำงานในวัตถุบริการ สำหรับแต่ละตัวกระทำการในวัตถุบริการที่ได้ถูกเรียกใช้จากข้อความที่ส่งมา ให้กำหนดข้อความต่างๆ ที่ส่งต่อไปได้ สำหรับแต่และข้อความ ให้กำหนดตัวกระทำระดับถัดไปที่ถูกเรียกใช้งานและเพิ่มเข้าไปในลำดับการทดสอบ

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

การสร้างตัวทดสอบจากแบบจำลองพฤติกรรม (Tests Derived from Behavior Models) แผนภาพสถานะของคลาสสามารถใช้ในการสร้างชุดลำดับการทดสอบที่ทดสอบพฤติกรรมพลวัตของคลาสที่เกี่ยวข้อง การออกแบบการทดสอบควรครอบคลุมทุกสถานะ สามารถสร้างกรณีทดสอบเพิ่มเติมได้เรื่อยๆ เพื่อให้มั่นใจว่าทุกๆ พฤติกรรมของคลาสได้รับการทดสอบอย่างเพียงพอ เราสามารถเดินทางไปในแผนภาพสถานะแบบทางกว้างก่อน (Breadth-First) ซึ่งทางกว้างนี้หมายถึง กรณีทดสอบจะทำให้เกิดการเปลี่ยนสถานเพียง 1 ครั้ง การเปลี่ยนสถานะใหม่จะถูกทดสอบก็ต่อเมื่อสถานะที่ได้ผ่านการทดสอบและถูกเรียกใช้งานด้วย

14.10 การทดสอบสำหรับสภาพแวดล้อม สถาปัตยกรรม และแอพพลิเคชั่นพิเศษ (TESTING FOR SPECIALIZED ENVIRONMENTS, ARCHITECTURE, AND APPLICATIONS)

14.10 การทดสอบสำหรับสภาพแวดล้อม สถาปัตยกรรม และแอพพลิเคชั่นพิเศษ
การทดสอบ GUIs (Testing GUIs) ความซับซ้อนของส่วนต่อประสานกับผู้ใช้เชิงกราฟิก (Graphical User Interface – GUI) ที่เพิ่มขึ้น จะนำไปสู่ความยากลำบากในการออกแบบและใช้งานกรณีทดสอบ แต่เนื่องจาก GUI สมัยใหม่มีหน้าตาและการใช้งานคล้ายๆ กัน เราจึงอาจสร้างตัวทดสอบมาตรฐานขึ้นมาได้ กราฟจำลองสถานะจำกัดอาจช่วยสร้างชุดลำดับของการทดสอบที่มุ่งทดสอบข้อมูลและโปรแกรมที่เกี่ยวเนื่องกับ GUI ** เนื่องจากจำนวนของการเรียงสับเปลี่ยนองค์ประกอบของ GUI มีขนาดใหญ่ การทดสอบจึงควรใช้เครื่องมืออัตโนมัติ **

การทดสอบสถาปัตยกรรมรับ-ให้บริการ หรือ client/server (Testing for Client/Server Architectures) การทดสอบแบบ Client/Server มีอยู่ 3 ระดับ คือ แอพพลิเคชั่น Client แต่ละตัวจะถูกทดสอบในโหมดที่ไม่เชื่อมต่อกับ Server และเครือข่าย ทดสอบแอพพลิเคชั่นด้าน Client และ Server ที่เชื่อมต่อกันและทำงานร่วมกัน แต่ไม่ต้องเจาะจงทดสอบตัวกระทำด้านการเชื่อมต่อ ทดสอบสถาปัตยกรรม Client/Server อย่างสมบูรณ์ ซึ่งรวมถึงตัวกระทำการด้านการเชื่อมต่อ และประสิทธิภาพของระบบ

การทดสอบสถาปัตยกรรมรับ-ให้บริการ หรือ client/server (Testing for Client/Server Architectures) วิธีการทดสอบที่พบได้ทั่วไปในแอพพลิเคชั่น Client/Server ได้แก่ การทดสอบหน้าที่การทำงานของแอพพลิเคชั่น การทดสอบ Server การทดสอบฐานข้อมูล การทดสอบทรานแซคชั่น การทดสอบการติดต่อเครือข่าย

การทดสอบระบบเรียลไทม์ (Testing for Real-time Systems) กลยุทธ์ในการทดสอบระบบเรียลไทม์ มีดังนี้ การทดสอบงานย่อย (Task Testing) ทดสอบงานแต่ละงานอย่างอิสระโดยใช้การออกแบบกรณีทดสอบแบบเดิม เพื่อค้นหาข้อผิดพลาดในหน้าที่การทำงานและตรรกะ โดยยังไม่ทดสอบเวลาหรือพฤติกรรม

การทดสอบระบบเรียลไทม์ (Testing for Real-time Systems) กลยุทธ์ในการทดสอบระบบเรียลไทม์ มีดังนี้ การทดสอบพฤติกรรม (Behavioral Testing) โดยการเลียนแบบพฤติกรรมของระบบเรียลไทม์ที่เป็นผลกระทบจากเหตุการ์ภายนอก การวิเคราะห์กิจกรรมที่เกิดขึ้นจะช่วยออกแบบกรณีทดสอบที่ต้องทำเมื่อระบบได้ถูกสร้างขึ้นแล้ว

การทดสอบระบบเรียลไทม์ (Testing for Real-time Systems) กลยุทธ์ในการทดสอบระบบเรียลไทม์ มีดังนี้ การทดสอบการทำงานระหว่างงานย่อย (Intertask Testing) เมื่อข้อผิดพลาดในงานย่อยแต่ละงาน และข้อผิดพลาดทางพฤติกรรมได้ถูกแยกออกมาแล้ว การทดสอบจึงมาค้นหาข้อผิดพลาดที่เกี่ยวกับเวลา การติดต่อสื่อสารกันระหว่างงานย่อยจะถูกทดสอบด้วยอัตราข้อมูลและภาระการคำนวณต่างๆ กัน เพื่อดูว่าข้อผิดพลาดจากการประสานเวลาทำงานระหว่างงานย่อย นอกจากนี้การสื่อสารผ่านแถวคอยของข้อความหรือผ่านตัวเก็บข้อมูล ก็ควรถูกทดสอบเพื่อค้นหาข้อผิดพลาดที่เกิดจากขนาดเนื้อที่ของตัวเก็บข้อมูล

การทดสอบระบบเรียลไทม์ (Testing for Real-time Systems) กลยุทธ์ในการทดสอบระบบเรียลไทม์ มีดังนี้ การทดสอบระบบ (System Testing) ในขั้นนี้ เราจะรวมซอฟต์แวร์และฮาร์ดแวร์เข้าด้วยกัน และจะทำการทดสอบอย่างเต็มอัตราเพื่อค้นหาข้อผิดพลาดจากการเชื่อมประสานซอฟต์แวร์และฮาร์ดแวร์ ดังนั้น การทดสอบการจัดการเหตุการณ์บูลีน (Boolean Events) จึงสำคัญมาก ผู้ทดสอบจะจัดทำรายการทั้งหมดของสัญญาณขัดจังหวะ และตัวประมวลผลที่เกิดขึ้นจากสัญญาณนั้น โดยการใช้แผนภาพสถานะและข้อกำหนดการควบคุม

การทดสอบระบบเรียลไทม์ (Testing for Real-time Systems) กลยุทธ์ในการทดสอบระบบเรียลไทม์ มีดังนี้ การทดสอบระบบ (System Testing) ตัวทดสอบจะได้รับการออกแบบให้เข้าถึงลักษณะต่างๆ ของระบบดังนี้ การจัดลำดับความสำคัญของสัญญาณขัดจังหวะถูกต้องหรือไม่ การประมวลผลสัญญาณถูกต้องหรือไม่ ประสิทธิภาพต่างๆ เป็นไปตามข้อกำหนดความต้องการหรือไม่ ถ้าสัญญาณถูกส่งมามากๆ ในช่วงวิกฤตจะสร้างปัญหากับหน้าที่การทำงานหรือประสิทธิภาพหรือไม่

14.11 แบบรูปการทดสอบ (TESTING PATTERNS)

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

14.11 แบบรูปการทดสอบ (Testing Patterns)
Marick ได้กล่าวถึงประโยชน์เพิ่มเติมของแบบรูปการทดสอบไว้ดังนี้ ให้คำศัพท์สำหรับนักแก้ปัญหา เช่น เราใช้วัตถุว่างเปล่า (Null Object) ในการทดสอบ มุ่งความสนใจไปที่สาเหตุเบื้องหลังปัญหา ทำให้นักออกแบบกรณีทดสอบเข้าใจเหตุผล และสถานการณ์ที่ประยุกต์ใช้แบบรูปมากขึ้น สนับสนุนการคิดแบบเวียนซ้ำ เนื่องจากแต่ละคำตอบจะสร้างบริบทใหม่ที่อาจช่วยแก้ปัญหาใหม่ๆ ได้

14.12 สรุปท้ายบท

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

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

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

14.12 สรุปท้ายบท การออกแบบตัวทดสอบสำหรับคลาสอาจใช้วิธีต่างๆ เช่น การทดสอบเชิงจับผิด การทดสอบเชิงสุ่ม และการทดสอบแบบแบ่งชั้น โดยแต่ละวิธีจะเรียกใช้งานตัวกระทำการภายในคลาส การทดสอบแบบบูรณาการอาจใช้กลยุทธ์เชิงการใช้งาน (Use-based Strategy) นอกจากนี้ก็ยังอาจใช้ตัวทดสอบเชิงสุ่มและแบบแบ่งชั้นได้ การทดสอบเชิงฉากการใช้งาน และตัวทดสอบที่สร้างจากแบบจำลองพฤติกรรมอาจใช้ในการทดสอบคลาสและการทำงานร่วมกันระหว่างคลาส ชุดลำดับการทดสอบจะช่วยติดตามการไหลของตัวกระทำการระหว่างคลาสได้

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

บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 14 กลวิธีการทดสอบซอฟต์แวร์ (TESTING STRATEGIES)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ