思维导图写测试点的额外补充
作者：互联网
经过近一个月的反复宣讲，以及通过用例评审反复和大家沟通意见建议，我们用思维导图写测试点的格式已经基本固定了下来。
基础的内容，请回看前两篇文章：
今天是在这些内容基础上的再补充。
1.表示层和逻辑层测试目的的区分
表示层测试点的测试目的应该是针对业务逻辑的覆盖，所以表示层测试点的描述，可能会被误以为是需求的描述，其实不一样，需求只是描述业务的展现形式，测试点是要验证产品满足了要求的展现形式，并且在验证时，我们把需求进行了颗粒度的拆分，逐点进行验证。
逻辑层测试点的测试目的应该是针对实现逻辑的覆盖，所以逻辑层测试点的描述，都应该是逻辑实现本身，只是某些情况，无法通过针对性的逻辑结果来确认测试结果，我们就会用表示层的现象来间接证明，一般不建议这么做，但如果只能这样，那就特殊说明下，毕竟针对同一个业务逻辑，表示层和逻辑层测试点的操作步骤几乎是一样的，只是关注点不同。
这么说起来比较抽象，我还是拿个例子来说吧。
需求：有一个程序，在自己退出时，会把自己的启动时间通过 http 打点上报给服务端。
针对这个需求，如果是表示层的用例，只需要下面两条就够了：
但是，经过和开发详细沟通后发现，他们的实现逻辑是这样的：
程序在启动时，把启动时间记录在一个本地文件中，程序退出时会从本地文件中读取启动时间，并且进行 http 打点。
知道这个逻辑后，我们可以补充相应的逻辑层测试点如下：
和前面的测试点对比，能看出来差异吧？第一种测试点只关注业务，第二种测试点同时也关注了实现。
也许有人会说我给的例子不恰当，没有人会这么去实现，嗯，意会下就行了，主要的意思是，针对业务的表示层和针对实现的逻辑层，我们都应该有对应角度的测试点去覆盖，这也是我们早前说的测试深度，至于深度要挖到什么程度，请根据自己项目特点合理判断。
从例子中我们还能看出来前面说的，逻辑层的测试点，实际的用例执行步骤和表示层是一样的，只是关注点不同，我们去区分表示层和逻辑层，只是借助这个概念去让我们知道，需要去关注哪些内容，所以在某些情况下，不要过分纠结一个测试点属于表示层还是逻辑层，只要能满足预期的覆盖度就行了。
2.验证没有少做事，也要验证没有做多余的事
继续上面的例子，不管是表示层还是逻辑层的测试点，绝大部分都是在验证程序没有少做事，这是我们主要的测试目的之一。
我们的另一个测试目的是「验证程序没有做多余的事」，比如我们看到逻辑层验证有一个测试点是「验证本地文件被占用时，程序直接返回不做任何处理」，这属于异常处理的一种，但是需求中并没有明确要求应该怎么做，所以可能会有开发实现为「文件被占用，就换个文件名创建」，反正不会抛出异常就可以。
碰到这种情况，一定记得要同开发、产品三方沟通确认预期。
关于这点，还有一个类似的情况，比如在程序的设置项中勾选一项设置，理论上程序只需要调用修改注册表值的函数，把对应注册表值做个修改即可，但是有些开发图省事，打开设置时，读取一下所有设置项的值，关闭设置时，按照当前设置值全部重写一遍。
从表示层看功能符合预期，从逻辑层看没有少做事，但是增加了不必要的开销，做了多余的事。
3.分类是为了条理更清晰，不要在分类标准的选取上纠结
上面例子中的逻辑层测试点，我们写了 10 条，放在一个节点上已经显得有点多，这时候就可以把测试点做个分类。
比如下图，是我按照本地文件的写入和读取分成两类：
这样看起来是不是清晰了很多？主要是测试目的会清晰，当然有同学会问，我换个分类标准行不行？必须行呀，如下图，是我按照程序启动和退出也分成了两类：
看，没啥区别，分类是为了让众多测试点更清晰易懂，最后面的测试点才是重点，针对本次测试点，甚至还可以按文件操作和打点操作分，还可以按正常情况和异常情况分等等。
总之，不要在分类标准选取上纠结，原则就是提取合适的公共属性，让整个测试点看起来更清晰即可。
4.维持平衡，不要钻牛角尖
不要在表示层和逻辑层的划分上钻牛角尖，你完全可以取一个自己喜欢的名称，也完全可以不区分这个层级，只要有办法保证测试点的覆盖度即可。
不要在逻辑深度的挖掘上钻牛角尖，理论上我们能挖多深就挖多深，发现深层次的实现问题，肯定更有成就感，但一定要基于项目的现状和需要去平衡投入产出比。
不要在需求/逻辑/实现是否对错上钻牛角尖，一切都是为了产品服务，测试目的当然也是，所以适合的就是最好的。
不要在分类条件的选取上钻牛角尖，如果选不出来概括性完美的分类标准，也可以不分类，或者选一个能概括大部分测试点的分类条件即可，时间要花在刀刃上。
以上，我基于目前实践的现状，总结了思维导图写测试点的额外关注点，不知道你是否认同，或者有啥额外补充。欢迎留言说说你的想法。
标签：逻辑,额外,测试点,验证,导图,表示层,测试,分类 来源： https://blog.51cto.com/sylan215/2919744