《软件测试》第十七章 计划测试工作

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

z tRE/ek0z%{V0Test Planning Topics - 测试计划的主题。51Testing软件测试网 y-D9pX8~|

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

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

3.Definitions - 清晰定义。很多时候，一些看上去很简单很浅显的东西却没有被定义好的~~例如什么是一个bug？或者说bug的优先级是如果定义的，哪些是重要那些是次要的。所以在计划的过程中，要识别出那些有歧义的名词或者定义，然后对其进行明确的清晰的定义，消除歧义。书中列出了一些比较容易产生歧义的定义：
ng'fR(n6~0c0a.Build - 构建。这build也有很多种daily build，weekly build。哪种才是我们测试计划里面说的有效build，还有一个就是build的质量？是不是要通过某个冒烟测试才算是一个被承认的build。
Rcqzdd0A+@8u0b.Test release document (TRD) - 测试产出文档。这个是伴随每个build所附带的文档，一般包含build的状态，这个版本加入了什么新功能，跟以前的差别，修复了那些bug，还有是否为测试做好准备。
-U-k&c4RF"Z~JJnF0c.Alpha release - Alpha版本。需要明确Alpha版软件的质量，还有应该分发给哪些用户群进行适用。51Testing软件测试网8wH7r
p{Kt/Bie
d.Beta release - beta版本。跟Alpha版相同，还是要看质量和用户群。当然，还有发布的日期。
4PT$K2o7}e%? {0e.Spec complete - 什么时候文档需要完成。这个几乎是设定了也没用，因为变化才是永恒的。不过我们可以制定一个日期，在这个日期之后，这个文档就不允许有大的改动了。51Testing软件测试网ZQ_~2@-a A2p
f.Feature complete - 功能完成。在这个日期之后，程序员就不允许再添加新的功能，应该把精力放在修复bug上面。
q$[9P#M)kC0g.Bug committee - Bug委员会。由各个经理组成的一个团队，他们决定那些bug是严重的，还有bug的修复优先级等等。51Testing软件测试网fv(T;i@`&L2p

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

k2C6_ y!P}*Yh05.What Will and Won't Be Tested - 分清楚哪些是要测试的哪些是不需要的。

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

x]*w#UWs)y07.Test Strategy - 测试策略。测试策略是定义在测试的过程中会用哪些方法。黑盒白盒？手动自动？选择外包？需要额外购买软件？

s @ u5[;b'|9H&k08.Resource Requirements - 资源要求。People -人！需要多少人哪些人？Equipment - 设备，PC?MAC?打印机？Office and lab space - 这个有点夸张了。Software - 会用到哪些软件？虚拟机？Outsource companies - 外包公司？Miscellaneous supplies - 其他杂项，例如电话、参考书、培训。51Testing软件测试网7L.hO,}2GZu

9.Tester Assignments - 测试员分配。问道有先后，术业有专攻。哪些人具体负责哪项测试需要分配好，而且也需要明确责任。51Testing软件测试网!z kN0v
ba8c

10.Test Schedule - 测试日程表。对不同的人力资源进行分配。哪些测试在什么时候介入。51Testing软件测试网GK#i#d)tB

UN:s#E xk-XH2q011.Test Cases - 测试用例。在计划里面，需要明确谁负责设计测试用例，测试用例在哪里存放，还有什么时候取出来用，还有，测试用例也需要维护。51Testing软件测试网8{7a_8XP1i

t?i n1I012.Bug Reporting - 错误报告。错误报告可以帮助我们对错误的追踪。可以知道我们提交的bug到了什么杨的状态了，是否被修正了。51Testing软件测试网/C1bdm-zq

13.Metrics and Statistics - 度量和统计。度量和统计能够帮助我们了解项目的进程。书中列举了一些度量的例子：51Testing软件测试网
r4z[.h GZQ
a.Total bugs found daily over the course of the project51Testing软件测试网!~\1{s!GC!@I
b.List of bugs that still need to be fixed
"ha4An$d"Ua0c.Current bugs ranked by how severe they are
]:D5K3w"_0d.Total bugs found per tester
5x"n+T*G!@i1as)z3u0e.Number of bugs found per software feature or area51Testing软件测试网"j:m[,Q|

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