测试流程中的思考
前言
在我们日常的测试过程中，经常会遇到这样的问题：测试前，我们的计划是A，每当开始实施后，总会遇到诸多问题，使得项目进行的非常艰难。因此在一轮项目测试完成后，质量回溯变得尤为重要。
计划和现实.jpeg
测试中的问题
- 测试过程中需求是否频繁变更？
- 需求未收敛，不断引入新需求？
- 提测质量较差，冒烟不通过？
- 修改一个bug引发多个bug？
- 回归过程中发现之前测试通过的功能又出bug了
- ...
流程规范
百度百科上定义规范是指群体所确立的行为标准。若想要提升团队的合作能力，必要的规范是不可少的。从上面例举的测试中的遇到的问题来逐一分析。
- 测试过程中需求频繁变更。
这里的需求变更分两种情况：-
每个项目在进行过程中，都会发现一些需求设计不合理的地方，但此时已经进入了开发阶段，如果这个时间点再要求开发修改代码，甚至在提测后修改需求，会大大增加项目的风险，拖慢项目的进度。
解决方法：在需求评审阶段，提升项目组成员的参与度，在需求或者交互评审阶段，就需要仔细分析需求，找出设计的漏洞。
举个栗子：
需求变更.png
以上是我测试的一个项目的需求改动，原因是账单类型有技术和人力两种，但是两种类型所包含的字段其实是不同的，因此改动会影响到多个页面的逻辑实现。这样就增加了开发和QA的工作量，拖慢了项目的进度。但实际上这些问题都是可以在评审阶段规避的。
- 开发过程中交互或产品进行变更需求，导致测试时间紧张，甚至延长项目的交付时间。
解决方法：在项目开始前，项目组内部就要达成一致，只有新需求为紧急需求时，才允许加入。并且需要重新评估开发和测试的工作量。如果会造成项目的延期，就要将目前优先级较低的任务延后，延期至下个版本开展
-
-
需求未收敛，不断引入新需求
在开发过程中，还会遇到业务方增加需求的情况。
解决方法：这个就需要我们的PM同学把关，在项目开发之前，就需要确定本次开发版本的需求内容，并在交互设计文档完成后，将手头的交互设计文档与业务方进行逐条确认，只有确认通过后，再进入项目开发阶段，并不再接受新的需求。在进入测试阶段前，需要PM和UI进行走查，走查通过后再进行提测，这样能够有效地提升提测的质量。 -
提测质量较差，冒烟不通过？
我们在测试过程中常常遇到提测后冒烟不通过的情况。就会出现以下的对话：
QA：这个用例没有通过，我点击按钮后没有跳转，这是为什么？
开发：不可能，当时我测的时候是好的，你复现给我看一下。
QA：这里切换tab为什么没有提示？
开发：这里需求改了呀，我和交互说了不实现了。
解决方法：- 首先QA要在测试前详细阅读需求文档，并时刻关注交互稿的变动。但有时候业务繁重时，常常会出现需求改动没有跟进到的情况。这就需要QA和项目成员协商好，任何开发提出或交互提出的变动，必须及时通知到项目所有成员。（可以在每日的站会、或者在项目开发群中进行及时的同步）；
- QA用例写完后，一定要组织用例评审，邀请交互、开发对用例逐条分析，在此过程中，不仅可以帮助开发同学再确认一次需求实现的可能性，还能收集开发童鞋的意见，对我们的用例进行一次补充。
- 建立规范，要求开发的冒烟环境必须和提测环境保持一致，且要求冒烟通过率必须保证达到100%，如果没有达到直接打回。
-
修改一个bug引发多个bug？
经常有开发在修bug的过程中，触发多个bug。
解决方法：QA必须和开发达成共识，建立有效的规范：开发必须对自己的代码负责，在修复bug后，需要在测试环境对bug以及其影响到的功能点进行自测后，再将bug标记为已解决状态，如果QA测试后，发现bug未修复或者触发了其他bug，则需提高jira的优先级； -
回归过程中发现之前测试通过的功能又出bug了
这种情况通常是开发在测试不知情的情况下，对代码进行了改动。
解决方法：引入代码变更覆盖率，并建立完善的自动化用例回归集。这样能够帮助QA及时地跟进代码变更情况，保证项目的质量。
综上分析，我们需要建立的规范重点主要包含以下几个方面：
- 需求必须收敛，开发阶段后不接受新的需求（紧急情况除外）；
- 交互稿出来后一定要和业务方以及开发（important!）进行逐条确认；
- 测试计划和测试用例需要组织评审，其中测试用例需要在tc上简历完备的用例集，并及时进行更新；
- 建立冒烟规范，要求开发自测环境和提测环境保持一致，达到100%才可提测，否则一律打回，并且记录到测试质量报告中。
- QA需要提升能力，引入更多的测试手段，并在质量报告中进行记录，在项目组中进行同步，提升项目质量的信心。
总结
测试过程中多多少少都会遇到一些问题，作为QA最重要的是能够在问题抛出后思考对应的解决方案，在下次的测试过程中，尽量地规避。当然不同的项目遇到的问题也不尽相同，还需要继续探索！
