软件测试培训之测试阶段及项目流程

软件测试培训之测试阶段及项目流程

第一阶段，产品需求评审完成，开发团队实现功能开发，然后草草提测，不写单元测试。测试人员进行人工测试，没有工具或系统做辅助，测试用例编写是在excel或脑图中呈现。这个阶段只对业务熟悉，开发只关注功能实现。

第二阶段，产品需求评审完成，开发团队实现功能开发，写自身功能相关的单元测试，组长review组内代码。测试方面，依然处于人工检测功能测试阶段，但开始有一些相关的小工具辅助测试。在两轮或多轮测试情况下，回归一直是一个问题，还有分支测试完成，主干回归的过程，测试环境、预发布环境、灰度环境、线上环境等测试回归效率很低，人工测试在这方面的不足格外明显。

第三阶段，随着业务的发展产品功能需要快速上线，同时系统技术不断迭代，质量也面临着从未有过的挑战，人肉战术不是长久之计。在此阶段部门做了很多改进，引入和开发了很多测试辅助工具，如项目管理工具、测试用例管理工具、BUG管理工具、自动发布系统、自动打包等。

搭建测试用例管理工具，方便编写及后期跟踪用例。一轮二轮测试人员如何分配;用例状态的管理是通过、挂起还是失败，一目了然。

BUG管理工具，主要是给开发和测试人员使用，通过文字和图片结合的方式描述功能问题，减少了开发和测试的沟通成本。

项目方面也开发出项目管理工具，方便查看项目状态和人力资源情况，在项目中做到很好的呈现。

在此阶段我们开始研发UI自动化测试工具，直观的想法是减少人工测试成本，提高测试效率。

自动化部署系统让开发环境、测试环境、灰度环境和线上环境做到很好的隔离，每个阶段更清晰，避免相互干扰引起的问题。

APP方面结合Jenkins可以实现自动打包，测试起来做到了开发和测试都以版本控制系统为主。

第四阶段，因为测试往往是最后一个环节，风险较大，“怎么实现降低风险提高人效，测试用例可以复用”变成了我们这个阶段的主要工作。之前的流程是开发完成提测，做一次冒烟。因为我们的产品是互联网金融APP，APP有服务端开发和前端开发，像web、wap、anroid、IOS等渠道，在研发过程中经常会出现以下场景：

需求只是项目中的一小部分，测试问产品要不要全量测?产品担心这次需求的研发会影响到其他部分，就要求全量测试，于是测试的工期会拉得很长，拉长了需求的整个工期。

测试抱怨开发的BUG多，还有阻塞流程的BUG，需要等待开发解决BUG后才能继续测试，导致整个测试工期加长。

手工测试偶有疏忽造成漏测试的点，需求上线后，客户反馈BUG。

产品上线时间有deadline;测试时间长，挤占开发时间;测试人手不够;测试的准确性达不到要求...要解决这些问题，必然要做自动化测试方案。

针对业务和测试开发同事的特点，我们从单元测试、接口测试、UI自动化测试三个方面做了有效衔接和可持续使用的自动化测试方案。

服务端开发完成，接口测试开始介入。接口测试前期使用一些小工具，会在小工具里写一些脚本，来方便测试过程中的功能多次回归检验，是否有更好的方式来做这件事，于是我们搭建了接口自动化系统。之前测试是只对UI界面做功能测试，我们现在还实现了单元测试、UI自动化测试、接口自动化测试。

第五阶段，测试团队全部人员转型测开，部分成员处在人工测试和自动化测试的边界上，实际上我们一直在做内训，让团队整体能更快地转型成为一个测试开发团队。这个阶段对成员要求相对较高，主要技术语言是python，还要对基础的系统架构及运维知识有更多了解，团队内部正在开发测试项目看板、重写用例管理工具、升级接口自动化工具等，后期计划实现APP多设备管理及测试。还有一些测试没有提到，但也包括在主流程中，比如安全测试、兼容性测试、分辩率测试等。

目前项目的整体流程是这样的：

产品通过DM上传PRD，参与人员熟悉需求。

开需求分析会议，确定需求最终版。

需求定稿后，开发人员抽象基础功能、编写UI部分，测试人员通过testlink写测试用例。

测试用例编写完需要产品、开发、测试人员做测试用例评审。

开发人员根据测试用例，编写自己具体业务的单元测试用例。前端人员和自动化测试人员制定UI自动化测试点，定义好断言字典和模拟用户行为的方法名称，自动化测试人员编写自动化测试case。

开发人员开发的同时，接口测试人员根据接口文档，编写接口测试用例。

所有编码工作完成，开发人员单元测试通过后，进行接口测试验证，再进行UI自动化测试验证。UI自动化测试既要测试当前需求点，也要回归以往的case。

验证都通过后，手工测试人员介入。

手工测试完毕，自动化CASE反复测试通过的情况下，进行上线。