一/测试早期：
测试质量：
好的质量不是测试测出来的，是需要每个环节的质量管理来提升的。
比如需求输出的质量（需求评审、有效降低有关需求的沟通成本）
比如开发质量（单元测试、Mock测试、静态代码分析等）
比如持续集成的质量（日构建、代码合规性检查、自动部署）
测试环节的就不说了。（https://www.zhihu.com/question/28747711/answer/42426038）
测试计划：
1.首先要有一个合理的详细的测试计划：
没有详细的测试计划，测试部的每个成员都在那儿盲无目的测试，何谈提高测试效率？当然测试计划也不能够太细，太细了，编写测试计划同样浪费时间，做到时可而止。最好是测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度，较为理想。合理配置测试资源。在什么阶段作什么最好，哪些事情提到前面作比较好，哪些事情放到后面比较好，某某任务的前置任务是什么，都要搞清楚。规划好的计划，不至于出现任务A等任务B的窝工现象。
在开始测试前，我们至少要弄清以下几个问题：
a） 要测试什么或测试的对象是谁？
b） 要测试什么问题或我们想要弄清楚或是论证的问题？
c） 哪些因素会影响测试结果？
d） 需要怎样的测试环境？
e） 应该怎样测试？
不同测试版本的测试侧重点（https://www.zhihu.com/question/28747711/answer/1445373578）
对于测试来说肯定需要测试很多轮，每一个测试版本作为一个测试轮，但是不是需要每个版本都做完整的测试呢？答案肯定是否定的，不然测试岂不是要累死？
那应该怎么取舍和分配呢？这里提供一下思路
- 第一轮：只测试大致功能，不需要细测，列出主要bug
- 第二轮：验证第一轮bug，然后全面细测，列出所有能发现的bug
- 第三轮——第x轮：验证上一轮的bug
- 最后一轮：验证全部bug，并全面细测。
测试准备：
2.测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备：
目前来说，可能大家都有类似的感受，接触到的大多数的项目，都是测试周期比较短，开发人员耽误了时间，为了不拖延项目进度，留给测试人员做测试的时间都非常紧张。如果项目测试的前期了解业务需求、了解产品属性和准备测试数据不充分，往往测试效率很低，测试时间变长，测试效率急剧下降。
前期准备包括熟悉需求、了解产品特性、准备测试数据、熟悉开发团队成员等方面。
测试人员一定要提前规划好自己的时间，让自己早熟悉、多熟悉项目各方面的情况。实践经验表明，测试人员越早介入项目，后续测试工作就会越有序和顺利，测试效率和测试质量也就会越高。
冒烟测试（开发和测试人员都要介入）
3.提高测试接受的标准，减少测试版本送测次数：
大部分公司的开发人员都有一种惰性，一旦公司成了测试部，他们自己测试时，都不会那么认真，以为有了测试人员，就自己就解放了。很多时候都是调试编译通过，实际上开发人员没有做完整的自测，就拿到测试部进行测试。如果测试部门有严格的测试接受标准，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试，明显提高了测试效率。
文档评审：用例和开发文档
4.测试负责人认真做好测试文档的评审：
测试经理一定要认真做好测试用例的评审，尽量使用较少的测试用例，发现较多的Bug，无疑是最佳提高效率的一种方式。很多时候，经验较少的测试人员在设计测试用例的时候，写了很多的测试用例，测试时几乎没有发现缺陷。还有一种：比如说等价类的测试，只要具备代表性就可以了，如果写了很多测试用例，执行了半天，臃肿的测试用例，未发现任何问题，也很不值。这些主要是靠测试用例评审的时候，测试Leader去把握了。尽量做到在满足需求的情况下，精简测试用例数量，提高测试覆盖率。很多时候，测试人员写好用例就自己测试,根本没人评审,有些地方理解有偏差,测试点没测试到,导致发给客户版本被退回，给公司也会带来巨大经济损失。
沟通的重要性：
5.测试负责人认真做好测试文档的评审：
测试经理一定要认真做好测试用例的评审，尽量使用较少的测试用例，发现较多的Bug，无疑是最佳提高效率的一种方式。很多时候，经验较少的测试人员在设计测试用例的时候，写了很多的测试用例，测试时几乎没有发现缺陷。还有一种：比如说等价类的测试，只要具备代表性就可以了，如果写了很多测试用例，执行了半天，臃肿的测试用例，未发现任何问题，也很不值。这些主要是靠测试用例评审的时候，测试Leader去把握了。尽量做到在满足需求的情况下，精简测试用例数量，提高测试覆盖率。很多时候，测试人员写好用例就自己测试,根本没人评审,有些地方理解有偏差,测试点没测试到,导致发给客户版本被退回，给公司也会带来巨大经济损失。
自动化工具的引用：
6.按照项目的大小不同，必要的情况下引入自动化测试工具：
是否引入自动化的测试工具，主要取决于测试的时间长短和测试的轮次。一般来说，测试周期较长、版本升级平凡和回归测试次数较多的项目，引用测试工具可以提高测试效率。如果测试周期较短，本来测试周期只有两三个月，开发测试脚步就要花费大量时间，引入自动化测试工具，用的次数较少，结果得不丧失。引入自动构建，即自动编译。个人使用心得，很不错，节省不少时间。
二/管理：
1）.测试部门内部成员的工作业绩数据化：
具体的做法如下：每天给每个人分配的任务非常具体，并且随时关注他们的进展情况，完成百分比，不断督促他们。并且，把每个人每天的工作成果（发现缺陷的数量和工作的质量）数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就加油赶工，形成一种良好的测试氛围。每周周例会的时候，对表现突出的给予表扬，对每次都比较差的下属，单独谈心，问问具体原因。
2）缺陷管理：
1.发现缺陷的质量：
同一个项目组内，我们一般运用测试管理工具TD， 按优先级和严重等级，把每个人的缺陷做成柱状图和饼图，放到一个文档中，邮件发给大家，让组内成员了解自己的工作情况和其他人的工作情况。同时也让开发人员，对每个测试人员的工作，做出评估，供绩效考核时参考。特别是发现非常隐蔽缺陷的测试人员，一定要重赏。
2. 测试的有效性：
一般来说，递交Bug的有效性，体现了测试员是否能够正确理解系统，并发现问题，是否能够发现有效的问题。很多时候，测试人员没有弄准确需求，或者是没搞清楚设计，一旦出现异常，就提交Bug.不是和前面的缺陷相同，重复递交相同类型的缺陷，就是递交无效的Bug，导致后来很多缺陷，都被项目评审时拒绝，既耽误了时间，效率自然不高。
3.测试组员交叉测试，发现漏测问题数量：
经常是这样，一个测试人员测试结束，修复了全部的缺陷。这个时候，测试的模块和测试人员交叉一下，再测试，很有可能又发现很多问题。这样我们可以对测试发现问题数量，进行统计。这样做，就迫使测试人员认真执行每一轮测试，每次测试都不敢懈怠。
4.遗漏到客户缺陷的比例：
一旦版本测试通过，发布给客户以后，客户要对发布的版本进行验收测试。同样会发现一些问题，我们也会对测试过程中发现的Bug分配到每个模块和具体的人。但是，如果缺陷在测试环境中不能重现，只能在实际工作环境中出现，则不属于遗漏给客户的Bug，不计入漏测统计里面。有时候，客户系统在使用中也会发现缺陷，我们同样做好记录。
5.递交的缺陷数量：
在同一个项目组内，每天递交的Bug数量，每周递交的Bug数量，每个版本测试结束，总共递交的Bug数量。最终测试结束，算出每个人递交有效缺陷的百分比。
3）人员管理：
1.执行用例的数量：
同一天，每个测试人员，执行用例的数量。但是一定要去除那些不能够测试的功能模块，或者是被阻塞的模块，这些一定要考虑到。否则大家意见就大了呢！
2.编写测试文档的速度和质量：
每次编写测试用例时，大家都要编写部分模块的测试用例，我们也可以通过单位时间内编写case的数量、速度和质量，来区分每个人的效率，我觉得也是一种好方法。
3.执行用例的速度*用例执行准确率。在测试执行期间，效率体现在执行速度上，但是还要考虑一个用例执行准确率，有的公司有这项指标，就是在执行过的用例中有一个抽查，看认真执行的准确率。
4.平均每天提交bug的数量和质量，这个指标应该是加权的，譬如（A级bug权值*数量+B级bug权值*数量+……）/总天数。