テストやアプリのテストの間1.web差？
1.1 通常B / Sアーキテクチャ、ブラウザベースのWebプロジェクト、アプリがC / Sである一方で、クライアントが存在する必要があります。
ビューの1.2システムアーキテクチャのポイントは、それから、ウェブがアップデートサーバ限りのテスト、クライアントが更新され同期します。そして、クライアントは、各ユーザーのクライアントのためにまったく同じことが保証されます。しかし、このアプリは、ユーザーがクライアントを更新する場合を除き、まったく同じエンドを保証することはできません。サーバは次のアプリを変更する場合には、手段は、ユーザが使用するクライアントのコアバージョンが再び回帰テストが必要であること。
1.3パフォーマンス、Webページのみが応答時間に焦点を当てることができ、アプリは、トラフィック、電源、CPU、GPU、メモリを心配する必要があります。FPS、メモリリーク、メモリオーバーフロー。
1.4互換性のある用語は、ウェブブラウザベースのは、しかし一般的またはブラウザベースで互換ブラウザとコンピュータハードウェア、コンピュータ・システムの方向である可能性が高いです。互換性のあるブラウザは、通常、別のブラウザカーネルのテスト（IE、クロム、Firefoxの）選択され、現在のWebの互換性テストは、モバイルブラウザで考慮されるべきです。アプリのテストは、電話またはパッドに依存しなければならない、解像度、画面サイズ、だけでなく、機器のシステムに依存していないだけ。全体的なシステムは、AndroidとiOSに分け、あまりにも多くの国内のAndroidシステムのカスタマイズ、だけでなく、問題が発生しやすくなります。実機実マシンをテストし、クラウド・テスト、テストチームを選択する3つのメソッドをテストする一般的なアプリケーションの互換性。まず、主流のモデルを選択し、そして第二に異なる解像度、サイズを選択するために、それは別のオペレーティングシステムです。
1.5ウェブテストと比較すると、アプリが特別なテストの数の詳細です：
1.5.1堅牢性テスト：
いくつかの珍しいシーンや弱いネットワークテストを考えてみましょう。ここではその上の異常中断、通話、テキストメッセージ、シャットダウン、再起動のシーンです。
弱いネットワークテストは、テストアプリケーションのテストを実行する必要があります。これは、弱いネットワークおよびネットワークハンドオーバテストが含まれています。弱いユーザー体験によって引き起こされるネットワークをテストする必要があり、焦点はロールバックし、それが二次リフレッシュが提出原因になりますかどうかを検討する必要があります。パケットロスをテストするためのメカニズムの必要性、遅延を処理します。顧客の損失を避けてください。これらは、弱いネットワークテストのエッセイの前での話されている、私はそれについて話すことはありません。
1.5.2、アンインストール、アップデート：
ウェブテストは、ブラウザベースのそれについて考えていないです。アプリは、インストール、アップデート、アンインストールをテストする必要があり、クライアントです。従来のインストール、アップデートに加えて、アンインストールも考慮に異常な光景を取ります。インストールの中断、弱いネットワーク、アンインストール後にインストールファイルをインストール後、アップデートおよび非更新の更新、増分更新パッケージ、HTTP、弱いネットワーク、削除アプリ関連のファイルを削除、などを含みます。学生が質問やコメントが私にメッセージを与えることができればここでは、その後、多くの発言。
1.5.3インタフェースの操作：
今、ユーザーがマルチタッチ、イベント、テストはジェスチャーに注意を払う必要がありますときに、画面を切り替える必要があった、タッチスクリーン携帯電話を使用して、アプリケーション製品であるテスト領域をトリガするというように。
アプリはappiumいる間に自動化の観点から1.6は、ウェブは、主に、セレン、webdriverを使用します。
使用されるWeb 1.7ツールのパフォーマンスは、アプリのJMeterはもう少し使い、LRあります。
1.8セキュリティテスト、アプリケーション コードのパッケージをコンパイルすることができた場合、パッケージをインストールするには、このような非表示にするには、ユーザー名かどうかなどのように、アクセス権の設定に署名しています。ウェブは懸念、SQLインジェクション、XXLの攻撃です。
1.9境界テスト、SDの欠如、フライトモードなどのアプリのテスト。ウェブあなたはこれらを考慮する必要はありません。
テスト1.10の権限は、アプリの権限は、ユーザーの多くを取得する必要がありますが、Webユーザはに権限の一握りを取得し、上のようにします。
2. POSTとGET HTTPプロトコルの違い
HTTPは、クライアント側とサーバー側の要求と応答の標準（TCP）です。クライアントは、サーバーがサイトで、エンドユーザーです。
指定されたポート（デフォルトポート80）上のサーバにクライアントを開始し、Webブラウザ、ウェブクローラや他のツールを使用することでHTTPリクエスト。
ユーザエージェント（ユーザエージェント）を調整（私たちは、このクライアントを呼び出します）。店舗のリソース（の一部）サーバー応答の
クライアントとサーバーが使用するメッセージの2種類の間の相互作用：リクエスト（要求）とレスポンス（応答）
特定のリソースへのGETリクエスト。
POSTは、指定されたリソース（例えば、ファイル送信フォームまたはアップロード）に要求の処理データを送信します。データは、リクエストボディに含まれています。
POSTリクエストは、新しいリソースにリソースを確立および/または既存の改正をもたらすことができます。
GETは、POSTデータがサーバーに送信され、サーバーからデータを取得することである
GETは、POST高いセキュリティ安全性が低くなります。
（デフォルト値）を取得するURLのフォームの値を通過させ、ポストフォームの値が隠さHTTPパケットボディに渡され、URLは見ることができません。
GETは、データサイズが制限された2キロバイトで提出しました
3.テストでバグを見つけましたが、経営者の開発は、これはあなたが取り組むべきかのバグではないと信じています。
将问题提交到缺陷管理库，类似禅道，进行备案，
根据需求文档，产品说明，设计文档等，确认实际结果是否与计划有不一致的地方，
如果没有文档，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据一般用户的使用习惯，来确认
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
4.如何跟踪线上用户反馈bug？
1.首先收到 bug，确认是否是bug，复现bug
2.确认是bug要对bug进行记录，
3.通知产品，告知开发，商量解决方案
4.协助运维去查看日志
5.解决bug，测试环境验证，集成验证
6.告知用户，体验解决
7.和产品运营等确认是否需要给用户赔偿
8.记录bug处理过程，分析原因，组织相关人员进行回顾
9.思考测试过程中不足，总结经验教训。