大家好，今天突然想起来我还有2个微信公众号。登录上来后发现已经快1年半没有更新了。

  这一年半的时间过的很快，自从步入35+,发现每天、每周甚至每月都过的很快。周一一睁眼再闭眼，再睁眼发现就是周五了。周末2天根本休息不过来，各种忙碌，2天就过去了。然后再睁眼发现又是周一了，一个轮回又开始了。

  好了，话归正传，2023第一篇微信公众号文章，就要开始了。

  先说点题外话，疫情过去后，大家都以为经济会快速复苏，gdp会像火箭一样噌噌上升，一飞冲天。但是现实却狠狠打脸，经济增速放缓，失业增加。最近刚公布16~24岁年轻人的失业率，已经超过20%了。说明这个年龄阶段的人，5个里有1个是失业的。从脉脉上也是看到各种裁员，各种找工作。之前粗放型经济已经不能持续了，在用户总量接近不变的情况，怎么才能过的稍微好一些呢？就是【降本增效】

   每个行业都在提降本增效，无论是公务员、传统行业还是互联网，都在提并已经落地实施。产研也是一样，今天我们就来说说测试行业的降本增效。

今天我们从2个方面来说说。

   业务线和效率提升

   先说说业务线。整个产品流程是什么呢？可以参照下面的业务线。

   产品收集并提出需求->产品需求评审->研发项目流程图->研发开发代码->测试用例评审->研发提测->测试测试->研发review代码->准备上线->线上验证

   一个产品的流程基本就是这些，有一些特殊的我没有标出，大家可以补充下。在业务线流程，我们有哪些可以提效呢？给大家一些思路一起探讨

    1.产品在需求评审前会和研发一起探讨需求实现的可能性，这个过程一般都不会叫测试。那么测试有必要一起参加需求讨论么？

      建议负责测试这个模块的同事一起参加需求讨论，厘清产品真实的需求，看和产品、研发是否理解有偏差。如果测试同事准备向业务专家发展，个人建议是需要参加的。可以边听边干自己的事情。需求讨论结束后，测试同事在脑中会对需求有个初步印象，对未来需求的测试领悟更深

   2.研发同事在听完需求后，一般都会根据需求/代码，画出合适的流程图。流程图越细，代表他对该业务理解的越深。讲解流程图时测试有没有必要在场参加呢？

      还是建议负责该模块的测试同事一起参加。根据个人参加多场的经验，有时候研发同事理解的和产品要求的，很可能是2个不同的东西。从中可以学到研发开发这个项目的思维逻辑，对自己未来开发平台或者自动化有很大的帮助。

   3.测试用例评审是必须的阶段，无论需求多小，有测试用例评审就会杜绝大部分的线上问题，个人多年经验之谈。对于测试用例，大家都是怎么保存的呢？

    是使用xmind、wiki还是使用excel?测试用例复用性高不高，留存度好不好？这些指标都指向一个方向，就是测试用例平台。一个完整的测试体系，测试用例可以看作是基础，一个大厦的基石。今天时间有限，还在上线中，就不画流程图了。

    测试用例平台的基本要求:

    1.测试用例可复用性。将用例进行拆分，确保即使新同事来测试这个模块，根据测试用例都可以轻松测试。

    2.将测试用例分为N个部分，全量用例、回归用例、核心用例、和自动化关联、和接口自动化关联等。

    3.编写测试用例后，需要进行测试用例评审，评审时会对测试用例进行修正。测试用例评审通过后，会生成测试计划。可以给研发提供冒烟测试用例计划，给自己全量用例计划。甚至可以区分各个环境，如冒烟、分支、预生产和线上测试计划。确保每个环境都能全量测试。

     4.线上bug分析、复盘，覆盖率等也会用到

     5.不同部门的用例都可以录入一个测试用例平台，团队中每个成员录入case的数量、评审和计划数量都一目了然。

4.测试数据的治理

   你所在的部门，线上环境中，可以做到测试数据和线上数据隔离么？如果不能隔离，还有更好的方法来减少对用户的打扰么？经常能看到一些新闻，比如用户收到很多测试push消息，很多测试短信。电商购买商品时发现是测试商品，根本不能发货或者收货。

    1.注册测试账号

       很多时候注册测试账号都是无序的，使用121~129~190等暂时没有的号段。这里就可以创建测试账号规范来约束。比如优先使用多少号段的账号。最好的方法就是使用前先登记，能做到账号和使用者关联的状态。谁绑定了这个账号，谁就对这个账号有使用权，当然了，如果这个账号出现了问题，也需要负责。如果账号有一些违规的情况，会通过巡检立刻将该账号封禁。

    2.线上数据隔离

      最早我司采用的是在测试公司前加上xx测测来区分测试数据和正式数据。但是由于账号的复杂性以及维护困难，后来放弃了这种方法。将测试账号假想为真正的用户，要做到的就是最大限度不打扰线上的用户。

      这里就可以和数据分析师联合，一起找到使用频率最低的情况。比如招聘业务，就可以找公司、HR和求职者人数最少的地方，然后各种命名诡异一些，用特殊的字特殊的词。职位类别用线上用户最少使用的。地区也是用最少人使用的地区。然后线上巡检，如果有用户使用非要求的地区、名称，即刻封禁。

 5.是否需要参加研发代码review

   建议参加，一是可以提升自己的代码能力，二是有可能真能发现代码中的问题。

6.给研发提供自测用例(单独创建对研发的测试计划)

  以前都是给excel，现在在测试用例平台上，不仅可以留痕，也可以衡量研发提测的质量，方便复盘时展示用。

以上是业务线部分提效的方案，后续还会有质量保障体系的提效方案。如果大家有合适的方案，欢迎大家提出。