1.手動テスト：
全体のプロセスフレームワーク：
テスト戦略 - - 手動テスト - テスト言及フィードバックを送信
評価が必要です。
（1）機能テストと受け入れは、受け入れポイントを確実に初期テスト優先順位にクリアポイント。
（2）実施例に対応する明確で正しい流れを確保します。
テストに言及：
（1）テストを提出し、テスターが言及する計測点のコアコンテンツの全体的なリスクを理解する必要があり、我々は最初の対策は大きなエラーの内容に言及することを確認する必要があり、かつ共同で明確なリスクポイントを開発する必要があるかもしれません。
その後のテストに著者のテストが完了したとき（2）ポイントの優先順位、限られた資源の限られた時間の中で、（クリア後、確認の下で開発することができます）私が認証をクリアしたいものである、明確な受け入れポイントが必要です試験は、次に方向、合理的な配置を示すことができる後に最高と最終リリースバージョンは、上の線によって検証することを敢えてしなければなりません。
テスト戦略：
（1）明示的な受諾ポイントの後にテスト戦略を手配するために、私が取得したい最後のものを - 取得する方法を、あなたは受け入れポイントをクリアしていないとある地点を通過しなければならない場合、そのポリシー、敬意の欠如を手配するもの自然。
（2）テストケースが信頼する必要があり、回避する必要がある明確なユースケースは、メインフローは、改訂さを変更していない、テストのバージョンの後に、ハイレベルではないに明確なテストケースを基本的なテストケースの可用性を確保するために、多くの場合ではありません右はテストが短くなり、十分な明確性とテストケース、明確なより多くのユースケースを飛んでいませんが、量の例が増えを避けるために、（私はそのようなピアレビューとして、明確な修正特定の手順によって測定されるユースケースを保護する必要があります）時間は、私はそれが（現在のユースケースは、貧しい人々の精度と適時性を、統一されたノードを修正する修正する間違った時間であり、そして何のピアレビューはありませんが、この問題の根本的な原因は、新しいユースケースに起因して、プロジェクトサイクルの良性だと思い、助けケース精度を確保するために何も処理が発生しない - プロセスの変形例では無修正の精度こと）を確保します。
（3）テストケースをできるだけ均一に分布試験と関連され、出力テストデータ報告は、適切な段階で、関連するモジュールを必要とします。（実際のプロジェクト、多くの場合、全体の大きなテストモジュールの担当者なので、デフォルトでは、モジュールに関連付けられています）
再現性の存在は（4）の繰り返し操作は慣性を考えて生成する傾向がある手動テストは、、すなわち、テスト戦略の手配がアカウントの人間に取るために、リークテストに自身で適切な方法インテグリティポリシーの受け入れポイントを確保する必要性をもたらす可能性が正確には、1つのミスは経由せずにテストポイントの受け入れにつながっ避けるようにしてください（個人的にこれは困難なテストプロセスであることを感じて、さまざまなシーンやプロセスが、明確な受け入れテストポイントことを条件に、次のことを確認するための措置のセットをターゲットにする必要があります） 、合理的な戦略では、問題は、故障検出されないの受諾ポイントへの個々のリード線のない達成することができますが、ポリシーによって受け入れポイントを発見し、問題を発見していない個人が何らかの責任を取る必要があることで（この点は、自分の心ではありません一時的に1つのアイデアは、それを行う方法は明らかではない。受け入れポイントが受け入れポイントを確保するために、明確であれば、完全に）すべてのテストポイントをカバーし、全体的な制御をしようとすることはできません。
（5）バグの提出および追跡、簡単なバグの説明、ナンセンス。アクセサリー材料は共感がバグソルバーこのバグの問題の彼をクリアし、彼が望んでいた追加情報を取得することが可能であることを明示的にクリア追加する必要があります。バグの解決プロセスは、またポイントを集中する必要があるかもしれない新しいバグを導入するかどうかである、と明確なの発展を追跡する必要性、バグを確認し、私はまだポイントは、これらの主観的な補助的なテストであるテストテストする必要があり、また、明確にする必要がある、つまりトレーサブルトレーサブル。レガシーバグの後、我々は明確なレガシーの理由である必要があり、また、従来のバグを修正し、テストに関連付けられているテスト・ポイントが明確とトレーサブルである必要があります。
（6）ロングフックおよびその他の関連するシナリオをテストするために設計された、個人的に私はちょうど感じで、それがハングアップする時間だと運によって純粋に動作し、これはまだ確認するとハングアップ対象、および追跡責任の明確な部門を開発する必要があると思います。
とき（7）受け入れテスト、受け入れテストポイント、適切な機能を確保するために、元の古いポイントの検査、受け入れテストを防ぐために、対象モジュールのテストデータ報告の手配とモジュールの他のエッジ、食事ブラインドテストステータスに属する人の被験者（しなければなりません受け入れの最終段階を避けるため、このようなモジュールとして、明確な方向のテストとテスト内容は、オーバー行かないだろうし、このような構成に問題がないかどうかを確認）の基本的な動作は、自由に、明確ではありません。
フィードバックを送信：
（1）バージョンは、プロセスから残された遺産に合わせて、それを明確に受け入れポイントあったように、制御点検査トレーサビリティの手配は、バグ修正のプロセスに従って解決することを決議または左、質問を提出した後。同時に、ユースケースを行方不明に行くためにプロセスを変更し、不足しているユースケースかどうかを確認します。
自動テスト：
アプリケーションの基本的なシナリオ：
执行自动化用例 - 输出自动化测试报告 - 分析及问题上报 - 策略安排
自动化用例执行：
（1）明确自动化用例，明确用例库中哪些用例应该被转换为自动化用例，存在一条用例中部分可转，该用例对于手工测试人员来说，应该是未转换成自动化用例，对于自动化用例编写人员来说，仅进行可转部分的转换。新需求用例，基于用例是否明确进行转换，不明确不可靠，不进入自动化用例转换流程。用例转换完毕后，应该要可以直观查看哪些用例已被自动化完全覆盖。
（2）在明确要转的用例之后，用例本身转换外，是否要补充主观测试脚本问题，存在的矛盾是补充主观脚本能增加覆盖范围，但是后期对于脚本的维护会存在时间成本的增加。所以我认为如果自动化脚本要补充主观测试点，那么在这条用例中，应该也是写清楚的，即脚本和用例描述一一对应（如果条件允许，自动化小组单独维护一套测试用例，在用例变更之后，也一定要同步进行脚本维护），如果做不到用例转换内容清晰明了的话，就不进行主观测试点脚本覆盖。
（3）用例兼容性和健壮性问题，当前这方面无明确的流程和技术保证，对于完成的脚本无互审之类的保证措施，个人觉得，在精简性的基础上再保证兼容性和健壮性，减少无本质意义的用例维护时间，不能一味做加法。
报告输出：
（1）通过输出的报告，对手工测试的策略安排有辅助作用，基本相当于模块测试数据报告的输出。如果用例发现bug，自动化测试人员和手工测试人员，应该是均需要对该模块相关联用例的测试数据进行分析，针对性的安排测试补充到测试策略中（如该模块用例在bug修改后重跑，手工人员走bug修改流程）。
（2）验收阶段，进行验收用例自动化脚本执行(个人认为最好是在手工验收之后进行，或者同步进行)，不是明确的验收点，不再进行脚本执行，手工和自动化此阶段需明确分工下，时间充裕的话，优先执行主流程脚本及验收点(执行完毕后，反馈手工人员)，边缘模块放后执行。
策略安排：
（1）自动化脚本执行人员，和手动测试人员不应该是完全区隔开，自动化人员往往对项目当前情况比较不了解，需要手动人员对于自动化测试人员当下要执行的有反馈，如果在时间有限的情况下自动化全覆盖，其实也是没有明确测试点的一种表现（就当前情况而言，我认为自动化测试的职责主要是保障，而非挖掘，只有在保障的基础上，挖掘才有意义，手动人员利用节省的时间进行探索性测试）。