フロントエンドテスト基本フロー

6631 ワード
フロントエンドオートメーションテストについて
  • フロント
  • テストツール
  • 継続テスト

    • 前言


    なぜテストするのか


    まず、なぜテストするのかを明らかにします.はっきり言って、私たちが書いたコードに間違いがあるかどうか、あるいは最適化が必要な場所があるかどうかを検査して、私たちのコードの品質を高めることです.自動化テストを行うには、テスト用例を書く必要があります.リリース前にテスト用例を走ってみると、テスト用例がカバーされている場所にバグがないことを保証できます.
    自動化テストのもう一つの利点は効率が高いことです.例えば、ボタンの機能をテスト担当者に渡して測定し、ページを見つけて対応するボタンをクリックしてから、この機能に問題があるかどうかを知る必要があります.それは機械に任せて、スクリプトでプログラムを走って、正しいかどうかを判断するのはもっと速くて正確で、しかもコードを変えるたびにすぐに自動化テストにアクセスして間違いがないかどうかを検査することができます.要するに、機械テストの効率はきっと人に行ってテストするのがずっと速いに違いない.

    テストがこんなに良い以上、すべてのコードにテスト例のサポートが必要ではないでしょうか。


    テストオーバーライド率はやはりテストコストと結びつけなければならないと思います.例えば、常に変わらない共通の方法で、できるだけテストオーバーライド率を100%にすることができます.完全なプロジェクトについては、前期に最も短い時間で80%のテスト例をカバーし、後期に徐々に改善することをお勧めします.
    常に変更を行うアクティビティページは、テストの永続的な使用例を変更し続けるため、メンテナンスコストが高すぎるため、100%近づける必要はないと思います.

    テストツール

  • テストフレームワーク:Mocha、Jasmineなど、主にテストの使用例を説明するために明確で簡明な文法を提供し、テストグループとテストがエラーを報告しないこと、具体的にどのエラーを報告するか、どの原因がエラーを報告するかなどを説明します.試験フレームワークは、通常、試験例を記述するために、BDD(動作駆動開発)とTDD(試験駆動開発)の2つの試験構文を提供する.Mochaは2種類サポートされていますが、JasmineはBDDのみサポートされています.以下、MochaのBDDを例に挙げます.
  • 断言庫:Should.js、chai、expect.jsなど,断言ライブラリがどれだけ意味化した方法を提供しているかについて,様々な状況の判断を提供する.もちろん、断言ライブラリを使わなくてもいいわけではありません.nodejsにはもともとassert断言モジュールもありますが、以下はShould.jsを例に挙げます.
  • コードオーバーライド率:Istanbulはローカルテストコードオーバーライド率でよく使われるツールの一つであり、コードオーバーライド率のテスト指標を提供し、どのコードがオーバーライドされていないかを明確に知ることができます.

    • 次に、最も簡単なnodejsプロジェクトを例にディレクトリ構造を説明します.
    .
├── LICENSE
├── README.md
├── index.js
├── node_modules
├── package.json
└── test
    └── test.js

    まず、テスト・フレームワークとブレークスルー・ライブラリをインストールする必要があります.
      npm install mocha should --save-dev

    テストケース


    そしてindex.jsで1行のコードを記述する
    'use strict'
module.exports = () => 'hello world!';

    ではtestではindexを判断するためのテスト例を書く必要がある.js出力の値が「hello world!」かどうか
    'use strict'
require('should');
const exp = require('../index');

describe('test', function () {
  it('should get "hello world!"', function () {
    exp().should.be.eql('hello world!');
  })
});

    packageでjsonファイルにコマンドを追加
    "scripts": {
  "test": "mocha"
},

    端末で実行できます
    npm test

    テスト結果:
    テストに合格すれば1 passingが見られます
    テストに合格しなければ1 failing、合格してもエラーメッセージが表示されます
    mochaには多くの構成項目があります
    1つはpackageを直接変更することです.jsonのtestコマンド、たとえば
    "scripts": {
  "test": "mocha --require should"
},

    これによりmochaは各ファイルに自動的にshouldを導入し、自分で導入しなくてもよい.
    もう一つの書き方はtestフォルダにmochaを新規作成することです.optsプロファイル、書き込み
    --require should

    効果は1つ目と同じです

    コードオーバーライド率


    まずistanbulをインストールする必要があります.
      npm install istanbul --save-dev

    Node.js側でコードオーバーライド率テストを行うのは簡単で、istanbulでMochaを起動するだけでいいです.
    testコマンドの変更
    "scripts": {
  "test": "istanbul cover mocha -- --delay"
},

    istanbulを使用してMochaを実行する場合、istanbulコマンドは自分のパラメータを--の前に置き、Mochaに渡すパラメータを--の後に置く必要があります.
    実行が完了すると、プロジェクトの下にcoverageフォルダが1つ増えます.ここがコードオーバーライド率の結果を置く場所です.

    アクセスKarma


    Karmaはテスト統合フレームワークであり、テストフレームワーク、テスト環境、カバー率ツールなどをプラグイン形式で容易に統合できます.まずnpmを使用して依存関係をインストールする必要があります.
  • karma:フレーム本体
  • karma-mocha:Mochaテストフレームワーク
  • karma-coverage:カバー率テスト
  • karma-spec-reporter:テスト結果出力
  • karma-chrome-launcher:Chrome環境
  • karma-firefox-launcher:Firefox環境
    • インストールが完了したら、前のプロジェクトを削除し、ソースファイルとテストファイルだけを残してkarmaを追加します.conf.jsファイル:
    .
├── karma.conf.js
├── package.json
├── src
│   └── index.js
└── test
    └── test.js

    karma.conf.jsはkarmaのプロファイルです.

    継続的なテスト


    オープンソースの継続的な統合


    オープンソースで有名な持続的な統合テストサーバはTravisですが、コードオーバーライド率はCoverallsを通過し、GitHubアカウントさえあればTravisとCoverallsにアクセスできます.
    Travisはプロジェクトの下のtravisを読み込みます.ymlファイル、簡単な例:
    language: node_js
sudo: true
node_js:
  - "6"

addons:
  firefox: "latest"
  chrome: "stable"

before_script:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
  - sleep 3 # give xvfb some time to start

before_install:
  npm install karma-cli -g

after_success:
  - cat ./coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js

    karma.conf.jsファイルはこの例では、ほぼこのようなものです.
    module.exports = function(config) {
  var configuration = {
    basePath: '',
    frameworks: ['mocha'],
    files: [
      'https://cdn.bootcss.com/jquery/2.2.4/jquery.js',
      'node_modules/should/should.js',
      'test/**.js'
    ],
    exclude: [
    ],
    preprocessors: {
    },
    reporters: ['progress'],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    browsers: ['Chrome'],
    customLaunchers: {
      Chrome_travis_ci: {
        base: 'Chrome',
        flags: ['--no-sandbox']
      }
    },
    singleRun: true,
    concurrency: Infinity
  };
  if(process.env.TRAVIS){
    configuration.browsers = ['Chrome_travis_ci'];
  }
  config.set(configuration);
}

    これらの配置はどういう意味ですか?ここで一つ一つ説明します.
  • frameworks:使用するテストフレームワーク、ここは依然として私たちがよく知っていて親切なMocha
    • です.
  • files:テストページにロードするリソースが必要で、上のtestディレクトリの下にはtestがありません.htmlです.すべてのロード内容はここで指定します.CDN上のリソースであれば、URLを直接書いてもいいですが、できるだけローカルリソースを使うことをお勧めします.そうすれば、テストが速く、ネットがなくてもテストできます.この例では、最初の行には断言ライブラリShouldがロードされています.js、2行目はsrcの下のすべてのコードであり、3行目はテストコード
    • にロードされる.
  • preprocessors:プリプロセッサを構成し、上のfilesに対応するファイルをロードする前に、ここでプリプロセッサを構成すると、まずファイルを処理し、処理結果をロードします.この例では、srcディレクトリの下のすべてのリソースにオーバーライド率ドットを追加する必要があります(このステップはgulp-istanbulで行い、karma-coverageフレームワークは便利に処理でき、フックなども必要ありません).後でReactコンポーネントのテストをするときもここでwebpack
    • を使用します.
  • plugins:インストールされたプラグインのリスト
  • browsers:テストが必要なブラウザです.ここではPhantomJS、FireFox、Chrome
    • を選択しました.
  • reporters:どのコードレポートを生成する必要がありますか
  • coverageReporter:オーバーライド率レポートをどのように生成するか、ここでは、オーバーライド率ページ、lcovなど、以前と同じレポートを生成することを期待する.info、coverage.json、およびコマンドラインのヒント
    • 最後にpackage.jsonのtestコマンドを次のように変更します.
    {
  "scripts": {
    "test": "karma start --single-run"
  }
}

    プロジェクトアクセスの継続的な統合は、複数の人が同じ倉庫を開発する際に大きな用途を果たすことができ、pushのたびに自動的にテストをトリガーすることができ、テストが過ぎないと警告が発生します.Issues+Merge Requestで管理する必要がある場合は、各需要ごとに1つのIssues+ブランチを必要とし、開発が完了したらMerge Requestを提出し、プロジェクトOwnerが合併を担当し、プロジェクトの品質がより保障される.

    まとめ


    ここで紹介するのはフロントエンド自動化テストの表面だけで,まだ深く研究できるものがたくさんある.さらに効率的な自動化テスト方法は、深く掘り起こすのを待っています.
    [algo]DFS、BFSとは?
    poj2245 Lotto