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.
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."
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.
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.
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.
Espresso: Khởi đầu mới: Thử nghiệm giao diện người dùng Android
Valera Zakharov (Google)
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.
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).
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.
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 (UCSD)
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.
Đ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.
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.
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.