บริษัท ขนาดใหญ่ของนักพัฒนาซอฟต์แวร์ตรวจสอบข้อบกพร่องในโปรแกรมของพวกเขาอย่างไร

ฉันสงสัยว่า บริษัท ผู้พัฒนาซอฟต์แวร์รายใหญ่ตรวจสอบข้อบกพร่องในโปรแกรมของพวกเขาอย่างไร

พวกเขาแค่ทดสอบในคอมพิวเตอร์หลายเครื่องหรือไม่

นี่คือเทคนิคบางส่วนที่ Google ใช้

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

ฉันได้จัดอันดับสิ่งเหล่านี้ในสิ่งที่ฉันสงสัยว่ามีประสิทธิภาพลดลงในการจับข้อบกพร่อง

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

หลายครั้งนักพัฒนาจะพบข้อบกพร่องในระหว่างกระบวนการพัฒนา นอกจากนี้ลูกค้ามักเป็นคนแรกที่พบข้อบกพร่อง

บริษัท ขนาดเล็กเช่นเดียวกับที่ฉันกำลังทำงานให้ใช้แบบทดสอบ Agile

ฉันจะบอกว่ามันเกี่ยวกับวุฒิภาวะของ บริษัทไม่ใช่ขนาด :) มี บริษัท ขนาดใหญ่ที่มีแนวทางการพัฒนาที่ไม่ดีและ บริษัท ขนาดเล็กที่ตกเลือด

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

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

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

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

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

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

การทดสอบกอริลลา: (ด้วยตนเองเท่านั้น) นี่คือการทดสอบเมื่อมนุษย์ที่ฉลาดหลักแหลมพยายามทำลายแอปพลิเคชัน

การทดสอบประสิทธิภาพมีเป้าหมายเพื่อให้แน่ใจว่าประสิทธิภาพเป็นที่ยอมรับและไม่ลดลงเมื่อเวลาผ่านไป โดยอัตโนมัติ

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

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

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

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

จับคู่การเขียนโปรแกรม:นักพัฒนาสองคนทำงานร่วมกันเพื่อมอบฟังก์ชันการทำงาน "คู่ที่เหนียวกว่าดีกว่าผลรวมของส่วนต่าง ๆ "

ที่สำคัญที่สุดที่จะไปคือระบบอัตโนมัติและบูรณาการอย่างต่อเนื่อง

ขึ้นอยู่กับ บริษัท และผลิตภัณฑ์ที่พัฒนาขึ้น

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

ประการที่สองหลาย บริษัท มีแผนกควบคุมคุณภาพที่รับผิดชอบในการตรวจสอบพฤติกรรม นี่เป็นเรื่องธรรมดาโดยเฉพาะในด้านการเงิน (ที่ความผิดพลาดอาจมีราคาแพงและกฎการตรวจสอบมีความซับซ้อน) แต่ก็มีอยู่ใน บริษัท ที่ขายผลิตภัณฑ์ให้กับผู้ใช้ซึ่งการเรียกคืนอาจมีราคาแพง (เช่น Intel, Microsoft เป็นต้น)

ประการที่สามเมื่อใดก็ตามที่ บริษัท ที่เป็นไปได้ทำ Dogfooding (มีผู้ใช้ของตนเองใช้ผลิตภัณฑ์ภายใน) จากนั้นปล่อย betas ที่ จำกัด มีข้อผิดพลาดมากมายในช่วงนี้ ตัวอย่างเช่นผู้ที่ทำงานที่ Microsoft ใช้ Office ภายในรุ่นที่ใหม่กว่าและ Windows และ DevStudio มากกว่าที่คุณมีอยู่ภายนอก จากนั้นกลุ่มผู้ใช้ที่ จำกัด หรือ บริษัท ที่ทำสัญญาจะได้รับตัวอย่าง ในทำนองเดียวกันที่ Google เราใช้ GMail และเอกสารภายในเวอร์ชันก่อนปล่อย บริษัท เกมจัด betas แบบเปิดเพื่อทดสอบผลิตภัณฑ์และโหลดบนเซิร์ฟเวอร์ ฯลฯ

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

การตั้งค่าพื้นฐาน: ซอฟต์แวร์แบ็กเอนด์สำหรับการประมวลผลข้อมูลจำนวนมากด้วย BizTalk

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

ขั้นต่อไปคือการสร้าง Virtual PC รายสัปดาห์ซึ่งผู้ทดสอบใช้ชุดของการทดสอบแบบ end-to-end อัตโนมัติส่วนใหญ่เกี่ยวกับ data-flow ตามเอกสารข้อกำหนดสำหรับแต่ละองค์ประกอบ

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

จากนั้นพีซีเสมือนถูกรวมเข้ากับส่วนประกอบอื่น ๆ ของระบบ (เช่นส่วนใหญ่เสมือน) จากแผนกอื่น ๆ ไปยังวงจรการทดสอบแบบรวมตามการทดสอบแบบ end-to-end จากผู้ใช้ที่ป้อนข้อมูลไปยังจุดสิ้นสุดของการไหลของข้อมูล

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

หลังจากการติดตั้งในสภาพแวดล้อมที่เหมือนการผลิตเราทำการทดสอบโหลดและความเครียดเพื่อทดสอบความเสถียรโดยรวม (ไม่ใช่สิ่งที่จะต้องดำเนินการเบา ๆ เมื่อคุณรันบนเซิร์ฟเวอร์ 10 BizTalk เซิร์ฟเวอร์ SQL 8 ตัวและฮาร์ดแวร์พิเศษอื่น ๆ เช่นตัวเร่ง XML และไฟล์เก็บถาวรที่เฉพาะเจาะจง - ทุกคลัสเตอร์แน่นอน)

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

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

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

ความต้องการเหล่านั้นจะต้องมีการแมปเข้าไปในแต่ละเรื่อง / ข้อกำหนดที่จะเร็ว ๆ นี้ (ในช่วงการก่อสร้าง) จะดำเนินการในรหัสที่มา

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

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

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

ฉันหวังว่าจะช่วยให้คุณเข้าใจ (โดยประมาณ) กระบวนการโดยรวม

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