点点点工程师，是很多人对UI功能测试的爱称。但是即便就只是点，你能够练出一阳指神功，一点就是bug吗？在测试的过程中很多人有发出过这样的疑问，为什么我根据用例的走查无数遍就是测试不出来bug，但是这个app到了一些资深的老油条手上就会bug无数呢？或者乃至发布了以后，用户那里也反馈无数呢？
你真的测到点上了吗？bug分布里面也是玄机的。如果你抓住玄机，就算只做纯粹的黑盒也能够做出技术含量。（本篇文章大为业务层面）
bug玄机之一：开发常见错误
如果一个开发突然没有bug了，那么不是他的技术突飞猛进，一般是你没有测试出来
--忘记是哪个高人说过
所谓bug，其实就是开发在程序上制造的错误，所以在本专题的所有部分都可以称作开发常见错误，其实只要跟着同一个开发团队测试个几个月就会有许多bug的积累，那么对于这些bug的积累，你是否仅仅是提出修改就将之忘记了呢，其实这里面有许多可以利用的价值，其中之一就是找出开发常犯的错误。
开发常见错误的总结其实是刚入门的小白可以尝试的一个方向，特别在这个时期的你没有太高的技术去整理一些干货，那么这个就是你的学习过程中累积下来的资本。
在大方向上我们可以通过review一些提过的bug做个简单的数据归类。看看哪个类型的bug数目最多。例如我们团队某个时期bug较多的是出现在需求的吻合度与衔接上。有些需求不明确的地方开发gg们更倾向于按照自己的想法去实现。那么就会出现不同端的开发在一个案子的功能细节上处理的不大一样。或者和需求不吻合。
在小方向上，开发gg会存在一些小的思维习惯。他们在设计与开发的时候更多专注自己这个模块，而欠缺对其他模块影响的考虑，那么我们在设计测试的时候就要多考虑这个方向。又如前文提到的有些开发在处理分页加载的时候会偷懒的问题亦是如此。
bug玄机之二：打破常规思维
这个模块暂时没有想好怎么写
bug玄机之三：业务关联影响
很多同学可能会说我对某个业务并不够熟悉导致我在接收到需求的时候无法准确的判断出关联的影响。或又是我有时一下子没有办法想的那么全面。俗话说的好：“好记性不如烂笔头”
这里有一个建议的方法。画一棵你的业务树亦或是功能树从多个维度去遍历评估。
下图为基于对业务熟悉的基础上画的业务骨架图。
根据业务的类型进行归纳，例如当前系统支持的消息明确的有多少中，消息来源又有哪些。这样当开发变更到某个消息来源系统的时候，我们能够不遗漏的考虑到所有的消息来源。（这个归类方法建议模仿开发的代码结构来归纳）
下图是从功能维度归纳的功能树。这种树比较好画，是最直观和小白的。例如当开发提供了一个群的新功能的时候，我们可以通过遍历这棵树找到与群业务关联的功能，再逐个去筛选是否可能影响，这样就不容易遗漏。
考虑到项目。以上的树都未全部展开。
以上的方法是业务层面的，如果各位修炼到家想要走在更加精准的层面，可以通过对代码的熟悉考虑往精准测试领域研究。
bug玄机之四：结合移动app特性
这块大家都比较熟悉，就不多说了直接上干货。
考虑几个维度。
第一个维度：控件化
移动app拆解开来无非就是无数个控件根据需求编织在一起的各种逻辑。当我们把需求抽离出来，剩下的也就是这些死板的控件规则，去归纳控件规则以后，控件的相关测试也就无非那些。
具体看下面这棵树，如果发现了新的测试点还可以在上面加以完善。
第二个维度：移动app兼容
网友评论