01 ポジショニング問題の重要性
多くのテスターは、私の義務はバグを見つけることだと言うかもしれませんが、原因を見つけて修正するのは開発の問題です。
私の答えは、テスターとして最も基本的で義務的なことだけをしたい場合は、次のように考えることができるということです。ただし、テストや開発をさらに進めたい場合は、その理由を知る必要があります。
では、なぜポジショニングの問題がそれほど重要なのでしょうか?
1. 問題が本当に「バグ」であるかどうかを明確にすることができます。多くの場合、問題の原因が判明し、それがまったくバグではないことがわかります。原因が特定されると、誤検知が減少します。たとえば、私たちのチームの Damei 氏は、その年に発生した 500 件のバグはどれも無効ではありませんでした。
2. バグの原因を見つけたら、特定の開発者にそれを明確に指摘して、開発者が行ったり来たりするのを防ぎ、バグの修復を迅速化することができます。
3. 開発者があなたを賞賛し、テストに対する開発の信頼を向上させます。
4. このプロセスでは多くのことを学ぶことができ、製品の内部ロジック、アーキテクチャの理解、データ フローの方向を理解するのに役立ちます。ビジネス アーキテクチャのロジックを理解することで、問題の位置付けが促進されます。
5. 不良率を下げることができます。これがおそらく最も重要です。バグシステムでは、開発者にバグの原因を記録するよう求めます。バグをより包括的に理解して初めて、開発と執筆が本当の理由であるかどうかを判断でき、将来のバグの分析と分類にも役立ちます。目標を定めた方法で製品の品質を向上させ、欠陥を減らします。
したがって、位置決めの問題は非常に重要です。
次に、問題を位置付ける方法とテクニックについて説明します。
02 問題の位置付けスキル
まず、位置決め問題には一般的な考え方があり、この考え方はデータの方向性と一致しています。おおよそ次のようになります。
まず、システムにバグが発生した場合には、そのバグ現象を記録し保存する必要があります。保存現象とは、バグが発生したことを証明するものであり、バグが修正され再現されれば問題ありません。シーンを保存する良い習慣
BUG に関しては、やはりテストの専門性を反映する必要があり、タイトルは簡潔で、問題の環境が明確に特定され、問題の詳細が説明され、システム エラーの出現マップ、インターフェイス パラメーターの転送、および参照マップを返し、必要に応じてサーバー ログが投稿されます。要約すると、バグ ラベルが 1 つ減ってはいけません。
1.小物製品の場合、フロントエンドとバックエンドを1人でコーディネート
たとえば、いくつかの小さなプログラムでは、フロント エンドとバック エンドがノード言語と php 言語で開発されていますが、システム全体のフロント エンドとバック エンドが同じ方法で開発されている場合、編集者は、システムの問題、バグを大胆に上げ、突然死 言及、責任者が間違っているはずがない！
2. 従来システム、複数人で共同開発
事前テスト: テスト前に、テスターはシステム、ビジネス、環境展開、開発者などについて精通します。
テスト前に、対応するブラウザの F12 キーを押して新しいタブを直接開くか、パケット キャプチャ ツールなどを使用します。システムに問題がある場合は、対応するリクエストやログ情報などを確認して、問題が発生しているかどうかを完全に特定します。フロントエンド担当者かバックエンド担当者かという問題がある場合、次の一般的な方法を紹介します。
1. 問題のシナリオを分析し、予測を立てる
まずページの外観を確認し、問題の外観に応じて問題の考えられる原因を判断し、範囲を絞り込み、問題を記録するための記録ツールを準備します
システム ページに正常にアクセスできないというプロンプトは、5 の先頭でバックエンドを探し、4 で始まる場合はまずリクエスト アドレスまたは対応するアクセス許可を確認してから、通常どおり開くシステム ページに入り、バックエンドを直接見つけます。異常なコードが間違っているというメッセージが表示された場合
システム ページに入り、異常な画像、ビデオ関連のプロンプト、Flash および Flash をインストールするためのその他の関連情報が表示されます。それでも動作しない場合は、フロント エンドを見つけてください。インターフェイス UI に互換性エラーが表示されます。フロント エンドを見つけてください。
システムアクセスが正常な場合は、操作ページに入り、機能エラーメッセージが報告されます。次に、次のリンクに入り、パケットをキャプチャして、対応するリクエストボディ、ログなどを確認します。
2. リクエストボディのステータスコードに注意してください
4** で始まるステータスコードは、一般的にクライアント（フロントエンド）の問題であり、例えば、一般的な 404 は要求されたアドレスが間違っているかどうかを確認し、403 はアクセス許可があるかどうかを確認します。
5** で始まるステータス コードは通常、サーバー (バックエンド) の問題です。たとえば、一般的な 500 は内部サーバー エラーを示し、503 ネットワーク過負荷によるサーバー遅延、502 サーバー クラッシュなどを示します。詳細については、Baidu を参照してください。
3. リクエストの入力データと参加応答データに注意する
エラーが報告されているページにアクセスし、エラーリクエストのロード時にF12を使用してリクエストパッケージを分析し、対応する入力パラメータと応答データを確認します。
例えば、リクエストの入力パラメータが間違っている場合、そのバグはフロントエンドのエラーに属し、フロントエンドページの入力内容または選択内容、入力パラメータの形式に応じて入力パラメータの規格を検証できます。必要かどうかはインターフェースドキュメントに従って分析するか、開発に確認してください
たとえば、リクエストが応答されない場合、または応答データが間違っている場合、そのバグはバックエンド エラーです。これは通常、特定のテーブル クエリの削除やエラー null ポインタの報告など、データベース ビューによって報告されるエラーです。等
リクエストの入力パラメータや応答データに問題がない場合は、ブラウザの解析の問題かどうかを開発者に報告したり、テストするブラウザを変更したりできます。
4. ログを表示する
サーバータイプのエラーレポートについては、ログプラットフォームにログインするか、サーバーに対応するログディレクトリで印刷されたログを表示できます。
通常、ログ コマンドの末尾を表示するために使用されます。 /error は、キーワード、インターフェイス名、およびその他の関連コンテンツを迅速に取得するために使用されます。
対応するログを取得し、ログ ファイルをバグ リストに貼り付け、バックエンドに割り当てて専門性を向上させます。テスターはログを読む習慣も身に付ける必要があります。ログを見ただけで理解できるようになります。
5. 経験則
Nginxやコードおよび SQL 関連のプロンプト エラー情報など、システムのフロントエンド ページでサーバー構成関連のエラー情報が発生した場合は、 JAVA *、.PHP、SQL などの処理のためにバックエンドに直接移動します。およびその他の異常なエラーレポート
フロントエンドの文字検証、形式検証など、ブラウザ インターフェイスの UI 互換性とプラグイン、または携帯電話の関連機能を呼び出して写真を撮るための APP と小さなプログラム、および音声を正常に呼び出すことができない場合は、直接フロントに移動します。 -終わり
テスターの位置決め問題の n 軸について話しましょう。
1. しばらく弾を飛ばしておきましょう
まず問題を急いで見つけず、まず犯罪現場を保存し、再現できることを確認してください。次に、QA の低レベルの問題を除外します。なぜシーンを保存するのでしょうか? 将来的に再現できない場合は、問題の存在を証明できません。QA の低レベルの質問とは何ですか? よくあるのは、ホストが間違っている、ネットワークに到達できない、操作姿勢が間違っているなどです。これは実際には上記のユーザーレベルの問題であり、ここでのユーザーは QA 担当者です。よく、問題を見つけてすぐに開発者に電話して調べてもらうQA担当者がいますが、このとき開発者は「ホストは正しいですか？」と静かに言います。
もう 1 つのタイプの問題はダーティ データです。サーバーによって 500 エラーが報告されることがあります。ログを確認すると、NULL ポインタが報告されるため、データベース内の関連テーブルのデータが人為的に削除された可能性があります。Fiddler などのツールの影響によって引き起こされる問題もあります。したがって、問題を見つけてもパニックにならず、しばらく弾を飛ばしてから、それが自分の問題ではないことを確認してください。
2. ページのパフォーマンスを視覚的に確認する
これは上記の Web ページの観察です。もはや。
3. ステータスコードを確認します。
4xx ステータス コードは通常、クライアントの問題を示します (もちろん、サーバー構成の問題である可能性もあります)。たとえば、401 が発生した場合は、正しい認証情報がもたらされたかどうかによって決まります。403 が発生した場合は、正しい認証情報がもたらされたかどうかによって決まります。 404 はアクセス許可であり、対応する URL が実際に存在するかどうかによって決まります。
5xx は通常、サーバー側の問題を示します。たとえば、500 エラーが発生した場合は、内部サーバー エラーであることを意味します。このとき、サーバー ログと協力してエラーを見つける必要があります。502 が発生した場合は、サーバーのハングが原因である可能性があります。503 の場合は、サーバーのハングが原因である可能性があります。 504 が発生した場合はネットワークの過負荷が原因である可能性があり、504 が発生した場合はプログラムが原因である可能性があり、実行時間が長すぎるとタイムアウトが発生しました。
4. サーバーログを確認します。
5xx 問題が発生した場合、またはバックエンド インターフェイスによって実行された SQL が正しいかどうかを確認するために、最も一般的なトラブルシューティング方法は、Tomcat ログなどのサーバー ログを確認することです。開発者は通常、問題を見つけるために重要な情報とエラー メッセージを表示します。テスターはログを読む習慣を身につけるべきです。さらに、将来的に開発する場合は、ログを記録する習慣も身につけなければなりません。そうしないと、問題を見つけたときにどこに泣いてよいかわかりません。
5. インターフェースのリクエストとリターン、jsの実行にエラーがないか
ポイント 3 では、ステータス コードの問題について説明し、4xx と 5xx の問題を明確にしました。では、インターフェイスが 200 を返した場合、それは正常なのでしょうか?
ページめくりコントロールをテストする必要がある状況があるとします。2 番目のページに移動すると、コンテンツが最初のページとまったく同じであることがわかり、インターフェイス リクエストは 200 を返します。このときどうやって調べますか？
このとき、フロントエンドから送信されたパラメータが正常であるか、バックエンドから返される内容、つまりインターフェースのリクエストとリターンが正常であるかによって決まります。
ページめくりコントロールの問題を見てみましょう。インターフェイスのリクエストを確認します (ネットワーク リクエストまたはパケット キャプチャ ツールをチェックするための F12 コンソール) 一般に、開発習慣に従って、渡された値が正しいかどうかを確認するための pn および ps パラメータがあります。リクエストパラメータが間違っている場合は、フロントエンドに問題があります。正しい場合は、応答を見て、返されたコンテンツが正しいかどうかを確認し、それがフロントエンドの問題なのかサーバー側の問題なのかを判断します。js の実行でエラーが報告された場合は、クロスドメインの問題など、フロントエンドに問題があることを意味します。
リクエストURLが間違っていればフロントエンドのバグ、渡されたパラメータが間違っていればフロントエンドのバグ、レスポンス内容が間違っていればバックエンドのバグです。応答内容が正しくないバックエンドの問題である場合は、インターフェイスがデータを吐き出すときにエラーが発生しているのか、データベース内のデータが間違っているのか、キャッシュ内のデータが間違っているのか、さらに深く掘り下げる必要があります。 (キャッシュが使用されている場合) は間違っています。一部のバックエンド開発者はインターフェイスを担当し、一部の開発者はデータベースへの書き込みを担当し、一部の開発者はキャッシュの維持を担当することがよくあります。そのため、バックエンドの問題であることが判明した場合は、さらに次のことを行うことができます。どの部分に問題があるのかを確認します。
6. 要件ドキュメントを確認します。
場合によっては、フロントエンドとサーバー間の対話が正しい場合もありますが、テストの観点からは意味がありません。現時点では、要件ドキュメントに目を通す必要があります (そうでない場合は、この質問を直接投げてください)。要件ドキュメントと一致しない場合、それがフロントエンドの変更なのか、サーバー側の変更なのか、あるいはその両方なのか、誰を変更するのが合理的かによって異なります。ここには原則があり、フロントエンドは可能な限りロジックを実行せず、レンダリングと表示のみを担当します。もちろん、要件書がすべて正しいとは思わず、間違いもあるかもしれません。要件書のバグも見つけて、PMと連携してFEやRDに変更を促す必要があります。この点に関して、開発によっては、自分のアイデアがあり、開発中に要件文書の間違いを見つけることもあり、より優れているものと、無条件で無思考に実行される開発があると言わざるを得ません。
7. バックエンド生成ページの問題
バックエンドはページを生成しますが、最も一般的なものは、フロントエンドとバックエンドを分離しない jsp、php、Python に似たフレームワークです。これは特殊であり、1 人で開発したプロジェクトでは一般的です。このプロジェクトのトラブルシューティングは他のプロジェクトと同じです。アイデアは同じですが、フロントエンドとバックエンドのバグの修正は同じ人が担当する可能性があります。
8. 開発はテスト容易性のサポートを提供します
場合によっては、多面的な協力が必要でテストが容易ではない場合、開発はテスト容易性のサポートを提供する必要があります。たとえば、あるインターフェイスから別のインターフェイスに送信されたリクエストが正しいかどうかを確認するには、開発者に完全なリクエスト ログを出力させることができます。ページ データ項目の数を変更するなどの論理スイッチもいくつかあり、それらはすべてテスト容易性サポートのカテゴリに属します。
9. 設定の問題
多くの場合、バグはコードの問題ではなく、Tomcat 設定、nginx 設定、jdbc 設定などの問題です。このレベルでは、テスターがさまざまな構成を理解できることが最善であり、問題を発見した後、この領域の問題を考えることができます。
10. 経験則
太陽の下では新しいことは何もありません、経験豊富な人々はすでに同じ問題に遭遇しています。専門家は多くの場合、表面的な現象の内部問題を一目で見抜き、すぐに主題に取り掛かり、すぐに報告したり解決したりするため、他の人は混乱に巻き込まれます...
11. その他
一般的な構築上の問題が発生する可能性があります。たとえば、コード自体は正しいが、コードをトランクにマージした後に問題が発生する場合です。一般的な問題は、コード内に競合があり、それが手動で解決される場合です。そのため、私はしばらくの間、開発がコードをマージしたときに競合がないかどうかを尋ねるのが好きでした。
さらに、問題を特定した後は、具体的な状況を考慮し、開発者の考え方に基づいて具体的な理由を伝えるかどうかを決定する必要があります。一部の開発者は十分にオープンではなく、あなたが彼の仕事を奪ったと感じるでしょう。オープンな開発に関しては、もっと暗黙的に協力してくれるでしょう。
もちろん、問題を発見したり、問題の原因を特定した後は、問題を再確認するという 1 つのステップを実行する必要があります。いわゆる確認問題とは、問題が毎回発生するのか、確率的な事象なのか、ツール関連の問題なのか（たとえば、別のブラウザではまだ表示されるのか、別のブラウザでは表示されない場合）を調べることです。 、フロントエンドの互換性の問題である可能性があります)。たとえば、ページめくりコントロールについては、テスト対象のシステムの多くのページにページめくりコントロールがあるため、すべてのページでこの問題が発生するかどうかを確認し、バグを報告するときに統一した説明を行う必要があります。開発者にとってバッチ処理に便利で、漏れを防ぎます。
最後に:以下の完全なソフトウェア テスト ビデオ チュートリアルが整理されてアップロードされており、必要な友人はソフトウェア テストのインタビュー文書を自分で入手できます。【保100%免费】
私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は誰もが満足のいく仕事を見つけることができると信じています。
