一个老油条测试对测试用例的思考
作为一名测试，大家都知道，测试一个元素的时候，需要从各种测试方法中去对该元素进行正反例编写，于是就会出现某一个功能，可能详细能写几十个用例或者上百个用例的情况，如果在算上整个平台的元素总量的话， 那么可想而知，测试用例的数量绝对非常庞大。作为一个老油条，每当我测试的时候，一看用例几百上千条或者更多的时候，就会很挣扎。
目前大部分的公司一般用例管理和执行是按照如下流程进行：
image.png
（上图简化了很多复杂流程，如有不适，请提示）
根据上面的流程我们可以看出用例方面存在一下情况:
用例存在无限更新的状态，因为不同的人，不同的测试方法,最主要是需求存在无限变动的情况，这样都会导致存在不同新的用例
测试每轮测试都是完全依赖这份用例文档，这个用例文档最终的用例数量非常巨大
测试每轮测试都是严重依赖开发发布测试环境，测试存在严重滞后
上述的这种测试还不是完全的基于敏捷开发测试的模式下进行的，如果上述这种测试行放到敏捷开发测试流程中会出现什么情况，同等时间更多的版本发布，测试需要更多的配合用例执行，这种情况下，测试就会进入到一种疲于奔命的应付中，对于测试来说，这是致命的，因为1无法保证用例执行的效率赶上版本的发布，2最重要的就是无法保证质量
当然也许有人会说我这个说法是对敏捷开发和测试的误解，我承认一个合格的敏捷开发和测试流程是非常符合当前大部分公司运作协作的，但是我们不得不说明一个现状就是，国内大部分的中小型公司，更多的还是基于传统开发模式的基础来讨论敏捷开发和测试的，有的一个产品甚至存在不同阶段传统与敏捷混用，导致这种情况的原因很多，这里就不做说明
基于这种情况，如果有大N根据自己的产品实现自己的测试用例管理平台或者流程管理平台，这是非常好的一个解决办法，但是基于更多公司测试环境的限制，下面我说下基于自己团队的尝试
测试用例管理工具的新尝试（xmind）
1. Execl，禅道，xmind的用例管理对比
excel具有很强大的表格特性，可以自定义任何方式的字段和丰富的表格关联，同时也具有很强大的统计功能，
禅道，是平台话管理工具，可以更好的和bug缺陷进行关联，同时可以随时监控执行过程
既然这些工具都这么有核心优势，为什么我们会选择xmind？
- 禅道的用例管理时按照随时添加的， 首先存在同一模块bug无法聚类，会导致不适合用例发散
- excel确实具有很强的表格特性，但是当内容较多时，视觉体验差，同时基于敏捷测试的现况具有高迭代的特性，存在用例维护频率高但是用例数量较少，发散快的特点（还有一点我没说，用excel来管理用例感觉有点杀猪用宰牛刀的感觉，因为excel实在是太强大了）
- 个人原因，因为喜欢xmind这种风格
结合上述有点牵强的理由，我选择xmind（非常适合发散， 高维护，用例较少的特点）效果如下：
xmind用例
用例区分核心用例和非核心用例
如何区分核心用例和非核心用例？
-
核心用例有以下来源：
所有的业务功能正向用例及部分严重等级的反例
业务核心主流程用例及部分严重性反向流程用例
安全类用例
性能测试用例 -
非核心用例有以下来源：
文本框校验用例（边界值，必填项，特殊字符，长度）
暴力操作相关用例（暴力点击，违规提交）
界面UI测试（文字错误，UI变形）
新增灰度测试环境
在测试和开发环境中，增加一个过程是灰度测试环境，灰度测试环境主要保持跟开发环境保持一致，可以定期更新开发当前最新内容，测试可以在灰度测试中完成部分可提前量的测试
更新后的测试用例管理和执行的流程如下图：
image.png
如上图所示，通过这种改动，首先确保非核心用例的执行在测试的空档期中，这样从一定程度上面可以提高测试的工作饱和度，此外，可以让测试可以在后续正常测试环境中确保核心用例的质量，从而给与平台有个基线质量，此外多余的时间可以完成相关更深层次的技术和业务方面的摸索性测试，提高平台的质量。
当然这只是一种暂时性的摸索，目前自己也在尝试这种优化方案的执行，至于效果仁者见仁智者见智，不同和的项目也有可能存在细微的区别。如果大家有更好的想法，可以直接提出，大家一起共同进步和完善关于测试用例的相关内容
