GTAC 2014: งานนําเสนอ

การบันทึกและสไลด์วิดีโอ GTAC 2014 ทั้งหมดจะเผยแพร่ต่อสาธารณะ คุณชมได้จากเพลย์ลิสต์ YouTube ของ GTAC 2014 หรือเรียกดูการบรรยายด้านล่าง

การเปิดหมายเหตุ

Sonal Shah (Google)

คําปราศรัยสําคัญเพื่อเปิดงาน - เดินหน้าอย่างรวดเร็วและไม่ทําลายสิ่งต่างๆ

Ankit Mehta (Google)

ลิงก์: วิดีโอ, สไลด์

ระบบอัตโนมัติเพื่อเว็บที่ดีขึ้น

James Graham (Mozilla)

เว็บเป็นแพลตฟอร์มแอปพลิเคชันที่ได้รับความนิยมมากที่สุดในโลก แต่ความสามารถในการทํางานร่วมกันของเบราว์เซอร์ไม่ดีเป็นสาเหตุที่ทําให้เกิดความไม่สบายใจและหงุดหงิดระหว่างนักพัฒนาเว็บ W3C ได้อํานวยความสะดวกให้ชุมชนสร้างชุดทดสอบแบบข้ามเบราว์เซอร์ที่ได้รับการอัปเดตอย่างต่อเนื่องสําหรับเว็บแบบเปิด และการทดสอบเว็บต่างๆ เพื่อปรับปรุงสถานการณ์นี้ ในการพูดคุยนี้ James จะแนะนําการทดสอบ Web-platform และอธิบายเครื่องมือที่เราสร้างมาเพื่อกระตุ้นการทดสอบอัตโนมัติในเบราว์เซอร์ต่างๆ ในเดสก์ท็อปและอุปกรณ์เคลื่อนที่ที่ใช้ Firefox OS เขาจะแสดงให้เห็นว่าซอฟต์แวร์นี้ออกแบบมาเพื่อตอบสนองความท้าทายของการเรียกใช้ชุดทดสอบจากแหล่งข้อมูลภายนอกและมีการอัปเดตบ่อยครั้งในทุกๆ สัญญาผูกมัดหลายร้อยวันต่อวันในระบบการผสานรวมที่ต่อเนื่องของ Mozilla

ลิงก์: วิดีโอ, สไลด์

ทําให้ Chrome เป็นเบราว์เซอร์ในอุปกรณ์เคลื่อนที่ที่ดีที่สุด

Karin Lundberg (Google)

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

  • ความเร็วมีไว้สําหรับการทดสอบประสิทธิภาพและการทดสอบที่รวดเร็ว
  • ความเสถียรคือการทดสอบความเสถียรและการทดสอบที่เสถียร
  • ความเรียบง่ายมีไว้สําหรับการทดสอบว่า Chrome ให้ประสบการณ์ผู้ใช้ที่เรียบง่าย และช่วยให้เพิ่มและทําการทดสอบได้อย่างง่ายดาย
  • ความปลอดภัยมีไว้เพื่อการทดสอบความปลอดภัย

ลิงก์: วิดีโอ, สไลด์

ภาษาทดสอบอัตโนมัติสําหรับโมเดลพฤติกรรม

Nan Li (โซลูชัน Medidata)

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

การพูดคุยนี้แนะนําภาษาทดสอบอัตโนมัติเพื่ออนุญาตให้ผู้ทดสอบสร้างการทดสอบโดยใช้โมเดลพฤติกรรมเพียงแบบเดียว เช่น แผนภาพเครื่องของรัฐ เราจะจัดการปัญหา 3 ข้อ ได้แก่ (1) การสร้างการแมปจากโมเดลไปยังโค้ดปฏิบัติการและการสร้างค่าทดสอบ (2) การเปลี่ยนกราฟและใช้เกณฑ์การครอบคลุมเพื่อสร้างเส้นทางทดสอบ และ (3) การแก้ปัญหาข้อจํากัดและการทดสอบที่เป็นรูปธรรม

ลิงก์: วิดีโอ, สไลด์

ทดสอบความครอบคลุมที่ Google

Andrei Chirila (Google)

เคยสงสัยไหมว่าการทดสอบที่ Google เป็นอย่างไร เครื่องมือใดใช้ช่วยเราและวัดผลและดําเนินการกับความครอบคลุมของการทดสอบ เราจะอธิบายกระบวนการพัฒนาที่ Google คร่าวๆ แล้วจากนั้นมุ่งเน้นที่การใช้การวัดการครอบคลุมของโค้ดและวิธีที่เราใช้การครอบคลุมของโค้ดเพื่อปรับปรุงคุณภาพโค้ดและประสิทธิภาพการทํางานด้านวิศวกรรม ในท้ายที่สุด เราจะนําเสนอข้อมูลการครอบคลุมจํานวนมหาศาล ซึ่งครอบคลุมสัญญาผูกมัดมากกว่า 100,000 รายการ ซึ่งเราได้รวบรวมและข้อสรุปที่เกี่ยวข้องอย่างแพร่หลาย

ลิงก์: วิดีโอ, สไลด์

CATJS: แอปพลิเคชันที่ทดสอบตัวเอง

Ran Snir (HP) และ Lior Reuven (HP)

ในช่วงหลายปีที่ผ่านมา เราได้เห็นความผิดปกติมากมายซึ่งเปลี่ยนวิธีที่เราคิดเกี่ยวกับโลกการประมวลผลข้อมูล มีเครื่องพิมพ์ 3 มิติที่พิมพ์เครื่องพิมพ์ 3 มิติ หุ่นยนต์ที่คิดด้วยตนเอง และเราก็มี catjs

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

ลิงก์: วิดีโอ, สไลด์

การผสานรวมอย่างต่อเนื่องที่รองรับการปรับขนาด - การใช้โอเพนซอร์ส

Vishal Arora (Dropbox)

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

ลิงก์: วิดีโอ, สไลด์

ฉันไม่ได้ทดสอบบ่อยนัก ... แต่เมื่อฉันทํา ฉันทดสอบในเวอร์ชันที่ใช้งานจริง

Gareth Bowles (Netflix)

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

ลิงก์: วิดีโอ, สไลด์

ความสําคัญของการทดสอบอัตโนมัติบนอุปกรณ์เคลื่อนที่จริงและเสมือนจริง

Jay Srinivasan (Google) และ Manish Lachwani (Google)

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

ลิงก์: วิดีโอ, สไลด์

การทดสอบฟรีดีกว่ากล้วยฟรี: การใช้เหมืองข้อมูลและแมชชีนเลิร์นนิงทําให้การตรวจสอบการผลิตแบบเรียลไทม์เป็นแบบอัตโนมัติ

Celal Ziftci (Google)

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

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

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

ลิงก์: วิดีโอ, สไลด์

ทดสอบระบบอัตโนมัติบนกล่องรับสัญญาณอินฟราเรด

Olivier Etienne (สีส้ม)

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

มาฟังกันว่าผู้ขายบางรายและโค้ดไม่กี่บรรทัดช่วยเปิดโลกแห่งการทดสอบเว็บให้ยอดเยี่ยมผ่าน Set-top box

ลิงก์: วิดีโอ, สไลด์

ความท้าทายของการเปรียบเทียบผู้ให้บริการระบบคลาวด์อย่างยุติธรรมและสิ่งที่เรากําลังทําอยู่

Anthony Voellm (Google)

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

ลิงก์: วิดีโอ, สไลด์

อย่าส่งให้มนุษย์ทํางานของเครื่อง: วิธีที่ Facebook ใช้บ็อตในการจัดการการทดสอบ

Roy Williams (Facebook)

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

ลิงก์: วิดีโอ, สไลด์

เอสเพรสโซ, ช้อน, Wiremock, โอ้โห ( หรือวิธีที่ฉันเรียนรู้วิธีหยุดกังวลและชื่นชอบการทดสอบ Android )

Michael Bailey (อเมริกัน Express)

ดูข้อมูลเกี่ยวกับการสร้างและทําการทดสอบ Android UI อัตโนมัติที่รวดเร็วและน่าเชื่อถือ เครื่องมือประกอบด้วยเอสเพรสโซ, ช้อน, Wiremock และ Jenkins ความรู้พื้นฐานเกี่ยวกับการพัฒนา Android และ Java

ลิงก์: วิดีโอ, สไลด์

Analytics ของ Google BigQuery

Brian Vance (Google)

BigQuery เป็นบริการข้อมูลขนาดใหญ่แบบอินเทอร์แอกทีฟของ Google Cloud ผู้ใช้จะวิเคราะห์ข้อมูลหลายเทราไบต์ได้ในไม่กี่วินาทีผ่านการค้นหาที่คล้ายกับ SQL เครื่องมือนี้สร้างขึ้นต่อยอดจาก Dremel ซึ่งผู้ทดสอบของ Google ได้ใช้ภายในองค์กรมาเป็นเวลาหลายปี เราจะแนะนําตัวอย่าง 2-3 ข้อ และวิธีเริ่มต้นใช้งาน BigQuery

ลิงก์: วิดีโอ, สไลด์

Selendroid - Selenium สําหรับ Android

Dominik Dary ( Adobe)

Selendroid เป็นเฟรมเวิร์กการทดสอบอัตโนมัติแบบโอเพนซอร์ส ซึ่งนํา UI ของแอปพลิเคชันแบบเนทีฟและไฮบริดของ Android ออกจากเว็บและเว็บบนอุปกรณ์เคลื่อนที่ การทดสอบจะเขียนโดยใช้ Selenium 2 API ของไคลเอ็นต์ สําหรับการทดสอบ ไม่จําเป็นต้องแก้ไขแอปภายใต้การทดสอบเพื่อให้ระบบอัตโนมัติดําเนินการ

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

ลิงก์: วิดีโอ, สไลด์

คงความเรียบร้อยในโลก Hypermedia

Amit Easow (แคสต์)

เมื่อ Comcast พัฒนาจากการเป็นบริษัทเคเบิลไปจนถึงผู้นําด้านสื่อและเทคโนโลยี ทีมวิศวกรก็มีประสิทธิภาพมากขึ้นเช่นกัน ตอนที่ Amit เข้าร่วม Comcast Interactive Media (CIM) ในปี 2006 พวกเขาคือร้านทดสอบด้วยตนเอง หลังจากที่พวกเขาจัดส่งเว็บไซต์แรกในปี 2007 เขาก็เริ่มสร้างต้นแบบสําหรับโครงสร้างพื้นฐานในการทดสอบ UI แบบอัตโนมัติ เขาได้รู้จักกับ Selenium ที่ GTAC 2008 จากนั้นกลับมาที่ Comcast เพื่อสร้างโครงสร้างพื้นฐานในการทดสอบอัตโนมัติร่วมกับ Selenium Grid, Hudson และ Subversion ปัจจุบันเขาทําการทดสอบ API กับการติดตั้งใช้งานจริงในเวอร์ชันที่ใช้งานจริงทุกวัน ซึ่งทําได้โดยใช้ Python, Git, Gerrit และ Anthill

ลิงก์: วิดีโอ, สไลด์

เริ่มทํางานได้อย่างรวดเร็วและเร็วยิ่งขึ้นด้วย MSL

Bryan Robbins (FINRA) และ Daniel Koo (FINRA)

การนําเสนอซอฟต์แวร์ที่เร็วขึ้นโดยไม่กระทบต่อคุณภาพนั้นไม่ใช่งานสําคัญ พวกเราทุกคนล้วนต้องการก้าวไปข้างหน้าอย่างรวดเร็วด้วยการพัฒนาการทดสอบล่วงหน้าและทําการทดสอบให้เร็วขึ้นโดยลดภาระในการบํารุงรักษา ที่ FINRA เราได้พัฒนา MSL (ออกเสียงว่า "Missile") เพื่อให้ทีม Agile ใช้ประโยชน์จากสถาปัตยกรรมแบบเป็นชั้น เช่น MVC เพื่อทดสอบโค้ด UI ได้เร็วและเร็วขึ้น

MSL รองรับการทดสอบการผสานรวมของโค้ด UI (เช่น JavaScript, HTML, CSS) โดยการติดตั้งใช้งานในเครื่องเซิร์ฟเวอร์ Node.js และกําหนดค่าการตอบกลับ HTTP จําลองจากโค้ดทดสอบโดยใช้ไคลเอ็นต์ของเรา (Java, JavaScript หรือ Node.js) การพูดคุยครั้งนี้จะแนะนําฟีเจอร์หลักของ MSL พร้อมตัวอย่างเล็กๆ น้อยๆ

ลิงก์: วิดีโอ, สไลด์

ประสบการณ์ของผู้ใช้ในการทดสอบ

Alex Eagle (Google)

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

ลิงก์: วิดีโอ, สไลด์

การประชุมโต๊ะกลม 1 - การทดสอบข้ามแพลตฟอร์มบนอุปกรณ์เคลื่อนที่

ลิงก์: วิดีโอ, สไลด์

การประชุมโต๊ะกลม 2 - การครอบคลุมของการทํางานอัตโนมัติในเอกสาร

ลิงก์: วิดีโอ, สไลด์

ผลกระทบจากโครงสร้างชุมชนที่มีต่อประสิทธิภาพของโซลูชัน SAT

Zack Newsham (มหาวิทยาลัยวอเตอร์ลู)

เครื่องมือแก้โจทย์ CDCL SAT สมัยใหม่แก้ปัญหาอินสแตนซ์ SAT อุตสาหกรรมขนาดใหญ่มากๆ ในช่วงเวลาสั้นๆ เป็นที่ชัดเจนว่าเครื่องมือแก้โจทย์คณิตนี้ใช้ประโยชน์จากโครงสร้างของอินสแตนซ์ในชีวิตจริง แต่ถึงอย่างนั้น จนถึงตอนนี้ ผลลัพธ์ที่แสดงโดยโครงสร้างนี้ยังคงมีความแม่นยําอยู่บ้าง ในเอกสารนี้ เราให้หลักฐานว่าชุมชน SAT ในชีวิตจริงของอินสแตนซ์ SAT ในชีวิตจริงมีความสัมพันธ์กับเวลาในการแก้โจทย์ CDCL SAT แต่ดังที่รู้มาระยะหนึ่งแล้วว่าอินสแตนซ์ SAT ในชีวิตจริง (ดูเป็นกราฟ) มีชุมชนที่เป็นธรรมชาติอยู่ในนั้น ชุมชนคือกราฟย่อยของอินสแตนซ์ของอินสแตนซ์ SAT เพื่อให้กราฟย่อยนี้มีขอบภายในมากกว่าภายนอกของกราฟ โครงสร้างชุมชนของกราฟมักจะมีลักษณะเป็นเมตริกคุณภาพที่เรียกว่า Q จะเห็นได้ว่ากราฟที่มีโครงสร้างของชุมชนคุณภาพสูง (Q สูง) นั้นคล้ายกับชุมชนเล็กๆ มาก ส่วนกราฟที่มีคุณภาพของชุมชนต่ําก็เปรียบเทียบไม่ได้ เราแสดงผลการค้นหา 3 อย่างโดยอิงตามข้อมูลเชิงประจักษ์ที่แสดงให้เห็นว่าโครงสร้างชุมชนของอินสแตนซ์ทางอุตสาหกรรมในชีวิตจริงเป็นการคาดคะเนล่วงหน้าเกี่ยวกับเวลาในการทํางานของเครื่องมือแก้โจทย์ CDCL เมื่อเทียบกับปัจจัยที่ใช้กันโดยทั่วไปอื่นๆ เช่น ตัวแปรและข้อสัญญา อย่างแรกคือเราแสดงให้เห็นว่าความสัมพันธ์ระหว่างค่า Q กับเมตริกระยะทางบล็อกลิตรของคุณภาพขัดแย้งกันในนโยบายการลบประโยคในรูปเครื่องมือแก้โจทย์กลูโคส ประการที่ 2 เมื่อใช้การวิเคราะห์การถดถอย เราจะแสดงจํานวนชุมชนและค่า Q ของกราฟของอินสแตนซ์ SAT ในชีวิตจริงที่คาดคะเนเวลาในการทํางานของเครื่องมือแก้โจทย์ CDCL มากกว่าเมตริกแบบดั้งเดิม เช่น จํานวนตัวแปรหรือข้อสัญญา สุดท้ายนี้ เราแสดงให้เห็นว่าอินสแตนซ์ SAT ที่สร้างขึ้นแบบสุ่มที่มี 0.05 ≤ Q ≤ 0.13 จะแก้โจทย์เครื่องมือแก้โจทย์ปัญหา CDCL ได้ยากกว่าที่เคย

ลิงก์: วิดีโอ, สไลด์

ความคุ้มครองอื่นๆ: ช่องโหว่ในชุดทดสอบคืออะไร

Patrick Lam (มหาวิทยาลัย University of Waterloo)

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

การพูดคุยครั้งนี้จะตรวจสอบมิติข้อมูลอื่นๆ จํานวนหนึ่งเพื่อประเมินชุดทดสอบ การบรรยายอ้างว่าชุดการทดสอบที่ดีขึ้นจะบํารุงรักษาได้ดีกว่า ใช้งานง่ายกว่า (เช่น เพราะทํางานได้รวดเร็วกว่าหรือใช้ทรัพยากรน้อยกว่า) และมีความล้มเหลวที่ไม่เป็นธรรมน้อยลง ในการพูดคุยนี้ ฉันจะนําเสนอและสังเคราะห์ข้อเท็จจริงเกี่ยวกับชุดทดสอบแบบโอเพนซอร์ส 10 ชุด (ตั้งแต่โค้ด 8,000 ถึง 246,000 บรรทัด) เพื่อประเมินประสิทธิภาพการทํางาน

ลิงก์: วิดีโอ, สไลด์

รักษ์โลก: ทําความสะอาดสภาพแวดล้อมที่เป็นพิษบนอุปกรณ์เคลื่อนที่

Thomas Knych (Google), Stefan Ramsauer (Google), Valera Zakharov (Google) และ Vishal Sethia (Google)

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

ลิงก์: วิดีโอ, สไลด์