HL2018で一連の要約を継続します。 Badooのメンバー（Vladimir
Yants vyantsとNikolai Krapivny）がこの
大要をチェックするのを手伝ってくれました。 これが報告書のメッセージの質にプラスの効果をもたらすことを願っています。
開発プロセスの特徴：
開発者の責任は、バックエンドのリリースで終わりません。 彼は、プラットフォームに実装する前に責任を負います。
手動テストはありますが、クライアントはリリース時に準備ができておらず、（予測不可能な）遅延でリリースされます。 多くの場合、顧客がいつそれを実装し始めるのかわかりません。 時々（あまり頻繁ではないが）機能が長い時間の後に実行されるようになります。 したがって、手でテストすることは難しく、すべてが可能というわけではありません。 したがって、自動テストが必要です。
テスト
単体テスト
phpunitで書かれています。
小さなユニットをテストします。 データベースやサービスにはアクセスしません（何もやり取りしないでください）。
レガシーはまだテストプロセスを保持し、複雑にします。
彼らはsoftMocksライブラリを開発しました-それはすべてinclude / requireをフックし、それを変更されたものと置き換えます。
静的メソッド、プライベートメソッド、最終メソッドなど、あらゆるメソッドをまとめることができます。
ライブラリはオープンソースで利用可能です。
問題：ソフトモックはリラックスし、テストされていないコードを記述できるようにします（そしてテストでカバーします）。
ルールを受け入れました：
- 新しいコードはphpunitを簡単にテストできるはずです
- SoftMocks-極端な場合（古いコード/長い/高価/複雑）
これらのルールのコードレビューを確認します。
テスト品質
突然変異試験
- コードを取る
- コードカバレッジを取得する
- コードを解析し、突然変異を適用します（変更+ =>-; true => falseなど）
- 突然変異ごとに、テストのスイート（セット）を実行します。
- テストが失敗した場合、約 そうでない場合は、十分な効果がありません。 テストを理解、変更/追加します。
既製のソリューション（Humbug、Infection）がありますが、それらは適合しませんでした（ソフトモックと互換性がなく、コードカバレッジに問題があります）。 したがって、彼らは自分で書きました。
突然変異テストは、手動テストではまだ利用できません。 コンソールから手動で実行できます。 現在、CIパイプラインに実装し、プロセスを構築しています。 結果はHabrにあります。
統合テスト
いくつかのコンポーネントの動作を組み合わせてテストします。 ベースやサービスで作業を確認します。
データベーステストの標準アプローチ（DBUnit）：
- テストデータベースを上げる
- それを埋める
- テストを実行する
- データベースを消去します
問題は次のとおりです。
- データテーブルとデータセットをサポートする必要がある（データベースのコンテンツの関連性）
- データベースの準備には時間がかかります
- 並行起動により、テストが不安定になり、デッドロックが発生します
ソリューション：DBMocksライブラリ（独自のソリューション）
動作原理：
- セットアップテストでSoftMocksを使用してインターセプトされたDBドライバーメソッド
- リクエストparsim db +テーブルから
- Tmpfsは同じスキーマで一時テーブルを作成します
- すべてのクエリは一時テーブルにのみ移動します
- TearDownでは、それらは削除されます。
ライブラリは小さいですが、まだオープンソースで開かれていません。
結果：
- テストでは元のテーブルのデータを破損できません
- テストは互いに分離されています（並行して実行できます）
- MySQLバージョンとのクエリ互換性のテスト
APIテスト
- クライアントセッションを模倣する
- バックエンドリクエストを送信できる
- バックエンドは本物の顧客のように反応します
通常、このようなテストには承認されたユーザーが必要です。 テストの前に作成し、後で削除する必要があります。 これにより、追加のリスク（レプリケーション、バックグラウンドタスク）が発生します。
解決策：テストユーザーのプールを作成しました。 それらをきれいにする方法を学びました。
devel！= Prodであるため、テストユーザーは実際のユーザーと同じ環境にいます。 テストユーザーとライブユーザーを分離する必要があります。
分離のために、ユーザーにis_test_userフラグが追加されました。 また、これらのユーザーは分析およびa / bテスト結果からも除外されます。
テストユーザーを「南極大陸」に送ることで安くすることができます。そこでは誰も見ることができません（ペンギンを除く）。
QA API
APIテストで環境を準備するためのツール。基本的に、ユーザー/環境設定をすばやく変更するためのバックエンドのバックドア。
- よく文書化されたAPIメソッド
- データを迅速かつ簡単に管理します。
- 開発者はバックエンドを書く
- テストユーザーにのみ適用できます。
ユーザーが不変データ（たとえば、登録日）を変更できるようにします。
必要な保護：
- ネットワークレベル（オフィスネットワークからのみ利用可能）
- リクエストごとにシークレットが渡され、その有効性がチェックされます
- メソッドはテストユーザーでのみ機能します。
HackerOneにはBugsBountyプログラムがあります。 発見された脆弱性の代価を支払います。 QA APIを使用することはできませんでした。
リモートモック
リモートバックエンドのMoki。
ソフトモックのベースで作業します。 テストでは、バックエンドにモックセッションの初期化を要求します。 要求を受信すると、バックエンドはセッションのmoxのリストをチェックし、SoftMocksを使用してそれらを適用します。
テスト例：
APIテストは便利すぎます。 ユニットの代わりにそれらを書くのは魅力的です。 ただし、APIテストは非常に遅くなります。
一連のルールを受け入れました：
- APIテストの目的は、プロトコルと統合をテストすることです
- 有効なチェックの複雑なフロー
- 小さな変動はテストできません。
- コードレビューでは、テストもテストします。
Uiテスト
バックエンドコマンドは書き込みません。
この機能は、安定するとUiテストでカバーされます。
Selenium for Webで使用されます。 モバイルひょうたん用。
試運転
100,000ユニットテスト。 6,000の統合、14,000のAPIテスト。
1ストリームでは、時間は40分/ 90分/ 10時間です。
TestCloudの作成-テストを実行するためのクラウド。
スレッド間のテストの分散：
- あなたは等しくすることができます（悪いことに、すべてのテストが異なり、時間部分で等しくないことがわかります）
- 複数のスレッドを実行し、phpunitテストを1つずつフィードします（初期化のオーバーヘッド。長い！）
解決策：
- 実行時の統計の収集。
- チャンクが30秒を超えないようにするテストのレイアウト
apiテストの問題は、長い時間と多くのリソースであり、他のユーザーの実行を許可しません。
解決するために、クラウドを2つの部分に分割しました。
- クイックテストのみを実行します。
- 両方のタイプのテストを実行します。
その結果、次のことが加速されます。
コードカバレッジの実行
実行するテスト コードカバレッジが表示されます。
- ブランチ差分を取得します
- 変更されたファイルのリストを作成する
- これらのファイルのテストのリストを取得します。
- これらのテストからのみスイート実行を実行します。
マスターブランチのカバレッジは、1日に1回、夜間に形成されます。 結果（diff）がデータベースに追加されます。
長所：
- 実行するテストの数を減らす：ハードウェアの負荷を減らし、テストのフィードバックを高速化
- パッチのテストを実行できます。 これにより、修正プログラムをすばやく展開できます。 パッチでは、速度が最も重要です。
短所：
- バックエンドリリースは1日に2回です。 昼食後、カバレッジの関連性は低くなります（ただし、ビートを展開するときは、常にフルスイートをドライブします）。
- APIテストは、広範なカバレッジを生成します。 彼らにとって、このアプローチはあまり節約になりません。
開発者がコードカバレッジ、つまりコンソールで実行できるツールをすぐに見る必要がある場合、特定のファイル/コンポーネントのカバレッジの最新のメトリックをすぐに取得できます。
扱いにくいと見なされます。対象マスタのデータが取得され、変更されたすべてのテストが追加され、カバレッジがすでに考慮されている小さなスイートが判明します。
まとめ
- すべてのテストレベルが必要
- 数量！=品質。 コードレビューと突然変異テストを行う
- テストユーザーを実際のユーザーから分離します。
- バックエンドのバックエンドは、テスト作成を簡素化し、スピードアップします
- テストに関する統計を収集します。
参照資料