序文
今年も卒業シーズンが到来し、インタビューが必要な友人がたくさん来ると思いますが、ここでは、ソフトウェアテストに携わる友人のために、著者がトップレベルのインタビュードキュメントを作成しました。
1. バグとは何ですか? バグはどのようなフィールド (要素) で構成されていますか?
1) コンピュータ システムまたはプログラムに隠れている未発見の欠陥や問題を総称してバグと呼びます。
2) バグはタイトル、前提条件、重大度、優先度、操作手順、期待される結果、実際の結果、バグカットオフで構成されます。
グラフやログなどの構成
2. 前の会社で定められているバグの深刻度はどのようなもので、どのように分類されていますか?
1) バグは 4 つのレベル (致命的、重大、一般、軽度) に分類されます。
2) 致命的な緊急: 通常、メインプロセスが実行できない、システムが実行できない、クラッシュまたは深刻なリソース不足として現れます。
モジュールの起動や異常終了ができなくなり、主要な機能モジュールが使用できなくなります。
深刻な\高い高さ: 通常、次のように現れます: システムの機能または操作に影響を及ぼし、主要な機能に重大な欠陥がありますが、影響はありません
システムの安定性への影響
平均的/中程度の髄膜炎: 通常、次のようなインターフェイス、パフォーマンスの欠陥として現れます: 1. 境界条件下のエラー 2. ビッグデータ
3. 大量のデータ操作には進行状況バーが表示されません。
軽度/低度: 通常、ユーザビリティと提案の問題として現れます。
3. 毎日のバグ作成に関する良い提案は何ですか?
1) バグを再現するために必要な手順が含まれています
2) 説明すべき特別な前提条件がある場合
3) バグが発生したページの関連スクリーンショットを提供した後、バックグラウンドのログ情報
4) 欠陥 (説明) は、開発を中傷したり、開発を批判したりする言葉を含まずに提出されます。
5) 欠陥を提出する際、欠陥に関する質問を含む記述を含めてはなりません
6) 欠陥を期限内に提出する (場合によっては、新人が正式にテストを実行する 1 か月前)
7) 小さな欠陥でも提出してください
4. 物議を醸す欠陥にどう対処するか?
開発により欠陥の状態が解決されないように変更される、設計がそうなっている、外部の理由など。
1) テストケースと要件書に基づいて、不具合かどうか（またはバグだと思われるか）を再度確認する
2) 次に、対応する要件を開発に提示します (開発は、要求担当者が一時的に通知すると言います)
3) 担当の需要担当者に確認し、開発が正しいことが確認できた場合は、問題の理由を記入し、クローズ状態（確認）にします。
要件担当者がテスト部門に通知しなかった)
4) その後、朝礼または勤務時間内に上司に問題を報告する
5. 開発側が変更したくない小さな欠陥にどう対処するか?
1) 小さな欠陥を、変更しないとユーザーにどのような影響があるかなど、もう少し深刻なものにします。
2) 同じタイプの製品を比較する
3) テスト管理ツールに提出する必要がある
6. ランダムな欠陥にどのように対処しますか?
ランダムな欠陥は、テストプロセス中に時々発生するか、または 1 回だけ発生します。
1) ランダムな欠陥はテスト管理ツールに送信する必要があります (バグが見つかったらすぐにスクリーンショットと関連ログを保存する必要があります)。
バグを解決するための証拠や考え方を開発する)
2) バグ発生時の操作手順を思い出し、可能な限り再現してみます。
3) バグ関連モジュールのログ記録の分析と有効化を開発に依頼します。
4) ランダムな欠陥が再発した場合は、開発者に来てもらい、分析のためにマシンをテストさせます (現場を維持します)
7. テスト ケース以外の欠陥にどう対処するか?
テスト プロセスでは同様の状況が数多くあります。
1) バグを送信する
2) ユースケースを保守し、バグの操作手順をテストケースに記述する
8. 繰り返し報告される欠陥にどう対処するか?
1) 開発は欠陥を繰り返しバグとして設定します。
2) テスターが繰り返し発生するバグであることを確認した後、理由を説明してクローズします。
9. 繰り返し欠陥が提出される理由とその解決方法
1) テスト部門の役割分担が明確でないか、クロステストが欠陥ライブラリに焦点を当てておらず、モジュールにテスターの割り当ての一部が交差している
不明瞭な
2) 解決方法: 明確な分業: クロステストの場合、まず問題を文書とともに対応するモジュールの担当者に提出します。
10. 欠陥の状態で、開発とテストに大きな影響を与える欠陥の状態はどれですか?
再オープンは開発に大きな影響を与えますが、問題ではありませんが、テストには大きな影響を与えます
11. フロントエンドの欠陥かバックエンドの欠陥かを区別する方法 (フロントエンドかバックエンドかを特定する方法) 1) バグを見つけた後、フィドラーを使用し
てバグを再現するときに分析のためにパケットをキャプチャする
2) フロントエンドによって送信されたデータが fiddler で正しく表示されない場合、返されるデータも正しくないはずです。
フロントエンド開発のバグ
3) フロントエンドによって送信されたデータがフィドラーで正しく表示されているが、返されたデータが間違っている場合は、バックステージが開いています。
バグ
fiddlerなどのパケットキャプチャツールに加え、バックグラウンドでのログからも判断可能
12. バージョンがオンラインになる前のバグのステータスはどうなっていますか?
クローズまたは延期されています。後者は次のバージョンでテストされる予定です。オープン状態と新しい状態は存在しません。
13. テストを妨げる問題にどう対処しますか?
開発に直ちに問題を解決し、最新のパッチ パッケージを更新するように通知し、開発および修復中に他のテスト タスクがあるかどうかを確認します。
残りを先にやってください。これは通常、音響煙テストの実装には当てはまりません。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト。お役に立てれば幸いです。エンジニア