การเปิดประเด็นสําคัญ - 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)
การพัฒนาการทดสอบ 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 (UCSD)
การสร้างอย่างต่อเนื่องคือหนึ่งในโครงสร้างพื้นฐานหลักใน 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 อย่างเข้มข้น