ソフトウェアテストの実装では、テスト戦略の包括的な使用は、プロジェクトの実際の状況に応じて限られたテストリソースと要素を調整し、テストの難しさを分析し、テストの問題点を解決し、プロジェクト全体からのテストリスクを制御し、適切なものを使用することです。テストの方法とテクノロジーは目標指向であり、ガイドラインの概要を示し、テストタスクに関連する人的要素、イベント要素、および材料要素が相乗効果を発揮できるようにし、効果的な時間内に最高のテスト効率とテスト配信を実現するよう努めます。
- テスト戦略の重要性
すべてのテストプロジェクトは、範囲、時間、品質、コストなどの要因によって制限されます。ここでのテストリソースと要素は、単に人、物、物です。
テスターだけでなく、開発者、プロジェクトマネージャー、アウトソーシングサプライヤー、リーダーシップなどもいます。
起こりうるリスク、要件の変更、人員の変更、利害関係者間の格闘、緊急事態などがあります。
理解するのに最適なのは、テスト時間、テストの進行状況、テストの範囲、テスト環境などの実際のリソースです。
テスト戦略では、人、物、物などの要素をさまざまな段階で包括的に考慮して使用するため、すべてのリソースが連携し、限られたリソースが最適な効果の組み合わせを生み出すことができます。ソフトウェアテスト中にテスト戦略と方法の適切な組み合わせを選択することによってのみ、テストの効率と品質を効果的に向上させることができます。特に今日のインターネットソフトウェアの時代では、ソフトウェア更新の反復サイクルが短く、ソフトウェアテストの品質と効率の要件に新たな課題があり、合理的なテスト戦略を包括的に適用する必要があります。
テスト戦略の包括的な適用は、最初にプロジェクトのテストの難しさ、問題点、およびリスクポイントを見つけ、次に範囲をより正確に決定し、ビジネス知識をより詳細に準備し、テストリソースと進捗状況をより合理的に配置し、テスターをより効果的に動員することとして要約できます。軍隊の熱意、そして最終的には優れた力を集中させて、困難なポイントを攻撃し、問題のポイントを打ち破り、リスクを制御し、システムの問題を早期かつタイムリーに発見します。同時に、ビジネス学習と技術交流を継続し、チームの戦闘効果を向上させ、プロジェクトのリスクポイントを動的にフォローアップし、ターゲットを絞った方法でテスト戦略を動的に調整し、最終的に効率的にテスト配信の品質を確保します。著者が経験した以下の2つの財務テストプロジェクトの例は、テスト戦略の包括的な適用について議論するために使用されます。私の目にヒョウを見て、石を投げて道を探り、読者の議論と思考を喚起できることを願っています。
2.1大規模な商業銀行のコアシステムのUATテストプロジェクトの背景：インターネットの開発に適応するために、ユーザーエクスペリエンスを強調し、銀行全体のビジネスの統合管理、データの統合管理、および銀行全体の1つのアカウントを強化します。一元化されたシステムは新しく設計され、置き換えられました。銀行の本社のITセンターは、新しいコアシステムの配信品質を保証するために特別にテストセンターを設置しました。プロジェクト開発規模：600人以上の開発者。プロジェクトテスト規模：6人のアウトソーシングテストプロバイダー+パーティA自身のチーム。初期段階では150人以上、ピーク時には500人以上のテスターがいます。プロジェクト実施の難しさ：
本社の長は毎月定期的に注意を払い、定期的に報告します。パーティAのテストセンターのリーダーはそれを非常に重視しており、テスト提供担当者へのプレッシャーは前例のないものです。
プロジェクトは残業に真剣に取り組み、テスターは非常に疲れていました。初期は996モード（午前9時、午後9時、週6日）でした。テスターの数が増えた後、週5営業日のうち3日間は午後9時まで、週末と土曜日は定休日に変更しました。 。
プロジェクトチームの管理スタッフはすべて、さまざまな州の支店や支店から引き出されたビジネスバックボーンであり、ビジネスに問題はありませんが、管理レベルは確かに限られており、テストの蓄積がなく、素人のリーダーのように感じます。
複数のテストサービスプロバイダーからの多数のテスターが存在し、複雑な人事管理が行われ、テスターの能力はさまざまです。
テスト戦略の適用：このような大規模なプロジェクトに直面すると、テストの編成と実行は大規模な軍隊の運用のようになります。適切なシリアル化されたテスト戦略の組み合わせがない場合、テストチームの共同戦闘能力を効果的に発揮し、テストキャンペーンと全滅に勝つことは困難です。以下は、チームの現状に基づいて、ビジネスの側面、技術の側面、および管理の側面からテスト戦略と組み合わせて、テスト戦略の組み合わせを包括的に策定するための、管理チームの基本的な理論的方法です。1）グループ内のテスト戦略のマッチング。テスターの未熟な事業に基づいて転勤する事業者の未熟な試験技能の問題を目指し、テスターが事業者をマッチングさせて事業や技術を補完し、事業チームリーダーと技術副チームリーダーをそれぞれに配置。 Shi監督も互いに影響を及ぼし合い、最終的にはすべてのUATテストが技術およびビジネスのデュアルアビリティテスターになる可能性があります。戦略的分析：ビジネス担当者による不十分なテスト技術とテスターの不十分なビジネスリザーブのリスクを効果的に回避します。
2）人員能力レベルに基づいた労働戦略の分割をテストします。テスターのビジネス能力の不均一性の問題に対応するため、需要分析チームが特別に設置され、上流のすべてのテスト需要分析、ケースフレームワーク、シナリオ設計を実施します。集合的なレビューの後、ケースの完了、テストデータの準備、テストのためにジュニアスタッフに送信されます。実施した。各テストサイクルでは、分析チームと優秀なテストエグゼクティブがビジネスについて評価され、ビジネス分析チームの機能を継続的に最適化するために、適切なジョブローテーションと最適な状態の存続が実行されます。戦略的分析：適切な人に適切なことをさせ、テストと評価によって人員の流れを促進します。
3）ビジネスシナリオに基づいたテスト戦略。テストケースの設計はすべて実際のビジネスシナリオから導き出され、ビジネスに対応する以前のすべての生産事故をカバーします。次のレベルのビジネスシナリオ設計では、すべてのページ機能ポイントとページコントロールがチェックされ、機能ポイントテストは1つのポジティブと3つのネガティブの比率に従って設計されます。 。戦略分析：ネガティブなユースケースと異常なユースケースの役割を強調し、プログラムのエラー処理範囲に注意を払います。
4）高周波サービスに基づく高速回帰テスト。各バージョンが公開される前に、対応するメンテナンスビジネスの包括的な回帰に加えて、他のビジネスは必要な迅速な返品を行うためにTop100高周波サービスを選択します。戦略的分析：テストを実際の生産に厳密に追跡させます。顧客が生産で気にするビジネスは、テストの最も重要な保護です。
5）異なる環境に基づく3ラウンドの相互検証。幅広いユーザーを抱える銀行業であるため、各機能ポイントは3回の相互検証テストで起動されます。A環境の1回目のテスターが初期テストを行い、合格後、B環境の2回目のテスターがレビューを行います。再テストに合格した後、テスターCはC環境で回帰テストを実行します。また、さまざまなテスターに、レビューされたユースケースを制限せず、要件に基づいてより多様なランダムテストを実行するように促します。戦略的分析：テスターの個人的な思考パターンに基づいて、死角や不十分なテストのリスクを効果的に回避します。
6）自動煙テストに基づく。各開発バージョンが送信された後、最初にバージョンの構成と自動テストを通じてコードのテスト可能性が検証されます。煙の通過率が90％未満の場合は直接返却され、煙の通過率が90％以上100％未満の場合は不良品により返却の可否が決定されます。ユースケースのスモークテストセットを継続的に更新します（動的）。戦略分析：自動化されたツールを効果的に使用し、システムを使用してテストアクセスをチェックし、無効なテストの実行を回避します。
7）テスト結果に基づく評価主導の戦略。テスターの数が多く、態度や能力が不均一であることを考慮して、2か月のオンラインサイクルの後、すべてのテストエグゼクティブは、合計10次元の定量的スコアリング評価の対象となり、通知後6ポイントの最初の3ポイントに報酬を与えます。 3人を引退させ、最後の6人を2回続けてクリアした。この戦略は、ナマズの効果を効果的に発揮し、テスターの熱意と配達能力を向上させました。戦略的分析：ナマズ効果を使用して、テスターが平和な時期の危険に備えることを学び、圧力を直接動機に変換し、テスターのセルフドライブを効果的に動員します！
8）テストデマンド作業指示に基づく責任者戦略。テストからテスト要件の開始まで、テストの最終レポートは、ABCの3ラウンドのテスター、テストチームリーダー、およびテストマネージャーによって署名され、すべてのレベルの責任が実行されます。戦略的分析：説明責任に基づいて、需要作業指示書のテスト品質は、マルチレベルの責任者に関連付けられています。人事管理から始めて、ビジネス特性設計のユースケースを統合し、ユースケースを選択し、環境を選択し、テスト評価とインセンティブ戦略を統合します。テスト戦略は常に人間とビジネスの2つのコアに焦点を当て、人間とビジネスの有機的な統合を促進し、最終的にテスト効率を向上させます。配信品質。
2.2大手証券会社のPBシステムのテストプロジェクトの背景：コアユーザーを獲得し、事業規模を拡大するために、証券会社は主要顧客のニーズに応じて複数のPBビジネスシステムを同時に立ち上げました。プロジェクト開発規模：50人以上の開発者。プロジェクトテスト規模：3人のフルタイムテスター。プロジェクト実装の難しさ：
PBビジネスシステムは、株式、オプション、ファンド、債券、新サードボードなど、市場全体のコアビジネスに直接接続しており、テスターのビジネス能力の幅広さと実験に対する非常に高い要件があります。特にリスク管理には、テスターが高度なビジネス理解を持っている必要があります。
プロジェクトのオンラインテストでは、テストの配信が大幅にピークに達しました。同社は、テストマネージャーを1人、外部委託のテストエグゼクティブを2人だけ構成し、人員は非常にタイトでした。
開発者も複数の仲介業者に直面しており、開発内でスケジュールされたタスクがあり、ブランチバージョンも多数あります。関連する3つのシステムは、3か月以内に順番に起動され、バージョン制御とテスト計画はすべて困難です。
開発者は主にアウトソーシングサプライヤーであり、オフショアで開発しています。テストコミュニケーションの役割は多く、リアルタイムで議論することは困難です。
顧客のニーズに基づいて、事業部門はシステムが稼働することを非常に期待しています。オンライン品質保証の圧力は非常に大きいです。
テスト戦略アプリケーション：
1）安定版テストに基づいて、すべての箇条書きを保存し、テストアクセスゲートを厳守してください。リリースされたバージョンの頻度と品質を厳密に管理します。スモークテストは合計3回失敗し、開発サプライヤーの担当者にインタビューが行われました。戦略的分析：チェックと説明責任は2つの側面からなり、開発バージョンの品質の低下や内部テストの欠如のリスクを効果的に回避します。
2）ビジネスシナリオに基づくテスト。テスターの厳しさと比較的集中したタスクのために、プロジェクトチームは、関連するビジネスモジュールの教師に、テスターのガイド、ビジネスプロセスの明確化、ビジネスシナリオの一覧表示を特別に依頼し、テスターはビジネスシナリオに基づいてテストケースを分類し、ビジネス教師にレビューとチェックを依頼しました。ビジネスカバレッジを確保するため。戦略的分析：テスターのテクノロジーとビジネスのビジネスを有機的に組み合わせて、1 + 1> 2のテストフォースを形成します。
3）完全なビジネス能力の向上に基づくテストの実行。言われているように、ナイフを研ぐことは誤って薪を切ることはなく、テストマネージャーは人が少なくタスクが多いために盲目的にテストの実行に投資しませんでした。テスターのビジネスの限られた蓄積に応えて、プロジェクトチームは、9つの連続したビジネスおよび技術トレーニングを組織し、同じテストサプライヤーから他の3人のテスターを動員して、テストリザーブチームとしてトレーニングに参加しました。戦略的分析：Zeng Guofanは、軍隊になるための訓練を受けていないときは、あえて軍隊を派遣しませんでした。これも真実です。テスターのビジネスが一定のレベルに達した場合にのみ、テストの実行が有効になります。戦闘効果なしで戦うことは、資源を浪費し、モラルを一掃するだけです。
4）事業部門に基づくバッチテスト。ビジネスシステム内のパブリックモジュール以外のビジネステンプレートの相対的な独立性に基づいて、テストチームと開発チームは、パブリックモジュールから高頻度ビジネスモジュール、次に低頻度ビジネスモジュールへの関連する配信計画について合意します。テストグループは分割されて囲まれ、段階的にテストされ、最後に統合テストとオンラインバージョンテストのラウンドが実行されます。戦略的分析：合理的な削減、主要なビジネスに対処するための力の集中、およびそれらを整然とした方法でバッチで実行することは、力が不十分な場合に必要な戦略です。
5）ビジネス影響分析に基づく回帰テスト。テスターの数が少ないため、限られたリソースと時間を完全に返すことはできません。テストマネージャーは、すべてのテスト要員の合理的かつ効率的な使用を大切にしています。回帰テストの場合、テストマネージャーは最初に各バージョンのコードを2つのレベルで分析します。1つ目はブラックボックス分析です。変更された機能ポイントについて、関連するビジネスシナリオと機能ポイントの使用例をすぐに見つけます。補足。2つ目はホワイトボックス分析です。コード変更後に転送関係にある関連関数、クラス、またはパッケージを分類し、これらの関数に関連する関数ポイントとビジネスパスを明確にし、最後に、リップル分析の2つのレイヤーに従って、正確に開発者を支援してください。返す必要のあるユースケースの範囲を決定します。戦略的分析：周囲の開発リソースを動員し、方向性のある広がり分析を行い、回帰の範囲を効果的に特定します。不十分な回帰テストのリスクを最小限に抑えます。
6）クロステストに基づく高速実行。実行効率と目に見える結果を強調します。テストコミュニケーションでは、毎日のスタンドアップモーニングミーティングが進捗状況と問題を同期します。テストケースはビジネスシナリオ分析とチームレビューを強調します。テスト欠陥追跡は問題解決を強調します。開発および配信バージョンが実行サイクルに入ると、共通モジュールの迅速なテストと主要モジュールのクロステストの組み合わせが強調されます。 、問題のあるモジュールは爆撃に焦点を当てています。戦略分析：テストの要点に焦点を合わせ、主要モジュールと欠陥モジュールに遅れずについていき、欠陥を取り締まることが、すべてのテスターが学ばなければならない戦略です。
7）必要なシナリオに応じた整然としたテストとランダムな発散テストの組み合わせにより、通常の要件を確実にカバーするだけでなく、例外処理の探索的テストも保証されます。戦略分析：秩序だったテストはカバレッジを保証することです。ランダムな発散探索は、テスト経験の蓄積に依存します。これにより、テストを見逃すリスクを効果的に減らすだけでなく、テスターがテストの思考習慣の限界を超えてジャンプできるようになります。
2.3テスト戦略の適用からの経験と教訓
長期的なテスト管理の実践では、主に次のように、テスト戦略の使用に関するいくつかの経験と教訓を要約しました。
自動テストの入出力比を考慮しながら、自動テストに注意を払いますが、自動テストに依存しないでください。
リソースが逼迫していると、事業の蓄積の重要性や個人の能力向上の必要性がより顕著になりますので、常に事業研修に注力する必要があります。テストチームの全体的な品質を効果的に向上させることができます。
テスト戦略の最も重要な制御は、テストリソースの効率的な統合と最適な利用です。統合して活用するリソースの中で決定的な要素は人です。テストエンジニアがテスト、実際の結果をテストし、結果を得ることができるように、テストリソースをどのように動員（または借用）するか。重要なポイントは、チームメンバーの成長のためにチームメンバーと対等な立場で仲良くすることです。効果的なインセンティブを実行するため。
無駄を予断することなく、事前に警告されます。テスト戦略の策定には、リソース、範囲、時間、コスト、および関連する利害関係者の要求を考慮し、困難とリスクを予測する予測計画が必要です。
作業環境の作成と管理は、テスト戦略の推進と効果的な実行を保証します。まず、否定的な感情の伝達はテストマネージャーで停止します。第二に、戦略的には、解決策があると信じ、プロジェクトで常に発生するリスクの問題に戦術的に注意を払い、プロジェクトチームの総合力を動員し、会社にタイムリーな支援を求める必要があります。
段階的テストの実行後の通信の要約は非常に重要であり、テストフィードバックはテスト戦略の最適化と微調整を促進します。
- 総括する
この記事では、テスト戦略の重要性を紹介し、テスト戦略の包括的な適用という2つの財務プロジェクトの実践に焦点を当て、最後にテスト戦略の包括的な適用の経験と教訓を要約します。テスト戦略の実装は、テスト管理の実装の重要な部分であり、テスト戦略の管理も、テクノロジーとアートの包括的なアプリケーションです。テスト戦略は、テスト実装の「概要」と「リード」です。テスト戦略を包括的に適用するための固定された方法はありません。プロジェクトによって異なり、比較的柔軟性があります。チームが異なれば、同じプロジェクトフェーズでも異なるテスト戦略を採用する必要がある場合があります。同様に、テスト戦略の使用は、テクノロジーの使用だけでなく、アートの表示でもあります。「テスト」には明確な方法がなく、「テスト」にも方法が必要です。テストエンジニアやテストマネージャーとして、テストの実践を最適化し、テスト管理を改善するには長い道のりがあります。プロジェクトを護衛するために、テスト戦略の新しいモデルと方法を継続的に模索する必要があります。
記事の出典：ソフトウェア品質レポート