软件测试管理

当前位置:首页 > 软件测试管理

《Google软件测试之道》第三章 续1

3.2.1 测试计划


和测试人员相比,开发人员有一个优势就是他们的工作产物是每个人都真正关心的。开发人员编写代码,构建用户期望的、能为公司赚钱的应用。很明显,代码是项目过程中产生的最重要的文档。


然而,测试人员要处理的是真正的文档和其他临时性的事物。在项目的早期阶段,测试人员编写测试计划;然后,他们创建和执行测试用例,编写bug报告;接下来是准备覆盖度报告,收集用户满意度和软件质量数据。在软件成功发布(或失败)之后,很少有人会问及测试产物是什么。如果软件深受人们喜爱,大家就会认为测试所作所为是理所应当的;如果软件很糟糕,人们可能就会质疑测试工作。但其实也没人真正想去了解测试到底做了什么。


测试人员不应该对测试文档过于珍爱。软件开发过程充满了痛苦的挣扎:编码、评审、构建、测试、一轮接一轮的开发等,在这个过程里实在很难有时间坐下来欣赏一下测试计划。糟糕的测试用例不会受到足够的关注和改善,它们只会被抛弃,而最后留下来的是更好的测试用例。大家的关注点集中在不断增长的代码库,这才是最重要的东西,理应如此。


作为一种测试文档,测试计划的生命周期是所有测试产物中最短的(显然,当客户明确要求编写测试计划,或者出于某些政府法规要求,就没这么灵活了。某些场合必须有测试计划并且保持更新)。在项目早期,人们需要一个测试计划(见附录A: Chrome OS测试计划)。事实上,项目经理经常坚持必须有一个测试计划,并将编写测试计划作为一个比较重要的里程碑。但是,一旦计划就绪,这些人就把它扔到一边了,既不评审也不更新。测试计划就像是闹脾气的小孩儿手中可爱的毛绒玩具。我们希望它总是存在,到哪里都能带着它,但却从不真正关注它。只有它被拿走的时候,我们才会发出尖叫。


测试计划是最早出现、最先被遗忘的测试产物。在项目早期,测试计划代表了对软件功能的预期。但是,除非得到持续的关注,它会很快随着新代码的完成、功能特性的改变以及设计的调整而过期。伴随着计划内或计划外的变更,维护一份测试计划是要花费大量精力的,除非多数项目的成员会定期查看,否则测试计划并没有什么价值。



注意:

测试计划是最早出现、最先被遗忘的测试产物。



后面这一点是测试计划真正的杀手:试问在产品的整个生命周期中,测试计划能在多大程度上作为测试活动的指导?测试人员会不断参考计划来安排一个应用的测试吗? 会要求开发人员在功能增加或修改时去更新测试计划吗?在开发经理管理to-do列表的时候,他们会在桌面上打开一份测试计划吗?在进展沟通会议上,测试经理会经常参考测试计划的内容吗?如果测试计划真的重要,那么所有这些事情应该每天都会发生。


理想情况下,测试计划应当在项目执行中发挥核心作用,应当在软件的整个生命周期中持续有效:随着代码库的更新而更新,时刻代表最新的产品功能,而不是停留在项目开始阶段时的样子。它应该可以帮助一个新加入的工程师迅速跟上项目进展。


但是,这些不过都是理想情况而已。在Google或其他公司中,其实很少有测试人员能真正做到。


下面是我们希望测试计划具有的一些特性。


●及时地更新。

●描述了软件的目标和卖点。

●描述了软件的结构、各种组件和功能特性的名称。

●描述了软件的功能和操作简介。


从纯粹测试的角度看,我们担心的是测试计划的投入和价值产出是否匹配。


●不必花过多的时间去撰写,必须随时可以被修改。

●应该描述必测点。

●应该能在测试中提供有用的信息,从而帮助确定进展以及覆盖率上的不足。


在Google,测试计划的历史与我们所经历的其他公司基本相同。测试计划曾经是由各团队根据自身的实际情况自行定义和执行的。一些团队用Google Docs (文本文档和电子表格)编写测试计划,与整个工程团队分享,但不放在中心数据库里;一些团队将测试计划放到产品主页的链接里;一些团队则放到项目的内部Google Sites页面里,或者作为工程设计文档或内部wikis的链接;少数团队甚至使用MicrosoftWord文档,通过电子邮件传播——很老派的方式;一些团队完全没有测试计划。我们只能认为测试用例的总数代表了整个测试计划。


这些测试计划的评审链条是不透明的,很难确定作者和评审者。相当多的测试计划有一个时间和日期戳,非常清楚地表明了它们悠长的被遗忘的历史,就像冰箱角落里酱罐的保质期一样。它一定在某个时间对某个人发挥了重要的作用,但那个时间已经一去不返了。


在Google,曾经流行过为所有产品建立一个中心库和模板的建议。这个有趣的想法曾经在别的公司尝试过,但显然是与Google内在的分布式和自我管理的文化相悖的。在Google,“州权”是常态,而大政府理念会受到嘲弄。


ACC (Attribute Component Capability,即特质、组件、能力。这是一种测试计划的替代方法,参见htp:p/oogletesting.blogspot.com/2011/10/google-test-analytics now-in-open.html)分析是一个从许多Google测试团队的最佳实践中总结出来的,并被本书作者和几位同事在各种产品领域里倡导的流程。ACC已经度过了早期试用阶段,也正被其他公司所采用并有了工具支持,得到了开发者的关注。读者可以用“Google Test Analytics"关键词搜索到这个工具。


ACC的指导原则如下。


●避免散漫的文字,推荐使用简明的列表。并不是所有的测试人员都想当小说家,也不具备将一个产品的目标或测试需求表达成散文的技能。而且,冗词赘句容易误读,只列出要点和事实就行了。


●不必推销。测试计划不是营销文案,既不是要讨论一个产品满足了多么重要的市场定位,也不是讨论这个产品有多么酷的功能。测试计划不是给客户或分析师看的,它的受众人群是工程师。


●简洁。测试计划并没有长度的要求。它不是中学的项目作业,长度无关紧要,不是越长越好。计划的大小与测试问题的规模有关,与作者的写作欲望无关。


●不要把不重要的、无法执行的东西放进测试计划。相关人员毫不关心的东西,就一个词也不要出现。


●渐进式的描述(Make it flow)。测试计划的每个部分应该是前面部分的延伸,以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。如果读者希望了解更多的细节,那么他可以继续读下去。


●指导计划者的思路。一个好的计划过程能帮助计划者思考产品功能及其测试需求,从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。


●最终结果应该是测试用例。在计划完成的时候,它不仅要清楚地描述要做什么样的测试,并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。



注意:

做出一个不直接指导测试的计划纯粹是在浪费时间。



最后一点非常重要:如果测试计划没有把测试用例应该怎么执行描述得足够详细,它就没有达到预先设定的帮助测试的本义。对测试的计划(the planning oftests)而言,它显然应该让我们清楚地知道需要编写哪些测试用例。当你正好处于“完全了解需要编写哪些测试”这一点时,才算完成了测试计划。


ACC通过指导计划者依次考察产品的三个维度达成这个目标:描述产品目标的形容词和副词;确定产品各部分、各特性的名词;描述产品实际做什么的动词。这样,我们通过测试完成的就是验证这些能力(capabilities) 能正常运作、产品各组件(component)能满足应用的目标。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~