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

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

ในทางเทคนิคแล้วคอมไพเลอร์และแอสเซมเบลอร์มีการทดสอบอย่างไร (ฉันคิดว่าสิ่งนี้เกี่ยวข้องกับปัญหาการหยุดชะงัก !!)

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

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

SQLite ประกอบด้วยโค้ดประมาณ 73k บรรทัดในขณะที่ชุดทดสอบประกอบด้วยโค้ดประมาณ 91378k บรรทัดมากกว่า 1250x เท่าของ SQLite ฉันคาดว่าคอมไพเลอร์และเครื่องมือหลักอื่น ๆ จะมีอัตราส่วนใกล้เคียงกัน โปรเซสเซอร์ในปัจจุบันได้รับการออกแบบโดยใช้ซอฟต์แวร์เป็นหลักโดยใช้ภาษาคำอธิบายฮาร์ดแวร์เช่น Verilog หรือ VHDL และผู้ที่มีการทดสอบซอฟต์แวร์ก็สามารถทำงานได้เช่นกันเช่นเดียวกับพิน IO แบบพิเศษสำหรับการทดสอบด้วยตนเอง ณ จุดผลิต

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

ในแง่ของคนธรรมดา:

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

ด้านล่างบรรทัด:

ฉันว่าไปสำหรับ OOP ( O ld, O pen และP opular) ฉันเพิ่งสร้างตัวย่อที่

มันเป็นเต่าตลอดทาง

ไม่มีอะไรแน่นอน คุณไม่มีทางเลือกนอกจากต้องชำระคะแนนความเชื่อมั่น

คุณสามารถคิดว่ามันเป็นสแต็ค: คณิตศาสตร์> ฟิสิกส์> ฮาร์ดแวร์> เฟิร์มแวร์> ระบบปฏิบัติการ> แอสเซมเบลอร์ / คอมไพเลอร์ / ฯลฯ

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

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

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

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

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

ใน 25 ปีของการเขียนโปรแกรมส่วนใหญ่ C, C ++ และ Java ฉันได้พบ:

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

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

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

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

จากข้อตกลงสิทธิ์การใช้งาน Microsoft Word

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

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

ซอฟต์แวร์เปรียบเสมือนทฤษฎีทางวิทยาศาสตร์ถือว่าทำงานตามที่ระบุไว้จนกระทั่งไม่สามารถใช้งานได้

ในฐานะนักเขียนคอมไพเลอร์สำหรับภาษาคณิตศาสตร์ * จากประสบการณ์ของฉันฉันสามารถพูดในเชิงทฤษฎีว่าคุณทำไม่ได้ และข้อบกพร่องบางอย่างก็ให้ผลที่ผิดเช่น (จากรายการอัปยศของฉัน) คำนวณ6/3*2จากด้านขวา6/(3*2)และส่งออก 1 โดยไม่ต้องหยุดทำหรือให้ข้อผิดพลาดในการรวบรวมแบบไร้สาระ

แต่คอมไพเลอร์ IMHO หลายคนไม่มีข้อผิดพลาดมากพอ ๆ กับซอฟต์แวร์อื่นเพราะ:

• การทดสอบหน่วยการเขียนเป็นเรื่องง่าย แต่ละคำสั่งเป็นหน่วยและคุณสามารถเขียนการทดสอบได้ง่ายเพียง:test_unit("2+(-2)*(-2+1)*3+1",9);
• โปรแกรมคือการรวมกันของคำสั่งและสำหรับโปรแกรมใด ๆ ที่จะส่งออกผลลัพธ์ที่ถูกต้องแต่ละคำสั่งแต่ละคนจะต้องให้ผลลัพธ์ที่ถูกต้อง ดังนั้นจึงไม่น่าจะมีข้อบกพร่องใด ๆ ในขณะที่โปรแกรมให้ผลลัพธ์ที่ถูกต้อง
• เมื่อขนาดและจำนวนของโปรแกรมที่เขียนเพิ่มโอกาสในการจับข้อบกพร่องเพิ่มขึ้นอย่างมาก

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

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

ในระยะสั้นเป็นไปได้ยากที่จะมีข้อบกพร่องร้ายแรงในคอมไพเลอร์, รหัสเครื่อง ฯลฯ

ภาษาคณิตศาสตร์ที่ถ่อมตนของฉัน *

Flawless? พวกเขาไม่. ฉันเพิ่งติดตั้ง "อัปเดต" บางรายการและเป็นเดือน (และส่วนที่เขียนโปรแกรมซ้ำหลายส่วน) ในภายหลังก่อนที่ไซต์ ASP.NET ของฉันจะทำงานอย่างถูกต้องอีกครั้งเนื่องจากมีการเปลี่ยนแปลงที่อธิบายไม่ได้เกี่ยวกับวิธีการทำงานพื้นฐานต่างๆหรือล้มเหลว

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

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

เพื่อแสดงว่าระบบพื้นฐานนั้นไร้ที่ติทั้งคุณ

a) ต้องพิสูจน์ว่าไม่มีตำหนิ

1. หลักฐานทางคณิตศาสตร์
2. เป็นไปได้จริงสำหรับโปรแกรมที่ไม่สำคัญ

b) ทำการทดสอบแบบละเอียด

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

ในการทดสอบซอฟต์แวร์การทดสอบแบบละเอียดจะใช้ในการทดสอบหน่วยของฟังก์ชั่นพื้นฐานบางอย่างเท่านั้น

ตัวอย่าง: คุณต้องการทดสอบอินพุต 8 อักขระ utf-8 ไปยังบางฟิลด์คุณเลือกที่จะตัดอินพุตที่ 8 เท่าของความยาวสูงสุด 6 ของ utf-8 ในหน่วยไบต์ซึ่งให้ 8 * 6 = 48 ไบต์เพื่อให้มีจริง ๆ จำนวน จำกัด ของความเป็นไปได้

ตอนนี้คุณสามารถคิดว่าคุณจะต้องทดสอบจุดรหัสที่ถูกต้อง 1,112,064ตัวสำหรับอักขระ 8 ตัวแต่ละตัวเช่น 1,112,064 ^ 8 (พูด 10 ^ 48) การทดสอบ (ซึ่งไม่น่าเป็นไปได้แล้ว) แต่คุณต้องทดสอบแต่ละค่าของแต่ละ 48 ไบต์หรือ 256 ^ 48 ซึ่งประมาณ 10 ^ 120 ซึ่งมีความซับซ้อนเช่นเดียวกับหมากรุกเทียบกับจำนวนอะตอมทั้งหมดในจักรวาลประมาณ 10 ^ 80

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

a) ทดสอบตัวอย่างที่ดีและไม่ดี

b) การครอบคลุมโค้ดเช่น ลองทดสอบโค้ดทุกบรรทัดซึ่งค่อนข้างง่ายสำหรับโค้ดส่วนใหญ่ ตอนนี้คุณสามารถสงสัยในสิ่งที่ 1% สุดท้ายของรหัสที่คุณไม่สามารถทดสอบคือ ... บั๊ก, รหัสตาย, ข้อยกเว้นฮาร์ดแวร์ ฯลฯ

c) ความครอบคลุมเส้นทางผลลัพธ์ทั้งหมดของสาขาทั้งหมดในชุดค่าผสมทั้งหมดจะถูกทดสอบ ตอนนี้คุณรู้แล้วว่าทำไมแผนกทดสอบถึงเกลียดเมื่อฟังก์ชั่นของคุณมีมากกว่า 10 เงื่อนไข นอกจากนี้คุณยังสงสัยว่าทำไม 1% สุดท้ายไม่สามารถทดสอบ ... บางสาขาขึ้นอยู่กับสาขาก่อนหน้า

d) การทดสอบข้อมูลทดสอบจำนวนตัวอย่างที่มีค่าเส้นขอบค่าปัญหาที่พบบ่อยและหมายเลขมายากล, ศูนย์, -1, 1, นาที +/- 1, สูงสุด +/- 1, 42, ค่า rnd หากสิ่งนี้ไม่ได้ให้ความคุ้มครองเส้นทางกับคุณคุณรู้ว่าคุณไม่ได้รับค่าทั้งหมดในการวิเคราะห์ของคุณ

หากคุณทำสิ่งนี้แล้วคุณควรเตรียมพร้อมสำหรับการสอบ ISTQB ขั้นพื้นฐาน