白话软件测试二

前一节介绍了什么是软件测试，如何进行软件测试。但是，软件测试不是一个孤立事件，它必须与其它部门（RD、PM、产品部、甚至客户等）进行交流。我们所有人都知道，人是一个群体动物，许多伟大的工程和项目都需要集体的力量才能实现，而管理是否有效往往决定着项目的成败。这章节，我将从实际经验中分析，哪些环节不当会导致项目的延期甚至失败。

一、测试语言

只要有沟通和交流就必须得先制定一套语言标准出来，这样大家才能有交流的基础。

而测试流程和测试规范正是软件测试人员与其它干系部门交流的语言，即，让别人知道你干了什么，干的怎么样，接着准备干什么，预计会干出什么来等等。

测试流程上，大家都基于一个需求输入进行分析，分别输出研发和测试计划，然后，研发输出设计文档，测试参考需求和设计文档编写测试用例，执行测试用例，研发修复缺陷，测试回归，最后输出测试报告。多么简单、有序、美好的愿景！

测试可能还会进一步细分出功能、性能、场景等等测试，证明产品在的各个方面都在测试验证考虑范围内。

现实真的如此的美好？我只能说depend：时间和人力资源！而这两个正好又都是最为昂贵的资源。因而，每一个公司苦苦挣扎的，正是如何控制好这两个资源的损耗，所以才会有尽信书不如无书这一说：哥也在江湖飘过，为啥江湖上没有哥的传说？因为哥一出门就中了菜刀-------江湖人都不讲究，不按套路出牌啊！

二、深渊

项目的某一个环节上出现问题，都会导致团队，甚至整个公司陷入无法自拔的深渊中，进退不得。要说规避的办法，随口就可以写一篇宏篇大论，但是这些真的能帮到坠入深渊的你吗？也许！真正能帮助的你的，可能就是多看、多听、勤思、小心慎行而已。

• 真假需求

曾经有一个项目，耗费了60个人月的资源进行开发测试，结果研发成果只能束之高阁，无人问津。其原因就是产品经理在没有实际调研的情况下，设想出一个功能以解决一个特定场景下的需求，强行推动，最后预期的客户并不满意，导致项目失败。

由此而来的反思是，需求的评审需要适当的推行民主，并要考虑失败后的应对策略。当然，可行性分析也是一个很好的风险规避策略，只是针对需求的规模、时间要求、资源要求等需要有不同的准入、准出标准。

• 天真的设计

有些项目在设计之初就已经确定了其悲伤的结局。其原因就是架构师在设计时，引入了太多的假设、前提，甚至有些架构师把某些前提理解为理所当然的存在，在设计文档中完全不提，导致实施时，这些假设和前提无法满足，紧随而来的就是项目的无限延期甚而失败：一个月完成的开发，需要一年的时间去修复问题，这是多么痛的领悟啊！

设计文档一定要实事求是，所有不确定的因素都需要罗列出来逐一确认。

• 大用例

用例过大、过粗，如：遍历所有场景下的加密用户能正确接入。这样的用例几乎没有可执行性，遗漏场景是必然的。因为随着产品使用，应用场景会越来越多，到最后，很少有人能真正的把场景列举完，执行的人在遍历几个他知道的场景后，就会将用例Pass, 而产品一旦上线，灾难极大可能伴随而来。

• 缺席的单元测试

现在开发，小部分是自主代码，大部分是第三方组件（免费居多），推行单元测试显得尤为困难，很多公司甚至就没有单元测试，这带来的，可能是灾难性的后果。曾经跟过的一个Bug, 设备间歇性的出现重启（1-3个月不等），开发人员甚至接连出国在客户那边呆了2个多月，一点眉目也没有，内部也想尽了一切办法试图复现，最后都是徒劳，还是在偶然一次新特性调试时，发现底层的一条打印日志异常才找到一些线索。

越是底层的代码，单元测试越是要充分。一个是调用频繁，另一个是因为层层调用、包裹后，这些代码的异常分支通过黑盒测试基本上发现不了。一般黑盒测试能够覆盖代码的75%的分支已经是非常高的覆盖率了。所以，即使因各种原因导致单元测试不能完全进行，也需要有策略执行，不能缺失!

• 无休止的测试

“生命不息，测试不止”，多么励志的座右铭。如果你是老板，你可能恨不能亲手打屎他。但实际项目中，这却是不争的事实，我们很多时候迫于时间压力，不得不将亲手设定的测试准出标准撕一个洞，有限度、有条件的让项目得到终结。为什么？

每一个缺陷的修复，都可能伴随着更多的缺陷引入，特别是代码足够庞大，代码维护简陋，人员更换频繁时。在这样的环境下，每一个疑难问题的修复都不下于一个新生孕育----剧痛、阵痛、生不如死……, 关键是TNND的还没有唐氏综合筛选!

“纸上得来终觉浅，绝知此事要躬行”。测试的原理、流程、规范都容易理解。但要制定适合你的一套规则，还得不断的实践、总结、调整……, 而且微调伴随着始终。测试需要在质量、时间、成本之间平衡，寻求最高的投入产出比。