ソフトウェア テストでは、トラブルシューティング (つまり、デバッグ) はテストの成功と密接に関連しています。テストが成功したというサインは、バグが見つかったことです。エラーの兆候に基づいてエラーの原因と正確な場所を特定し、それを修正することは、主にトラブルシューティング手法に依存します。
1. トラブルシューティングのプロセス
トラブルシューティング プロセスは、テスト ケースの実行から始まります. テスト結果が予期した結果と異なる場合、それはエラーの症状があることを意味します. トラブルシューティング プロセスでは、まずエラーの原因を見つけ、次にエラーを修正する必要があります.エラー。したがって、トラブルシューティング プロセスには 2 つの可能性があります. 1 つは、エラーの原因を見つけてエラーを修正することです. もう 1 つは、エラーの原因が不明であることです. 推測が失敗した場合、エラーが発生するまで 2 回目の推測が行われます.見つけて修正。
トラブルシューティングは、開発者の心理的な障害のためだけでなく、プログラムに隠されているエラーには次のような特別な特性があるため、かなり骨の折れるプロセスです。
(1) エラーの外部症状はエラーの内部原因から遠く離れており、これは高度に結合されたプログラム構造にとってより深刻です。
(2) 1 つのエラーを修正すると、別のエラー現象が (一時的に) 消失します。
(3) 一部のエラー症状は単なる幻想です。
(4) オペレーターの一時的な過失によって引き起こされたエラー症状を追跡するのは容易ではありません。
(5) エラーは、プログラムではなく巻き上げ時間によるものでした。
(6) 入力条件を正確に再構成するのが困難です (たとえば、一部のリアルタイム アプリケーションの入力順序が不確実です)。
(7) エラー症状が消えることがあります。この現象は組み込みシステムでは特に一般的です。
(8) 複数の異なるプロセッサで実行するタスクを分散すると、エラーが発生します。
ソフトウェアのトラブルシューティングの過程で、大小さまざまな種類の問題に遭遇する可能性があります. 問題の数が増えるにつれて、トラブルシューティング担当者へのプレッシャーも大きくなります. 過度の緊張により、開発者は 1 つの問題をトラブルシューティングするときに、さらに多くの問題を持ち込むことになります.新しい質問の。
トラブルシューティングは簡単なテクニックではありませんが (技術と呼ぶこともあります)、効果的な方法と戦略がいくつかあります。
2. トラブルシューティング方法
どのようなトラブルシューティング方法を使用しても、目的は 1 つだけです。つまり、エラーの原因を見つけて排除することです。そのためには、トラブルシューティング担当者が直感的な想像力とシステム評価をうまく組み合わせることができる必要があります。
一般的に使用されるトラブルシューティング戦略は、次の 3 つのカテゴリに分類されます。
①プリミティブクラス（総当たり）
②バックトラッキング授業（バックトラッキング）
③除外（原因排除）
元のクラスのトラブルシューティング方法は、最も一般的に使用されている最も効率の悪い方法です. 絶望的な状況でのみ使用されます. 主なアイデアは、「コンピューターでエラーを見つける」ことです. 例えば、メモリやレジスタの内容を出力したり、プログラムに出力文をいくつか並べたりするなど、エラーの手がかりを見つけるために大量の現場情報に頼っていますが、最終的には成功する可能性があります。必然的に多くの時間とエネルギーが必要になります。
バックトラッキングは、プログラムのデバッグにうまく使用できます。その方法は、エラーの兆候からエラーの原因を突き止めるまで、制御フローに沿って手動でトレースバックすることですが、残念ながら、プログラムが大きくなると、可能なトレースバック経路が大幅に増加するため、手動でトレースバックすることはできなくなります。
消去法は帰納法と演繹法に基づいた「分割統治」の考え方を採用しており、まず誤りに関するデータがすべてそろい、その誤りの仮想原因を用いて証明する。またはそれを反駁する; またはすべての考えられる理由を一度にリストし、テストに合格する. それらを1つずつ除外する. あるテスト結果が、ある仮説が浮かび上がったことを示している限り、データはすぐに洗練され、勝利が追求されます。
上記の各方法は、トラブルシューティング ツールで補足できます。現在、デバッグ コンパイラ、ダイナミック デバッガ (「トレーサ」)、自動テスト ケース ジェネレータ、メモリ マップ、クロスアクセス グラフなどの一連のツールが広く使用されています。ただし、完全な設計ドキュメントと明確なソース コードを慎重にレビューおよび精査した後、開発者が果たす役割に取って代わるツールはありません。さらに、トラブルシューティング プロセスで最も貴重なリソースの 1 つである開発チームの他のメンバーの評価とアドバイスを無視してはなりません。 ."
以前に何度も述べたように、古い問題を修正すると、いくつかの新しい問題が発生する可能性があり、プログラムが変更されると、プログラムがより混乱することがありますが、エラーを修正する前に 3 つの質問を自問することができれば、状況は大幅に改善されます。
① このエラーの原因は、プログラムの他の部分にあるのでしょうか?
② この変更は、プログラム内の関連するロジックとデータにどのような影響を与える可能性がありますか? それはどのような問題を引き起こしますか？
③ 前回遭遇した同様の問題を解決するには？
最後に: 以下の完全なソフトウェア テスト ビデオ学習チュートリアルが整理されてアップロードされました。友人は必要に応じて無料で入手できます。【保证100%免费】
これらの資料は、[ソフトウェア テスト] の友人のための最も包括的で完全な準備倉庫である必要があります. この倉庫はまた、最も困難な旅を通して何万人ものテスト エンジニアに同行しています. それがあなたにも役立つことを願っています!
软件测试技术交流群社：786229024（里面还有工作内推机会，毕竟我们是关系社会。）ソフトウェア テスト インタビュー ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません. 次のインタビューの質問は、アリ、テンセント、バイトなどの一流のインターネット企業からの最新のインタビュー資料であり、一部のバイトのボスは信頼できる回答を提供しています. このセットを終了する インタビュー資料誰もが満足のいく仕事を見つけることができると信じています。
面接書類の入手方法：
