最初のステップ、UIテストの経験
1.スタイル、スタイル、色、かどうかコーディネート
2.インターフェースのレイアウトがきちんとしている、コーディネート（可能な限り、スクロールバーを使用しないように、確実にするためにすべてのアウトを表示
3.タイトルに記載のインタフェースの動作は、適切な（説明曖昧さ、ノートタイプミスかどうか）です。
4.（同様の機能コントロールは、一緒に動作するように簡単に置く必要はありませんでした）人々の習慣を持つ従来のラインの操作をい
コンプライアンスのためのプロンプトインターフェース（など、英語で表示すべきでないキャンセル、OK、OK中国人は、表示されるべきです）
前記各制御のインターフェースは整列されています
7.日付コントロールが編集可能です
8.制御日付の長さが合理的である、ディスプレイにどちらアウトすべての時間を変更することが可能です
9.クエリ結果リストの列幅は、ラベルは、合理的な説明かどうか、合理的です
10.検索結果のリストが広すぎる横スクロールのヒントではありません
11.長いテキスト情報については、何のテキストボックスが存在しない自動垂直スクロールバーを提供します
12.コントロール簡単なデータ入力です
整理するTabキー、キーシーケンスはサポートされていません13、バウンスしないでください
14.何の申し出関連するホットキーはありません
15.かどうかのプロンプトが正しくコントロールについて説明します
16.モジュールコール統一され、同一のインタフェースを起動するかどうかを同じモジュール
17.ページを移動するには、スクロールバーを使用する場合は、ページが表示され、通常のコントロール
18.正しい日付形式はXXXX-XXXXまたはXXXX-XX-XXXXであるべきである：XX：XX
19ページがあり、余分なボタンやラベルです
20.ウィンドウのタイトル統一か、アイコンメニューバーの
21.ハンドオーバーが正常に最小化されているかどうか、ウィンドウを最大化
22.正常な機能のために、ユーザーが使用できるようになります取扱説明書を読む必要はありません。
23.オペレーショナル・リスクの実装、確認、それと他のヒントを削除
24.操作のシーケンスは合理的です
25.正しさを確認してください：レビューページ、ボタン、テーブル、ヘッダー、フッター、メッセージの形式は、文法のスペルを他の文字があり、文は正しいです。
26.システムは、ユーザの操作、迅速な情報に誤りの前に警告し実行する必要があります。
27.システムチェックにシステム・インターフェースを閲覧解像度のさまざまなページ解像度、親しみやすさをチェックしてください。
28.健全性チェック：削除、更新、追加、キャンセル、背中や他の操作を行った後、ページへの情報バックが合理的である参照してください。
情報の英語版が正確かつ専門的な中国語、英語の翻訳を持つべきではありません：ローカライズされたことによってかどうか29.チェック。
30.凍結灰色の背景
第二段階、機能的完全性試験
1.テスト用のすべてのデフォルト値は、
2.すべての製品マニュアル、ドキュメントのヘルプがテストを通過するコンテンツです
分析を入力します
4.すべての画面が表示され、ロジックをテストするかどうか
5.例外処理
6.敏感な言葉
7.すべてのパスのフローチャートトラバーサルは、要件文書をフローチャート
プログラムの内容は、ポイントの論理的トラバーサルトラバースへのelif他に切り替えた場合
9.インタフェースは、さまざまなコントロールをテストします
第3工程と、ビジネスプロセスのテスト
ビジネスプロセス、データは一般的に複数のモジュールなので、ビジネス・プロセス・テストを必要とする、私たちはまず、多くの場合、問題の傾向がある、各モジュールのテスト、との間で必要なデータ転送に続いて、個々のモジュールの機能の正しさを確認する必要があります場所、テストするためのさまざまな設計データをテストすることを確認してください。
基本的なCRUD機能を有する機能モジュール、以下の試験が必要です。
1.個別機能テスト（削除、問い合わせ、改変、追加）
2. [追加 - >追加 - >（連続増加テスト）を追加
3.増加 - > [削除]
4.増加 - > [削除] - >（同じ内容を削除するために新たに追加）を追加します。
5. [追加] - >編集 - > [削除]
6.修正 - >変更 - >修飾（改変連続試験）
7.修正 - >（新規追加および変更の内容が同じである前に）追加
8. [修正] - > [削除]
9. [修正] - > [削除] - >（同じ内容を削除するために新たに追加）を追加します。
10.削除 - >削除 - >削除（DELETE連続試験）
第四段階、フォールトトレランステスト
1.入力システムは、入力としてデータを許可しません。
関連モジュールまたはサブシステム2は、現在のシステムの影響を確認し、停止します。
3.コンフィギュレーションファイルまたは設定エラーを削除します。
4.データベース射出エラーデータ。
第五の工程、通常の試験
1.ノンストップ運転（7 * 24）、そのメモリリークを確認し、システムリソース他のリークが存在する場合
2.緊急事態がライン上にある場合は、2日に実行夜間や週末を実行することができます。
一般压力很大的情况下，数据库连接数问题、内存泄露问题会曝露的比较快但是死锁可能不能体现，所以要看系统重要性，如12306稳定性则最好7*24小时
第六步、性能测试
1.连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3.压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等
第七步、交互体验测试
1.系统界面的控件是否可以通过tab键遍历，并且顺序合理
2.主要功能的入口和操作是否易于理解
3.界面是否布局合理，功能是否易于查找和使用
4.操作步骤
5.操作习惯
6.有足够的提示信息，且信息文字描述准确
第八步、兼容性测试
包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。
除了上面所说的这些测试以外，还有算法测试、配置测试、安全性测试等等，在工作中不断总结和分析，形成自己的功能测试框架，当你把这份工作做起来以后，对于你自己对于测试团队而言都是一份很有价值的事情，你的测试思路也会变得更全面。
内容来源：https://www.cnblogs.com/seven000/p/7575293.html