这个问题问的非常好,也确实是很多人有过切肤之痛的问题,对我来说,我也一直在苦苦追寻这个问题的答案,现在我不能说完全找到了,只能说把自己的心得分享一下,希望大家的测试计划和测试用例不再是一个摆设。
(一)   先说测试计划吧
        诚如magic_zhu所言,现在很多测试人员没意识到测试计划的重要性,很多时候测试计划成为一纸空文,其根本原因在于测试计划缺乏可执行性,也正是因为测试计划缺乏可执行性,导致下一次写计划的时候非常草率,甚至不写,就算写了也是一个花架子应付领导,这样形成了一个恶性循环,久而久之,测试计划纯属一个摆设,我们很多从业者不写测试计划,其理由是反正写了也不能按照计划执行,这种理由真的很荒唐可笑,这是典型的因噎废食,因为你的计划执行性差就不写?这样只能使测试更加失去控制,使你的测试过程彻底无计划,无目标,变成一个放任主流的状态,完全没有受控性。这样的产品质量保证显然是空谈。
        我觉得这个问题的解决方案不是不写,而是想办法写得更好,更有实效性,执行性。这个是问题的关键。
        一个好的测试计划是用来计划测试的,指导整个测试过程。所以一个好的测试计划一定是可以指导测试的,就是对整个测试过程中的人力,时间,资源,策略,范围的一个说明。
        作为一个测试计划来讲,核心的三个要素是时间,资源,范围。(这句话摘自微软的软件测试培训材料),时间就是什么时候做以及要花多久做,资源就是你要调用的人力、机器等资源,范围是你要测试的东西以及测试重点。
        除以上提到的3项之外,还有比较重要的项目有策略(具体就是怎么测)、风险控制(一旦有问题采取什么应急措施)等项目。
        要把一个计划做得很有实用性,按照笔者的经验,要注意以下几个方面:
a.   上面提到的三要素不能少
b.   测试策略一定要交待清楚,就是大概怎么测试
c.   需要其他人员(部门)协调的,要交待清楚
d.   在估计测试所需的时间、人力及其它资源时,尽量做到客观、准确、留有余地,特别是估计开发时间和debug时间,以及要对自己的执行用例速度,回归速度心里有数
e.   测试计划中每个阶段要明确表明,并且测试阶段的输入、输出文档要清楚
f.   测试计划中的时间段不宜太长(最好以day为单位),太长就比较模糊,不好度量,不好check
g.   一定要有风险控制,要不然计划缺乏可执行性
h.   计划写完之后不是装在兜里,要组织PM和Dev进行评审
i.   要不断更新计划,记住:每个计划都是动态的,不是一成不变的
(二)   再说测试用例
        和测试计划一样,测试用例很多时候也沦为形式,这是软件测试的可悲之处,软件测试的依据就是测试用例,如果用例弃之不用,你凭什么做好测试?这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处,笔者认为还是用例实用性问题,有的时候用例洋洋洒洒数万字,到回归测试的时候根本用不上,至于如何选择回归测试用例,我曾经写过另一篇文章,欢迎查阅。
        下面我就个人体会谈谈做好测试用例的关键。
        首先,在做用例之前,要做两件事情。
        第一,   透彻了解程序(需求和架构)。
        第二,   做一个正式的测试设计(最好文档化)。然后再开始写用例。一般写用例的步骤和建房子一样,先搭框架,然后填材料,填材料的时候,主要根据需求做相关的设计,具体的设计方法就是那几种(郑老的书上写的很清楚)
        一般来说,设计一个比较实用的测试用例,注意如下几个方面:
a.   选用好的用例管理工具(这个很重要,千万不要用word,excel)
b.   用例一定要及时更新(补充新的想法,删除过时的需求)
c.   做好用例分级
d.   做好用例评审,写用例之前可以征询相关人员的意见
e.   可以考虑结对编写,这个是不错的主意
f.   要全面,包括功能、性能、兼容性、安全性、易用性、容错性等等
g.   注意把握适当的颗粒度
        OK,以上是我个人总结的一些心得,希望对您有些帮助,谢谢magic_zhu提这个问题,如果对读者您有些帮助,也不浪费我写到凌晨0点的心血,呵呵~~~~~~~~关于这两个话题太大了,欢迎大家展开讨论!!