软件测试经验谈——5个大于

软件测试经验谈——5个大于

文章版本历程
V1.0  2013-04-10
V1.1  2013-06-15
V1.2  2013-09-23

　　从一名软件实施人员，经过研发人员、需求分析人员、测试人员的历练，一路来到测试主管兼项目主管的位置，实属不易。回首往昔，深觉经历的重要，也感叹实事造就人的真理。既感谢领导，也感谢同事。身为一名从事应用系统软件开发十余载的技术人员，今天相谈一些对于软件测试的感想。

一、计划大于执行
　　这是我第一件感慨的事情。经常见到手下新人对测试充满激情、兴致盎然，拿到测试任务，草草看过需求文档或说明书，一头扎进程序和用例当中里，戏耍个天翻地覆，找bug乐此不疲。但这与真正的软件测试还差得很远，我一问Why？说出都是“与需求相呼、与设计相应”的大道理。其实，他/她不解，我想问的是：需求为何如此？设计为何如此？计划为何如此？用例为何如此？执行为何如此？
　　要回答这些问题，就要知道软件工程的终极目标：完全的控制能力！一个软件从知道意向开始到交付运维，方案、技术、工具、人员、资金、进度所有的一切都受控，才是软件工程的目标。那么，只有在软件工作的所有环节中都贯穿这一思想，整件事情才是受控的，软件测试也不例外。
　　那么如何获得控制能力，就是在进行每项工作时都以那个“戴明环”（PDCA：Plan-Do-Check-Action）为方法论，开展具体工作。这个PDCA就是以计划为开端的，因此所有的执行都应当是计划的遵照、调整、删补，甚至是推翻重建，但是前提是必须有计划作参照。
　　既然计划这么重要，大家就不要以“我发现了多少多少bug”自居了。如果测出的bug都在计划中，而且测试覆盖率计算标准科学，你才算会测试！这时我会说“你是在做测试，而不是在玩测试。”换句话说，在没有计划时，你只是图个新鲜，与小孩子遇到游乐场是一样的，但从某种意义上说（经济结果），在游乐场中的你分明是被设计者玩的。
　　最后，回答一下开始我提的问题。1、需求为何如此？是因为业务背景（使用者、受众、政策、环境）业务范围如此，这些是非常软性的，但又是客观存在，不可违反的（在一定程度上是），这部分是新鲜力量最缺乏，也是最不愿意接触的。2、设计为何如此？因为需求和实现代价如此。需求就不说了，代价是你的团队赖以生存的条件，如果一个软件做10年能达到极高质量，但是人家要2个月交付，你怎么办？让对方等10年吗？所以10年有10年的设计，2个月有2个月的设计，说到底还是需求——隐性需求。3、计划为何如此？因为需求、设计如此。4、用例为何如此？因为计划和软件成品如此，用例必然不能天马行空，“计划给指导，软件来执行”。5、执行为何如此？因为计划、用例和制度如此。很多人都会忽略制度约束，找一些不必要的麻烦。如果你非要在没有权限的情况下验证涉密逻辑或数据，那你不是在测试软件，而是在测试组织制度和领导处罚人的坚定性。这些问题我也只是简要回答，肯定不全面，但原于实践，到底对不对，还请您用实践检验。
　　这些问题回答完后，如果你能自觉地制定计划、执行计划、修订计划，你就开始向真正的测试领域迈进了。

二、覆盖率大于执行效率
　　这是我做具体测试工作的总结。俗话说“治病除根”，而不是“治病除症”。人如果头疼了，是的只吃止疼片，让头不疼呢，还是应当把头疼的原因消除呢？实际上两个都要做，先临时止疼，然后看病除根。“除病根”是长远目标，“止疼”只是短期目标。
　　作为测试工作，测试覆盖率是一个很关键的指标，经常看到一些测试计划中动不动就写覆盖率100%，但是根本不提覆盖率的计算范畴，是需求层面、设计层面，还是代码层面的。如果都考虑全了，这个100%是比较难达到的（尤其是需求层面）。
　　关于覆盖率和执行率的关系，我举个例子。我们要烙芝麻烧饼了，需要准备灶火、饼铛、盆、盘、面粉、油酥、芝麻、盐、水等；覆盖率相当于把每样东西大致检查一遍，虽然不细致，但是如果马上要开始烙烧饼就可以了（可能质量不高），不耽误大事；执行效率相当于在检查芝麻、油酥每种原料时的细致程度和速度，可是如果没有先检查所有的原料齐不齐，就开始挨着粒的查芝麻，我只能说您很可爱了（可能等芝麻查完了，发现没有盐，那可就糗大了）。
　　测试工作也是如此，测试人员应当时刻记着远期目标，操作时关注短期目标。可是很多人，包括我自己在开始做测试时，都是有了短期目标，就完全忽略远期目标，测着测着不知道该干什么了，才想起看看远期目标？这是不好的习惯，而且说明对于将要进行的测试，没有一个清晰的思路和整体目标，业就无法形成你自己的执行策略，总体执行效率必然不高，很有可能要漏掉某些测试方面。

三、记录大于操作
　　我看到的很多研发人员都有一个毛病：急于实现，而不喜欢记录。这一毛病在很多测试人员身上也有，只是出现的形式不同罢了。在一般的开发工具中都会有两个辅助工具：ToDoList和日志。一个是要做什么的记录，一个是做了什么的记录。前一个类似于计划（不过只是给自己看的），后一个类似于操作记录。有了记录保证了很多事情：
　　　　1、计划性——就是给自己一个比较明确的指导，第一部分啰嗦得够多了，不多说了。
　　　　2、描述性——可以通过简单的文字看出要做什么和做了什么，做完这件事本身就是把思路和头绪理清了。
　　　　3、可追溯性——可以在结项一段时间以后，看出自己做了什么（当然看用例也能做到），但有些时候需要查问题，最重要的是自己当时怎么想的，具体怎么操作的，甚至能够想起为什么，这一点是非常重要的。
　　　　4、任务的中止与恢复能力——如果测试项目中止了一段时间，恢复测试项目时，你可以快速地知道做过什么了，该做什么了。
　　　　5、多任务并发能力——有了记录机制，就有了上一种机制，内么任一一个任务都可以方便地中断和恢复。
　　　　6、回顾与总结——文字是人类的宝贵遗产啊！有了回顾的资料，才能总结进步，是吧？
　　说了这么多好处，有什么不好的呢？
　　　　1、麻烦——肯定要写东西嘛，不过这只是因为没有习惯这种方式。
　　　　2、容易忘记火化——年轻人经常闪现“火花”，但是有什么火花非要先试试不可（如果是火烧眉毛或人命关天的事除外），而不能先记下来呢？
　　再多啰嗦一点，这里的记录更重要讲的是“养成思路成文，文字指导、记载的习惯”，大家不要教条于记什么、怎么记、何时记等等的事情，最终要的是通过这种习惯弥补质量控制和记忆力的不足。可能有些东西只是给自己看的，也只有自己才看得懂，有时记事本上的一句话顶得上一周的工作量。

四、再现大于发现
　　发现bug是软件测试的天职，而且发现的越多，说明测试越成功。很多测试人员都在努力锻炼发现bug的能力，的确，这确实是软件测试人员的重要能力之一，但是在发现bug的背后。有一项更重要的能力：bug的可再现性。
　　当然，如果一切都记录的非常完美，环境受控，可以说测试环节没有什么不可再现的。但这是梦想，我们不可能拥有生产环境，也不能掌握所有人的操作习惯、兼容性测试也不可能完整、没有那么多资源准备足够的系统和硬件平台。所有有些问题就是急难再现，那么“发现了不能再现的”bug应当称为问题，几乎不可能修复，至少不能从本质上修复。
　　提出这一点，我是想强调，软件测试人员应当关注测试过程。如果测试人员一味关注测试结果，而忽略机理、过程，那么测试就不是受控的，不是做测试，而是玩测试。很多情况下，只知道按用例执行，而不知道如何设计、分解用例，测试人员的可再现能力就会大大下降。

五、评估大于总结
　　最后这一点是我在接触项目管理后的体会。软件测试项目一般会在结项时给出统计数字，覆盖率、执行时间、bug情况、修复情况、人员情况、工作量计算等等指标。这些指标对于软件能力的度量固然重要，但是企业的项目是鲜货的，这些冰冷的数字只代表历史，是一种客观结果。而项目还要继续“活”下去，那么测试工作就应当为活着做出尽可能多的努力和贡献。
　　通常测试通过后，就是面临着系统上线、客户确认、市场推广等发布环节。测试报告中应当至少“工程实施建议”和“风险评估”方面的建议，并且交给项目经理。其中应当描述诸如：系统在哪些环节还存在问题或不足（可能是短期技术上解决不了的）、工程实施或技术演示时应当注意什么、建议如何规避问题。这种描述应当客观（实际情况）、善意（给出建议），而且应当事先作为一种工作策略与项目组其他人员沟通一下，不要让研发人员认为测试是在宣扬他们的不足，而是要从项目或工程的角度避免项目惹麻烦。
　　当然，测试的核心目标仍然是提高质量，这是不能动摇的，评估并不是让测试为软件质量缺陷找借口，而是要在工作问心无愧的情况下（例如时间不足了），对结果给出一定的评价，帮助项目更好的推进。

六、有感
　　最后，我写了一首小诗表达一下做测试的心情，结束这段感谈。
　　　　　　迷丛乐
千丝万缕乱丛纷，愿作彩蝶探精深。
丛中自有丛中乐，甘苦相缠感最真。
阴阳格物由心起，莫教迷津扰此身。
从来不变应万变，跳出丛中自成神。