การจัดส่งต่อเนื่องสามารถทำงานในทางปฏิบัติได้อย่างไร

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

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

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

ประสบการณ์การพัฒนาซอฟต์แวร์หลายปีของฉันแนะนำว่าในทางปฏิบัติมันใช้งานไม่ได้

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

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

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

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

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

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

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

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

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

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

การรวมเข้ากับ / การทดสอบการทำงานเสริมการทดสอบหน่วย แต่สิ่งเหล่านี้ใช้เวลานานในการรัน (หากคุณไม่กำหนดค่าเริ่มต้นสภาพแวดล้อมการทดสอบจะไม่สอดคล้องกัน)

หนึ่งในผลิตภัณฑ์ที่ฉันเคยทำงานมีชุดการทดสอบการตอบรับถึง 3,500 แบบซึ่งใช้เวลา 18 ชั่วโมงในการทำงาน เราเรียกใช้มันขนานกันบนตาราง 70 กล่องและรับผลตอบรับใน 45m ยังคงนานเกินกว่าอุดมคติจริงๆซึ่งเป็นเหตุผลที่เราเรียกใช้เป็นขั้นตอนที่สองในท่อหลังจากการทดสอบหน่วยทำงานในไม่กี่นาทีดังนั้นเราจึงไม่เสียทรัพยากรของเราในงานสร้างที่เราไม่มีระดับพื้นฐาน มั่นใจใน

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

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

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

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

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

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

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

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

คุณไม่ต้องการความคุ้มครอง 100% คุณต้องการความมั่นใจในระบบของคุณมากพอที่การเปลี่ยนแปลงในที่เดียวจะไม่ทำลายสิ่งที่คุณเคยพิสูจน์มาก่อน

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

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

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

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

คุณสามารถใช้เวลาในการสร้างวัตถุจำลองซึ่งอาจไม่สอดคล้องกับการใช้งานจริง

I / O ของวัตถุจำลองควรตรงกับสิ่งที่คาดหวังอย่างไรก็ตาม เกิดอะไรขึ้นข้างในมันไม่สำคัญ

การรวมเข้ากับ / การทดสอบการทำงานเสริมการทดสอบหน่วย แต่สิ่งเหล่านี้ใช้เวลานานในการรัน (หากคุณไม่กำหนดค่าเริ่มต้นสภาพแวดล้อมการทดสอบจะไม่สอดคล้องกัน)

สิ่งเหล่านี้ไม่ควรเรียกใช้ตลอดเวลา เพียงเท่าที่จำเป็น

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

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

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

ไม่แน่ใจว่าคุณมาที่นี่หรือไม่ หากมีข้อบกพร่องเขียนการทดสอบเพื่อแสดงว่ามีอยู่แล้วแก้ไข

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

ความจริงแล้วซอฟแวร์ทั้งหมดนั้นมีการส่งมอบอย่างต่อเนื่อง! สิ่งที่สำคัญที่สุดคือออกไปนอกประตู! ให้ผู้ใช้ของคุณใช้งานและจัดลำดับความสำคัญของคำขอคุณลักษณะและการบีบอัดบั๊กหลังจากนั้น

"เรือศิลปินจริง"
- Steve Jobs