ฉันเป็นนักเรียนที่ทำงานเกี่ยวกับ BE (CS) และคำถามของฉันคือ:

1. จำเป็นต้องทำการทดสอบในสาขาซอฟต์แวร์หรือไม่?
2. ถ้าเราสร้างซอฟต์แวร์ด้วยความระมัดระวังเราจะทดสอบทำไม
3. หลังจากการทดสอบเรามั่นใจได้หรือไม่ว่าเราบรรลุเป้าหมายนี้ (ผลิตภัณฑ์ / ซอฟต์แวร์ทำงานตามที่ตั้งใจ) เพราะเราทำการทดสอบเสร็จแล้ว? มันเป็นไปได้?

คำถามของฉัน: จำเป็นต้องมีการทดสอบซอฟต์แวร์หรือไม่

ใช่. เพราะไม่ว่าคุณจะเก่งแค่ไหนคุณก็ไม่สามารถคิดถึงทุกสิ่งได้

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

ใช่

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

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

ขาด การ ที่เหมาะสมทดสอบ Kills จะ

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

ซอฟต์แวร์เขียนโดยคน

ผู้คนไม่สมบูรณ์และทำผิดพลาด

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

ใช่ต้องมีการทดสอบ มันนำความสมดุลและมุมมอง

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

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

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

และในระดับวิทยาลัยลองอ่านเรื่องการพัฒนาโดยใช้การทดสอบการทดสอบหน่วยและการฝึกฝนแบบว่องไวเพื่อทราบว่าตอนนี้สิ่งต่าง ๆ อยู่ที่ใด

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

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

ความผิดพลาดของมนุษย์คือ

ไม่มีสิ่งเช่นซอฟต์แวร์ปราศจากข้อบกพร่อง

นักพัฒนาที่มีทักษะมากที่สุดเขียนโค้ดพร้อมข้อบกพร่อง แม้ว่าจะมีนักพัฒนาซอฟต์แวร์ที่สมบูรณ์แบบก็ยังคงมีข้อผิดพลาดเนื่องจากความแตกต่างระหว่าง:

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

นักพัฒนาที่สมบูรณ์แบบเป็นเพียงส่วนหนึ่งของทุกสิ่ง และนักพัฒนาที่สมบูรณ์แบบไม่มีอยู่จริง

โปรแกรมในชีวิตจริงส่วนใหญ่:

ก) มีโค้ดหลายร้อยบรรทัดขึ้นไปกระจายในไฟล์จำนวนมาก
b) พัฒนาโดยโปรแกรมเมอร์มากกว่าหนึ่งคน
c) ใช้ในสภาพแวดล้อมที่แตกต่างจากสภาพแวดล้อมของผู้พัฒนา

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

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

ใช่.

นี่คือมุมมองที่ลึกซึ้งยิ่งขึ้นอีกเล็กน้อยที่ยังไม่ได้รับการคุ้มครอง:

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

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

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

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

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

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

คุณคิดว่าอะไรทำให้เขามั่นใจในการทำเช่นนั้น?

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

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

มีกลิ่นเหมือนคำถามการบ้าน

จำเป็นต้องทำการทดสอบในสาขาซอฟต์แวร์หรือไม่?

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

ถ้าเราสร้างซอฟต์แวร์ด้วยความระมัดระวังเราจะทดสอบทำไม

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

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

หลังจากการทดสอบเรามั่นใจได้หรือไม่ว่าเราบรรลุเป้าหมายนี้ (ผลิตภัณฑ์ / ซอฟต์แวร์ทำงานตามที่ตั้งใจ) เพราะเราทำการทดสอบเสร็จแล้ว? มันเป็นไปได้?

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

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

สถานการณ์ในโลกแห่งความเป็นจริง - ฉันทำงานกับระบบแบ็คเอนด์ที่ส่งการอัปเดตไปยังบริการ GUI เพื่อแสดงในตารางบนหน้าจอเป็นครั้งคราว ในระหว่างโครงการมีการเพิ่มข้อกำหนดเพื่อเพิ่มการกรองไปยังจอแสดงผล (เช่นผู้ประกอบการสามารถเลือกที่จะแสดงชุดย่อยของรายการในตาราง) ความผิดพลาดในการออกแบบ # 1 - การกรองควรทำโดยบริการ GUI (ฉันมีความคิดที่แปลกประหลาดนี้, ความคิดโบราณวัตถุที่ฟังก์ชั่นการจัดการการแสดงผลควรเป็นความรับผิดชอบของซอฟต์แวร์การจัดการการแสดงผล) แต่เนื่องจากการเมืองและการไร้ความสามารถของฉันปัญหาความต้องการนั้นถูกวางไว้ในบริการแบ็คเอนด์ เอาล่ะไม่มีปัญหาฉันทำได้ กรองการเปลี่ยนแปลงสถานะฉันได้รับข้อความจากนั้นฉันจะส่งสร้างหรือลบข้อความแต่ละแถวในตารางนั้นเป็นวิธีที่อินเทอร์เฟซใช้งานได้ (การออกแบบที่ผิดพลาด # 2 - ไม่มีวิธีส่งอัปเดตไปยังหลายแถวในข้อความเดียวเราไม่สามารถแม้แต่ส่ง "ชัดเจน" หรือ "ลบ" ข้อความเดียวเพื่อล้าง ตารางทั้งหมด)

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

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

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

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

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

1. ) กำจัดความล้มเหลวที่เป็นไปได้มากที่สุดผ่านการออกแบบและการใช้งานที่เหมาะสม 2. ) กำจัดความล้มเหลวที่ไม่คาดคิดจากขั้นตอนการออกแบบและการใช้งานที่ไม่ถูกต้องผ่านการทดสอบในรูปแบบต่าง ๆ (หน่วยการรวม temporal => คำนวณใหม่ลองใหม่หรือเป็นระยะ => เก็บสำเนา, พาริตี้)

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

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

โปรแกรมทั้งหมดมีข้อบกพร่องอย่างน้อยต้องเริ่มด้วย

มีการศึกษาบางอย่างที่มาบรรจบกันประมาณ 1 บั๊กต่อทุกๆห้าบรรทัดของรหัสที่ยังไม่ผ่านการทดสอบ

บทเรียนประวัติศาสตร์:

ย้อนกลับไปในทศวรรษ 1960 ไอบีเอ็มต้องการโปรแกรม "NOP" เพื่อให้สามารถใช้งานฟังก์ชันบางอย่างใน JCL ได้โดยไม่ต้องเรียกใช้โปรแกรม นักพัฒนาเกิดขึ้นกับโปรแกรมแอสเซมเบลอร์หนึ่งบรรทัดซึ่งมีรหัสทั้งหมดอยู่ในชื่อ "IEFBR14" ซึ่งเป็นรหัสจริง:

       BR 14 * brach to return address in register 14

ในช่วงระยะเวลาที่ยาวนานโปรแกรมบรรทัดนี้มีรายงานข้อผิดพลาด 2 รายการและการแก้ไขห้ารายการ

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

เมื่อคุณกำลังพัฒนาด้วย TDD (การทดสอบที่พัฒนาแล้ว) คุณไม่มีผู้ทะเยอทะยาน / ผู้ตั้งค่าที่ไม่จำเป็น ฯลฯ คุณเพียงแค่สร้างสิ่งที่คุณต้องการ

วิธีตอบคำถาม# 3ของคุณ:

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

{ใส่หมวก QA}

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

{หมวก QA ปิด}

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

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

แต่นี่ไม่ใช่กรณี ++++++++

ข้อผิดพลาดเกิดขึ้นบ่อยครั้งบางคนมีความสำคัญต่อการดำเนินงานของโครงการ นอกจากนี้ยังมีการทดสอบข้ามเบราว์เซอร์ (ซึ่งหมายถึงการทดสอบบนเบราว์เซอร์ที่มีอยู่แตกต่างกันเช่น SAFARI, FIREFOX, CHROME และ Internet Explorer) และฉันทำงานในโครงการที่ปุ่มอินเตอร์เฟสแบบง่ายเช่น YES และ NO บนหน้าต่างสำรวจที่ไม่ทำงานในเบราว์เซอร์ทั้งหมดเท่านั้น บางส่วนของพวกเขา

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

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

ใช่

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

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

(ยังมีต่อ)