这个章节是属于用例设计进阶部分，阅读前需要先掌握基本的用例设计技巧。
工作了几年以后，发现在同样的一个领域去编写测试用例，发现是存在一定的划分与封装技巧的，本章主要介绍，在实际项目运用的一个用例库的概念。本章的目的不只是为了的说明这种封装的方法，也是为了向大家介绍用例设计进阶可以考虑的一个方向。
1、搭建用例框架
我们可以基于分层的测试理念、业务流程的梳理、固定的异常场景等梳理我们所需要的测试框架，其实也就是我们平时在写用例的时候的一个思路的凝结。例如下面这张图
软件用例设计框架
在做软件测试的这几年，我慢慢发现自己拿到一个案子的时候已经能够比较熟练的运用一个思路去写对应的测试用例，但是每次总会有一些遗漏是在测试过程中才发现的，比如在测试过程中发现旧版本有些问题，而对应用例却根本没有提及，才发现唉怎么这个方面又忘记补上了，基于这个思路我搭建了在写软件用例的时候一般要思考的几个方向。例如我的个人思路就是基于策划案，对于功能结构清晰的案子画出功能结构图，每个小小的子功能去套用对应的思路。例如
模块功能结构图
这样先保证用例正向的覆盖面不会把正向的重要的模块遗漏，如果是流程性比较强功能建议融合流程图来进行综合评估会比较好。
然后再对异常的场景进行回顾，从入行开始无论是通过学习、前辈口头指导，我们多多少少了解了一些的需要固定去考虑的基于移动端的异常场景，这部分也可以沉淀总结成固定的一些思维方向。例如基于用户场景会去考虑的一些方向也可以总结出一些用例库。例如交叉事件用例库（又名冲突事件）、手机权限相关用例库等等。尤其一些固定的控件会和这些有紧密的结合。（例如音频播放器与交叉事件、相机与权限申请）
2、控件化的用例
就框架中体现的，每个功能子模块中我们会发现归根到底我们的移动端功能就是由那些固定的控件组装完成的，那么我们是否可以将控件这部分重复的思路抽取出来将用例控件化呢。例如某个按钮、某个列表的用例正向异常场景我们封装完了以后，只要在有使用的时候复制或者调用这些用例根据需求进行修改即可。这样我们能够将这些细节的用例设计时间节省也可以将用例设计的水平统一提高上来。
具体可以封装的控件有哪些可以与对应的操作系统开发文档进行结合。
3、封装异常用例库
用例除了控件这块，还有很多时候我们会去思考一些比较大块方向的异常场景，例如：
1）兼容
包括：
网络兼容、机型兼容、版本兼容、多端兼容等
2）耦合（不同功能之间的联系与冲突）
新功能耦合，同期上线的所有新功能中是否存在联系与冲突
旧功能耦合，上线的新功能与旧功能是否存在联系与冲突
3）用户场景
我一直觉得用户场景测试是我发现重要的bug的必杀技，因为这块可以覆盖大部分的用户使用场景，发现一些影响范围广，影响程度大的bug。拿到功能的时候我会对自我角色做一个切换，如果我是用户，我会如何去使用这个产品，我最在意的是什么？同时在有限的时间内，这个方法也会被我用作验收他人测试质量的一个方法，因为这些场景拿下，心理至少会有50%的安全感。
有时对于一些重要的功能，在自我用户体验的之外，我还会去邀请一些贴近用户群体的小伙伴来体验我的产品。这个是一个办法。
4）其他性能、安全等方面
除了第三点只是提供一个方向以外，另外2点我们都可以沉淀和总结出来的用例库。
用例设计其实是我们测试思维的一个体现，说用例的封装，其实是对我们日积月累经验的沉淀与思考方向的扩充。
用例库这个本章仅仅提供一个概念，对于测试初学者来说，可以在本章开阔一下你的测试思维。对于用例设计有了一定年限的同学，也可以考虑做一些这方面的沉淀。对于也想要用用例库这种方法来提升团队用例设计的同学，这里有几点提醒也是我目前还没有想明白的一些问题。
1、用例的性价比
测试思维有多完善，你的用例库就会有多复杂。在完善好你的用例库以后，你会发现，原来基于遗漏你的用例只有100条。好了你补充完以后有1000条，而你的时间根本不够支持你做这么完善的测试。（这也不意味着你可以继续遗漏，我们需要知道自己没有覆盖到的区域是哪些）这个时候你就需要去思考你的用例性价比的问题了。什么样的用例可以帮助你更加快速有效的发现更为重要的bug。
2、用例库的维护
如何确保你所生产出来的用例库是最完善或者比较完善的，并且可以切实在项目中应用
3、用例库使用的目的
你使用用例库的目的是什么？提高用例设计质量？解决用例设计某些问题？还是节省时间？在后续的落地过程中都不能够忘记你最初的目的，要不容易跑偏。
4、用例库的扩展使用（我的乌托邦）
用例库的最终凝结是否可以运用在自动化上。又是否可以和精准测试做个挂钩？
这些都值得我们深思。
以上。
网友评论