功能测试小感

功能测试某种意义上确实是有套路规律的。所谓的测试经验，在我看来就是把套路运用在不同场景的能力，也就是灵活运用的能力。其实这里的套路，换种说法就是测试理论。

从黑盒角度来说，边界值、等价类，这些应该都是软件测试人员的基本知识，应该深入思维信手拈来而不是刻意为之。边界值帮助我们发现比较好找的bug，改善软件最下限的质量（还别说边界校验真的是bug的重灾区，具体依赖RD自测水平），等价类帮助我们精简用例数量，提高执行效率。这些方法论使得我们可以脱离具体业务场景对代码逻辑针对性设计用例。

除此之外，场景法也是非常重要的手段。场景法 简单理解就是根据不同的用户场景来设计用例，这里没有什么一套一套的测试理论，唯一的要求就是理解业务场景，从用户角度出发。一些不是bug的问题，在这样的要求下可能就会变成bug，因为它们有悖于业务场景，削弱了用户体验。

另外，一些更加工程类的bug，比如线程饿死、变量未初始化、数据库死锁等问题，从黑盒角度症状有时会比较奇怪。这些问题更加适合在白盒的角度发现，这也是code review存在的必要性。很多时候，如资源竞争这类问题需要的业务场景比较复杂，场景触发所需要的成本相对更高，甚至靠线下测试环境的机器资源根本无法触发。所以如果什么问题都想着从黑盒角度来发现，那是不靠谱的。这也正是一个好的QA与普通QA拉开差距的地方——除了理解业务场景、熟练地黑盒发现功能问题外，还要求可以白盒通读代码，在脑海模拟业务场景，进而去发现逻辑问题。

如何设计测试用例

这里并不打算写一篇全面的教程，只是分享个人对某些点的一些看法。

测试的初衷，是验证程序功能是否符合需求。那可能会问：“既然只需要符合需求，那为什么还要考虑那么多的边界、异常值呢？”，道理很简单，因为这些都是隐藏在需求之下的情景。需求，本身是服务于用户体验的，而不是凭空出来的产品功能约束。那么为了一个完整的用户体验，肯定要包含一定程度的容错操作，这就是边界值、异常值考虑的缘由。

既然已经有了一个测试的最终目的，那么具体如何设计用例就好办了。

1. 根据代码逻辑设计用例，以代码覆盖率作为衡量标准。

   明显覆盖相同逻辑、相同代码路径的用例可以只留下一条。比如新增功能点是支持连续升级，如果连续升级2次和连续升级3次这两个case覆盖的代码逻辑没有差异，后者完全没有存在的必要，不必因为没有测试后者而不安。

2. 结合需求进行用例设计。

   QA必须对一切保持怀疑，故不能认为RD已经完全按照需求完成开发工作。相反，往往不同的视角对需求的理解不一样，在功能的实现方式上会有区别，进而影响功能实际效果——比如同样是实现队列，一个用单向链表实现、一个用数组实现、优先级队列甚至还要用堆来实现，不同的实现方式内部数据流转过程是完全不一致的。另外，这种方式可能会有bonus——发现RD与QA对需求点理解的差异，反向确认真正的需求到底是什么，这样无疑对产品有积极的帮助。

3. 刻意的异常情景考虑。

   异常测试可以被放在一个大块里，这样更加方便归纳整理、查漏补缺。异常包括很多情况，具体根据不同业务类型来定义什么是 “异常” ，安装失败、升级失败、解析配置失败、网络失败、用户作弊操作、数据库失败、业务场景失败等等，这些都是异常。

4. 提高用户体验的用例设计。

   这里本身不应该单独分出来的，但是我觉得很重要。用户体验其实不一定会有具体的用例，很多时候往往只是一种主观感受，比如UI层面的感受、操作流程顺序、功能的作用大小等。一个具体例子就是根据商品名的历史订单搜索，商品名使用模糊匹配效果往往要比精确匹配好，原因很简单，因为用户根本不可能记住商品叫什么名字。

扯一点题外话，一个好的QA，还应该要熟练掌握各种对自己有帮助的工具。除了发现bug外，还应该有定位bug、调试代码的能力。定位某些bug，比如常见却又难定位的内存泄漏，就需要特定工具帮忙。