下面这些问题想必大多数测试同学都遇到过，希望作者的解决方案能给大家带来一些启发。
1.开发经常私自发布代码
先介绍下当时团队的开发模式，我们总共有2套环境，dev环境和线上环境。新需求开发流程是，将master代码merge到dev分支，开发在各自的研发分支开发feature，然后merge到dev分支，提测后，测试在dev环境测试新功能，测试通过后，会让开发给当前测试通过的代码打版本tag，然后将此代码merge到master分支，再进行线上环境的回归测试。
对于质量体系建立还不够不完善的团队，这个问题是比较常见的。和开发同学打交道这么多年，还是比较了解开发私自改代码的动机的。我说几种常见的情况：
1）提测后，开发发现自己的代码有缺陷A，就偷偷修改代码，并随测试同学提交的缺陷的修复代码一起commit到dev分支。说实话，这个还是比较隐蔽的，如果他们修复缺陷A的代码不会引出新缺陷，测试很难发现这个问题的。
2）开发同学发现自己犯了比较低级的配置问题时候，碍于情面，就悄咪咪修改并commit。
改进建议：（1）记录开发“犯错”的次数以及引发的问题，用于约束开发不要私自修改代码，话说再一再二不再三，人都是要面子的，次数多了他们也不敢再乱来，如果还是私自改，说明他们态度真的有问题。（2）采用技术手段监控开发提交的代码-gitlab/github上都可以配置提交/merge代码的webhook，用于监控开发提交的代码并在群里消息提醒。
2.项目漏测频出
缺陷来源分析
我们在进行项目复盘的时候发现，一些漏侧的缺陷明明是测试评审用例中有覆盖到此场景的，而在测试同学执行的用例记录中，漏侧的场景用例也是Pass的，那么为什么线上仍会有此缺陷呢？
和负责的测试同学沟通后，发现有以下几个情况：
- 业务流程不熟悉
- 第一轮测试，A场景用例通过，B场景用例发现缺陷。开发修复后，测试同学对B场景进行回归验证，因为他觉得A场景和B关联性不大，所以没做回归，但是恰恰感觉关联性不大的地方实则有一定关联，导致漏测。
- 执行用例的同学觉得针对功能模块A设计相关的几个测试用例属于等价类，所以在执行其中一个用例通过后，其他用例完全没执行就进行了Pass标记。但是实际用例之间并不等价，导致漏测。
- 我们测试流程是DEV环境全量用例测试，线上环境仅执行主流程用例。正由于线上回归不是全量回归，而又缺乏自动化回归能力，我们也踩了一些环境配置导致的漏测的坑。
改进建议：这个问题也侧面反应两个点，1.频繁的手工测试让人倦怠，测试同学很容易眼高手低。2.没有自动化回归，测试同学的经验如果不可靠，往往付出血的代价。
为了解决这个问题，我们小组采取交叉回归策略。例如一个迭代有A、B两个同学参与测试，在一轮测试完毕后，AB两个测试同学相互交叉测试彼此负责的模块，这样能解决一部分测试人员因工作粗心导致的漏测。
此外，我们团队开始着手接口自动化能力的建设，重点在测试环境自动化回归。3.建立项目文档知识库，缺陷复盘存档。
3.项目初期 发现bug数量多，修复率低，上线频频延期
团队初期由于项目节奏比较快，项目组成员不是在评审，就是在评审的路上，几乎每天都有各种项目相关的会议，大家都在赶项目上，而忽略了项目过程遇到的流程不健全的问题，最大的问题就是对开发的“宽容”（现在想想，真的是对开发的宽容就是对自己的残忍），具体点就是没有要求开发冒烟测试，开发自测完事后走一遍流程就提测了，而测试过程发现缺陷比较多，而且reopen的缺陷比较多。
当然，针对缺陷比较多的问题，我们自身也进行了缺陷分析原因和归类，大致有以下几类：
- 需求问题产生的bug，需求设计不合理，而直到测试阶段才发现问题
- 开发实现和需求不一致产生的bug
- 开发自测打马虎眼，对bug睁一只眼闭一只眼
- 开发新人对产品功能不熟悉
- 环境问题导致的bug
下面分析一下第3点，如果开发对自己开发代码多些责任心，自测质量高一些，会大大降低缺陷逃逸到测试阶段以及reopen的次数。而项目质量的提升，不能完全只靠“测”，离不开测研协作，推动开发高质量自测就显得非常重要。
而鉴于此问题的严重性，我们和开发同学沟通制定了三板斧策略：
- 推动开发高质量自测，不管是缺陷修复还是功能开发阶段。
- 设置项目提测门禁，冒烟测试用例100%通过方可提测。
- 给开发打质量分，初期我们给开发打质量分的指标也比较简单，主要针对缺陷统计侧面评估开发质量，当然每个项目的开发质量分会和开发leader反映问题所在，目的在于提升开发质量。具体质量分依赖的指标见图表。
4.测试过程发现了需求之外的缺陷如何处理？
随着业务压力越来越大，老板也给我们很对外包招聘名额，后续团队陆陆续续增加到7人，其中6个外包，当然并不是每个项目都是6个人一起上，而是将其划分了3、2、1的模式，其中3个人cover一个较大的项目，2个人cover较小的项目，1个人是自由人，主要承担线上反馈问题处理以及随时补位。较大项目一般2周发布，小项目一周一发。由于两条项目线并行的问题，这样就出现了A项目的测试同学负责的项目发现B项目测试同学负责过的版本存在遗漏的缺陷，而对这种问题，我们分情况处理：
- 如果测试过程发现历史缺陷，产研测会将此问题抛出来，评估严重程度以及修复成本。(1).严重程度决定是否修复; (2).修复成本用于评估额外的项目成本是否对项目整体造成延期的风险。
-
- 如果缺陷比较严重，修复成本比较高，则会延期修复。
- 如果缺陷不严重，则根据开发测试意愿自己决定是否修复。
- 如果A小组负责项目上线后，发现了B小组测试的项目版本出现缺陷，则缺陷责任人属于B小组测试人员。
5.开发过程需求经常变更
你是否也遇到过类似问题，开发实现的产品和交互设计的不一致？问了开发原因才晓得是产品单独找开发更改需求了。。。
当然并不是说 需求不能变更，需求问题在任何公司，我想都是不可避免的。因为随着系统复杂度的不断提高等原因，产品同学确实不太容易考虑完全。
该问题也比较常见，对项目的影响：
- 提测前需求变更，导致开发过程不流畅，且会存在设计变更的风险，缩短开发时间，影响开发进度及项目质量。
- 提测后需求变更，影响开发新版本的流程及开发修复bug时间，影响QA的测试进度。且需求变更容易引出新的问题致使项目质量不可控。
需求变更直接影响是，增加项目不确定性风险。
解决方案：
针对需求问题，我们通过以下措施去推动解决：
- 硬性要求，需求变更必须通知到研测，三方共同拍板，并重新评估项目排期。
- 测试角度，产品同学提前发需求文档，鼓励测试同学在需求评审的过程参与需求测试，多思考异常场景。
- 产品角度，避免需求文档中出现不确定、同上等模糊不清的说辞。如变更需求，PRD应及时更新要有变更记录，避免口头变更。
- 开发角度，避免盲从产品变更需求，应三方确认后，重新更新技术方案，如有必要可以重新技术评审。
- 如未告知测试进行需求变更，测试有理由拒绝测试。
6.线上故障应急效率低以及改进策略
第一阶段：刚接手项目后，就被拉进了很多飞书应急群。要说整个项目过程什么时候是最紧张的，那肯定是项目上线后的第2天早上，因为新需求上线后，可能会有未知的缺陷暴露，所以规定发布后的第2天一大早就要去公司侯着，以随时应对线上反馈的问题。对这是团队最早的应急方式-应急群被动接线上问题，完全属于人肉应急。
除了应急效率低的问题，还经常报一些非代码缺陷的情况，例如网络原因导致的响应延迟问题、用户对新需求不熟悉的问题。当时我们也采取了一些手段来提升应急效率，针对用户对需求不熟悉的问题，让产品同学及时和CQC同学沟通新需求内容；和一线的用户沟通，最好在多个用户能同时复现再反馈到应急群。此外，针对网络等因素的问题，我们还给用户培训如何辨别问题的原因，例如利用Chrome的开发者工具查看接口报错等。再者就是建立缺陷知识库，给缺陷归类并标记tag，让一线用户可以自助找解决方案。
第二阶段：这阶段半自动应急阶段，何为半自动？其实就是给问题自动分配应急人，并通过机器人自动化记录问题，用于每个月的项目质量打分，可以理解为问题自动化存档。
第三阶段：接入字节跳动兄弟团队研发的应急机器人，可以基于知识库给用户自动化推荐相似问题的解法。可以有效排除一些反馈的无效问题，节省应急人的时间。
7.开发只改了一点点，为什么测试需要耗费那么多时间？
也许你也遇到过经常被开发/产品挑战“只改了一点点，为什么测试需要耗费那么多时间啊？”
这个问题在我经历过的几家公司都被开发产品挑战过。这个问题的本质是测试依赖手工测试的局限性。没有完备的自动化回归能力，缺乏有效的精准测试能力，仅人肉回归必定增加无效的测试，也属于测试有效性需要解决的问题。
下面说下我们测试组对测试开发时间比的“争论”以及最终的“妥协”。
第一阶段：没有什么测试开发时间比，因为当时项目多，测试人员少，往往一个测试全包全揽，所以测试时间根据功能测试范围由测试评估，当然测试时间的长短由测试经验评估的测试范围准确性决定。而缺乏有效的评估工具和精准测试工具，有时候经验也不准备，所以有时候项目比较赶有时候比较松。接着我们想到根据用例数评估测试时间，就按每天200个测试用例的执行数，评估一轮测试时间，再加 1人日回归时间，这样作为测试工时。例如600个测试用例一轮测试3人日，加1人日回归，总共4人日测试时间。
第二阶段：后来随着项目的任务量减小，经过高强度项目长时间的浴血奋战，老板发现测试同学手工测试略显疲态，为了缓解这种长时间手工带来的问题，和开发老板一起沟通决定测试开发时间比按1:3排期。这样不管项目大小，其实都给测试留出了一些自主时间可以用于技术提升。
第三阶段：建立接口自动化能力，将业务按主流程划分，全部实现接口自动化覆盖，提升测试效率，可以更快速的测试。
