คุณวัดการทดสอบการรวมระบบของคุณอย่างไร


21

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

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

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

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

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

เล็กน้อยเกี่ยวกับสแต็คเทคโนโลยีของเรา ขณะนี้เรากำลังทดสอบสภาพแวดล้อมการจำลอง (CPU และหน่วยความจำมาก) เพื่อทำการทดสอบของเราตั้งแต่ต้นจนจบ ซึ่งประกอบด้วยบริการเว็บ Azure REST ซึ่งแสดงแบ็กเอนด์ noSql (ATS) เรากำลังจำลองสภาพแวดล้อมการผลิตของเราโดยทำงานใน Azure desktop Emulator + IISExpress เรา จำกัด หนึ่งตัวจำลองและหนึ่งที่เก็บแบ็คเอนด์โลคัลต่อหนึ่งเครื่อง dev

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

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

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

ดังนั้นฉันกำลังตรวจสอบว่าเราสามารถใช้เทคนิคและกลยุทธ์ใดในการลดเวลาการทดสอบลงอย่างมาก

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

ฉันต้องการดูว่ากลยุทธ์ (และเครื่องมือ) อื่น ๆ ที่ใช้ในพื้นที่นี้คืออะไร

(ฉันต้องเชื่อว่าคนอื่นอาจเห็นความยากลำบากเช่นนี้โดยใช้ชุดเทคโนโลยีบางอย่าง))

[อัพเดท: 12/16/2016: เราสิ้นสุดการลงทุนมากขึ้นในการทดสอบแบบขนานของ CI สำหรับการอภิปรายผล: http://www.mindkin.co.nz/blog/2015/12/16/16-jobs]


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

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

คำตอบ:


9

ฉันทำงานในสถานที่ที่ใช้เวลา 5 ชั่วโมง (30 เครื่อง) เพื่อทำการทดสอบการรวมระบบ ฉันปรับโครงสร้าง codebase อีกครั้งและทำการทดสอบหน่วยแทนสิ่งใหม่ การทดสอบหน่วยใช้เวลา 30 วินาที (ในเครื่อง 1 เครื่อง) โอ้และแมลงก็ลดลงเช่นกัน และเวลาในการพัฒนาเนื่องจากเรารู้ว่าอะไรที่ขัดกับการทดสอบที่ละเอียด

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

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


ฉันเห็นด้วย. การทดสอบหน่วยนั้นสามารถปรับขนาดได้มากกว่าและสนับสนุนลูปการตอบกลับที่เร็วขึ้น
แบรนดอน

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

1
เพิ่มความชัดเจนให้กับโพสต์เพื่อระบุอย่างชัดเจนว่าเราสร้างผลิตภัณฑ์นี้โดยใช้ TDD ดังนั้นเราจึงมีการทดสอบหลายพันหน่วยซึ่งได้รับการสนับสนุนโดยการทดสอบการรวมที่เป็นปัญหา .
Jezz Santos

8

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

เมื่อคุณทำงานในระบบคลาวด์แล้วดูเหมือนว่าฉันจะอยู่ในตำแหน่งที่สำคัญในการขยายการทดสอบของคุณในหลาย ๆ เครื่อง

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


ความคิดดี! ดูกลยุทธ์แบบนั้น แต่ด้วยเครื่องมือบางอย่างที่ช่วยกระจายการทดสอบ
Jezz Santos

4

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

ฉันประสบปัญหาที่คล้ายกัน แต่ไม่ได้อยู่ในการทดสอบการรวมระบบของเรา (ที่ทำงานในไม่กี่นาที) แต่มันเป็นเพียงการสร้างของเรา: รหัสฐาน C ขนาดใหญ่อาจใช้เวลาหลายชั่วโมงในการสร้าง

สิ่งที่ฉันเห็นว่าสิ้นเปลืองอย่างยิ่งคือความจริงที่ว่าเรากำลังสร้างสิ่งใหม่ทั้งหมดตั้งแต่เริ่มต้น (ประมาณ 20,000 ซอร์สไฟล์ / ชุดคอมไพล์) แม้ว่าไฟล์ต้นฉบับจะมีการเปลี่ยนแปลงเพียงเล็กน้อยเท่านั้นและใช้เวลาหลายชั่วโมงในการเปลี่ยนแปลง ที่เลวร้ายที่สุด.

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

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

โครงการด้านในขณะที่รอรวมในภายหลัง

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

การแยกไฟล์ต้นฉบับด้วยตนเองเพื่อคิดออกว่าจะสร้างใหม่ / รันใหม่อีกครั้ง

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

กลยุทธ์เดียวกันควรใช้กับการทดสอบการรวมเข้าด้วยกัน เพียงแค่แยกวิเคราะห์ไฟล์ซอร์สแบบซ้ำ ๆ เพื่อหาว่าไฟล์ใดที่การทดสอบการรวมขึ้นอยู่กับ (เช่น: importใน Java,#includeใน C หรือ C ++) ทางฝั่งเซิร์ฟเวอร์และไฟล์ที่รวม / นำเข้าจากไฟล์เหล่านั้นและอื่น ๆ การสร้างกราฟไฟล์พึ่งพา / นำเข้าเต็มรูปแบบสำหรับระบบ ต่างจากบิลด์ที่แยกวิเคราะห์ซึ่งเป็น DAG กราฟควรถูกยกเลิกการทำเส้นทางเนื่องจากมันสนใจไฟล์ใด ๆ ที่เปลี่ยนแปลงซึ่งมีรหัสซึ่งสามารถดำเนินการทางอ้อมได้ เรียกใช้การทดสอบการรวมอีกครั้งเฉพาะไฟล์ใด ๆ ในกราฟสำหรับการทดสอบการรวมที่น่าสนใจที่มีการเปลี่ยนแปลง แม้แต่สำหรับโค้ดหลายล้านบรรทัดมันง่ายในการแยกวิเคราะห์ในเวลาน้อยกว่าหนึ่งนาที หากคุณมีไฟล์อื่นนอกเหนือจากซอร์สโค้ดซึ่งอาจส่งผลกระทบต่อการทดสอบการรวมเช่นไฟล์เนื้อหาบางทีคุณสามารถเขียนข้อมูลเมตาลงในความคิดเห็นในซอร์สโค้ดที่ระบุการพึ่งพาเหล่านั้นในการทดสอบการรวมดังนั้นหากไฟล์ภายนอกเหล่านั้นเปลี่ยนแปลง รับการเรียกใช้ใหม่

* เป็นตัวอย่างถ้า test.c มี foo.h ซึ่งรวมอยู่ใน foo.c ด้วยดังนั้นการเปลี่ยนเป็น test.c, foo.h หรือ foo.c ควรทำเครื่องหมายการทดสอบแบบรวมว่าต้องการการเรียกใช้ใหม่

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


3

ดูเหมือนว่าคุณจะมีการทดสอบการรวมระบบมากเกินไป จำพีระมิดทดสอบ การทดสอบการรวมอยู่ในตรงกลาง

เป็นตัวอย่างใช้พื้นที่เก็บข้อมูลด้วยวิธีการset(key,object), get(key). พื้นที่เก็บข้อมูลนี้มีการใช้อย่างกว้างขวางทั่วฐานรหัสของคุณ วิธีการทั้งหมดที่ขึ้นอยู่กับพื้นที่เก็บข้อมูลนี้จะถูกทดสอบด้วยพื้นที่เก็บข้อมูลปลอม ตอนนี้คุณต้องการการทดสอบการรวมสองการทดสอบหนึ่งชุดสำหรับการทดสอบหนึ่งชุด

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

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

เกือบทุกสิ่งทุกอย่างสามารถทดสอบหน่วยกับ stubbed / mocked / faked / in-mem-implementations สำหรับการอ้างอิง


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

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

ฉันอัปเดตคำตอบเพื่อตอบความคิดเห็นของคุณ
Esben Skov Pedersen

2

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

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

ตัวเลือกอื่นที่ควรพิจารณาคือโซลูชันที่พัฒนาขึ้นในปี 2545 เรียกว่า Service Virtualization สิ่งนี้จะสร้างสภาพแวดล้อมเสมือนจำลองการโต้ตอบโมดูลกับทรัพยากรที่มีอยู่เพื่อการทดสอบในองค์กรที่ซับซ้อน DevOps หรือสภาพแวดล้อม Agile

บทความนี้มีประโยชน์ในการทำความเข้าใจเพิ่มเติมเกี่ยวกับวิธีทำการทดสอบการรวมในองค์กร


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

1

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

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

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

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

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


1

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

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

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

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


0

ดูเหมือนว่าฐานรหัสของคุณมีขนาดใหญ่ขึ้นเรื่อย ๆ และการจัดการรหัสบางอย่างจะช่วยได้ เราใช้ Java ดังนั้นต้องขออภัยล่วงหน้าหากฉันสมมติสิ่งนี้

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

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


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

0

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

แทนที่จะส่งการเปลี่ยนแปลงโดยตรงไปยังผู้พัฒนาสาขาส่งพวกเขาไปยังระบบการตรวจสอบอัตโนมัติแบบรวมศูนย์ซึ่งทำการตรวจสอบและ

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

วิธีการดังกล่าวช่วยให้สามารถรวมและทดสอบการเปลี่ยนแปลงที่ส่งหลายรายการพร้อมกันซึ่งอาจเพิ่มความเร็วการตรวจสอบ CI ที่มีประสิทธิภาพหลายครั้ง

ตัวอย่างหนึ่งคือ ระบบ gating ที่ใช้ Gerrit / Zuul ที่ OpenStackใช้

อีกหนึ่งคือApartCI ( ข้อจำกัดความรับผิดชอบ - ฉันเป็นผู้สร้างและเป็นผู้ก่อตั้ง บริษัท ที่เสนอขาย)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.