对测试的理解

 

 对测试的理解

　如果将整个测试流程划分为四个环节：测试的计划，测试的设计，测试的执行，测试的评估；那么需求分

析应该贯彻在前两个环节，当然有时在测试的执行阶段出现一些问题，也需要去重新定位需求，但往往不会

涉及后两个环节了，测试的执行阶段应当完全依赖测试设计的结果，也就是测试用例；而测试的评估当然就

是依赖测试执行的结果：测试用例通过率，缺陷修复率，测试覆盖率等手段，验证产品是否可以交付。

　　测试的设计是整个测试流程的重中之重；而分析需求的能力，决定测试设计的好坏。

　　测试的设计，第一步应该对未来项目的生产环境有个认知，需求文档中的要求往往不会具体到的每个细

节，有时客户潜意识中已经默认了一些期待，所以我们除了根据有型的文档，更要进行不断的沟通，同时也

要考虑资源（财力/人力），来构建我们的测试环境，我认为测试环境的考虑，从功能上说实质是兼容性测试

的角度，从性能来说，应当是业务要求的角度（性能方面了解有限）。

　　撰写测试用例可以说是衡量一个测试人能力主要的硬性指标。顺便推荐一篇文章《How to write better

test case》,google一下应该可以下载的到。（《51测试天地》翻译版：

http://www.51testing.com/html/90/n-96790.html）文章将测试用例分为三类：Step by Step, Matrix,

Automated scrīpts。大多数时候，我们默认的测试用例仅仅是第一种，测试脚本是基于测试用例的升级，作

者将脚本也归纳成测试用例的一种类型，也未尝不可。

　　测试人之间经常会讨论测试人员需不需要懂开发，如果单纯的是作为一个测试执行者来说，这方面可能

要求不是很高，但作为测试设计者，也就是到了设计测试用例的层面，这问题就不需要回答了。

　　虽然要求测试人员站在用户的角度考虑，但不代表仅此而己就够了，你也应当理解产品的内部是如何工

作的，这有助于你设计出更优秀的测试用例，也就是在测试的执行阶段可以最大化的发现缺陷；同时，自己

在设计测试用例时，开发方面的知识可以帮助你去预见一些问题，将他们反馈给开发人员，也许就避免了后

面一个性能的瓶颈。这里的价值，可以说弥足珍贵。

　　除了对于项目的代码逻辑要有清晰的思路，同时对于相应的业务领域也要有很好的理解，举个自身的小

例子最说明问题：网上银行输入密码的键盘，其各个键的位置是变动的，而我一直不知道，直到开发人员把

这个Bug验证为无效。

　　在设计测试用例时，首先脑海应该有个架构，应该清楚的知道自己的步骤，注重骨架的划分，不要急于

去细化到场景。一般来说骨架是以单元功能块来划分的，当然需求人员可能已经给你划分出来，那更好不用

自己操心了。采用功能业务逻辑和代码路径逻辑两种思路结合去分析，去生成多个的场景；然后对应每个场

景，去制定相应的测试用例；对应每个测试用例，准备不同业务类型的数据，同时再针对每种类型的数据，

灵活的采用黑盒测试方法去划分出最合理的验证组合。

　　好像大部分测试管理工具都很少支持Matrix这种类型的测试用例编写，不过根据功能需求不同，设计的

测试用例也可以采用不同的类型，比如重逻辑轻数据的采用为Step by Step;轻逻辑重数据的可以采用Matrix

。我提到的那篇文章有很好的介绍。

　　设计测试用例，不是追求其书面结构的好看或者理想状态下的面面俱到或者尽量来表现编者水平，它的

价值是在接下来的测试执行阶段来体现。有时候应该告诫自己，测试用例到了这个粒度已经足够了。