如何设计功能测试用例

最近招聘面试测试工程师，发现很多测试工程师都是半路出家，对一些基本的测试概念，思路与技术没有认知。在设计测试用例的时候只是基于直觉与经验去测试。这就导致测试用例的设计既不全面，也不科学。

一般功能测试指的都是黑盒测试。就是测试工程师基于需求文档，对开发完的功能进行测试。也就是说，功能测试都是基于需求的黑盒测试。而需求主要归为两大类：

• 显式功能性需求:指的是需求中明确规定且用户可以感知到的需求，比如“访客用户访问管理员页面时会跳转到登录页”。
• 非功能性需求:指的是用户无法直接体验到的，非具体功能性的需求，但这种非功能性需求在做功能性测试的时候也会涉及到，因为很多非功能性的需求会影响到功能的可用性与用户体验，比如性能测试。

下边我们分别来看一下两类不同的需求都有哪些测试用例设计方法或思路。

1、显式功能性需求

对于显式功能性需求我们最长用到的方案主要有三种：

• 等价类划分法
• 边界值分析法
• 错误推断法

1.1、 等价类划分法

我们如果想测试一个功能的最傻的办法就是穷举。比如说一个密码验证功能，我们把所有的可能的密码都尝试一遍，自然就可以覆盖掉到所有的问题与可能。但是这种穷举的方法明显是做不到的。因此我们要用到等价类划分法。

等价类划分法就是说我们将所有可能的输入数据或操作分为多组不同的子集，每个子集中的数据与操作对发现程序中的潜在错误都有同等的效应。这样我们就将一个子集称为一个等价类。比如输入各种与用户名不相符的密码，是一个等价类；输入各种不存在的用户名是另一组等价类。这样在测试的时候，我们只要在每个等价类中选择一个典型操作，就可以达到较好的测试覆盖度。

等价类还会分为有效等价类和无效等价类两种。有效等价类指的是合理的、有意义的输入，主要用来验证功能是否实现了某个功能。无效等价类与有效等价类相反，指的是无意义的，超过软件规格的，不合理的输入，主要用来测试功能的健壮性，看是否考虑了如何处理不合理的情况。

1.2、边界值分析法

在我们在测试合理与不合理的数据的时候，往往最容易出现问题的就是合理与不合理的边界，这时我们就需要使用边界值分析法了。边界值分析法，就是对恰好大于、小于和等于边界的值进行测试，来验证程序是否做到了合适的处理。边界值分析法一般是作为等价类的补充，来加强测试功能实现的程度与健壮性保障的程度，是否符合规格。

1.3 错误推测法

在测试的时候就算我们使用了等价类划分法和边界值分析法，也很可能会遗漏一些需求中没有清晰提出，技术上比较隐蔽的错误。这种错误就需要测试人员通过已有的经验、对功能实现可能的方法的理解或直觉，来推测出软件中可能存在的各种错误与场景，然后编写测试用例来进行验证，这就叫做错误推测法。比如，登录超时后，某个需要权限操作的功能在使用的时候，是否跳到了登录页，还是直接报错，甚至说依旧可以操作。这种错误是需要测试人员一定的经验、技术积累与直觉的。

虽然说功能性测试往往是黑盒测试，但是如果测试工程师对于功能的实现有一定的理解——比如说是否用了缓存、是否使用了消息队列、是否某个地方会消耗极大的性能等等——将会更容易的推断出哪些地方会产生错误。

2、非功能性需求

在测试工程师测试完显示功能需求之后，还要考虑到系统的非功能性需求。这种需求可能在文档中有明确提到，也可能并没有明确的提出。但是我们的测试工程师在测试的时候却必须要关注到。

2.1 兼容性测试

兼容性指的是开发的软件是否在各种平台都可以使用。比如我们开发一个网站，我们的用户可能会用到各种不同的浏览器访问我们的网站。这样我们在测试的时候，就不能只考虑到某一种浏览器。我们需要考虑到多种浏览器的兼容性。

兼容性测试可能会涉及到：

• 不同厂商的浏览器及相同厂商不同版本的浏览器。
• 不同的设备终端及操作系统
• 不同的屏幕分辨率
• 不同的用户软件环境（比如是否禁用了cookie、是否可以连接外网等）

2.2 安全性测试

我们的测试人员还需要关注到开发软件的安全性。这涉及到：

• 用户隐私信息是否加密
• 需要权限的资源是否有没有权限也可以被拿到的风险
• 会不会受到跨站脚本的攻击
• 会不会受到sql注入攻击
  等等

2.3 压力测试

测试人员也需要考虑的软件是否能够承载其需求所需的压力，例如：

• 软件是否能在合理的时间内响应用户行为
• 软件是否可能承载足够的请求
• 软件在处理大数据量时会不会产生资源锁死
  等等

3、总结