计划测试系列

（六）——事

本计划的上一篇《计划测试系列（五）——时》，是Aaron的软肋，写得很糟糕，但为了保持完整性，Aaron还是贴出来了，看着寥寥几人的访问量，Aaron觉得应该加油写出更好的东西出来。废话少说，开始念叨计划测试系列中关于事的部分。

测试是做什么事的呢？测试是为了……赶紧打住，Aaron指的“事” 是一个测试项目过程中所做的具体的事，不是拿着《软件测试》或者其他的经典来念句子的。按照Aaron自己在上一篇中的理解，软件项目流程或者说一个迭代必定要经过计划实施总结这几个阶段。对于测试来讲我们可以将各个阶段再细分，然后就成了下面这个样子：

制定测试计划

至于计划的作用就不再赘述了，而测试计划作为计划测试活动的结晶，理应受到重视。在实际项目中Aaron发现自己写出来的测试计划这个文档本身意义并不大，至少没有计划测试的过程那般有意义。在很多软件作坊之中，测试计划自一出生便被打入冷宫，测试计划的意义仅仅是作坊主朝自己脸上贴金而使用的一种手段。Aaron推荐的方法是完成一个交差的测试计划后，维护一个名为测试计划实质上更像测试设计（Test Design Spec）的文档，在整个测试执行过程中该文档都起着提纲的作用，而且任何读者都可以通过这份Test Design Spec中了解Aaron对项目测试的想法和测试思路。Aaron在自己所处的项目组中争取到了Test Design Spec的Review机会。Aaron是这样告诉他们的：Aaron担心自己理解错误了PM的意思，Aaron担心自己想的跟Dev不一样，Aaron想先把事情说清楚，所以Aaron要Review。

关于测试计划的内容Aaron在本系列文章的第二篇也聊过——《计划测试系列（二）——测试计划 》。

测试软件需求

软件需求是测试应该覆盖到的地方，这也是为什么很多软件方法提倡测试尽早介入到软件开发进程中的原因之一。对于PM提供的那份Feature列表或者Feature Spec，我们应该抱着怀疑的态度，PM不是项目对象领域的专家，他会犯错，他也会马虎，他也会有脑袋短路的时候，所以这个时侯需要包括测试人员在内的很多项目成员来一起检查这个list或者spec，称之为Review。对于测试人员及其他参与Review的人员应该实现阅读文档并了解项目相关领域的知识。Aaron刚才提到的Test Design Spec的Review工作比较好地完成了任务，当然限于相关业务知识和经验，Test Design Spec的质量会有高有低，Reivew的效果也就可能很不一样。Aaron建议先不断锤炼自己的Test Design Spec之后再提交Review，Aaron自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。

测试用例设计

有关测试用例设计的方法，诸如等价类划分，边界值分析，甚至需求矩阵方法等等，Aaron在这里就不在闲聊，这些东西网络上已有的文档要比Aaron讲的专业的多，更何况这些内容也不是本文的目的所在。

执行测试

主要是指测试用例的执行，但是还应该包括测试用例的更新，还包括bug的提交和管理等等内容。Aaron在周期稍长的迭代中还会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展（以测试用例的数量趋势，分布），还会报告当前的bug相关的信息（Bug总数，趋势，严重bug分布，区域分布等），这些对于帮助项目顺利进行很有帮助。

报告测试结果

Aaron在周期稍长的迭代中会每周发一个Weekly Test Report给项目组成员，帮助他们了解一周来测试工作的进展（以测试用例的数量趋势，分布），还会报告当前的bug相关的信息（Bug总数，趋势，严重bug分布，区域分布等），这些对于帮助项目顺利进行很有帮助。当然，在一个迭代结束或者项目结束之后我们也要提交一个测试报告，这是一份总结性的报告。

安装测试

考虑软件所使用的各种硬软件环境等问题，不仅仅在计划的过程中体现到，还要检查部署文档或者产品说明书中是否包含了安装环境的定义和介绍。

自动化测试

自动化测试的范畴及涉及的内容很多，根据项目组的实际情况引入和实施自动化测试是软件测试发展的趋势。

性能测试

性能测试的范畴又包括了压力测试，负载测试，性能测试（狭义），大容量测试等等，这些都要根据实际需求加以取舍和安排，并在计划中体现出来。

更新（软件变更）测试

主要指版本的升级测试，尤其对于产品性质的软件更应该注意这方面的问题。

测试工作本身还包括了其他很多内容，Failover和Switchover测试等等很多内容都需要考虑，有时候还要对软件的逻辑关系，软件的物理关系进行测试，还有更常见的界面测试，可用性测试，验收测试等。这些测试及测试程度的取舍则取决与项目实际情况（时间，成本等等）以及测试人员个人的经验等等。

（七）——我们什么时候停止？

我们什么时候停止我们的项目？我们应该在我们达到目标的时候停止。可是，目标是什么？Aaron认为所谓目标，即测试应该实现的可度量的要求，这个东西更常见的叫法——测试停止标准。

不知道有没有程序员会笑话Aaron说：我们项目就是一个测试人员在点点，甚至不要测试人员点点我们也可以顺利交付给客户很有用的产品；不知道有没有测试人员会讲：我们测试的时候除了用例之外什么都没有，更不用说什么无聊的测试停止标准 =! 不过Aaron告诉你，真要在项目里面有了这么个东西，只会对大家都好。你想，测试停止标准就是那可以止渴的“梅”，有了它咱就有了奋斗的方向，有了等到出头之日的盼头。同时因为一些项目组中测试标准也会作为版本发布标准——尽管这两者还是有区别的——所以测试停止标准对于开发人员和PM也是有用的。

当然，并不是所有的测试停止标准都会有这般功效，在Aaron看来，一个合格的测试停止标准应该满足一下条件：

在计划阶段尽早订立测试停止标准

没有规矩不成方圆，先定下规矩可以帮助我们一开始就计划的时候就在画着“方圆”，而不是等画了一点点之后才发现用的“规矩”不是标准版的，那样浪费了时间。

测试停止标准应该获得项目负责人的确认

这一条尤其适用于并不是那么和谐的项目组以及习惯优柔寡断的项目负责人领导的项目组。还要注意口说无凭，所以立字为据有时候也是需要的~我们的目的是要使规矩“定”下来。

对于这一条，存在这两个风险：

一是容易导致不和谐：如果项目负责人签了，感觉像是兄弟们在给他上枷锁似的，更像是把一些责任推到他的身上去了。（因为存在这样一种情况，大家订立一个规矩，可是后来做的东西让top leader不满意，普通组员这个时候好歹还可以推说我们组的规矩是这样做的，不需要问，当时签字确认的项目负责人这下子责任就大了。）

二是因为需求变化，因为测试停止标准要求满足可度量性（具体内容在后文详谈），所以可能会涉及到比较细致的东西，比如某个核心模块应该怎么样才算行——如果在后期需求变了，会不得不更改“定”下来的测试停止标准了。

对于这些风险的预防和处理，Aaron虽然有些心得，但是考虑到各个作坊情况不一样，Aaron就不误导各位了。

测试停止标准应该是可度量的

Aaron看来，对于测试停止标准，“可度量”这个要求是必需的，用抽象的语言来描述测试停止标准是无意义的。如在测试停止标准里面出现“在适当的时间停止测试”这句话是不对的，所谓“合适的时间”这类词汇，要么让人不解其意，要么出现“一千个观众眼中有一千个哈姆莱特”这种情况，因此一个准确的定义是必需的。

测试停止标准都是可以达到的

这个很容易理解，如果标准里面出现了要我们三五个人十来杆抢在一个月内造一个跟windows Xp一模一样的操作系统给客户，那定这个标准的人怕是跟Aaron前天一样SB了~测试停止标准之中切忌出现不可能实现的或者很难达到的目标，比如在测试停止标准里面出现“修复所有的bug”这种条文，我们就要考虑实际情况中我们是否可能修复所有的bug，项目的要求是否如此严格——所有的bug都必须修复，而不是被处理（修复，延迟并报告等处理方式），是否允许部分bug推迟修复？

测试停止标准的检查者

测试停止标准作为一个验收标准，还需要明确规定标准执法者。没有规矩不成方圆，但是有了规矩而不执行，也是成不了“方圆”的，所以需要执法者或者说护法者，在这里体现为检查和核实我们的测试是否达到了标准。有时候，为了表示民主，大家一起说了算在人数不多的项目组也是一个可取的方式。

Aaron讲了自己的一些理解，但看着过于抽象，所以就继续具体点讲一下。开发人员贴code，Aaron这边没Code，只好贴几张便签纸

上面几张便签来自网络和个人实践，Aaron只是摘选部分，切不可直接拿来作模板，否则就是Aaron的误人子弟的罪过了~这几张便签纸并不能直接帮助读者建立起一个适合自己项目的“测试停止标准”，因为Aaron相信大家的能力。Aaron将测试停止标准扯到计划测试系列的目的，是要提醒读者在计划的时候就要有看到我们的结果的眼光。项目也好，测试过程也好，都是以结果为导向的，没有最后的成功，中间过程即使很完美，对于项目（产品）自身是没有任何意义的（大多数情况下，项目成员在吞食失败的挫折感的同时，至少还收获了经验，所以可能还会有人会享受失败项目中的“美好的过程”）。

文章来源于领测软件测试网 https://www.ltesting.net/