目次
4. TDD は最初にテストコードを記述する必要はありません
6. テストを使用してアーキテクチャとコードの品質を向上させる
7. 「テスト依存のコードを書きたい」から「テスト依存のコードを書きたい」へ
1.「開発者テスト」とは「テストする開発者」を意味します
開発者テストは現代のソフトウェア エンジニアリングの非常に重要な部分であり、アジャイル開発やバックボーン開発などの高度なプロジェクト管理手法とプロセスは、完璧な開発者テストに基づいています。バージョンが毎月、あるいは毎週配信される場合、大規模なシステムレベルのテストを行うために大量のテストエンジニアを投入することは不可能であり、テスト全体のほとんどのテストを自動化する必要がある。ピラミッド。
今日は開発者テストについて話しましょう。「開発者テスト」とは何ですか? 当社では開発とテストを明確に区別しています。コードを書くことは攻城獅子の開発に属し、テストは攻城獅子のテストに属し、ほとんどの場合、両者は「赤と青の対立」状態にあります。これは、10 年以上前の私の研究開発チームの状況とよく似ています。しかし、現在のソフトウェア エンジニアリングでは、常勤の「テスト シージ ライオン」は非常に少なく、多くの企業では開発とテストの比率が 10:1 を超えており、一部の部門ではシージ ライオンのテストを行っていません。テスト包囲ライオンの役割は、テスト ケースを手動で実行する「クーリー」ではなくなり、製品テスト システムを管理し、製品テストを計画し、機能テストのマインド マップを分析および要約し、テスト ケースを設計し、R&D チームをテストに導きます。 「テストの専門家/テストコーチ」のように働きます。簡単な例で言うと、以前作ったプロダクトはオンラインビデオ会議のコラボレーションプロダクトでした。毎日のオンライン定例会は自社製品を使用し、自社開発の新機能テストサイトを使用して「スタンドアップミーティング」を開催します。日々の更新にわずかな時間を費やすことに加えて、テスト専門家はチーム (PO、アーキテクト、SM、開発を含む) を率いて、計画に従って集中 (30 分) テストを実行します。したがって、「開発者テスト」は「テストする開発者」を意味し、従来のテスト エンジニアの多くは、成長、変革、排除という 3 つの出口に直面しています。「テストの専門家」もプロジェクト内で高い発言権を持っており、以前の会社ではバックボーン開発を行っており、「一対一」のレビューを行っていましたが、チーム内のこのタイプの「テストの専門家」には拒否権があります。社内には PE レベルのテスト専門家もいます (当社の技術専門家 20 ～ 21 名に相当)。
- One-in:機能がリリース ブランチに入ることができるかどうかについては、リリース レベルのテストのためにリリース ブランチで機能の切り替えを開きます。
- ワンアウト:エンジニアのリリース中に、機能の品質が認定され、機能の切り替えが生産ラインに入ることが許可されます。
2.「自動テスト」できないテストはない
テストピラミッドの話に戻りますが、テストの「開発コスト」「実行コスト」「テストカバレッジ」「問題箇所」の4つの観点から、コードレベルに基づいたホワイトボックステストが非常に重要です。 。
- 開発コスト: テスト ケースの実装にかかるコスト。
- 実行コスト: テスト ケースの実行にかかるコスト。
- テストカバレッジ: 通常ラインカバレッジとブランチカバレッジと呼ばれるもの
- 問題の場所: テストで問題が発生し、問題を特定する効率
テスト ピラミッドとその 4 つのテスト ディメンションの評価を通じて、次のことが結論付けられます。
- できるだけ多くの低レベル テストを実行します。上位レベルのテスト タイプに比べて実行速度がはるかに速く、比較的安定しているため、1 日に複数回実行できます。一般に、LLT グレーは継続的統合構築タスクに実装され、コード ウェアハウスに入るコードの品質を保証するために MR でも実行されます。
- 自動化保証の場合、ある程度の規模のIT、ST、UIテストを実行します。実行速度が遅く、環境への依存度が高いため、まずテストが不安定になります。通常、コードの品質を定期的にチェックし、コードの問題についてフィードバックを提供するために、夜間に 1 回実行されます。
- 大規模な手動テストはできるだけ少なくしてください。LLT よりも実行速度が遅く、安定性が十分ではないため、人件費が高く、1 日に複数回実行できず、実行ごとに待機する必要があるためです。フィードバック結果が得られるまでに長い時間がかかります。ただし、これらは実際のユーザー シナリオに近いため、ソフトウェアの品質を確保するには、次のテストが一定の期間内またはクリティカルなノード時間に実行されるようにする必要があります。
現在、多くの企業の反復リリース サイクルはますます短くなり、2 週間に達することもあります。手動テストは明らかにこの開発モードに適応できず、さまざまな技術ソリューションを通じて手動テストのユースケースを自動化することが唯一の方法です。コード レベルでは、基盤となるビジネス コードから UI コードに至るまで、アーキテクチャ設計が合理的であれば、UT を実行できます。最上位の UI インタラクション テスト、テスト ケースは自動化することもできます (ほとんどの UI フレームワークは、アクセシビリティ インターフェイスを通じて UI 自動テストを実行できます)。携帯電話のハードウェアでも「電話を落とす」という極端なテストを自動的にテストできると想像してください。ソフトウェアには何ができないのですか? 少なくとも、業界をリードするテクノロジー企業の一部の製品では、マージ リクエストのコード送信から製品の生産ラインまで、数日で計算できます。この製品のテストは手動テストでは行われませんし、行うこともできません。
3. 開発者は「現在の利益」と「将来の勝利」をテストします
多くの人は、基礎となる開発者テストは機能の正確性を確認するために多くの時間を費やし、多くのコードを記述すると考えていますが、コードの機能や構造が変更されるたびに、テスト コードを変更する必要があります。手動でデバッグして検証する方が効率的です。確かに、UT および API テストによるコードのデバッグは、手動でデバッグを実行することとそれほど変わりませんが、開発者テストによるコードのデバッグは、現在のプロジェクトの反復の品質を保証できますが、より重要な役割はこれではありません。
バグ カテゴリには、ビルド リグレッション バグ、リリース リグレッション バグなどの名詞があります。
- ビルド回帰バグ: 開発中の同じ機能に新しいバージョンにはバグがありますが、以前のバージョンにはそのような問題はありません。これをビルド回帰バグと呼びます。
- リリース回帰バグ: 生産ライン上の同じ機能に新しいバージョンにはバグがありますが、以前のバージョンにはそのような問題はありません。これをリリース回帰バグと呼びます。
コードを製品にコミットするたびに、問題が発生しないことを 100% 保証できる人はいません。アジャイル開発の迅速な反復下では、フル機能の手動テストを実行することは不可能であるため、開発者テスト、特に基盤となるテストが必要になります。 UT、API テスト、統合テストでは、このような問題を簡単に特定して発見できます。そのため、開発者は「現在での利益」と「将来での勝利」をテストしていると言われています。
4. TDD は最初にテストコードを記述する必要はありません
TDD では、最初にテスト コードを書いてから実装コードを書くというのが誰もの認識ですが、この言葉が正しいか間違っているかはわかりません。コンセプトは正しいのですが、これを厳密に行うと効率が最高にならない可能性があり、それがTDDを推進しにくい理由の1つです。コーディングの実装は、コードの実装、コードのテスト、コードのデバッグの 3 つの部分に分けられます。TDD の概念によれば、最初にテスト コードを作成し、次にコードを記述し、最後にデバッグします。通常、コードを実装する場合、最初から明確に検討してインターフェイスを完全かつ正確に定義することはあまりありませんが、テスト、コーディング、デバッグを厳密に実行すると、コーディングに合わせてテスト コードも頻繁に変更する必要があります。もちろん、それ自体は大きな問題ではありませんが、実際の実装プロセスでは、多くの人が最初にコード フレームワークとテスト フレームワークを設定し、その後コーディングとテストを行うことに慣れています。テストが完了したらデバッグします。したがって、ファーウェイのグレースケール管理の観点からは、デバッグ前に単体テストが実行される限り、TDD開発モードと呼ぶことができます。ところで、もちろん今は BDD が普及しつつありますが、私がここで言いたいのは、先ほど述べた TDD さえもできないチームなら BDD を検討する必要はないということです。
(動作駆動開発: BDD は、TDD の一般的なテクニックと原則とドメイン駆動設計 (DDD) のアイデアを組み合わせたものです。BDD は、予想される動作に基づいて機能ブロックを段階的に構築する設計アクティビティです。BDD の焦点は、使用される言語とインタラクション。動作駆動型の開発者は、コードの目的と利点を説明するために、母国語をドメイン駆動設計言語と組み合わせて使用します。BDD を使用するチームは、次の形式で広範な「機能ドキュメント」を提供できる必要があります。ユーザー ストーリー " を作成し、実行可能なシナリオや例を追加します。BDD は通常、コード レベルのテストを公開するのではなく、ドメインの専門家が実装を理解するのに役立ちます。通常、BDD は GWT 形式 (GIVEN WHEN & THEN) で定義されます。)
5. 100% UT カバレッジは非常に悪い
単体テストでは、誰もが「カバレッジ」という指標に注目します。モジュール、関数、行、および分岐のカバレッジに関係なく、一定の割合のカバレッジが必要です。ただし、各項目で100％を達成した場合は「悪い評価」が与えられます。うまくできないのではなく（正しい方法を使用したかどうかについてはここでは触れません）、コストとコストパフォーマンスです。最も困難なブランチ カバレッジ (ブランチ カバレッジ) では、100% カバレッジを達成したい場合、メモリ割り当てまたはフォールト トレランス保護の一部のブランチをテストする必要があり、テスト ケースを 2 倍にする必要がありますが、対応する値にはなりません。 。一部のコードの条件分岐であっても、実行中のプログラムのライフサイクル中に実行されていません。
- モジュール カバレッジ: ビジネス モジュール コードは UT を通過し、アーキテクチャ モジュール コードは IT を通過します。UT カバレッジの観点からは、アーキテクチャ コードをテストする必要はありません。
- 関数カバレッジ: ロジックのないコードに対して UT を記述しないでください。たとえば、一部の関数は属性の取得/設定であり、内部実装では変数を使用して割り当てと保存を行います。この種の関数記述 UT は、実際の意味はなく、カバーのために書かれています。
- ライン カバレッジ: 一般的に、ライン カバレッジは 80% 程度が妥当な指標です。0% の場合もあれば、100% が必要な場合もあります。すべてのコードが 90% を超えると、コストが高く効率が低くなります。これは、推奨されません。
- ブランチ カバレッジ: ビジネス ロジックが複雑になればなるほど、それをカバーするためにより多くのテスト ケースを作成する必要があり、一部のメモリ割り当てエラー ロジックの判断はテストする必要がありません。
6. テストを使用してアーキテクチャとコードの品質を向上させる
ここでは、主にコードに完全なテスト可能性を持たせるための、テスト駆動アーキテクチャとコードの品質について説明します。簡単に言うと、クラス間、モジュール間を切り離し、インターフェースを介してクラスとモジュール間のプログラミングを行うことです。依存インターフェイスは、アクティブな取得ではなくパッシブな注入を通じて渡されます。プログラムが正常に実行されている場合、渡されるインターフェイス パラメータは実際のビジネス オブジェクトであり、テスト時には、偽のシミュレーション実装を渡すことができます。もちろん、すべての依存モジュールがこれを行うわけではなく、ビジネスに関係のない一部のユーティリティ ライブラリや特定のデータ オブジェクト実装は直接呼び出すことができます。
ここでは、fakeとmockについて説明しましたが、Test Doublesについては、基本的な概念は次のとおりです。
- ダミー
- スタブ
- スパイ
- モックオブジェクト
- 偽のオブジェクト
現在、弊社では基本的に全員が開発者テストを行う際にMock Objectを使用しています（実際、使用する過程では入力パラメータの戻り値で制御されるStubを使用している人が多いです）。概念的な問題は別として、Mock を通じてコードをテストできますが、実際には Mock を使用すると、基本的にコードの相関性が強く、モジュール表示に依存性が高く、特に C 言語ではモジュールの移植性が低いことを意味します。プログラミングにはそのような問題がたくさんあります。その結果、多くのモジュールは単体テストをまったく実行できなくなり、より多くの統合テストが行われるようになりました。
なぜこのようなことが起こるのでしょうか? 当社のハイレベル アーキテクトは、システム レベルのアーキテクチャ設計に重点を置き、システム モジュールとさまざまなアプリケーション間の関係を非常に明確に整理します。通常、ハイレベル アーキテクトは、システム モジュールまたはアプリケーション間の関係をより合理的に設計できます。 。ただし、特定のアプリケーション業務の設計と実装に関しては、下級アーキテクトに引き継がれます。実際、これらのモジュール内のコードの量は少なくなく、その多くはコード行数十万行、さらには数百万行にもなります。このとき、アーキテクトのレベルによってコードのクリーン コード品質が決まります。現在のコードの問題の多くはシステム アーキテクチャの問題ではなく、特定のビジネスの実装における厳格な要件と合理的なアーキテクチャ設計が欠如していることです。アプリケーション レベルで標準化する一連のアーキテクチャ ソリューションがある場合、少なくともモジュールのインターフェイスとモジュール間の相互作用は、システム設計と同じくらい明確かつ合理的になります。次に、不確実な部分は、各サブモジュール内の数万行のコード部分です。
テスト駆動アーキテクチャとコード品質の使用を提案する理由は、テストに高い標準が提案されると、全員がアーキテクチャからテスト問題を解決する必要があり、テスト問題が解決されれば、自然にクリーン コード L3 が達成されるからです。
7. 「テスト依存のコードを書きたい」から「テスト依存のコードを書きたい」へ
この文は奇妙に見えますが、実際には単体テストを根本的に解決する基本的な方法です。Mock であっても Fake であっても、モジュール間には依存関係が存在しますが、どんなに合理的なアーキテクチャであっても、この種の依存関係を取り除くことはできません。最初の「テストに依存するコードを書きたい」は、モジュールを実装するときに、テストするためのテスト コードを記述する必要があることを意味します。ただし、テストしたいのは、テストの依存関係をどのように記述するかです。2 番目の「テストに依存するコードを書きたい」は、コードを実装するときに考慮する必要があるのは、テストするためにモジュールに依存するときに依存関係を解決する方法であることを意味します。「テストの依存関係コードを書きたい」(つまり、私が偽のオブジェクトと実装と呼んでいるもの) を使用して、モジュールに依存してテストの依存関係の問題を解決します。
- 思考の変化、テスト駆動: モジュールを開発するときは、最初に自分自身をテストする方法を考えるのではなく、他の人が私を信頼している場合に他の人がテストしやすくするにはどうすればよいかを考えます。モジュールのプロバイダーは、モジュール コードを提供するだけでなく、再利用可能な偽のオブジェクト (呼び出し検証、戻り値、パラメータ検証、パラメータ処理、関数シミュレーションなど) も提供する必要があります。
- モジュール コードの作成者は独自の Fake 実装を実装します。基本的にコードの大部分はモジュールの作成者によって行われ、これは再利用可能な Fake 実装です。モジュール依存当事者は、独自の特別なビジネス要件に従って独自のコードを追加します。基本的には 80/20 の原則に従います。
- アーキテクチャ上の依存関係の分離、依存関係の注入によるインターフェイス プログラミング。開発者テストでは、Fake を使用して依存関係を実装します。
- テスト コードを作成するときは、すべての依存インターフェイスと依存実装が基本的に完了しているため、テストの依存関係よりもテスト ケースに注意を払う必要があります。
要約:
私の記事を注意深く読んでくださった皆さん、ありがとうございました！！！
私は過去数年間のソフトウェア テストのキャリアでまとめたいくつかの技術資料を個人的に整理しました。これには、電子書籍、履歴書モジュール、さまざまなジョブ テンプレート、インタビュー ブック、独習プロジェクトなどが含まれます。皆様、下の名刺をクリックして無料で入手してください。お見逃しなく。
http://qm.qq.com/cgi-bin/qm/ qr?_wv=1027&k=DhOSZDNS -qzT5QKbFQMsfJ7DsrFfKpOF&authKey=eBt%2BF%2FBK81lVLcsLKaFqnvDAVA8IdNsGC7J0YV73w8V%2FJpdbby66r7vJ1rsPIifg&noverify=0&group_code=1984 08628