試験面接中、面接官は全員のテスト設計能力をテストするために、全員がテストポイントを設計する簡単なシーンを提示することがよくありますが、質問は簡単そうに見えて実は殺意が含まれており、試験官は勤務年数に応じて異なる回答をする必要があり、合格することができます。
1 ～ 2 年勤務している場合は、機能テストのポイントに答えるだけで済みますが、考慮される機能ポイントは包括的である必要があります。
3 ～ 4 年働く場合は、機能に加えて、パフォーマンスやユーザー エクスペリエンスも考慮する必要があります。
4 年以上働いている場合は、より包括的に検討する必要があり、セキュリティ テストと互換性テストを考慮する必要があります。
ここではまず石を投げて、Web システムのログインを例としてユースケースを設計し、最も一般的に使用されるログインに対してテスト ポイントをいくつ設計できるかを皆に見てもらいます。(ユーザー名とパスワードを使用した Web システムへのログインのみを考慮しており、携帯電話の確認コード、携帯電話のスキャン コード、およびサードパーティのログインは考慮していません)
機能的なユースケースの設計ポイント:
1. 登録したユーザー名と正しいパスワードで、ログインが成功したかどうかを確認します
2. 登録されたユーザー名とパスワードが間違っているか、検証が成功したかどうか、およびプロンプト情報が正しいかどうか
3. 未登録のユーザー名と任意のパスワードについては、ログインが失敗し、プロンプト情報が正しいかどうかを確認します。
4. アカウントがログイン用にアクティブ化されておらず、検証でログインに失敗する
5. 無効化されたユーザーがログインし、ログインが失敗するかどうかを確認します。
6. ユーザー名とパスワードが両方とも空です。ログインが失敗するかどうか、プロンプト情報が正しいかどうかを確認します。
7. ユーザー名とパスワードの 1 つが空です。ログインが失敗するかどうか、プロンプト情報が正しいかどうかを確認します。
8. ページ上のパスワードボックスが暗号化されて表示されるかどうか
9. ユーザーがログインに成功した後、セッションがタイムアウトすると、操作を続行するかどうかがユーザー ログイン インターフェイスにリダイレクトされます。
10. 管理者と一般ユーザーなど、さまざまなレベルのユーザーがシステムにログインした後に正しい権限を持っているかどうか
11. ブラウザ ページのデフォルトのフォーカスがユーザー入力ボックスにあるかどうか
12. ショートカットキーのTabとEnterが正常に使用できるかどうか
13. ユーザー名とパスワードが特殊文字と中国語をサポートしているかどうか
14. ログアウトに成功したら、ブラウザの戻るボタンをクリックして、オペレーティング システムを続行できるかどうかを確認します。
15. さまざまなブラウザで、ログイン ページの表示と機能が正しいことを確認します。
16. ログイン UI ページのデザインが美しいことを確認します
セキュリティ テスト ケースの設計ポイント:
1. ユーザーパスワードデータベースのストレージが暗号化されているかどうか
2. ネットワーク送信時にユーザーパスワードが暗号化されるかどうか
3. パスワードに有効期間があるかどうか、およびパスワード有効期間終了後にパスワードを変更する必要があるかどうか
4. ログインしない場合は、ログイン後にブラウザに URL アドレスを直接入力して、ユーザー ログイン インターフェイスにリダイレクトされるかどうかを確認します。
5. パスワード入力ボックスはコピーアンドペーストをサポートしていませんか?
6. パスワード入力ボックスに入力したパスワードがブラウザの開発者コードモードで閲覧できるかどうか
7. ユーザー名とパスワードの入力ボックスに SQL インジェクションの脆弱性はありますか?
8. ユーザー名とパスワードの入力ボックスに XSS クロスサイト スクリプティング攻撃の脆弱性があるかどうか
9. 連続ログイン失敗時のアカウントロックの有無
10. 同じユーザーが複数の端末（ブラウザ、携帯電話など）に連続してログインし、相互に排他的ログインかどうかを検証する
12. パスワードを記憶できるかどうか、記憶したパスワードを暗号化して保存するかどうか、記憶したパスワードに有効期限があるかどうか、およびパスワードが有効期限後にクリアされるかどうか
13. パスワードの強度と複雑さの検証
パフォーマンス ストレス テストのユースケース設計ポイント:
1. シングルユーザーログインの応答時間が要件を満たしているかどうか
2. 同時実行性の高いシナリオでのユーザー ログインの応答時間が要件を満たしているかどうか
3. サーバーのハードウェア リソースが同時実行性の高いシナリオで期待を満たしているかどうか (ネットワーク、ディスク、CPU、メモリのリソース使用率を考慮)
上記のテストポイントの設計漏れもありますが、面接時にこれらのテストポイントを挙げていただければ面接官も満足してもらえると思います！
ソフトウェアテストの典型的な面接の質問
1. テストのキャリア開発は何ですか?
テストの経験が増えるほど、テストの能力は高くなります。したがって、私のキャリア開発には、上級テストエンジニアに向けて一歩ずつ積み重ねる時間が必要です。また、予備的なキャリアプランを立て、最初の 3 年間でテストの経験を積み、優れたテストエンジニアになるための重要なポイントに従って自問し、常に自分自身をアップデートして修正し、テストタスクで良い仕事をします。
2. テスターにはどのような資質が必要だと思いますか?
テストを行うには、テスターは開発者との接触で何らかの問題に対処しなければならないことが多いため、一定の調整能力が必要です。それらがうまく処理されない場合、いくつかの衝突が発生します。そうなると仕事はうまくいきません。また、テスターはある程度の忍耐力を持っている必要があり、テストを行うのは非常に退屈な場合もあります。テスターは忍耐強いだけでなく、起こり得るすべてのエラーを見逃すことはできません。
3. なぜテストができるのですか?
私のテスト技術は未熟ですが、ソフトウェアテストには高い技術が必要なだけでなく、ある程度のコミュニケーション能力も必要なので、まだソフトウェアテストはできると思います。その他の外部要因。総合すると、私はこの仕事に適任だと思います。
4. テストの目的は何ですか?
テストの目的は、ソフトウェア製品のエラーを見つけて、ソフトウェアがユーザーの要件を可能な限り満たすようにすることです。もちろん、ソフトウェア テストですべてのエラーを見つけることは不可能です。
5. テストの段階は何ですか?
一般的に、単体テスト、結合テスト、確認テスト、システムテスト、受け入れテストの 5 つの段階に分かれます。
6. 単体テストのテスト対象、目的、テスト基準、テスト方法 テスト
対象はモジュール内部のプログラムエラーであり、部分モジュールのロジックや機能のエラーや欠陥を除去することが目的です。テストの基礎はモジュールの詳細設計であり、テスト方法はホワイトボックステストです。
7. 残業はどうするのですか?
私は残業についてはあまり意見がありませんが、時間を合理的に調整できれば残業はそれほど多くないと思います。
8. これまでの勉強と職歴を総合して、テストはどのように実施されるべきだと思いますか。
これまでの仕事と勉強の経験から、良い仕事をするためには、まず良好なコミュニケーションが必要だと思います。コミュニケーションがバリアフリーになって初めて、良好なコラボレーションと効率の向上が可能になります。テクノロジーはテストに合格する必要があります。テストを行うには、十分な忍耐力と良い作業習慣が必要です。理解できない場合は、質問し、リアルタイムで同僚とコミュニケーションを取る必要があります。この方法でのみ、良いことを行うことができます。テストでの仕事。
9. なぜソフトウェアテスト業界を選んだのですか
? ソフトウェアテスト業界については以前から知っていたので、その発展の見通しは非常に良いと思いました。
10. これまでの仕事や勉強の経験に基づいて、ソフトウェアの開発とテストのプロセスを説明してください。担当する役割は何ですか。アーキテクト、
開発マネージャー、テスト マネージャー、プログラマー、テスターが必要です。私は主に、割り当てられたモジュールのテストケースの実行を担当しています。
11. ご経験に基づいたソフトウェアのテスト/品質保証についての理解を教えてください
ソフトウェアの品質保証とテストは、ソフトウェア開発段階の仕様とプログラムの内部構造に従って慎重に設計された一連のテスト ケースです。 、入力データと期待される出力結果)、これらのテスト ケースに従ってプログラムを実行して、間違ったプロセスを見つけます。これは、アプリケーションのさまざまな側面をテストして、その機能、言語の有効性、およびレイアウトをチェックすることです。
12. ソフトウェアテストのプロセスとは?
要件調査：システムの概要、アプリケーション分野、ソフトウェア開発サイクル、ソフトウェア開発環境、開発組織、時間調整、機能要件、性能要件、品質要件、テスト要件などを包括的に理解します。システム概要をもとに、プロジェクトにかかる人員・時間・労力の見積もり、およびプロジェクトの見積書を作成します。
予備的なプロジェクト計画を作成します。
テスト準備: テストチームの編成、トレーニング、テストおよび管理環境のセットアップなど。
テスト設計：テスト要件に応じて、テスト項目ごとにテストケースの設計やテストスクリプトの開発などのテスト設計を行います。
テストの実施：テスト計画に従ってテストを実施します。
試験評価：試験結果に応じて試験評価報告書を発行します。
13. SQA の責任と作業活動 (ソフトウェア測定など) について何を理解していますか?
SQA はソフトウェア開発から独立したプロジェクト チームです。ソフトウェア開発プロセスを監視することで、ソフトウェア開発プロセスが指定された CMM 手順に従っていることを確認します (ソフトウェア測定など)。いずれか）対応する CMM 規制）を遵守し、不適合項目に対する提案と改善計画をタイムリーに提出し、必要に応じて問題解決のために上級管理者に報告します。このようにして、欠陥の導入が防止され、その後のソフトウェアのメンテナンスコストが削減されます。SQAの主な業務内容には、SQA作業計画の策定、段階製品のレビューへの参加、プロセス品質、機能構成、物理構成などの監査、プロジェクト開発プロセス中に生成されるデータの測定などが含まれます。
14. ソフトウェア構成管理についての理解について話してください。
プロジェクトの開発プロセス中、構成項目 (各段階の製品を含む) の変更を制御するには、対応する構成管理ツールを使用する必要があります。構成管理の使用は、プロジェクトの規模、複雑さ、リスクのレベル。ソフトウェアが大きくなるほど、構成管理の重要性が増します。構成管理においても、さまざまな構成項目をある段階で組み合わせたベースラインという非常に重要な概念があり、ベースラインは正式な標準を提供し、その後の作業はこの標準に基づいて行われ、許可されたものだけが作成されます。この標準は後でのみ変更できます。構成管理ツールには主に CC、VSS、CVS、SVN などがあります。私は SVN しか使ったことがなく、他のツールについてはあまり詳しくありません。
15. テスト計画とテスト ケースの書き方が
より簡単になります。テスト計画には、詳細なテスト戦略とテスト方法、合理的かつ詳細なリソースの配置などが含まれる必要があります。機能要件）機能点、テスト可能かなどを絞り込みます。
16. 主流のソフトウェア エンジニアリングのアイデア (CMM、CMMI、RUP、XP、PSP、TSP など) の一般的な状況とその理解について話す。 CMM: SW 機能成熟度モデル ソフトウェア機能成熟度モデル、その役割はソフトウェア
プロセスソフトウェアの機能の改善、評価、評価。
CMMI: 能力成熟度モデルの統合 CMMI は、最新のソフトウェア管理手法のほとんどを統合し、同時に SW-CMM モデルの欠陥を補います。
RUP: 合理的統一プロセスはソフトウェア エンジニアリング プロセスです。
XP:エクストリームプログラムとは、極端なプログラミングを意味し、小規模チームのソフトウェア開発に適しており、上記3番目の質問と同様に、プロトタイピング手法と組み合わせて開発プロセスを採用することができます。XP 開発におけるテストの重要性を理解するには、まずテストの概念 (単体テストに重点を置く) を強調します。プログラミングはコードの品質を大幅に向上させることができ、継続的統合は問題を迅速に特定するのに適しています。
PSP と TSP はそれぞれ個別のソフトウェア プロセスとグループ ソフトウェア プロセスです。CMMはやるべきことを教えるだけで、やり方は教えてくれないことは誰もが知っているので、PSP/TSPはCMM導入の過程でやり方を教えてくれます。PSPは個人のスキル（計画の立て方、やり方、やり方）の確立を重視します。品質管理や他者とのコミュニケーション方法、相互協力など）。そして TSP は、高品質のソフトウェア製品の作成と提供 (直面するプロジェクト開発タスクを効果的に計画および管理する方法など) に焦点を当てています。つまり、CMM の導入だけでは決して機能の成熟度を高めることはできず、PSP や TSP の導入と CMM の導入を有機的に組み合わせることでのみ最大限の効果を発揮することができます。したがって、ソフトウェアプロセスフレームワークは、CMM/PSP/TSP を有機的に統合する必要があります。
17. ソフトウェアの品質をどのように保証しますか、つまり、ソフトウェアの品質を最大限に保証するにはどうすればよいですか? テストではソフトウェアの品質を最大限に保証することはできません
。テスト後ではなく、開発と設計を監視する必要があるため、ソフトウェア開発のすべての段階が指定された手順に従って実行されるようにするだけでなく、各段階での製品のレビューやQAのモニタリングを通じても監視する必要があります。プロセスの監査、機能と構成の監査を行い、開発の最適化を実現します。もちろん、テストはソフトウェアの品質を保証する重要な方法でもあり、ソフトウェア品質保証エンジニアリングの重要な部分です。
18. 現在の中国の国情を踏まえると、ほとんどの企業はプロジェクトのスケジュールが厳しく、人員も少なく、要件ドキュメントがないか、非常に不規則な状況にありますが、この状況でソフトウェアの品質はどのように保証されていると思いますか? (ほとんどの企業が最も知りたいと思っていること)このような困難に直面してソフトウェアの品質をどのように確保しますか (これらの企業は一般的にこのような状況にあります - 彼らはあまり投資したくないし、品質を確保したいと考えています) . それはほとんど不可能です
。テストに十分な時間がなく、標準化された文書がないため、テスト要件を十分に絞り込み、的を絞ることができません。したがって、企業の品質保証として、プロジェクトマネージャーは、プロジェクト自体に適合したソフトウェアライフサイクルモデル（RUPの建材、プロトタイプ手法など）を決定し、プロジェクト開発プロセスを明確にし、プロジェクトチームにそれに従って作業するよう促す必要があります。すべてのプロジェクトのチームメンバー (プロジェクトマネージャーがより重要) は、合理的な作業計画を立て、コードの単体テストを強化し、顧客があらかじめ決めた製品納期の範囲内で製品の継続的インテグレーションを実行するなど、時間が許せば、顧客と協力して必要なシステム機能テストを実行できます。
19. テストエンジニアが持つべき資質・スキルとは
1-テストの基礎基礎理論をマスターする
2-ソフトウェアに存在する問題点を見つける姿勢でテストし、うるさいイメージを持たせない
3- 要件仕様書やその他の文書を読むことに熟練している
4- ユーザーの視点から問題を見てみる
5. 高級感が強い
6-慎重かつ責任感のある人
7- (開発者および顧客との) 良好かつ効果的なコミュニケーション
8-以前のテスト経験があり、高リスク領域がどこにあるかをタイムリーかつ正確に判断できる
20. ソフトウェアテストで良い仕事をするためのいくつかの重要なポイント
1. テスターは、テストの基本的な知識と理論に関する適切なトレーニングを受けなければなりません
2- テスターはシステム機能とビジネスに精通している必要があります
3- テストは計画する必要があり、テスト計画はプロジェクト計画全体と調整する必要があります。
4- テスト ケースを作成し、テスト ケースに従ってテスト実行フェーズを実行する必要があります。
5- ユーザビリティ、機能、分岐、境界、パフォーマンスなどの機能要件と非機能要件をテストする必要があります。
6-複雑なプロセスの場合、プロセス分岐、結合条件分析を実行し、その後同値クラス分割を実行して関連するテストデータを準備する必要があります
7- テスト設計の重要な部分は、特定のテスト データを準備し、そのテスト データがどのシナリオまたはブランチであるかを把握することです。
8- 平均して、個人タスクの 3 つのテスト ケースごとに少なくとも 1 つのバグが見つかるはずです。そうでない場合は、テスト ケースの品質が良くないことを意味するだけです。
9- 毎日構築される繰り返しテストを除いて、テストの自動化は検討できますが、それ以外は当面検討すべきではありません。
21. ソフトウェアテスターの資質を育てる
1- まずはソフトウェアテストに興味を持ち、自分に自信を持つ この2点があれば、開発中にどんな困難に遭遇しても、必ずできるようになりますそれらを克服する
2- 疑うのが得意です。実際、絶対的な正しさはありません。間違いは常にあります。私には反抗的な精神があります。他の人が不可能だと思うことでも、私はそれが起こるかもしれないと思います。他の人はそれが正しいと考えていますが、私はそれが正しいと思います正しくない。
3. 釜を割って終わりを告げる精神、一度しか出現しなかったBUGに対して、原因を究明し、解決するまで決して諦めない。
4- 機嫌を良くしてください。そうしないと、テストで良い成績を収めることができない可能性があります。人生における不快な感情を仕事に持ち込まないでください。
5- テストするときは注意してください。すべてのバグが簡単に見つかるわけではありません。これらのバグを見つけるには注意する必要があります。
6- 柔軟に、賢く、バグが発生しやすいサンプルをより多く作成してください。
7- 可能であれば、顧客ともっとコミュニケーションを取りましょう。顧客はあなたが必要とするものを持っています。
8- 顧客の立場に立って、顧客の視点からシステムをテストします。
9. プログラマーに「そんなことはありえない」という言葉であなたを説得させないでください。代わりに、顧客心理において、それはそのようなものではないことをプログラマーに納得させる必要があります。
10. 問題を包括的に検討し、顧客のニーズ、ビジネス プロセス、システム アーキテクチャと組み合わせて問題を検討します。
11- 質問を複雑にしないでください。これは前の点と矛盾します。初心者であれば、最終的にはグループのメンバーによって議論され解決されるため、今のところ心配する必要はありません。
12. 完璧を追求してください。新しいテスターの場合は、完璧を目指してください。それはあなたにとって良いことです。できないこともありますが、試してみてください。
13. ユーモアのセンス、開発チームとの良好なコミュニケーションが鍵です。開発チームのバグキラーを見つけようとするか、「あなたが書いたプログラムに今までバグが見つからなかったなんて信じられない」と開発チームに言ってください。 。
22. なぜチームでテスト作業を行う必要があるのですか?
ソフトウェアの品質をリリース前に知るのは難しいからです ISO 品質認証と同様に、テストにも品質認証が必要です。チームに所属してソフトウェアテストに携わる。テストの過程でソフトウェアの問題が発見され、開発者に通知されて修正され、リリースが近づくとテストレポートからソフトウェアの品質を知ることができます。
23. どのような種類のソフトウェア テストに精通していますか?
テストの種類には、機能テスト、パフォーマンス テスト、インターフェイス テストが含まれます。
機能テストはテスト作業の中で最も大きな割合を占めており、機能テストはブラックボックステストとも呼ばれます。
パフォーマンス テストは、自動テスト ツールを使用して、さまざまな正常、ピーク、および異常な負荷状態をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストします。負荷テストとストレス テストはどちらもパフォーマンス テストであり、組み合わせることができます。
インターフェイス テスト。インターフェイスはソフトウェアとユーザー間の対話の最も直接的な層であり、インターフェイスの品質によってソフトウェアに対するユーザーの第一印象が決まります。
違いは、機能テストでは製品のすべての機能に焦点が当てられ、すべての詳細な機能とあらゆる考えられる機能上の問題が考慮されることです。パフォーマンス テストは主に、マルチユーザーの同時実行下での製品全体の安定性と堅牢性に焦点を当てています。インターフェイスのテストでは、ユーザーが製品を使用するときにその製品を使用したかどうか、理解しやすいか、標準化されているかどうか（ユーザーが意図せずに無効なデータを入力することはもちろん、経験的な性質を考慮すると警告は必要です）など、ユーザーエクスペリエンスに関連する内容に焦点を当てます。あまり失礼にならないように）。特定のパフォーマンス テストを実行するときは、最初に機能ポイントを使用する場合があり、まずその機能が正しいことを確認してから、パフォーマンスの問題を考慮する必要があります。
24. テスト ケース設計で良い仕事をするための鍵は何だと思いますか?
ホワイト ボックス テスト ケース設計の鍵は、少ない使用例でできるだけ多くの内部プログラム ロジック構造をカバーすることです。ブラックボックス テスト ケース設計の鍵は、より少ないユースケースでモジュールの出力インターフェイスと入力インターフェイスをカバーすることでもあります。最小限の使用例で、妥当な時間内に最大限の問題を見つけるために徹底的にテストすることは不可能です。ソフトウェアのブラックボックステストとは、ソフトウェアのインターフェース部分でテストを行うことを指し、テスト対象をブラックボックスとみなして、テスト担当者はプログラムの論理構造や内部特性を全く考慮せず、プログラムの要求仕様に従ってのみ、マニュアルに記載されているとおりにプログラムが機能することを確認します。したがって、ブラック ボックス テストは、機能テストまたはデータ駆動テストとも呼ばれます。ブラック ボックス テストは、主に次の種類のエラーを検出することを目的としています。
1- 間違った機能や欠落している機能はありますか
2- インターフェース上で、入力は正しく受け付けられますか? 正しい結果が出力されます。
3- データ構造のエラーや外部情報（データファイルなど）へのアクセスエラーの有無
4-性能が要求を満たせるかどうか
5- 初期化エラーまたは終了エラーがあるかどうか
ソフトウェアのホワイトボックステストは、ソフトウェアの手順の詳細を詳細に検査することです。この方法では、テスト オブジェクトをオープン ボックスとみなします。これにより、テスターはプログラムの内部論理構造と関連情報を使用して、テスト ケースを設計または選択し、プログラムのすべての論理パスをテストできます。さまざまな時点でプログラムの状態を調べることにより、実際の状態が期待される状態と一致しているかどうかを判断します。したがって、ホワイト ボックス テストは、複合テストまたはロジック駆動テストとも呼ばれます。ホワイトボックステストでは主に次のようなプログラムモジュールをチェックします。
1 - プログラム モジュールのすべての独立した実行パスを少なくとも 1 回テストします。
2- すべての論理的判断について、「真」を取る場合と「偽」を取る場合の 2 つの状況を少なくとも 1 回テストできます。
3- ループの境界内および実行の境界内でループ本体を実行します。
4- 内部データ構造などの妥当性をテストします。
25. 各種テストの意味を詳しく紹介してください
1-単体テスト（モジュールテスト）とは、テスト対象のコードの小さく明確な機能が正しいかどうかを確認するために、開発者が作成した小さなコードのことです。一般に、単体テストは、特定の条件 (またはシナリオ) の下で特定の機能の動作を判断するために使用されます。単体テストはプログラマ自身によって行われ、最終的に恩恵を受けるのはプログラマです。プログラマは関数コードを書く責任があると同時に、自分のコードの単体テストを書く責任もある、と言えます。単体テストは、このコードの動作が期待と一致していることを証明するために実行されます。
2- 統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれます) は、単体テストの論理的な拡張です。最も単純な形式では、テストされる 2 つのユニットが 1 つのコンポーネントに結合され、それらの間のインターフェイスがテストされます。このレベルから、コンポーネントは複数のユニットの統合された集合体を指します。実際のプログラムでは、多くのユニットがコンポーネントに結合され、これらのコンポーネントはプログラムのより大きな部分に集約されます。このアプローチは、フラグメントの組み合わせをテストし、最終的にプロセスを拡張して、モジュールを他のモジュール グループでテストすることです。最後に、プロセスを構成するすべてのモジュールが一緒にテストされます。
3- システムテストは、テスト対象のサブシステムをテスト用の完全なシステムに組み立てることです。システム方式仕様書で規定された機能をシステムが本当に提供できるかを検証する有効な方法です。(共通の共同デバッグ テスト)。システム テストの目的は、最終ソフトウェア システムに対して包括的なテストを実施し、最終ソフトウェア システムが製品要件を満たし、システム設計に従っていることを確認することです。
4- 受け入れテストは、ソフトウェアを展開する前の最後のテスト操作です。受け入れテストの目的は、ソフトウェアが準備が整っており、ユーザーが意図した機能とタスクを実行できる状態にあることを確認することです。受け入れテストは、システムが注文どおりに動作することを将来のユーザーに実証します。統合テストの後、すべてのモジュールが設計に従って完全なソフトウェア システムに組み立てられ、インターフェースのエラーが基本的に排除されたら、ソフトウェアの有効性をさらに検証する必要があります。これが受け入れテストのタスクです。 、つまりソフトウェアの機能と機能であり、パフォーマンスはユーザーが合理的に期待できるとおりです。
26. テスト計画作業の目的は何ですか? テスト計画作業の内容は何ですか? 最も重要なのはどれですか? ソフトウェア テスト計画書は、製品の概要、テスト戦略などのテスト プロセスを知るためのプログラム的な文書です
。 、テスト方法、テスト領域、テスト構成、テストサイクル、テストリソース、テストコミュニケーション、リスク分析など。ソフトウェア テスト計画の助けを借りて、テストに関与するプロジェクト メンバー、特にテスト マネージャーは、テスト タスクとテスト方法を明確にし、テスト実装プロセスでの円滑なコミュニケーションを維持し、テストの進行状況を追跡および管理し、次のような問題に対処することができます。テストプロセスにおけるさまざまな変更。
テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があり、テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースは具体的なものです。テストタスクを完了するための戦術。したがって、最も重要なのはテスト戦略とテスト方法です (最初に復習することが最善です)。
27. テスト計画をうまく進めるための鍵は何だと思いますか?
1- テストの目標を明確にし、テスト計画の実行可能性を高める
ソフトウェア テスト計画を作成する重要な目的は、テスト プロセスでより多くのソフトウェア欠陥を発見できるようにすることです。そのため、ソフトウェア テスト計画の価値は、テスト プロジェクトの管理と潜在的なソフトウェア欠陥の発見に役立つ能力に依存します。したがって、ソフトウェア テスト計画のテスト範囲は機能要件を高度にカバーし、テスト方法は実用的で、テスト ツールは非常に実用的で使いやすく、生成されるテスト結果は正確でなければなりません。
2-「5W」ルールを遵守し、内容とプロセスを明確にする
「5W」ルールとは、「WHAT（何をするか）」「WHY（なぜ行うのか）」「WHEN（いつ行うか）」「WHERE（どこで）」「HOW（どう行うか）」のことを指します。 」。「5W」ルールを使用してソフトウェア テスト計画を作成すると、テスト チームがテストの目的 (WHY) を理解し、テストの範囲と内容 (WHAT) を明確にし、テストの開始日と終了日 (WHEN) を決定するのに役立ちます。 )、テストの方法とツール (HOW) を示し、テスト文書とソフトウェアが保存されている場所 (WHERE) を示します。
3. テスト計画が実際のニーズを満たしていることを確認するために、レビューと更新のメカニズムを採用します。
テスト計画完了後、レビューが行われていない場合は、テストチームに直接送信されますが、テスト計画の内容が不正確であったり、テスト内容が省略されていたり、変更によりテスト範囲が増減する可能性があります。ソフトウェア要件に誤りがあり、テスト計画の内容が時間内に更新されず、テストに誤解を招くことになります。
4- テスト計画を作成し、詳細な仕様、テストケースをそれぞれテストします
詳細なテスト技術指標は独自に作成したテスト詳細仕様書に含める必要があり、テスト チームの実行プロセスの指針となるテスト ケースは独自に作成したテスト ケース文書またはテスト ケース管理データベースに配置する必要があります。テスト計画とテスト仕様およびテスト ケースの間には戦略的および戦術的な関係があり、テスト計画は主にマクロの観点からテスト アクティビティの範囲、方法、リソースの割り当てを計画しますが、テスト仕様とテスト ケースは具体的なものです。テストタスクを完了するための戦術。
28. 開発者がバグではないと言ったら、どう対処しますか?
開発者がバグではないと言ったら、2つの状況があります。1つは、要件が決まっていないので、これを行うことができます。変更が必要かどうかを確認してくれるプロダクトマネージャーを見つけることができます。3者で協議し確認した上で、変更するかどうかを検討します。2つ目は、このような状況は起こり得ないので修正する必要はありませんが、現時点でできる限り最初に言えるのは、バグとは何か、ユーザーによって発見された場合、または何か問題が発生した場合、どうなるかということです。プログラマはさまざまな理由を提示するかもしれませんが、あなたはその説明に反論することができます。それでも動作しない場合は、この問題を提起して開発マネージャーとテストマネージャーに確認します。変更したい場合は変更できます。変更したくない場合は変更しないでください。それ。実際のところ、中には実際にはバグではなく、私が推奨する方法でテスト ドキュメントに書き込んでいるだけであり、開発者が修正しなければ大きな問題は発生しません。それがバグでない場合は、自分の立場を貫き、問題が最終的に確認されるようにしなければなりません。
29. テストの利点は何だと思いますか?
利点は、テストに対する揺るぎない自信と熱意にあり、経験は十分ではありませんが、テストに必要な基礎的なスキルは仕事に活かせると確信しています。
30. システムのボトルネックとは何ですか?
ボトルネックとは主に、ソフトウェアとハードウェア全体で構成されるソフトウェア システムの 1 つまたは複数の側面が、ユーザーの特定のビジネス要件を満たせないことを指します。「特定」とは、ボトルネックが発生することを意味します特定の条件下では、結局のところ、ほとんどのシステムは以前に使用されるからです。
技術的な観点から厳密に言うと、ほとんどのシステムではリソース割り当てが調整されていないため、すべてのシステムにボトルネックが発生します。たとえば、CPU 使用率が 100% に達した時点では、メモリが枯渇しているだけです。したがって、アプリケーションの観点からシステムのボトルネックについて説明します。重要なのは、システムがユーザーのニーズを満たせるかどうかです。ユーザーがシステムを限界まで使用しても、システムの応答は正常であり、システムにボトルネックはないか、ボトルネックがユーザーの作業に影響を与えることはないと考えることができます。
したがって、主に次の 2 つの目的を達成するために、システムのボトルネックをテストします。
- 「表面」のボトルネックの発見。これは主に、ユーザーの操作をシミュレートし、ユーザーがシステムを限界まで使用したときのボトルネックを見つけてボトルネックを解決することであり、これがパフォーマンス テストの基本的な目的です。
- 潜在的なボトルネックを見つけて解決し、システムの長期的な安定性を確保します。主に考慮すべき点は、ユーザーが将来システムを拡張したり、ビジネスが変化したりしたときに、システムがその変化に適応できるかどうかです。ユーザーの現在のニーズを満たすシステムが最適であるわけではなく、システムのソフトウェア ライフ サイクル全体がユーザーの変化に継続的に適応できること、またはシステムを拡張するだけで新しい変化に適応できることをシステム設計の目標としています。
テストを受けている友達が参加してコミュニケーションをとることができ、グループは学習資料や面接の質問、プロジェクトの履歴書などを大量にまとめています。