【总结】版本迭代中，测试人员要做的准备

2018年7月开始我们的项目，截至目前系统已经从1.0.0版本更新到1.3.1，现阶段并行开发1.3.2和1.3.3以及140，测试会并行需要准备几个迭代测试，产品需求已经准备到1.5.0。
上述三位数，第一位数的变动是相当于重构之类的整个系统都有变更，涉及改动最大，这个数会升级；第二位数变动的话，代表在原基础新增一个功能模块，也有可能是业务逻辑变动；第三位数的变更只是以前功能的优化或者小改动，影响不大的优化需求；

迭代需求流程：

1、市场运营根据现有客户需求和业务向产品经理提需求，产品经理整理需求与业务逻辑；
2、产品经理将需求原型以及相关文档，对应的页面设计图确稿后，跟技术开需求评审会议，进行交付技术讨论；
3、开发和测试在需求评审会议之后需要针对现有业务需求，确认完后思考实现流程和准备测试用例，可提出疑问以及存在难实现的点。同时会确定开发完成时间和提测时间，以便产品或者项目经理推进项目进度。
4、如果这期间有时间，会进行一个测试用例评审，这样能确保测试会达到的覆盖率。在开发完成需求实现交付给测试后，测试对已有用例和业务逻辑进行测试，提bug及跟踪修复；
5、测试完成后交付产品进行验收，确定与原需求是否符合；验证没有问题即可安排上线。
以上即为日常迭代任务流程。每一个小版本迭代都有几个到十几个需求拆解，前后端拆分再联调。这期间的时间一般是一个月内，小迭代一般是两周内。这样能避免过程太长造成人员精力耗费产生负能量。

一 、测试工作之前做的准备：

测试要提前设想好各种测试要点，平常开发和产品详解需求时也要听，万一需求有更变或者交互做不了要换交互方式，我们测试用例也要相对跟着改，一个团队真的是要协作起来，不是规定职位就负责一定职责，进自己的力量想到别人想不到但是要做的事，要提供支持和协助，最好自己本职以外还可以弥补他人不足，这样我们才能发挥出一个精英团精神。

二、测试执行之间：

1、保证测试用例全部执行完毕；
2、测试用例覆盖率达到100%；
3、验证新业务逻辑是，还要兼顾是否影响以前业务逻辑的功能。

公司业务个项目都有可对接的数据和链接的业务，可以打通服务，为客户提供更全面的全网联通。基于erp系统业务，产品根据市场需求做了很多功能优化和需求升级，市场的实时反馈和技术的大力支持都是为了客户使用系统更简便，我们的迭代越多，就会有更多体验上需要优化的地方，在这其中测试扮演的角色就是：把关新需求上线前的问题和保证线上客户使用的各种疑难杂症回复处理。

三、测试业务上线后：

项目已经在市场运营，上线企业有60家，他们后面有几万客户，日均在线使用会达到3000左右。这样就意味着如果线上运营发现bug，测试接到反馈需要快速定位同步给开发进行快速修复紧急上线，而市场总会有提不完的需求和deadline给我们。这期间会考验我们的抗压能力和沟通协调能力。

随着迭代经验增多，我们上线前测试基本都全系统重新回归各功能和业务逻辑，也严格控制了bug的流出量。这不仅对市场是一种责任，对我们上线后担惊受怕也减免了不少。项目实行多迭代并行开发，这样能小步快走，测试人员就需要在紧凑的时间内安排多个版本紧接测试，警力了很多次后，个人在迭代经验上、处理事情的方式上、个人情绪把控上都有了很大的提升和改善。

以上是关于项目迭代开发过程中，测试人员会涉猎的一些工作内容概述和总结。