为客户负责的测试项目 ，采取的开发模式是每周一次提测 ，每次提测一到两个模块 ，由于是新项目，故bug会多了一点 。但如果让你在一天内发现30个以上的bug ，这个其实也是比较难的。而且当测试的功能多了，提的bug多了 ，最容易就是乱。 到最后连你自己都不知道测试的如何？覆盖率如何 。 那么，该如何保证效率的同时，又能保证测试覆盖率呢 ？
以下是本人在测试过程中的一次经历 ，在一个小时内发现10个bug ，半天内提交48个bug的经历 。最快时相当于每6分钟提交一个bug ，除去提交一个bug的时间大约花2~3分钟 ，发现一个bug的实际时间大约也就2~3分钟
将上面的经历总了一个小的总结 ，具体如下 ：
方法1 ： 清除数据 。
数据可能是测试人员接触最多的，每天会创建各种不同数据，有正常数据、异常数据 ，业务数据、流程数据等。很多bug其实就是使用了不同的数据才发现的，比如测试人员使用最熟练的就是特殊字符，只要是个输入框就要输入特殊字符试试 。但是测试数据多了也会比较麻烦，很多数据最后都变成了垃圾数据了，造成一些测试影响。
所以，第一个建议就是每隔一段时间清除一遍业务数据 ，防止这些数据的干扰和影响 。 由于数据被清空 ，所有功能都的重头开始测试，在这种情况下，往往能发现一些之前没有发现的bug 。这些bug基本都在初始化状态下才会出现的 。
第二个建议就是你最好写了一个SQL清除脚本 ，因为清除数据是定时要做的，每隔一段时间做一次 ，所以你后面使用起来就方便多了 。每次清除时只需执行一下就可以了 。
方法2 ：数据设置规则
很多测试人员在添加数据时非常随意 ，他们测试一个功能往往是在每个字段中随意输入几个字符，添加上这么几条数据，查看下显示没有问题，这个功能算验证通过了 。
这种测试方式除了没法保证覆盖率之外，最主要的就是数据多了容易乱 ，如果数据之间相互调用那就更乱了 。 所以 ，建议将数据设置为一定规则 ，给数据设置规则至少有两个好处 。
（1）可以快速统计数据的覆盖情况 ，比如你要输入的数据中包括中文，英文，特殊字符 ，长度的边界值 ，各种分类的数据。这样你就可以某一个字段中标记要覆盖的数据类型，要覆盖的。具体如下 ：
（2）规则可以让我们快速的测试 ，因为有很多数据需要分类，只要一分类，如果不给数据设置个规则 ，数据多了就特别容易乱，严重影响测试。 比如下面的这个功能 ，每个运营商都会有ICCID号，而且这个号在其它功能中也会多次使用，如果你随便填，在其它功能使用就容易乱 。所以 ，我会按运营商给它编号 ，比如移动编号从A100开始 ，联通从B100开始，电信从C100开始 。后面使用时我只要看字母就知道是那个运营商的的ICCID号 。
方法3 ： 验证功能逻辑
有时候 ，当我们完成一个功能操作后 ，往往会在好几功能中有所展现 。比如完成一个支付操作 ，你会看到有支付记录 ，同时也会账号金额发生变化 ，并且在统计中也会有订单数统计等等 。
所以我们往往测试一个功能， 从点击按钮开始，到返回数据的期间，系统在此期间系统做了什么？ 如何能体现出来 ？在哪里体现 ？这些都是我们要验证的逻辑，在这个逻辑中，最重要的则是我们看不见的那一部分 ，即点击按钮后服务端所做的业务处理 。
要了解这部分的业务处理，就需要以白盒的视角去看系统的内部处理 ，这样你才能覆盖到它的真正逻辑 。 这里推荐一种测试方法，探索式测试 ，个人认为验证这种内部逻辑实现有很大作用 。
这种测试方法简单的说就是通过一边验证， 一边学习(学习业务逻辑)，从学习中获得反馈，从反馈中计新用例进行继续验证 ，如此循环验证，只到你认为这个内部逻辑已经非常熟悉并且已经没有问题即可结束。
方法4 ： 回顾覆盖率情况
覆盖率是在测试过程中是必须要考虑的，在测试过程中，至少要从两个方面进行考虑 ，即功能覆盖率 ，其它类型的覆盖率 。 每一种类型又都可以细分子类 ，比如我会把功能分为功能操作 ，功能逻辑 ，功能交互 。每一种子分类都是事先总结好的，有那几种情况 ，使用那几种方法，到时候使用即可 。
然后将细分到子类的测试类型和功能进行正交，得到了要测试的范围 。你所要做的就是按照范围去进行覆盖 。一般这个测试范围我都会使用一个表格来维护，以实时的了解当前的测试进度，同时只要是进入到测试阶段都会每天发测试日报 。
最后，通常每天测试完都要评估下覆盖率 ，因为有时候你没有去执行测试用例 ，这种情况下你更的评估下覆盖率 ，测试了那些模块 ，是从哪方面进行测试的 ，应该还有那些方面没有覆盖到 ，最后记录到覆盖率表中，随同日报一起发出去 。
方法5 ： 易用性测试
按照ISO9126质量模型 ，我们说易用性主要包括：易理解 ，易操作性 。
所谓的易理解，主要是能使的操作的用户更容易理解 ，比如各个界面的提示一致性就能提升用户的理解度 ，再比如像下面这样比较模式的字段加上注解也能提示用户的理解度 。
如果你是自己测试，这些易理解性都可以从bug中总结出来，所以 ，建议你测试完多总结bug，肯定对你发现bug有一定帮助 ；另外一个方法就是多关注好的产品的设计，比如你现在测试一个电商网站的添加地址提示框 ，如果你觉得不太清楚这个提示框是否合理 ，你就可以参考京东、天猫的网站，看看人家的设计，然后也可以见解过来 。
易操作性，主要遵循一个原则就行，就是减少用户的操作步骤，比如设置默认的数据 。像下面这个bug，如果你不知道这个易操作性，很多人是发现不了这个bug的(虽然简单)。总之，只要能通过一步搞定的就不需要两步，能不需要操作的就直接省了操作步骤。比如百度以前需要搜索关键字搜索，现在直接给你把热点展示出来，你可以直接点击查看，省去搜索步骤。
方法6 ： 效率提升
一提到效率，很多人首先想到的就是自动化 ，但自动化测试只是提升效率的一种方式 。只要能提升测试效率和质量。无论是策略，方法，脚本，工具都是值得见解和学习的。
提升效率和质量的需求其实就来至于我们平时的测试中的痛点。只要在平时测试时就要注意细节、注意观察。这些需求是不难发现的，比如：观察在执行时那些地方会占用时间，那些地方测试起来不方便。这些费事费力的活可否优化？如何优化？目前市面上有那些好的实践。这些测试痛点，正是我们优化和改善的地方 。
以提升效率为例 。在测试过程中，如遇到构造数据不方便 ，那就可以编写个脚本自动生成测试数据 ；比如有些功能需要大量运算 ，人工算起来太费劲 ，那就编写工具来代替你运算 。
下面的截图就是我说测试的项目，添加数据时不方便的一个例子 ，若让你手工添加这些数据，肯定很不方便 。但是若让你写个脚本解决的话，相对来说就轻松搞定。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
