Testing and maintenance
แนะนำใหม่| English | ไทย |
|---|---|
| run-time error/rʌn taɪm ˈerə/ | ข้อผิดพลาดขณะทำงาน |
| syntax error/ˈsɪntæks ˈerə/ | ข้อผิดพลาดทางไวยากรณ์ |
| logic error/ˈlɒdʒɪk ˈerə/ | ความผิดพลาดด้านตรรกะ |
| dry run/draɪ rʌn/ | การรันแบบแห้ง |
| walkthrough/ˈwɔːkθruː/ | การตรวจสอบผ่าน |
| white-box testing/waɪt bɒks ˈtestɪŋ/ | การทดสอบแบบกล่องขาว |
| black-box testing/blæk bɒks ˈtestɪŋ/ | การทดสอบแบบกล่องดำ |
| integration testing/ˌɪntɪˈɡreɪʃn ˈtestɪŋ/ | การทดสอบแบบบูรณาการ |
| stub/stʌb/ | สตั๊บ (Stub) |
| alpha testing/ˈælfə ˈtestɪŋ/ | การทดสอบอัลฟา |
| beta testing/ˈbiːtə ˈtestɪŋ/ | การทดสอบเบตา |
| acceptance testing/əkˈseptəns ˈtestɪŋ/ | การทดสอบเพื่อรับมอบ |
| test strategy/test ˈstrætədʒi/ | กลยุทธ์การทดสอบ |
| test plan/test plæn/ | แผนการทดสอบ |
| normal data/ˈnɔːml ˈdeɪtə/ | ข้อมูลปกติ |
| abnormal data/əbˈnɔːml ˈdeɪtə/ | ข้อมูลผิดปกติ |
| extreme data/ekˈstriːm ˈdeɪtə/ | ข้อมูลเชิง extrém |
| boundary data/ˈbaʊndəri ˈdeɪtə/ | ข้อมูลขอบเขต |
| corrective maintenance/kəˈrektɪv ˈmeɪntənəns/ | การบำรุงรักษาแบบแก้ไข |
| adaptive maintenance/əˈdæptɪv ˈmeɪntənəns/ | การบำรุงรักษาแบบปรับตัว |
| perfective maintenance/pəˈfektɪv ˈmeɪntənəns/ | การบำรุงรักษาแบบสมบูรณ์ |
| regression testing/rɪˈɡreʃn ˈtestɪŋ/ | การทดสอบย้อนกลับ |
สี่สิบเจ็ดวินาที
- ในวันที่ 4 มิถุนายน 1996 จรวด Ariane 5 ลำแรกถูกส่งขึ้นจากเฟรนช์โกลียา 37 วินาทีต่อมา มันเบี่ยงเบนเส้นทางและทำลายตัวเองNames of payloads worth $370 ล้าน
- สาเหตุมาจากรหัสเพียงบรรทัดเดียวที่ถูกนำกลับมาใช้จากเอเรียน 4 ซึ่งแปลงตัวเลขขนาด 64 บิตให้เป็นจำนวนเต็มขนาด 16 บิต เอเรียน 5 บินเร็วขึ้น ตัวเลขมีขนาดใหญ่ขึ้น และการแปลงนี้เกิดการล้น (overflow): ความผิดพลาดในช่วงรันไทม์ (run-time error) ในฟังก์ชันที่ไม่จำเป็นแม้หลังยกตัว
- โค้ดนี้ไม่เคยถูกทดสอบกับข้อมูลการบินของเอเรียน 5 ไม่มีใครเลือกข้อมูลทดสอบที่ขอบเขตสูงสุดของช่วงบินจรวดลำใหม่
- บทเรียนนี้ครอบคลุมสามประเภทของความผิดพลาด, วิธีการทดสอบ, การเลือกข้อมูลทดสอบ以及如何รักษาโปรแกรมให้ทำงานต่อหลังการปล่อย
สามประเภทของความผิดพลาด
- ความผิดพลาดด้านไวยากรณ์ (syntax error) ทำลายกฎของภาษา: การขาดวงเล็บ, คำสำคัญพิมพ์ผิด พบได้ระหว่างการแปล (translation), ดังนั้นโปรแกรมจะไม่ทำงานจนกว่าจะแก้ไข
- ความผิดพลาดในช่วงรันไทม์ (run-time error) เกิดขึ้นขณะที่โปรแกรมกำลังทำงาน: การหารด้วยศูนย์, ไฟล์不存在, ดัชนีอาเรย์เกินขอบเขต โปรแกรมหยุดทำงานหรือเกิดข้อยกเว้น; การแก้ไขคือการตรวจสอบก่อนดำเนินการที่เสี่ยง
- ความผิดพลาดด้านตรรกะ (logic error) ทำให้โปรแกรมสามารถทำงานและสร้าง ผลลัพธ์ที่ผิด:
+สำหรับ-, ลูปที่ผิดเพี้ยนไปหนึ่งรอบ, เงื่อนไขในลำดับที่ผิด ไม่มีการเตือนอะไร; เพียงการทดสอบและการติดตาม (tracing) เท่านั้นที่จะเผยให้เห็น
พบระหว่างการแปล, พบในช่วงรันไทม์, พบเฉพาะในผลลัพธ์
จับคู่ประเภทความผิดพลาดแต่ละชนิดกับรูปแบบการปรากฏ
ซิงแท็กซ์ = ถูกตรวจจับในขั้นตอนการแปลภาษา; ลอจิก = ผลลัพธ์ผิด; ขณะรัน = ระบบล่มขณะทำงาน
ตัวอย่างวิธีทำ: หาและแก้ไขความผิดพลาด
Total ← 0
FOR i ← 1 TO Count
Total ← Total + Marks[i]
NEXT i
Average ← Total / Count
IF Average > 50 THEN
OUTPUT "Pass"
- ด้านไวยากรณ์:
IFไม่มีENDIF. ตัวแปลปฏิเสธ ด้านรันไทม์: หากCountเป็น 0 การหารจะล้มเหลว; ป้องกันด้วยIF Count > 0 THEN. ด้านตรรกะ: หากคะแนนสอบเป็น 50 ขึ้นไป,> 50จะตัดสินนักเรียนที่คะแนน 50 พอดีว่าไม่ผ่าน; ควรจะเป็น>= 50** - ระบุประเภท, บอกเหตุผลว่าเป็น类型那样, และให้คำแก้ไข. สองส่วน, สองคะแนน
โปรแกรมหนึ่งแบ่งค่ารวมด้วยจำนวนรายการ แล้วล้มเหลวเมื่อไฟล์ข้อมูลเข้ามีข้อมูลว่างเปล่า นี่คือ:
การหารด้วยศูนย์เกิดขึ้นขณะที่โปรแกรมกำลังทำงานและทำให้หยุดลง การใช้เงื่อนไขป้องกัน เช่น IF Count > 0 สามารถแก้ไขได้
วิธีการทดสอบ: อ่านโค้ด
- การ试运行 (dry run) ติดตามโค้ดบนกระดาษ, เขียนค่าตัวแปรแต่ละตัวลงในตารางติดตาม (trace table) หลังแต่ละบรรทัด
- การ walkthrough เป็นการทบทวนทีม: นักพัฒนาอธิบายโค้ดบรรทัดต่อนั้น mientrasเพื่อนร่วมงานมองหาข้อผิดพลาด
- การทดสอบแบบกล่องขาว (White-box testing) ออกแบบการทดสอบจากโครงสร้างภายในของโค้ด, เพื่อให้ทุกคำสั่ง,每条分支和每个循环都被执行. การทดสอบแบบกล่องดำ (Black-box testing) ออกแบบการทดสอบจากสเปกIFICATIONSเท่านั้น: ใส่ข้อมูลเข้า, เปรียบเทียบผลลัพธ์กับสิ่งที่คาดหวัง, โดยไม่ดูโค้ด
*มองเข้ามาภายนอก, หรือมองเข้าไปภายในเพื่อตรวจสอบทุกเส้นทาง
การออกแบบกรณีทดสอบจากสเปกเพียงอย่างเดียว (ข้อมูลเข้าและผลลัพธ์ที่คาดหวัง) โดยไม่สนใจโค้ดภายใน เรียกว่า ______-box testing.
การทดสอบแบบกล่องดำใช้สเปก; แบบกล่องขาวใช้โครงสร้างภายในของโค้ดเพื่อครอบคลุมคำสั่งและทางแยก
วิธีการทดสอบ: การประกอบและการปล่อย
- การทดสอบแบบบูรณาการ (Integration testing) รวมโมดูลที่ทดสอบแยกต่างหากและทดสอบอินเทอร์เฟซระหว่างกัน สตับ (stub) แทนที่โมดูลที่ยังไม่เขียน, ส่งคืนค่าคงที่เพื่อให้ส่วนอื่นๆ สามารถทดสอบแบบลงสู่ระดับล่างได้
- การทดสอบแบบอัลฟา (Alpha testing) α ทำภายในองค์กรโดยนักพัฒนา ก่อนการปล่อย การทดสอบแบบเบตา (Beta testing) β ให้กลุ่มผู้ใช้จริงจำนวนจำกัดใช้งานโปรแกรมในสภาพแวดล้อมของตนเอง
- การทดสอบการยอมรับ (Acceptance testing) ทำโดยลูกค้า ตามข้อกำหนด, เพื่อตัดสินใจว่าผลิตภัณฑ์พร้อมใช้งานหรือไม่
ห้องปฏิบัติการกระบวนการซอฟต์แวร์
จำแนกตัวอย่างการพัฒนาตามขั้นตอนหรือเครื่องมือที่เกี่ยวข้อง
ตัวอย่างวิธีทำ: วิธีไหนสำหรับสถานการณ์ไหน
- โมดูลรายงานเสร็จแล้วแต่โมดูลฐานข้อมูลที่มันเรียกยังไม่มี: ทดสอบด้วย สตับ ที่ส่งคืนข้อมูลคงที่
- สองโมดูลผ่านการทดสอบของตัวเองแต่ล้มเหลวเมื่อผลลัพธ์ของโมดูลหนึ่งป้อนให้โมดูลอีก: การทดสอบแบบบูรณาการ ของอินเทอร์เฟซ
- ซอฟต์แวร์พร้อมใช้งานแล้ว; บริษัทต้องการให้พบข้อผิดพลาดในสภาวะจริงก่อนการปล่อยตัวจริง: beta testing โดยกลุ่มผู้ใช้จำนวนจำกัด
- ลูกค้าตัดสินใจว่าจะชำระเงินหรือไม่: acceptance testing เทียบกับข้อกำหนดที่ตกลงไว้ ให้ชื่อวิธีนี้ และ อธิบายวัตถุประสงค์ของมัน
จับคู่สถานการณ์แต่ละอย่างกับวิธีการทดสอบที่เหมาะสม
สตับสำหรับส่วนที่หายไป, เบ타สำหรับผู้ใช้งานจริง, รับมอบหมายสำหรับลูกค้า, บูรณาการสำหรับการเชื่อมต่อ
กลยุทธ์การทดสอบและแผนการทดสอบ
- Test strategy คือแนวทางระดับสูง: จะมีการทดสอบประเภทใดบ้าง, ทำโดยใคร, เมื่อไหร่, และต้องผ่านอะไรก่อนเข้าสู่ขั้นตอนถัดไป
- Test plan คือรายการละเอียดของการทดสอบ สำหรับแต่ละข้อ: วัตถุประสงค์, ข้อมูลเข้า, expected output, และคอลัมน์สำหรับ actual output เมื่อรันการทดสอบ
- การทดสอบที่ไม่มีผลลัพธ์ที่คาดหวังไม่ถือเป็น软件测试 มันเพียงแสดงว่าโปรแกรมทำอย่างไร ไม่ใช่ว่าถูกหรือผิด
แผนการทดสอบระบุ สำหรับแต่ละกรณีทดสอบ ได้แก่ ข้อมูลเข้าและผลลัพธ์ที่คาดหวัง
วัตถุประสงค์, ข้อมูลเข้า, ผลลัพธ์ที่คาดหวัง และคอลัมน์สำหรับผลลัพธ์จริง กลยุทธ์คือแนวทางระดับสูง; แผนคือรายการรายละเอียด
การเลือกข้อมูลทดสอบ
- Normal data: ค่าปกติที่ถูกต้องภายในช่วงที่ยอมรับได้ ซึ่งควรได้รับการยอมรับและประมวลผลอย่างถูกต้อง
- Abnormal data: ค่าที่ควรจะถูก ปฏิเสธ,超出ช่วง หรือผิดประเภท
- Extreme data: ค่าที่ใหญ่ที่สุดและเล็กที่สุดที่ยังคง รับได้, ที่ขอบเขตของช่วง Boundary data: คู่ที่ข้ามแต่ละขอบเขต ได้แก่ ค่า extreme ที่รับได้และค่าที่ถูกปฏิเสธที่อยู่นอกขอบเขตเล็กน้อย ซึ่งที่นั่นซ่อนอยู่ความผิดพลาดแบบ off-by-one
ด้านใน, ด้านนอก, และตรงบนเส้น
สำหรับฟิลด์ที่ยอมรับคะแนน 0–100 ค่าทดสอบขอบเขตคืออะไร?
ข้อมูลขอบเขตอยู่ที่ขอบเขตของช่วงที่ยอมรับได้ (และเกินขอบเขตเล็กน้อย) — ซึ่งเป็นจุดที่ข้อผิดพลาด off-by-one ซ่อนอยู่
ตัวอย่างงาน: ข้อมูลทดสอบสำหรับคะแนนตั้งแต่ 0 ถึง 100
| Kind | Data | Expected result |
|---|---|---|
| normal | 50, 75 |
accepted and processed |
| anomali | -10, 200, "abc" |
ditolak: di luar julat atau jenis yang salah |
| ekstrem | 0, 100 |
diterima: nilai sah terkecil dan terbesar |
| boundary | -1 and 0, 100 and 101 |
-1 rejected, 0 accepted; 100 accepted, 101 rejected |
- ทุกบรรทัดต้องมี ผลลัพธ์ที่คาดหวัง; ตารางที่มีเพียงอินพุตเพียงอย่างเดียวจะได้อะไรได้ครึ่งหนึ่ง ค่าสุดขั้วคือ ที่ยอมรับ:
-1เป็นค่าขอบเขต ไม่ใช่ค่าสุดขั้ว
ฟิลด์หนึ่งยอมรับคะแนนตั้งแต่ 0 ถึง 100 ค่าใดเป็น ข้อมูลทดสอบเชิงสุดขั้ว? เลือก ทุก ข้อที่เกี่ยวข้อง
ค่าเชิงสุดขั้วคือค่าน้อยที่สุดและมากที่สุดที่ยังคงรับได้ -1 ไม่ได้รับ จึงเป็นข้อมูลขอบเขตหรือผิดปกติ; 50 เป็นค่าปกติ
การบำรุงรักษา
- ส่วนใหญ่ของค่าใช้จ่ายตลอดอายุการใช้งานของโปรแกรมถูกใช้หลังการปล่อยตัว Corrective maintenance แก้ไขข้อผิดพลาดที่พบขณะใช้งาน
- Adaptive maintenance ทำให้โปรแกรมทำงานต่อได้ในสภาพแวดล้อมที่เปลี่ยนแปลง: ระบบปฏิบัติการใหม่, API ใหม่, การเปลี่ยนแปลงทางกฎหมาย
- Perfective maintenance ปรับปรุงโปรแกรมที่ทำงานอยู่แล้ว: ประสิทธิภาพเร็วขึ้น, ฟังก์ชันใหม่ที่ผู้ใช้ร้องขอ โปรแกรมอาจต้องการทั้งสามชนิดตลอดอายุการใช้งาน
แก้ไขให้, รักษาให้ทำงานต่อ, ทำให้ดีขึ้น
การบำรุงรักษาแบบแก้ไขแก้ปัญหา, การบำรุงรักษาแบบปรับปรุงเพิ่มคุณสมบัติ, และการบำรุงรักษาแบบปรับตัวช่วยให้ซอฟต์แวร์ทำงานต่อได้ในสภาพแวดล้อมที่เปลี่ยนไป
สามประเภทของการบำรุงรักษา: แบบแก้ไข (แก้บั๊ก), แบบปรับปรุง (เพิ่มประสิทธิภาพ), แบบปรับตัว (ระบบปฏิบัติการ/ฮาร์ดแวร์/กฎใหม่)
โปรแกรมบัญชีเงินเดือนถูกแก้ไขเนื่องจากกฎหมายภาษีเปลี่ยนแปลง นี่คือ نوعการบำรุงรักษาส่งใด?
โปรแกรมไม่ได้มีข้อผิดพลาดและไม่ได้รับการปรับปรุง แต่สภาพแวดล้อมเปลี่ยนไป นั่นคือการบำรุงรักษาแบบปรับตัว
การแก้ไขโปรแกรมที่มีอยู่
- อ่านโค้ดเดิมจนเข้าใจอัลกอริทึมและการไหลของข้อมูล หาจุดที่ต้องการแก้ไข: subroutineไหน, บรรทัดไหน
- ทำการเปลี่ยนแปลงให้ น้อยที่สุด; อย่าเขียนโค้ดที่ทำงานอยู่แล้วใหม่ อัปเดตทุกส่วนที่เกี่ยวข้อง: ผู้เรียกพารามิเตอร์ที่เปลี่ยน, routine ที่ใช้โครงสร้างข้อมูลที่เปลี่ยน
- ทดสอบพฤติกรรมใหม่ และ เก่า: regression testing ตรวจสอบว่าสิ่งที่เคยทำงานไม่ได้เสียไป Then document the change.
หลังจากการแก้ไขโปรแกรม การทดสอบถอยกลับจะตรวจสอบว่า:
การทดสอบถอยกลับรันกรณีทดสอบเก่าซ้ำเพื่อยืนยันว่าพฤติกรรมเดิมยังทำงานต่อไปหลังจากมีการเปลี่ยนแปลง
เรียงลำดับขั้นตอนในการแก้ไขโปรแกรมที่มีอยู่
เข้าใจ, หาตำแหน่ง, แก้ไขเล็กน้อย, กระจายผล, ทดสอบทุกอย่าง, บันทึก การข้ามการทดสอบถอยกลับคือสาเหตุที่ทำให้การแก้ไขไปทำลายสิ่งอื่น
คะแนนที่หลุดหายไป
- Extreme is accepted; abnormal is rejected.
0และ100เป็น extreme;-1และ101เป็น boundary values บนฝั่งที่ถูกปฏิเสธ - Logic error ไม่ทำให้ crash โปรแกรม ถ้ามัน crash นั่นคือ run-time error
- Alpha เป็นภายในองค์กร; beta เป็นผู้ใช้จริงภายนอก Stub แทนที่โมดูลที่ขาดหายไป; มันไม่ใช่วิธีการทดสอบสำหรับโค้ดที่สมบูรณ์
- แถว test plan ที่ไม่มี expected output ไม่ได้คะแนน Regression testing ต้องตามหลัง every การเปลี่ยนแปลง
คุณเข้าใจแล้ว
- syntax errors หยุดการแปล · run-time errors ทำให้โปรแกรมที่กำลังทำงาน crash · logic errors ทำงานและให้ผลลัพธ์ผิด, พบได้จากการทดสอบเท่านั้น
- methods: dry run, walkthrough, white-box (จากโค้ด), black-box (จากสเปค), integration (interfaces, กับ stubs สำหรับโมดูลที่ขาด), alpha (ภายในองค์กร), beta (ผู้ใช้จริง), acceptance (ลูกค้า)
- test data: normal รับได้, abnormal ถูกปฏิเสธ, extreme เป็นขอบเขตที่ยอมรับได้, boundary ทั้งสองข้างของแต่ละขอบเขต; การทดสอบทุกครั้งมีผลลัพธ์ที่คาดหวัง
- maintenance: corrective แก้ไข, adaptive ตามทันสภาพแวดล้อม, perfective ปรับปรุง; แก้ไขเล็กน้อย, อัปเดตผู้เรียก, regression test