作为软件测试人员，本职工作就是帮助完成质量保障工作。但是当下不论ToB还是ToC，目标都是为了更快的获客，更快的满足客户需求，这就给交付时间下了死命令, 熟悉软件开发流程的人都知道，软件测试基本属于最后一环，中间发生任何变故，都会导致延期。为了完成交付，只有牺牲测试时间。所以软件上线后事故多有发生。ToC在应对这一块有很多成熟的应对办法，如灰度发布逐步放量，快速回滚机制，可以避免造成不可挽回的后果。此外ToC环境单一，复现问题相对容易，也给排查解决问题带来便利。ToB相对来说复杂一些，每个客户版本不同，升级更新频率也无法控制，每个客户数据差异很大，环境也不相似，给我们排查问题增加了很多复杂度。
怎样解决呢？我们还是要先分析问题，看看我们当务之急是解决什么问题。我把问题归为两类，一种是版本上线后新功能会引入问题，一种是发版后发现主路径总是存在很多缺陷。
版本上线后新功能会引入问题
新版本上线后，引入很多新功能。由于客户环境差异，使用习惯不同，在测试时间压缩情况下，会引入很多测试场景没有覆盖到。如何解决这个问题，我们可以参考ToC的灰度发布的解决办法。我们可以给愿意尝鲜，并且环境容易连接的少量客户提供新版本，等待客户使用反馈后，再决定是否给其他客户提供最新的功能。
同时对于一些没那么迫切使用新功能，对稳定性有很高要求的客户，我们维护一个稳定版，把主干发现的重大问题，及时cherry-pick到稳定版上，定期发布补丁。但是需要注意的是，由于ToB的特殊性，要求我们不能维护过多的稳定版。也就要求我们及时获得新版本在客户那边的反馈，从而确定是否升级稳定版。
上线后主路径总是存在很多缺陷
这个问题属于是老大难问题，早期时候由于对测试不重视，加上项目管理上疏忽，经常会出现此类问题。项目持续运行几年，也会因为代码重构或者系统部署脚本变更，引入很多重大问题。这类问题有两个解决办法，相辅相成。短期办法，在项目早期收益最大，就是梳理系统的系统的关键路径，在版本发布前进行冒烟测试，在客户更新前发现问题。随着项目越来越大，需要回归的冒烟用例越来越多，此办法收益会越来越低。所以需要第二种办法，持续对自动化进行建设，先覆盖关键路径的用例，并不断提升覆盖率。由于需要投入很多时间持续建设，这个办法在早期roi不高。但是管理者不能因小失大，这个有点类似人工智能的涌现，量变引起质变，等到覆盖率达到一定水平，可以极大提升交付速率以及质量。
最后总结下本文，质量保障是软件开发绕不开的一个话题，也是与交付速率一场博弈。想同时获得鱼和熊掌，在当下环境下很难。我们要做的事，就是小步快跑，在客户前面发现问题，尽量控制客户那边提交的问题数量。
