Nhận xét Mở đầu
Tony Voellm (Google)
Liên kết: Video
Bài phát biểu khai mạc - Sự phát triển từ việc đảm bảo chất lượng đến kỹ thuật kiểm thử
Ari Shamash (Google)
Bạn đã tạo một ứng dụng. Bạn đã chạy ứng dụng này. Bạn đã nghĩ là mình sẽ thu được kết quả, xây dựng một số khối lượng, tìm nguồn tài trợ, bỏ hết và sau đó bắt đầu từ đầu để có thể "làm đúng". Tuy nhiên, nhu cầu sử dụng các tính năng mới rất cao. Giờ đây, bạn đang được yêu cầu đẩy nhanh tiến độ chưa từng có với tốc độ chưa từng có. Rất tiếc! Bây giờ bạn phải làm gì?
Bạn không thể bỏ nó đi và bắt đầu từ đầu, bạn chỉ cần phát triển những gì bạn có, trong khi tiếp tục thêm các tính năng chất lượng cao với tốc độ ngoạn mục. Ngoài ra, bạn cần đảm bảo những nội dung đã có không bị lỗi. Bạn làm việc này như thế nào? May mắn thay, một lĩnh vực mới đang hình thành trong ngành kỹ thuật phần mềm giải quyết tình huống chung này: tại Google, chúng tôi gọi đây là "kỹ thuật thử nghiệm".
Buổi nói chuyện này sẽ tập trung vào khái niệm kỹ thuật thử nghiệm, quá trình phát triển từ quá trình đảm bảo chất lượng và toàn bộ ngành đã triển khai kỹ thuật thử nghiệm như thế nào (kèm theo ví dụ cụ thể về cách triển khai tại Google).
Đường liên kết: Video, Trang trình bày
Hệ thống thử nghiệm trên quy mô lớn @Twitter
James Waldrop (Twitter)
James sẽ thảo luận về các công cụ, quy trình và triết lý dùng trong việc thử nghiệm hiệu suất trên Twitter. Đặc biệt chú trọng vào thư viện thử nghiệm nguồn mở Iago mà ông đã viết để hỗ trợ các nhóm kỹ thuật của Twitter thực hiện thử nghiệm tải trước khi triển khai mã vào sản xuất. Buổi nói chuyện sẽ đi sâu vào chi tiết triển khai của một số kiểm thử trong số này (bao gồm cả mã nguồn) và cách quản lý các yếu tố phức tạp như OAuth và giao thức Thrift tùy ý.
Đường liên kết: Video, Trang trình bày
Bạn kiểm tra hệ điều hành di động bằng cách nào?
David Burns (Mozilla) và Malini Das (Mozilla)
Đây là vấn đề đã gặp phải với Mozilla khi chúng tôi quyết định dấn thân vào thế giới của FirefoxOS. Bắt đầu từ đâu và làm như thế nào để chứng minh một nhiệm vụ thú vị. Hãy lắng nghe cách chúng tôi giải quyết vấn đề này và cách chúng tôi tạo ra một khuôn khổ mới.
Đường liên kết: Video, Trang trình bày
Tự động hóa thiết bị di động trong quy trình phân phối liên tục
Igor Dorovskikh (Expedia) và Kaustubh Gawande (Expedia)
Expedia bắt đầu đầu tư vào Web di động và ứng dụng iOS/Android vào đầu năm 2012. Đồng thời, các Kỹ sư kiểm thử cũng bắt đầu phát triển các giải pháp tự động hoá kiểm thử để xây dựng các sản phẩm có chất lượng và khả năng kiểm thử ngay từ đầu. Trong buổi nói chuyện này, chúng tôi sẽ chia sẻ kinh nghiệm và kiến thức của mình về việc sử dụng các công cụ nguồn mở để xây dựng quy trình kiểm thử tự động trong môi trường phát triển và phân phối liên tục của Expedia. Chúng ta sẽ thảo luận về Kim tự tháp thử nghiệm và đi sâu hơn về các công cụ nguồn mở cụ thể đã mang lại hiệu quả cho chúng ta. Một số công cụ nguồn mở mà chúng tôi sử dụng là các công cụ BDD như Cucumber, công cụ tự động hóa web Selenium-WebDriver, công cụ tự động hóa iOS Frank, các công cụ tự động hóa Android Robotium và Calabash, và hệ thống Tích hợp liên tục Jenkins. Ngoài ra, chúng tôi cũng sẽ chia sẻ một số nguyên tắc phân phối Agile mà chúng tôi cố gắng áp dụng như TDD, Lập trình theo cặp, Xây dựng và Thử nghiệm bộ tản nhiệt. Cuối cùng, chúng tôi sẽ chia sẻ một số lợi ích nhận được từ việc đầu tư vào Agile và tự động hóa thử nghiệm cũng như cách điều đó giúp chúng tôi đạt được mục tiêu Phân phối liên tục.
Đường liên kết: Video, Trang trình bày
Thử nghiệm giải mã tín hiệu tự động bằng GStreamer và OpenCV
David Röthlisberger (YouView)
Chúng tôi sẽ xây dựng một hệ thống nhận dạng hình ảnh quay video trong 3 phút, sử dụng các công cụ dòng lệnh và OpenCV của GStreamer. (GStreamer là khung xử lý phương tiện nguồn mở; OpenCV —"Open Computer Vision"—Tiện ích xử lý hình ảnh nguồn mở.)
Một ví dụ hàng đầu về hệ thống này là http://stb-tester.com, một công cụ nguồn mở được phát triển tại YouView để tự động hóa việc kiểm tra giao diện người dùng trên các hộp giải mã tín hiệu số của chúng tôi. Chúng tôi sẽ mô tả stb-tester, tính linh hoạt được cung cấp bởi nền tảng GStreamer của nó, một số khả năng mà nó mở ra và những thách thức phía trước.
Đường liên kết: Video
Webdriver dành cho Chrome
Ken Kania (Google)
Từ ban đầu là trình duyệt chỉ có Windows, Chrome đã mở rộng sang Mac, Linux, ChromeOS và mới nhất là Android và iOS. Thử nghiệm ứng dụng web ở cấp người dùng trên các nền tảng này đã gặp khó khăn và đòi hỏi nhiều phương pháp tự động hóa khác nhau. Buổi trò chuyện này sẽ mô tả công việc mà nhóm Chrome đang thực hiện để cung cấp WebDriver cho Chrome trên tất cả các nền tảng. Điều này sẽ bao gồm cái nhìn kỹ thuật về phương pháp cơ bản nhưng sẽ tập trung vào cách nhà phát triển có thể sử dụng ChromeDriver mới để viết thử nghiệm cho các nền tảng khác nhau của Chrome. Ngoài ra, trạng thái hiện tại của dự án và lộ trình cho tương lai của dự án cũng sẽ được đề cập.
Đường liên kết: Video, Trang trình bày
Karma - Trình chạy kiểm thử JavaScript
Vojta Jina (Google)
Giới thiệu về Karma - trình chạy kiểm thử giúp kiểm thử các ứng dụng JavaScript trong trình duyệt thực dễ dàng và thú vị.
Bạn không bắt buộc phải thử nghiệm khi đang xây dựng một ứng dụng JavaScript phải hoạt động trên nhiều trình duyệt và thiết bị. Tuy nhiên, việc thực thi kiểm thử trong tất cả các môi trường này là khó. Karma biến công việc này thường là một công việc khó khăn thành một chiếc bánh. Công cụ này cho phép bạn thực thi kiểm thử JavaScript trong trình duyệt hoặc thiết bị thực, chẳng hạn như điện thoại hoặc máy tính bảng, ngay trên thiết bị thanh toán hoặc IDE mà bạn yêu thích.
Đường liên kết: Video
Đo lường chất lượng video tự động
Patrik Höglund (Google)
Có, bạn có thể tự động kiểm tra các phép đo phức tạp, chủ quan như chất lượng video! Buổi trò chuyện này sẽ trình bày cách chúng tôi thực hiện thử nghiệm toàn diện tự động, liên tục cho cuộc gọi video WebRTC. Chúng ta sẽ tìm hiểu về chuỗi công cụ ở cấp cao và những thách thức chúng ta phải đối mặt khi xây dựng chuỗi này. Đây là lựa chọn hoàn hảo nếu bạn muốn tìm nguồn cảm hứng để nâng tầm thử nghiệm nội dung nghe nhìn.
Đường liên kết: Video, Trang trình bày
Khi điều xấu xảy ra với ứng dụng tốt...
Minal Mishra (Netflix)
Sự bùng nổ của điện toán di động và máy tính bảng đã làm tràn ngập ngành công nghiệp phần mềm với các nền tảng phát triển ứng dụng. Phát triển ứng dụng tiêu dùng trên các nền tảng điện toán mang lại trải nghiệm kỳ diệu của riêng họ cho người dùng cuối. Các công ty phần mềm hướng đến người tiêu dùng luôn cố gắng phát huy hết khả năng khi họ phát triển một ứng dụng dành cho các nền tảng này. Tuy nhiên, thách thức lớn nhất trong việc phát triển ứng dụng chỉ bắt đầu sau khi các công ty triển khai phiên bản đầu tiên của ứng dụng. Người tiêu dùng và các công ty phần mềm muốn được phát triển các tính năng và chức năng mới nhất càng sớm càng tốt với chất lượng cao nhất. Điều này dẫn đến việc rời bỏ mã không ngừng trong mọi lớp của ngăn xếp. Chúng tôi, những kỹ sư về giao diện người dùng, tự động xây dựng nhiều hệ thống phát hiện sớm để phát hiện các sự cố của ứng dụng. Trong buổi nói chuyện này, tôi sẽ chia sẻ một số thách thức và thành công của chúng tôi đằng sau một hệ thống phát hiện như vậy. Hệ thống đó đã giúp tìm ra các vấn đề bên ngoài lớp ứng dụng nhưng vẫn ảnh hưởng tiêu cực đến trải nghiệm người dùng.
Đường liên kết: Video, Trang trình bày
Thử nghiệm trò chơi mang tính giáo dục và trò chơi giáo dục để thử nghiệm
Tao Xie (Đại học bang North Carolina)
Buổi trò chuyện này giới thiệu Pex4Fun (http://www.pexforfun.com/), tận dụng tính năng tạo thử nghiệm tự động để làm cơ sở cho việc chấm điểm tự động trong hệ thống lập trình trực tuyến có thể mở rộng quy mô đến hàng trăm nghìn người dùng. Nền tảng này mang lại trải nghiệm chơi tập trung vào chương trình bên ngoài lớp học, giúp người dùng học các kỹ năng lập trình và kỹ thuật phần mềm, bao gồm cả kỹ năng kiểm thử, chẳng hạn như viết mã kiểm thử đơn vị. Pex4Fun góp phần đáng kể vào vấn đề đã biết khi chấm điểm bài tập, cũng như mang đến trải nghiệm học tập thú vị dựa trên trò chơi tương tác. Pex4Fun đã trở nên phổ biến cao trong cộng đồng: kể từ khi nó được phát hành ra công chúng vào tháng 6 năm 2010, số lần nhấp vào nút "Hỏi Pex!" (cho thấy nỗ lực của người dùng để giải quyết các trò chơi tại Pex4Fun) đã đạt hơn một triệu vào đầu năm 2013.
Đường liên kết: Video, Trang trình bày
Bế mạc bài phát biểu - Cách Facebook thử nghiệm Facebook trên Android
Simon Stewart (Facebook)
Facebook là một trong những ứng dụng Android phổ biến nhất hiện có. Trong cuộc trò chuyện này, bạn sẽ tìm thấy những gì Facebook làm để đảm bảo rằng mỗi bản phát hành đều tốt. Chúng tôi sẽ trình bày mọi việc, từ cách quản lý mã, cho đến các phương pháp thử nghiệm và cả việc thử nghiệm nội bộ.
Đường liên kết: Video, Trang trình bày
Bài phát biểu khai mạc - JavaScript có thể kiểm tra - Kiến trúc ứng dụng của bạn để kiểm tra
Mark Trostler (Google)
JavaScript có thể thử nghiệm là một quá trình. Dù bắt đầu với một phương tiện chặn trống hay một ứng dụng đã triển khai (hoặc một nơi nào đó ở giữa), thì việc có thể kiểm tra mã JavaScript một cách đơn giản, rõ ràng và hiệu quả là một tính năng cần thiết. Mã không thể kiểm tra sẽ được viết lại.
Mặc dù JavaScript là duy nhất do vô số môi trường mà JavaScript chạy, nhưng có một số phương pháp có thể thử nghiệm và 'có thể thử nghiệm' thực sự từ các ngôn ngữ khác cũng đúng với JavaScript. Và tất nhiên vẫn còn những thách thức duy nhất mà các nhà phát triển JavaScript phải đối mặt khi viết và thử nghiệm mã của họ.
Các mẫu nào giúp mã có thể kiểm thử được? Mẫu hình nào cản trở việc thử nghiệm? Bạn có thể sử dụng các chỉ số và cột chỉ dẫn chung nào để đo lường khả năng kiểm thử của mã? Sau khi quá trình tạo mã có thể kiểm thử bắt đầu, bây giờ bạn phải làm gì?
Hãy cùng tôi chia nhỏ quy trình viết JavaScript có thể thử nghiệm. Chúng tôi sẽ điều tra các ý tưởng, mẫu và phương pháp giúp tăng đáng kể khả năng thử nghiệm, từ đó duy trì khả năng bảo trì, độ chính xác và tuổi thọ của mã. Cho dù bạn viết mã JavaScript phía máy khách hay phía máy chủ thì quá trình này đều sẽ nâng cao chất lượng mã của bạn.
Đường liên kết: Video, Trang trình bày
Phá bỏ ma trận – Thử nghiệm Android trên quy mô lớn
Thomas Knych (Google), Stefan Ramsauer (Google) và Valera Zakharov (Google)
Bạn đã sẵn sàng uống viên thuốc màu đỏ chưa?
Thiết bị di động đã thay đổi cách con người tương tác với máy tính. Điều này thật tuyệt, nhưng là một kỹ sư, chúng tôi đang phải đối mặt với ma trận môi trường ngày càng tăng mà mã của chúng tôi chạy trên đó. Những ngày chỉ xem xét một vài trình duyệt và độ phân giải màn hình sẽ không trở lại. Các kỹ sư có thể đối phó với Matrix như thế nào? Chúng tôi sẽ trình bày cách Google chiến đấu với vấn đề thử nghiệm này trên các máy trạm, trên đám mây và trong đầu...
"Tôi đang cố gắng giải phóng tâm trí của bạn, Neo. Nhưng tôi chỉ có thể cho bạn xem cửa. Bạn là người phải vượt qua."
Đường liên kết: Video, Trang trình bày
Tự động hóa giao diện người dùng Android
Guang Zhu (朱光) (Google) và Adam Momtaz (Google)
Khi Android trở nên phổ biến trong thế giới di động, các nhà phát triển ứng dụng và nhà cung cấp OEM đang khám phá các cách thực hiện thử nghiệm giao diện người dùng toàn diện dựa trên ứng dụng hoặc toàn bộ nền tảng. Với bài đánh giá ngắn gọn về các giải pháp Tự động hóa giao diện người dùng hiện có trên Android, buổi trò chuyện này giới thiệu khung tự động hóa giao diện người dùng Android mới phát hành gần đây, đồng thời tiếp tục giới thiệu chi tiết về khung, các trường hợp sử dụng và quy trình làm việc điển hình.
Đường liên kết: Video, Trang trình bày
Appium: Tự động hóa cho ứng dụng dành cho thiết bị di động
Jonathan Lipps (Phòng thí nghiệm nước sốt)
Appium là một máy chủ Node.js tự động hóa các ứng dụng gốc và ứng dụng dành cho thiết bị di động kết hợp (cả iOS và Android). Theo triết lý của Appium, ứng dụng không được sửa đổi để được tự động hoá và bạn có thể viết mã kiểm thử bằng bất kỳ ngôn ngữ hoặc khung nào. Kết quả là máy chủ Selenium WebDriver hỗ trợ thiết bị di động như người bản ngữ. Appium chạy trên các thiết bị và trình mô phỏng thực tế và là một nguồn mở hoàn toàn, giúp ứng dụng trở thành một phương tiện tuyệt vời để bắt đầu tự động hoá quy trình kiểm thử trên thiết bị di động. Trong buổi nói chuyện này, tôi sẽ trình bày các nguyên tắc thông báo cho thiết kế của Appium, trình bày về Appium trong không gian của các khung tự động hóa di động khác và giới thiệu kiến trúc tạo nên điều kỳ diệu. Cuối cùng, tôi sẽ đi sâu vào mã cho một thử nghiệm đơn giản về ứng dụng dành cho thiết bị di động hoàn toàn mới và minh họa Appium chạy thử nghiệm này trên iPhone và Android.
Đường liên kết: Video, Trang trình bày
Xây dựng cơ sở hạ tầng thử nghiệm trên thiết bị di động có thể mở rộng cho Google+ dành cho di động
Eduardo Bravo (Google)
Thử nghiệm các ứng dụng gốc theo cách có ý nghĩa, ổn định và có thể mở rộng là một thách thức. G+ đã phát triển các giải pháp hiệu quả để giải quyết những vấn đề này bằng cách cung cấp cơ sở hạ tầng phù hợp cho từng tình huống thử nghiệm phức tạp mà thiết bị di động trình bày. Cơ sở hạ tầng thử nghiệm hiện tại của chúng tôi cung cấp các công cụ phù hợp cho cả ứng dụng iOS và Android để giúp nhóm phát triển của chúng tôi tự tin rằng các thay đổi mới sẽ không làm hỏng các khách hàng hiện tại.
Đường liên kết: Video, Trang trình bày
Espresso: Khởi đầu mới: Thử nghiệm giao diện người dùng Android
Valera Zakharov (Google)
Cập nhật [Tháng 10 năm 2013]: Espresso hiện là nguồn mở. Hãy xem https://code.google.com/p/android-test-kit/.
Việc phát triển một chương trình kiểm thử đáng tin cậy trên Android phải nhanh chóng và dễ dàng như việc kéo một ly cà phê espresso. Thật không may, với các công cụ hiện có, bạn có thể sẽ cảm thấy giống như việc pha một ly cà phê caramel-sauce-upside-down-single-whip-Half-decaf-latte - gây nhầm lẫn và hiếm khi nhất quán. Espresso là một khung kiểm thử mới trên Android cho phép bạn viết mã kiểm thử giao diện người dùng ngắn gọn, đẹp mắt và đáng tin cậy một cách nhanh chóng. API cốt lõi có quy mô nhỏ, dễ dự đoán và dễ học nhưng cũng mở để tùy chỉnh. Các thử nghiệm Espresso cho biết rõ ràng các kỳ vọng, tương tác và khẳng định của họ một cách rõ ràng mà không gây mất tập trung với nguyên mẫu, cơ sở hạ tầng tuỳ chỉnh hoặc chi tiết triển khai lộn xộn. Các thử nghiệm sẽ chạy nhanh một cách tối ưu – cho phép bạn chờ, đồng bộ hoá, ngủ và tham gia các cuộc thăm dò ý kiến. Đồng thời, khung này cũng dễ dàng thao tác và xác nhận trên giao diện người dùng của bạn ngay cả khi ở trạng thái nghỉ. Bắt đầu viết và thực thi kiểm thử giao diện người dùng – hãy thử Espresso.
Đường liên kết: Video, Trang trình bày
Kiểm tra hiệu suất web với WebDriver
Michael Klepikov (Google)
Trong kiểm tra hiệu suất web, chúng tôi biết khá rõ cách phân tích tải trang. Tuy nhiên, chúng ta cần phải vượt qua tải trang: các ứng dụng hiện đại có tính tương tác cao và hoạt động có xu hướng không tải lại toàn bộ trang, mà cập nhật trang. Những người khác nhau (bao gồm cả tôi) đã tích hợp WebDriver vào các trình kiểm thử hiệu suất web. Điều này rất hữu ích, nhưng vẫn tách biệt các bài kiểm thử hiệu suất với phần còn lại của bộ kiểm thử giao diện người dùng. Tôi đề xuất tích hợp các tính năng thử nghiệm hiệu suất vào chính WebDriver, tận dụng API ghi nhật ký mà chúng tôi mới thêm gần đây. Điều này giúp bạn có thể thu thập các chỉ số về hiệu suất trong khi chạy kiểm thử chức năng thông thường, cho phép tích hợp liền mạch hơn nhiều kiểm thử hiệu suất vào quy trình phát triển và kiểm thử tổng thể. Điều này cũng ít gây gián đoạn hơn nhiều đối với chuỗi công cụ xây dựng/kiểm thử tuỳ chỉnh mà hầu hết mọi tổ chức lớn đều tạo ra.
Tôi sẽ minh hoạ điều này bằng ChromeDriver thế hệ mới (WebDriver dành cho trình duyệt Chromium).
Đường liên kết: Video, Trang trình bày
Kiểm thử Dữ liệu Bản đồ Liên tục
Yvette Nameth (Google) và Brendan Dhein (Google)
Kiểm thử liên tục thường là về việc chạy kiểm thử đơn vị và kiểm thử tích hợp. Nhưng khi dữ liệu mà máy chủ của bạn xử lý thực sự là nguyên nhân lớn nhất gây ra sự thay đổi, làm cách nào để bạn đảm bảo rằng người tiêu dùng dữ liệu vẫn có thể sử dụng dữ liệu đó và không có sự cố nào trong tốc độ thay đổi hoặc thay đổi không tốt? Chúng ta sẽ thảo luận về các kỹ thuật kiểm tra dữ liệu liên tục với các ví dụ từ Google Maps.
Đường liên kết: Video, Trang trình bày
Tự động tìm ra thủ phạm trong các công trình hư hỏng - tức là ai đã làm hỏng công trình?
Celal Ziftci (UCSD) và Vivek Ramavajjala (Google)
Xây dựng liên tục là một trong những cơ sở hạ tầng quan trọng trong Google. Khi công trình xây dựng bị lỗi, bạn phải nhanh chóng xác định danh sách thay đổi thủ phạm (CL)/danh sách thay đổi nhanh chóng để có thể khắc phục nhằm khôi phục công trình xây dựng trở lại màu xanh lục.
Giải pháp phát hiện thủ phạm tồn tại cho các công trình quy mô vừa và nhỏ, nhưng không dành cho các công trình tích hợp lớn.
Trình tìm kiếm thủ phạm của chúng tôi nhắm mục tiêu tự động tìm CL tới các tòa nhà lớn trong một khung thời gian rất ngắn với thành công cao. Dựa vào quá trình sử dụng dữ liệu sản xuất của nhiều dự án trong 9 tháng qua, công cụ tìm thủ phạm mang lại kết quả rất khả quan. Hãy cùng trò chuyện để xem cách chúng tôi triển khai công cụ tìm kiếm thủ phạm, xác định khả năng thành công của công cụ này trong thực tế, cũng như hiệu quả hoạt động của công cụ này.
Đường liên kết: Video, Trang trình bày
Điều tra thực nghiệm về chất lượng dòng sản phẩm phần mềm
Katerina Goseva-Popstojanova (Đại học Tây Virginia)
Các dòng sản phẩm phần mềm thể hiện mức độ tương đồng cao giữa các hệ thống trong dòng sản phẩm và số lượng biến thể có thể có được chỉ định rõ ràng. Dựa trên dữ liệu được trích xuất từ hai nghiên cứu điển hình - dòng sản phẩm công nghiệp quy mô trung bình và dòng sản phẩm nguồn mở lớn, ngày càng phát triển - chúng tôi đã khám phá theo kinh nghiệm nếu việc sử dụng lại có hệ thống sẽ cải thiện chất lượng và hỗ trợ dự đoán thành công các lỗi tiềm ẩn trong tương lai từ các lỗi đã gặp phải trước đó, số liệu mã nguồn và thay đổi số liệu. Kết quả nghiên cứu của chúng tôi đã xác nhận rằng trong một cài đặt dòng sản phẩm phần mềm, những phát hiện về các lỗi khác có liên quan chặt chẽ hơn với các chỉ số thay đổi so với các chỉ số mã tĩnh. Kết quả đánh giá chất lượng cho thấy rằng mặc dù các gói cũ (bao gồm các điểm tương đồng) liên tục thay đổi nhưng chúng vẫn giữ được mật độ lỗi thấp. Hơn nữa, dòng sản phẩm nguồn mở đã cải thiện chất lượng trong quá trình phát triển thông qua các bản phát hành. Dự đoán dựa trên mô hình hồi quy tuyến tính tổng quát đã xếp hạng chính xác các gói theo lỗi sau khi phát hành bằng cách sử dụng các mô hình được xây dựng dựa trên bản phát hành trước. Kết quả cũng cho thấy việc dự đoán lỗi sau khi phát hành sẽ giúp ích cho thông tin bổ sung về dòng sản phẩm.
Đường liên kết: Video, Trang trình bày
AddressSanitizer, ThreadSanitizer và MemorySanitizer -- Công cụ kiểm tra động cho C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) là một công cụ tìm lỗi tràn (buffer) trong ngăn xếp, vùng nhớ khối xếp và các lỗi chung) cũng như các lỗi sử dụng sau khi trống trong các chương trình C/C++. ThreadSanitizer (TSan) tìm ra các trường hợp dữ liệu trong chương trình C/C++ và Go. MemorySanitizer (MSan) là một công cụ đang được tiến hành để tìm cách sử dụng bộ nhớ chưa khởi tạo (C++). Các công cụ này dựa trên khả năng đo lường trình biên dịch (LLVM và GCC), khiến các công cụ này có tốc độ rất nhanh (ví dụ: ASan chỉ chịu ảnh hưởng gấp 2 lần). Chúng tôi sẽ chia sẻ kinh nghiệm của mình về quy trình kiểm tra trên quy mô lớn thông qua các công cụ này.
Đường liên kết: Video, Trang trình bày
Bài phát biểu bế mạc - Uống rượu giữa đại dương - Tìm kiếm XSS ở quy mô của Google
Claudio Criscione (Google)
Tập lệnh trên trang web hoặc XSS, tương đương với bệnh dịch hạch đen thời trung cổ trong thế giới ứng dụng web: bệnh này phổ biến, xấu và có ít hoặc không có cách kỹ thuật để phát hiện cho đến khi quá muộn. DOM XSS là một biến thể đặc biệt khó chịu trong số đó vì biến thể này yêu cầu một trình duyệt thực hoặc tương đương để được phát hiện: một vấn đề khó với một số giải pháp tự động sẵn có.
Chúng tôi cần các công cụ tự lái mạnh mẽ để sớm xác định DOM XSS trong vòng đời phát triển. Các kỹ sư bên ngoài nhóm bảo mật không thể sử dụng được tất cả những gì chúng tôi muốn. Tất cả những gì chúng tôi muốn là một sản phẩm có thể quét các tập hợp ứng dụng khổng lồ, di chuyển nhanh, rất phức tạp và phức tạp... và tất nhiên là chúng tôi không tìm thấy gì. Vì vậy, chúng tôi đã xây dựng cho mình một máy quét ứng dụng web nhắm mục tiêu DOM XSS được thiết kế dựa trên các công nghệ chuẩn của Google. Công cụ này chạy trong App Engine và tận dụng trình duyệt Chrome mạnh mẽ cũng như hàng trăm CPU làm nền tảng quét bảo mật.
Đây cũng là một công dân tốt của kho vũ khí thử nghiệm tại Google: nó được xây dựng bên trong cơ sở hạ tầng thử nghiệm của chúng tôi, thay vì là công cụ của nhóm bảo mật.
Trong cuộc trò chuyện này, chúng tôi trình bày phương pháp tiếp cận mới của mình, những thách thức mà chúng tôi phải đối mặt khi mở rộng hệ thống của mình sang Google và những ý tưởng đằng sau các mô hình phát hiện và thu thập thông tin của chúng tôi trên các ứng dụng chuyên sâu về JavaScript.
Đường liên kết: Video, Trang trình bày