腹腔镜术后肚子胀气:做好测试计划和测试用例的工作的关键是什么？

基本情况描述：

  测试流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导。但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

个人：

留言者1：

      这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。

（一）  先说测试计划吧
      现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写？这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任自流的状态，完全没有受控性。这样的产品质量保证显然是空谈。
      我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。一个好的测试计划是用来计划测试的，用来指导整个测试过程的。

测试计划：就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。

     作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料）。

                  时间就是什么时候做以及要花多久做；

                  资源就是你要调用的人力、机器等资源；

                  范围是你要测试的东西以及测试重点。

       除以上提到的3项之外，比较重要的项目要有测试策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面
a.  上面提到的三要素不能少

b.  测试策略一定要交待清楚，就是大概怎么测试
c.  需要其他人员（部门）协调的，要交待清楚
d.  在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

e.  测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚

f.  测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check

g.  一定要有风险控制，要不然计划缺乏可执行性
h.  计划写完之后不是装在兜里，要组织PM和Dev进行评审
i.  要不断更新计划，记住：每个计划都是动态的，不是一成不变的

（二）  再说测试用例
       和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，下面我就个人体会谈谈做好测试用例的关键。

首先，在做用例之前，要做两件事情。

第一，  透彻了解程序（需求和架构）。
第二，  做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）

一般来说，设计一个比较实用的测试用例，注意如下几个方面：

a.  选用好的用例管理工具（这个很重要，千万不要用word，excel）

b.  用例一定要及时更新（补充新的想法，删除过时的需求）

c.  做好用例分级

d.  做好用例评审，写用例之前可以征询相关人员的意见

e.  可以考虑结对编写，这个是不错的主意

f.  要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

g.  注意把握适当的颗粒度

留言者3：

我不知道lz说的做好测试计划中的“做好”两字具体指的是什么
对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已
所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）
写好测试计划的关键在于：
1 充分了解你的团队的整体实力和团队中每个成员的特点
2 充分理解为当前软件制订的整个研发活动过程
带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。 只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。 否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：
1 有一个合理的测试计划
2 熟悉相关业务
3 深入体会用户的实际需求
这个不想多解释了，不难理解。

至于测试用例
看到上面不少朋友认为关键在于理解用户需求
其实理解用户实际需求是一切的根本
并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切
当然，如果有一份好的需求和设计文档的话，什么事情都解决了。 可是现实往往是不存在这样的文档的。
所以我的看法是：
1 对业务理解的深入程度
2 经验
3 有自己的文档
前两条不解释了。 自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。 这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。 另一个就是自己测试模块对应的相关需求和设计文档。 服务器上的标准文档拖到本地来并且记得及时更新。 然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么……应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。 当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动
项目需要的用例详尽程度可以商量，但是必须要有。 如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差）