การเปิดหมายเหตุ
Tony Voellm (Google)
ลิงก์: วิดีโอ
การเปิดประเด็นปราศรัยสําคัญ - วิวัฒนาการตั้งแต่การประกันคุณภาพไปจนถึงวิศวกรรมทดสอบ
Ari Shamash (Google)
คุณได้สร้างแอปไว้ คุณอาจจะคิดขึ้นมาเองเลย สร้างวอลุ่มเพิ่ม หาเงินทุน กําจัดให้หมด แล้วเริ่มต้นใหม่ทั้งหมดเพื่อให้ "ทําถูก" แต่ความต้องการของฟีเจอร์ใหม่ๆ นั้นเพิ่มสูงขึ้นมาก ในตอนนี้เราขอให้คุณเพิ่มความสามารถในการใช้งานแอปอย่างที่ไม่เคยมีมาก่อน อึ๋ย! ควรทำอย่างไรต่อไปดี
ทิ้งไปและเริ่มใหม่ทั้งหมดไม่ได้ คุณเพียงแค่ต้องพัฒนาสิ่งที่คุณมีเอาไว้ ในขณะเดียวกันก็เพิ่มคุณลักษณะที่คงคุณภาพเยี่ยมด้วยความเร็วที่น่าทึ่ง นอกจากนี้ คุณต้องตรวจสอบให้แน่ใจว่าสิ่งที่มีอยู่แล้วไม่เสียหาย คุณจะทําอย่างไร โชคดีที่ฟิลด์ใหม่กําลังเกิดขึ้นภายในอุตสาหกรรมวิศวกรรมซอฟต์แวร์ที่แก้ไขสถานการณ์ทั่วไปนี้ ที่ Google เราเรียกสิ่งนี้ว่า "การทดสอบวิศวกรรม"
การบรรยายนี้จะมุ่งเน้นว่าวิศวกรรมทดสอบคืออะไร มีการเปลี่ยนแปลงอย่างไรจากการประกันคุณภาพ และวิธีที่อุตสาหกรรมโดยรวมได้ดําเนินการวิศวกรรมทดสอบ (พร้อมกับตัวอย่างที่เจาะจงเกี่ยวกับวิธีนําระบบไปปฏิบัติที่ Google)
ระบบทดสอบในวงกว้างที่ @Twitter
James Waldrop (Twitter)
James จะพูดคุยถึงเครื่องมือ กระบวนการ และปรัชญาที่ใช้ทดสอบประสิทธิภาพที่ Twitter มีการเน้นย้ําเป็นพิเศษในไลบรารีการทดสอบโอเพนซอร์สแบบโอเพนซอร์สของ Iago ซึ่งเขียนขึ้นเพื่อช่วยให้ทีมวิศวกรของ Twitter สามารถทดสอบการโหลดได้ก่อนที่จะนําโค้ดไปใช้จริง การพูดคุยจะเจาะลึกรายละเอียดการใช้งานของการทดสอบเหล่านี้บางส่วน (รวมถึงซอร์สโค้ด) และวิธีจัดการปัจจัยที่ซับซ้อน เช่น OAuth และโปรโตคอล Thrift ที่กําหนดเอง
คุณจะทดสอบระบบปฏิบัติการบนอุปกรณ์เคลื่อนที่อย่างไร
David Burns (Mozilla) และ Malini Das (Mozilla)
นี่ก็เป็นปัญหาของการเผชิญหน้ากับ Mozilla เมื่อเราตัดสินใจที่จะก้าวเข้าสู่โลกแห่ง Firefox แทน จุดที่ควรเริ่มต้นและวิธีการทําสิ่งที่จะพิสูจน์ให้เห็นว่าน่าสนใจ ลองเข้ามาดูว่าเราแก้ปัญหานี้อย่างไรและเราได้สร้างเฟรมเวิร์กใหม่อย่างไร
การทํางานอัตโนมัติบนอุปกรณ์เคลื่อนที่ในไปป์ไลน์อย่างต่อเนื่อง
Igor Dorovskikh (Expedia) และ Kaustubh Gawande (Expedia)
Expedia เริ่มลงทุนในแอปบนอุปกรณ์เคลื่อนที่และแอป iOS/Android ในช่วงต้นปี 2012 ในขณะเดียวกัน วิศวกรทดสอบก็เริ่มพัฒนาโซลูชันการทดสอบอัตโนมัติเพื่อสร้างคุณภาพและความสามารถในการทดสอบผลิตภัณฑ์มาตั้งแต่ต้น ในการพูดคุยนี้ เราจะแชร์ประสบการณ์และการเรียนรู้เกี่ยวกับการใช้เครื่องมือโอเพนซอร์สเพื่อสร้างการทดสอบแบบอัตโนมัติในสภาพแวดล้อมการพัฒนาอย่างคล่องตัวและการแสดงโฆษณาแบบต่อเนื่องของ Expedia เราจะพูดคุยเกี่ยวกับการทดสอบพีระมิด และลงรายละเอียดเพิ่มเติมเกี่ยวกับเครื่องมือโอเพนซอร์สที่ได้ผลดีกับเรา เครื่องมือโอเพนซอร์สบางอย่างที่เราใช้คือเครื่องมือ BDD เช่น Cucumber, Selenium-WebDriver เครื่องมือการทํางานอัตโนมัติบนเว็บ, Frank เครื่องมือสําหรับ iOS ที่ทํางานอัตโนมัติ, เครื่องมือ Android Robotium และ Calabash, Jenkins ซึ่งเป็นระบบการผสานรวมแบบต่อเนื่อง นอกจากนี้ เราจะแชร์หลักการส่งมอบบางส่วนที่เราพยายามจะนํามาใช้ เช่น TDD, การจับคู่การเขียนโปรแกรม, การสร้างและการทดสอบด้วยหม้อน้ํา ปิดท้ายด้วยการแชร์ประโยชน์บางอย่างที่เราได้จากการลงทุนในด้านการทดสอบแบบคล่องตัวและแบบอัตโนมัติ และวิธีที่จะทําให้เราบรรลุเป้าหมายการนําส่งอย่างต่อเนื่อง
การทดสอบ Set-top box อัตโนมัติด้วย GStreamer และ OpenCV
David Röthlisberger (YouView)
เราจะสร้างระบบจดจําภาพในวิดีโอภายใน 3 นาที โดยใช้เครื่องมือบรรทัดคําสั่งของ GStreamer และ OpenCV (GStreamer เป็นเฟรมเวิร์กการจัดการสื่อแบบโอเพนซอร์ส; OpenCV —"Open Computer Vision" เป็นไลบรารีการประมวลผลรูปภาพแบบโอเพนซอร์ส)
ตัวอย่างสําคัญของระบบนี้คือ http://stb-tester.com ซึ่งเป็นเครื่องมือโอเพนซอร์สที่พัฒนาโดย YouTubeView เพื่อทดสอบ UI ของ Set-top box ของเราโดยอัตโนมัติ เราจะอธิบายเกี่ยวกับผู้ทดสอบที่เชื่อถือได้ ความยืดหยุ่นที่ GStreamer นําเสนอ ความเป็นไปได้บางอย่างที่เปิดอยู่ และความท้าทายข้างหน้า
ลิงก์: วิดีโอ
Webdriver สําหรับ Chrome
Ken Kania (Google)
นับตั้งแต่เริ่มเป็นเบราว์เซอร์บน Windows เท่านั้น Chrome ได้ขยายไปยัง Mac, Linux, ChromeOS และ Android และ iOS เวอร์ชันล่าสุด การทดสอบระดับเว็บแอปพลิเคชันของผู้ใช้ในแพลตฟอร์มเหล่านี้เป็นเรื่องยากและกําหนดวิธีการอัตโนมัติหลายอย่าง การพูดคุยนี้จะอธิบายถึงงานของทีม Chrome ในการทําให้ WebDriver พร้อมใช้งานใน Chrome ในทุกแพลตฟอร์ม ซึ่งจะรวมถึงมุมมองทางเทคนิคเกี่ยวกับแนวทางที่เป็นพื้นฐาน แต่จะเน้นวิธีการที่นักพัฒนาซอฟต์แวร์สามารถใช้ ChromeDriver ใหม่เพื่อเขียนการทดสอบสําหรับแพลตฟอร์มที่หลากหลายของ Chrome นอกจากนี้ เราจะกล่าวถึงสถานะปัจจุบันของโครงการและแผนงานในอนาคต
Karma - ตัวดําเนินการทดสอบสําหรับ JavaScript
Vojta Jina (Google)
ทําความรู้จักกับ Karma - ตัวทดสอบการใช้งานที่ทําให้การทดสอบแอปพลิเคชัน JavaScript ในเบราว์เซอร์จริงใช้งานได้ราบรื่นและสนุกยิ่งขึ้น
การทดสอบไม่ได้เป็นทางเลือก เมื่อแอปพลิเคชันหนึ่งสร้างแอปพลิเคชัน JavaScript ซึ่งต้องทํางานในเบราว์เซอร์และอุปกรณ์จํานวนมาก อย่างไรก็ตาม การดําเนินการทดสอบในสภาพแวดล้อมต่างๆ ทั้งหมดเหล่านี้เป็นเรื่องยาก กรรมเปลี่ยนงานสุดเหวี่ยงให้กลายเป็นชิ้นเค้ก เครื่องมือนี้ช่วยให้คุณสามารถทดสอบ JavaScript ในเบราว์เซอร์หรืออุปกรณ์จริง เช่น โทรศัพท์หรือแท็บเล็ตของคุณได้โดยตรงจากคอมพิวเตอร์หรือ IDE ที่คุณชื่นชอบ
ลิงก์: วิดีโอ
การวัดคุณภาพวิดีโออัตโนมัติ
Patrik Höglund (Google)
มี การทดสอบเชิงวัดที่ซับซ้อนและเป็นส่วนตัว เช่น คุณภาพวิดีโอ จะทําได้โดยอัตโนมัติ การพูดคุยนี้จะแสดงให้เห็นวิธีที่เราสร้างการทดสอบแบบเบ็ดเสร็จโดยอัตโนมัติของแฮงเอาท์วิดีโอ WebRTC เราจะดูเกี่ยวกับเครื่องมือเครือข่ายในระดับสูงและความท้าทายต่างๆ ที่เราพบขณะสร้าง วิธีนี้เหมาะอย่างยิ่งหากคุณต้องการแรงบันดาลใจในการทดสอบสื่อในอีกระดับ
สิ่งที่ไม่ดีเกิดขึ้นในแอปพลิเคชันที่ดี...
Minal Mishra (Netflix)
ความแพร่หลายของการประมวลผลบนมือถือและแท็บเล็ตทําให้อุตสาหกรรมซอฟต์แวร์มีแพลตฟอร์มการพัฒนาแอปพลิเคชันเพิ่มมากขึ้น การพัฒนาแอปพลิเคชันสําหรับผู้บริโภคบนแพลตฟอร์มการประมวลผลนั้นมีประสบการณ์ที่ยอดเยี่ยมสําหรับผู้ใช้ปลายทาง บริษัทซอฟต์แวร์สําหรับผู้บริโภคมักจะพยายามก้าวไปข้างหน้าเสมอเมื่อพัฒนาแอปพลิเคชันสําหรับแพลตฟอร์มเหล่านี้ อย่างไรก็ตาม ความท้าทายใหญ่ที่สุดในการพัฒนาแอปพลิเคชันจะเริ่มหลังจากที่บริษัทเปิดตัวแอปพลิเคชันเวอร์ชันแรกแล้วเท่านั้น ผู้บริโภคและบริษัทด้านซอฟต์แวร์ต้องการพัฒนาคุณลักษณะและฟังก์ชันใหม่ๆ โดยเร็วที่สุดโดยมีคุณภาพสูงสุด ซึ่งส่งผลให้การเลิกใช้โค้ดคงที่ในทุกชั้นของสแต็ก เราซึ่งเป็นวิศวกรระบบอัตโนมัติ UI สร้างระบบตรวจจับที่หลากหลายเพื่อตรวจจับปัญหาของแอปพลิเคชันให้เร็วยิ่งขึ้น ในการพูดคุยนี้ ฉันจะแชร์ความท้าทายและความสําเร็จต่างๆ เบื้องหลังระบบตรวจสอบซึ่งจะช่วยค้นหาปัญหาที่อยู่นอกเหนือชั้นแอปพลิเคชัน แต่ก็ยังคงส่งผลเสียต่อประสบการณ์ของผู้ใช้ด้วย
การทดสอบสําหรับเกมเพื่อการศึกษาและการเล่นเกมเพื่อการศึกษาสําหรับการทดสอบ
Tao Xie (มหาวิทยาลัยนอร์ทแคโรไลนาสเตต)
การพูดคุยครั้งนี้นําเสนอ Pex4Fun (http://www.pexforfun.com/) ซึ่งใช้ประโยชน์จากการสร้างการทดสอบอัตโนมัติเพื่อสนับสนุนการให้คะแนนอัตโนมัติในระบบการเขียนโปรแกรมออนไลน์ที่สามารถรองรับผู้ใช้หลายแสนคน โดยจะมอบประสบการณ์การเล่นเกมที่เน้นการเขียนโปรแกรมนอกห้องเรียน การฝึกอบรมผู้ใช้ให้เรียนรู้ทักษะด้านการเขียนโปรแกรมและวิศวกรรมซอฟต์แวร์ที่หลากหลาย ซึ่งรวมถึงทักษะการทดสอบอย่างการเขียนการทดสอบหน่วยพารามิเตอร์ Pex4Fun มีส่วนสําคัญต่อการทราบถึงปัญหาการให้คะแนนงานที่ทราบ ตลอดจนมอบประสบการณ์การเรียนรู้ที่สนุกสนานตามเกมแบบอินเทอร์แอกทีฟ Pex4Fun ได้รับความนิยมอย่างแพร่หลายในชุมชน: ตั้งแต่มีการเปิดตัวสู่สาธารณะในเดือนมิถุนายน 2010 มีการคลิกปุ่ม "Ask Pex!" จํานวนหนึ่ง (ระบุการที่ผู้ใช้พยายามแก้ไขปัญหาเกมที่ Pex4Fun) และถึงหนึ่งล้านล้านต้นปี 2013
สรุปประเด็นสําคัญ - วิธีที่ Facebook ทดสอบ Facebook บน Android
Simon Stewart (Facebook)
Facebook คือแอปพลิเคชัน Android ยอดนิยมรายการหนึ่ง เราจะดูแลทุกอย่างตั้งแต่วิธีการจัดการโค้ดไปจนถึงผ่านวิธีการทดสอบและไปจนถึงการลองใช้
การเปิดประเด็นสําคัญ - JavaScript ที่ทดสอบได้ - สถาปัตยกรรมของแอปพลิเคชันเพื่อความสามารถในการตรวจสอบ
Mark Trostler (Google)
JavaScript ที่ทดสอบได้เป็นกระบวนการ การเริ่มต้นด้วยแถบสเลทเปล่าหรือแอปพลิเคชันที่ใช้งานแล้ว (หรือที่อยู่ระหว่างการทดสอบ) สามารถทดสอบโค้ด JavaScript ของคุณได้อย่างง่ายดาย สะอาด และมีประสิทธิภาพ ระบบจะเขียนรหัสที่ทดสอบไม่ได้
แม้ว่า JavaScript จะไม่ซ้ํากันเนื่องจากสภาพแวดล้อมในการทํางานจํานวนมาก ก็มีวิธีการ 'ทดสอบที่ทดสอบ' ได้มากมายหลายวิธีจากภาษาอื่นๆ ที่ใช้กับ JavaScript ได้ด้วย และแน่นอน ยังมีความท้าทาย ที่นักพัฒนาซอฟต์แวร์ JavaScript จะต้องเจอระหว่างการเขียนและทดสอบโค้ด
รูปแบบใดที่ทดสอบโค้ดได้ การต่อต้านรูปแบบใดขัดขวางการทดสอบ เมตริกและคําแนะนําทั่วไปใดบ้างที่สามารถใช้วัดความสามารถในการทดสอบของโค้ดของเรา ข้อใดคือกระบวนการสร้างโค้ดที่ทดสอบได้
เข้าร่วมกับเราเพื่อเขียนกระบวนการเขียน JavaScript ที่ทดสอบได้ เราจะตรวจสอบแนวความคิด รูปแบบ และระเบียบวิธีที่สามารถช่วยเพิ่มความสามารถในการทดสอบได้เป็นอย่างมาก ดังนั้นจึงทําให้การบํารุงรักษา ความถูกต้อง และความยั่งยืนของโค้ดนั้นๆ เป็นไปได้ด้วย ไม่ว่าคุณจะเขียน JavaScript ฝั่งไคลเอ็นต์หรือเซิร์ฟเวอร์ในกระบวนการนี้ จะช่วยปรับปรุงคุณภาพของโค้ดได้อย่างมาก
Breaking the Matrix - การทดสอบ Android ตามระดับที่เหมาะสม
Thomas Knych (Google), Stefan Ramsauer (Google) และ Valera Zakharov (Google)
คุณพร้อมที่จะรับประทานยาสีแดงแล้วหรือยัง
มือถือได้เปลี่ยนแปลงวิธีการที่มนุษย์โต้ตอบกับคอมพิวเตอร์ ซึ่งนับเป็นเรื่องที่ยอดเยี่ยม แต่ในขณะที่วิศวกรของเรากําลังเผชิญกับเมทริกซ์สภาพแวดล้อมที่เติบโตขึ้นเรื่อยๆ ที่โค้ดของเราทํางาน วันที่พิจารณาเบราว์เซอร์และความละเอียดหน้าจอจํานวนหนึ่งไม่ได้กลับมาใหม่ วิศวกรจะรับมือกับเมตริกซ์อย่างไร เราจะอธิบายวิธีที่ Google รับมือกับปัญหาการทดสอบนี้ในเวิร์กสเตชัน ในระบบคลาวด์ และในหัวของคุณ...
"ผมพยายามปลดปล่อยคุณนะ Neo แต่ฉันเปิดประตูให้ได้อย่างเดียวนะ เจ้าคือคนที่ต้องเดินผ่านมัน"
การทํางานอัตโนมัติสําหรับ UI ของ Android
Guang Zhu (朱光) (Google) และ Adam Momtaz (Google)
เนื่องจาก Android ได้รับความนิยมในโลกมือถือ นักพัฒนาแอปพลิเคชันและผู้ให้บริการ OEM จึงกําลังสํารวจวิธีทดสอบแอปพลิเคชันหรือแพลตฟอร์มทั้งหมดที่ขับเคลื่อนโดย UI ตั้งแต่ต้นจนจบ จากการพูดคุยสั้นๆ เกี่ยวกับโซลูชันการทํางานอัตโนมัติของ UI ที่มีอยู่ใน Android การพูดคุยครั้งนี้จะแนะนําเฟรมเวิร์ก Android UI ที่ทํางานอัตโนมัติที่เพิ่งเปิดตัว และยังคงให้ความเห็นลึกเกี่ยวกับกรอบงาน กรณีการใช้งานและเวิร์กโฟลว์โดยทั่วไป
Appium: การทํางานอัตโนมัติสําหรับแอปบนอุปกรณ์เคลื่อนที่
Jonathan Lipps (ห้องทดลองซอส)
Appium คือเซิร์ฟเวอร์ Node.js ที่ใช้แอปพลิเคชันมือถือแบบเนทีฟและแบบไฮบริดโดยอัตโนมัติ (ทั้ง iOS และ Android) ปรัชญาของ Appium กําหนดว่าต้องไม่มีการแก้ไขแอปพลิเคชันเพื่อที่จะเป็นระบบอัตโนมัติ และคุณควรสามารถเขียนรหัสการทดสอบของคุณในภาษาหรือกรอบการทํางานใดๆ ผลที่ได้คือเซิร์ฟเวอร์ Selenium WebDriver ที่พูดภาษาเดียวกับอุปกรณ์เคลื่อนที่ Appium ทํางานบนอุปกรณ์และตัวจําลองจริง และเป็นโอเพนซอร์สโดยสมบูรณ์ ช่วยให้การเริ่มต้นทดสอบการทํางานอัตโนมัติบนอุปกรณ์เคลื่อนที่เป็นวิธีที่ดี ในการพูดคุยนี้ ฉันจะร่างหลักการที่กล่าวถึงการออกแบบของ Appium, พูดคุยเกี่ยวกับ Appium ในกรอบของกรอบการทํางานอัตโนมัติของมือถืออื่นๆ และแนะนําสถาปัตยกรรมที่ทําให้เกิดความมหัศจรรย์ สุดท้ายนี้ ฉันจะเจาะลึกโค้ดเพื่อการทดสอบแบบง่ายๆ สําหรับแอปบนอุปกรณ์เคลื่อนที่ใหม่และสาธิต Appium ที่ใช้การทดสอบนี้ใน iPhone และ Android
การสร้างโครงสร้างพื้นฐานของการทดสอบสําหรับอุปกรณ์เคลื่อนที่ที่รองรับการปรับขนาดสําหรับ Google+ มือถือ
Eduardo Bravo (Google)
การทดสอบแอปที่มาพร้อมเครื่องอย่างมีความหมาย เสถียร และปรับขนาดได้ถือเป็นสิ่งที่ท้าทาย G+ ได้พัฒนาโซลูชันที่มีประสิทธิภาพเพื่อรับมือกับปัญหาเหล่านี้ด้วยการนําเสนอโครงสร้างพื้นฐานที่เหมาะสมสําหรับแต่ละสถานการณ์การทดสอบที่ซับซ้อนซึ่งอุปกรณ์เคลื่อนที่นําเสนอ โครงสร้างพื้นฐานในการทดสอบปัจจุบันของเรานําเสนอเครื่องมือที่เหมาะสมสําหรับทั้งแอป iOS และ Android เพื่อให้ทีมที่กําลังพัฒนาของเรามั่นใจได้ว่าการเปลี่ยนแปลงใหม่ๆ จะไม่ทําลายลูกค้าที่มีอยู่
Espresso: ทดสอบ UI ใหม่ของ Android
Valera Zakharov (Google)
อัปเดต [ตุลาคม 2013]: เอสเปรสโซเป็นโอเพนซอร์ส โปรดดู https://code.google.com/p/android-test-kit/
การพัฒนาการทดสอบ Android ที่เชื่อถือได้นั้นควรจะรวดเร็วและง่ายดายพอๆ กับการถ่ายภาพเอสเพรสโซ แต่การใช้เครื่องมือที่มีอยู่แล้ว คุณอาจรู้สึกว่าการทําช็อตคาราเมลคู่ซอสนี้จะเติมคําเดียวแต่มักจะไม่ค่อยสับสน Espresso เป็นเฟรมเวิร์กการทดสอบ Android แบบใหม่ที่ให้คุณเขียนการทดสอบ UI ให้กระชับ สวยงาม และเชื่อถือได้ได้อย่างรวดเร็ว API หลักมีขนาดเล็ก คาดเดาได้ และเรียนรู้ได้ง่าย แต่ก็เปิดให้มีการปรับแต่งด้วย การทดสอบเอสเพรสโซ่ระบุความคาดหวัง การโต้ตอบ และการยืนยันอย่างชัดเจน โดยไม่สร้างความรําคาญให้กับต้นแบบ โครงสร้างพื้นฐานที่กําหนดเอง หรือรายละเอียดการใช้งานที่ยุ่งเหยิงของคุณ การทดสอบทํางานได้รวดเร็วที่สุด ปล่อยให้การรอ การซิงค์ การนอน และแบบสํารวจทําหาย และให้เฟรมเวิร์กปรับเปลี่ยนและยืนยันใน UI ของคุณได้ดีเมื่อไม่ได้ใช้งาน เริ่มสนุกกับการเขียนและการดําเนินการทดสอบ UI แล้วลองกด Espresso
การทดสอบประสิทธิภาพเว็บด้วย WebDriver
Michael Klepikov (Google)
ในการทดสอบประสิทธิภาพของเว็บ เรารู้วิธีวิเคราะห์การโหลดหน้าเว็บเป็นอย่างดี เราต้องไปไกลกว่าการโหลดหน้าเว็บ: แอปที่ทันสมัยเป็นแบบอินเทอร์แอ็กทีฟสูง และปฏิบัติการมักจะไม่โหลดซ้ําทั้งหน้า แต่จะอัปเดตอีกครั้ง หลายๆ คนที่ผมได้รวมอยู่ด้วย ได้ผสานรวม WebDriver เข้ากับชุดการทดสอบประสิทธิภาพบนเว็บ ซึ่งช่วยให้การทดสอบประสิทธิภาพแยกออกมาต่างหากจากชุดการทดสอบ UI ส่วนที่เหลือ ผมขอเสนอสร้างคุณลักษณะการทดสอบประสิทธิภาพโดยตรงใน WebDriver โดยใช้ประโยชน์จาก Logging API ที่เพิ่มเข้ามาล่าสุด ซึ่งช่วยให้คุณรวบรวมเมตริกประสิทธิภาพขณะทําการทดสอบการทํางานตามปกติ ซึ่งจะช่วยให้ผสานรวมการทดสอบประสิทธิภาพกับการพัฒนาและขั้นตอนการทดสอบโดยรวมได้ราบรื่นยิ่งขึ้น นอกจากนี้ยังรบกวนการสร้างบิลด์/เครื่องมือทดสอบที่กําหนดเองที่องค์กรขนาดใหญ่เกือบทั้งหมดสร้างขึ้นน้อยมาก
ฉันจะสาธิตเรื่องนี้ด้วย ChromeDriver รุ่นใหม่ (WebDriver สําหรับเบราว์เซอร์ Chromium)
การทดสอบข้อมูลแผนที่อย่างต่อเนื่อง
Yvette Nameth (Google) และ Brendan Dhein (Google)
โดยทั่วไปแล้ว การทดสอบแบบต่อเนื่องเป็นเรื่องเกี่ยวกับการเรียกใช้การทดสอบหน่วยและการทดสอบการรวมระบบ แต่เมื่อข้อมูลที่เซิร์ฟเวอร์ของคุณประมวลผลเป็นสาเหตุของการเปลี่ยนแปลงมากที่สุด แน่ใจได้อย่างไรว่าผู้บริโภคข้อมูลยังคงใช้ประโยชน์ได้และไม่มีสิ่งใดขัดข้องภายใต้อัตราการเปลี่ยนแปลงหรือการเปลี่ยนแปลงที่ไม่ดี เราจะพูดคุยเกี่ยวกับเทคนิคสําหรับการทดสอบข้อมูลอย่างต่อเนื่องด้วยตัวอย่างจาก Google แผนที่
การค้นหาผู้มีส่วนเกี่ยวข้องโดยอัตโนมัติในบิวด์ที่ล้มเหลว - ใครเป็นผู้สร้างงานสร้างบ้าง
Celal Ziftci (UCSD) และ Vivek Ramavajjala (Google)
การสร้างอย่างต่อเนื่องคือหนึ่งในโครงสร้างพื้นฐานหลักใน Google เมื่อบิวด์ล้มเหลว จะต้องระบุรายการเปลี่ยนแปลง (Culprit Changelist) (CL)/รายการการเปลี่ยนแปลงอย่างรวดเร็ว เพื่อให้ได้รับการแก้ไขให้เป็นสีเขียว
โซลูชันการตรวจจับการกระทํามีอยู่ทั้งในรุ่นเล็กและขนาดกลาง แต่ไม่มีสําหรับการผสานรวมขนาดใหญ่
โปรแกรมค้นหาผู้ต้องผิดของเรามุ่งหา culprit CL สําหรับบิวด์ขนาดใหญ่โดยอัตโนมัติในช่วงเวลาสั้นๆ ที่ประสบความสําเร็จสูง จากการใช้งานจริงบนหลายโปรเจ็กต์ในช่วง 9 เดือนที่ผ่านมา ผู้หาสาเหตุของปัญหาอาจให้ผลลัพธ์ที่น่าสนใจ มาพูดคุยกับเราเพื่อดูว่าเราใช้เครื่องมือตรวจจับผู้กระทําผิดอย่างไร วิธีการนี้ประสบความสําเร็จได้จริงแค่ไหน รวมถึงรู้สึกว่าเป็นอย่างไรและมีลักษณะอย่างไร
การตรวจสอบเชิงคุณภาพเรื่องสายผลิตภัณฑ์ซอฟต์แวร์
Katerina Goseva-Popstojanova (มหาวิทยาลัยเวสต์เวอร์จิเนีย)
สายผลิตภัณฑ์ซอฟต์แวร์แสดงให้เห็นถึงความคล้ายคลึงกันสูงในบรรดาระบบต่างๆ ในสายผลิตภัณฑ์หนึ่งและมีจํานวนตัวแปรที่เป็นไปได้เป็นอย่างดี จากข้อมูลที่ดึงมาจากกรณีศึกษา 2 สาย ได้แก่ สายผลิตภัณฑ์อุตสาหกรรมขนาดกลางและสายผลิตภัณฑ์โอเพนซอร์สขนาดใหญ่ที่พัฒนาขึ้นเรื่อยๆ เราได้สํารวจแนวทางต่างๆ อย่างชัดเจนหากการใช้ระบบอย่างเป็นระบบอีกครั้งช่วยปรับปรุงคุณภาพและสนับสนุนความบกพร่องในอนาคตที่เป็นไปได้ซึ่งเกิดจากความผิด เมตริกซอร์สโค้ด และเมตริกการเปลี่ยนแปลงที่ประสบความสําเร็จก่อนหน้านี้ จากผลการวิจัยของเรา ในการตั้งค่าสายผลิตภัณฑ์ซอฟต์แวร์ ผลการสืบค้นของผู้อื่นที่เป็นความผิดสําคัญต่อเมตริกการเปลี่ยนแปลงมากกว่าเมื่อเทียบกับเมตริกโค้ดแบบคงที่ ผลการประเมินคุณภาพแสดงให้เห็นว่าแม้ว่าแพ็กเกจแบบเก่า (รวมถึงแบบทั่วไป) จะมีการเปลี่ยนแปลงอย่างต่อเนื่อง แต่ยังคงมีความหนาแน่นต่ํา ยิ่งไปกว่านั้น สายผลิตภัณฑ์โอเพนซอร์สยังมีคุณภาพเพิ่มขึ้นเมื่อมีการพัฒนาไปจนถึงรุ่นต่างๆ การคาดการณ์ตามโมเดลการถดถอยเชิงเส้นทั่วไปและจัดอันดับแพ็กเกจอย่างถูกต้องตามข้อผิดพลาดหลังการเผยแพร่โดยใช้โมเดลที่สร้างขึ้นในรุ่นก่อนหน้า ผลลัพธ์ยังเผยให้เห็นว่าการคาดการณ์ผิดพลาดหลังจากเผยแพร่นั้นได้รับประโยชน์จากข้อมูลสายผลิตภัณฑ์เพิ่มเติมแล้ว
AddressSanitizer, ThreadSanitizer และ MemorySanitizer -- เครื่องมือทดสอบแบบไดนามิกสําหรับ C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) คือเครื่องมือที่ใช้ค้นหาการล้นของบัฟเฟอร์ (ในสแต็ก ฮีพ และทั่วโลก) รวมถึงข้อบกพร่องหลังการใช้งานในโปรแกรม C/C++ ThreadSanitizer (TSan) พบการแข่งขันด้านข้อมูลในโปรแกรม C/C++ และ Go MemorySanitizer (MSan) คือเครื่องมือที่อยู่ระหว่างดําเนินการ ซึ่งจะค้นหาการใช้หน่วยความจําที่ไม่ได้เริ่มต้น (C++) เครื่องมือเหล่านี้จะอ้างอิงจากเครื่องมือคอมไพเลอร์ (LLVM และ GCC) ซึ่งทําให้ทํางานได้รวดเร็วมาก (เช่น ASan ให้บริการช้ากว่า 2 เท่า) เราจะแชร์ประสบการณ์ในการทดสอบขนาดใหญ่โดยใช้เครื่องมือเหล่านี้
สรุปประเด็นสําคัญ - การดื่มมหาสมุทร - การค้นหา XSS ที่มาตราส่วน Google
Claudio Criscione (Google)
การใช้สคริปต์ข้ามไซต์หรือ XSS เป็นแนวคิดเทียบเท่าสมัยใหม่ในยุคปัจจุบันของกลุ่มคนผิวดําวัยกลางคน สําหรับเว็บแอปพลิเคชัน แพร่หลายไปในทางที่ไม่ดี แย่มาก และไม่มีวิธีทางเทคนิคที่จะตรวจพบได้เลยจนกว่าจะสายเกินไป DOM XSS เป็นรูปแบบที่ไม่เหมาะสมอย่างยิ่ง เนื่องจากต้องใช้เบราว์เซอร์จริงหรือเทียบเท่าที่สามารถตรวจพบได้ เป็นปัญหายากที่มีโซลูชันอัตโนมัติเพียงเล็กน้อย
เราต้องการเครื่องมือที่ขับเคลื่อนได้เองและมีประสิทธิภาพเพื่อระบุ DOM XSS ตั้งแต่เนิ่นๆ ในวงจรการพัฒนา ซึ่งวิศวกรที่อยู่นอกทีมความปลอดภัยก็ใช้งานได้ ทั้งหมดนี้คือผลิตภัณฑ์ที่สามารถสแกนคลังข้อมูลแอปพลิเคชันขนาดใหญ่ ทํางานได้รวดเร็ว ซับซ้อน และอวดโฉม... และแน่นอนยังไม่พบ เราจึงสร้างโปรแกรมสแกนเว็บแอปพลิเคชันที่กําหนดเป้าหมายเป็น DOM XSS ซึ่งออกแบบมาตามเทคโนโลยีมาตรฐานของ Google โดยจะทํางานใน App Engine และใช้ประโยชน์จากเบราว์เซอร์ Chrome ที่มีประสิทธิภาพและ CPU หลายร้อยรายการในฐานะแพลตฟอร์มการสแกนความปลอดภัย
ทั้งยังเป็นพลเมืองที่ดีของคลังสรรพาวุธการทดสอบที่ Google ด้วย ซึ่งอยู่ภายในโครงสร้างพื้นฐานในการทดสอบของเรา แทนที่จะเป็นเครื่องมือของทีมรักษาความปลอดภัย
ในการพูดคุยครั้งนี้ เราสรุปเกี่ยวกับแนวทางใหม่ของเรา ความท้าทายที่เราพบในการปรับขนาดระบบให้เป็นขนาดของ Google และแนวคิดเบื้องหลังโมเดลการตรวจหาและการรวบรวมข้อมูลในแอปพลิเคชันที่ใช้ JavaScript อย่างเข้มข้น