51Testing软件测试网;}1@#A-Zk$X/r制定测试计划的目的是增强测试团队内部和外部的沟通,统一期望,还有对将要被执行的测试的理解。测试计划(Test Plan)只是制定测试计划过程的一个副产品,并不是制定计划的目的。当然啦,这个测试计划的文档还是相当重要的。不过要提防一种现象 -Shelfware- 那些文档永远都是躺在硬盘里面,没有去人看它。51Testing软件测试网ap9l)n)Fq g3P
51Testing软件测试网Tsm`V%CTest Planning Topics - 测试计划的主题。51Testing软件测试网Lk!c+I'E;j
8AkDc)s
w01.High-Level Expectations - 概要期望。这个问题经常被忽略,因为这个问题实在太明显了,以至于大家都默认其他人都知道了。不过作为一个测试工程师,永远不要去假设。51Testing软件测试网4SE}'?u8WKQ/qE
a.你知道制定测试计划和软件测试计划的目的么?如果你知道的话恭喜你,不过你能保证程序员,经理还有其他相关人等都知道么?还有一个更加重要的问题,他们都同意么?
S {.L,|:J6q0b.什么样的产品会被测试?这个问题真的很幼稚啊,不就是XXXX3.0嘛。我们公司的产品,但是这个产品在什么时候release?是个简单的升级还是改头换面的大变化?是在公司内部完成的还是外包出去了?等等……完全了解一个产品是成功完成任务的关键。51Testing软件测试网6aHa9yE3};_![9I
c.产品的对质量的要求是到哪个水平?不同的人会有不同的要求,但是很多要求都是不可度量的,例如速度快,所以要定义一个被大家所接受的Scope是非常重要的。一定要明确指出测试的目标,而且还要得到大家的同意。这里或许需要有很多人的妥协。51Testing软件测试网v8L]0NB1Z
ahj,m
w/?02.People, Places, and Things - 人力,软件存放位置和硬件设施。人那就不用说了,没人谁来干活啊?这些参与项目的人都需要明确定义,他们是干啥的,怎么联系。尤其是在一个大的项目里面,需要跟踪每个工程师正在干啥,这样才有可能在项目进行的 过程中进行调整。文档放在哪里?被测试的软件在哪里可以下载,这些都是很重要的。如果需要某些硬件,那么这些硬件由谁来负责采购。
E"Z@HMj]R-si
C051Testing软件测试网:m7Q9\(Eqe1n3.Definitions - 清晰定义。很多时候,一些看上去很简单很浅显的东西却没有被定义好的~~例如什么是一个bug?或者说bug的优先级是如果定义的,哪些是重要那些是次要的。所以在计划的过程中,要识别出那些有歧义的名词或者定义,然后对其进行明确的清晰的定义,消除歧义。书中列出了一些比较容易产生歧义的定义:
/qU.A7V+LZ9a+Y0a.Build - 构建。这build也有很多种daily build,weekly build。哪种才是我们测试计划里面说的有效build,还有一个就是build的质量?是不是要通过某个冒烟测试才算是一个被承认的build。
_W*YnPx0b.Test release document (TRD) - 测试产出文档。这个是伴随每个build所附带的文档,一般包含build的状态,这个版本加入了什么新功能,跟以前的差别,修复了那些bug,还有是否为测试做好准备。
4r!bAYL0c.Alpha release - Alpha版本。需要明确Alpha版软件的质量,还有应该分发给哪些用户群进行适用。51Testing软件测试网;l WZ@~b
d.Beta release - beta版本。跟Alpha版相同,还是要看质量和用户群。当然,还有发布的日期。
#?!}GwK0Z0e.Spec complete - 什么时候文档需要完成。这个几乎是设定了也没用,因为变化才是永恒的。不过我们可以制定一个日期,在这个日期之后,这个文档就不允许有大的改动了。
Y9M&YqI
j's0f.Feature complete - 功能完成。在这个日期之后,程序员就不允许再添加新的功能,应该把精力放在修复bug上面。51Testing软件测试网]6^.K,RN4H1]u
g.Bug committee - Bug委员会。由各个经理组成的一个团队,他们决定那些bug是严重的,还有bug的修复优先级等等。
Gc\#F/gr![0on GV"i
u2z#pGf"[04.Inter-Group Responsibilities - 跨部门责任制。很多时候有一些任务是几个不同的部门的同事来负责,而又有一些任务是没有一个特别明显的负责人,到了项目的后期,很可能出现一种情况就是大家都觉得是对方完成了,最终发现谁也没有去做。为了避免这种情况的出现,我们可以制定一个表,上面把所有任务都列出来,然后相关的负责人也在上面,在表上做好特定的标记,标识出每个具体任务的负责人,还有参与者。51Testing软件测试网c?-^z
z;P
51Testing软件测试网5qC
YmGrq-u5.What Will and Won't Be Tested - 分清楚哪些是要测试的哪些是不需要的。51Testing软件测试网6P+c;uy| \v&Z1h
"t"_eQ3`06.Test Phases - 测试阶段。制定测试阶段,假如说现在项目是迭代开发,或者应用瀑布模型,那么测试阶段也可以分好多种。可以有对需求文档进行测试的,对详细设计进程测试的,还有系统测试等等……这里有2个概念是非常重要的:entrance and exit criteria。入口条件和出口条件,测试做到什么样的程度就能结束,或者开发的具体活动到什么样的程度,测试才会介入。51Testing软件测试网$V,nb)JEhz
!N
q]c6V m5~4FL07.Test Strategy - 测试策略。测试策略是定义在测试的过程中会用哪些方法。黑盒白盒?手动自动?选择外包?需要额外购买软件?
F(D$B|T051Testing软件测试网.nU7m/@K~%Q$nY X8.Resource Requirements - 资源要求。People -人!需要多少人哪些人?Equipment - 设备,PC?MAC?打印机?Office and lab space - 这个有点夸张了。Software - 会用到哪些软件?虚拟机?Outsource companies - 外包公司?Miscellaneous supplies - 其他杂项,例如电话、参考书、培训。51Testing软件测试网a ^Rr-C|
51Testing软件测试网OK3D aT*O9.Tester Assignments - 测试员分配。问道有先后,术业有专攻。哪些人具体负责哪项测试需要分配好,而且也需要明确责任。51Testing软件测试网"T!B!a J.KN%_*N[
sr'nDgZnv
Wj#B010.Test Schedule - 测试日程表。对不同的人力资源进行分配。哪些测试在什么时候介入。
rI*tV!`0!Am6PDY011.Test Cases - 测试用例。在计划里面,需要明确谁负责设计测试用例,测试用例在哪里存放,还有什么时候取出来用,还有,测试用例也需要维护。51Testing软件测试网#[y*`!W1p5NF
qU2NeXi!}o2eh012.Bug Reporting - 错误报告。错误报告可以帮助我们对错误的追踪。可以知道我们提交的bug到了什么杨的状态了,是否被修正了。51Testing软件测试网 aV R1y;j9U#avZ
51Testing软件测试网;{\*Y2ln7l13.Metrics and Statistics - 度量和统计。度量和统计能够帮助我们了解项目的进程。书中列举了一些度量的例子:
GGg9[,H:ed0a.Total bugs found daily over the course of the project51Testing软件测试网%]:R'ml3F*D ['Yc6T
b.List of bugs that still need to be fixed
.u
y8k:iBZ#Qha0c.Current bugs ranked by how severe they are
{ n+r2Pon0d.Total bugs found per tester51Testing软件测试网xD(Jr}2L7k
e.Number of bugs found per software feature or area51Testing软件测试网hq-YY J4X
J^*{nY(z/U]014.Risks and Issues - 风险和问题。识别风险在测试计划里面是一个比较有用的工作。识别出风险,做出一些应对风险的准备。尽早识别风险并且解决问题对整个项目是很有好处的,因为我们都知道,修复错误的代价会随着项目的进行而变得越来越高。51Testing软件测试网"cVRg4j1z-H