古典的なソフトウェアテストの面接での質問と洞察 - 概念的なテクノロジに関する記事

1. まず自己紹介をお願いします。

まず、面接の最初の質問は自己紹介ですが、ソフトウェアテスト職の自己紹介は、これまでどんな仕事をしてきたのか、どんなスキルを知っているのか、どんな仕事をしているのかという視点からスタートするべきだと個人的には思っています。自分自身については、興味や趣味は二の次であり、テスト作業に関係のない他の話題については言及されません。

例：

こんにちは、インタビュアーさん、このようなインタビューの機会をいただいてとてもうれしいです。私は XX 市出身の XXX です。大学でコンピュータサイエンスを専攻し 5 年間卒業しました。大学 4 年生からソフトウェア会社でインターンをしています。 6 年間のテスト経験があります。この間、私はソフトウェア会社 2 社で働き、その業務範囲には機能テスト、インターフェイステスト、自動テスト、パフォーマンステストなどが含まれます。

最初の会社では、私はインターンとして入社しました。通常の機能テストから始めて、テスト技術文書、テストケースを作成し、機能テストを実行しました。その後、ビジネスニーズによりパフォーマンステストも学びました (ここでは、その他のことを書くことができます)適切な、クローズドループ）スキルを達成し、実際に開発でパフォーマンスの問題を特定するのに役立ち、継続的な作業と学習の結果、3年目に部門マネージャーに昇進しました。

その後、一身上の都合により、○○事業の一種である○○社へ転職しましたが、ここでは非常に成長が早く、前職での経験を積み、継続的に学習し、新しい会社でも上手に活用することができましたシステム展開のための Linux ステートメント、データベース補助機能を操作するための SQL ステートメントの熟練した使用、パフォーマンステスト、インターフェイステストのための Jmeter インターフェイステストツールの使用、パフォーマンステスト、UI 自動化テストのための Selenium+Python モードの使用など。

私自身、業界に取り残されたくない人間なので、仕事や生活以外にも常に新しい知識を学び、時代に遅れないように取り組んでいきたいと思っています。

以上が私の自己紹介となりますが、他にも知りたいことがございましたら、お気軽にお問い合わせください。

2. 前の会社のテストプロセスについて簡単に話してもらえますか?

この質問は私がこれまでに面接した企業から聞かれたもので、あまり多くの企業を面接したわけではありませんが（個人的に仕事探しはまだとても早いです^_^）、これは個人の言語構成能力と仕事をよく反映していると思います。身元確認、経験レベルに関する質問。

例：

私が以前滞在したソフトウェア会社 2 社でも、テストのプロセスは似ていました。基本的には、要件検討会議に参加することから始まります。会議後、おおよそのテスト時間を提示する必要があります。プロダクトマネージャーが要件を更新した後、テストを行います。」会議の後、テスト担当者は、時間、人員、設備、その他のリソースの計画とテスト計画の設計を含むテスト計画の作成を開始します。その後、プロジェクトのテスターがテスト計画の作成を開始します。担当モジュールのテストケース、テスト後のテスト実行、バグ追跡管理、回帰テスト最終的に開始基準を満たした時点で、テスト概要レポートが作成され、関係者全員に電子メールで通知されます。そして企業のWeChat。2 番目の会社がオンラインになった後、特別なオンライン認証を行う必要があります。

3. 良いテストケースとはどのようなものであるべきだと思いますか?

テスターとしては、機能テスト、パフォーマンステスト、インターフェイステスト、自動テスト、セキュリティテストなどを実行しているかどうかにかかわらず、これは避けられない問題です。ユースケースはテストに魂があることを意味しており、それを知っておく必要があります。

例：

テストケースを作成する際の第一原則は、要件を完全にカバーし、要件に厳密に従うことだと思います。

そうすれば、ユースケースを書くという考え方が明確になるはずです。たとえば、合計点合計の考え方がある場合、まずシステムにモジュールがいくつあるか、大きなモジュールごとに小さなモジュールがいくつ含まれているかを分析します。最小のモジュール単位で、すべての関数ポイントを抽出し、ユースケースを 1 つずつ記述し、最後にビジネス関連のすべてのモジュールをプロセステストケースに接続します。

3 点目は、ユースケースの独立性を保つことです。ユースケース間に依存関係があってはなりません。依存関係がある場合には、このユースケースが依存するデータがどのように取得されるのかを前提条件に明確に記述できます。

次に、非常に重要なポイントがいくつかあり、ユースケースのタイトルは明確かつ明確であり、名前も明確であること、ステップが明確で操作可能であること、期待が要件と一致していることです。

また、ユースケースの粒度は中程度にする必要があり、全体のストーリーを 1 つの文で説明したり、詳細になりすぎたりしないでください。

最後に非常に重要なポイントは、ユーザーの視点で問題を考える必要があるということです。要件定義書には明確に記述されていない場合もありますが、自分がユーザーであると仮定した場合、システムをどのように運用しますか?ビジネス上の課題は何ですか? 悪用等の可能性はどうなっているのか。

4. 通常何ラウンドテストしますか? 各ラウンドのテストの焦点は何ですか?

これは決まった答えのない質問なので、面接官が見たいのは試験に対する理解度や実際の業務での取り組み方かもしれません（たぶん）。

例：

私はこれまでに多くのプロジェクトを行ってきましたが、開発リーダーの違いはテストラウンドの数に直接影響します。しかし、要約すると、おそらく 3 ～ 5 ラウンド程度です。

正式試験の前にスモークテストを実施し、主要工程に支障がないことを確認し、一次試験に入ります。

最初のラウンド: すべてのユースケースを実行する必要があり、主要なプロセスはテストに集中する必要があります。

第 2 ラウンド: 最初に最初のラウンドで見つかったバグを返し、実際の修復状況に応じてバグを閉じるか有効にしてから、テストを使用します。

サンプルを再度実行します。(一部の企業は、時間が重要な場合に、問題のある主要プロセスの最初のテストにのみ焦点を当てます)

3 番目のラウンド: 前の 2 つのラウンドですべてのバグを返し、テスト漏れを防ぐためにスキャンテスト用の要件ドキュメント、プロトタイプなどをオープンします。その後、いくつかの互換性テスト、脆弱なネットワーク、切断されたネットワーク、および長期的なテストが行われます。特別なテストを待ち、問題がなければ終了、問題がなければ続行します（バグにより何ラウンドも続く場合があります）。

ビジネスで必要な場合は、インターフェイスとパフォーマンスのテストも実行される場合があります。

春節前などの特別な状況では、パケットテストが行われます。

5. あなたはバグだと思っていますが、開発者はバグではないと考えています。どうすれば解決できますか?

テスト自体も開発者と緊密に連携する必要があるため、この質問もよく聞かれますが、この質問には、テストに対する確固たる立場と原則を持ち、開発者と効果的にコミュニケーションと調整を行う（つまり、コミュニケーションを行わない）必要があります。開発中)、戦ってください...)

例：

まずは要件書を精査してプロダクトマネージャーに確認し、本当にバグであれば要件を理解した上で開発に説明し、プロダクトマネージャーが同意していることを説明します。開発者が承認し、バグを修正する、つまりバグ追跡管理プロセスに入ります。それでも開発者が同意しない場合は、開発者がそれをどのように理解しているのか説明してもらいます。開発者の言うことが合理的であると思う場合は、プロダクトマネージャーにも尋ねます参加して一緒に話し合って、最終的に結論を出すことです。最終的に本当にバグで、開発側が変更しないと判断した場合は、リーダーに説明して対応してもらいますが、対応しない場合はテストレポートに記載します。

6. 社内でテスト書類を書いてもらえますか? あなたは普段どのような書類を書きますか? 書き方？

テストをするにはライティングスキルが必要で、結局ユースケースを書いてバグを書いてドキュメントを書かないといけないのですが、バグを書いても開発側は全く理解できないのでどうすればいいでしょうか？次に、テストでは通常、計画、報告書などの技術文書を作成する必要があり、一部の企業ではユーザーマニュアルなどを作成するためにテストも必要です。

例：

会社ではテストケースやバグなどを書くだけでなく、テスト計画やテストレポートも書く必要があります。

まず第一に、テスト計画は、需要検討会議の後に最終決定する必要があります。会社には対応するテンプレートが用意されており、そこに内容を入力するだけで、プロジェクトの実際の状況に応じて対応する調整を行う必要があります。主に以下のようなものが挙げられます。

テストの目的とテストの範囲。
計画を実施するための役割と責任。
タスクのスケジューリングとリソースの割り当て。
リスク評価と緊急時対応計画。
テストの開始/終了基準。

テストレポートには、主に次のような適用するテンプレートも含まれています。

テストの目的とテストの範囲。
テストのプロセスと結論（テストの回数、問題の数、見つかった問題の数、修復された問題の数、残った問題の数、それらの対処方法など）。
システムが製品要件仕様の記述に完全に準拠しているかどうか。
オンライン標準を満たしているかどうか。
リスクはありますか。

7. あなたの会社のバグレベルはどのように分けられていますか? 根拠はあるのでしょうか？

「これには標準的な答えはありません。私も大まかに同じことを言いたいのです。面接官はあなたが本当に自分の理解を持っていることを知っているはずです。私がそれを暗唱するときは、私の言葉で大まかなアイデアを述べます。」

例：

企業によって分類方法は異なりますが、大きな違いはなく、私たちの以前は、バグは一般的に次の 4 つのレベルに分類されていました。

1) レベル 1: 致命的なバグ

このテストは、システムのクラッシュ、クラッシュ、ブルースクリーン、ハング、またはプログラムの不正終了に直接つながります。
セキュリティ上の欠陥があり、クリックにより重要なデータが失われたり、破損したり、回復できなくなったりします。
主要なモジュールと機能ポイントは実現されていません。

2) レベル 2: 重大なバグ

テスト対象システムの二次機能ポイントが実現されていない、またはセキュリティ要件が実現されていない。
ソフトウェアの特定の機能ポイントにエラーがあると、完全なプロセステストを完了できなくなります (妨害バグ)。
メインインターフェイスには、明らかで影響の大きい UI のバグがあります。

3) レベル 3: 一般的なバグ

期待される結果と矛盾する機能上のバグは、この機能にのみ影響します。
ソフトウェアの対話性が低いと、ユーザーが理解して操作することが困難になります。
より厳しい条件下ではより深刻なバグが発生します。
インターフェースに表示されるテキストなどの説明に誤りがあると、ユーザーの誤解を引き起こします。

4) レベル 4: 思わせぶりなバグ

実際の関数と期待される結果の間には若干の違いがあります。
より厳しい条件下で発生する通常レベルのバグ。
インターフェース、プログラム、プロンプトなどにテキスト記述の問題がありますが、影響は大きくありません。
UI と設計図の間には小さな違いがあります。
プログラムの使いやすさに関する提案、ユーザーエクスペリエンスの最適化に関する提案。

8. 一番印象に残ったバグ

「この質問はちょっとした命題のような気がします。普通の虫は感動するものではありません。悪い結果を引き起こす場合にのみ、印象が大きくなります。人々はつぶやきます、あなたはそのような事故に遭わないでしょう？」。。。それで、何と言えばいいでしょうか? 悲惨な結果を引き起こしたバグに対して全責任を負わない方が良いと思います。このバグの概要について話し合って、進歩を遂げた方が良いと思います。

例：

xxx 社のプロダクトバックグラウンドシステムをテストしていたとき、一度オンラインでバグを報告しました。つまり、プロダクトバックグラウンドのインバウンドとアウトバウンドに関連する機能を修正した後、デマンドテストでは問題なく、関連する問題もありませんでした。モバイル端末の検証。販売機能は直接立ち上げられました。当時、モバイル端末をテストするための特別なテスターがいました。私はバックグラウンド機能のみを担当していましたが、その同僚はその間、別のオフィスエリアにいたため、彼女から依頼を受けましたわかりませんが、プロジェクトが直接立ち上げられたため、製品の背景の変化がフロントエンドの売上に影響を及ぼし、顧客に一定の損失をもたらしました。このバグの最も根本的な原因は、当社の分業メカニズムと情報が同期していないことです。その後、このような状況が今後再び起こらないようにするために、インターフェイス自動化スクリプトを記録しました。新しい需要がオンラインになるたびに、オンラインにする前に、すべての主流ビジネスプロセスのインターフェイスをバックグラウンドとフロントエンドで一度実行して、問題がないことを確認します。

テスト職の面接に行くと、さまざまな質問に遭遇します。古典的な質問に加えて、データベース、Linux コマンド、自動化、Python に関する質問など、特別な基本的な質問もあります。時間があるときにもう少しアップします。