测试计划的作用:
1.在测试过程中起指导作用（目标、方法、里程碑的时间……）
2.改善测试任务与测试过程的关系
3.提高测试的组织、规划和管理能力
计划文档中包括：
1.测试项目简介
2.测试项
3.需要测试的特征
4.不需要测试的特征
5.测试的方法 （测试人员、
测试工具、测试流程）
6.测试开始条件和结束条件
7.测试的准入和准出
8.里程碑时间
9.全部挂起、部分挂起条件，及恢复条件
10.测试提交的结果
11.测试环境（软件、硬件、网络）
12.测试者的任务、联系方式与培训
13.测试进度与跟踪方式
14.测试风险与解决方式
15.变更方式
………………………………
（实际中不同的公司详细程度也不相同）
做任何事都必需有个计划
为什么需要测试用例：
1.在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性；
2.测试用例的使用令
软件测试的实施重点突出、目的明确；
3.根据测试用例的多少和执行难度，估算测试
工作量，便于测试项目的时间和资源管理与跟踪；
4.减少回归测试的复杂程度
5.在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
6.功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升；
7.根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报告；
8.可以根据测试用例的执行等级，实施不同级别的测试；
9.为分析软件缺陷和程序模块质量提供依据；
10.便于大型软件测试项目外包测试指导基础；
现实工作中很多时候会遇到这中情况
需求在哪边？开发脑子里！
需求不明确，没有以文档的形式记录下来，不明确，更变态的是1天一小变，3天一大变（夸张了点o(∩_∩)o），在这种情况下用例的作用是什么？说不定花了好久写了一千条用例（1000条用例不算多的，基本一个超过半年的系统在保证测试覆盖率的情况下用例肯定超过4000条），需求一变，六百条需要维护，工作量之大~~~~
OK变了就维护吧~谁知道刚刚维护好，需求又变了，又有400-500条需要维护~~崩溃了吧
所以就取巧了，测试就不按照测试用例来了，monkey test 单纯的靠脑子想到哪边就测试下，我也这样做过，最后结果是测试很盲目；不知道哪些bug是已经提交过的；不知道还有哪些地方没有测试到；有的时候状态好，发现的bug就多一点，状态不好就完蛋了；最主要的是不知道什么时候可以测试结束（本来以为可以结束了，谁知道一兴奋多点了几下，哇靠bug一个个排队出来，后来又一直点到经理说结束才停止了这个噩梦）
现在还没有想到最好的办法解决
个人觉得需求不明确的时候（测试介入比较晚，介入时界面可以看到，软件基本完成），测试人员应该多于开发沟通，因为开发是最了解需求的人。然后开始“玩”软件，慢慢的了解系统，一段时间后针对一些比较稳定的模块进行写用例进行测试。需求还不稳定的，先进行随即测试，找出的bug记录下来，分析原因，找到bug多发点，将一些严重的bug以用例形式记录下来。慢慢模块稳定后，需求不再大变动的时候，开始编写用例，将以前一些问题也写在用例中，bug多发的地方更全面的覆盖到…………具体编写用例方法就不说了
PS:用例最好不要使用word，excel，很难管理很难管理~~~~而且维护起来真TMD难受；密密麻麻的字和蚂蚁一样；不能测试结果的追踪（大问题啊）
还有测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。
