Headless Browser và kiểm thử với Headless Chrome

Hẳn chúng ta khi muốn thực hiện các tác vụ trên trang web như crawling data, automatic testing, automatic action, ... nếu dùng các tool thông thường thì sẽ gặp vấn đề về ajax, javascript,... từ đó không thể thực hiện hành động như mong muốn được. Headless browser ra đời để giải quyết vấn đề này. Bài viết này sẽ trình bày tổng quan cho bạn về Headless browser và ứng dụng phổ biến của nó là phục vụ automatic testing sử dụng Headless Chrome.

1. Headless Browser là gì

Headless browser có vẻ là một cái tên kỳ quặc (Headless đơn giản là không đầu đấy, không tin bạn search từ điển đi), nhưng nó chỉ đơn giản là tên cho trình duyệt hoặc mô phỏng trình duyệt mà không có giao diện đồ họa. Thay vì testing một trang web hoặc thực hiện các hành động phổ biến bằng các yếu tố giao diện đồ họa quen thuộc, các trường hợp sử dụng headless browser được tự động hóa và được kiểm tra với giao diện dòng lệnh.

Các trường hợp sử dụng headless browser phổ biến:

Kiểm thử website và ứng dụng web
Kiểm thử JavaScript library.
Mô phỏng các tương tác với JavaScript.
Chạy một hoặc nhiều kiểm thử UI tự động ở dưới background.

Những hành động này giúp nhà phát triển xác nhận xem các hoạt động trang web có trôi chảy hay không và có thể xác định các sự cố tiềm ẩn với UI và UX. Do trải nghiệm của người dùng cuối là tối quan trọng trong môi trường web được cá nhân hóa cao hiện nay, nên nó rất quan trọng để khắc phục càng nhiều lỗi càng tốt trước khi tung ra phiên bản release của một trang web.

2. Headless browser cho việc kiểm thử

Ứng dụng phổ biến nhất của headless browser là kiểm thử tự động (automatic testing). Vậy những trường hợp sử dụng nào thì nên dùng headless browser để kiểm thử? Ta sẽ xem xét các hành động thường xuyên nhất mà người dùng có thể thực hiện trên bất kỳ trang nào. Mỗi điểm mà người dùng gõ, nhấp hoặc tương tác với các yếu tố trên trang là một điểm có thể xảy ra sự cố và ta nên tìm hiểu và khắc phục sự cố trong giai đoạn thử nghiệm của trang web hơn là để bị người dùng phát hiện ra sự cố sau vài tuần hoặc thậm chí vài tháng

Trong môi trường headless browser, ta có thể viết và thực thi các script như sau:

Kiểm thử flow cơ bản của ứng dụng.
Mô phỏng click trên link và các nút.
Tự động điền form.
Kiểm tra SSL performance.
Thí nghiệm khả năng load của server.
Chụp lại kết quả màn hình khi kiểm thử.

3. Kiểm thử với headless chrome.

Sau đây chúng ta sẽ dùng codeception của php để kiểm thử với headless chrome.

Cài đặt

Tùy thuộc vào sở thích của bạn, bạn có thể cài đặt Codecellect bằng cách tải xuống kho lưu trữ codecept.phar từ trang web hoặc cách khác bằng cách sử dụng trình soạn thảo.

{
    "require-dev": {
        "codeception/codeception": "*",
    }
}

Với nhà soạn nhạc, bạn sẽ cần phải thực thi:

php composer.phar install

Trong hướng dẫn trước, chúng tôi đã cài đặt bằng Trình soạn thảo, vì vậy trong các ví dụ hiện tại, chúng tôi cũng sẽ sử dụng nó.

Chắc chắn, chúng tôi cũng cần máy chủ Selenium thực thi là tốt. Bạn cần cài đặt Java để chạy máy chủ Selenium. Bạn có thể khởi chạy nó bằng cách chạy này:

java -jar selenium-server-standalone-2.37.0.jar

Khi tất cả các bước cài đặt được thực hiện, chúng ta có thể tiếp tục với việc tạo bootstrap Codecellect.

Khởi động

Không giống như Codunit phpunit yêu cầu một bước bootstrap nhỏ. Mật mã giúp bạn tổ chức các bài kiểm tra thành 3 loại: kiểm tra chấp nhận, chức năng và đơn vị. Để tạo tất cả các bài kiểm tra và thư mục hỗ trợ, bạn sẽ cần chạy lệnh bootstrap.

vendor/bin/codecept bootstrap

Các xét nghiệm Selen là các xét nghiệm chấp nhận. Vì vậy, hãy để cùng nhau tạo ra một bộ xương cho bài kiểm tra chấp nhận cơ bản:

vendor/bin/codecept generate:cept acceptance GitHub

Điều này sẽ tạo tập tin mới trong tests / accept / GitHubCept.php. Nhưng chúng tôi cần một số cấu hình bổ sung phải được thực hiện trước khi tiến hành. Thay vì tạo phiên webroll trong các bài kiểm tra theo cách thủ công, chúng tôi ủy thác việc này cho Codecellect. Codecellect sẽ chăm sóc để tạo phiên trước mỗi bài kiểm tra và đóng nó sau. Đó là lý do tại sao cấu hình Selen nên được viết thành tests / accept.suite.yml.

class_name: WebGuy
modules:
    enabled:
        - WebDriver
        - WebHelper
    config:
        WebDriver:
            url: 'http://github.com'
            browser: 'firefox'

Mỗi khi bạn thay đổi cấu hình trong Codecellect, bạn nên chạy lệnh build.

vendor/bin/codecept build

Viết test

Hãy bắt đầu với một cái gì đó rất cơ bản. Chúng tôi sẽ mở trang Github và chúng tôi sẽ đảm bảo rằng từ GitHub nằm trong tiêu đề trang.

<?php
$I = new WebGuy($scenario);
$I->wantTo('see GitHub word in title ');
$I->amOnPage('/');
$I->seeInTitle('GitHub');
?>

Chúng tôi đang sử dụng lệnh WantTo chỉ để đưa ra một mô tả sạch thử nghiệm. Lệnh amOnPage mở trình duyệt trên trang chủ github và tất cả các lệnh bắt đầu bằng xem là các xác nhận bạn có thể sử dụng. Có rất nhiều lệnh trong lớp WebGuy bạn có thể sử dụng để viết bài kiểm tra. Tất cả chúng đang lấy từ các mô-đun sửa lỗi, trong trường hợp của chúng tôi, đó là mô-đun WebDriver. Nếu bạn sử dụng IDE, bạn có thể kiểm tra tất cả chúng với tự động hoàn thành.

uc?id=1kUVDJh2FmJM-Hhk8H1jXZMYHGWBO071k&export=download

Nhưng hãy để thực hiện một thử nghiệm với lệnh chạy:

vendor/bin/codecept run

Và bạn sẽ thấy đầu ra này:

Codeception PHP Testing Framework v1.8.0
Powered by PHPUnit 3.7.28 by Sebastian Bergmann.

Functional Tests (0) ------------------------
---------------------------------------------

Acceptance Tests (1) -------------------------------------------
Trying to see github word in title  (GitHubCept.php)       Ok
----------------------------------------------------------------

Unit Tests (0) ------------------------------
---------------------------------------------


Time: 21.62 seconds, Memory: 5.00Mb

OK (1 test, 1 assertion)