之前的文章介绍了黑盒测试的几种用例设计，包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
通过这些方法设计的用例覆盖率是很高的，当然用例太多，也意味着更多的工作量，那没问题来了，在确保用例的一定覆盖率的情况下，尽量减少我们的工作，达到最高的效率，例如大量的重复用例和无效用例需要怎么去判断，今天就用例进行精简方面说说我的想法
首先是对用例重复进行合并，所谓用例重复，不是说很多用例完全一样，而是说部分用例的检查点或影响因素相同，操作步骤相同，使用例看起来像是重复的用例一样，对于这种情况，可以进行合并。
当对象部分功能类似，检查点和影响因素相同，操作步骤相同，则可以将相同的部分进行合并。如果是检查点和影响因素相同，合并的方式也是一样的，这种用例精简方式适用于一个操作步骤，可以检查多个检查点的情况，如果只是检查点相同，但是步骤不同，仍然不建议进行合并
接下来对无效用例进行删减，针对测试对象，找出相关的检查点，再由检查点出发，发散影响因素，这种用例方式是纯黑盒的用例设计方法，但是在很多时候，并不是只进行纯黑盒，而是灰盒。功能内部逻辑对我们来讲就不是黑的了，在了解完开发实现后，会发现纯黑盒情况下发散出来的一些影响因素其实没有没有必要，直接去掉就可以。
如果开发表示，他使用的系统自带的窗口函数绘制的，那么这些影响因素就需要保留；
如果开发表示，他是自己写的窗口函数绘制的，不会适配系统的当前情况，那么这些影响因素就会有多余的，系统相关的修改不会影响到自绘窗口的显示。
如果开发表示，他是自己写的窗口函数，但是会根据系统的情况进行适配，那么需要进一步了解会适配哪些情况
这种用例精简的方式是根据开发实现，对用例进行增删改，这个度就看对开发实现进度了。
所以想要高效的完成app功能测试或者其他软件功能测试，不仅需要一款合适的功能测试工具辅助，更重要的是用例的设计方式，和对用例精简已，帮助我们更高效的测试。
TestBird-手游和App自动化测试平台
