17 | 测试左移：测试如何应对新的开发模式？

1. 测试左移和测试右移是在市场激烈竞争情况下的必然结果，做不到的话，迟早会被淘汰。 2. 如果项目在用成熟的敏捷开发框架进行项目管理，团队中测试人员的比重会越来越少。 3. 在做项目计划的时候，尤其是让开发人员给时间评估时，必须要为单元测试和自动化测试预留时间，一个功能可以交付的标准不仅仅是实现功能，对应的测试集也是需要包括的，这部分需要管理层有一个思维转换。 4. 软件开发团队变为全栈开发全队的趋势越来越明显，全栈开发不止是对传统开发人员你的要求，也是对测试人员的要求，测试人员可以考虑扩展技能，例如自动化测试、运维、项目管理等，不要让工作中的角色限制我们未来的无限可能。

关于这个所谓的后端全栈。刚好有过思考，分享下。 从经济学角度看，社会分工可以实现专人专事，进而解放生产力，让总收益更大，所有参与方都受益。但是分工就会有沟通协作的成本，工序多会增加出事故的概率。那么为什么以前强调分工，现在又推崇垂直整合呢（去qa和devops的理念）。我认为是软件稳定性诉求和软件工程开发模式共同决定的。以前，软件的用户体量小，事故和不可用的影响较小，并且开发模式大多是瀑布开发，时间上也比较经得起折腾。而现在，大的互联网公司，用户体量都是千万，亿级别的，系统稳定性诉求就高，往往都要4个9，5个9，且大部分推行的都是敏捷开发或伪敏捷开发，进而对系统稳定性和迭代速度的诉求就有了新的挑战 。而依旧保持分工的模式对接不上这个变化（天时），同时测试运维经过这几年的发展演变，也推陈出新有了很多新技术新框架，开发要学习测试运维技术栈的成本已经可以接受（地利），最后，新技术的轻便学习成本低，加上程序员的高薪，进几年也涌进了大量新鲜血液到互联网行业（人和）。故，这种垂直整合的模式一推出需求（去qa和devops），就有大批技术人员调整技术栈去迎合变化。而在精益开发，企业中台建设的推进中，甚至连产品思维也可能会落到开发的技能树中。

管理团队理念的改变至关重要，将传统智能团队重组成全栈团队，不然很多实践只能流于表面

测试左移是 TDD/BDD 能充分发挥作用的地方了。右移大部分时间应该在预发布环境（共享生产环境数据）进行测试。

测试左移和右移，减少了耗时长的功能测试（例如从3个人变成1个人），增加了自动化测试（例如从1人个变成2个人），提升了测试的效率，总体上应该是减少了测试人员岗位数量。 作为测试人员，要用全栈开发的标准来要求自己，不仅要横向发展，也要竖向发展。例如在学习多种测试技能（功能测试、自动化测试、性能测试、安全测试）、完成本岗位工作任务的基础上，根据个人和公司的情况向运维、开发、需求、项目管理等领域渗透拓展。

有个问题请教一下 ，现在我们的代码管理有开发分支，测试分支和发布分支 ，如果现在开发左移，让研发参与更多测试工作的话 ，则还需要有一个供研发自测的测试分支吗？因为如果在开发分支上测试的话，代码频繁提交会影响测试的有效性。盼复。

测试左移能否成功，依赖左移的测试工作量是不是能被工具化和研发人员自测消化掉，不然就累死QA了（去QA，哈哈）

测试左移和右移，对于测试来说是好事情，可以掌握整个需求的全面性，来源以及价值。 但是目前会存在一个问题，就是没办法完全依靠左移来提高原来竖井模式的测试效率，测试既要左移，右移，又要进行测试。比如正在进行一个项目的测试，此时产品又提了几个需求，测试陷入车轮战，会很疲惫。

测试左移可以提高开发测试比么？ it depends，它俩没有绝对的因果关系。切记。哈哈。

我们是这样管理分支的，请老师看看有没有优化的空间： - Master：线上版本对应的主分支（Master 分支的头指针指向当前线上版本） - Release：每个 sprint 的开发、测试主分支，可以理解为不同迭代的计划上线分支，也称为 Sprint 分支 - Feature：用于研发开发自己的特性 / bugfix 分支。 一般只对研发可见。 - Hotfix：用于对线上问题进行热修复的分支。parent 是当前 Master 分支。 具体的操作方式如下： - Master 主分支是一个受保护分支，绝大部分情况下只应通过持续集成工具进行合并。合并的时机是 Prod 上线完成， - Release 分支是目前按 Sprint Name 定义，例如 sprint-101，表示第 101 个迭代对应的 sprint。 - Feature 分支从计划发布的 Release 分支上拉出单独的 Feature 分支进行开发。Feature 开发完毕以后，提 Merge Request ，请求将对应分支合并到 Release 主分支。Merge Request 提出以后，会触发 Pre Merge check，待 merge 的版本会在 Gitlab 先进行一次 local CI（主要是单元测试），并将结果更新至 Gitlab Merge Request 页面中。若 Pre Merge Check 通过，研发负责人 review 代码，review 通过后合并代码到 Sprint 主分支。若 Pre Merge Check 不通过，Merge Request 提交人修复后重新提交。 环境维护方式如下： - 研发人员在 Sprint N 结束时将 Sprint N 分支的当前版本更新给测试人员。 - 在 Sprint N+1 开始时 - 研发人员基于 Sprint N 的版本，拉出 Sprint N+1 的主分支，开始下一个 Sprint 的 Feature 的对应开发。 - 测试人员发布 Sprint N 的版本到测试环境，开始测试。测试过程中若发现 Bug，提出 Jira，指派给对应的研发人员。研发人员按相关流程修复以后，还应 Merge 到 Sprint N+1 分支。 - 研发人员按需将 Sprint 分支的当前版本更新到 Dev 环境，用以联调。 Dev / Test 环境有常规的 CI Job 对当前 Sprint 版本的正确性进行校验（每日的 1830 / 0630 执行）。对于集成自动化测试的测试用例，也有一个和 Release 分支相对应的分支，用于编写当周实现的功能的自动化用例。 其他注意事项 需要有节点检查当前的版本是否包含 master 分支上的所有改动，目前 check point 通过以下方式设置： - gitlab server 上设置 pre-receive hook，检测每次提交是否包含 master 当前最新版本 - venus 提交发布工单时，检测当前版本是否包含 master 当前最新版本 - 未上线的 Release 分支的所有变化(bugfix，临时插入的需求等），都要被所有后续拉出的活跃 Release 分支 Merge