1. ソフトウェアテストの 8 つの原則
- すべてのテスト基準はユーザーのニーズに基づいています
- 常に「品質第一」の意識を持ち、時間と品質が矛盾する場合には、時間は品質に従わなければなりません。
- 要件段階では、製品の品質基準を明確に定義する必要があります。
- ソフトウェア テストは、プログラムの作成を待ってからテストを開始するのではなく、ソフトウェア プロジェクトが開始されるとすぐに開始されます。
- 第三者によるテストはより客観的かつ効果的になります
- ソフトウェア テスト計画は、優れたソフトウェア テスト作業の前提条件です
- テストケースは記述されるものではなく設計される
- エラーが多いプログラムセクションはより深くテストする必要があります
2. テスト中にバグを発見しましたが、開発マネージャーはバグではないと考えています。どのように解決すればよいですか?
1. 問題を提出するために欠陥管理データベースに送信します。
2. 判断根拠と基準を得るには：
要求仕様書、製品説明書、設計書などをもとに、実際の結果が適切かどうかを確認します。計画と矛盾している、欠陥が確認されているかどうかの直接的な根拠を提供する；文書化された根拠がない場合、類似ソフトウェアの一般的な特性に基づいて矛盾があるかどうかを説明することで欠陥であるかどうかを確認できる；欠陥があるかどうかを確認するユーザーの一般的な使用習慣に基づく欠陥。 4. 合理的な議論を行い、自分の判断を試験監督に説明してください。理由は客観的かつ厳密なものである必要があり、個人的な感情が混じってはいけません。テスト管理者が最終決定を下すのを待ちますが、それでも議論がある場合は、会社のポリシーで定められたルートを通じて上司に報告することができ、上司が決定を下します。
3. 設計者、開発者、顧客担当者、その他の関連担当者と話し合い、それが欠陥であるかどうかを確認します。
3. Web サイトを与えられた場合、どのようにテストしますか?
1. 要件の説明、Web サイトのデザイン、その他の関連ドキュメントを検索し、テスト要件を分析します。
2. テスト計画を作成し、テスト範囲とテスト戦略を決定します。これには通常、次の部分が含まれます:
機能テスト、インターフェイス テスト、パフォーマンス テスト、データベーステスト、セキュリティ テスト、互換性テスト
3. テスト ケースの設計:
機能テストには次の側面が含まれますが、これらに限定されません。
**リンクテスト。 **リンクが正しくジャンプするかどうか、空のページや無効なページがないか、誤ったエラー メッセージが返されるかどうかなど。 機能のテストを送信します。
マルチメディア要素を正しく読み込んで表示できます。多言語サポートにより、選択した言語が正しく表示されるかどうかなど。
インターフェイスのテストには次の側面が含まれますが、これらに限定されません。
- ページのスタイルは一貫していて美しいですか?
- ページレイアウトは合理的か、キーコンテンツやホットコンテンツは目立つか
- コントロールが正常に使用されているかどうか
- インストールに必要なスペースについては、自動ダウンロードおよびインストール機能はありますか?
- テキストチェック
パフォーマンス テストは、通常、
ストレス テスト、 負荷テスト、 の 3 つの側面から検討されます。 /span> a>セキュリティ テスト: データベース テストは、実行する必要があるかどうかを具体的に判断する必要があります。データベースは通常、接続、データ アクセス操作、データ コンテンツの検証などの側面を考慮する必要があります。 強度テスト
- 基本的なログイン機能のチェック
- システムクラッシュや権限漏洩を引き起こすオーバーフローエラーはありますか?
- SQL インジェクションなど、開発言語に関連する一般的なセキュリティ問題を確認します。
- 高度なセキュリティ テストが必要な場合は、必ず専門のセキュリティ会社から支援を受けるか、テストをアウトソーシングするか、互換性テストのサポートを取得してください。要件の説明の内容に基づいて、サポートされるプラットフォームの組み合わせを決定します。
互換性には、ブラウザの互換性、オペレーティング システムの互換性、ソフトウェア プラットフォームの互換性、データベースの互換性が含まれます。
4. テストを実施し、欠陥を記録します。テストの進行を合理的に調整および調整し、テストに必要なリソースを事前に取得し、管理システム (たとえば、要求の変更、リスク、構成、テスト文書、欠陥レポート、人的リソースなど) を確立します。定期的にテストを見直し、評価、要約し、テストの内容を調整します。
検索エンジンに漢字を入力すると、対応するドメイン名が解析されます。r LoadRunner を使用してテストする方法を教えてください。
テスト計画を確立し、テスト基準とテスト範囲を決定する
一般的なビジネス プロセスや珍しいビジネス プロセスなどをカバーする、典型的なシナリオのテスト ケースを設計します。
テスト ケースに基づいて自動テスト スクリプトとシナリオを開発します。
テスト スクリプトを記録する
新しいスクリプトを作成します (Web/HTML プロトコル)
記録ボタンをクリックし、テスト スクリプトの URL に「about」と入力します。ポップアップ ダイアログ ボックス:空白」。
開いたブラウザで通常の操作プロセスを実行した後、記録を終了します。
スクリプトをデバッグして保存します。文字セットの依存関係が指摘される場合があります。
テスト シナリオを設定します
主にシステムの平均トランザクション応答時間が通常の状況で標準を満たしているかどうかを判断するために、パフォーマンスのテスト シナリオを設定します < a i=7 > 圧力負荷のテスト シナリオを設定します。主に、システムが長時間にわたって全負荷にさらされた場合、またはシステムの耐荷重を超えた場合にシステムが崩壊するかどうかを判断します。
テストの実行、テスト結果の取得、テスト結果の分析
4. 1 つのクライアントに 300 のクライアントが存在する場合と、300 のクライアントにサーバーに負荷がかかる場合の違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのより多くのリソースが占有され、テスト結果に影響します。
スレッド間の干渉が発生し、一部の例外が発生する場合があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要になります。
IP アドレスの問題については、IP スプーフを使用して、単一 IP アドレスの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーが 1 つのクライアントに存在する場合、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散している間は、コントローラーを使用してユーザーを異なるクライアントに全体的に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定を指定する必要があります。
5. ソフトウェアの概念と特徴について説明してください。ソフトウェアの再利用とは何を意味しますか?コンポーネントには何が含まれていますか?
ソフトウェアは、ハードウェアと相互依存するコンピュータ システムの別の部分であり、プログラムとドキュメントの完全な集合体です。
ソフトウェアの再利用とは、既存のソフトウェアに関するさまざまな関連知識を利用して新しいソフトウェアを作成し、ソフトウェアの開発とメンテナンスのコストを削減することです。ソフトウェアの再利用は、ソフトウェアの生産性と品質を向上させるための重要なテクノロジーです。初期のソフトウェアの再利用は主にコード レベルの再利用であり、再利用された知識は特にプログラムを指しました。その後、それはドメイン知識、開発経験、設計上の決定、アーキテクチャ、要件、設計、コード、ドキュメント、およびその他すべての関連する側面を含むように拡張されました。 。
再利用可能なソフトウェアコンポーネントを一般に再利用コンポーネントと呼びます。
6、Q: ソフトウェアのライフサイクルとそのモデルは何ですか?
ソフトウェア ライフ サイクルは、すべてのソフトウェア開発プロセス、アクティビティ、タスクの構造的なフレームワークであり、実現可能性調査から要件分析、ソフトウェア設計、コーディング、テスト、ソフトウェア リリース、メンテナンスに至るプロセスです。
要件、分析、設計、実装、展開を経た後、ソフトウェアは使用され、メンテナンス段階に入りますが、メンテナンス コストの不足により徐々に使用できなくなります。このようなプロセスを「ライフサイクルモデル」と呼びます。
7.ソフトウェア テストとは何ですか?ソフトウェア テストの目的と原則
手動または自動の手段を使用してシステムを操作またはテストするプロセス。その目的は、指定された要件を満たしているかどうかをテストすること、または期待される結果と実際の結果の違いを明確にすることです。 ソフトウェア テストの目的: テストはプログラムの実行プロセスであり、目的はエラーを見つけることです。 成功テスト ケースは、これまでに発見されていないバグを見つけることです。 成功したテストとは、これまでに発見されていないバグを見つけることです。 製品が約束または発表したとおりに動作することを確認します。ユーザーがアクセスできる機能についての説明が明確に書かれています。 製品がパフォーマンスと効率の要件を満たしていることを確認する 製品が堅牢でユーザー環境に適応できることを確認する 原則ソフトウェア テスト: 教科書の内容: ソフトウェア テストは、できるだけ早く、ソフトウェア ライフ サイクル全体を通じて実行する必要があります。 ソフトウェア テストは要件を追跡する必要があります テストはサードパーティによって構築される必要があります 徹底的なテストは不可能であり、Good-enough 原則に従う必要があります< a i=15> 期待値を決定する必要がある 出力 (または結果) 各テスト結果を徹底的にチェックする必要がある テストにおけるクラスタリング現象に十分な注意を払う a> バグ修正に重点を置く 同じテストを繰り返し使用すると、ソフトウェアの耐性が高まります。 テストは「小規模」から開始し、徐々に「大規模」に移行する必要があります。 「 プログラムが実行すべきでないことを実行していないか確認する 合法的かつ合理的な入力に注意を払うだけでなく、不正な予期しない入力に注意する テスト計画を厳密に実施し、テストの恣意性を排除する 欠陥 28 の定理
8.ソフトウェア構成管理の役割は何ですか?ソフトウェア構成には何が含まれますか?
ソフトウェア構成管理は、ソフトウェア開発プロセスに必要なリンクであり、ソフトウェア開発管理の基礎として、ソフトウェアのライフサイクル全体を通じて実行されます。また、ソフトウェア開発プロセスのマクロ管理において重要なサポートの役割も果たします。つまりプロジェクト管理です。ソフトウェア開発組織によるソフトウェア構成管理の真に効果的な実装により、ソフトウェア開発プロセスがより予測可能になり、システムが再現可能になり、ソフトウェア組織の競争力が大幅に向上します。
ソフトウェア構成には次のものが含まれます:
構成アイテムの識別
ワークスペース管理
バージョン管理 < /span> 構成監査 ステータス レポート
変更管理
9.ソフトウェアの品質とは何ですか?
ソフトウェア品質: ソフトウェア製品の機能がユーザーの機能要件とパフォーマンス要件を満たす能力。
10.現在の主なテスト ケース設計方法は何ですか?
ホワイト ボックス テスト:
ロジック カバレッジ
ループ カバレッジ
基本パス カバレッジ
ブラック ボックス テスト:
境界値分析法
同値クラス分割
エラー推測法 ランダム テスト シナリオ法 テスト アウトライン法 状態図法
特性要因図法
11.ソフトウェアのセキュリティはどのような側面でテストする必要がありますか?
ソフトウェア セキュリティ テストには、プログラムとデータベースのセキュリティ テストが含まれます。テスト戦略は、システムのセキュリティ指標に応じて異なります。
ユーザー認証のセキュリティをテストするときに考慮すべき問題:
システム内のさまざまなユーザー権限を明確に区別する
システム内にユーザーが存在するかどうかシステムに問題がありますか? 競合
ユーザー権限の変更によりシステムが混乱しますか?
ユーザーのログイン パスワードは表示され、コピー可能ですか?
はい 絶対的な手段でシステムにログインできます (ユーザーがログイン後にリンクをコピーしてシステムに直接アクセスします)
ユーザーがシステムを終了した後にすべての認証マークを削除するかどうか。ユーザーがパスワードを入力せずに戻るキーを使用してシステムにアクセスできるかどうか
システムのネットワーク セキュリティをテストするときに考慮すべき問題
講じられた保護対策が正しく行われているかどうかをテストする
不正な攻撃をシミュレートして、保護システムが強力かどうかを確認します。
成熟したネットワーク脆弱性チェック ツールを使用して、システム関連の脆弱性をチェックします (つまり、最も専門的なハッカー攻撃ツールを使用して攻撃を試みます。
現在最も一般的に使用されているのは、NBSI シリーズと IPhacker IP です)
さまざまなトロイの木馬チェックを使用します。システムのトロイの木馬の状況をチェックするツール
さまざまなプラグイン対策ツールを使用してシステムをチェックする 各プログラム グループのプラグインの脆弱性
データベース セキュリティ考慮事項:
システム データが機密であるかどうか (たとえば、これは銀行システムでは特に重要ですが、一般的な Web サイトではそれほど高い要件はありません)
システム データの整合性 (完成したばかりのエンタープライズ実名認証サービス システムに不完全なデータがあり、このシステムの機能実現に支障をきたしていました。
) a> システム データの独立性
システム データの管理性
システムデータのバックアップおよびリカバリ機能 (データのバックアップが完了したかどうか、復元できるかどうか、および復元を完了できるかどうか)
12.テスト ケースとは何ですか? テスト スクリプトとは何ですか? 2 つの関係は何ですか?
テストを実施する目的でテスト対象のシステムに提供される、特定の入力データ、操作、またはさまざまな環境設定と期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの記述は、対応するテスト ケースに対応する必要があります。
静的テスト、動的テスト、ブラック ボックス テスト、ホワイト ボックス テスト、α テストとは何かを簡単に説明します。 β テスト
静的テストは、プログラム コード内で考えられるエラーを探したり、プログラム自体を実行せずにプログラム コードを評価したりするプロセスです。
動的テストでは、テスト対象のプログラムを実際に実行し、対応するテスト インスタンスを入力し、実行結果と期待される結果の違いを確認し、
実行結果が要件を満たしているかどうか。プログラムの正確性、信頼性、有効性をテストし、システムの動作効率
と堅牢性を分析します。
ブラック ボックス テストは、一般にソフトウェア機能の正確性と操作性を確認するために使用されます。その目的は、ソフトウェアの各機能が実装可能かどうかを検出することです。
テスト対象のプログラムは内部構造を考慮せずブラックボックスとして扱われ、プログラムの入出力関係やプログラムの機能がわかった上で、ソフトウェアの仕様に基づいてテストの正しさを判断します。 ユースケースと推定されたテスト結果。 ホワイト ボックス テストは、ソフトウェアの内部論理構造の分析に基づいています。コードベースのテストです。テスターは、 プログラム コードを読み取るか、開発ツール。シングル ステップ デバッグは、ソフトウェアの品質を判断するために使用されます。一般に、ブラック ボックス テストは、プログラマの開発中にプロジェクト マネージャによって実装されます。 アルファ テストは、開発環境でユーザーが実施するテストですが、社内のユーザーが実際の運用環境を模擬して実施する管理されたテストの場合もあります。 テスト、アルファテストはプログラマーやテスターが行うことはできません。 ベータ テストは、ソフトウェアの複数のユーザーが 1 人以上のユーザーの実際の使用環境で実施するテストです。通常、開発者はテスト サイトには存在せず、プログラマーやテスターがベータ テストを行うことはできません。 ソフトウェア品質保証システムとは何ですか? 品質保証管理に関連する国家基準は何ですか? ? その番号 と正式名称は何ですか? ? 試してみてください。 (それには) 要件文書のレビュー、コード管理、コード レビュー、変更管理、構成管理、バージョン管理、およびソフトウェア テストが含まれる必要があります SQA は、（ソフトウェアの）品質を保証するための一連のソフトウェア エンジニアリング プロセスと手法で構成されます。 SQA はソフトウェア開発プロセス全体を通じて実行されます。
13.ソフトウェア製品の品質特性は何ですか? ?
機能: 適応性、正確性、相互運用性、コンプライアンス、セキュリティ。
信頼性: 成熟度、フォールト トレランス、リカバリ。
使いやすさ: 理解しやすく、習得しやすく、操作も簡単です。
効率: 時間特性、リソース特性。
保守性: 分析が簡単、変更が簡単、安定性があり、テストが簡単です。
移植性: 適応性、取り付けの容易さ、準拠性、交換の容易さ。
14.ソフトウェア テストの戦略は何ですか?
ソフトウェア テスト戦略: 特定のソフトウェア テスト標準とテスト仕様の指針に基づき、テスト プロジェクトの特定の環境制約に基づいて
、ソフトウェアテストは指定された収集を行います。
15.ソフトウェア テストはいくつかの段階に分かれています。各段階のテスト戦略と要件は何ですか? ?
ソフトウェア テストは、単体テスト、統合テスト、システム テスト、<受け入れテスト> (必ずしも必要ではありません) といういくつかの段階に分けることができます
段階< a i=2 > 単体テストのテスト戦略: トップダウンの単体テスト戦略 概要: コストは、単体テストではなく分離された単体テストよりもはるかに高くなります。 良い選択です。 ボトムアップの単体テスト戦略 概要: より合理的な単体テスト戦略ですが、テスト サイクルが長くなります。 分離された単体テスト戦略 概要: 最適な単体テスト戦略。 統合テストのテスト戦略: ビッグバン統合 メンテナンス プロジェクトまたはテスト対象のシステムが小規模な場合に適しています。 a> a> システム テストのテスト戦略 短所: スタブとドライバの作業負荷が大きい、一部のインターフェイス テストが不十分、一部のテストが繰り返し行われ無駄が多い。 利点: 高度な並列性があり、プロジェクトの開発スケジュールを効果的に短縮できます。 進捗ベースの統合 基礎となるインターフェイスは比較的安定しており、上位レベルのインターフェイスは頻繁に変更され、基礎となるコンポーネントはより早く完成するという事実に適応します。 ボトムアップ統合 行動します。 修正; 運用ポート制御コンポーネントには大きな技術的リスクがあり、できるだけ早く検証する必要があります; 製品のシステム機能を確認したいと考えていますできるだけ早く 比較的明確で安定した製品制御構造に適しています。高レベルのインターフェイスはほとんど変更されません。レベル インターフェイスは未定義であるか、頻繁に変更される可能性があります トップダウン統合
データとデータベースの整合性テスト、機能テスト、ユーザー インターフェース テスト、パフォーマンス ベンチマーク、負荷テスト、強度テスト、容量テスト、
、セキュリティとアクセス コントロールのテスト、フェイルオーバーとリカバリのテスト; 構成テスト; インストール テスト; 暗号化テスト;
ユーザビリティ テスト; バージョン検証テスト; ドキュメント テスト
ソフトウェア テストの各段階では、通常どのような作業が行われますか?各ステージの結果ファイルは何ですか?何が含まれていますか?
単体テストの段階。各独立したユニット モジュールは、システムの他の部分から独立してテストされます。ユニット テスト ニードル
は、各プログラム モジュールに対して正当性チェックを実行し、各プログラム モジュールが指定された機能を正しく実装されているかどうかを確認します。単体テスト レポートを生成
し、欠陥レポートを送信します。
統合テスト フェーズ。統合テストは単体テストに基づいており、概要設計仕様の要件に従ってすべてのソフトウェア ユニットをモジュール、サブシステム、またはシステムに組み立てるプロセス中に各部分の作業が達成されるかどうか、または対応する技術指標を達成するかどうかをテストします。。この段階では、テストの概要と欠陥レポートの提出が必要です。 システム テスト フェーズ。検証テストに合格したソフトウェアは、コンピュータ ハードウェア、周辺機器、特定のサポート ソフトウェア、データ、人員などの他のシステム要素と組み合わせて、コンピュータ システム全体の要素として使用され、実際の動作環境下で包括的な機能をカバーします。コンピュータ システムの と必要なアクティビティ。この段階で、統合テストレポートが生成され、欠陥レポートが提出されます。
16.ソフトウェア開発プロセスにおけるテスターのタスクは何ですか?
1. バグを探す;
2. ソフトウェア開発プロセスの欠陥を回避する;
3. ソフトウェアの品質を測定する; < a i=3> 4. ユーザーのニーズに注意を払います。 全体的な目標は、ソフトウェアの品質を確保することです。 以前の仕事では、ソフトウェア欠陥 (またはバグ) レコードにはどのような内容が含まれていましたか?高品質のソフトウェア欠陥 (バグ) 記録を提出するにはどうすればよいですか?
バグ記録には基本的に、番号、バグが属するモジュール、バグの説明、バグレベル、発見日、発見者、修正日、修正者、修正方法、回帰結果などが含まれます。
バグを効果的に発見するには、要件や詳細設計などの事前ドキュメントを参照して効率的なテストケースを設計し、テストケースを厳密に実装し、発見された問題点を十分に確認する必要があります。
確認してから外部に公開します。これにより、送信されたバグの品質が向上します。
ブラック ボックス テストとホワイト ボックス テストはソフトウェア テストの 2 つの基本的な方法です。それぞれの長所と短所を説明してください。
ブラック ボックス テストの利点は次のとおりです:
比較的単純で、コードやプログラム内の実装を理解する必要がありません。
ソフトウェアに関係する 内部実装は関係ありません;
ユーザーの観点からは、ユーザーがどの機能を使用し、どのような問題が発生するかを簡単に知ることができます。 a> 自動テストは再利用性が低いです。 すべてのコードをカバーすることは不可能であり、カバー率は低く、おそらくコード全体の 30% のみです; ブラック ボックス テストの欠点は次のとおりです。 自動ソフトウェア テストを行う場合に便利です。
ソフトウェア開発ドキュメントに基づいているため、ドキュメント内のどの機能がソフトウェアによって実装されているかを知ることもできます。
ホワイト ボックス テストの利点は次のとおりです。
ソフトウェア テスターがコード カバレッジを増やし、コードの品質を向上させ、コード内の隠れた問題を発見するのに役立ちます。
ホワイト ボックス テストの欠点は次のとおりです:
プログラムの動作にはさまざまなパスがあり、すべての実行パスをテストすることは不可能です。< a i=4 > テストはコードに基づいています。テストは開発者が正しく実行したかどうかのみをテストできますが、設計が正しいかどうかはわかりません。一部の機能要件が欠けている可能性があります。システムが大きいと、テストのオーバーヘッドが非常に大きくなります。
17.紙コップをテストするにはどうすればよいですか?
機能性: カップに水を入れるときに漏れがないか確認します。水が飲めるかどうか。
安全性: カップに毒や細菌が付着していないか
信頼性: さまざまな高さから落としたときのカップの損傷の程度
携帯性: さまざまな場所、温度などでカップが正常に使用できるかどうか。
互換性 : カップにジュース、白水、アルコール、ガソリンなどを入れることができるかどうか。
使いやすさ : カップが触れると熱いか、滑り止めが付いているか、使いやすいか飲料用
ユーザーマニュアル: ユーザーマニュアルには、カップの使用法、制限事項、使用条件などの詳細な説明が記載されていますか?
疲労テスト:カップに水を満たし (ケース 1)、24 時間放置して漏れの時間と状況を確認します。ガソリンを入れます (ケース 1) ケース 2)
24 時間放置して確認します。漏れ時間や漏れの状況など。
圧力テスト: 針を使用し、針に重りを加え続け、どの程度の圧力がかかるかを確認します。 透明
18.テスト計画の目的は何ですか?テスト計画書の内容には何を含めるべきですか?これらのうちどれが最も重要ですか?
答え: ソフトウェア テスト計画は、テスト プロセスをガイドするプログラムによる文書です。
製品の概要、テスト戦略、テスト方法、テスト領域、テスト構成、テスト サイクル、テスト リソース、テスト
コミュニケーション、リスク分析などが含まれます。ソフトウェア テスト計画の助けを借りて、テストに関わるプロジェクト メンバー、特にテスト マネージャーは、テスト タスクとテスト方法を明確にし、テスト実装プロセス中に円滑なコミュニケーションを維持し、テストの進行状況を追跡および管理し、< a i=4> テスト中のさまざまな変更。 テスト計画、詳細なテスト仕様、テスト ケースの間には戦略的および戦術的な関係があります。テスト計画では主に、マクロの観点から範囲、方法、テスト活動を計画します。 リソースの割り当て、テストの詳細な仕様とテスト ケースは、テスト タスクを完了するための具体的な戦術です。 したがって、最も重要なことは、テスト戦略とテスト方法をテストすることです (できれば最初に確認できる)。
19.ブラック ボックス テストの一般的なテスト ケース設計方法は何ですか?テスト ケース設計作業におけるこれらのメソッドの適用を説明するには、具体的な例を使用してください。
同値クラスの分割
同値クラスの分割: 同値クラスとは、特定の入力ドメインのサブセットを指します。このサブセットでは、各入力データはプログラムを明らかにするために重要です。 . 誤差はすべて等価です。等価クラスの代表値をテストすることは、このクラスの他の値をテストすることと同等であると考えるのが合理的です。
したがって、すべての入力データは合理的に複数の同値クラスに分割でき、各同値クラスの 1 つのデータがテストの入力条件として取得されるため、少量の代表的なテスト データを使用して取得することができます。より良い結果 テスト結果 同値クラスの分割には、有効な同値クラスと無効な同値クラスの 2 つの異なる状況が考えられます。
2) 境界値の分析方法
境界 値分析法は、同値クラス分割法を補足するものです。テストの実務経験から、入力範囲と出力範囲内ではなく、入力範囲または出力範囲の境界で大量のエラーが発生することがわかりました。したがって、さまざまな境界条件に合わせてテスト ケースを設計すると、より多くのエラーを検出できるようになります。 3) エラー推測方法 経験に基づいて、プログラム内のすべての考えられるエラーを直感的に推測し、それによって的を絞った方法でテスト ケースを設計します。 の基本的な考え方。エラー推測方法: 考えられるすべてのエラーとプログラム内のエラーをリストする エラーが発生する特殊な状況、およびそれに基づいてテスト ケースが選択される たとえば、モジュール内の多くの一般的なエラーは単体テスト中にリストされます。製品テストなど、これらは経験の要約です。また、入力 データと出力データが 0 である、入力フォームが空白である、または入力フォームが 1 行しかないなど、エラーが発生しやすい状況です。これらの状況の例としては、テスト ケースとして選択される
4) 特性要因図法
先ほど紹介した同値クラス分割法や境界値解析法は、入力条件を考慮することに重点を置いており、入力条件間のつながりは考慮していません。入力条件の相互の組み合わせなど 入力条件の相互の組み合わせを考慮すると、新たな状況が生じる可能性がありますが、入力条件の組み合わせを確認することは容易ではありません。組み合わせは非常に多いため、複数の条件の組み合わせを記述し、それに応じて複数のアクションを生成するのに適した形でテストケースを設計することを検討する必要があり、そのためには特性要因図（論理的特性図）を使用する必要があります。
特性特性図法 最終的に生成されるのは決定表であり、プログラムの入力条件の様々な組み合わせを確認するのに適しています。 5) 直交表分析法 アウトライン法は、要件に着目した方法であり、さまざまなテスト条件を列挙するために、要件をアウトライン形式に変換します。アウトラインは、ルートと各リーフ ノードの間に一意のパスを持つツリー構造として表されます。アウトライン内の各パスは、テスト ケースの定義に使用される特定の入力条件のセットを定義します。ツリー内の葉の数、またはアウトライン内のパスの数から、すべての機能をテストするのに必要なテスト ケースのおおよその数がわかります。 8) アウトライン法 入力条件とシステム要件の記述を通じてテスト対象システムのすべての状態を取得し、入力条件と状態を通じて出力条件を取得します。入力条件、出力条件、および状態により、テスト対象システムのテスト ケースが生成されます。 7) ステート チャート方式 は、ユーザーのシナリオに基づいてユーザーの操作手順をシミュレートすることを指します。これは特性要因図に似ていますが、実行の深さと実現可能性が向上します。 6) シナリオ分析手法
場合によっては、多数のパラメーターの組み合わせによってテスト ケースの数が急増することが原因である可能性があります。同時に、これらのテスト ケースとテスターとの間に優先順位に明らかなギャップがないことも考えられます。は、そのような多数のテストを完了することはできないため、直交テーブルを使用してテストを減らすことができます。ユース ケースを使用して、できる限り少ないユース ケースで、可能な限り広い範囲をカバーできる可能性を実現します。
20. テスト アクティビティの完全なプロセスを詳しく説明します。
回答: (参考までに、この回答は主にウォーターフォール モデルに基づいています)
プロジェクト マネージャーは顧客とのコミュニケーションを通じて要件文書を完成させ、開発者とテスターは共同で要件文書を完成させます。要件の文書レビューには、要件が不明確な領域と、明らかな矛盾または達成不可能な機能が存在する可能性のある領域が含まれます。
プロジェクト マネージャーは、開発者、テスター、顧客の意見を統合してプロジェクト計画を完成させます。次に、SQA がプロジェクトに入り、統計と追跡を開始します。
開発者は要件ドキュメントに基づいて要件分析ドキュメントを完成させ、テスターはレビューを実施します。レビューの主な内容には、要件が満たされているかどうかが含まれます。双方の欠落または理解の相違。テスターはテスト計画文書を完成させます。テスト計画に含まれる内容は上記で説明されています。
テスターは修正された要件分析ドキュメントに基づいてテスト ケースの作成を開始し、開発者は概要設計ドキュメントと詳細設計ドキュメントを完成させます。これら 2 つのドキュメントは、テスターがテスト ケースを作成するための補助資料になります。
テスト ケースが完了したら、テストと開発をレビューする必要があります。
テスターの構築環境
開発者が最初のバージョンを提出するとき、説明が必要な未完成の機能がある可能性があります。テスターはテストを実施し、バグを発見した後、BugZilla に送信します。
バグ修正と追加機能を含む 2 番目のバージョンを開発して送信し、テスターがテストできるようにします。上記の作業を繰り返すと、通常 3 ～ 4 バージョン後に BUG の数が減り、出荷要件が満たされます。顧客から問題が報告された場合、テスターは再現と再テストを支援する必要があります。
21.以前の仕事では、ソフトウェアの欠陥 (またはバグ) レコードには何が含まれていましたか?高品質のソフトウェア欠陥 (バグ) 記録を提出するにはどうすればよいですか?
従来の BugZilla では、BUG の説明には次の情報を含める必要があります。
、BUG 世代に対応するソフトウェア バージョンとモジュール
開発されたインターフェイス担当者< /span>。 これは開発者が見つけるのに役立つため、高品質のソフトウェア欠陥レコードを送信するときは、BUG レコードの高品質で正確な説明に注意を払う必要があります 高品質な BUG レコードとは、わかりやすい BUG レコードを指すため、記述要件が高く、提供できる情報量が多い BUG 添付ファイルにより、関連するログとスクリーンショットが提供されます。 バグの説明、バグを修正する手順を示す必要があります バグのタイトル、現象を明確に説明する必要があります。 BUG が属するモジュール。確認できない場合は、開発者が判断できます。 BUG の重大度
BUG の優先度
G BUG 管理ツールの追跡プロセス
BugZilla を例として使用する
テスターが BUG を発見し、Bugzilla に送信しました。ステータスは新規です。 BUG 受信者は開発インターフェイス担当者です
開発インターフェイスは、BUG を関連モジュールの開発者に割り当て、ステータスを割り当て済みに変更し、開発者とテスターは BUG を確認します（それが私のものである場合）。自分のバグを受信するように設定します。別の開発者の問題の場合は転送され、次の開発者がこれを実行します。問題がない場合は、全員で話し合って確認した後、このバグを拒否します。< /span> バグは閉じられます。 。 テスターは新しいバージョンでテストします。問題がまだ存在することが判明した場合、検証は拒否されます。問題が修正された場合、。 開発者がバグを受け入れて修正した場合、開発者はバグのステータスを修正済みに変更し、どのバージョンでテストをテストできるかを通知します その後、テスターがこの問題をクローズします。
回答: 1) テスターまたは開発者はバグを発見すると、その問題がどのモジュールに属するかを判断します。バグ レポートに記入すると、システムは自動的にプロジェクト チームのリーダーに電子メールで通知するか、開発者に直接通知します。 。
\2) 検証後の変更ステータスは VERIFIED になります。製品全体がリリースされた後、CLOSED に変更されます。
\3) まだ残っています問題、再開しました。ステータスが再び「新規」に変わり、電子メール通知が送信されます。
\4) プロジェクト リーダーは、特定のバグに基づいて、バグが属する開発者にバグを再割り当てします。
\5) その場合は、処理して解決し、解決策を提示します (パッチの添付ファイルと補足説明を作成できます)
\6) その後開発者は電子メール メッセージを受信し、それが自分自身の変更であるかどうかを判断します。範囲。
\7) そうでない場合は、プロジェクト リーダーまたは割り当てられるべき開発者に再割り当てします。 a>
\8) テスターが開発者に問い合わせると、バグが修正されているため、再テストします。
22. **テスターと開発者間のコミュニケーションプロセスにおいて、コミュニケーションの効率と効果を向上させる方法を考えていますか? **テスターと開発チームの他のメンバーの間で良好な人間関係を維持するための鍵は何ですか?
対面でコミュニケーションするように努め、次に電話で直接コミュニケーションするようにしてください。電子メールやその他のタイムリーでないコミュニケーション ツールでしかコミュニケーションできない場合
は、次のことを強調してください。特性を深く理解し、それを表現できる。
TestDirector などのテスト管理ツールを使用して管理することもより効果的な方法ですが、
チーム内のテスターと開発者の間で良好なコミュニケーションを確立するときは、次の点に注意してください。
1誠実さ
2 つ目はチームスピリット
3 つ目は職業
において共通言語を持つことです。 4 人ではなく問題を扱い、仕事を優先する
もちろん、次のような方法で相手の好意を高めることもできます。 BUG追跡システムに入る代わりに、いくつかの小さな問題を直接指摘します。
23.テストに関して最も興味のあることは何ですか?なぜ？
この面接の質問に対する明確で統一された答えはありませんが、多くの企業で尋ねられる可能性があります。試験のために次の答えを入力してください:
私の最大の関心事は、これはやりがいのある仕事だと感じています。
試験は経験産業であり、長く働けば働くほど、うまくテストすることの難しさと楽しさ
自分の仕事を通じて、ソフトウェア製品をどんどん完成度を高めていき、その楽しさを体験することができます。 =4> このような質問に答えるときは、次の点に注意してください。 側面: 求人企業の技術的なルートにできるだけ近い関心を表明してください。たとえば、企業がデータベースの場合などです。アプリケーション会社に連絡し、 興味を示してください。データベースでテストしており、テストを通じてデータベースの習熟度を向上させることを期待しています。 テストの目的は、自分の能力を向上させ、より良いテストを行うことであることを示します。能力の向上は、将来の開発やその他の転用や 目的ではありません。ただし、雇用主がそのような取り決めを行っている場合を除きます。 求人企業の範囲を超えて興味を表明しすぎないでください。たとえば、人材紹介会社は金融ソフトウェアに取り組んでいますが、あなたはゲーム ソフトウェアに興味を示しています。または、人材紹介会社は JAVA 開発に取り組んでいますが、あなたは C 言語プログラムに興味を示しています。 開発。
24.テストの利点は何だと思いますか?
このインタビューに対する決まった答えはありませんが、次の点を参考にして自分の特性と組み合わせることができます:
打たれ強い
忍耐力
計画的に物事を進める
困難に立ち向かうのが好き
何事もうまくやる自信がある
優れたコミュニケーション能力
以前のマネージャーからは、私が良い仕事をしているという良い評価を受けています
25.統合テストには通常どのような戦略がありますか?
1. ビッグバン統合
2. トップダウン統合
3. ボトムアップ統合
4サンドイッチ統合は、ほとんどのソフトウェア開発プロジェクトに適しています
5. バックボーン統合
6. 階層化された統合
7. 機能ベース統合
8. メッセージベースの統合
9. リスクベースの統合
10. 進捗ベースの統合 a>
26. 一般的に使用される X UNIX コマンド x (一般的な Linux コマンド) ) (少なくとも 10); (Unix)
答え: ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit、
Linux の教科書を参照してください。
27. これまでの仕事で行ったことと、よく知っていることを簡単に説明してください。
この問題は人によって異なります。参考回答は以下の通りです。
これまでの私の主な仕事は、システム テストと自動テストでした。システム テストでは、BOSS システムのビジネス ロジック機能とソフトスイッチング システムのクラス 5 機能がテストされました。パフォーマンス テストは主に、さまざまなリクエスト数の下でシステムの応答時間とシステム リソースの消費量を取得するストレス テストです。自動テストでは、独自のスクリプトを作成し、いくつかのサードパーティ ツールを組み合わせて、主にソフトスイッチ機能のテストをテストします。 テストでは、ユーザーのニーズを完全に正確に理解することが非常に重要であると感じています。さらに、BUG の管理は 要件に基づく必要があり、すべての BUG を変更する必要はありません。 テストには忍耐と細心の注意が必要です。新しいバージョンでは、最初に発見されたバグのほとんどが修正されているためです。
正しい機能が正しく動作しなくなる場合もあります。したがって、反復テストと回帰テストに重点を置きます。
28,C/C++ での c static の用途は何ですか? (少なくとも 2 つのタイプを説明してください)
1) 関数本体内で、static として宣言された変数は、関数の呼び出し中にその値を維持します。
\2) モジュール内 (ただし関数本体の外) では、静的として宣言された変数にはモジュール内で使用される関数からアクセスできますが、
にはアクセスできません。モジュールによってアクセスされ、他の関数によってアクセスされます。ローカルグローバル変数です。
\3) モジュール内で、static として宣言された関数は、このモジュール内の他の関数からのみ呼び出すことができます。つまり、 この
関数は、それが宣言されているモジュールのローカル スコープに制限されます
29.リファレンスとポインタの違いは何ですか?
\1) ポインタではなく参照を初期化する必要があります。
\2) 初期化後に参照を変更することはできませんが、ポインタが指すオブジェクトを変更することができます。
\3) null 値への参照はありませんが、null 値へのポインタは存在します。
t インターネットではどのようなネットワーク プロトコルが使用されますか?プロトコルの主な階層は何ですか? t インターネットの物理アドレスと P IP アドレスの変換
どのようなプロトコルが使用されますか?
30、TCP/IP 协议
主な階層構造は、アプリケーション層/トランスポート層/ネットワーク層/データリンク層です。
ARP (アドレス解決プロトコル)
31.統合テストにおけるトップダウン統合とボトムアップ統合という 2 つの戦略についての理解を教えてください。また、それぞれの利点について話してください**** 欠点主にどのタイプのテストに適しているか。
1. トップダウン統合
利点: 主要な制御ポイントと判断ポイントを早期に検証します。深さの優先順位に従って、最初に完全なソフトウェア機能を実装して検証できます。 短所: 大量のカラム開発、低レベルの検証が遅れる、低レベルのコンポーネントのテストが不十分。
機能。機能は早期に証明されているため、信頼性が得られます。必要なドライバーは 1 つだけであり、ドライバー開発コストを削減します。障害分離をサポートします。
比較的明確で安定した製品管理構造に適しています。上位レベルのインターフェイスはほとんど変更されません。最下位レベルのインターフェイスは未定義であるか、頻繁に変更される可能性があります
。生産管理コンポーネントには比較的大規模なテクノロジーが搭載されています。リスクはできるだけ早く検証する必要があります。製品のシステム機能
動作をできるだけ早く確認したいと考えています。
2. ボトムアップ統合
利点: 基礎となるコンポーネントの動作を早期に検証します。作業は最初に並行して統合できるため、トップダウンよりも効率的です。スタブの
ワークロードを軽減し、障害の分離をサポートします。
短所: ドライバー開発の作業負荷が大きく、高レベルの検証が遅れ、設計エラーを時間内に発見できません。
比較的安定した低レベル インターフェイスに適応します。高レベル インターフェイスはより頻繁に変更され、低レベル コンポーネントはより早く完了します。
软件验收测试包括 ___ 、 ___ 、 ____ 三种类型。
软件验收测试包括正式验收测试、alpha 测试、beta 测试三种测试。
2 2 ．系统测试的策略有 ____________________________等 等 15 种方法。（该题
5 15 个空）
系统测试的策略有很多种的，有性能测试、负载测试、强度测试、易用性测试、安全测试、
配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、恢复测试、分布测试、可
用性测试。
3 3 ．设计系统测试计划需要参考的项目文档有 ___ 、 ___ 和 ____ 。
设计系统测试计划需要参考的项目文档有**软件测试计划、软件需求工件、和迭代计划。**
4 4 ．通过画因果图来写测试用例的步骤为 ___ 、 ___ 、 ___ 、 ___ 及把因果图转换为状态图共五
个步骤。 利用因果图生成测试用例的基本步骤是：
§ 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结
果（即输出条件），并给每个原因和结果赋予一个标识符。
§ 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么
关系? 根据这些关系，画出因果图。
§ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。
为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。 § 把因果图转换成判
定表。
§ 把判定表的每一列拿出来作为依据，设计测试用例。
一、 测试的种类很多，比如：
代码、函数级测试
模块、组件级测试
系统测试
请说出这些测试最好由那些人员完成，测试的是什么？
代码、函数级测试一般由白盒测试人员完成，他们针对每段代码或函数进行正确性检验，检
查其是否正确的实现了规定的功能。
模块、组件级测试主要依据是程序结构设计测试模块间的集成和调用关系，一般由测试人员
完成。
系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例
进行全面的测试。
32. テスト ケースを設計するときに考慮する必要がある側面、つまり、さまざまなテスト ケースでどの側面がテストされるか?
テスト ケースを設計するときに注意する必要があるのは、全体的なプロセスと機能に加えて、強度テスト、パフォーマンス テスト
テスト、ストレステスト、境界値テスト、安定性性テスト、安全性テスト、その他多くの側面。 (テスト ケースで考慮する必要がある 4 つの基本要素は、入力、出力、操作、およびテスト環境です。さらに、テスト ケースでは、テストの種類 (機能、 パフォーマンス、セキュリティ...) を考慮する必要があります。 、この部分については TP を参照して回答してください。さらに、ユースケースの重要性と優先順位も考慮する必要があります)
33. Windows 上でテキストファイルを保存すると、保存ダイアログボックスが表示されますので、ファイル名のテストケースを作成すると、
同値クラスはどのように分割すべきですか?
A などのシングルバイト、
ダブルバイト、AA、me、
特殊文字 /‘。 ';、=- など;
com などの予約語;
ファイル形式は 8.3 形式です;
ファイル名前形式 8.3 以外の形式 (
/,, およびその他の 9 つの特殊文字) です。
10 文字の郵便番号の入力を必要とするテキスト ボックスがあるとします。テキスト ボックスは同等のクラスにどのように分割されるべきでしょうか?
10 などの特殊文字 や￥、
ABCDefghik などの英字、
10 文字未満（123 など）、
10 文字を超える文字（11111111111 など）、
混合数字およびその他（123AAAAAAA など） 予約文字
ヌル文字;
34. ソフトウェアテストプロジェクトはいつ始まりますか?なぜ？
テストの対象はプログラムのコーディングだけではなく、ソフトウェア開発プロセスで作成されるすべての製品をテストする必要があり、ソフトウェアの欠陥は拡大する傾向があるため、ソフトウェアテストは要件分析の段階で行う必要があります。修理するのに費用がかかるほど、費用が高くなります。
35.ホワイト ボックス テストとは何ですか?ブラック ボックス テストとは何ですか? ? 回帰テストとは何ですか? ?
回答: ホワイトボックス テストでは、テスターはプログラムの構造と処理プロセスを理解し、プログラムの内部ロジックに従ってプログラムをテストし、プログラム内の各パスが所定の要件に従って正しく動作するかどうかを確認する必要があります。主にテスト対象のプログラムのソース コードに焦点を当てており、テスターはプログラムの機能をまったく考慮する必要がありません。
ホワイト ボックス テスト プロセス: 詳細設計 –> ソース プログラム –>プログラムの内部論理構造の分析 –> フローチャート –> テスト ケースの開発 –> テスト対象のプログラム –> 実行パス –> カバレッジ分析。
ブラックボックス テスト: (ブラックボックス テスト。機能テストまたはデータ駆動型テストとも呼ばれます) テスト オブジェクトをブラック ボックスとして扱います。ブラックボックステスト手法を動的テストに使用する場合、ソフトウェア製品の機能をテストする必要があり、ソフトウェア製品の内部構造や処理プロセスをテストする必要はありません。
回帰テスト: (回帰テスト): 回帰テストには、ユースケース回帰とエラー回帰の 2 種類があります。ユースケース回帰は、一定期間後に以前に使用したユースケースに戻って再テストすることです。問題が再び見つかることを確認してください。エラー回帰とは、以前のバージョンで発生し修正された不具合を新バージョンで再検証し、不具合を核として該当する修正部分をテストする手法です。
36. 単体テスト、統合テスト、システムテストの焦点は何ですか?
単体テストは、ソフトウェア設計の最小単位であるプログラム モジュール（プロセス指向では関数や手続き、オブジェクト指向ではクラス）を対象とし、各プログラムの内部内容を発見するのが正当性検証のテスト作業です。モジュール 考えられるエラー。一般に 2 つのステップがあります: 手動静的検査\動的実行追跡
統合テストは、単体テストに合格した各モジュールに統合されたコンポーネントをテストすることを目的としています。その主な内容は次のとおりです。各単位モジュール間のインターフェースと、統合後に各モジュールによって実装される機能 システムテストは、コンピュータハードウェア/周辺機器/特定のサポートソフトウェア/データおよびその他のシステムとともに、コンピュータシステム全体の要素として統合されたソフトウェアシステムを対象としています。人員などの要素を組み合わせ、実際の運用環境でコンピュータシステムに対して一連の結合テストや確認テストを実施する必要がある。
37. ユースケースを設計する方法:
テストのさまざまな段階でさまざまなテスト方法を使用すると、テスト ケース設計の基礎が異なります。
ホワイトボックス テスト ケースの設計には、次の方法が使用されます: ロジック カバレッジ、ループカバレッジと基本パスのカバレッジ
ブラック ボックス テスト ケースの設計手法: 同値クラス分割、境界値分析、エラー推定、原因影響図、状態図、テスト概要、シナリオ手法、直交戦略テーブル。
38. テストエンジニアが持つべき資質とは何ですか?
1. 責任
2. コミュニケーション スキル
3. チームワークの精神
4. 忍耐力と慎重さ、自信
5. 常に疑う姿勢を持ち、不具合防止の意識を持ちましょう
6. 一定のプログラミング経験がある
39. 統合テストには通常どのような戦略が使用されますか?
分解に基づく統合: ビッグバン統合\トップダウン統合\ボトムアップ統合\サンドイッチ統合\コール グラフベース
統合\パスベースの統合\レイヤード統合\機能ベースの統合\高頻度の統合\進捗ベースの統合\リスクセットベース
統合\イベントベースの統合\用途ベースの統合\C/S 統合
質問 2: どのような種類のソフトウェア テストを知っていますか? 簡単に紹介してください。
テスト戦略による分類: 1. 静的テストと動的テスト 2. ブラック ボックス テストとホワイト ボックス テスト 3. 手動テストと自動テスト 4. スモーク テスト
テスト 5 、回帰テスト;
テスト段階による分類: 単体テスト、統合テスト、システム テスト;
その他の一般的なテスト方法: 1. 機能テスト 2、パフォーマンス テスト 3 、ストレス テスト 4、負荷テスト 5、ユーザビリティ テスト 6、
インストール テスト 7、インターフェイス テスト 8、構成テスト 9、ドキュメント テスト 10、互換性テスト 11、セキュリティ テスト 12、回復テスト
40. 優れたテスト計画の鍵は何だと思いますか?
テストの目的を明確にし、テスト計画の実践性を高める
ソフトウェア テスト計画を作成する重要な目的は、テスト プロセスでより多くのソフトウェア欠陥を発見できるようにすることです。したがって、ソフトウェア テスト計画の価値は、テスト プロジェクトの管理とソフトウェアの潜在的な欠陥の特定に役立つかどうかにかかっています。したがって、ソフトウェア テスト計画のテスト範囲は機能要件を高度にカバーする必要があり、テスト方法は実用的かつ実行可能でなければならず、テスト ツールは非常に実用的で使いやすく、生成されるテスト結果は直観的で正確でなければならず、 「5W」ルールを定め、内容とプロセスを明確にする 「5W」ルールとは、「何を」「なぜ」「いつ」「どこで」「どのように」を意味します。 「5W」ルールを使用してソフトウェア テスト計画を作成すると、テスト チームがテストの目的 (Why) を理解し、テストの範囲と内容 (What) を明確にし、テストの開始日と終了日 (When) を決定するのに役立ちます。テスト方法とツール (How) を示し、テスト文書とソフトウェアの保管場所 (Where) を示します。
レビューと更新のメカニズムを使用して、テスト計画が実際の要件を満たしていることを確認します。テスト計画を作成した後、レビューせずにテスト チームに直接送信すると、テスト計画の内容が不正確になったり、テストの内容が正しくない可能性があります。テスト計画の内容が適時に更新されず、テスト実行担当者に誤解を与えた。
テスト計画を作成し、詳細仕様とテストケースをそれぞれテストします。詳細なテスト技術指標は独自に作成されたテスト詳細仕様書に含まれ、テストチームがテストプロセスを実行するように導くためのテストケースは独自に作成されたテストケースドキュメントに配置されます。またはテストケース、ユースケース管理データベース。
テスト計画、詳細なテスト仕様、およびテスト ケースの間には戦略的および戦術的な関係があります。テスト計画は主にマクロの観点からテスト活動の範囲、方法、およびリソースの割り当てを計画しますが、詳細なテスト仕様とテスト ケースは特定の戦術です。テストタスクを完了する。
41. 優れたテストケース設計の鍵は何だと思いますか?
ホワイトボックス テスト ケース設計の鍵は、少ないユースケースでできるだけ多くの内部プログラム ロジック結果をカバーすることです
ブラックボックス テスト ケース設計の鍵は、使用例が少なくなり、モジュールの出力インターフェイスと入力インターフェイスをカバーします。完全に測定することは不可能です。
最小限の使用例で、妥当な時間内に最大限の問題を見つけるように努めてください。
42. パフォーマンス テストの目的は何だと思いますか?パフォーマンス テストで良好な結果を得る鍵は何ですか?
パフォーマンス テストの主な目的は、マルチユーザーおよび大規模データの同時操作中に要件との差異があるかどうかを確認することです
。パフォーマンス テストの鍵は、システム分析と機能分析を行ってシステムのボトルネックを特定することです (ATT
第 10 章 LoadRunner PPT をここで参照してください)。
43. テストのキャリア開発目標は何ですか?
テスト経験が豊富であればあるほど、テスト能力は高くなります。そのため、私のキャリア形成には時間と積み重ねが必要であり、一歩ずつ上級テストエンジニアを目指して走ります。また、暫定的なキャリア プランもあり、最初の 3 年間はテストの経験を積み、常に自分自身を更新および修正し、テスト タスクで良い仕事をしました。
44. 私たちの会社についてどのくらい知っていますか?
求人広告からより多くの情報を入手すると同時に、応募先の企業の Web サイトにアクセスして、その企業についてできるだけ詳しく知ることをお勧めします。
これらの質問にうまく答えるために。
45. テストを終了する基準は何ですか?
ミクロな観点から見ると、これはテスト計画で定義されます。たとえば、システムが特定のパフォーマンスで 72 時間スムーズに動作する場合、現時点ではこのバージョンのバグに重大なバグはありません。< a i=1> Tracking System.、一般的なバグの数が 3 未満、バグ修復率が 90% 以上、その他のパラメータに基づいて、開発マネージャー、テスト マネージャー、およびプロジェクト マネージャーが連名でバージョンに署名して承認します。リリース。 巨視的に言えば、ソフトウェアが完全に消滅した時点でテストは終了することを意味します。
46. ソフトウェアテストはブラックボックスとホワイトボックスに分かれますが、それぞれどのような状況に適していますか? ?
ソフトウェアのテスト方法は、一般にホワイト ボックス テストとブラック ボックス テストの 2 種類に分類されます。ホワイト ボックス テストは、構造テスト、ロジック駆動テスト、またはプログラム自体に基づくテストとも呼ばれます。プログラムの内部構造とアルゴリズムに焦点を当て、通常は機能や性能には関心がありません。 指標。ブラック ボックス テストは、機能テスト、データ駆動型テスト、または仕様ベースのテストとも呼ばれます。実際には、エンド ユーザーの立場に立って、入力および出力情報と、システム パフォーマンス インジケーターは、仕様で指定されている機能要件とパフォーマンス要件を満たしています。
47. 完全なテストセットはどの段階で構成されなければなりませんか?
実現可能性分析、要件分析、概要設計、詳細設計、コーディング、単体テスト、結合テスト、システムテスト、受け入れ
受け入れテスト
48. テストケースには通常どのような内容が含まれますか?
さまざまな構造のユースケースには、さまざまなユースケースが含まれます。 (バージョン、番号、プロジェクト、デザイナー、設計日、入力、期待される出力...)
ソフトウェア テスト ケースの基本要素には、テスト ケース番号、テスト タイトル、重要度レベル、テスト入力、操作手順、期待される結果。
テスト ケースの数: テスト ケースの数には特定の規則があります。たとえば、システム テスト ケースの数は次のように定義されます: < a i=4> PROJECT1 -ST-001、命名ルールはプロジェクト名 + テストフェーズタイプ (システムテストフェーズ) + 番号です。テスト ケース番号を定義すると、テスト ケースの検索と追跡が容易になります。 テスト タイトル: テスト ケースの説明。テスト ケースのタイトルは、テスト ケースの目的を明確に表現する必要があります。たとえば、「ユーザーがログイン時に間違ったパスワードを入力したときのソフトウェアの応答をテストする」などです。 重要度: テスト ケースの優先度を定義します。一般に、「高」と「低」の 2 つのレベルに分けることができます。一般的に、ソフトウェア要件の優先度が「高」であれば、その要件に対するテストケースの優先度も「高」となり、その逆も同様で、一般的には5段階に分けられます。 テスト入力: テスト実行時のさまざまな入力条件を提供します。要件の入力条件に基づいてテストケースの入力を決定します。テスト ケースの入力はソフトウェア要件の入力に大きく依存するため、要件の入力がソフトウェア要件で明確に定義されていない場合、テスト ケースの設計に大きな障害が発生します。 操作手順: テスト実行プロセスの手順を示します。複雑なテストケースの場合は、テストケースの入力を複数のステップに分けて完了する必要がありますが、この部分は操作手順に詳しく記載されています。 期待される結果: テスト実行の期待される結果を提供します。期待される結果は、ソフトウェア要件の出力に基づく必要があります。の場合
実際のテスト プロセス中に、得られた実際のテスト結果が期待された結果と一致しない場合、テストは失敗し、そうでない場合、テストは合格します。
49. 過去に働いていた会社のソフトウェア開発プロセスを理解していますか?理解できましたら、開発プロセス全体でどのような作業を完了する必要があるのか説明してください。これらのタスクを実行するさまざまな役割は何ですか?これまでのテスト作業では、具体的にどのようなタスクに従事していましたか?仕事のどの部分が一番得意ですか?
開発プロセス - 要件調査 (要件担当者)、要件分析 (要件担当者)、概略設計 (設計者)、詳細設計 (設計者)、コーディング (開発者) ) テスト プロセス- 要件レビュー、システム テスト設計、概要設計レビュー、統合テスト設計、詳細設計レビュー、単一メタテスト設計、テスト実行 a> プロセスが品質を決定します ソフトウェアのプロセス改善とは、まさにソフトウェアの品質を向上させ、さまざまな要素を組み合わせることです。過去の経験と教訓が蓄積されています。 テスト業務の全プロセスを行っており、テスト設計が得意です
50、あなたが経験したテスト活動の参加者は誰でしたか?あなたの役割は何ですか?
プロジェクト マネージャー、開発マネージャー、システム アナリスト、デザイナー、開発者、品質マネージャー、テスト マネージャー、テスター
テスト デザイナーとテスター a>
テスト マネージャー、テスト デザイナー、テスターを務めました
テスト ケース設計の原則は何ですか?現在の主なテストケース設計方法は何ですか?
代表性: さまざまな合理的と不合理、合法と違法、境界と越境、および極端な
入力データ、操作、および環境設定を表現し、カバーすることができます。など。
決定可能性: つまり、テスト実行結果の正しさは決定可能であり、各テスト ケースには対応する期待結果が必要です。< a i=7> 再現性: つまり、同じテスト ケースでは、システムの実行結果は同じになるはずです。 メソッドには、等価クラス、境界値、因果関係図、状態図、直交メソッド、アウトラインメソッドが含まれます。 オブジェクト指向テスト ケースにはメソッドがいくつありますかデザイン？どうやって達成するのか？ クラス内のコンストラクターごとに一連のテスト ケースを設計する クラス内のクラス変数とインスタンス変数を組み合わせる 組み合わせ さまざまなクラス内のメソッド 事前条件と事後条件に基づいてテスト ケースを設計する コードに基づいてテスト ケースを設計する LoadRunner 3 つとはモジュール?各モジュールの主な機能を簡単に説明してください。 仮想ユーザー ジェネレーター: 足音の記録用 Mercury LoadRunner コントローラー: シナリオの作成、実行、監視用
Mercury LoadRunner Analysis: テスト結果の分析に使用されます。
51.テストに関して最も興味のあることは何ですか?なぜ？
最大の関心事は、テストが難しくて挑戦的であるということです。テストを長く続けるほど、テストをうまく行うことがいかに難しいかがわかります。以前、Wuyou テスト Web サイトでテスト エンジニアになる方法に関する記事を見たことがあります。合計11、12のポイントが挙げられていますが、その中には人の性格に関係するものもあれば、後天的な努力が必要なものもあります。しかし、キャラクターに関連する 1 と 2 の点を除けば、それ以外の点ではうまくやる自信があります。 私が初めてテスト業界に入ったとき、私のテストについての理解は、Wuyou Test Network から学んだいくつかの情報に基づいていました。当時、私が目指していたのは 多くのスキルを必要とするテスト。うまくやってこそうまくできる。始めるのは簡単だが、うまくやるのは難しい。開発よりも難しい。本当は開発をやりたかったが、 （私はプロフェッショナルが好きだったので、学校のプロフェッショナルの授業は基本的に欠席しませんでした）しかし、テストのほうが開発よりも難しくてやりがいがあることを見て、テストで良い仕事をしようとさらに決意するようになりました。 テスト プロセス全体で非常に難しいと感じる点が 2 つあると思います (私にとって、難しいことには非常に興味があります )
1 つ目はテスト ケースの設計です。テストの本質はテスト ケースの設計にあるためです。バージョンがリリースされる前に
、テスト ケースは適切に記述され、どのようなテストをどのように書くべきですか? (例: テスト計画またはテスト戦略)、
新しいタスクをテストするだけの場合、ビジネス要件と技術的基盤を理解するために一定の時間を費やす必要があります。ビジネス要件は簡単に理解できます。理解できます (Duohe 目標は、 プロダクト マネージャー
や開発者とコミュニケーションをとることで達成できます) が、技術的な基礎はそれほど単純ではないため、意識的な学習能力が必要です。たとえば、Web サイトを例に挙げます。最も基本的な技術知識としては、Web サイトが内部でどのように動作するのか、バックエンドがユーザーのリクエストにどのように応答するのかを知る必要があります。テスト環境をセットアップするにはどうすればよいですか?これらは早い段階で学習する必要があります。テストを開始する前に少なくとも基本的な準備ができた場合、どのような困難に遭遇する可能性がありますか?要件の詳細はまだ決まっていないのでしょうか？これらの問題は、ユースケースを設計するときに発見できます。 2 回目はバグを見つけることです。これはテスターの最も基本的なタスクです。通常、テスト ケースに従ってテストを開始することで、ほとんどのバグを見つけることができます。 < a i=9> バグ、および一部のバグは、テスト対象のバージョンに関する 詳しい情報を取得し、テスト ケースを補足し、バグをテストするために、テスト プロセス中によく理解する必要があります。そして、バグを見つけるにはどうすればよいでしょうか?そのためには、 テスト ケースが有効な場合に注意と忍耐を持ってバグを発見する必要があります。バグはあらゆるユース ケースで見つかる可能性があり、エラーはあらゆる場所で発生する可能性があるため、 バグの説明方法も非常に特殊です。どのような状況でバグが発生するのか? 条件が少しでも変わるとバグは存在しません。テスト プロセス中は明確に考えてください (データ フローとテスト プロセスの結果を注意深く見る必要があり、そこにバグが見つかります)。たとえば、
このバグを再現するための最小限の手順は何ですか? このバグのパターンは何ですか?十分な能力があれば、開発者が最初に問題を特定できるよう支援できます。
52、質問 15: テストのキャリア開発の目標は何ですか?
テスト経験が多いほど、テスト能力は高くなります。そのため、私のキャリア形成には時間の積み重ねが必要であり、上級テストエンジニアを目指して一歩ずつ走っています。また、暫定的なキャリアプランもあり、最初の 3 年間でテストの経験を積んだ後、 優れたテストエンジニアになる方法を学びます
11 時と 12 時に、常に自分自身を更新して修正し、テスト タスクで良い仕事をするように自分に問いかけてください。
**53. どのような種類のソフトウェア テストに精通していますか?これらの異なるテスト タイプの違いと関連性を比較してみてください。
テストの種類には、機能テスト、パフォーマンス テスト、インターフェイス テストが含まれます。機能テストはテスト作業の中で最も大きな割合を占めており、機能テストはブラック ボックス テストとも呼ばれます。テスト オブジェクトをブラック ボックスとして扱います。ブラックボックステスト手法を動的テストに使用する場合、ソフトウェア製品の機能をテストする必要があり、ソフトウェア製品の内部構造や処理プロセスをテストする必要はありません。ブラック ボックス テクノロジを使用してテスト ケースを設計する方法には、同値クラス分割、境界値分析、誤差推測、因果関係図、および包括的な戦略が含まれます。
パフォーマンス テストでは、自動テスト ツールを使用してシステムのさまざまなパフォーマンス指標をテストし、さまざまな正常、ピーク、および異常な負荷状態をシミュレートします。負荷テストとストレス テストはどちらもパフォーマンス テストであり、この 2 つを組み合わせることができます。負荷テストでは、さまざまなワークロード下でのシステムのパフォーマンスを確認し、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることが目的です。ストレス テストは、システムが提供できる最大のサービス レベルを得るために、システムのボトルネックまたは許容できないパフォーマンス ポイントを特定するテストです。インターフェイス テスト: インターフェイスは、ソフトウェアとユーザー間の対話の最も直接的な層であり、インターフェイスの品質によって、ソフトウェアに対するユーザーの第一印象が決まります。さらに、適切に設計されたインターフェイスは、ユーザーが対応する操作を自分で完了できるようにガイドし、ガイドとして機能することができます。同時に、インターフェイスは人間の顔のようなものであるため、ユーザーを引き付けるという直接的な利点があります。優れたインターフェイスはユーザーにリラックス感、喜び、成功感をもたらしますが、逆にインターフェイスの設計が失敗すると、ユーザーはイライラすることになり、どんなに実用的で強力な機能であっても、ユーザーのニーズに無駄になってしまう可能性があります。恐怖と放棄。
違いは、機能テストでは製品のすべての機能に焦点が当てられ、あらゆる詳細な機能とあらゆる考えられる機能上の問題が考慮されることです。パフォーマンス テストは主に、マルチユーザーの同時実行下での製品全体の安定性と堅牢性に焦点を当てます。インターフェイスのテストでは、ユーザーが製品を使用する際に、使いやすいか、分かりやすいか、標準化されているか（ショートカットキーなど）、美しいか（ユーザーの注意を引くか）、安全か（ユーザーの注意を引くか）など、ユーザーエクスペリエンスに重点を置いています。フロントデスクは、ユーザーが意図せずに無効なデータを入力することを防ぎます。もちろん、エクスペリエンスを考慮して、あまりにも無礼に警告をポップアップすることはできません）。特定のパフォーマンス テストを行う場合、まずそれがファンクション ポイントである可能性があります。まず、その機能が正常であることを確認してから、このファンクション ポイントのパフォーマンス テストを検討する必要があります
**54. ブラックボックステスト、ホワイトボックステスト、単体テスト、結合テスト、システムテスト、受け入れテストを比較してみてください。
相違点と関連性
ブラック ボックス テスト: 製品の機能設計仕様がわかれば、実装された各機能が要件を満たしているかどうかを証明するテストを実施できます。
尋ねます。
ホワイト ボックス テスト: 製品の内部動作プロセスは既知であり、各内部動作が設計仕様を満たしているかどうか、およびすべての内部動作が設計仕様を満たしているかどうかをテストすることができます。検査後、内部コンポーネントは設計の要件を満たしています。 ソフトウェアのブラック ボックス テストとは、ソフトウェアのインターフェイスでテストが実行されることを意味します。この方法では、テスト対象をブラックボックスとして扱い、テスタはプログラムの内部論理構造や内部特性を全く考慮せず、プログラムの要求仕様のみに依存する =7> プログラムの機能が規定に準拠しているかどうかを確認するその機能説明。したがって、ブラック ボックス テストは、機能テストまたはデータ駆動テストとも呼ばれます。ブラック ボックス テストは、主に次の種類のエラーを検出することを目的としています。 1. 間違った機能や欠落している機能はありますか? 2. インターフェイス上で入力を正しく受け入れることができますか?正しい結果を出力できるでしょうか? 3. データ構造のエラーや外部情報 (データ ファイルなど) へのアクセス エラーはありませんか? 4. パフォーマンスは要件を満たすことができますか? 5. 初期化または終了エラーはありますか? ソフトウェアのホワイト ボックス テストは、ソフトウェアの手順の詳細を詳細に検査することです。このメソッドは、テスト オブジェクトを 開いたボックスとみなし、テスターがプログラムの内部論理構造と関連情報を使用してテスト ケースを設計または選択できるようにします。 プログラムのすべての論理パスをテストします。さまざまな時点でプログラムの状態をチェックすることで、 実際の状態が期待される状態と一致しているかどうかを判断します。したがって、ホワイトボックス テストは、構造テストまたはロジック駆動テストとも呼ばれます。ホワイト ボックス テストでは、主にプログラム モジュールに対して次のチェックを実行します。 1. プログラム モジュールのすべての独立した実行パスを少なくとも 1 回テストします。 2. すべての論理的判断について、「真」と「偽」の両方の状況を少なくとも 1 回テストできます。 3. ループの境界および操作の制限内でループ本体を実行します。 4. 内部データ構造などの妥当性をテストします。 単体テスト (モジュール テスト) は、テスト対象のコードの小さくて明確な機能が正しいかどうかを検証するために、開発者によって作成された小さなコードです。一般に、単体テストは、特定の条件 (またはシナリオ) での特定の機能の動作を判断するために使用されます。単体テストはプログラマー自身によって完了し、最終的にはプログラマー自身が利益を得ます。プログラマーは機能コードを書く責任があり、また自分のコードの単体テストを書く責任もあると言えます。単体テストを実行することは、このコードが期待どおりに動作することを証明することです。 統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれる) は、単体テストの論理的な拡張です。最も単純な形式では、すでにテストされた 2 つのユニットが 1 つのコンポーネントに結合され、それらの間のインターフェイスがテストされます。この意味で、コンポーネントとは、複数のユニットが統合された集合体を指します。実際のシナリオでは、多くのユニットがコンポーネントに結合され、コンポーネントがプログラムのより大きな部分に集約されます。このアプローチは、フラグメントの組み合わせをテストし、最終的には他のモジュール グループを使用してモジュールをテストするプロセスを拡張することです。最後に、プロセスを構成するすべてのモジュールが一緒にテストされます。システムテストは、テスト対象のサブシステムをテスト用の完全なシステムに組み立てることです。システムソリューション仕様書で定められた機能をシステムが本当に提供できるかを検証する有効な方法です。 (一般的な共同デバッグ テスト) システム テストの目的は、最終ソフトウェア システムが製品要件を満たし、システム設計に従っていることを確認するために、最終ソフトウェア システムを包括的にテストすることです。
受け入れテストは、ソフトウェアを展開する前の最後のテスト操作です。受け入れテストの目的は、ソフトウェアの準備が整い、エンド ユーザーがソフトウェアの意図した機能やタスクを実行するために使用できることを確認することです。受け入れテストは、システムが意図したとおりに動作することを将来のユーザーに実証します。統合テストの後、すべてのモジュールが設計に従って完全なソフトウェア システムに組み立てられ、インターフェイスのエラーが基本的に排除され、ソフトウェアの有効性がさらに検証されます。これが受け入れテストのタスクです。ソフトウェアの機能と機能、パフォーマンスはユーザーが合理的に期待するものです。
55. 開発者がバグではないと言ったらどう対処しますか?
開発者は「これはバグではない」と言っています。状況は 2 つあります。1 つは、要件が決まっていないため、これを行うことができます。この時点で、プロダクト マネージャーを見つけて、変更が必要かどうかを確認できます。三者は、変更するかどうかについて話し合って決定します。次に、このような状況は起こり得ないので、修正する必要はありませんが、この時点で、まずバグの根拠が何であるかを可能な限り伝えることができます。ユーザーに発見されたり、何か問題が発生した場合、どのような悪影響がありますか?プログラマはさまざまな理由を説明するかもしれませんが、その説明に反論することもできます。それでも動作しない場合は、この問題を提起して開発マネージャーとテストマネージャーに確認します。変更する場合は変更してください。変更したくない場合は変更しないでください。 。中には実際にはバグではないものもあり、私が提案した方法で TD に書き込んだだけなので、開発者が修正しなければ大きな問題は発生しません。バグであると判断された場合は、自分の立場を貫き、問題が最終的に確認されるようにしなければなりません。
56. ソフトウェアのテストをチームで実行する必要があるのはなぜですか?
リリース前にテストされていないソフトウェアの品質を知るのは難しいためです。ISO 品質認証と同様に、テスト
にも品質保証が必要です。現時点では、ソフトウェアテストの作業はチームで実行する必要があります。テスト プロセス中に、 ソフトウェアの問題が
発見され、開発者に通知され、タイムリーに修正されます。リリースが近づくと、テスト レポートから問題を取得できます。
ソフトウェアの品質。
57. 開発者になる機会があったら、開発の仕事をしますか?
会社が本当に私を必要としてくれれば、開発にも携わることができますが、私はテストが好きなので、テストのほうが向いていると思っています。
58. テスト計画には何を含めるべきですか?
背景、プロジェクトの紹介、目的、テスト範囲、テスト戦略、人事分業、リソース要件、スケジュール、参考資料、共通用語、提出書類、リスク分析。
59. ソフトウェア業界の背景を考慮すると、ソフトウェア ビジネスをどのように理解しますか?
ソフトウェアの機能や操作手順を理解するためにユーザーマニュアルを読んだり、ビジネス知識を補うためにビジネスに関する専門書を読んだり、実際のユーザーデータがある場合は実際のデータを参照したり、過去のユースケースやバグレポートを参照したりできます。ソフトウェアを使用する過程で、より多くのことを考え、プロダクト マネージャーとより多くのコミュニケーションを図ります。
60. テストケースには何を含めるべきですか?
番号、モジュール名、作成者、日付、操作手順、入力データ、期待される結果など。
テスト ケースの役割をどのように位置づけるか?
構成: 執筆、構成、機能範囲、再現性、追跡、テスト確認
61、テスト プロセスで最も重要なことは何ですか?
要件の計画。
62、互換性テストとは何ですか?互換性テスト リストをテストに使用する方法の例を提供してください。
主に、ソフトウェア製品の異なるバージョン間の互換性を検証します。下位互換性と相互互換性を含め、下位互換性はソフトウェアの新しいバージョンが以前のバージョンの機能を保持しているかどうかをテストすることです。相互互換性は 2 つの関連する異なる製品の共存を検証することです< /span>。
63、 特定のソフトウェアをテストしたところ、8 WIN98 での動作が非常に遅いことがわかりました。ソフトウェアに問題があるのか、ソフトウェアとハードウェアの動作に問題があるのかを判断する方法環境？
ソフトウェアの動作環境要件を確認してください。要件が満たされている場合はプログラムに問題があり、要件が満たされていない場合はハードウェア システムに問題があります。