首页手记还在为测试文档“难用”烦恼吗？

还在为测试文档“难用”烦恼吗？

标签：

测试

前言

测试文档，作为形式化测试过程的一个重要组成部分，也是我们测试人员最主要的工作输出之一，重要性不言而喻，无论是大型企业还是小微公司。

多数企业中的测试团队会制定出一系列的测试文档模板，这些文档模板可能来源于搜索引擎、某些质量管理体系文件或者其他公司。制定测试文档模板的初衷是当需要编写文档时，测试人员只需要在模板上进行简单的、选择性的修改即可，既能让工作标准更加统一，也可以大大提高编写文档的效率。

事实上，我们常常会在编写测试文档的过程中遇到问题和麻烦，最常见的就是花费大量的时间和精力投入到了填充格式的案头工作中，而最后输出的文档并不具有特别的价值。甚至在某些文档使用一段时间后，由于成本和文档效果的限制，逐渐放弃……最终测试团队进入一种依赖个人发挥的“奇迹式”、“个人英雄主义式”测试管理方式……这种情况很可能导致测试团队进入一种恶性循环：因为文档编写工作没有做好而导致产品质量下降，期望着下一次会把工作做的更好，抱怨这次由于某种原因没有做好，然后继续按以前的方式工作。

究其原因，主要在于我们是否使用了符合公司和项目团队实情的文档和方法。

本文通过分享一些个人的经验，提出有助于大家决定自己需要什么的问题，来帮助大家探索自己的测试文档需求。

经验1：使用文档前先考虑要解决什么问题

这个道理很好懂，就好比医生需要先诊断才会给出意见。

我们需要考虑目前项目团队、测试团队或者当前测试项目中存在哪些问题？其中某个或某些问题是否可以通过编写文档来控制甚至解决？要解决这些问题，除了编写文档，是否还有更好的解决方式？如果需要采用文档，可能会带来什么问题？理论上某类文档可以解决我们的问题，但我们怎么保证最终执行效果能达到我们的预期？

例：

公司要求测试人员每次测试前要编写测试计划和测试用例，但某天接到一个急需上线的需求，此时是否仍然需要编写测试计划和用例？

这个问题，不应只简单的回答是或者否。

仍然需要考虑我们面临的问题：

任务紧急，测试周期短，如果写计划和用例时间上是否来得及？
有没有方法可以缩短编写计划和用例的时间？比如是否可以复用之前的计划和用例？或者使用其他形式来代替传统的文档？
如果不写可能带来什么问题？公司是否有责罚? 测试执行人的能力是否足够胜任无文档指导的工作？测试质量怎么保证？
是否可以后补文档？

总之，如果测试文档被滥用了，一般都是违背了这个原则。先考虑测试文档需要解决的问题，然后再运用一种适合解决方案的形式。

经验2：灵活使用测试文档模板

测试文档模板不能替代技能。

模板用起来很简单—填满所有内容或填空，就会得到自己的文档—但模板的问题是，编写的文档看起来不错但可能内容没有价值或价值很低。因此，为了借助模板来编写好的测试文档，必须理解文档每一部分的含义，理解为什么要有这一部分，每个模块是哪些人在关注，是否可以删除或者什么情况下可以删除。如果不理解这些，就容易受模板的影响，做出“无效”工作。

比如某些计划模板中会有测试环境这一项，我们在参考前需要考虑是否可以删除它？加上这一模块是否对测试人员有指导作用？或者是否能在出质量事故时免责？

很多时候模板使我们测试人员的工作效率下降，其实是因为没有理解模板作者对需求和权衡所做的全面考虑，类似于某个医生看到另一个医生用很先进的配方治疗好了某个病人，然后就把这个配方直接用在了自己病人身上，效果可想而知。

总之，模板有助于更快的写出有效的测试文档，但不能僵硬的套用！我们在测试之前都需要先分析需求，这一点同样适用于文档。决定什么内容要包含到测试文档中，什么内容不包含，应该以项目需要为基础。

经验3：按照分析需求的方式写文档

我们如何来分析团队需要什么样的测试文档呢？可以参考以下问题：

1. 测试小组的使命是什么，测试这个产品的目标是什么？

如果文档不能支撑这样的目标，就没有价值。

2. 自己的测试文档是产品还是工具？

产品是给别人使用的东西，比如需要随产品一起交付给客户。如果文档只是内部工具，则不必太完整、太多要求、太整齐，能在最低限度上有助于达成目标即可。

3. 设计变更有多频繁？

如果很频繁，则不要写太多细节，因为这些细节很快就过时。

4. 反映设计变更的规格书变更有多频繁？