試験職の面接は実はよく似ていますが、ここではよく聞かれる面接の質問185個を集めてまとめましたので、就職活動中の方や転職準備中の皆さんのお役に立てれば幸いです。
1. テストの基本
1. テスト計画の立て方
参考回答：
テスト計画には、テストの目的、テスト範囲、テスト環境の説明、テストの種類（機能、セキュリティ、パフォーマンス、安定性）の説明、テストツール、モジュール分割、テストリーダー、テスト実行ラウンドのタイムスケジュール、および関連文書が含まれます。文書管理リポジトリ内の位置、テストのリスク。モジュールの分割は、テスターの業務知識や個人的な能力に基づいて割り当てる必要があり、作業負荷の見積もりは、これまでのテスト経験に基づいて行う必要があり、この要件の修正と組み合わせることで、テスト量を大まかに見積もることができます。
2. プロジェクトでソフトウェアの品質を確保する方法
参考回答：
プロジェクトの品質は、1 人または特定のチームだけで保証されるものではなく、チーム全体の共同作業の結果であり、会社レベルで標準化されたプロジェクト プロセスが必要です。
1. 製品については、反復プロセス中に製品ロジックを確認し、互換性とアップグレードの可能性を予測し、ソリューションを提供します。
2.製品表現を満足させながらデザインの連続性を確保するデザイン。
3. 開発中は製品の詳細を確認し、互換性と性能を考慮して技術ソリューションを厳密に選択し、開発完了後は完全な自己テストを実施し、開発仕様に厳密に従う必要があります。
4. プロダクトロジックのテストと検証、ユーザー視点でのインタラクションデザインの体系的な検証を実施し、可能な限り多くの技術的手段を用いてテスト品質を確保する
3. 機能テスト ケースには通常何が含まれますか?
参考回答：
一般に要素には、ユース ケース番号、ユース ケースの優先順位、テストの目的、属するモジュール、前提条件、テスト環境、
入力データ、テスト手順、期待される結果、テスト スクリプトなど。
中心的な要素: ユースケースの優先順位、テストの目的、期待される結果
4. ブラック ボックス (または機能) テスト ケースの設計方法とは何ですか?
参考回答：
同値クラス分割法: 同値クラス分割法は、プログラムのすべての可能な入力データ (有効および無効) をいくつかの同値クラスに分割します。
境界値法: 境界値分析法は、入力または出力の境界値をテストするブラック ボックス テスト手法です。
エラー推測法: プログラムをテストするとき、経験や直感に基づいてプログラム内に存在する可能性のあるさまざまなエラーを推測し、これらのエラーを的を絞った方法でチェックするテスト ケースを作成できます。
特性要因図法: 特性要因図法は、複数の入力条件の組み合わせを記述するのに適した検査法であり、入力条件の組み合わせ、制約関係、出力条件の因果関係に基づいて、入力条件のさまざまな組み合わせを記述します。ユースケース法は、プログラムの入力条件のさまざまな組み合わせを確認するのに適しています。
デシジョンテーブル駆動分析手法：デシジョンテーブルとは、ブラックボックステスト手法の一つで、条件となるすべての入力の様々な組み合わせ値と、それに対応する出力値を列挙して形成されるテーブルです。
直交分解法: 多要素、多レベルを検討するための設計手法であり、直交性に基づいて、テスト要素のすべてのレベルの組み合わせからいくつかの代表的な点を選択してテストします。この部分のテスト結果を分析することで、分析します。テスト全体の状況を理解して、最適なレベルの組み合わせを見つけます。
シナリオ分析手法：ソフトウェアの適用シナリオを分析し、ユーザーの視点でテストケースを設計する、ユーザー指向のテストケース設計手法です。製品が何をするかではなく、ユーザーが何をするかに注目してください。
グローバルな探索的テスト方法: テスターは、アプリケーションによって提供される情報に基づいて、制限や制約を受けることなく、プログラムのさまざまな機能を自由に探索できます。
5.APPテストとWebテストの違いは何ですか?
Web 側のテストとモバイル側のテストは基本的に似た種類のテストであり、どちらも機能テスト、パフォーマンス テスト、セキュリティ テストが必要です。
テストでは主に、Web 側 (通常は B/S アーキテクチャでブラウザベース) とアプリ (C/S アーキテクチャでクライアントが存在する) を区別します。
(1) システム アーキテクチャの観点から: Web テストでサーバーが更新される限り、クライアントも同時に更新され、サーバーがアプリで変更される場合、クライアント ユーザーが使用するすべてのコア バージョンが必要になることを意味します。再度テストしてください。
(2) クライアントのパフォーマンス: Web は応答時間のみを重視する場合がありますが、アプリはトラフィック、電力、CPU なども考慮する場合があります。
(3) 互換性: Web はブラウザーに基づいているため、ブラウザー (IE、Chrome、Firefox) とコンピューター ハードウェアおよびコンピューター システム間の互換性が優先されます。アプリのテストは、解像度、レート、チャネルだけでなく、携帯電話またはパッドに依存する必要があります。サイズや設備システムも重要です。
6. バグが見つかった場合、それがアプリ側の問題なのかサーバー側の問題なのかをどのように判断すればよいですか?
1. パケット キャプチャ分析: クライアント上のパケットをキャプチャし、サーバーから返されたデータが期待を満たしているかどうかを分析します。
サーバーのデータが正しい場合、それはクライアントの問題です
2. ログ分析は、クライアント/サーバーのログを参照し、異常なログ情報がないか分析することができます。
具体的な理由を特定するために
7. アプリのインストール機能のテスト ポイントを作成しますか?
1. 通常のインストール テストを実行して、インストールが成功したかどうかを確認します。
2. APP バージョン カバレッジ テスト。たとえば、最初にバージョン 1.0 APP をインストールし、次に上位バージョン (バージョン 1.1) APP をインストールして、上書きされているかどうかを確認します。
3. バージョンのテストをロールバックします。例: 最初にバージョン 2.0 APP をインストールし、次にバージョン 1.0 APP をインストールします。通常の状況では、バージョンはロールバックできます。
4. インストール中にメモリが不足し、プロンプトがポップアップ表示されます。
5. 設置マニュアルに従って、正しく設置されていることを確認してください。
6. インストール中に予期せぬ事態（強制停電、ネットワーク切断、着信、情報確認）などが発生した場合の対応を確認します。
7. 「同期ソフトウェア」を使用して、インストール中にいくつかのファイルが同時にインストールされているかどうかを確認します。
8. さまざまなモデル、システム、画面サイズ、解像度の携帯電話にインストールします。
9. SD カードがインストール中に認識され、デフォルトで SD カードにインストールされるかどうか。
10. インストール完了後、アプリケーションは正常に起動できますか?
11. インストールが完了したら、電話機を再起動して、アプリケーションが正常に起動できるかどうかを確認します。
12. インストール完了後、他のアプリケーションに影響はありますか?
13. インストールが完了したら、ショートカットを追加できますか?
14. インストール完了後、ウイルス対策ソフトはウイルスとして扱いますか?
15. 複数のプロセスを経てインストールし、インストールが成功したかどうかを確認します。
16. インストールプロセス中のプロンプト情報はすべて英語または中国語である必要があり、プロンプト情報にコード、記号、文字化けなどを含めることはできません。
17. インストール後、プログラムを自動的に起動するかどうか。
18. サードパーティのインストールをサポートするかどうか。
19. インストール中に「キャンセル」をクリックします。
8. 継続的インテグレーションの目的は何ですか?
継続的統合とは、コードを頻繁に (1 日に複数回) トランクに統合することを指します。
主な利点は 2 つあります。
(1) エラーを素早く見つけます。更新が完了するたびにバックボーンに統合されるため、エラーがすぐに発見され、エラーの場所を特定しやすくなります。
(2) 枝が幹から大きく逸脱しないようにする。統合が頻繁に行われず、バックボーンが常に更新されている場合、統合はさらに困難になるか、将来的には困難になる可能性があります。
継続的インテグレーションの目的は、高品質を維持しながら製品を迅速に反復できるようにすることです。その中心的な対策は、コードがトランクに統合される前に自動テストに合格する必要があるということであり、1 つのテスト ケースが失敗する限り、そのコードは統合できません。
9. 紙コップのテスト方法
機能：紙コップの容量（空のカップ、満杯のカップリットル、ハーフカップのリットル）、水が飲めるかどうか、紙コップの形状（直筒、上面が広くて細い円筒、上面が狭くて広い円筒、その他の形状）、紙コップの素材(全紙、全プラスチック、半紙半プラスチック)、紙コップ耐熱温度(冷水、温水、冷水、氷)、対応液体名(水、コーヒー、ミルク、コーラ)
安全性: カップには毒や細菌が含まれていますか? 液体が化学反応を起こすまでにどのくらい時間がかかりますか (例: 臭い)
信頼性: さまざまな高さから落としたカップの損傷
携帯性: カップがさまざまな場所、温度、その他の環境でも正常に使用できるかどうか
互換性: カップにジュース、水、アルコール、ガソリンなどを入れることができるかどうか。
使いやすさ：カップが手に熱くないか、滑り止めが付いているか、飲みやすいか、液が漏れるまでの時間、お湯の量が多いか。
どのくらい変形しますか? 何度の熱湯で変形しますか?
ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、使用条件などの詳細な説明が記載されていますか?
疲労試験：カップに水を入れて24時間放置し漏れ時間や状態を確認、ガソリンを入れて24時間放置して漏れ時間や漏れ状態などを確認します。
圧力テスト：針を使用し、針に継続的に重りを加えて、どのくらいの圧力が浸透するかを確認し、手で絞ったときに変形するまでにどのくらい時間がかかるかを確認します（単一）
手、両手）
10. 開発者がバグではないと言ったらどう対処しますか?
開発者はこれはバグではないと言いましたが、状況は 2 つあり、1 つは需要が決まっていないため、現時点ではプロダクト マネージャーに調査を依頼することができます。
変更が必要かどうかを確認し、議論の上変更するかどうかを決定してください。第二に、このような状況は起こり得ないので、その必要はありません。
修正したい場合は、まずバグの根拠をできるだけ詳しく教えてください。ユーザーに発見されたり、何らかの異常が発生した場合には、
どのような悪影響が生じるのでしょうか? プログラマはさまざまな理由を説明するかもしれませんが、その説明に反論することもできます。まだそうでない場合は
OK、それではこの問題を提起し、開発マネージャーとテストマネージャーに確認してください。変更したい場合は変更してください。変更したくない場合は、
変更する場合は変更しないでください。最終的にバグが修正されないと判断された場合は、将来の参照のためにテスト レポートに記録する必要があります。
11. 確率的なバグに遭遇した場合はどうすればよいですか?
確率的バグはゴースト バグとも呼ばれます。まず明確にしておきたいのは、このタイプのバグには、動作環境、動作手順、データが明確に記載され、必要なログが提供される船荷証券も必要であるということです。理由。その後、忍耐強く、消去法と間違った推測を使用してパターンを見つけ、必要に応じて、分析して一緒に議論する開発者とプロジェクト マネージャーを見つけます。最終的に解決しない場合は、テスト レポートに反映する必要があります。起こり得る影響を分析し、このバグを放置できるかどうかを全員で比較検討する必要があります。
12. ID 番号入力ボックスのユースケースを設計するにはどうすればよいですか?
ID 番号ルール (住所コード、生年月日コード、シーケンス コード、チェック コードを含む) の有効性を検証します。
15 桁の ID 番号と 18 桁の ID の両方が利用可能であることを確認します。
最後の桁がXの場合の状況を確認してください
15桁未満、16～17桁、18桁以上の状況を確認する
必須入力の場合、認証が入力されていない場合は正しいプロンプトが表示されますか?
必須入力でない場合は、入力しなくても正常に処理が進むか確認する必要があります。
数字以外（大文字、小文字、漢字、特殊文字、句読点を含む）を入力した場合に正しいプロンプト情報が表示されるかどうかを確認します。
全角数字を入力したときにシステムが認識するかどうかを確認します (これは、全角数字を使用できるかどうかを判断するニーズによって異なります)。
13.回帰テストとは何ですか? 回帰テストはどのように行うのでしょうか?
回帰テストとは、ソフトウェアのライフサイクル中、ソフトウェアが変更される限り、ソフトウェアに問題が発生する可能性があることを意味します。
したがって、ソフトウェアを変更するたびに、既存の機能を再テストして、変更が意図した目的を達成したかどうか、および変更によって本来の正常な機能が破壊されていないかどうかを確認する必要があります。
回帰テストは、単体テスト、統合テスト、システム テストなど、どの段階でも実行できます。
では、回帰テストはどのように行うのでしょうか? それは次の点に要約できます
1. テスト戦略策定段階では回帰テスト戦略を策定する
2.回帰テストが必要なバージョンを決定する
3.回帰テストバージョンをリリースし、回帰テスト戦略に従って回帰テストを実行します。
4. 回帰テストに合格し、欠陥追跡チケット (問題チケット) が閉じられます。
5. 回帰テストが失敗した場合、欠陥追跡命令は開発者に返され、開発者は問題を再修正して、再度回帰テストのためにテスターに提出します。
14. 高品質な欠陥追跡チケットを送信する方法
まず第一に、欠陥追跡シートは自分だけのものではないことを明確にする必要があります。そのため、高品質の欠陥シートの最も重要な基準は次のとおりです。
審査基準は、他人が一目で理解できること、タイトルが簡潔明瞭であること、手順が明確で整理されていることです。また、欠陥レベル、機能モジュール、バージョン、再現手順、期待される結果、実際の結果、原因、ログのスクリーンショットなど、欠陥の完全性を考慮する必要もあります。
15. プロジェクトのテスト手順は何ですか?
要件レビュー、テスト計画、技術レビュー、ユースケース作成、ユースケースレビュー、テスト実行、テストレポート、オンライン検証、プロジェクト概要
16. バグの優先度と重大度を分類する方法
Priority (優先度) と Severity (重大度) は、バグを送信するための 2 つの重要な属性です。
通常、バグを送信する場合、テスターはバグの Severity、つまりバグの重大度のみを定義し、優先度の定義はプロジェクト リーダーまたはチーム リーダーに任せ、バグ修正の優先順位を決定します。ある意味、優先度の定義は重大度に依存しており、ほとんどの場合、重大度が深刻であるほど、バグの優先度は高くなります。
重大度は次のとおりです。
ブロッカー: つまり、システムが実行できない、クラッシュする、またはリソースが著しく不足している、アプリケーション モジュールが起動できないか異常終了する、テストできないなど、システムが不安定になります。
重大: システムの機能または動作に影響を及ぼします 主要な機能に重大な欠陥がありますが、システムの安定性には影響しません。
Major (深刻): インターフェイス、パフォーマンスの欠陥、互換性。
軽微/軽微: ユーザビリティとアドバイスの問題。
優先度: 即時、緊急、高、
通常、低速（少し遅い）
17. 優れたテストケース設計の鍵は何だと思いますか?
重要なのは要件を理解することですが、要件は次の側面に分類できます。
1. ビジネスニーズを熟知している
2. 他のシステムとこの要件との関係を理解する
3. 開発設計ドキュメントに精通し、開発実装ロジックを理解する
4. データベース設計文書に精通しており、データ ストレージについて理解している
5. プロジェクトの構造を理解し、隠れた要件を発見する
18. ウェブサイトとテストの実施方法を提供する
1. 要件の説明、Web サイトのデザイン、その他の関連ドキュメントを検索し、テスト要件を分析します。
2. テスト計画を作成し、テスト範囲とテスト戦略を決定します。
3. 機能、互換性、パフォーマンス、セキュリティなどのテストケースを設計します。
4. テスト実行を行う
5. 回帰テストとテストの概要
