การเปิดหมายเหตุ
Yvette Nameth (Google)
คําปราศรัยสําคัญเพื่อเปิดงาน
Jürgen Allgayer (Google)
ความท้าทายของ Uber ในการทดสอบหลายแอปพลิเคชัน/หลายอุปกรณ์
Apple Chow (Uber) และ Bian Jiang (Uber)
ไม่นานหลังจากเข้าร่วม Uber ในเดือนมีนาคม 2015 เราได้พบความท้าทายที่ไม่เหมือนใครกับ Uber ขณะตรวจสอบเครื่องมือทดสอบ UI สําหรับแอปพลิเคชันบนอุปกรณ์เคลื่อนที่ของเรา การทดสอบความเรียบร้อยของเราจํานวนมากต้องใช้แอปพลิเคชันไรเดอร์และแอปพลิเคชันฝั่งคนขับเพื่อสื่อสาร/ประสานงานการดําเนินการของแต่ละฝ่ายจึงจะดําเนินการตามสถานการณ์ในการทดสอบได้ตั้งแต่ต้นจนจบ ในการพูดคุยครั้งนี้ เราจะนําเสนอโซลูชันที่ไม่จําเป็นต้องพึ่งพาแพลตฟอร์มต่างๆ ซึ่งเรียกว่า Octopus และอภิปรายถึงวิธีประสานงานกันระหว่างแอปต่างๆ ที่ทํางานบนอุปกรณ์ต่างๆ คุณนําโซลูชันนี้ไปใช้กับการทดสอบที่ต้องใช้การประสานงาน/การสื่อสารในแอปหรืออุปกรณ์ต่างๆ ได้ (เช่น เกมที่มีผู้ใช้หลายคน แอปรับส่งข้อความ/การสื่อสารกับผู้ใช้หลายคน เป็นต้น)
การทดสอบอัตโนมัติที่ได้รับการสนับสนุนจากหุ่นยนต์
Hans Kuosmanen (OptoFidelity) และ Natalia Leinonen (OptoFidelity)
OptoFidelity เป็นบริษัทเทคโนโลยีขั้นสูงจากฟินแลนด์ที่มีประสบการณ์ 10 ปีในการพัฒนาและให้บริการโซลูชันการทํางานอัตโนมัติแบบวิจัยและพัฒนา การบรรยายนี้จะพูดถึงประสบการณ์ของเราและแนวทางในอนาคตของวิธีการทดสอบที่ไม่ก่อให้เกิดความรําคาญที่ใช้ในการทดสอบประสิทธิภาพ UI ของอุปกรณ์เคลื่อนที่ คุณทราบไหมว่าทีม Chrome OS ใช้โซลูชันหุ่นยนต์จาก OptoFidelity ในการวัดเวลาในการตอบสนองจากต้นทางของอุปกรณ์ Android และ Chrome OS
เลื่อยโซ่ไฟฟ้าเพื่อความสนุกและทํากําไร: บทเรียนที่ได้รับจากการทดสอบการผสานรวมข้ามแพลตฟอร์มบนอุปกรณ์เคลื่อนที่
Dan Giovannelli (Google)
การพัฒนาอุปกรณ์เคลื่อนที่เป็นเรื่องยาก การสร้างโครงสร้างพื้นฐานของการทดสอบเป็นเรื่องยาก การทํางานข้ามแพลตฟอร์มเป็นงานหนัก เมื่อรวมเข้าด้วยกันแล้วมีสูตรภัยพิบัติ ในการพูดคุยครั้งนี้ Dan Giovannelli จะแชร์ประสบการณ์การทํางานในโครงการโครงสร้างพื้นฐานบนอุปกรณ์เคลื่อนที่แบบข้ามแพลตฟอร์ม เขาจะพูดถึงสิ่งที่ผิดพลาด สิ่งที่ผิด (มาก) และสิ่งที่เขาต้องการในตอนนี้ มาฟังข้อมูลเชิงลึกเกี่ยวกับการออกแบบเครื่องมือสําหรับอุปกรณ์เคลื่อนที่สําหรับวิศวกรที่ไม่ใช่อุปกรณ์เคลื่อนที่กัน มาดูกันว่ายาบ้า The M ฯลฯ คืออะไรและเอาชนะเกมนี้ได้อย่างไร
การทดสอบเกมในอุปกรณ์เคลื่อนที่อัตโนมัติโดยใช้อุปกรณ์จริง
Jouko Kaasila (Bitbar/Testdroid)
เกมในอุปกรณ์เคลื่อนที่คือหมวดหมู่ที่สร้างรายได้มากที่สุดใน App Store ในปัจจุบัน เพื่อให้มั่นใจว่าเกมแต่ละเวอร์ชันทํางานได้ในอุปกรณ์ของผู้ใช้จึงมีความสําคัญสูงสุดสําหรับนักพัฒนาเกม แม้ว่าการตรวจสอบดังกล่าวมีความสําคัญ แต่ก็มีตัวอย่างหรือเฟรมเวิร์กเพียงไม่กี่อย่างสําหรับการทดสอบเกมในอุปกรณ์เคลื่อนที่โดยอัตโนมัติ โดยบังคับให้นักพัฒนาเกมนําไปยังการทดสอบด้วยตนเองที่ไม่ได้ขยายขอบเขตในขอบเขตที่บริษัทเกมจะต้องรองรับตลาดทั่วโลก สาเหตุหลักอย่างหนึ่งคือลักษณะพิเศษของเกมเป็นแอปบนอุปกรณ์เคลื่อนที่ เนื่องจากเกมเหล่านี้เข้าถึงหน้าจอโดยตรงและข้ามบริการ UI ทั้งหมดที่ระบบปฏิบัติการแสดงผล และแสดงเฟรมเวิร์กระบบอัตโนมัติในการทดสอบส่วนใหญ่ที่ไม่มีประโยชน์เนื่องจากไม่เปิดเผยออบเจ็กต์แบบดั้งเดิม
แต่โชคดีที่ไม่สามารถใช้เฟรมเวิร์กการทดสอบอัตโนมัติบนอุปกรณ์เคลื่อนที่แบบมาตรฐานเพื่อกระตุ้นการทดสอบอัตโนมัติในอุปกรณ์เคลื่อนที่จริงสําหรับเกมได้ โดยใช้ความคิดสร้างสรรค์และไลบรารีที่พร้อมใช้งานแบบสาธารณะ ในการนําเสนอของเขา Jouko Kaasila จาก Testdroid จะมาพูดคุยเกี่ยวกับ 3 แนวทางที่แตกต่างกันกับตัวอย่างการใช้งานจริงและโค้ดตัวอย่าง
วิธีการทําชิ้นส่วนซุปทดสอบ
Toni Chang (Google)
ผู้ที่ใช้เวลามากเกินไปในการรักษาการทดสอบที่ไม่น่าเชื่อถือจะช่วยให้เราเห็นว่าเราต้องแยกการทดสอบ อย่างไรก็ตาม บางคนรู้สึกว่ามันยากและไม่แน่ใจว่าคนอื่นจะท้าทายอย่างไรโดยเพื่อนร่วมทีมที่เชื่อว่าเราต้องทดสอบ E2E เพื่อตรวจสอบสถานการณ์ทั้งหมด เนื่องจากบางครั้งการเข้าใจแนวคิดเมื่อคุณไม่ได้ใช้เพื่อดูผลิตภัณฑ์ในคอมโพเนนต์อาจทําได้ยาก ฉันจะใช้ตัวอย่างนามธรรมของเกี๊ยวซุปเพื่อสาธิตวิธีจําแนกสิ่งที่ดูเหมือนจะเป็นส่วนประกอบที่เปรียบเทียบได้ยากและใช้การทดสอบกับคอมโพเนนต์
ฉันจะอธิบายเส้นทางความสนุกในการแปลการทดสอบ E2E เป็นการทดสอบคอมโพเนนต์ที่ช่วยให้คุณมีความมั่นใจในผลิตภัณฑ์สุดท้าย เราหวังว่ามุมมองนี้จะช่วยให้คุณได้รับมุมมองใหม่ๆ เมื่อมองดูผลิตภัณฑ์ของคุณเอง
การทดสอบอัตโนมัติของ Chromecast
Brian Gogan (Google)
อินเทอร์เน็ตในสรรพสิ่งนําไปสู่การเพิ่มขึ้นอย่างรวดเร็วของอุปกรณ์ที่เชื่อมต่อ การตรวจสอบลักษณะการทํางานในอุปกรณ์ระหว่างการทํางานร่วมกันที่หลากหลายเป็นความท้าทายที่สําคัญในการทดสอบ การทดสอบ Chromecast ทําได้หลายวิธี เราสรุปเฟรมเวิร์กการทดสอบ โครงสร้างพื้นฐานของห้องทดลอง และเครื่องมือการทดสอบที่เราพัฒนาขึ้นมาเพื่อสร้างสัญญาณคุณภาพที่เชื่อถือได้จากผลิตภัณฑ์ เราอธิบายรายละเอียดความท้าทายในการทดสอบผลิตภัณฑ์ที่ทํางานในสภาพแวดล้อมที่มีเครือข่ายมีเสียงดัง เราเสนอว่าเครื่องมือการทดสอบสําหรับอุปกรณ์อย่างเช่น Chromecast อยู่ในระยะเวลาที่จํากัดและเปิดโอกาสให้เกิดนวัตกรรมด้านวิศวกรรมทดสอบซอฟต์แวร์
การใช้โรบ็อตสําหรับการทดสอบแอป Android
Dr.Shauvik Roy Choudhary (จอร์เจีย Tech/Checkdroid)
โรบ็อตของซอฟต์แวร์ เช่น Monkey สามารถใช้เพื่อทดสอบแอปพลิเคชัน Android ได้โดยไม่ต้องลงแรงด้วยตนเอง มีเครื่องมือมากมายที่เสนอให้วิชาการโดยมีเป้าหมายเพื่อสร้างอินพุตทดสอบโดยอัตโนมัติเพื่อกระตุ้นแอปพลิเคชัน Android ในการพูดคุยนี้ ผมจะแนะนําชุดเครื่องมือในการสร้างอินพุตสําหรับตัวแทนทดสอบ และนําเสนอการศึกษาเปรียบเทียบเพื่อไฮไลต์จุดแข็งและข้อจํากัด คุณจะได้เรียนรู้เกี่ยวกับภายในของเครื่องมือเหล่านี้และวิธีใช้เครื่องมือเหล่านั้นเพื่อทดสอบแอปพลิเคชัน ดูรายละเอียดของการศึกษาพร้อมกับการตั้งค่า VM ด้วยเครื่องมือได้ที่ http://bear.cc.gatech.edu/~shauvik/androtest/
การทดสอบไม่ไม่น่าเชื่อถือ
Alister Scott (อัตโนมัติ)
การทดสอบที่ไม่น่าเชื่อถือเป็นข้อบกพร่องของวิศวกรทดสอบอัตโนมัติ มีคน (อาจเรียกว่า Alister) เคยกล่าวว่า "การทดสอบนั้นทําซ้ําๆ และได้ผลลัพธ์ที่ต่างกัน" การทดสอบที่ไม่น่าเชื่อถือทําให้การทดสอบไม่เป็นไปตามที่คาดหวังเสมอไป แต่บางทีอาจไม่ได้เป็นการทดสอบที่ไม่น่าเชื่อถือหรืออาจจําเป็นต้องผ่านปัญหานี้ในเลนส์อื่น เราควรใช้เวลาไปกับการสร้างระบบที่พิจารณาได้ชัดเจนมากขึ้นและทดสอบได้มากกว่าการใช้เวลาสร้างความยืดหยุ่นและการทดสอบอย่างต่อเนื่อง Alister จะแชร์ตัวอย่างเมื่อการทดสอบที่ไม่น่าเชื่อถือซ่อนปัญหาจริงไว้ใต้ระบบและวิธีแก้ไขการแก้การทดสอบที่ไม่น่าเชื่อถือด้วยการสร้างระบบที่ดีขึ้น
การทดสอบภาพอัตโนมัติขนาดใหญ่
Adam Carmi (Applitools)
การทดสอบภาพอัตโนมัติเป็นเทรนด์ใหม่ที่สําคัญในชุมชนนักพัฒนาซอฟต์แวร์ / ทดสอบ ในการพูดคุยนี้ คุณจะได้ทราบว่าการทดสอบภาพคืออะไร และเหตุใดจึงควรใช้การทดสอบอัตโนมัติ เราจะเจาะลึกเกี่ยวกับความท้าทายด้านเทคโนโลยีบางประการที่เกี่ยวข้องกับระบบอัตโนมัติด้วยการทดสอบภาพ และแสดงให้เห็นว่าเครื่องมือสมัยใหม่จะจัดการกับความท้าทายเหล่านั้นได้อย่างไร เราจะสาธิตเทคโนโลยีล้ําสมัยที่ช่วยให้ทําการทดสอบแบบภาพข้ามเบราว์เซอร์และข้ามอุปกรณ์ได้ รวมถึงบอกเคล็ดลับที่สําคัญในการประสบความสําเร็จด้วยการทดสอบภาพขนาดใหญ่
การทดสอบการถดถอย
Karin Lundberg (Twitter) และ Puneet Khanduri (Twitter)
ทีมของคุณได้ปรับเปลี่ยนรูปแบบหลักของบริการและผ่านการทดสอบทั้งหน่วยและการผสานรวมแล้ว เยี่ยมไปเลย แต่คุณยังไม่ได้ทําเลย ตอนนี้คุณต้องตรวจสอบให้แน่ใจด้วยว่าคุณไม่ได้ทําอะไรผิดพลาด และยังไม่มีข้อบกพร่องที่อยู่เบื้องหลัง ได้เวลาเปลี่ยนให้ Diffy ทํางานแล้ว
Diffy แตกต่างจากเครื่องมือที่ตรวจสอบว่าโค้ดมีเสียง เช่น การทดสอบหรือการผสานรวมการผสานรวม
เราเพิ่งเปิดเครื่องมือแบบโอเพนซอร์ส และเครื่องมือนี้ก็กลายเป็นหนึ่งในโปรเจ็กต์โอเพนซอร์สที่ได้รับความนิยมมากที่สุดจาก Twitter อย่างรวดเร็ว
การทดสอบการเข้าถึงอัตโนมัติสําหรับแอปพลิเคชัน Android
Casey Burkhardt (Google)
การพูดคุยครั้งนี้จะแนะนําความสามารถหลักของการช่วยเหลือพิเศษบนแพลตฟอร์ม Android และแสดงให้เห็นข้อผิดพลาดที่พบบ่อยสําหรับนักพัฒนาซอฟต์แวร์เกี่ยวกับการช่วยเหลือพิเศษ คุณจะได้ดูข้อมูลเกี่ยวกับเฟรมเวิร์กการทดสอบการช่วยเหลือพิเศษใหม่ของ Android และการผสานรวมดังกล่าวกับเฟรมเวิร์กการทดสอบ Espresso และ Robolectric ขั้นตอนสุดท้าย คุณจะได้เรียนรู้ว่าการเพิ่มการตรวจสอบการเข้าถึงอัตโนมัติในการทดสอบโครงการ Android ที่มีอยู่นั้นง่ายเพียงใด
การสุ่มตัวอย่างข้อมูลทางสถิติ
Celal Ziftci (Google) และ Ben Greenberg (นักศึกษาระดับบัณฑิตศึกษาของ MIT)
เป็นเรื่องปกติที่จะใช้ตัวอย่างข้อมูลที่ใช้งานจริงในการทดสอบ ตัวอย่างเช่น
- การทดสอบความเรียบร้อย: ป้อนข้อมูลตัวอย่างการผลิตลงในระบบเพื่อดูว่าล้มเหลวหรือไม่
- การทดสอบ A/B: จัดกลุ่มข้อมูลที่ใช้งานจริงจํานวนมาก เรียกใช้ผ่านระบบเวอร์ชันปัจจุบันและเวอร์ชันใหม่ และนําเอาต์พุตออกเพื่อตรวจสอบ
ทีมมักจะใช้โซลูชันเฉพาะกิจในการรับตัวอย่างข้อมูลที่ใช้งานจริง เช่น
- พิจารณาการกระจายช่องที่เฉพาะเจาะจงด้วยตนเอง (เช่น ช่องตัวเลข)
- การเลือกตัวอย่างแบบสุ่มทั้งหมด
อย่างไรก็ตาม แนวทางเหล่านี้มีข้อเสียที่ร้ายแรง นั่นคืออาจพลาดเหตุการณ์ที่พบได้น้อย (เช่น กรณี Edge) ซึ่งเพิ่มความเสี่ยงในข้อบกพร่องที่ตรวจจับไม่ได้ในเวอร์ชันที่ใช้งานจริง ทีมต่างๆ จะเลือกตัวอย่างขนาดใหญ่เพื่อลดความเสี่ยงนี้ อย่างไรก็ตาม ด้วยตัวอย่างขนาดใหญ่เช่นนี้ แต่กลับมีข้อได้เปรียบมากกว่าดังนี้
- คุณอาจพลาดกิจกรรมหายาก
- รันไทม์ของการทดสอบเพิ่มขึ้นอย่างมาก
- ความแตกต่างนั้นใหญ่เกินที่มนุษย์จะเข้าใจได้ และการกล่าวซ้ําๆ นั้นมีมากมาย
ในการสนทนานี้ เราเสนอเทคนิคการสุ่มตัวอย่างข้อมูลทางสถิติแบบใหม่เพื่อให้ "ชาญฉลาด" ในการเลือกตัวอย่าง "ที่ดี" จากข้อมูลการผลิตซึ่งมีลักษณะดังนี้
- รับประกันว่าจะพลาดกิจกรรมหายาก
- ลดขนาดของตัวอย่างที่เลือกโดยกําจัดรายการที่ซ้ํา
เทคนิคของเราตรวจจับกรณีที่พบได้น้อย/ไม่มีขอบเขต รักษาขนาดตัวอย่างให้น้อยที่สุด และลดภาระที่เจ้าหน้าที่ต้องดูผลการทดสอบ/ความแตกต่างของนักพัฒนาซอฟต์แวร์ ทั้งยังรองรับการดําเนินการพร้อมกัน (เช่น MapReduct) เพื่อให้สามารถประมวลผลข้อมูลจํานวนมากในกรอบเวลาสั้นๆ เพื่อเลือกตัวอย่างได้
โครงสร้างพื้นฐานระบบอัตโนมัติของ Nest
Usman Abdullah (Nest), Giulia Guidi (Nest) และ Sam Gordon (Nest)
วิสัยทัศน์ของ Thoughtful Home ในเรื่องอุปกรณ์ Nest ประกอบไปด้วยอุปกรณ์อัจฉริยะที่เชื่อมต่อถึงกันได้และช่วยให้บ้านของคุณมีความปลอดภัย ประหยัดพลังงานมากขึ้น และรับรู้ได้มากขึ้น การพูดคุยนี้จะมุ่งเน้นที่โครงสร้างพื้นฐานและเครื่องมือทดสอบอัตโนมัติที่สร้างขึ้นมาเพื่อช่วยให้วิสัยทัศน์นั้นเป็นจริง หลายทีมภายใน Nest ทํางานทั้งในระบบที่ทํางานข้ามแพลตฟอร์มและระบบ/อุปกรณ์เฉพาะเพื่อการทดสอบและวิเคราะห์การเกิดปัญหาซ้ําโดยอัตโนมัติ เมื่อใช้ตัวอย่างจากการทดสอบผลิตภัณฑ์ในชีวิตจริง เราจะพูดถึงฮาร์ดแวร์ข้ามผลิตภัณฑ์ในโครงสร้างพื้นฐานของการทดสอบแบบวนซ้ําและเครื่องมือวิเคราะห์การถดถอยกําลัง ตลอดจนชุดเครื่องมือเฉพาะกล้องและการตรวจจับการเคลื่อนไหว
เครื่องมือสร้างเหตุการณ์
Roussi Roussev (Splunk)
การพูดคุยครั้งนี้ครอบคลุมประสบการณ์ของเราในการพัฒนาและใช้โปรแกรมสร้างซอฟต์แวร์ที่ Splunk ได้รับแรงบันดาลใจจากฟิสิกส์อนุภาคที่หน่วยวัดเหตุการณ์ไม่สามารถเข้าใจโลกจริงได้โดยไม่ต้องใช้เครื่องทดลองขนาดใหญ่ โปรแกรมสร้างบันทึกจึงปรับปรุงวิธีที่เราทดสอบการผสานรวมจํานวนมากกับซอฟต์แวร์ของบุคคลที่สามแบบเดิมและที่ทันสมัย การพูดคุยจะครอบคลุมฟังก์ชันการทํางานพื้นฐานและความท้าทายในการสร้างบันทึกที่สมจริง
การสังเคราะห์การทดสอบแบบหลายชุดข้อความ
Murali Krishna Ramanathan (สถาบันวิทยาศาสตร์อินเดีย บังคาลอร์)
ข้อผิดพลาดที่เกิดขึ้นพร้อมกันเล็กน้อยในไลบรารีแบบหลายชุดข้อความที่เกิดขึ้นเนื่องจากการซิงค์ไม่ถูกต้องหรือไม่เพียงพอมักระบุได้ยากโดยใช้เทคนิคแบบคงที่เท่านั้น ในทางกลับกัน ประสิทธิภาพของตัวตรวจจับแบบไดนามิกจะต้องอาศัยชุดทดสอบแบบหลายชุดข้อความซึ่งสามารถใช้ระบุและเรียกข้อบกพร่องที่เกิดขึ้นพร้อมกัน รวมถึงการแข่งขันทางข้อมูล การติดตาย และการละเมิด โดยปกติ การทดสอบแบบหลายชุดข้อความดังกล่าวจะต้องเรียกใช้ชุดค่าผสมของเมธอดที่เจาะจงกับออบเจ็กต์ที่เกี่ยวข้องในการเรียกใช้ที่ได้รับร่วมกันอย่างเหมาะสมเพื่อแสดงข้อบกพร่อง การไม่รู้ถึงข้อบกพร่องดังกล่าวนั้นเป็นเรื่องสําคัญ การสร้างการทดสอบดังกล่าวอาจเป็นเรื่องที่ท้าทาย
ในการพูดคุยนี้ ฉันจะนําเสนอเทคนิคขนาดเล็กที่ปรับขนาดได้สําหรับการทดสอบสังเคราะห์สําหรับการตรวจพบการละเมิดความปลอดภัยของชุดข้อความ เมื่อพิจารณาถึงไลบรารีแบบหลายชุดข้อความและชุดการทดสอบตามลําดับ ฉันจะอธิบายการวิเคราะห์อัตโนมัติทั้งหมดที่ตรวจสอบการติดตามการดําเนินการตามลําดับ และสร้างเอาต์พุตเป็นโปรแกรมไคลเอ็นต์ที่ทํางานพร้อมกันซึ่งขับเคลื่อนออบเจ็กต์ที่แชร์ผ่านการเรียกเมธอดไลบรารีไปยังรัฐที่จําเป็นต่อการทําให้เกิดข้อบกพร่องที่เกิดขึ้นพร้อมกัน ผลลัพธ์จากการทดลองในไลบรารี Java ที่มีการทดสอบอย่างดีแสดงให้เห็นถึงประสิทธิภาพของแนวทางของเราในการเปิดเผยข้อบกพร่องที่ซับซ้อนจํานวนมาก
การเปิดใช้การทดสอบสตรีมมิงที่ Netflix
Minal Mishra (Netflix)
ประสบการณ์สตรีมมิงของผู้ใช้กว่า 69 ล้านคนมีความสําคัญอย่างยิ่งต่อ Netflix เพื่อเป็นการปรับปรุงอย่างรวดเร็ว เราย้ายอัลกอริทึมสตรีมมิงแบบปรับขนาดได้ไปไว้ในเลเยอร์ JavaScript นี่จึงเป็นความท้าทายที่ไม่เหมือนใครสําหรับการเปิดตัวซอฟต์แวร์ JavaScript ของไคลเอ็นต์บ่อยครั้งซึ่งส่งผลโดยตรงต่อประสบการณ์สตรีมมิงของผู้บริโภค มีการยืมกระบวนทัศน์อย่างต่อเนื่องที่ปรับใช้กันอย่างแพร่หลายและนําไปสู่ความสําเร็จในการใช้บริการนี้ เราใช้ความเสี่ยงนี้ตลอดวงจรเช็คและจัดส่งอัปเดตเป็นประจํา ในการพูดคุยครั้งนี้ เราจะอธิบายองค์ประกอบสําคัญของกระบวนทัศน์นี้เพื่อให้เปิดใช้การอัปเดตซอฟต์แวร์ เราจะเจาะลึกขั้นตอนการเปิดตัวไคลเอ็นต์ JavaScript และเครื่องมือต่างๆ เพื่อเปรียบเทียบสุขภาพกับเวอร์ชันปัจจุบันอย่างถูกต้อง เราจะแชร์ปัญหาที่คุณพบในกระบวนการนี้ด้วย
จําลองอินเทอร์เน็ต
Yabin Kang (LinkedIn)
มาดูตัวอย่างอินเทอร์เน็ตเกี่ยวกับระบบจําลองแบบใหม่ใน LinkedIn ที่จะช่วยจําลองการรับส่งข้อมูลขาออกทั้งหมดสําหรับการทดสอบการผสานรวมระดับบริการ ซึ่งจะพูดถึงภาพรวมของกลยุทธ์ LinkedIn Mocks ด้วย แชร์ความรู้และสิ่งที่ได้เรียนรู้กับทุกคน
การทดสอบอย่างมีประสิทธิภาพของตัวรับสัญญาณ GPS สําหรับตรวจสอบ
Andrew Knodt (ล็อกเฮด มาร์ติน)
สถานีตรวจสอบ GPS ปัจจุบันที่กองทัพอากาศใช้ดูแลได้ยาก และกําลังพยายามแทนที่ด้วยสถานีวิทยุที่กําหนดโดยซอฟต์แวร์ (SDR) แบบ GPU แบบเร่ง ภาพรวมของการทดสอบที่ไม่ซ้ํากันของตัวรับสัญญาณ GPS โดยเฉพาะนี้จะมาพร้อมกับการทดสอบวิธีการทดสอบมากมาย ในขณะมุ่งเน้นไปที่แอปพลิเคชัน GPS คุณสามารถใช้วิธีทดสอบ SDR ระดับที่ใช้งานจริงอื่นๆ ได้อย่างง่ายดาย
การทํางานอัตโนมัติในอุปกรณ์ที่สวมใส่ได้
Anurag Routroy (Intel)
เนื่องจากเทคโนโลยีอุปกรณ์ที่สวมใส่ได้กําลังได้รับความนิยมเพิ่มขึ้นทั้งในด้านการใช้งานส่วนตัวและธุรกิจ บริษัททั้งหมดที่มีพื้นที่ขนาดใหญ่ในตลาด Android จึงได้เปลี่ยนจุดมุ่งเน้นของเทคโนโลยีที่กําลังจะมีขึ้นนี้ไป ด้วยเหตุนี้ จึงสร้างแอปด้วยการสนับสนุนอุปกรณ์ที่สวมใส่ได้ ซึ่งจะช่วยเพิ่มความพยายามในการทดสอบแอปในอุปกรณ์ที่สวมใส่ได้ ดังนั้น ระบบอัตโนมัติในอุปกรณ์ที่สวมใส่ได้จึงมีความสําคัญในการลดความพยายามทดสอบและเพิ่มประสิทธิภาพ
การทดสอบการผสานรวมแบบรวมสําหรับ Infra และ CI (Docker/Vagrant)
Maxim Guenis (Supersonic)
นักพัฒนาซอฟต์แวร์ประสบปัญหาเป็นประจําทุกวันเพื่อเตรียมสภาพแวดล้อมการพัฒนาภายในให้พร้อมเมื่อพัฒนา แก้ไขข้อบกพร่อง และดําเนินการผสานรวมระบบต่อไป เราจะแก้โจทย์นั้นได้โดยการผสานรวม Docker และให้มีช่องว่างกับเครื่องมือ CI การผสมผสานนี้ช่วยให้ควบคุมแอปพลิเคชันในระดับสแต็กเครื่องพัฒนาซอฟต์แวร์ได้ ทั้งยังใช้สแต็กเดียวกันในการทดสอบการผสานรวมได้ด้วย ในการพูดคุยครั้งนี้ เราจะพูดคุยกันว่า:
- การใช้ Dock ในการทดสอบการผสานรวม CI
- การควบคุมสแต็กแทน Docker หรือแอปเดียว
- การควบคุมเวอร์ชันสําหรับการพัฒนาและสภาพแวดล้อมการทดสอบ โดยจะกระจายได้ง่ายๆ ด้วยเครื่องมือ Git และ Docker
- รองรับการใช้งาน RTB บน Mac และหน้าต่างอย่างราบรื่น
การกําจัดบิตทดสอบที่ไม่มีประโยชน์
Patrick Lam (มหาวิทยาลัย University of Waterloo)
ความเชี่ยวชาญเฉพาะทางเกี่ยวกับเทคนิคการวิเคราะห์แบบคงที่สําหรับชุดทดสอบทําให้ได้ผลลัพธ์ที่น่าสนใจ ก่อนหน้านี้เราได้รู้ว่าการทดสอบส่วนใหญ่เป็นโค้ดแบบเส้นตรงธรรมดา เช่น ลําดับคําสั่งตั้งค่า ตามด้วยเพย์โหลดที่ประกอบด้วยการยืนยัน เราแสดงให้เห็นว่าการวิเคราะห์แบบคงที่จะระบุข้อความเกี่ยวกับการตั้งค่าที่ไม่มีประโยชน์ได้อย่างไร ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์ลดความซับซ้อนและเร่งกระบวนการทดสอบให้เร็วขึ้น
ความครอบคลุมไม่มีความเกี่ยวข้องอย่างมากกับประสิทธิภาพของชุดทดสอบ
Laura Inozemtseva (มหาวิทยาลัยวอเตอร์ลู)
การครอบคลุมของชุดทดสอบมักจะใช้เป็นพร็อกซีสําหรับการตรวจหาข้อผิดพลาด อย่างไรก็ตาม การศึกษาก่อนหน้าที่ตรวจสอบความสัมพันธ์ระหว่างการครอบคลุมของโค้ดกับประสิทธิภาพของชุดทดสอบล้มเหลวในความเห็นพ้องเกี่ยวกับลักษณะและความรัดกุมของความสัมพันธ์ระหว่างลักษณะเฉพาะของชุดทดสอบเหล่านี้ นอกจากนี้ การศึกษาจํานวนมากยังทําโดยใช้โปรแกรมขนาดเล็กหรือสังเคราะห์ ทําให้ไม่ทราบชัดเจนว่าผลลัพธ์ของตนเหมาะกับโปรแกรมขนาดใหญ่หรือไม่ และการศึกษาบางรายการไม่ได้พิจารณาอิทธิพลของขนาดชุดโปรแกรมทดสอบขนาดใหญ่ เราได้ขยายการศึกษาเหล่านี้ด้วยการประเมินความสัมพันธ์ระหว่างขนาดชุดโปรแกรมทดสอบ การครอบคลุม และประสิทธิภาพสําหรับโปรแกรม Java ที่สมจริง การศึกษาของเราใหญ่ที่สุดจนถึงปัจจุบันในวรรณกรรม เราวัดการครอบคลุมของใบแจ้งยอด การครอบคลุมของการตัดสินใจ และความครอบคลุมของเงื่อนไขที่แก้ไขของชุดโปรแกรมเหล่านี้ และใช้การทดสอบการกลายพันธุ์เพื่อประเมินประสิทธิภาพของการตรวจจับข้อผิดพลาด เราพบว่าความสัมพันธ์ระหว่างการครอบคลุมและประสิทธิภาพจะต่ําปานกลางถึงปานกลางเมื่อมีการควบคุมจํานวนกรอบการทดสอบในชุดโปรแกรม นอกจากนี้ เรายังพบว่ารูปแบบความครอบคลุมที่แน่นแฟ้นขึ้นไม่ได้ให้ข้อมูลเชิงลึกที่ละเอียดยิ่งขึ้นเกี่ยวกับชุดโปรแกรมดังกล่าว
แบ็กเอนด์ปลอมที่มี RpcReplay
Matt Garrett (Google)
การทําการทดสอบอย่างรวดเร็วและเสถียรเป็นสิ่งสําคัญมาก การทําแบบนี้เป็นเรื่องยากเมื่อเซิร์ฟเวอร์ต้องอาศัยแบ็กเอนด์จํานวนมาก นักพัฒนาแอปต้องเลือกระหว่างการทดสอบแบบยาวกับการทดสอบที่ไม่น่าเชื่อถือ หรือเขียนและบํารุงรักษาการใช้งานปลอม แต่คุณจะทําการทดสอบโดยใช้การเข้าชมที่บันทึกไว้จากแบ็กเอนด์เหล่านี้ได้แทน วิธีนี้ช่วยให้สิ่งที่ดีที่สุดจากทั้ง 2 ระบบ ช่วยให้นักพัฒนาซอฟต์แวร์ทดสอบเทียบกับแบ็กเอนด์จริงได้อย่างรวดเร็ว
ห้องทดลองการทดสอบอัตโนมัติของ ChromeOS
Simran Basi (Google) และ Chris Sosa (Google)
ปัจจุบัน ChromeOS จัดส่ง Chromebook/กล่องต่างๆ กว่า 60 เครื่องโดยใช้ซอฟต์แวร์ของตนเอง ในอุตสาหกรรมนี้ ลูกค้าจะได้รับระบบใหม่ทุกๆ 6 สัปดาห์ เป็นไปไม่ได้เลยหากไม่มีระบบการตรวจสอบที่ต่อเนื่องที่มีประสิทธิภาพจากการตรวจสอบนักพัฒนาแอปของเรากว่า 200 คน ในการพูดคุยครั้งนี้ เราได้อธิบายสถาปัตยกรรมโดยรวมโดยเน้นไปที่ห้องทดลองการทดสอบอัตโนมัติของเรา นอกจากนี้ เราพูดถึง Moblab (สั้นๆ สําหรับอุปกรณ์เคลื่อนที่ (ทดสอบ) ห้องทดลอง) โครงสร้างพื้นฐานของการทดสอบอัตโนมัติทั้งหมดที่ทํางานจาก chromebox เครื่องเดียว พาร์ทเนอร์หลายรายใช้ระบบนี้เช่นกัน จึงจะทําการทดสอบในแบบของเราได้เช่นกัน