もし試験管理者が私の記事を読んでいるなら、彼は面接官に微笑みかけたいと願っているでしょう。そうでないと、面接が終わった後、一万頭の馬が駆け抜けることになるでしょう。実際、面接官はあなたが彼らに何も期待しているのではなく、ある種の敬意を期待しているのです。平等と平等 話すときは傲慢にならず、自分がとてもすごいと感じてください。もちろん、テスト技術を学んでいる人も感謝の気持ちを持ち、すべての面接官に平等に敬意を持って接するべきです。
自動テストの面接質問 200 のよくある質問、あなたは何問正解できますか?
早速ですが、ソフトウェア テストの面接でよく聞かれる質問を次のように整理します。
1. テスト中にバグを発見しましたが、開発マネージャーはバグではないと考えています。どのように解決すればよいですか?
まず、提出するために問題を欠陥管理データベースに送信します。
次に、判断の根拠と基準を取得するには、次のようにします。
- 要求仕様、製品説明、設計図書などに従って、実際の結果が計画と矛盾しているかどうかを確認し、欠陥を確認するための直接の根拠を提供します。
- 文書化された根拠がない場合は、同様のソフトウェアの一般的な特性を使用して矛盾があるかどうかを説明し、それが欠陥であるかどうかを確認できます。
- ユーザーの一般的な使用習慣に基づいて欠陥かどうかを確認します。
- 設計者、開発者、顧客担当者、その他の関係者と話し合い、欠陥であるかどうかを確認します。
- 合理的な議論を行い、判断の理由を試験管理者に説明し、客観的かつ厳格に、個人的な感情を混ぜ込まないでください。
テスト管理者が最終決定を下すのを待ちます。それでも議論がある場合は、会社のポリシーで定められたルートを通じて上司に報告することができ、上司が決定を下します。
2. Web サイトがある場合、どのようにテストしますか?
まず、要件の説明や Web サイトのデザインなどの関連文書を探し、テスト要件を分析します。
テスト計画を作成し、テスト範囲とテスト戦略を決定します。これには通常、機能テスト、インターフェイス テスト、パフォーマンス テスト、データベース テスト、セキュリティ テスト、および互換性テストの部分が含まれます。
テスト ケースを設計します。
機能テストには次の側面が含まれますが、これらに限定されません。
- リンクテスト。リンクが正しくジャンプするかどうか、空白ページや無効なページがあるかどうか、誤ったエラー メッセージが返されるかどうか。
- 機能のテストを送信します。
- マルチメディア要素を正しくロードして表示できるかどうか。
- 多言語サポートにより、選択した言語が正しく表示されるかどうかなど。
インターフェイスのテストには次の側面が含まれますが、これらに限定されません。
- ページのスタイルが統一されていて美しいかどうか。
- ページレイアウトが合理的かどうか、重要なコンテンツや注目のコンテンツが目立つかどうか。
- コントロールが通常に使用されているかどうか。
- インストールする必要があるコントロールについて、自動ダウンロードおよびインストール機能はありますか?
- テキストチェック。
パフォーマンス テストでは通常、次の側面が考慮されます。
応力試験、荷重試験、強度試験
データベーステスト
実行する必要があるかどうかを具体的に判断します。データベースは通常、接続、データ アクセス操作、データ コンテンツの検証などの側面を考慮する必要があります。
セキュリティテスト:
- 基本的なログイン機能のチェック。
- システムのクラッシュやアクセス許可の漏洩を引き起こすオーバーフロー エラーが発生したかどうか。
- SQL インジェクションなど、関連する開発言語の一般的なセキュリティ問題を確認します。
- 高度なセキュリティ テストが必要な場合は、必ず専門のセキュリティ会社の助けを求めるか、テストを外注するか、サポートを受けるようにしてください。
互換性テストでは、要件の説明の内容に基づいて、サポートされるプラットフォームの組み合わせが決定されます。
- ブラウザの互換性。
- オペレーティング システムの互換性。
- ソフトウェアプラットフォームの互換性。
- データベースの互換性。
テストが実行され、欠陥が記録されます。テストの進行を合理的に調整および調整し、テストに必要なリソースを事前に取得し、管理システム (たとえば、要求の変更、リスク、構成、テスト文書、欠陥レポート、人的リソースなど) を確立します。
定期的にテストを見直し、評価、要約し、テストの内容を調整します。
3. 検索エンジンに中国語の文字を入力すると、対応するドメイン名が解決されますが、LoadRunner を使用してテストするにはどうすればよいですか?
テスト計画を確立し、テスト基準とテスト範囲を決定します。
一般的なビジネス プロセスと一般的ではないビジネス プロセスをカバーする、典型的なシナリオのテスト ケースを設計します。
テスト ケースに基づいて自動テスト スクリプトとシナリオを開発します。
テストスクリプトの記録：新しいスクリプト（Web/HTMLプロトコル）を作成し、記録ボタンをクリックし、ポップアップダイアログボックスのURLに「about:blank」と入力し、開いたブラウザで通常の操作プロセスを実行した後、記録を終了します。 ; スクリプトをデバッグして保存します。文字セットの関連付けに注意する必要があるかもしれません。
テスト シナリオの設定 : 主にシステムの平均トランザクション応答時間が通常の状況で標準を満たしているかどうかを判断するために、パフォーマンスのテスト シナリオを設定します。主にシステムが全負荷に達しているか、システムの耐荷重を超えているかどうかを判断するために、圧力負荷のテスト シナリオを設定します。システムがクラッシュするかどうか、テストを実行し、テスト結果を取得し、テスト結果を分析します。
4. 1 つのクライアントに 300 のクライアントが存在する場合と、300 のクライアントにサーバーに負荷がかかる場合の違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのリソースがより多く占有され、テスト結果に影響します。スレッド間の干渉が発生し、一部の例外が発生する可能性があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要です。
IP アドレスの問題の場合は、IP スプーフを使用して、単一 IP アドレスの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーが 1 つのクライアント上に存在するため、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散されている間は、コントローラーを使用してユーザーを異なるクライアントに全体的に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定を指定する必要があります。
5. ソフトウェアの概念と特徴について説明してください。ソフトウェアの再利用とは何を意味しますか? コンポーネントには何が含まれていますか?
ソフトウェアは、ハードウェアと相互依存するコンピュータ システムのもう 1 つの部分であり、コンピュータ システムの動作に関連するコンピュータ プログラム、手順、ルール、およびファイル、文書、データなどです。
ソフトウェアの再利用（SoftWare Reuse）とは、既存のソフトウェアに関するさまざまな関連知識を利用して新しいソフトウェアを作成し、ソフトウェアの開発と保守のコストを削減することです。ソフトウェアの再利用は、ソフトウェアの生産性と品質を向上させるための重要なテクノロジーです。初期のソフトウェアの再利用は主にコード レベルの再利用であり、再利用された知識は特にプログラムを指しました。その後、それはドメイン知識、開発経験、設計上の決定、アーキテクチャ、要件、設計、コード、ドキュメント、およびその他すべての関連する側面を含むように拡張されました。 。
再利用可能なソフトウェアコンポーネントは、一般に再利用可能コンポーネントと呼ばれます。
6. ソフトウェアのライフサイクルとそのモデルは何ですか?
ソフトウェアライフサイクル（ソフトウェアライフサイクル）は、ソフトウェアのライフサイクルや生存期間とも呼ばれます。ソフトウェア開発の概念が形成され、開発されたソフトウェアが使用された後、使用価値を失い消滅するまでの過程を指します。一般にライフサイクル全体は計画（定義）、開発、運用（保守）の3つの期間に分かれており、各期間はいくつかの段階に分かれており、それぞれの段階で明確なタスクが定められています。
ウォーターフォールモデル：これはすべて理解できます。
ラピッドプロトタイピングモデル：ラピッドプロトタイピングモデルでは、要件分析段階でのソフトウェア要件の予備的ではあるが完全ではない分析と定義、および機能と性能のすべてまたは一部をユーザーに示すソフトウェアシステムのプロトタイプの迅速な設計と開発が可能になります。ユーザーはプロトタイプをテストおよび評価し、ソフトウェア要件を強化および改善するための具体的な改善提案を行い、開発者はこれに基づいてソフトウェアを修正および改善し、ソフトウェアの実装、テスト、保守を完了するまで完了します。ユーザーは満足し、承認されます。
反復モデル: 反復には、製品リリース (製品の安定した実行可能バージョン) をもたらすすべての開発アクティビティと、そのリリースを使用するために必要なその他すべての周辺要素が含まれます。ある意味、開発イテレーションは、要件分析、設計、実装、テストのワークフローなど、すべてのワークフローを一度に実行するプロセスです。本質的には、小さなウォーターフォール プロジェクトに似ています。RUP は、すべての段階を反復に細分化できると考えています。各反復では、最終製品のサブセットであるリリース可能な製品が生成されます。
ライフサイクルのフェーズ:
- ソフトウェアの実現可能性の分析と計画
- 需要分析
- ソフトウェア設計
- コーディング
- ソフトウェアテスト
- 運用・保守
7. ソフトウェアテストとは何ですか? ソフトウェアテストの目的と原則
指定された条件下でプログラムを動作させて、プログラムのエラーを発見し、ソフトウェアの品質を測定し、設計要件を満たせるかどうかを評価するプロセス。
ソフトウェアテストの目的:
- テストとは、エラーを見つけることを目的としたプログラムの実行です。
- 成功したテスト ケースは、これまで発見されていないバグを発見することにあります。
- 成功したテストとは、これまで発見されていないバグを発見したものです。
- 製品が約束または発表された機能を確実に実行し、ユーザーがアクセスできる機能には明確な書面による指示があることを確認します。
- 製品がパフォーマンスと効率の要件を満たしていることを確認します。
- 製品が堅牢で、ユーザーの環境に適応できることを確認してください。
ソフトウェアテストの原則:
- テスト ケースの重要な部分は、予想される出力または引き継ぎを定義することです。
- プログラマは自分が書いたプログラムをテストすることを避けるべきです。
- ソフトウェアを作成する組織は、作成したソフトウェアをテストすべきではありません。
- 各テストの実行結果を徹底的にチェックする必要があります。
- テスト ケースの作成は、有効で予期される入力状況だけでなく、無効で予期しない入力状況にも基づいて行う必要があります。
- プログラムが「すべきことをしない」かどうかをチェックするのはテストの半分にすぎず、テストの残りの半分はプログラムが「すべきでないことをする」かどうかをチェックすることです。
- ソフトウェア自体が使い捨てでない限り、使い捨てのテスト ケースは避けるべきです。
- テスト作業は、バグが見つからないという暗黙の前提のもとに計画されるべきではありません。
- プログラムの一部にさらに多くのバグが存在する可能性は、その部分で見つかったバグの数に比例します。
- ソフトウェア テストは、非常に創造的で知的にやりがいのある仕事です。
8. ソフトウェア構成管理の役割は何ですか? ソフトウェア構成には何が含まれますか?
ソフトウェア構成管理( SCM ) は、変更を特定、整理、および制御するための技術です。ソフトウェア構成管理は、ソフトウェア エンジニアリング プロセス全体に適用されます。ソフトウェアを構築する際に変更は避けられず、変更はプロジェクトのソフトウェア開発者間の混乱につながります。SCM 活動の目標は、変更を特定し、変更を管理し、変更が正しく実装されていることを確認し、他の関連担当者に変更を報告することです。ある観点から見ると、SCM は、エラーを最小限に抑え、生産効率を最大化するために、変更を特定、整理、および制御するためのテクノロジーです。
ソフトウェア構成には、構成項目の識別、ワークスペース管理、バージョン管理、変更管理、ステータスレポート、および構成監査が含まれます。
9. ソフトウェアの品質とは何ですか?
一言で言えば、ソフトウェア品質とは「ソフトウェアが明示的および暗黙的に定義された要件にどの程度準拠しているか」です。具体的には、ソフトウェアの品質とは、ソフトウェアが明示的に記載された機能およびパフォーマンス要件、ドキュメントに明示的に記載された開発標準、および専門的に開発されたすべてのソフトウェアが持つべき暗黙の特性にソフトウェアがどの程度準拠しているかを指します。ソフトウェアの品質に影響を与える主な要因。これらの要因は、管理の観点から見たソフトウェアの品質の尺度です。ソフトウェア製品を使用する際のユーザーの 3 つの視点を反映して、3 つのグループに分類できます。正確性、堅牢性、効率性、完全性、使いやすさ、リスク（製品の運用）、理解性、保守性、柔軟性、テスト容易性（製品の変更）、移植性、再利用性、相互運用性（製品の移転）。
10. 現在の主なテストケース設計方法は何ですか?
ホワイト ボックス テスト: ロジック カバレッジ、ループ カバレッジ、基本パス カバレッジ。
ブラックボックステスト：境界値解析法、同値クラス分割、誤差推定法、特性要因図法、状態図法、テスト概要法、ランダムテスト、シナリオ法。
11. ソフトウェアのセキュリティはどのような側面からテストする必要がありますか?
ソフトウェア セキュリティ テストには、プログラムとデータベースのセキュリティ テストが含まれます。テスト戦略は、システムのセキュリティ指標に応じて異なります。
ユーザー認証のセキュリティをテストするときに考慮すべき問題: システム内の異なるユーザー権限を明確に区別するか、システム内でユーザーの競合が発生するかどうか、ユーザー権限の変更によりシステムが混乱を引き起こすかどうか、ユーザーのログイン パスワードが表示されているか、コピー可能かどうか、および絶対的な手段でシステムにログインできるかどうか (ユーザーがログインした後にリンクをコピーしてシステムに直接入る)、ユーザーがシステムを終了した後にすべての認証マークを削除するかどうか、戻るキーを使用してシステムに入ることができるかどうかパスワードを入力せずにシステムを起動し、システムのネットワークセキュリティテストを検討する必要があります。質問、講じられた保護対策が正しくインストールされているかどうか、関連するシステムパッチが適用されているかどうかをテストし、不正な攻撃をシミュレートして保護システムが強力であるかどうかを確認し、使用する必要があります。システム関連の脆弱性をチェックするための成熟したネットワーク脆弱性チェック ツール (つまり、最も専門的なハッカー攻撃ツールを使用します。攻撃を試してください。現在最も一般的に使用されているものは NBSI シリーズと IPhacker IP です)。さまざまなトロイの木馬チェック ツールを使用してトロイの木馬の状況をチェックします。システムの各グループのプラグインの脆弱性をチェックするには、さまざまなプラグイン対策ツールを使用します。
データベースのセキュリティに関する考慮事項: システム データが機密であるかどうか (たとえば、銀行システムの場合、これは特に重要ですが、一般的な Web サイトにはそれほど高い要件はありません)、システム データの完全性 (これは企業の実名検証サービス システムに存在していました)完了しました 不完全なデータは、システムの機能の実現に障害をもたらします）、システム データの管理性、システム データの独立性、システム データのバックアップおよびリカバリ機能（データのバックアップが完了しているかどうか、リストアできるかどうか、およびリストアが可能かどうか）完了）。
12. テスト ケース、テスト スクリプトとは何ですか? 両者の関係は何ですか?
テストを実行するためにテスト対象のシステムに提供される、特定の入力データ、操作、またはさまざまな環境設定と期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの作成は、対応するテスト ケースに対応する必要があります。
13. 静的テスト、動的テスト、ブラック ボックス テスト、ホワイト ボックス テスト、アルファ テスト、ベータ テストとは何かを簡単に説明します。
静的テストは、プログラム コード内で考えられるエラーを探したり、プログラム自体を実行せずにプログラム コードを評価したりするプロセスです。
動的テストとは、テスト対象のプログラムを実際に実行し、対応するテストインスタンスを入力し、実行結果と期待される結果との差異を確認し、実行結果が要件を満たしているかどうかを判断することにより、プログラムの正確性、信頼性、有効性をテストすることです。 、システムの動作効率、堅牢性、その他の特性を分析します。
ブラックボックステストは、一般にソフトウェアの機能の正確性や操作性を確認するために行われ、ソフトウェアの各機能が実現できるかどうかを検出することを目的としており、テスト対象のプログラムは内部構造に関わらずブラックボックスとして扱われます。プログラム 入力と出力の間の関係、またはプログラムの機能の場合、テスト ケースを特定し、テスト結果の正確さを推測するためにソフトウェア仕様が信頼されます。
ホワイト ボックス テストは、ソフトウェアの内部論理構造の分析に基づいています。コードベースのテストです。テスターは、プログラム コードを読み取るか、開発ツールのシングル ステップ デバッグを使用して、ソフトウェアの品質を判断します。一般に、ブラック ボックス テストは、ソフトウェアの内部論理構造の分析に基づいています。ボックステストはプロジェクトマネージャーによって実行され、プログラマーはそれを実装するために開発を行っています。
アルファ テストは、ユーザーが開発環境で実施するテスト、または社内のユーザーが実際の運用環境を模擬して実施する管理されたテストです。
ベータテストは、ソフトウェアの複数のユーザーが、1人または複数のユーザーの実際の使用環境で実施するテストです。通常、開発者はテスト サイトには存在せず、プログラマーやテスターがベータ テストを行うことはできません。
14. ソフトウェア品質保証制度とは何ですか? 品質保証管理に関する国家基準は何ですか? シリアル番号とフルネームは何ですか?
SQA (SQA-ソフトウェア品質保証) は、(ソフトウェア) 品質を保証するための一連のソフトウェア エンジニアリング プロセスと方法で構成されます。SQA はソフトウェア開発プロセス全体を通じて実行されます。それには、要件文書レビュー、コード管理、コードレビュー、変更管理、構成管理、バージョン管理、およびソフトウェアテストが含まれます。
ソフトウェア品質保証とは、提案された標準、手順、実践、および方法がすべてのプロジェクトに正しく採用されていることを管理者が保証するための、計画的かつ体系的なアプローチの確立です。ソフトウェア品質保証の目的は、ソフトウェア プロセスを管理者が見えるようにすることです。ソフトウェア製品と活動のレビューと監査を通じて、ソフトウェアが標準に準拠していることを検証します。ソフトウェア品質保証グループは、プロジェクトの開始時に協力して計画、標準、プロセスを確立します。これらにより、ソフトウェア プロジェクトが組織のポリシーの要件を満たすことが可能になります。
15. ソフトウェア製品の品質特性は何ですか?
- 機能: 適応性、正確性、相互運用性、コンプライアンス、セキュリティ。
- 信頼性: 成熟度、耐障害性、容易な回復。
- ユーザビリティ：理解しやすく、学びやすく、操作しやすい。
- 効率: 時間特性、リソース特性。
- 保守性: 分析が容易、変更が容易、安定性、テストが容易。
- 移植性: 適応性、設置の容易さ、準拠性、および交換の容易さ。
16. ソフトウェアテストの戦略は何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準およびテスト仕様の指針に基づいて、テスト プロジェクトの特定の環境制約に基づいて指定されたソフトウェア テストの原則、方法、および方法の集合。
17. ソフトウェアのテストはいくつかの段階に分かれていますが、各段階のテスト戦略と要件は何ですか?
開発プロセスに対応して、テスト プロセスは、単体テスト、統合テスト、システム テスト、受け入れテストの4 つの主要な段階を経ます。
単体テスト: 単体テストは、ソフトウェア設計の最小単位であるプログラム モジュールやコード セグメントの正確性をチェックするテスト作業であり、通常は開発者によって実行されます。
結合テスト: 結合テストは、テストの設計要件に従ってモジュールを組み立てることであり、主な目的はインターフェイスに関連する問題を見つけることです。製品をテスト部門に提出する前に製品開発チームは共同デバッグを実施する必要があるため、ほとんどの企業では統合テストは開発者によって完了します。
システムテスト: システムテストは、統合テストに合格した後に実行され、システムが完全に動作し、各サブシステムが正常に動作し、設計要件を満たしているかどうかを検証することを目的としています。主にテスト部門で実施され、テスト部門の中で最も大規模かつ最も重要なテストであり、製品の品質に大きな影響を与えます。
受入テスト：受入テストは、需要段階の「要求仕様書」を受入基準とし、実際のユーザーの使用環境を模擬したテストが求められます。実際のプロジェクトの場合はお客様と一緒に実施できますが、製品の場合は最後のシステムテストです。テスト内容は機能モジュールの総合テスト、特にドキュメントテストです。
単体テストのテスト戦略:
- トップダウンの単体テスト戦略: 個別の単体テストよりもはるかにコストがかかるため、単体テストには適していません。
- ボトムアップの単体テスト戦略: より合理的な単体テスト戦略ですが、テスト サイクルが長くなります。
- 分離された単体テスト戦略: 最適な単体テスト戦略。
統合テストのテスト戦略:
- Big Bang Integration: メンテナンス プロジェクトまたはテスト対象のシステムが小規模な場合に適しています。
- トップダウン統合: 比較的明確で安定した製品制御構造に適しています。上位レベルのインターフェースはほとんど変更されません。下位レベルのインターフェースは未定義であるか、頻繁に変更される可能性があります。生産制御コンポーネントは技術的リスクが大きいため、すぐに検証する必要があります。できるだけ早くそうすることを希望します 製品のシステム機能の動作を確認できます。
- ボトムアップ統合: 下位レベルのインターフェイスへの適応は比較的安定しており、上位レベルのインターフェイスはより頻繁に変更され、下位レベルのコンポーネントはより早く完了します。
- 進行状況ベースの統合の利点: 高度な並列性があり、プロジェクトの開発進行を効果的に短縮できます。短所: スタブとドライバーの作業負荷が大きい、一部のインターフェイス テストが不十分、一部のテストが繰り返し行われ無駄が多い。
システムテストのテスト戦略:
データおよびデータベースの整合性テスト、機能テスト、ユーザー インターフェイス テスト、パフォーマンス測定、負荷テスト、強度テスト、容量テスト、セキュリティおよびアクセス制御テスト、フェイルオーバーおよび回復テスト、構成テスト、インストール テスト、暗号化テスト、ユーザビリティ テスト、バージョン検証テスト、ドキュメントのテスト。
18. ソフトウェアテストの各フェーズでは通常どのような作業が行われますか? 各ステージの結果ファイルは何ですか? 何が含まれていますか?
単体テスト段階: 独立した各ユニットモジュールをシステムの他の部分から分離してテストし、各プログラムモジュールの正当性チェックを実行して、各プログラムモジュールが指定された機能を正しく実装しているかどうかを確認します。単体テストレポートを生成し、欠陥レポートを提出します。
統合テスト段階: 統合テストは単体テストに基づいており、ソフトウェアの要件に従ってすべてのソフトウェアユニットをモジュール、サブシステム、またはシステムに組み立てるプロセス中に、各部分の作業が対応する技術指標および標準に到達または実現しているかどうかをテストします。設計仕様の概要、必要な作業。この段階で、統合テストレポートが生成され、欠陥レポートが提出されます。
システムテスト段階：確認テストに合格したソフトウェアは、コンピュータハードウェア、周辺機器、一部のサポートソフトウェア、データ、人員などの他のシステム要素と組み合わせて、コンピュータシステム全体の要素として使用され、実際の動作でテストされます。環境: コンピュータ システムの包括的な機能範囲。この段階では、テストの概要と欠陥レポートの提出が必要です。
19. ソフトウェア開発プロセスにおけるテスターのタスクは何ですか?
1. システム内のバグをできるだけ早く発見します。
2. ソフトウェア開発プロセスにおける欠陥の発生を回避します。
3. ソフトウェアの品質を測定し、システムの品質を保証します。
4. ユーザーのニーズに注意を払い、システムがユーザーのニーズを満たしていることを確認します。
全体的な目標は、ソフトウェアの品質を保証することです。
20. 以前の仕事では、ソフトウェアの欠陥 (またはバグ) レコードには何が含まれていましたか? 高品質のソフトウェア欠陥 (バグ) 記録を提出するにはどうすればよいですか?
バグ レコードには基本的に次の内容が含まれている必要があります。
バグ番号、バグの重大度レベル、優先度、バグが発生したモジュール、まず第一に、バグの一般的な内容を説明するバグの概要、バグに対応するバージョン、バグの詳細な説明（一部を含む）が必要です。スクリーンショット、ビデオなど; バグ 表示されたときのテスト環境、および生成される条件は操作手順に対応しています。
高品質のバグログ:
1) 一般的な UI は統一され、正確である必要があります。欠陥レポートの UI は、テストされたソフトウェアの UI と一致しており、見つけやすくする必要があります。
2) 正確な表現を確保し、プロフェッショナリズムを反映するために、業界で一般的に使用される表現用語と表現方法を使用するように努めてください。
3) 各欠陥レポートには欠陥が 1 つだけ含まれます。各欠陥レポートには欠陥が 1 つだけ含まれるため、欠陥修正者は欠陥を迅速に特定し、一度に 1 つの欠陥のみを修正することに集中できます。検証者は、一度に 1 つの欠陥が正しく修正されたかどうかのみを検証します。
4) 再現不可能な欠陥も報告する必要がある まず、欠陥レポートは欠陥を再現できることを証明する必要があります。再現不可能な欠陥は可能な限り再現する必要があり、あらゆる努力をしても再現できない場合でも、その欠陥を報告する必要がありますが、その報告には、欠陥が再現できないことと、欠陥の発生頻度を示す必要があります。
5) 欠陥の種類を明示し、欠陥の現象から欠陥の種類を要約して判断します。たとえば、機能的欠陥、インターフェース欠陥、データ欠陥、合理化は、これらが最も一般的な種類の欠陥または欠陥であることを示唆しており、他の形式の欠陥または欠陥もこれらのいずれかに属することを示唆しています。
6) 不具合の重大度と優先順位を明確に示し、重大度と優先順位の違いを常に明確にしてください。重大度の高い問題は解決する価値がない可能性があり、軽微な外観上の問題は優先度が高いと考えられる場合があります。
7) 説明は簡潔、正確かつ完全であり、欠陥の本質を明らかにし、欠陥または欠陥が発生する場所を記録します。説明は欠陥の本質を正確に反映し、簡潔かつ明確でなければなりません。ソフトウェア欠陥管理データベース内の指定されたテスト欠陥の検索を容易にするために、欠陥が発生したときのユーザー インターフェイス (UI) を含めることをお勧めします。たとえば、ダイアログ ボックスのタイトル、メニュー、ボタンなどのコントロールの名前を記録します。
8) 短い行の間に自動数値シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用します。短い行の間に自動数値シリアル番号を使用し、同じフォント、フォント サイズ、行間隔を使用して、各行の形式が確実に一致するようにします。記録は一貫性があり、標準化されています。
9) 簡潔かつ整理され、繰り返しやすくするために、各ステップの操作を 1 つだけ記録するようにしてください。
10) 欠陥を迅速かつ正確に繰り返すために、ステップが完全、正確、短いことを確認します。「完全」はギャップがないことを意味し、「正確」はステップが正しいことを意味し、「短い」は冗長なステップがないことを意味します。
11) 欠陥に応じて、画像キャプチャを実行するかどうかを選択できます。欠陥または欠陥現象を視覚的に観察するには、通常、欠陥または欠陥が現れる界面を添付して「添付ファイル」に添付する必要があります。 」 記録の一部を画像の形式で添付します。スペースを節約し、欠陥または欠陥の本質を正確に反映するために、欠陥または欠陥が発生したときに全画面、アクティブウィンドウ、およびローカルエリアをキャプチャできます。欠陥や欠陥位置を迅速に特定して修正するには、通常、中国の管理マップを添付する必要があります。必要な特別な文書と個人的なアドバイスやコメントを添付してください 特定の文書を開いたときに欠陥または欠陥が発生した場合、欠陥または欠陥を迅速に再現できるように、この文書を添付する必要があります。場合によっては、欠陥または欠陥修正者に欠陥または欠陥のパフォーマンスをさらに明確にするために、個人的な修正提案やコメントを添付することができます。12) スペルと文法上の欠陥を確認する 各欠陥を送信する前に、スペルと文法をチェックして内容が正しいことを確認し、欠陥を正確に説明してください。13) 複雑な文型を避け、できるだけフレーズや短い文章を使用する ソフトウェア欠陥管理データベースの目的は、欠陥の特定を容易にすることであるため、語彙や複雑さを修正することなく、操作手順を客観的に記述する必要があります。文型、可読性を高めるためのセックス。上記は、テストの欠陥を報告するための標準的な要件を要約したものですが、さまざまなソフトウェア テスト要件があり、テスターは長期間のテストの後、徐々に専門的な良い習慣を身につけ、対応するテスト経験を蓄積し、常に新しい仕様作成要件を追加します。さらに、他のテストエンジニアのテスト欠陥レポートを読んで研究したり、自分の過去のテスト欠陥レポートと比較して考えることで、常にスキルを向上させることができます。14) 欠陥の説明の内容 欠陥の説明の内容には、欠陥の操作手順、実際の結果、および期待される結果が含まれます。この操作手順により、開発者は欠陥を再現して修正することが容易になります。開発者の中には、欠陥を再現する能力が低い人もいます。指摘されている欠陥は理解していますが、再現することができません。特に、システムに慣れていない新規開発者にとっては、導入手順により、再出現が容易になります。実際の結果により、開発者はエラーが何であるかを理解することができ、期待される結果により、開発者は正しい結果がどうあるべきかを理解することができます。
21. ソフトウェアテストの基本的な手法としてブラックボックステストとホワイトボックステストがありますが、それぞれのメリットとデメリットを教えてください。
ブラック ボックス テストの利点は、比較的単純で、プログラムの内部コードや実装に関する知識を必要としないこと、ソフトウェアの内部実装とは何の関係もないこと、ユーザーの観点からは、それを知るのが簡単であることです。ユーザーがどの機能を使用するか、どのような問題が発生するか、ソフトウェア開発ドキュメントに基づいて、ドキュメント内のどの機能がソフトウェアによって実装されているかを知ることができ、自動ソフトウェアテストを行うときに便利です。
ブラック ボックス テストの欠点は、すべてのコードをカバーすることは不可能であること、カバー率が低く、コード量全体の 30% に達することがある、自動テストの再利用性が低いことです。
ホワイト ボックス テストの利点は、ソフトウェア テスターがコード カバレッジを増やし、コードの品質を向上させ、コード内の隠れた問題を発見できるようにすることです。
ホワイトボックス テストの欠点は、プログラムの動作にはさまざまなパスがあり、すべての実行パスをテストすることは不可能であることです。テストはコードに基づいており、開発者が正しく実行しているかどうかのみテストできますが、テストが正しいかどうかはわかりません。設計が正しいかどうか、リークする可能性がある 一部の機能要件を削除する; システムが大規模な場合、テストのオーバーヘッドが非常に大きくなります。
22. 紙コップをテストするにはどうすればよいですか?
- 機能: 水カップを使用して、漏れがないか、水が飲めるかどうかを確認します。
- 安全性：カップ内には毒や細菌はありません。
- 信頼性: さまざまな高さから落としたカップの損傷の程度。
- 携帯性: カップがさまざまな場所、温度、その他の環境でも正常に使用できるかどうか。
- 互換性: カップにジュース、水、アルコール、ガソリンなどを入れることができるかどうか。
- 使いやすさ：カップを触ると熱くないか、滑り止めは付いているか、飲みやすいか。
- ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、使用条件などの詳細な説明が記載されていますか?
- 疲労試験：カップに水を満タンにして（ケース1）24時間放置し漏れ時間や状況を確認、ガソリンを満タンにして（ケース2）24時間放置して漏れ時間や漏れ状況などを確認します。
- 圧力テスト: 針を使用し、針に重りを加え続けて、どの程度の圧力が浸透するかを確認します。
23. テスト計画作業の目的は何ですか? テスト計画書には何を含めるべきですか? これらのうちどれが最も重要ですか?
ソフトウェア テスト計画は、テスト プロセスをガイドするプログラム的な文書です。リーダーはマクロ制御を実施し、テスト計画に従ってリソースを割り当てることができます。テスト担当者は、プロジェクトのテスト全体の状況とプロジェクト テストのさまざまな段階で実行される作業を理解できます。他の担当者の利便性を高める テスターの作業内容を理解し、関連する連携作業を実行します。
製品概要、テスト戦略、テスト方法、テスト領域、テスト構成、テストサイクル、テストリソース、テストコミュニケーション、リスク分析などが含まれます。ソフトウェア テスト計画の助けを借りて、テストに関わるプロジェクト メンバー、特にテスト マネージャーは、テスト タスクとテスト方法を明確にし、テスト実装プロセス中に円滑なコミュニケーションを維持し、テストの進行状況を追跡および管理し、テスト プロセス中のさまざまな変更に対応できます。 。
テスト計画作成の 6 つの要素 (5W1H):
- Why - これらのテストが実行される理由。
- 何を - さまざまな段階でどのような側面がテストされ、作業内容がテストされるのか。
- いつ - テストのさまざまな段階の開始時刻と終了時刻。
- どこ - 対応する文書、欠陥の保管場所、テスト環境など。
- 誰 - プロジェクトの関連要員の構成、どのテスターがテストのために手配されるか。
- どのようにするか、どのように行うか、テストにどのテスト ツールとテスト方法を使用するか。
テスト計画、詳細なテスト仕様、およびテスト ケースの間には戦略的および戦術的な関係があります。テスト計画は主にマクロの観点からテスト活動の範囲、方法、およびリソースの割り当てを計画しますが、詳細なテスト仕様とテスト ケースは特定の戦術です。テストタスクを完了する。したがって、最も重要なことは、テスト戦略とテスト方法をテストすることです (できれば最初に確認できる)。
24. ブラックボックステストにおけるテストケースの一般的な設計方法は何ですか? テスト ケース設計作業におけるこれらのメソッドの適用を説明するには、具体的な例を使用してください。
1)同値クラス分割: 同値クラスは入力領域の部分集合を指します。このサブセット内では、各入力データはプログラムのバグを明らかにする点で同等です。そして、等価クラスの代表値をテストすることは、このクラスの他の値をテストすることと同等であると仮定するのが合理的です。したがって、すべての入力データをいくつかの同値クラスに合理的に分割でき、各同値クラスの 1 つのデータがテストの入力条件として取得されるため、少量の代表的なテスト データを使用してより良いテスト結果を得ることができます。同値クラスの分割には、有効な同値クラスと無効な同値クラスという 2 つの異なる状況が考えられます。
2)境界値解析法：同値クラス分割法を補足するものです。テストの作業経験から、入力および出力範囲内ではなく、入力または出力範囲の境界で大量のエラーが発生することが分かりました。したがって、さまざまなエッジ ケースに合わせてテスト ケースを設計すると、より多くのエラーを検出できるようになります。境界値分析手法を使用してテスト ケースを設計する場合は、まず境界条件を決定する必要があります。通常は、入力と出力の同値クラスの境界が、テストに重点を置く必要がある境界条件です。テスト データとしては、典型的な値や同値クラス内の任意の値ではなく、境界と正確に等しい、境界より大きい、または境界より小さい値をテスト データとして選択する必要があります。
3)エラー推測法: 経験と直感に基づいてプログラム内のあらゆるエラーを推測し、的を絞った方法でテストケースを設計する方法。
エラー推測手法の基本的な考え方は、プログラム内で考えられるすべてのエラーと、エラーが発生しやすい特殊な状況をリストし、それらに基づいてテスト ケースを選択することです。たとえば、モジュール内の多くの一般的なエラーは単体テスト中にリストされ、以前の製品テストで発見されたエラーなどがリストされています。これらは経験の要約です。また、入力データと出力データが 0 の場合、入力フォームが空白の場合、または入力フォームが 1 行しかない場合も、エラーが発生しやすい状況です。これらの状況の例は、テスト ケースとして選択できます。
4)特性要因図法：先ほど紹介した同値クラス分割法や境界値分析法では、入力条件を考慮することに重点が置かれており、入力条件間の関連性や相互の組み合わせなどは考慮されていません。入力条件の組み合わせを考慮すると、新たな状況が生じる可能性があります。しかし、入力条件の組み合わせを確認することは容易ではなく、すべての入力条件を同値クラスに分けたとしても、それらの間の組み合わせは非常に多く存在します。そのため、複数の条件の組み合わせを記述し、それに応じて複数のアクションを生成するのに適した形式でテストケースを設計することを検討する必要があります。これには因果関係図 (ロジック モデル) の使用が必要です。因果関係図法の最終結果は決定表です。プログラムの入力条件のさまざまな組み合わせを確認するのに適しています。
5)直交表分析手法: 多数のパラメータの組み合わせによりテストケースの数が増加する可能性があるが、テストケース間に明らかな優先順位の差がなく、テスターはそれほど大きなテストを完了することはできません。テストの数。直交表を使用して一部のユース ケースを削減し、できる限り少ないユース ケースで可能な限り広い範囲をカバーできるようにすることができます。
6)シナリオ分析手法: ユーザー シナリオに基づいてユーザーの操作手順をシミュレートすることを指し、特性要因図に似ていますが、実行の深さと実現可能性がより優れている場合があります。
7)ステートチャート法: 入力条件とシステム要件の記述からテスト対象システムのすべての状態を取得し、入力条件と状態から出力条件を取得し、入力条件、出力条件、状態からテスト対象システムのテスト ケースを取得します。
8)アウトライン方式： アウトライン方式は、要件に着目した方式であり、さまざまなテスト条件を列挙するために、要件をアウトライン形式に変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内の葉の数、またはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。
25. テスト活動の完全なプロセスを詳細に説明します。(参考までに、この回答は主にウォーターフォールモデルに基づいています)
プロジェクトマネージャーは顧客とのコミュニケーションを通じて要件文書を完成させ、開発者とテスターは共同で要件定義書のレビューを完了します。実装される。プロジェクトマネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。その後、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要件文書に基づいて要件分析文書を完成させ、テスターは両者の認識漏れや認識の相違がないかをレビューするのが主な内容です。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析書に従ってテストケースの作成を開始し、開発者は概要設計書と詳細設計書を完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テストケースが完了したら、テストと開発をレビューする必要があります。
テスターは環境を構築します。
開発者は最初のバージョンを提出しますが、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
開発者は、バグ修正と追加機能を含む 2 番目のバージョンをテスターがテストできるように提出します。
上記の作業を繰り返します。通常は 3 ～ 4 つのテスト バージョンの後、BUG の数が減り、出荷の要件が満たされます。
顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
26. BUG管理ツールの追跡プロセス（例としてBugZillaを使用）
テスターは BUG を見つけて Bugzilla に送信します。ステータスは新規です。BUG の受信者は開発インターフェイス担当者です。
開発インターフェースは該当モジュールの開発者にバグを割り当て、ステータスが割り当て済みに変更されます。開発者とテストはバグを確認します。自分のバグの場合は受信するように設定され、別のバグの場合は受信するように設定されます。開発者の問題がある場合、転送されます。この動作を実行するかどうかは次の開発者次第です。問題がない場合は、議論して確認し、このバグを拒否する必要があります。その後、テスターがこの問題をクローズします。
開発者がバグを受け入れて修正した場合、開発者はバグのステータスを修正済みに変更し、どのバージョンでテストできるかを開発者に通知します。
テスターは新しいバージョンでテストを行い、問題がまだ存在することが判明した場合は検証を拒否し、問題が修正された場合はバグを閉じます。
27. テスターと開発者間のコミュニケーションのプロセスにおいて、コミュニケーションの効率と効果を向上させるにはどうすればよいと思いますか? テスターと開発チームの他のメンバーの間で良好な人間関係を維持するための鍵は何ですか?
できる限り対面でのコミュニケーションを心がけ、次に電話で直接コミュニケーションができるようにすること、メールなどタイムリーでないコミュニケーションツールでしかコミュニケーションが取れない場合は、その特性を深く理解する必要があることを強調するそしてそれらを明確に表現できるようになります。
TestDirector などのテスト管理ツールを使用して管理することもより効果的ですが、TestDirector のバグの正確な記述にも注意する必要があります。
チーム内のテスターと開発者の間で良好なコミュニケーションを確立するときは、次の点に注意してください。
1つ目は誠実さ、2つ目はチームスピリット、3つ目は職業上の共通言語を持つこと、4つ目は人ではなく物を扱い、仕事を最優先することです。
もちろん、バグ追跡システムに入力する代わりに、小さな問題を直接指摘することで、相手の好感度を高めることもできます。
28. テストに関して最も興味のあることは何ですか? なぜ？
この面接の質問に対する明確で統一された答えはありませんが、多くの企業で尋ねられる可能性があります。検討のために次の回答が提供されます。
- 最大の関心は、これがやりがいのある仕事であるということです。
- テストは経験ベースの産業であり、長く働けば働くほど、テストで良い仕事をすることの難しさと楽しさを感じることができます。
- 自分の仕事を通じて、ソフトウェア製品をどんどん完成度を高めて楽しむことができます。
これらの質問に答えるときは、次の点に注意してください。
採用企業の技術的なルートにできるだけ近い関心を表明してください。たとえば、その企業がデータベース アプリケーション会社の場合は、データベースのテストに興味があり、テストを通じてデータベースの習熟度を向上させたいと考えていることを表明してください。
テストの目的は、自分の能力を向上させ、より良いテストを行うことであることを示してください。雇用主がそのような取り決めをしていない限り、能力の向上は、将来開発や他の分野への転職を目的としたものではありません。
求人企業の範囲を超えて興味を表明しすぎないでください。たとえば、人材紹介会社は金融関連のソフトウェアを扱っているが、あなたはゲーム ソフトウェアに興味がある、または人材紹介会社は JAVA 開発に取り組んでいるが、あなたは C 言語プログラムの開発に興味がある、などです。
29. テストの利点は何だと思いますか?
この面接に決まった答えはありませんが、以下の点を参考に、自分の特徴と組み合わせるとよいでしょう。
回復力があり、忍耐強く、組織的で、困難に直面するのが好きで、何事もうまくやる自信があり、コミュニケーション能力が高く、前任のマネージャーから良い評価を受けており、良い仕事をしていることがわかります。
30. これまでの仕事で行ったことと、よく知っていることを簡単に説明してください。
これまでの私の主な仕事はシステムテストと自動テストでした。システム テストでは、BOSS システムのビジネス ロジック機能とソフトスイッチング システムのクラス 5 機能が主にテストされました。パフォーマンス テストでは、主に、さまざまなリクエスト数の下でシステムの応答時間とシステム リソースの消費量を取得するストレス テストが行われます。自動テストでは、独自のスクリプトを作成し、いくつかのサードパーティ ツールを組み合わせて、主にソフトスイッチ機能のテストをテストします。
テストでは、ユーザーのニーズを正確に理解することが非常に重要だと感じています。さらに、BUG の管理はニーズに基づいて行う必要があり、すべての BUG を変更する必要はありません。
新しいバージョンでは、最初に発見されたバグのほとんどは修正されていますが、元の正しい機能も正しくなくなる可能性があるため、テストには忍耐と細心の注意が必要です。したがって、反復テストと回帰テストに注意してください。