背景
この事件は、昨年と最近の2度にわたるオーナーの「障害」が原因でした。共通の原因は、パブリッシング・プラットフォーム上の足場リリース・パッケージのエラーで、その結果、白い画面が表示され、オンライン・アプリケーションが利用できなくなりました。
驚くべきは、何度かのコード・レビューの後でも、この問題の原因となるバグが見つからず、最終的にサーバーのリリース・パッケージに問題があったのではないかと推測したことです。
上司が、自分が書いたエンジニアリング・ツールのせいで、熱湯の入った鍋を受け取ったとN+1回目の苦情を言ったとき、私はふと、この熱湯の鍋を避けるにはどうしたらいいかと考えました。
結局のところ、この種のオンライン障害の原因はすべて、オンライン用にパッケージ化されたコードが検証されていないという事実にあります。この問題に対処するには2つの方法があります：
- この問題を解決するために、プレリリース版はリクエストアドレスが異なるため、直接オンラインに送信することができません。そのため、リリースシステムでプレリリースとオンラインリリースの間にベータリリースを追加することができます。 ベータリリースはオンラインリリースのパッケージングプロセスを使用しますが、イントラネットからのみアクセスが許可され、特に内部テストに使用されるという違いがあります。ベータリリースを追加しても、オンラインリリースがエラーなくリパッケージされる保証はないのでは？このソリューションの核心は、ベータリリースがテストされ合格した後、ベータリリースのパッケージ化された製品が直接オンラインリリースされるという事実にあります。ベータ・リリースの追加には、O&M、バックエンド、モバイルといった異なる職種間の協力が必要なため、実装はより困難です。
- 症状を治すには、オンライン版では検証できないので、オンライン版の後にすぐに検証に戻り、問題が見つかったらすぐに手動でロールバックします。誰も発見しない不具合は不具合ではない、ということわざがあるように、完璧です！
前述の通り、治療法を実施するのはより難しいため、治療法、つまり本番稼働後の回帰検証に焦点を当てます。
そういえば、皆さんに質問なのですが、要件が本稼働した後、フロントエンドとして、テストを待つのではなく、率先して回帰検証を行いますか？
あなたがそうするかどうかは別として、とにかく私は[doge]しません。
この場合、フロントエンドのUI自動化テストが輝きます。
フロントエンドUIオートメーションテストとは
ご存知のように、テストはプロセスにおいて非常に重要な部分であり、その重要性から、ソフトウェアエンジニアリングではTDDという言葉まで登場しました。
いわゆるフロントエンドのテストでは、ページ上でポイント＆クリックする、人間によるテストが多く、間違いなく非効率的です。
そこで、人間の代わりに機械を使うフロントエンド自動テストがあります。一般的に、フロントエンドの自動テストにはユニットテストとe2eテストの2種類があります。
ユニットテストは基本的にホワイトボックステストの一形態で、プログラムの中でテスト可能な最小単位をテストします。
e2e テストは、本質的にブラックボックステストの一形態であり、アプリケーションにアクセスするユーザをシミュレートするこ とに相当します。
ユニットテストに比べ、UI自動化テストはよりユーザーの視点に立ち、ユーザーの視点から問題を発見します。しかし、実際にはブラックボックステストの一種であるため、ホワイトボックステストに比べると効率は落ちます。
フロントエンドUI自動化テストフレームワークの比較
Selenium: いくつかのプログラミング言語で利用可能な、すべてのe2eテストフレームワークの祖先です。 あなたの会社のテストスタッフに尋ねると、彼らはSeleniumのPythonバージョンで自動テストスクリプトを書いていることに気づくでしょう。webkit kernelの代わりにwebdriverに基づいて実装されているので、Seleniumのブラウザの互換性は他のブラウザと比べてはるかに優れていることを言及する価値があります。
PhantomJS：先駆的なヘッドレステストフレームワーク、つまりUIインターフェイスを持たないブラウザです。ヘッドレスには、ユニットテストのようにコマンドラインからe2eテストを実行できるという大きな利点があります。
nightmare：一言で言えば、PhantomJSの強化版です。PhantomJSに比べて、開発効率も運用効率も大幅に向上しています。
nightwatch：名前と悪夢は非常に似ていますが、e2eフレームワークとは全く異なる、Nodeの呼び出しWebドライバの実装を使用しています。Seleniumに比べて、開発と運用効率が高く、最も重要なことは、イテレーションが非常にアクティブであるということです、この点は、オープンソース製品の使用は、ユーザーが理解しています。
cypress：最初のe2eテストフレームワーク、テストインターフェイスと究極の製品を行うための文書との私の接触は、あなたが試すことができることをお勧めします。
puppeteer：マスターのe2eテストフレームワーク、ヘッドレスモードがデフォルトですが、Chromiumを実行するように設定することもできます 。開発効率と運用効率は一流ですが、最も重要なのは悪夢のようなもので、テストコード生成プラグインpuppeteer-recorder提供しています。
まとめると、ブラウザの互換性が気になるなら nightwatch、その逆なら cypress puppeteer、ヘッドレスや自動コード生成機能が必要なら puppeteer使いましょう。
フロントエンドUIオートメーションテストの利用価値
自動テストの利点には公式があります：
自動化のメリット = イテレーション * 完全手動導入のコスト - 最初の自動化のコスト - メンテナンス訪問回数 * メンテナンス・コスト
つまり、イテレーションの頻度が高ければ高いほど、またメンテナンスコストが高ければ高いほど、自動テストを追加する価値は高くなります。インフラプロジェクトやイテレーションが頻繁に行われるプロジェクトにフロントエンドのUI自動テストを導入することで、イテレーションのたびに手作業でテストする時間を大幅に削減することができます。フロントエンドUI自動化テストは、手動テストよりも迅速かつ徹底的です。
一方、フロントエンド技術の急速な発展により、各社のフロントエンド開発と監視システムは非常に完璧になりましたが、フロントエンドのテスト方向の拡張が不足しています。フロントエンドUI自動化テストの最大の価値はフロントエンド部分にあり、開発と監視の間の空白部分を補い、完全なクローズドループを形成し、三方面からのアプローチで、プロジェクトの品質を大幅に保護します。
今後の展望
フロントエンドのUI自動化テストについて、私は長い間考えてきましたが、個人的には大きく2つの方向性があると考えています：
- 単一のプロジェクトでは、テストの主な機能のシリーズが、あなたがテストカバレッジを追求する必要がある場合、それはより多くの時間がかかり、より従来の、微調整のテストプログラムですので、インフラプロジェクトや大規模なビジネスプロジェクトのいくつかの長期的なメンテナンスのために、より適している、欠点は、ページの活動は基本的にカバーすることができないということです。
- すべてのプロジェクトでは、自動化されたテストの足場を追加し、項目を介して設定することができ、自動的にターゲットページにアクセスし、e2eテストのシリーズは、スクリーンショットを撮るために、さまざまな結果に応じて、PDF、アラームやその他のさまざまな処理オプションを生成します。
2つ目のオプションである汎化オプションは、私が最近開発したもので、このオプションの設計と具体的な実装を大まかに説明するために、次の記事を捧げなければなりません。
もし違うアイデアをお持ちでしたら、遠慮なくお聞かせください。
