Nhận xét mở đầu
FirstName Nameth (Google)
Phần mở đầu
Jürgen Allgayer (Google)
Thách thức của Uber trong việc thử nghiệm trên nhiều ứng dụng/thiết bị
Apple Chow (Uber) và Bian Jiang (Uber)
Đường liên kết: Video, Trang trình bày
Ngay sau khi gia nhập Uber vào tháng 3 năm 2015, chúng tôi đã gặp phải một thách thức riêng của Uber trong khi điều tra các công cụ kiểm tra giao diện người dùng cho các ứng dụng di động của mình. Nhiều bài kiểm tra về sự an toàn của chúng ta đòi hỏi chúng ta phải có ứng dụng lái xe và ứng dụng điều khiển có thể giao tiếp/phối hợp hành động với nhau để hoàn thành kịch bản kiểm thử toàn diện. Trong buổi trò chuyện này, chúng tôi sẽ trình bày giải pháp không phụ thuộc vào nền tảng, có tên là Octopus và thảo luận về cách điều phối hoạt động giao tiếp giữa các ứng dụng chạy trên nhiều thiết bị. Giải pháp này có thể áp dụng cho mọi thử nghiệm yêu cầu phối hợp/giao tiếp trên các ứng dụng hoặc thiết bị khác nhau (ví dụ: trò chơi nhiều người dùng, ứng dụng nhắn tin/trao đổi cho nhiều người dùng, v.v.)
Tự động hoá thử nghiệm có hỗ trợ của rô-bốt
Hans Kuosmanen (OptoFidelity) và Natalia Leinonen (OptoFidelity)
Đường liên kết: Video, Trang trình bày
OptoFidelity là công ty công nghệ cao của Phần Lan với 10 năm kinh nghiệm trong việc phát triển và cung cấp các giải pháp tự động hoá thử nghiệm R&D. Buổi trò chuyện này sẽ giới thiệu những trải nghiệm của chúng tôi cũng như góc nhìn sau đây của các phương pháp thử nghiệm không xâm nhập, được sử dụng trong quá trình thử nghiệm hiệu suất của giao diện người dùng trên thiết bị di động. Bạn có biết rằng nhóm Chrome OS sử dụng giải pháp robot của OptoFidelity để đo độ trễ từ đầu đến cuối của các thiết bị Android và ChromeOS?
Cưa xích để giải trí và thu lợi nhuận: Bài học kinh nghiệm từ thử nghiệm tích hợp trên nhiều nền tảng di động
Dan Giovannelli (Google)
Đường liên kết: Video, Trang trình bày
Việc phát triển thiết bị di động không hề đơn giản. Việc xây dựng cơ sở hạ tầng kiểm thử là một việc khó khăn. Làm việc trên nhiều nền tảng là một việc khó khăn. Kết hợp cả ba để có một công thức nấu ăn cho thảm họa. Trong buổi trò chuyện này, Dan Giovannelli sẽ chia sẻ kinh nghiệm về dự án cơ sở hạ tầng thử nghiệm trên nhiều nền tảng di động. Anh ấy sẽ thảo luận về những vấn đề đã xảy ra, những việc đã xảy ra (rất sai sót) và những việc mà anh ấy muốn làm bây giờ để bắt đầu. Hãy xem thông tin chi tiết về cách thiết kế công cụ dành cho thiết bị di động dành cho những kỹ sư không chuyên về thiết bị di động. Đừng quên tìm hiểu ma trận ma trận và cách đánh bại trò chơi đó trong trò chơi của riêng họ.
Tự động hoá kiểm thử trò chơi dành cho thiết bị di động bằng thiết bị thực
Jouko Kaasila (Bitbar/Thử nghiệm)
Đường liên kết: Video, Trang trình bày
Trò chơi dành cho thiết bị di động là danh mục kiếm tiền lớn nhất trong các cửa hàng ứng dụng ngày nay, vì vậy, việc đảm bảo rằng mọi phiên bản của mỗi trò chơi đều hoạt động trên thiết bị của người dùng là ưu tiên cao đối với mọi nhà phát triển trò chơi. Mặc dù tầm quan trọng của việc xác thực là rất nhỏ, nhưng rất ít ví dụ hoặc khung tiêu chuẩn để tự động thử nghiệm trò chơi dành cho thiết bị di động, buộc các nhà phát triển trò chơi phải sử dụng các quy trình kiểm thử thủ công và không mở rộng quy mô đến mức mà các công ty trò chơi cần có được thị trường toàn cầu. Lý do chính là trò chơi trên thiết bị di động có tính chất độc đáo vì chúng truy cập trực tiếp vào màn hình mà bỏ qua tất cả dịch vụ giao diện người dùng do hệ điều hành cung cấp, và kết xuất hầu hết các khung tự động hoá kiểm thử vô ích vì các đối tượng truyền thống sẽ không hiển thị.
May mắn thay, có nhiều cách sử dụng khung tiêu chuẩn tự động hoá cho hoạt động kiểm thử trên thiết bị di động để thúc đẩy quy trình tự động hoá kiểm thử trên các thiết bị di động thực tế trong trò chơi, thông qua việc sử dụng một số thư viện có sẵn và công khai. Trong bản trình bày của mình, Jouko Kaasila đến từ Testdroid sẽ thảo luận về ba phương pháp khác nhau với ví dụ thực tế và một số mã mẫu.
Cách kiểm tra thành phần bánh bao
Toni Chang (Google)
Đường liên kết: Video, Trang trình bày
Những người đã dành quá nhiều thời gian để ổn định các thử nghiệm không ổn định sẽ đồng ý rằng chúng ta cần phân rã các thử nghiệm đó. Tuy nhiên, một số người cảm thấy khó khăn và không chắc chắn cách thực hiện, những người khác có thể gặp khó khăn với những thành viên trong nhóm tin rằng chúng tôi cần thử nghiệm E2E để xác thực mọi tình huống. Vì đôi khi khó để biết được ý tưởng khi bạn chưa quen xem sản phẩm của mình trong các thành phần, tôi sẽ sử dụng một ví dụ trừu tượng về Dumpling để minh họa cách phân tích những gì dường như là một phần không thể tách rời với các thành phần và áp dụng thử nghiệm cho các thành phần đó.
Tôi sẽ hướng dẫn bạn thực hiện một hành trình thú vị để dịch thử nghiệm E2E thành thử nghiệm thành phần, nhằm giúp bạn tự tin vào sản phẩm cuối cùng. Chúng tôi hy vọng rằng điều này sẽ giúp bạn có góc nhìn mới mẻ khi nhìn vào sản phẩm của mình.
Tự động hoá kiểm thử Chromecast
Brian Gogan (Google)
Đường liên kết: Video, Trang trình bày
Internet kết nối Internet đã dẫn đến sự phát triển của các thiết bị thông minh. Việc xác thực hành vi trên các thiết bị tương tác đa dạng là một thách thức lớn đối với hoạt động kiểm thử. Để kiểm tra Chromecast, chúng tôi đã áp dụng một số phương pháp. Chúng tôi vạch ra các khung kiểm thử, cơ sở hạ tầng phòng thí nghiệm và công cụ kiểm thử mà chúng tôi phát triển để tạo ra các tín hiệu chất lượng đáng tin cậy từ sản phẩm. Chúng tôi trình bày chi tiết những thách thức trong việc thử nghiệm một sản phẩm hoạt động trong môi trường có kết nối mạng ồn ào. Chúng tôi đề xuất rằng công cụ thử nghiệm cho các thiết bị như Chromecast đang ở giai đoạn sơ khai và mang đến các cơ hội đổi mới trong kỹ thuật thử nghiệm phần mềm.
Sử dụng rô-bốt để kiểm tra ứng dụng Android
Dr.Shauvik Roy Choudhary (Georgia Tech/Checkdroid)
Đường liên kết: Video, Trang trình bày
Bạn có thể sử dụng rô-bốt phần mềm, chẳng hạn như Monkey để thử nghiệm ứng dụng Android mà không cần nhiều thao tác thủ công. Có một số công cụ như vậy được đề xuất trong học viện với mục tiêu là tự động tạo dữ liệu đầu vào thử nghiệm để thúc đẩy ứng dụng Android. Trong buổi trò chuyện này, tôi sẽ giới thiệu một bộ công cụ tạo dữ liệu đầu vào thử nghiệm đại diện và trình bày một nghiên cứu so sánh để làm nổi bật thế mạnh và hạn chế của những công cụ đó. Bạn sẽ tìm hiểu nội bộ về các công cụ này và cách sử dụng chúng để thử nghiệm ứng dụng. Bạn có thể xem thông tin chi tiết về nghiên cứu cùng với thiết lập máy ảo bằng các công cụ tại: http://bear.cc.gatech.edu/~shauvik/androtest/
Thử nghiệm của bạn không diễn ra suôn sẻ
Alister Scott (Ô tô)
Đường liên kết: Video, Trang trình bày
Kiểm thử không ổn định là lỗi thường gặp của mọi kỹ sư kiểm thử tự động; và ai đó (có thể là Alister) từng nói "sự không rõ ràng là chạy nhiều lần thử nghiệm giống nhau và nhận được kết quả khác nhau". Kiểm thử không ổn định gây ra kết quả thất vọng, nhưng có lẽ không có vấn đề nào như một thử nghiệm không ổn định, có thể chúng ta cần xem xét vấn đề này thông qua một ống kính khác. Chúng ta nên dành nhiều thời gian hơn để xây dựng các hệ thống có tính quyết định và dễ kiểm thử hơn so với việc dành thời gian để xây dựng các thử nghiệm bền bỉ và bền bỉ. Alister sẽ chia sẻ một số ví dụ về trường hợp tính năng thử nghiệm không ổn định giúp ẩn các vấn đề thực tế bên dưới hệ thống, và cách giải quyết vấn đề không ổn định bằng cách xây dựng các hệ thống tốt hơn.
Kiểm thử trực quan quy mô lớn tự động
Adam Carmi (Công cụ phân tích ứng dụng)
Đường liên kết: Video, Trang trình bày
Thử nghiệm hình ảnh tự động là một xu hướng mới nổi chính trong cộng đồng nhà phát triển / thử nghiệm. Trong cuộc trò chuyện này, bạn sẽ tìm hiểu về kiểm thử trực quan và lý do nên tự động kiểm thử. Chúng ta sẽ tìm hiểu kỹ hơn về một số thách thức về công nghệ liên quan đến công nghệ tự động hoá thử nghiệm hình ảnh, đồng thời cho thấy cách những công cụ hiện đại giải quyết những thách thức đó. Chúng tôi sẽ minh hoạ các công nghệ tiên tiến cho phép bạn chạy các thử nghiệm hình ảnh trên nhiều thiết bị và trình duyệt, đồng thời cung cấp các mẹo quan trọng để đạt được thành công với thử nghiệm hình ảnh trên quy mô lớn.
Tắt thử nghiệm hồi quy
Karin Lundberg (Twitter) và Puneet Khanduri (Twitter)
Đường liên kết: Video, Trang trình bày
Nhóm của bạn vừa hoàn tất việc tái cấu trúc chính dịch vụ và tất cả các đơn vị kiểm thử tích hợp và đơn vị của bạn đều đạt. Bạn làm rất tốt! Nhưng bạn vẫn chưa hoàn tất. Bây giờ, bạn cần đảm bảo rằng bạn không làm hỏng bất kỳ nội dung nào và không có bất kỳ lỗi ẩn nào mà bạn chưa phát hiện được. Đã đến lúc dùng Diffy để làm việc.
Không giống như các công cụ đảm bảo rằng mã của bạn hợp lý, chẳng hạn như kiểm thử đơn vị hoặc tích hợp, Diffy so sánh hành vi của dịch vụ đã sửa đổi bằng cách đứng lên các bản sao của dịch vụ mới và dịch vụ cũ song song, định tuyến các yêu cầu mẫu cho từng dịch vụ, so sánh phản hồi và cung cấp hồi quy đã hiển thị từ những phép so sánh đó.
Ngoài ra, chúng tôi vừa sử dụng công cụ nguồn mở và công cụ này nhanh chóng trở thành một trong những công cụ phổ biến nhất trong số các dự án nguồn mở của Twitter.
Thử nghiệm hỗ trợ tiếp cận tự động cho ứng dụng Android
Casey Burkhardt (Google)
Đường liên kết: Video, Trang trình bày
Buổi trò chuyện này sẽ giới thiệu các thành phần chính hỗ trợ tiếp cận trên nền tảng Android, đồng thời minh hoạ một số sai lầm thường gặp của nhà phát triển liên quan đến khả năng hỗ trợ tiếp cận. Bạn sẽ tìm hiểu về Khung kiểm thử chức năng hỗ trợ tiếp cận Android mới và cách tích hợp khung này vào khung kiểm thử Espresso và Robolectric. Cuối cùng, bạn sẽ tìm hiểu mức độ dễ dàng của việc thêm tính năng kiểm tra khả năng hỗ trợ tiếp cận tự động vào các thử nghiệm dự án Android hiện có.
Lấy mẫu dữ liệu thống kê
Celal Ziftci (Google) và Ben Greenberg (nghiên cứu sinh MIT)
Đường liên kết: Video, Trang trình bày
Phương pháp phổ biến là sử dụng một mẫu dữ liệu sản xuất trong thử nghiệm. Ví dụ như:
- Kiểm tra tình trạng: Cung cấp một mẫu dữ liệu thực tế cho hệ thống của bạn để xem có sự cố nào không.
- Thử nghiệm A/B: Lấy một phần lớn dữ liệu trong môi trường thực tế, chạy dữ liệu này thông qua các phiên bản hiện tại và phiên bản mới của hệ thống, sau đó kiểm tra kết quả để kiểm tra.
Để có mẫu dữ liệu sản xuất, các nhóm thường sử dụng giải pháp đặc biệt, chẳng hạn như:
- Xem xét việc phân phối các trường cụ thể theo cách thủ công (ví dụ: các trường số),
- Chọn một mẫu hoàn toàn ngẫu nhiên
Tuy nhiên, những phương pháp này có một nhược điểm nghiêm trọng: có thể bỏ lỡ các sự kiện hiếm gặp (ví dụ: các trường hợp hiếm gặp), làm tăng nguy cơ lỗi chưa nắm bắt được trong quá trình sản xuất. Để giảm thiểu rủi ro này, các nhóm chọn những mẫu rất lớn. Tuy nhiên, với những mẫu lớn như vậy, có nhiều nhược điểm hơn:
- Các sự kiện hiếm gặp vẫn có thể bị bỏ lỡ,
- Thời gian chạy kiểm thử tăng lên đáng kể,
- Khác biệt quá lớn đối với con người là không thể hiểu được và có nhiều lần lặp lại.
Trong cuộc trò chuyện này, chúng tôi đề xuất một kỹ thuật lấy mẫu dữ liệu thống kê mới để "thông minh" chọn một mẫu "tốt" trong số các dữ liệu chính thức:
- Đảm bảo sẽ không bỏ lỡ sự kiện hiếm gặp nào,
- Giảm thiểu kích thước của mẫu đã chọn bằng cách loại bỏ các bản sao.
Kỹ thuật của chúng tôi phát hiện các trường hợp hiếm gặp/ranh giới, giữ cho kích thước mẫu ở mức tối thiểu và ngầm ẩn giảm bớt gánh nặng thủ công trong quá trình xem xét kết quả kiểm thử/kết quả thử nghiệm của nhà phát triển. Thư viện này cũng hỗ trợ quá trình thực thi song song (ví dụ: MapDecrease) để có thể xử lý lượng dữ liệu khổng lồ trong khung thời gian ngắn này.
Cơ sở hạ tầng tự động hóa của Nest
Usman Abdullah (Nest), Giulia Guidi (Nest) và Sam Gordon (Nest)
Đường liên kết: Video, Trang trình bày
Tầm nhìn của Nest về ngôi nhà Thoughtful là những thiết bị thông minh, kết nối với nhau hoạt động để giúp ngôi nhà của bạn an toàn hơn, tiết kiệm năng lượng hơn và nâng cao mức độ nhận biết. Buổi trò chuyện này sẽ tập trung vào cơ sở hạ tầng tự động và các công cụ thử nghiệm được xây dựng để hiện thực hoá tầm nhìn đó. Nhiều nhóm trong Nest đã làm việc trên cả hệ thống đa nền tảng và thiết bị/tính năng để kiểm tra và phân tích hồi quy tự động. Bằng cách sử dụng những ví dụ cụ thể từ thử nghiệm sản phẩm thực tế, chúng tôi sẽ đề cập đến phần cứng của các sản phẩm trong cơ sở hạ tầng thử nghiệm vòng lặp và công cụ phân tích hồi quy nguồn, cùng với bộ công cụ phát hiện chuyển động và máy ảnh cụ thể.
Trình tạo sự kiện
Roussi Roussev (Splunk)
Đường liên kết: Video, Trang trình bày
Buổi nói chuyện này bao gồm những kinh nghiệm của chúng tôi trong việc phát triển và sử dụng các trình tạo sự kiện phần mềm tại Splunk. Lấy cảm hứng từ vật lý hạt, trong đó các trình tạo sự kiện không thể hiểu được thế giới thực mà không chạy các máy thử nghiệm lớn, trình tạo nhật ký đã cải thiện cách chúng tôi kiểm thử nhiều công cụ tích hợp với phần mềm hiện đại và cũ của bên thứ ba. Buổi trò chuyện này sẽ nói về chức năng cơ bản và những thách thức trong việc tạo nhật ký thực tế.
Tổng hợp kiểm thử đa luồng
Murali Krishna Ramanathan (Viện Khoa học Ấn Độ, Bangalore)
Đường liên kết: Video, Trang trình bày
Lỗi đồng thời nhỏ trong thư viện đa luồng phát sinh do đồng bộ hóa không chính xác hoặc không đầy đủ thường khó xác định chính xác khi chỉ sử dụng các kỹ thuật tĩnh. Mặt khác, hiệu quả của trình phát hiện động còn phụ thuộc rất nhiều vào các bộ kiểm thử đa luồng. Các bộ kiểm thử này có thể dùng để xác định và kích hoạt các lỗi đồng thời, bao gồm cả cuộc đua dữ liệu, tắc nghẽn và lỗi vi phạm. Thông thường, các kiểm thử đa luồng như vậy cần gọi một tổ hợp phương thức cụ thể với các đối tượng liên quan đến lệnh gọi được chia sẻ thích hợp để hiển thị lỗi. Nếu không biết trước về lỗi, việc tạo các thử nghiệm đó có thể không dễ dàng.
Trong cuộc trò chuyện này, tôi sẽ trình bày một kỹ thuật gọn nhẹ và có thể mở rộng để tổng hợp thử nghiệm nhằm phát hiện các lỗi vi phạm về an toàn luồng. Do có một thư viện đa luồng và một bộ kiểm thử tuần tự, tôi sẽ mô tả một bản phân tích hoàn toàn tự động kiểm tra các dấu vết thực thi tuần tự và tạo ra kết quả là một chương trình ứng dụng đồng thời hướng các đối tượng dùng chung thông qua các lệnh gọi phương thức thư viện đến các trạng thái thuận lợi để kích hoạt lỗi đồng thời. Kết quả thử nghiệm trên nhiều thư viện Java đã được thử nghiệm kỹ lưỡng cho thấy hiệu quả của phương pháp của chúng tôi trong việc phát hiện nhiều lỗi phức tạp.
Bật tính năng thử nghiệm phát trực tuyến tại Netflix
Nhị phân sai (Netflix)
Đường liên kết: Video, Trang trình bày
Hơn 69 triệu trải nghiệm phát trực tuyến của người dùng là yếu tố quan trọng đối với Netflix. Để nhanh chóng cải thiện điều này, chúng tôi đã chuyển các thuật toán phát trực tuyến thích ứng vào lớp JavaScript. Việc này đã gây ra một thách thức lớn đối với việc thường xuyên phát hành phần mềm javascript khách hàng ảnh hưởng trực tiếp đến trải nghiệm phát trực tuyến của người tiêu dùng. Mượn mô hình phân phối liên tục (đã được áp dụng rộng rãi và thành công cho các ứng dụng dịch vụ) nên chúng tôi đã sử dụng mô hình này để loại bỏ rủi ro trong vòng đời của hoạt động đăng ký và thường xuyên cập nhật thông tin. Trong cuộc trò chuyện này, chúng tôi sẽ mô tả một thành phần chính trong mô hình này để bật tính năng cập nhật phần mềm. Chúng tôi sẽ đi sâu vào quy trình phát hành của ứng dụng và công cụ javascript để so sánh chính xác tình trạng so với phiên bản hiện tại. Chúng tôi cũng sẽ chia sẻ những thách thức mà quy trình này gặp phải.
Mô phỏng Internet
Yabin Kang (LinkedIn)
Đường liên kết: Video, Trang trình bày
Mô phỏng Internet, nói về một hệ thống mô phỏng mới trong Linkedin giúp mô phỏng tất cả lưu lượng truy cập đi cho các thử nghiệm tích hợp ở cấp dịch vụ, cũng sẽ trình bày một chút về tổng quan về chiến lược Minh họa mô phỏng. Chia sẻ kiến thức và những điều chúng tôi học được với mọi người.
Kiểm thử hiệu quả Bộ thu GPS theo dõi GPS
Andrew Knodt (Khoá Martin)
Đường liên kết: Video, Trang trình bày
Các trạm theo dõi GPS hiện có mà Không quân sử dụng đã trở nên khó duy trì và đang nỗ lực thay thế các trạm này bằng phương pháp vô tuyến phần mềm (SDR) được tăng tốc GPU. Giới thiệu tổng quan về những thử thách riêng biệt của bộ thu GPS này cùng với việc kiểm tra một số phương pháp thử nghiệm. Mặc dù tập trung vào ứng dụng GPS, nhưng các phương pháp thử nghiệm này có thể dễ dàng áp dụng cho các hoạt động SDR khác ở cấp sản xuất.
Tự động hoá trên thiết bị đeo
Anurag Routroy (Intel)
Đường liên kết: Video, Trang trình bày
Khi công nghệ đeo ngày càng phổ biến trong việc sử dụng cho cá nhân và doanh nghiệp, tất cả các công ty có không gian vững chắc trên thị trường Android đều đã tập trung vào công nghệ sắp ra mắt này. Do đó, việc tạo ứng dụng bằng tính năng hỗ trợ thiết bị đeo cũng làm tăng nỗ lực kiểm thử ứng dụng trên thiết bị đeo. Do đó, tính năng tự động hoá trên các thiết bị đeo trở nên quan trọng để giảm bớt công sức kiểm thử và tăng hiệu quả.
Kiểm thử tích hợp Cơ sở hạ tầng và CI hợp nhất (Docker/Vgrant)
Maxim Guenis (Supersonic)
Đường liên kết: Video, Trang trình bày
Các nhà phát triển gặp khó khăn mỗi ngày để chuẩn bị một môi trường phát triển cục bộ hiệu quả khi phát triển, gỡ lỗi và thực hiện chu kỳ tích hợp liên tục.Chúng tôi có thể giải quyết vấn đề này bằng cách tích hợp Docker và vagrant để được sử dụng với Công cụ CI. Sự kết hợp này cho phép kiểm soát các ứng dụng ở cấp ngăn xếp trên các máy phát triển, trong khi vẫn có thể sử dụng cùng một ngăn xếp trong các kiểm thử tích hợp. Trong cuộc trò chuyện này, chúng tôi sẽ thảo luận:
- Sử dụng Docker trong các thử nghiệm tích hợp CI
- Kiểm soát ngăn xếp thay vì một docker hoặc ứng dụng.
- Quản lý phiên bản môi trường phát triển và thử nghiệm, dễ dàng phân phối bằng các công cụ git và docker.
- Hỗ trợ liền mạch để chạy đế sạc trên máy Mac và cửa sổ.
Xóa các bit kiểm thử vô ích
Patrick Lam (Đại học Waterloo)
Đường liên kết: Video, Trang trình bày
Việc chuyên môn kỹ thuật phân tích tĩnh cho các bộ thử nghiệm đã mang lại kết quả thú vị. Trước đây, chúng ta đã biết rằng hầu hết các kiểm thử đều là mã đường thẳng đơn giản, cụ thể là một chuỗi các câu lệnh thiết lập sau đó là một trọng tải bao gồm các câu nhận định (assertion). Chúng tôi cho thấy cách phân tích tĩnh có thể xác định các câu lệnh thiết lập vô dụng, cho phép các nhà phát triển đơn giản hoá và đẩy nhanh quá trình kiểm thử.
Mức độ phù hợp không liên quan chặt chẽ đến hiệu quả của Bộ thử nghiệm
Laura Inozemtseva (Đại học Waterloo)
Đường liên kết: Video, Trang trình bày
Mức độ bao phủ của một bộ kiểm thử thường được dùng làm một proxy để có thể phát hiện lỗi. Tuy nhiên, các nghiên cứu trước đây đã điều tra mối tương quan giữa mức độ bao phủ của mã và hiệu quả của bộ thử nghiệm đã không đạt được sự đồng thuận về bản chất và sức mạnh của mối quan hệ giữa các đặc điểm của bộ thử nghiệm này. Hơn nữa, nhiều nghiên cứu được thực hiện qua các chương trình nhỏ hoặc tổng hợp, khiến không rõ liệu kết quả của họ có tổng quát đến các chương trình lớn hơn hay không, và một số nghiên cứu không tính đến ảnh hưởng nhiễu của kích thước bộ thử nghiệm. Chúng tôi đã mở rộng những nghiên cứu này bằng cách đánh giá mối quan hệ giữa quy mô, phạm vi thử nghiệm và mức độ hiệu quả của bộ thử nghiệm đối với các chương trình Java thực tế. Nghiên cứu của chúng tôi là lớn nhất cho đến nay trong tài liệu. Chúng tôi đã đo lường mức độ phù hợp của tuyên bố, mức độ phù hợp của quyết định và mức độ phù hợp của điều kiện đối với các bộ ứng dụng này và sử dụng quy trình kiểm tra đột biến để đánh giá mức độ hiệu quả của tính năng phát hiện lỗi. Chúng tôi nhận thấy có tương quan từ thấp đến trung bình giữa mức độ phù hợp và hiệu quả khi số lượng trường hợp kiểm thử trong bộ ứng dụng được kiểm soát. Ngoài ra, chúng tôi nhận thấy rằng các dạng bao phủ mạnh hơn không cung cấp thông tin chi tiết hơn về mức độ hiệu quả của bộ ứng dụng này.
Phần phụ trợ giả mạo với RpcPlayback
Matt Garrett (Google)
Đường liên kết: Video, Trang trình bày
Việc kiểm thử nhanh và ổn định là cực kỳ quan trọng. Điều này sẽ khó khăn khi máy chủ phụ thuộc vào nhiều phần phụ trợ. Nhà phát triển phải lựa chọn giữa các bài kiểm tra dài và không ổn định, hoặc viết và duy trì các phương thức triển khai giả mạo. Thay vào đó, bạn có thể chạy thử nghiệm bằng cách sử dụng lưu lượng truy cập được ghi lại từ các phần phụ trợ này. Điều này cung cấp những tính năng tốt nhất trong cả hai thế giới, cho phép các nhà phát triển thử nghiệm nhanh chóng với các phần phụ trợ thực tế.
Phòng thí nghiệm tự động hoá kiểm thử ChromeOS
Simran Basi (Google) và Chris Sosa (Google)
Đường liên kết: Video, Trang trình bày
ChromeOS hiện đang phân phối hơn 60 Chromebook/hộp, mỗi hệ thống chạy phần mềm riêng. Trên thực địa, khách hàng nhận được hệ thống mới sau mỗi 6 tuần. Điều này sẽ không thể thành hiện thực nếu không có một Hệ thống tích hợp liên tục hoạt động mạnh mẽ, kiểm tra kỹ hơn 200 nhà phát triển của chúng tôi. Trong cuộc trò chuyện này, chúng tôi mô tả kiến trúc tổng thể tập trung vào phòng thí nghiệm tự động hoá kiểm thử. Ngoài ra, chúng tôi còn thảo luận về Moblab (phòng thí nghiệm ngắn cho thiết bị di động (thử nghiệm)), toàn bộ cơ sở hạ tầng tự động hoá kiểm thử đang chạy từ một chromebox. Hệ thống này được nhiều đối tác của chúng tôi sử dụng để họ cũng có thể chạy thử nghiệm theo cách chúng tôi thực hiện.