1. Web サイトを与えられた場合、どのようにテストしますか? （ニーズ探索＋計画策定）
まず、要件の説明や Web サイトのデザインなどの関連ドキュメントを見つけて、テスト要件を分析します。
テスト計画を作成し、テスト範囲とテスト戦略を決定します。通常、次の部分が含まれます。
機能テスト、インターフェーステスト、パフォーマンステスト、データベーステスト、セキュリティテスト、互換性テスト
機能テストには次の側面が含まれますが、これらに限定されません。
リンクテスト。リンクが正しくジャンプするか、空のページや無効なページはないか、誤ったエラー メッセージが返されるかどうか。
関数のテストを送信します。
マルチメディア要素を正しくロードして表示できるかどうか。
多言語対応により、選択した言語が正しく表示されるかどうかなど。
インターフェイスのテストには次の側面が含まれますが、これらに限定されません。
ページのスタイルが統一されていて美しいかどうか
ページレイアウトは合理的か、キーコンテンツやホットコンテンツは目立つか
制御が正常に動作するかどうか
インストールする必要があるがインストールされていないコントロールについて、自動ダウンロードおよびインストールの機能を提供するかどうか
単語チェック
パフォーマンス テストでは通常、次の 2 つの側面が考慮されます。
圧力試験;
負荷テスト。
強度試験
データベースのテストは、実行する必要があるかどうかを具体的に判断する必要があります。データベースでは通常、接続、データ アクセス操作、データ コンテンツの検証を考慮する必要があります。
セキュリティテスト:
基本的なログイン機能をチェックします
システムクラッシュや権限リークを引き起こすオーバーフローエラーが発生したかどうか
SQL インジェクションなど、関連する開発言語の一般的なセキュリティ問題チェック。
高度なセキュリティ テストが必要な場合は、専門のセキュリティ会社の支援を受けるか、テストを外注するか、サポートを受けるようにしてください。
互換性テストは、要件の説明の内容に従って、サポートされるプラットフォームの組み合わせを決定します。
ブラウザの互換性。
オペレーティング システムの互換性。
ソフトウェアプラットフォームの互換性。
データベースの互換性
テストが実行され、欠陥が記録されます。テストスケジュールを合理的に調整および調整し、テストに必要なリソースを事前に取得し、管理システム (要件の変更、リスク、構成、テスト文書、欠陥レポート、人的リソースなど) を確立します。
定期的にテストを見直し、評価、要約し、テストの内容を調整します。
2. 現在の主なテストケース設計方法は何ですか?
ホワイトボックステスト: ロジックカバレッジ、ループカバレッジ、基本パスカバレッジ
ブラックボックステスト：境界値解析、同値クラス分割、エラー推測、因果関係図、状態図、テスト概要法、ランダムテスト、シナリオ法
システムデータの独立性、システムデータのバックアップ・リカバリ機能（データのバックアップが完了しているか、リストアが可能か、リストアが完了できるか）
3. 静的テスト、動的テスト、ブラック ボックス テスト、ホワイト ボックス テスト、アルファ テスト、ベータ テストとは何かを簡単に説明します。
静的テストは、プログラム自体を実行せずに、プログラム コード内の潜在的なバグを見つけたり、プログラム コードを評価したりするプロセスです。
動的テストとは、テスト対象のプログラムを実際に実行し、対応するテストインスタンスを入力し、実行結果と期待される結果との差異を確認し、実行結果が要件を満たしているかどうかを判断することにより、プログラムの正確性、信頼性、有効性を検証することです。プログラムを解析し、システムの動作効率や堅牢性などの性能を分析します。
ブラックボックステストは、ソフトウェア機能の正確性や操作性を確認するために一般的に使用され、入出力間の関係やプログラム機能の場合は、ソフトウェアの仕様に基づいてテストケースを決定し、テスト結果の正確性を推測します。
ホワイトボックステストは、ソフトウェアの論理構造の分析に基づいて実行され、コードベースのテストであり、テスターはプログラムコードを読み取るか、開発ツールのシングルステップデバッグを使用してソフトウェアの品質を判断します。一般的にブラックボックステストはプロジェクトマネージャーが行い、それを達成するためにプログラマーが開発を行います。
アルファテストは、ユーザーが開発環境で実施するテスト、または社内のユーザーが実際の運用環境を模擬して実施する管理テストであり、プログラマーやテスターが行うことはできません。
ベータテストとは、ソフトウェアの複数のユーザーが、1人または複数のユーザーの実際の使用環境下で実行するテストです。通常、開発者はテスト サイトには存在せず、プログラマーやテスターがベータ テストを行うことはできません。
4. ソフトウェアのテストはいくつかの段階に分かれていますが、各段階のテスト戦略と要件は何ですか?
開発プロセスに対応して、テスト プロセスは、単体テスト、統合テスト、システム テスト、受け入れテストの 4 つの主要な段階を経ます。
単体テスト: 単体テストは、ソフトウェア設計の最小単位、つまり正確性をチェックするためのプログラム モジュールまたはコード セグメントのテスト作業であり、通常は開発者によって実行されます。
統合テスト: 統合テストは、テストの設計要件に従ってモジュールを組み立てることであり、主な目的はインターフェイスに関連する問題を見つけることです。製品をテスト部門に提出する前に製品開発チームは共同デバッグを実施する必要があるため、ほとんどの企業では統合テストは開発者によって行われます。
システムテスト: システムテストは統合テストに合格した後に実行されます。その目的は、システムを完全に実行し、各サブシステムが正常に動作し、設計要件を満たしているかどうかを検証することです。主にテスト部門で実施され、テスト部門の中で最も大規模かつ最も重要なテストであり、製品の品質に大きな影響を与えます。
受け入れテスト: 受け入れテストは、要求フェーズの「要求仕様書」を受け入れ基準とし、実際のユーザーの動作環境をシミュレートする必要があります。実際のプロジェクトの場合は顧客と一緒に実施できますし、製品の場合は最後のシステムテストになります。テスト内容は機能モジュールの総合テスト、特にドキュメントテストです。
単体テストのテスト戦略:
トップダウンの単体テスト戦略: 単独の単体テストよりもはるかにコストがかかるため、単体テストには適していません。
ボトムアップの単体テスト戦略: より合理的な単体テスト戦略ですが、テスト サイクルが長くなります。
統合テストのテスト戦略:
Big Bang Integration: メンテナンス プロジェクトまたはテスト対象のシステムが小規模な場合に適しています
トップダウン統合: 明確で安定した制御構造を持つ製品に適しています。上位レベルのインターフェイスはほとんど変更されません。下位レベルのインターフェイスは未定義であるか、頻繁に変更される可能性があります。生産ポート制御コンポーネントは技術的リスクが比較的高く、検証が必要です。できるだけ早く、できればできるだけ早く 製品のシステム機能動作を確認できます。
ボトムアップ統合: 最下位のインターフェイスは比較的安定していますが、上位のインターフェイスは頻繁に変更され、最下位のコンポーネントはより早く完成します。
進捗ベースの統合
利点: 高度な並列性があり、プロジェクトの開発進行を効果的に短縮できます。
短所: 杭とドライバーの作業負荷が大きい、一部のインターフェイス テストが不十分、一部のテストが反復的で無駄である。
システムテストのテスト戦略:
データとデータベースの整合性テスト。
機能テスト;
ユーザーインターフェイスのテスト。
パフォーマンス評価。
負荷テスト。
強度テスト。
能力テスト。
セキュリティとアクセス制御のテスト。
フェイルオーバーとリカバリのテスト。
構成テスト。
取り付けテスト。
暗号化テスト。
ユーザビリティテスト。
バージョン検証テスト。
書類試験
5. ソフトウェアテストの各フェーズでは通常どのような作業が行われますか? 各フェーズの成果文書は何ですか? 何が含まれていますか?
単体テスト段階: 独立した各単体モジュールをシステムの他の部分から分離してテストし、各プログラム モジュールの正当性をチェックして、各プログラム モジュールが指定された機能を正しく実装しているかどうかを確認します。単体テストレポートを生成し、欠陥レポートを提出します。
統合テスト段階: 統合テストは単体テストに基づいており、すべてのソフトウェアユニットが対応する技術指標と必要なアクティビティを満たしているか、または実現しているかどうかをテストします。このフェーズでは、統合テスト レポートが生成され、欠陥レポートが送信されます。
システムテストフェーズ: 検証テストに合格したソフトウェアは、特定のコンピュータシステム全体の要素として使用され、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わせて、実際の動作でテストされます。環境: コンピュータ システムの包括的な機能範囲。この段階では、テストの概要と欠陥レポートを提出する必要があります。
6. ソフトウェアの欠陥 (またはバグ) 記録には何が含まれますか?
バグ記録には基本的に次の内容を含める必要があります。
バグ番号。
バグの重大度レベル、優先度。
バグによって生成されたモジュール。
まず、バグの一般的な内容を説明するバグの概要が必要です。
バグに対応するバージョン。
いくつかのスクリーンショット、ビデオなどを含む、バグの詳細な説明。
バグが発生したときのテスト環境と、生成された条件が対応する操作手順です。
7. ブラックボックステストとホワイトボックステスト、それぞれの長所と短所
ブラックボックス テストの利点は、比較的単純で、プログラムの内部コードや実装を理解する必要がないこと、ソフトウェアの内部実装とは何の関係もないこと、ユーザーの観点からは、それを知るのが簡単であることです。ユーザーがどの機能を使用するか、どのような問題が発生するか、ソフトウェア開発ドキュメントに基づいて、ドキュメント内のどの機能がソフトウェアによって実装されているかを知ることもでき、ソフトウェア自動テストを行うときに便利です。
ブラックボックス テストの欠点は、すべてのコードをカバーすることは不可能であり、カバー率が低く、コード量全体の 30% に達するだけであること、自動テストの再利用性が低いことです。
ホワイト ボックス テストの利点は、ソフトウェア テスターがコード カバレッジを増やし、コードの品質を向上させ、コード内の隠れた問題を発見できるようにすることです。
ホワイト ボックス テストの欠点は、プログラムを実行するにはさまざまなパスがあり、すべての実行パスをテストすることは不可能であること、テストはコードに基づいており、開発者が実行しているかどうかしかテストできないことです。正しいものですが、設計が正しいかどうかを知ることができず、一部の機能要件を見逃す可能性があります。システムが巨大な場合、テストのオーバーヘッドが非常に大きくなります。
8. 紙コップをテストするにはどうすればよいですか?
機能: 水カップに水を入れて、漏れているかどうかを確認し、水が飲めるかどうかを確認します。
安全性: カップの中に毒物や細菌はありませんか?
信頼性: さまざまな高さから落としたカップの損傷の程度
携帯性: カップがさまざまな場所、温度、その他の環境でも正常に使用できるかどうか
互換性: カップにジュース、白湯、アルコール、ガソリンなどを入れることができるかどうか。
使いやすさ：カップは熱いか、滑り止めはあるか、飲みやすいか
ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、および使用条件が詳細に記載されていますか?
疲労試験：カップに水を入れ（ケース1）24時間放置し漏れ時間と状況を確認、ガソリンを入れて（ケース2）24時間放置し漏れ時間と漏れ状況等を確認します。
圧力テスト: 針を使用し、針に重りを加え続けて、どの程度の圧力が浸透するかを確認します。
9. ブラック ボックス テストのテスト ケースの一般的な設計方法は何ですか? テストケース設計作業におけるメソッドの適用。
1) 同値クラスの分割:同値クラスとは入力領域の部分集合を指します. この部分集合では, 各入力データはプログラムの誤りを明らかにすることに相当します. ある等価性をテストする クラスの代表値はこのクラスの他の値の検定と等しいため、すべての入力データは合理的に複数の同値クラスに分割でき、各同値クラスの 1 つのデータが検定の入力条件として取られ、少量の代表的なテスト データ。良好なテスト結果が得られます。同値クラスの分割には、有効な同値クラスと無効な同値クラスという 2 つの異なる状況が考えられます。
2) 境界値分析:同値クラス分割法を補足するものです。テスト業務の経験から、入出力範囲内ではなく、入出力範囲の境界で多くのエラーが発生することがわかっているため、さまざまな境界条件に合わせてテスト ケースを設計することで、より多くのエラーを検出できるようになります。
境界値分析手法を使用してテスト ケースを設計するには、最初に境界条件を決定する必要があります。通常、入力と出力の同値クラスの境界は、テストに重点を置く必要がある境界条件です。値が完全に等しい、同値クラス内の典型的な値や任意の値をテスト データとして選択するのではなく、境界よりわずかに大きいか小さい値をテスト データとして選択する必要があります。
3) エラー推測方法: 経験と直観に基づいて、プログラム内のすべての考えられるエラーを推測し、的を絞った方法でテスト ケースを設計します。
エラー推測手法の基本的な考え方: プログラム内で考えられるすべてのエラーとエラーが発生しやすい特殊なケースをリストし、それらに基づいてテスト ケースを選択します。たとえば、単体テスト中にモジュール内の多くの一般的なエラーがリストされています。従来品 テストで見つかったエラー等、経験をまとめたものです また、入力データ、出力データが0である、入力フォームが空白、または入力フォームが1行しかない などの状況です。これらの状況を選択できます 次の例はテスト ケースとして使用されます。
4) 特性要因図法：上記で紹介した同値クラス分割法と境界値分析法は、いずれも入力条件を考慮することに重点を置いており、入力条件間の関係や相互の組み合わせなどは考慮していません。入力条件の組み合わせにより、新たな状況が生成される場合もありますが、入力条件の組み合わせを確認することは容易ではありません。すべての入力条件を同値類に分けたとしても、それらの組み合わせは非常に多く存在します。さまざまな条件の組み合わせを記述し、それに応じて複数のアクションを生成してテストケースの設計を検討するために、因果関係図（ロジックモデル）を使用する必要があります。因果関係図法の最終結果は、判定テーブルですので、様々な組み合わせのプログラム入力条件を確認するのに適しています。
5) 直交テーブル分析手法: 多数のパラメータの組み合わせによりテストケースの数が急増する可能性がありますが、これらのテストケースには明らかな優先順位のギャップがなく、テスターがそのようなテストを完了することはできません。多数のテストがあるため、直交表を使用していくつかのユースケースを削減し、できる限り少ないユースケースでできるだけ広い範囲をカバーできるようにすることができます。
6) シナリオ分析手法: ユーザーのシナリオに従ってユーザーの操作手順をシミュレーションすることを指し、特性要因図に似ていますが、実行の深さと実行可能性の点でより優れている場合があります。
7) 状態図法: 入力条件とシステム要件の記述を通じてテスト対象システムのすべての状態を取得し、入力条件と状態を通じて出力条件を取得し、入力条件、出力条件と状態を通じてテスト対象システムのテスト ケースを取得します。
8) アウトライン法: アウトライン法は、要件に焦点を当てた方法であり、さまざまなテスト条件を列挙するために、要件をアウトラインに変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内のリーフまたはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。
10. テスト活動の完全なプロセスを詳細に説明します。(参考までに、この回答は主にウォーターフォールモデルの実践です)
プロジェクトマネージャーは顧客とコミュニケーションをとって要件文書を完成させ、開発者とテスターは共同で要件文書のレビューを完了します。 。プロジェクトマネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。その後、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要求書に従って要件分析書を完成させ、テスターは両者の認識漏れや認識の相違がないかを主なレビュー内容とします。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析書に従ってテストケースの作成を開始し、開発者は概要設計書と詳細設計書を完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テスト ケースが完了したら、テストと開発をレビューする必要があります。
テスターが環境を構築する
開発者は最初のバージョンを提出しますが、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
開発者はバグ修正や機能追加を含む第2版を提出し、テスターがテストを実施します。
上記の作業を繰り返すと、通常 3 ～ 4 バージョン後に BUG の数が減り、出荷要件が満たされます。
顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
11. 統合テストにおけるトップダウン統合とボトムアップ統合という 2 つの戦略についての理解を説明し、それぞれの長所と短所、およびどのタイプのテストが主に適しているかについて話します。
トップダウンの統合
利点: 主要な制御および判断ポイントがより早期に検証される; 完全なソフトウェア機能を最初に深さに応じて実現および検証できる; 機能がより早期に検証されるため、信頼性がもたらされる; 必要なドライバは 1 つだけであり、ドライバ開発コストが削減される; 障害分離をサポートします。
短所: カラムの開発量が多い、基礎となる検証が遅れる、基礎となるコンポーネントが十分にテストされていない。
製品管理構造は比較的明確で安定しています。高レベルのインターフェースはほとんど変更されません。低レベルのインターフェースは未定義であるか、頻繁に変更される可能性があります。生産および港湾制御コンポーネントには高い技術的リスクがあり、できるだけ早く検証する必要があります。 ; 製品のシステムの機能的な動作をできるだけ早く確認したいと考えています。
ボトムアップの統合
利点: 基礎となるコンポーネントの動作を早期に検証できます。最初に作業を並行して統合できるため、トップダウンよりも効率的です。スタブの作業負荷が軽減され、障害の分離がサポートされます。
短所: ドライバーの開発負荷が大きい、高レベルの検証が遅れ、設計ミスの発見が間に合わない。
基礎となるインターフェイスは比較的安定しており、上位レベルのインターフェイスは頻繁に変更され、基礎となるコンポーネントはより早く完成します。
12. テスト ケースを設計するときはどのような側面を考慮する必要がありますか?つまり、どの側面がさまざまなテスト ケースでテストされますか?
テストケースを設計する際には、全体のプロセスや機能だけでなく、強度テスト、性能テスト、ストレステスト、境界値テスト、安定性テスト、セキュリティテストなどの側面にも注意を払う必要があります。(テスト ケースで考慮する必要がある 4 つの基本要素は、入力、出力、操作、およびテスト環境です。さらに、テスト ケースでは、テストの種類 (機能、パフォーマンス、セキュリティなど) を考慮する必要があります。この部分は、 TP を参照することで回答できます。また、ユースケースの重要性と優先順位も考慮する必要があります)
13. Windowsでテキストファイルを保存する際、保存ダイアログが表示されますが、そのファイル名でテストケースを作成する場合、同値クラスはどのように分ければよいでしょうか？
A などの半角文字、全角文字、AA、I I、特殊文字 /'。';、=- など、com などの予約語、ファイル形式が 8.3 形式である、ファイル名の形式が 8.3 形式ではない、/、*、およびその他の 9 つの特殊文字。
10 文字の郵便番号の入力を必要とするテキスト ボックスがあると仮定すると、テキスト ボックスを同等のクラスにどのように分割する必要がありますか?
特殊文字（10 * や ¥ など）、英字（ABCDefghik など）、10 文字未満（123 など）、10 文字を超える文字（11 など）、数字とその他の混合（123AAAAAAAA など）、空文字、予約文字
14. 単体テスト、統合テスト、システム テストの焦点は何ですか?
単体テストは、ソフトウェア設計の最小単位であるプログラムモジュール（プロセス指向では関数や手続き、オブジェクト指向ではクラス）を対象とし、各プログラムモジュール内に存在する可能性のあるエラーを発見する正当性チェックのテスト作業です。一般に、手動静的検査と動的実行追跡の 2 つのステップがあります。
結合テストは、単体テストを通過した各モジュールに統合されたコンポーネントをテストすることを目的としており、主な内容は各単位モジュール間のインターフェースと統合後の各モジュールが実現する機能です。
システムテストは、コンピュータシステム全体の要素として、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わされた統合ソフトウェアシステムを対象としており、実際の動作環境で一連のテストを実行します。コンピュータシステム上の統合テストと検証テスト。
15. あなたが知っているソフトウェアテストの種類を教えてください。それらを簡単に紹介します。
テスト戦略によって分類されます。 1. 静的テストと動的テスト 2. ブラック ボックス テストとホワイト ボックス テスト 3. 手動テストと自動テスト 4. スモーク テスト 5. 回帰テスト。
テストフェーズによって分類: 単体テスト、統合テスト、システムテスト。
その他の一般的なテスト方法: 1. 機能テスト 2. パフォーマンス テスト 3. ストレス テスト 4. 負荷テスト 5. ユーザビリティ テスト 6. インストール テスト 7. インターフェイス テスト 8. 構成テスト 9. ドキュメント テスト 10. 互換性テスト 11. セキュリティ テスト 12 、回復テスト
16. テストケース設計で良い仕事をするための鍵は何だと思いますか?
ホワイトボックス テスト ケース設計の鍵は、より少ないテスト ケースでできるだけ多くの内部プログラム ロジックの結果をカバーすることです。
ブラックボックス ユース ケース設計の鍵は、より少ないユース ケースでモジュールの出力インターフェイスと入力インターフェイスをカバーすることでもあります。最小限のユースケースで妥当な時間内に最大限の問題を見つける完全なテストは不可能
17. 完全なテスト セットはどのフェーズで構成されますか?
実現可能性分析、要件分析、全体設計、詳細設計、コーディング、単体テスト、結合テスト、システムテスト、受け入れテスト