《Software Testing》第十七章 – 计划你的测试

制定测试计划的目的是增强测试团队内部和外部的沟通,统一期望,还有对将要被执行的测试的理解。测试计划(Test Plan)只是制定测试计划过程的一个副产品,并不是制定计划的目的。当然啦,这个测试计划的文档还是相当重要的。不过要提防一种现象 – Shelfware – 那些文档永远都是躺在硬盘里面,没有去人看它。

Test Planning Topics – 测试计划的主题。

1.High-Level Expectations – 概要期望。这个问题经常被忽略,因为这个问题实在太明显了,以至于大家都默认其他人都知道了。不过作为一个测试工程师,永远不要去假设。
a.你知道制定测试计划和软件测试计划的目的么?如果你知道的话恭喜你,不过你能保证程序员,经理还有其他相关人等都知道么?还有一个更加重要的问题,他们都同意么?
b.什么样的产品会被测试?这个问题真的很幼稚啊,不就是XXXX3.0嘛。我们公司的产品,但是这个产品在什么时候release?是个简单的升级还是改头换面的大变化?是在公司内部完成的还是外包出去了?等等……完全了解一个产品是成功完成任务的关键。
c.产品的对质量的要求是到哪个水平?不同的人会有不同的要求,但是很多要求都是不可度量的,例如速度快,所以要定义一个被大家所接受的Scope是非常重要的。一定要明确指出测试的目标,而且还要得到大家的同意。这里或许需要有很多人的妥协。

2.People, Places, and Things – 人力,软件存放位置和硬件设施。人那就不用说了,没人谁来干活啊?这些参与项目的人都需要明确定义,他们是干啥的,怎么联系。尤其是在一个大的项目里面,需要跟踪每个工程师正在干啥,这样才有可能在项目进行的 过程中进行调整。文档放在哪里?被测试的软件在哪里可以下载,这些都是很重要的。如果需要某些硬件,那么这些硬件由谁来负责采购。

3.Definitions – 清晰定义。很多时候,一些看上去很简单很浅显的东西却没有被定义好的~~例如什么是一个bug?或者说bug的优先级是如果定义的,哪些是重要那些是次要的。所以在计划的过程中,要识别出那些有歧义的名词或者定义,然后对其进行明确的清晰的定义,消除歧义。书中列出了一些比较容易产生歧义的定义:
a.Build – 构建。这build也有很多种daily build,weekly build。哪种才是我们测试计划里面说的有效build,还有一个就是build的质量?是不是要通过某个冒烟测试才算是一个被承认的build。
b.Test release document (TRD) – 测试产出文档。这个是伴随每个build所附带的文档,一般包含build的状态,这个版本加入了什么新功能,跟以前的差别,修复了那些bug,还有是否为测试做好准备。
c.Alpha release – Alpha版本。需要明确Alpha版软件的质量,还有应该分发给哪些用户群进行适用。
d.Beta release – beta版本。跟Alpha版相同,还是要看质量和用户群。当然,还有发布的日期。
e.Spec complete – 什么时候文档需要完成。这个几乎是设定了也没用,因为变化才是永恒的。不过我们可以制定一个日期,在这个日期之后,这个文档就不允许有大的改动了。
f.Feature complete – 功能完成。在这个日期之后,程序员就不允许再添加新的功能,应该把精力放在修复bug上面。
g.Bug committee – Bug委员会。由各个经理组成的一个团队,他们决定那些bug是严重的,还有bug的修复优先级等等。

4.Inter-Group Responsibilities – 跨部门责任制。很多时候有一些任务是几个不同的部门的同事来负责,而又有一些任务是没有一个特别明显的负责人,到了项目的后期,很可能出现一种情况就是大家都觉得是对方完成了,最终发现谁也没有去做。为了避免这种情况的出现,我们可以制定一个表,上面把所有任务都列出来,然后相关的负责人也在上面,在表上做好特定的标记,标识出每个具体任务的负责人,还有参与者。

5.What Will and Won’t Be Tested – 分清楚哪些是要测试的哪些是不需要的。

6.Test Phases – 测试阶段。制定测试阶段,假如说现在项目是迭代开发,或者应用瀑布模型,那么测试阶段也可以分好多种。可以有对需求文档进行测试的,对详细设计进程测试的,还有系统测试等等……这里有2个概念是非常重要的:entrance and exit criteria。入口条件和出口条件,测试做到什么样的程度就能结束,或者开发的具体活动到什么样的程度,测试才会介入。

7.Test Strategy – 测试策略。测试策略是定义在测试的过程中会用哪些方法。黑盒白盒?手动自动?选择外包?需要额外购买软件?

8.Resource Requirements – 资源要求。People – 人!需要多少人哪些人?Equipment – 设备,PC?MAC?打印机?Office and lab space – 这个有点夸张了。Software – 会用到哪些软件?虚拟机?Outsource companies – 外包公司?Miscellaneous supplies – 其他杂项,例如电话、参考书、培训。

9.Tester Assignments – 测试员分配。问道有先后,术业有专攻。哪些人具体负责哪项测试需要分配好,而且也需要明确责任。

10.Test Schedule – 测试日程表。对不同的人力资源进行分配。哪些测试在什么时候介入。

11.Test Cases – 测试用例。在计划里面,需要明确谁负责设计测试用例,测试用例在哪里存放,还有什么时候取出来用,还有,测试用例也需要维护。

12.Bug Reporting – 错误报告。错误报告可以帮助我们对错误的追踪。可以知道我们提交的bug到了什么杨的状态了,是否被修正了。

13.Metrics and Statistics – 度量和统计。度量和统计能够帮助我们了解项目的进程。书中列举了一些度量的例子:
a.Total bugs found daily over the course of the project
b.List of bugs that still need to be fixed
c.Current bugs ranked by how severe they are
d.Total bugs found per tester
e.Number of bugs found per software feature or area

14.Risks and Issues – 风险和问题。识别风险在测试计划里面是一个比较有用的工作。识别出风险,做出一些应对风险的准备。尽早识别风险并且解决问题对整个项目是很有好处的,因为我们都知道,修复错误的代价会随着项目的进行而变得越来越高。

Leave a Reply

Your email address will not be published. Required fields are marked *