เครื่องมือแก้ไขของ Downcodes จะแนะนำให้คุณรู้จักกับ BugFree ซึ่งเป็นเครื่องมือการจัดการข้อบกพร่องบนเว็บที่ได้รับการปรับปรุง ใช้ปรัชญาการพัฒนาซอฟต์แวร์ของ Microsoft และนำเสนอในรูปแบบของโค้ดโอเพ่นซอร์สฟรี เป็นหนึ่งในซอฟต์แวร์ฟรีไม่กี่ตัวที่ประสบความสำเร็จในการ "โคลน" เครื่องมือจัดการข้อบกพร่องภายในของ Microsoft Product Studio (เดิมเรียกว่า Raid) บทความนี้จะเจาะลึกเกี่ยวกับการแนะนำ BugFree กระบวนการเติมโค้ดให้สมบูรณ์ และวิธีจัดการกับข้อบกพร่องของซอฟต์แวร์ ฉันหวังว่าสิ่งนี้จะช่วยให้คุณเข้าใจและใช้เครื่องมือนี้ได้ดีขึ้น
BugFree เป็นเครื่องมือการจัดการข้อบกพร่องแบบโอเพ่นซอร์สที่มีประสิทธิภาพบนเว็บซึ่งใช้ปรัชญาการพัฒนาซอฟต์แวร์ของ Microsoft ปัจจุบันเป็นหนึ่งในซอฟต์แวร์ฟรีไม่กี่ตัวที่ "โคลน" เครื่องมือจัดการข้อบกพร่องภายในของ Microsoft Product Stuido (เดิมเรียกว่า Raid)
BugFree เป็นเครื่องมือการจัดการข้อบกพร่องแบบโอเพ่นซอร์สที่มีประสิทธิภาพบนเว็บซึ่งใช้ปรัชญาการพัฒนาซอฟต์แวร์ของ Microsoft ปัจจุบันเป็นหนึ่งในซอฟต์แวร์ฟรีไม่กี่ตัวที่ "โคลน" เครื่องมือจัดการข้อบกพร่องภายในของ Microsoft Product Stuido (เดิมเรียกว่า Raid)
BugFree เขียนด้วย PHP+MySQL และสามารถทำงานได้ทั้งบนแพลตฟอร์ม Linux และ Windows แนวคิดการออกแบบที่รวมอยู่ใน BugFree 2.0 ได้แก่:
– รหัส: โปรแกรมเป็นการดำเนินการ (การทำแผนที่) ของเอกสารข้อกำหนดการออกแบบข้อกำหนด (Spec)
– กรณีทดสอบ: เป็นการใช้งาน (การทำแผนที่) ของ Spec ด้วย แต่จากมุมมองของการทดสอบ
– ผลการทดสอบ: ใช้ Test Case (test mapping) เพื่อตรวจสอบ Code (development mapping)
– ข้อผิดพลาด: ความไม่สอดคล้องกันระหว่างการแมปทั้งสองอาจเป็นข้อผิดพลาด (โค้ดเบี่ยงเบนไปจาก Spec)
ด้วยวิธีนี้ ตั้งแต่กรณีทดสอบ (กรณีทดสอบ) ไปจนถึงผลการทดสอบ (ผลการทดสอบ) ไปจนถึงข้อบกพร่อง (ข้อบกพร่อง) ทั้งสามอย่างจะรวมกันแบบออร์แกนิก
BugFree ใน "Digital Nervous System" เขียนด้วยโอเพ่นซอร์ส PHP+MySQL และทำงานบนเบราว์เซอร์ ฉันไม่เคยมีประสบการณ์ในการพัฒนา Linux+Apache+MySQL+PHP มาก่อน แต่ฉันโชคดีที่ได้รับสมัครโปรแกรมเมอร์เว็บที่ยอดเยี่ยมสองคนที่สามารถสร้างระบบดังกล่าวได้ในเวลาเพียงสองเดือน ในบรรดานั้น BugFree ได้รับการพัฒนาโดยเพื่อนร่วมงานของฉัน Wang Chunsheng เขาใช้เวลาเขียนโค้ดไม่ถึงหนึ่งเดือน ซึ่งทำให้ฉันรู้สึกประหลาดใจและทำให้ฉันตระหนักถึงเสน่ห์ของการพัฒนาเว็บบน Linux
หลังจากที่เราทดสอบมาเดือนกว่าก็สามารถนำไปใช้งานจริงได้ BugFree กลายเป็นเครื่องมือที่สำคัญที่สุดในการทำงานประจำวันของเรา พนักงานทุกคนยังคุ้นเคยกับการใช้ Bug เพื่อบันทึกและติดตามสิ่งต่าง ๆ ไม่เพียงแต่ข้อบกพร่องในโค้ดเท่านั้นที่อาจถูกบั๊ก แต่ยังมีข้อกำหนดใหม่ การเปลี่ยนแปลงการออกแบบ ฯลฯ สามารถใช้ข้อบกพร่องนี้ได้ ระบบการจัดการ ในความเป็นจริง Bugs ไม่เพียงแต่สามารถใช้เพื่อบันทึกข้อบกพร่องในซอฟต์แวร์เท่านั้น แต่ยังสามารถใช้เพื่อติดตามกิจวัตรประจำวันของบริษัทอีกด้วย ตัวอย่างเช่น ก่อนที่จะสร้างระบบการชำระเงินคืนแบบออนไลน์ของบริษัท เราใช้ BugFree เพื่อจัดการการชำระเงินคืน แม้ว่าเพื่อนร่วมงานจะให้ข้อผิดพลาดนี้แก่ฉัน: เดสก์ท็อปของคุณยุ่งเกินไป โปรดจัดระเบียบให้เรียบร้อย :-)
อ่านเพิ่มเติม:
โดยปกติแล้วเมื่อผู้คนพบข้อบกพร่องของซอฟต์แวร์ พวกเขาจะจำแนกข้อบกพร่องของซอฟต์แวร์ด้วยวิธีเดียวเท่านั้น ซึ่งก็คือระดับความรุนแรง เช่นเราเจอสถานการณ์ดังนี้ ผู้ทดสอบพบว่ามีฟังก์ชันที่ต้องเพิ่ม ในกรณีนี้ เขาบอกโปรแกรมเมอร์และโปรแกรมเมอร์บอกว่าไม่มีเวลาหรือไม่จำเป็น สถานการณ์นี้จะทำให้เกิดความขัดแย้งระหว่างทั้งสอง หากคุณทำวาฟเฟิล คุณจะไม่ทราบผลลัพธ์สุดท้าย ซึ่งจะช่วยลดความกระตือรือร้นของผู้ทดสอบในครั้งต่อไปพวกเขาจะไม่พิจารณาปัญหาของผลิตภัณฑ์ให้มากที่สุดเท่าที่จะเป็นไปได้ สามารถวิ่งได้ ที่จริงแล้ว สถานการณ์นี้สามารถแก้ไขได้ ด้านล่างนี้ ผมจะพูดถึงแนวคิดการจำแนกข้อบกพร่องของซอฟต์แวร์ใหม่เพื่อแก้ไขปัญหานี้อย่างมีประสิทธิภาพ
ข้อบกพร่องของซอฟต์แวร์ไม่เพียงแต่เป็นข้อผิดพลาดร้ายแรงเท่านั้น แต่ยังรวมถึงฟังก์ชันที่ไม่ได้ใช้งานด้วย ณ จุดนี้ ทุกคนอาจเข้าใจว่าความต้องการยังไม่ได้รับการพิจารณา แต่ความต้องการจะไม่สมบูรณ์แบบในครั้งเดียว และต้องใช้ความพยายามร่วมกันของทุกคนในการปรับปรุงอย่างต่อเนื่อง แล้วเราจะนำคำแนะนำที่ดีของผู้ทดสอบไปใช้อย่างมีประสิทธิภาพได้อย่างไร นี่คือสิ่งที่ผมอยากจะพูดต่อไป มีอีกวิธีหนึ่งในการจำแนกข้อบกพร่องของซอฟต์แวร์ ตามเนื้อหาข้อบกพร่อง ส่วนใหญ่จะแบ่งออกเป็นข้อบกพร่องด้านความต้องการและข้อบกพร่องของโปรแกรม เราทุกคนรู้ดีว่าข้อบกพร่องของโปรแกรมได้รับการจัดการโดยนักพัฒนาที่เกี่ยวข้อง ต่อไปนี้จะกล่าวถึงข้อบกพร่องของความต้องการเป็นหลัก เมื่อพิจารณาจากชื่อแล้ว ข้อบกพร่องของความต้องการจะต้องได้รับการจัดการโดยบุคลากรด้านความต้องการ จะจัดการกับมันอย่างไรและจะมีประสิทธิภาพในกระบวนการนี้ได้อย่างไร? ในเวลานี้ ผู้ทดสอบของเราจะส่งข้อบกพร่องด้านข้อกำหนดไม่ใช่ให้กับโปรแกรมเมอร์ แต่จะส่งไปยังนักวิเคราะห์ข้อกำหนดเพื่อดำเนินการ อย่างไรก็ตาม สิ่งที่ฉันต้องการเน้นย้ำในที่นี้คือการวางตำแหน่งของจุดบกพร่องด้านความต้องการ หากมีการกล่าวถึงจุดบกพร่องนี้อย่างชัดเจนในข้อกำหนดข้อกำหนดของซอฟต์แวร์ ก็เป็นไปไม่ได้ที่จะระบุจุดบกพร่องดังกล่าวว่าเป็นจุดบกพร่องด้านข้อกำหนด ข้อบกพร่อง การส่งจะถูกจัดการโดยโปรแกรมเมอร์ แต่หากข้อกำหนดข้อกำหนดไม่ได้ระบุไว้อย่างชัดเจน เราก็สามารถระบุได้ว่าข้อกำหนดนั้นเป็นข้อบกพร่องของข้อกำหนด
ข้างต้นนี้เป็นเนื้อหาเกี่ยวกับ bugfree ฉันหวังว่ามันจะเป็นประโยชน์กับทุกคน
ฉันหวังว่าการแนะนำ BugFree นี้จะเป็นประโยชน์กับทุกคน บรรณาธิการของ Downcodes จะนำบทความทางเทคนิคที่เป็นประโยชน์เพิ่มเติมมาให้คุณต่อไป หากคุณมีคำถามหรือข้อเสนอแนะ กรุณาฝากข้อความไว้!