公司发展过快导致的产品、开发、测试问题分析
前言：
我们公司是刚成立不久的公司，随着公司的不断壮大，暴露出来的问题也日益显著，以老生常谈的测试人员、开发人员、产品经理（项目经理）之间的矛盾为主，主要是部分开发的代码质量不高，导致发布频繁，测试需要不断的做回归测试；各个节点没有版本控制的思想，产品和项目经理没有提前规划每一次迭代需要迭代的内容，当然我们应该做出产品/项目的标准的版本管理，在这方面做过两次努力，最终都以失败告终（有标准版本控制的可以忽略此篇文章），基于这种背景下，怎么样才能最大化的缓解这个问题，我们想出了自动化测试的方法检验开发的代码质量和折中式的版本控制方法，自动化测试的主要方式将在下期给大家分享，下面给大家分享一下我们针对代码质量做的一系列的工作，和版本控制的一些方法。
一、代码质量
1、针对开发代码质量不高和开发不进行自测导致的质量的问题，我们的扫描规则是sonar默认的。不只是sonar扫描的白盒层面的问题，在功能上也存在很多问题诸如：bug不进行修改直接指回给测试，一个小bug修复完成了大bug，等诸多开发不自测问题。我们在jenkins上安装sonar插件（代码扫描工具），对开发提交的代码进行扫描，结果可以给大家看一下，问题特别多：
2、除了sonar扫描的工作，我们还把jmeter加到了pipline的管道流水线里，来进一步保证我们测试接到的测试代码是相对较高的一个质量。保证jmeter覆盖的主要接口是没有异常的。简单来说就是一构建就会自动执行接口自动化脚本生成测试报告，如果测试报告中存在异常接口，则需要进行代码回滚，修改完异常接口后，再重新进行构建操作。测试报告例子如图：
3、测试介入前的提测环节，开发/产品/项目提前确认好提测时间，开发提前准备好提测需要用的演示数据，对提测的模块进行冒烟测试，测试人员针对冒烟测试的结果判定提测的结果。
二、版本控制
1、最好的方案就是从产品or项目经理开始，制定流程性的版本控制方案，但是对于没有版本控制思想的人员来说，不容易被接受，会被误认为增加无用的工作量，我们的方案被否定也是这个原因，一般是运维制定相关的版本控制流程。
但是如果没有形成标准的版本控制方案，就是真的在给下方流程的人员造成多余的工作量，虽然属于下策，但也是有成效的。
2、开发人员控制版本：
首先开发主管确定此次迭代的内容，同时还须控制发布版本的频率，待迭代内容基本完成可以测试的时候，由开发主管统一要求各个开发人员提交代码，提交完成后，开发主管通知测试负责人，进行构建，然后测试负责人查看相关的测试报告，查看代码质量，质量可以（sonar扫描无bug）接口自动化覆盖接口无异常，测试人员更新版本号及版本内容，可以进行下一个环节，也就是提测。下面就是正常的测试流程了。
3、测试人员控制版本：
测试人员控制版本算是最后的一个补救的环节，也是最难掌控的，开发人员提交代码后，告知测试人员满足测试条件了，测试人员进行构建，查看代码质量，质量可以（sonar扫描无bug）接口自动化覆盖接口无异常，测试人员跟开发主管确认此次迭代的内容或通过代码提交的注释确定迭代的内容，进行记录，形成版本号，然后将结果反馈给开发，告知是否符合提测条件。符合提测条件，继续进行，否则代码回滚重新发布。关于发布的频率，这里就很不好控制了，开发只要改完就会提交代码，就需要测试/运维发布测试版本，发布的频率就会很快，而且会频繁的打回，但是也恰恰能说明，测试的工作做的是到位的，开发会思考为什么被频繁打回，从而形成良性的循环。
4、关于bug修复的版本控制
在测试过程中很多开发改完bug以后直接提交代码，并在bug管理工具里标记bug的解决情况，这个在开发眼里是属于一个正常的流程，但是对于测试来说，这种情况能不能测试，取决于代码是否更新到测试环境，当测试人员不清楚的时候进行测试，就会频繁的激活bug，造成开发和测试扯皮的显现，相信这个问题也是大部分创业型公司都会经历的一个过程。
bug修复的版本控制，在这里说一下我们的解决方案，希望可以帮到大家：
按照版本控制的结果，不管是开发控制还是测试控制，测试人员只需关注当前迭代版本的bug是否全部解决完成或基本解决完成（遗留了部分无逻辑性的bug），然后测试人员可以进行构建测试，可以减少回归测试的成本，当然这个方法有优点，缺点也是很明显的，就是需要等开发解决bug，这段时间是测试的空档期。当然这段时间可以安排其他工作。
以上就是我们现在出现的问题的一些解决方法，欢迎交流沟通~~~