คุณควรทดสอบอะไรกับการทดสอบหน่วย


122

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

ปัญหาคือผมไม่ทราบว่าสิ่งที่จะทดสอบ ฉันควรทดสอบกรณีทั่วไปหรือไม่ กรณีขอบ? ฉันจะรู้ได้อย่างไรว่าฟังก์ชั่นครอบคลุมเพียงพอ?

ฉันมักจะมีความรู้สึกแย่ ๆ ที่ในขณะที่การทดสอบจะพิสูจน์ว่าฟังก์ชั่นนั้นใช้ได้กับบางกรณี


ลองดูที่บล็อกของรอย Osherove มีข้อมูลมากมายเกี่ยวกับการทดสอบหน่วยที่นั่นรวมถึงวิดีโอ เขายังได้เขียนหนังสือเล่มหนึ่งว่า "ศิลปะแห่งการทดสอบหน่วย" ซึ่งดีมาก
Piers Myers

9
ฉันสงสัยว่าคุณคิดอย่างไรกับเรื่องนี้หลังจากผ่านไปเกือบ 5 ปี เพราะมากขึ้นเรื่อย ๆ ฉันรู้สึกว่าทุกคนควรรู้จัก "สิ่งที่ไม่ควรทดสอบหน่วย" ในปัจจุบัน การพัฒนาพฤติกรรมขับเคลื่อนมีวิวัฒนาการมาจากคำถามที่คุณถาม
Remigijus Pankevičius

คำตอบ:


121

ปรัชญาส่วนตัวของฉันเป็นเช่นนี้มานานแล้ว:

  1. ทดสอบกรณีทั่วไปของทุกสิ่งที่คุณทำได้ สิ่งนี้จะบอกคุณเมื่อรหัสหยุดพักหลังจากที่คุณทำการเปลี่ยนแปลง (ซึ่งในความคิดของฉันคือประโยชน์ที่ยิ่งใหญ่ที่สุดเพียงอย่างเดียวของการทดสอบหน่วยอัตโนมัติ)
  2. ทดสอบกรณีขอบของรหัสที่ซับซ้อนผิดปกติบางอย่างที่คุณคิดว่าอาจมีข้อผิดพลาด
  3. เมื่อใดก็ตามที่คุณพบข้อบกพร่องให้เขียนกรณีทดสอบเพื่อให้ครอบคลุมก่อนที่จะแก้ไข
  4. เพิ่มการทดสอบขอบเคสลงในโค้ดที่มีความสำคัญน้อยกว่าเมื่อใดก็ตามที่ใครบางคนมีเวลาฆ่า

1
ขอบคุณสำหรับสิ่งนี้ฉันดิ้นรนอยู่ที่นี่ด้วยคำถามเดียวกันกับ OP
สตีเฟ่น

5
+1 แม้ว่าฉันจะทดสอบกรณีขอบของฟังก์ชั่นห้องสมุด / ยูทิลิตี้ประเภทใด ๆ เพื่อให้แน่ใจว่าคุณมีตรรกะ API เช่นเกิดอะไรขึ้นเมื่อโมฆะถูกส่งผ่าน? แล้วอินพุตเปล่าล่ะ? สิ่งนี้จะช่วยให้มั่นใจว่าการออกแบบของคุณมีเหตุผลและบันทึกพฤติกรรมของมุม
mikera

7
# 3 ดูเหมือนจะเป็นคำตอบที่มั่นคงมากเพราะมันเป็นตัวอย่างในชีวิตจริงของการทดสอบหน่วยที่จะช่วยได้ ถ้ามันพังครั้งเดียวก็สามารถแตกอีกครั้ง
Ryan Griffith

เพิ่งเริ่มต้นฉันพบว่าฉันไม่ได้มีความคิดสร้างสรรค์มากในการทดสอบการคิด ดังนั้นฉันจึงใช้มันเป็น # 3 ข้างต้นซึ่งทำให้มั่นใจได้ว่าข้อผิดพลาดเหล่านั้นจะไม่ถูกตรวจจับอีกครั้ง
ankush981

คำตอบของคุณให้ความสำคัญในบทความสื่อยอดนิยมนี้: hackernoon.com/…
BugHunterUK

67

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

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

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

| # |  Equivalence class    | Input        | Output       | # test cases |
+------------------------------------------------------------------------+
| 1 | Lowercase letter      | a - z        | A - Z        | 26           |
| 2 | Uppercase letter      | A - Z        | A - Z        | 26           |
| 3 | Non-alphabetic chars  | 0-9!@#,/"... | 0-9!@#,/"... | 42           |
| 4 | Non-printable chars   | ^C,^S,TAB... | ^C,^S,TAB... | 34           |

คอลัมน์สุดท้ายจะรายงานจำนวนกรณีทดสอบหากคุณระบุจำนวนกรณีทดสอบทั้งหมด ในทางเทคนิคตามกฎของ @ fishtoaster 1 คุณจะต้องรวม 52 กรณีทดสอบทั้งหมดเหล่านั้นสำหรับสองแถวแรกที่ให้ไว้ด้านบนตกอยู่ภายใต้ "กรณีทั่วไป" กฎของ @ fishtoaster 2 จะเพิ่มบางส่วนหรือทั้งหมดจากแถว 3 และ 4 ด้านบนเช่นกัน แต่ด้วยการแบ่งพาร์ติชันที่เท่าเทียมกันการทดสอบกรณีทดสอบหนึ่งกรณีในแต่ละคลาสที่เทียบเท่านั้นเพียงพอแล้ว หากคุณเลือก "a" หรือ "g" หรือ "w" คุณกำลังทดสอบพา ธ ของรหัสเดียวกัน ดังนั้นคุณมีกรณีทดสอบทั้งหมด 4 กรณีแทนที่จะเป็น 52+

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

| # | Input                | # test cases |
| 1 | a, w, z              | 3            |
| 2 | A, E, Z              | 3            |
| 3 | 0, 5, 9, !, @, *, ~  | 7            |
| 4 | nul, esc, space, del | 4            |

(ทันทีที่คุณได้รับค่าขอบเขตมากกว่า 3 ค่าที่แนะนำว่าคุณอาจต้องการคิดทบทวนการแบ่งคลาสดั้งเดิมของคุณ แต่นี่ก็ง่ายพอที่ฉันไม่ได้กลับไปแก้ไข) ดังนั้นการวิเคราะห์ค่าขอบเขตทำให้เราเป็นเพียงแค่ กรณีทดสอบ 17 กรณี - ด้วยความมั่นใจอย่างสูงในการครอบคลุมที่สมบูรณ์ - เปรียบเทียบกับกรณีทดสอบ 128 กรณีเพื่อทำการทดสอบแบบละเอียด (ไม่ต้องพูดถึงว่า combinatorics บอกว่าการทดสอบอย่างละเอียดเป็นไปไม่ได้สำหรับแอปพลิเคชันใด ๆ ในโลกแห่งความเป็นจริง!)


3
+1 นั่นคือวิธีที่ฉันจะเขียนแบบทดสอบ ตอนนี้ฉันสามารถใส่ชื่อ :) ขอบคุณสำหรับการแบ่งปัน
guillaume31

+1 สำหรับ "คำตอบเชิงคุณภาพมีประโยชน์ แต่เป็นไปได้ - และดีกว่า - เป็นเชิงปริมาณ"
Jimmy Breck-McKye

ฉันคิดว่านี่เป็นคำตอบที่ดีถ้าคำสั่งคือ "ฉันจะได้รับความครอบคลุมที่ดีกับการทดสอบของฉัน" ฉันคิดว่ามันจะมีประโยชน์ในการหาวิธีการปฏิบัติด้านบนนี้ - เป็นเป้าหมายที่ทุกสาขาของตรรกะทุกชิ้นในทุกชั้นควรทดสอบอย่างละเอียดด้วยวิธีนี้หรือไม่
Kieren Johnstone

18

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

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

ดังนั้นข้อเสนอแนะของฉันคือ:

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

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

  • ปล่อยให้สิ่งนี้ TDD ไปยังผู้เชี่ยวชาญ TDD

  • และใช่บางครั้งคุณให้ความสนใจกับกรณีขอบบางครั้งในกรณีทั่วไปขึ้นอยู่กับที่คุณคาดหวังที่ไม่คาดคิด แม้ว่าคุณจะคาดหวังสิ่งที่คาดไม่ถึง แต่คุณควรคิดใหม่เกี่ยวกับขั้นตอนการทำงานและวินัย ;-)


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

6
ใหญ่ +1 การมีกำแพงทดสอบหน่วยที่ทดสอบการใช้งานแทนกฎทำให้ต้องมีการเปลี่ยนแปลง 2-3 เท่า
TheLQ

9
เช่นรหัสการผลิตที่เขียนไม่ดีการทดสอบหน่วยการเขียนที่ไม่ดีนั้นยากที่จะรักษา "การทดสอบหน่วยมากเกินไป" ดูเหมือนว่าจะไม่เป็น DRY การทดสอบแต่ละครั้งควรเล่น / พิสูจน์เฉพาะส่วนของระบบ
อัลลัน

1
การทดสอบแต่ละหน่วยควรตรวจสอบสิ่งหนึ่งดังนั้นจึงไม่มีการทดสอบหน่วยมากเกินไป แต่ขาดการทดสอบ หากการทดสอบหน่วยของคุณซับซ้อนแสดงว่าเป็นปัญหาอื่น
graffic

1
-1: ฉันคิดว่าโพสต์นี้เขียนได้ไม่ดี มีหลายสิ่งที่กล่าวถึงและฉันไม่รู้ว่าเกี่ยวข้องกันอย่างไร หากจุดของคำตอบคือ "ประหยัด" ตัวอย่างของคุณเกี่ยวข้องอย่างไร? ดูเหมือนว่าสถานการณ์ตัวอย่างของคุณ (แม้ว่าจริง) มีการทดสอบหน่วยที่ไม่ดี โปรดอธิบายบทเรียนที่ฉันควรจะเรียนรู้จากสิ่งนั้นและช่วยให้ฉันประหยัดได้อย่างไร Leave this TDD stuff to the TDD-expertsนอกจากนี้ผมตรงไปตรงมาก็ไม่ทราบว่าคุณหมายถึงเมื่อคุณพูด
Alexander Bird

8

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

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


คุณคำนวณเปอร์เซ็นต์ความครอบคลุมที่ได้อย่างไร การครอบคลุม 90% ของรหัสของคุณหมายความว่าอย่างไร
zneak

2
@zneak: มีเครื่องมือครอบคลุมรหัสที่จะคำนวณให้คุณ google สำหรับ "ครอบคลุมรหัส" อย่างรวดเร็วควรนำมาเป็นจำนวนมาก เครื่องมือติดตามบรรทัดของโค้ดที่ถูกเรียกใช้งานในขณะที่รันการทดสอบและฐานที่แสดงบรรทัดทั้งหมดของรหัสในแอสเซมบลี (IES) เพื่อให้ได้เปอร์เซ็นต์ความครอบคลุม
Steven Evers

-1 ไม่ตอบคำถาม:The problem is, I don't know _what_ to test
Alexander Bird

6

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

การทดสอบมาก่อน

ไม่เคยเขียนรหัสก่อนเขียนแบบทดสอบ ดูRed-Green-Refactor-Repeat ซ้ำเพื่อดูคำอธิบาย

เขียนการทดสอบการถดถอย

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

สีแดงสีเขียว-Refactor ซ้ำ

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

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

Refactor : ล้างข้อมูลโค้ดของคุณเรียกชื่อเมธอดให้ถูกต้อง ดูว่าการทดสอบยังคงผ่าน เพิ่มประสิทธิภาพ รันการทดสอบอีกครั้ง

ทำซ้ำ : คุณจำกรณีขอบที่การทดสอบไม่ครอบคลุมใช่ไหม ดังนั้นตอนนี้มันเป็นช่วงเวลาที่ยิ่งใหญ่ เขียน testcase ที่ครอบคลุมสถานการณ์นั้นดูมันล้มเหลวเขียนโค้ดดูผ่านมัน refactor

ทดสอบรหัสของคุณ

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


1
สมมติว่าฉันมีอยู่แล้วและ (เท่าที่ฉันเห็น) ฐานการทำงานรหัสฉันจะทำอย่างไร
zneak

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

3
-1 ฉันไม่คิดว่ามันเป็นคำตอบที่ดีมากสำหรับคำถามนี้ คำถามไม่ได้เกี่ยวกับ TDD มันถามเกี่ยวกับสิ่งที่จะทดสอบเมื่อเขียนการทดสอบหน่วย ฉันคิดว่าคำตอบที่ดีสำหรับคำถามจริงควรนำไปใช้กับวิธีการที่ไม่ใช่ TDD
ไบรอัน Oakley

1
หากคุณสัมผัสมันทดสอบ และ Clean Code (Robert C Martin) แนะนำให้คุณเขียน "การทดสอบการเรียนรู้" สำหรับรหัสบุคคลที่สาม วิธีนี้ทำให้คุณเรียนรู้ที่จะใช้มันและคุณมีการทดสอบในกรณีที่รุ่นใหม่เปลี่ยนพฤติกรรมที่คุณใช้
Roger Willcocks

3

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

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


0

คำตอบที่หุ้นคือการ"ทดสอบทุกอย่างที่อาจจะทำลาย"

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

แน่นอนว่าระยะทางของคุณและสภาพแวดล้อมการทำงานของคุณอาจแตกต่างกันไป


ถูก ดังนั้นกรณีใดที่ฉันควรทดสอบ กรณี "ปกติ" กรณีขอบ?
zneak

3
หลักการง่ายๆ? หนึ่งหรือสองขวาตรงกลางของเส้นทางทองและเพียงภายในและนอกขอบใด ๆ
Jeffrey Hantin

@JeffreyHantin นั่นคือ "การวิเคราะห์ค่าขอบเขต" ในคำตอบที่ต่างออกไป
Roger Willcocks
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.