จะสร้าง Mission Critical Software ได้อย่างไร

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

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

แต่วิธีการตรวจสอบว่าซอฟต์แวร์ (ไม่เพียง แต่สเปค) ถูกต้องแน่นอน?

ข้อจำกัดความรับผิดชอบ: ฉันเป็นคนงี่เง่า 90% เมื่อพูดถึงวิทยาศาสตร์คอมพิวเตอร์เชิงทฤษฎี ดังนั้นโปรดเมตตาในขณะตอบรับ

คำถามค่อนข้างกว้าง เพื่อตอบในพื้นที่ที่เหมาะสมฉันจะทำให้ oversimplifications มากมาย

ให้เราเห็นด้วยกับคำศัพท์ โปรแกรมนั้นถูกต้องเมื่อมันหมายถึงข้อกำหนดของมัน ข้อความที่คลุมเครือนี้สร้างขึ้นอย่างแม่นยำในหลาย ๆ ด้านโดยการกำหนดว่าโปรแกรมคืออะไรและอะไรคือข้อกำหนด ตัวอย่างเช่นในการตรวจสอบรูปแบบโปรแกรมเป็นโครงสร้าง Kripkeและข้อกำหนดมักเป็นสูตรLTL หรือโปรแกรมอาจเป็นรายการของคำสั่ง PowerPC และสเปคอาจเป็นชุดของการยืนยัน Hoare-Floyd ที่เขียนด้วยคำพูดตรรกะอันดับหนึ่ง. มีรูปแบบที่เป็นไปได้มากมาย มันเป็นการดึงดูดที่จะสรุปว่าในกรณีหนึ่ง (โครงสร้าง Kripke) เราไม่ได้ตรวจสอบโปรแกรมจริงในขณะที่ในกรณีที่สอง (รายการคำสั่ง PowerPC) ที่เราทำ อย่างไรก็ตามสิ่งสำคัญคือต้องตระหนักว่าเรากำลังมองหาแบบจำลองทางคณิตศาสตร์ในทั้งสองกรณีและนี่คือสิ่งที่ดีอย่างสมบูรณ์ (สถานการณ์ค่อนข้างคล้ายกับฟิสิกส์ที่ยกตัวอย่างเช่นกลศาสตร์คลาสสิกเป็นแบบจำลองทางคณิตศาสตร์ของความเป็นจริง)

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

• (ขั้นตอนเล็ก ๆ ) ความหมายในการปฏิบัติงาน : นี่เป็นเหมือนการกำหนดภาษาโปรแกรมด้วยการเขียนล่ามให้ สำหรับสิ่งนี้คุณต้องพูดว่ารัฐคืออะไรและมันได้รับผลกระทบจากแต่ละคำสั่งในภาษา (คุณอาจสงสัยในภาษาที่คุณเขียนล่าม แต่ฉันจะแกล้งคุณไม่ได้)
• สัจพจน์เชิงสัจพจน์ : ที่นี่แต่ละประเภทคำสั่งมาพร้อมกับสคีสัจพจน์ ดังนั้นเมื่อใดก็ตามที่มีการใช้ข้อความเฉพาะประเภทนั้นจะแปลว่าสามารถใช้สัจพจน์บางอย่างได้ ตัวอย่างเช่นการกำหนดมาพร้อมกับสคี{ P [ x / e ] ${\bf x}:={\bf e}$ ; การมอบหมายโดยเฉพาะ x : = x + 1มาพร้อมกับสัจพจน์ { x + 1 = 1 $\{P[{\bf x}/{\bf e}]\}\,{\bf x}:={\bf e}\,\{P\}$$x:=x+1$ถ้าเรายกตัวอย่างสคีกับ P = ( x = 1 )$\{x+1=1\}\,x:=x+1\,\{x=1\}$$P=(x=1)$

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

• Necula ลีหลักฐาน Carrying รหัส 1996

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

โดยสรุปฉันคิดได้สามเหตุผลที่นำไปสู่คำถามของคุณ:

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

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

วิธีหนึ่งในการลดช่องว่างระหว่างโปรแกรมและข้อมูลจำเพาะคือใช้ภาษาที่มีความหมายเป็นทางการ ตัวอย่างที่น่าสนใจที่นี่จะเป็นEsterel ลองดูที่หน้าเว็บของGérard Berry เพื่อพูดถึงสิ่งที่น่าสนใจเกี่ยวกับงานของเขาที่นำวิธีการที่เป็นทางการมาสู่โลกแห่งความเป็นจริง http://www-sop.inria.fr/members/Gerard.Berry/

ป.ล. เคยอยู่บนแอร์บัส? คุณบินด้วยวิธีการทางการ!

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

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

• ระบบสำรองที่ผิดพลาด / ผิดพลาด นี่เป็นการศึกษาที่กว้างขวาง ความผิดพลาดของความผิดพลาดและความซ้ำซ้อนสามารถออกแบบได้ในหลายชั้นของระบบ เช่นเราเตอร์เซิร์ฟเวอร์ดิสก์ไดรฟ์ ฯลฯ

• การทดสอบ ทุกประเภท - การทดสอบหน่วยการทดสอบการรวมการทดสอบการยอมรับของผู้ใช้การทดสอบการถดถอย ฯลฯ

• ปัจจุบันการทดสอบอัตโนมัติผ่านชุดทดสอบที่สามารถทำงานแบบอัตโนมัติได้นั้นมีการพัฒนา / สำคัญขึ้น ชุดทดสอบที่ใช้งานมักจะมาพร้อมกับเครื่องมือสร้าง

• แนวคิดที่สำคัญในการทดสอบคือครอบคลุมรหัส นั่นคือการใช้รหัสใดในการทดสอบ การทดสอบไม่สามารถหาข้อบกพร่องในรหัสที่ไม่ได้ "สัมผัส" โดยการทดสอบ

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

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

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

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

• หนึ่งสามารถดำเนินการไปกับการทดสอบ! มีปัญหากับการทดสอบน้อยหรือมากเกินไป มี "จุดหวาน" ไม่สามารถสร้างซอฟต์แวร์ได้สำเร็จในระดับสุดยอด

• ใช้เครื่องมือพื้นฐานทั้งหมดในวิธีที่มีประสิทธิภาพที่สุด debuggers, profilers รหัส, เครื่องมือทดสอบการครอบคลุมโค้ด, ระบบติดตามข้อบกพร่อง ฯลฯ ! ไม่จำเป็นต้องผูกมัดกับการแก้ไข แต่ติดตามแม้แต่ข้อบกพร่องที่เล็กที่สุดในซอฟต์แวร์การติดตาม

• การใช้ SCM อย่างระมัดระวังการจัดการซอร์สโค้ดและเทคนิคการแยกเป็นสิ่งสำคัญในการหลีกเลี่ยงการถดถอยการแยกและการแก้ไขความคืบหน้า ฯลฯ

• การเขียนโปรแกรม N-version : การปฏิบัติที่ใช้บ่อยในการพัฒนาซอฟต์แวร์ Mission Critical สถานที่ตั้งของการปฏิบัตินี้คือโปรแกรมที่พัฒนาขึ้นโดยอิสระ N ไม่น่าจะมีข้อผิดพลาดทั่วไป / ข้อผิดพลาดเดียวกัน นี้ได้รับการวิพากษ์วิจารณ์ในไม่กี่เอกสาร อย่างไรก็ตาม NVPเป็นแนวปฏิบัติไม่ใช่แนวคิดเชิงทฤษฎี

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

มันจะช่วยได้ถ้า Team B มีพื้นฐานด้านวิศวกรรมซอฟต์แวร์ที่ดีเช่นตัวมันเองสามารถเขียนโค้ดเทียม / การทดสอบแบบเป็นโปรแกรมและอื่น ๆ ในกรณีนั้นทีม B มีระดับทรัพยากรเกือบเท่ากันกับทีม A ในทางกลับกันวิธีการนี้มีราคาแพงเนื่องจากสามารถสร้างค่าใช้จ่ายในการสร้างซอฟต์แวร์ได้เกือบสองเท่า โดยทั่วไปแล้วจะมีทีมงาน QA ที่เล็กกว่าเมื่อเปรียบเทียบกับทีมพัฒนา

วิธีการแบบเก่า (แต่ยังคงใช้ในบางแอปพลิเคชัน) คือการเขียนโปรแกรม N-version

จาก Wikipedia:

การเขียนโปรแกรม N-version ( NVP ) หรือที่เรียกว่าการเขียนโปรแกรมแบบหลายตัวแปรเป็นวิธีการหรือกระบวนการในวิศวกรรมซอฟต์แวร์ที่มีโปรแกรมที่เทียบเท่าหลายหน้าที่สร้างขึ้นอย่างอิสระจากข้อกำหนดเริ่มต้นเดียวกัน แนวคิดของการเขียนโปรแกรม N-version ได้รับการแนะนำในปี 1977 โดย Liming Chen และ Algirdas Avizienis ด้วยการคาดเดาจากส่วนกลางว่า "ความเป็นอิสระของความพยายามในการเขียนโปรแกรมจะช่วยลดความน่าจะเป็นของความผิดพลาดของซอฟต์แวร์ที่เหมือนกัน ของ NVP คือการปรับปรุงความน่าเชื่อถือของการดำเนินงานซอฟต์แวร์โดยการสร้างความทนทานต่อข้อบกพร่องหรือความซ้ำซ้อน
....

ดูตัวอย่าง: " ความท้าทายในการสร้างความผิดพลาด - ระบบควบคุมการบินอดทนสำหรับอากาศยานพลเรือน "

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

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

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

การทดสอบเพียงอย่างเดียวไม่ใช่วิธีการแบบเป็นทางการซึ่งช่วยปรับปรุงความน่าเชื่อถือ แต่ไม่ตรวจสอบความถูกต้อง

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

เมื่อมาถึงจุดของการแสวงหาหลังจากที่พยายามเครื่องมือบางอย่าง (Z, B, VHDL และเอสเทล) นี่ผมใช้TLA + นี่คือตัวแปรของตรรกะเชิงเวลาด้วยเครื่องมือซอฟต์แวร์สำหรับการตรวจสอบแบบจำลองและการพิสูจน์ทางกลไก ฉันคิดว่าฉันเลือกวิธีนี้เพราะแอลแลมพอร์ตอยู่ข้างหลังไวยากรณ์นั้นเรียบง่ายมีตัวอย่างมากมายมีชุมชนที่ดูแลมันและภาษาและเครื่องมือมีเอกสารค่อนข้างดี

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

โดยสรุปฉันคิดว่าคำอุปมาต่อไปนี้ (จาก Lamport) มีประสิทธิภาพมาก: "คุณคาดหวังว่าบ้านจะสร้างโดยอัตโนมัติจากพิมพ์เขียวหรือไม่คุณจะซื้อบ้านที่ยังไม่ได้สร้างและมันไม่มีพิมพ์เขียว" .

ในระหว่างการสืบเสาะนี้ฉันได้พบทรัพยากรที่เป็นประโยชน์ต่อไปนี้:

• ข้อกำหนดคุณลักษณะซอฟต์แวร์ หนังสือเล่มนี้ให้ภาพรวมคร่าวๆของวิธีการและเครื่องมือที่มีอยู่ มีคำอธิบายพื้นฐานและตัวอย่างของ Z, SDL, TLA +, Petri Nets, Coq และอื่น ๆ
• ถ้าคุณคิดว่า TLA + เหมาะกับความต้องการของคุณผมขอแนะนำหนังสือการระบุระบบ คุณสามารถรับหนังสือได้ฟรีและมันมาพร้อมกับตัวอย่างเพื่อเล่นกับ :)
• เมื่อเร็ว ๆ นี้ผมอ่านคู่ของบทความที่เกี่ยวข้องที่ให้สองมุมมองที่แตกต่างกับรัฐของศิลปะในวิธีการอย่างเป็นทางการไปนี้: กรณีสำหรับวิธีการทางการและอย่างเป็นทางการคณิตศาสตร์ที่ตรวจสอบแล้ว

โชคดี!

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

สร้างซอฟต์แวร์ที่มีความสำคัญต่อภารกิจอย่างไร

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

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

อัลกอริทึมที่รับรองจะมีประโยชน์เมื่อสร้างซอฟต์แวร์ที่มีความสำคัญต่อภารกิจ

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

อ่านเพิ่มเติมในกระดาษสำรวจนี้อัลกอริทึมการรับรองโดย McConnell, RM และ Mehlhorn, K. และ Naher, S. และ Schweitzer, P.

แต่วิธีการตรวจสอบว่าซอฟต์แวร์ (ไม่เพียง แต่สเปค) ถูกต้องแน่นอน?

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

ในทางทฤษฎีการพูดถ้าการทดสอบหน่วยของคุณมีความคุ้มครองรหัส 100% (เช่นทุกวิธีเดียวในการทดสอบรหัสของคุณ) ซอฟต์แวร์ของคุณควรถูกต้องหากการทดสอบตัวเองถูกต้องและสมจริง