เรียนรู้ที่จะตรวจสอบข้อบกพร่อง [ปิด]

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

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

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

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

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

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

ฉันต้องทำอะไรเพื่อช่วยให้จินตนาการที่ จำกัด ของฉันเกิดขึ้นพร้อมกับวิธีที่โครงงานของฉันอาจแตกได้

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

คุณควรเข้าสู่กระบวนการแก้ไขจุดบกพร่องด้วยข้อมูลชิ้นต่อไปนี้:

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

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

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

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

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

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

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

ในระดับหนึ่งมันก็เหมือนกับการสืบสวนคดีอาชญากรรมหรือปริศนาที่ไม่น่าเชื่อ

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

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

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

• ฉันจะหลีกเลี่ยงการเสียเวลานี้ได้อย่างไร
• สิ่งที่ฉันมองข้ามในตอนแรกและทำไม?
• ฉันใช้สมมติฐานที่ไม่ผ่านการตรวจสอบและ / หรือผิดอะไร

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

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

ฉันต้องทำอะไรเพื่อช่วยให้จินตนาการที่ จำกัด ของฉันเกิดขึ้นพร้อมกับวิธีที่โครงงานของฉันอาจแตกได้

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

ที่จะให้ภาพรวมที่ดีของสิ่งต่าง ๆ ที่ผิดพลาดในผลิตภัณฑ์ของคุณ หากคุณสนใจโดยทั่วไปในสิ่งที่ผิดพลาดในซอฟต์แวร์ทุกประเภทโดยเฉพาะอย่างยิ่งการเน้นข้อบกพร่องด้านความปลอดภัยฉันขอแนะนำให้คุณอ่านรายการ CWE: http://cwe.mitre.org/data/index.html

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

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

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

บางคนสนับสนุนการทดสอบเหล่านี้เพื่อให้มีการประกาศข้อกำหนดที่ชัดเจนซึ่งจะต้องเขียนก่อนรหัสเช่น Test First (หรือ Test Driven Development)

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

เมื่อคุณพบข้อกำหนด - ต้องแข็งแกร่ง / ต้องปลอดภัยจากนั้นลองขุดลึกลงไปและค้นหาว่าจะต้องมีความปลอดภัยมากน้อยเพียงใดหรือยอมรับได้ว่ามีความล้มเหลวมากแค่ไหนมีข้อ จำกัด ไม่ใช่คนจำนวนมากที่มีหลักฐาน NSA ระดับความปลอดภัยเป็นข้อกำหนดสำหรับแอปพลิเคชันหรือต้องการชำระค่านั้น ยิ่งคุณขุดให้ชัดเจนเท่าไรมันก็จะเป็นการป้องกันความปลอดภัยประเภทใดที่คุณต้องปกป้องหรือใช้งานง่าย ๆ ที่คุณตั้งเป้า ความรู้เกี่ยวกับโดเมนบางส่วนนั้นมีประโยชน์ในด้านความปลอดภัยการออกแบบประสิทธิภาพ ฯลฯ ซึ่งเป็นที่ที่คุณถามคำถามเพิ่มเติมจากผู้เชี่ยวชาญที่คุณสามารถพบได้ในทีมของคุณหรือที่นี่ใน SE หรือ google / books