测试用例优化和bug提交的一点经验

关于用例优化：

当测试项目越来越多，测试用例必然也越来越多。看着几千条用例还有那些测了又测的服务器，完整的执行一次全覆盖是多么可怕的事情。但是在测试覆盖率上我们又不能松懈，质量保证是测试的根本。

其实我们内心是抗拒的，原因无非有以下几点：

（1）重复率很高的用例，反反复复的执行

（2）需求又变更了，用例改起来很麻烦

（3）内心的浮躁

当前国内的测试环境是混乱而复杂的，个人感觉可以用浮躁来形容，原因很多。企业对测试的重视程度不够、测试入门门槛低、薪资普遍比开发低、做测试没几年就匆匆的往测试开发或管理发展、走到后面看不到出路，等等。如果有更好的出路，感觉做测试是在混日子，真的建议改行。因为测试发展到后面其实和开发差不多，甚至比开发的涉及面还要广，这是一次苦修。

说上面这些是为了冷静，这样才能让自己思考。回到用例上面来，无论是后期做自动化、做性能、做接口，好的测试用例都能让你事半功倍。不要以为设计用例是很低端和简单的事情。其实它是基石，是很能体现测试技术高低的。

这里我就不去说那些老生常谈的什么优先级、什么粒度、什么边界值等价类了。

（1）关于爽。设计是一门艺术，从测试点的 分析，到通过 语言描述来实现，甚至到 执行，每个环节都有优化空间，应该多想想怎么写起来更爽，读起来更爽，执行起来更爽，这些都是成长点。虽然无绩效或者领导不care，但是为了自己还是做起来吧。

（2）关于 公共用例，在细化测试点的时候，我们会发现其实有些模块是共用的，比如不同页面弹出的相同窗口，我们可以把类似这样的部分提炼为公共用例，在其他页面遇到这个相同的窗口时，点到即可，没必要再把里面的内容轮一遍。当然，求同存异，提炼共同点也要发现差异点，差异点的用例要单独体现出来。

（3）关于新技术，随着测试技术的发展，现在已不只限制于边界值、等价类这些最常用的设计方法了，在一些特殊场景二叉树、对偶、遗传等方法也得到了应用。但是个人感觉这方面的技术发展还是太慢了， 适合项目的，既能节约成本又能提高效率的技术才是好技术

，通过学习新技术然后到项目中去提炼这才是自己的。

（4）关于维护，维护用例是一个review的过程，静下心来看看以前写的用例，你会想到一些新的思路。可以从 全局上对用例进行一个把控，可以对整体的业务流程进行更好的 梳理，比如一些通用属性，比如一些特殊场景。可以通过当前的 bug来进化你的用例，提高准确性。可以变换 角色，从客户从产品的角度发现新的大陆。甚至可以从市场上 同类产品进行比较而发现新的测试点。

还是那句话，测试用例能提现你的思维模式和你的测试能力，也是自动化、性能、接口的基础。

关于BUG提交：

提交bug是个既愉快又痛苦的过程。因为有时候bug会很多（特别是前期），项目周期又很忙。但是好的bug能避免很多麻烦。比如避免了开发让你 重现的情况（不绝对，有些开发确实自身有问题），避免了 开发看不懂又找你麻烦的情况，避免了时间久了 自己都看不懂的情况。

什么样的bug才是好bug。曾经有人面试过我这个问题，我忘了怎么回答的了，但是他提到一点，有图的bug是好bug。这印证了有图有真相的那句话。确实能够用图表说明的bug确实比纯文字描述的bug好理解的多，久了之后，也不至于开发不认账。

至于bug不重复、严重等级、优先级这些问题这里就不谈了，这是基本的东西，而且每个公司不一样。

（1）关于截图，要有 截图（如果有日志更好），这很有说明性，可以说明绝大部分情况，开发也能一目了然。也便于跟踪

（2）关于标题，语言描述始终是个难题，如果bug的标题能让开发猜对 80%应该算是成功的。所以至少要有‘在哪里’，‘做了什么’，‘导致出现了什么问题’，这几点要清晰。关于做了什么做好找到最短路径，否则就在详情中说清楚。

（3）关于跟踪，有时候提交bug会忘记一些信息，这些信息最好在发现的时候补上，重新修改自己的bug不丢脸。即使是错误的bug，及时去修改也避免了浪费时间，因为大家始终会发现的，所以没必要刻意隐瞒人都会犯错。

（4）关于偶现，偶现的bug经常遇到，发现了就先提交吧，有时候死磕也不容易复现的。如果上线后或者几个版本都没有出现再关闭总比在线上发现好。

（5）关于回归，回归环境、版本、结果（通过、不通过、变相通过、场景不存在...）、步骤，应该要有，方便回溯。

（6）关于项目周期很紧，很多情况是因为bug太多，提交bug会占据很多时间，所以很多同事就简单几句，就把bug提交了，为后面埋了很多坑。其实截个图，把标题的要素习惯养起来，提交bug也会很快的。