关于“测漏”的那些事……

“测漏” 即缺陷遗漏，对研发团队来说，是个很敏感的话题，每个项目或多或少都会有。如何能尽量避免缺陷遗漏，在研发团队中是最头疼的问题之一。中医讲究望、闻、问、切，由表及里的诊断病症根节所在，而后对症下药，我们也可以逐层的分析导致缺陷遗漏的原因。

就像病症原因可以分为内因和外因，缺陷遗漏的原因也主要分两方面：资源不足和测试不充分。他们往往不是单独出现，一个问题的出现经常伴随着“并发症”，比如需求变更往往是前期需求不明确，没有抓住用户真正的需求。

向身边的测试人员了解到，对于缺陷遗漏的原因，相当大部分的同事认为是公司项目多，测试时间紧，以致开发及测试质量明显下降；也有很大一部分认为是系统业务逻辑复杂，易测性低导致的；当然还有人员流动频繁、政策压力等等......这些原因确实都客观存在，但是我们应该看到，同一个公司内，同样的企业文化之下，依旧有一些团队的缺陷遗漏情况明显要好很多，这说明以上的问题有解药的。

通过观察，结合以往的工作经验，我们总结了如下一些良好做法：

1．无论在什么情况下，测试前的准备工作要做足。参与测试的人员，首先需要了解清楚需求涉及的功能完整的业务流程，用户角色涉及哪些？需求要解决实际的问题是什么？涉及哪些关联系统或者资源？

2．测试计划很关键。依据需求大小可能有口头的、随笔的或者书面正式的测试计划，详细记录各阶段的里程碑。对内是具体工作推进的纲领；对外有利于定期整合，避免扯皮。

3．测试用例的设计是渐进明细的过程。基于测试前的准备工作，能产出一些案例场景，但绝不能就此止步。随着对设计的了解、测试进度的推进，应该随时补充更正测试案例。另外还有检查单、团队评审、交叉测试等方式可供使用。这里需要重点强调一下检查单。在缺陷遗漏这个问题上“历史总是惊人的相似”，统计分析遗漏的缺陷，我们发现只有很小一部分是从未遇到的，因此把犯过的错总结起来建立一个检查单，来避免我们遗忘历史教训是必要的。而这个检查单就可以在团队评审等活动中作为评审依据来使用。

4．尽可能的使用模块化分层测试。业务流程可能很长，“出发久了容易忘记来的方向”。在敏捷开发中，我们强调story拆分的原则是最小的可验证点，测试策略制定的时候同样应遵循这个原则，帮助时刻保持逻辑清晰，并能更快的反馈测试结果，避免测试重点不明或者产生测试重点偏差。

5．定期的汇总测试结果。周期根据测试计划和团队情况决定，可以是每天。汇总参与项目测试的所有人员的进展，讨论下当天的测试情况及缺陷情况，同时确认对应开发人员的跟进情况，有必要时并适时对测试策略进行调整。这一项也是对测试计划的补充，定期监视计划执行情况。

6．注意交叉测试。实际工作中，需求会分配到具体的测试人员，也就是说每个测试人员可能在一个测试循环中专注于一个功能模块的测试，那么在下一个测试循环中应当让其测试不同的功能模块。这样一可以抵御因人员流动带来的风险，二是通过交叉测试缓解测试人员由于审美疲劳产生的缺陷遗漏。

7．每个测试循环的测试完成后，需及时维护测试用例集。测试循环结束后按照功能模块整理测试案例，在下一个测试循环中可以在这个基础上设计案例，一方面节约了测试设计的投入，另一方面降低测试人员“状态不好”的影响，同时也能抵消人员流动带来的影响。

8．自动化测试很重要。明确自动化测试主要是用来评估变化的部分对于不变的部分的影响，作为系统影响分析的一个补充。自动化测试需要随着功能变化持续的维护，对于哪些经常变化的功能点酌情使用，对于不常变化的页面、接口等应该尽可能自动化。

9．缺陷描述需准确。提交缺陷时，提供具体的场景、数据等，减少来回沟通的时间，也避免理解片面导致缺陷未完全修复。

10．缺陷修复需遵守流程。缺陷产生的根本原因、修复方案、影响、验证方案都需要开发、测试甚至其他干系人参与，确保风险可控，修复完成必须验证才能关闭缺陷。因此越是后期发现的缺陷修复成本越高。涉及历史缺陷非本次引入，或者影响较大的缺陷，在团队内部升级评估。

测试循环结束后应组织对本循环内发现的缺陷进行分析。由涉及到的开发、测试甚至需求人员共同参与，讨论为避免缺陷在需求到测试各个阶段的可行方案和投入，并在以后的工作中实施和跟踪。

缺陷之于软件，就如同疾病之于人体。扁鹊和他两个哥哥的故事大家应该都听过，“长兄於病视神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於闾。若扁鹊者，鑱血脉，投毒药，副肌肤，闲而名出闻於诸侯。”对软件质量的控制同样应该贯穿期生命周期的全过程，并且测试活动越是早期介入，软件本身的风险越小。