预期目标
一次迭代版本有一个测试报告
测试过程中遇到的问题如下
-
迭代版本没有测试报告
-
测试过程很慢
-
master测试版本混乱太多,分不清谁的版本
Release Notes管理:
-
每个迭代任务必须有对应的迭代版本号
-
每个迭代版本必须在release notes记录,方便测试人员知晓有哪些迭代版本需要测试报告
-
版本记录:(1)bom版本升级(2)升级改动点
开发配合测试如下:
-
需求阶段: (1)需求任务通知:帮助测试能够提前感知需求特性、改动点,通知内容:任务描述、改动接口、功能改动点描述、迭代任务链接 (2)时间通知:开发预估任务开发时间、提测时间,测试人员提前预估测试时间,安排测试计划
-
开发阶段 (1)开发人员提供系分文档,协助测试人员测试分析(注:功能点较小、任务时间进度紧张、bug hotfix不用提供,但是需要向测试说明) (2)如果开发设计复杂,在提测前,召开需求会议,讲解需求功能、改动点及设计(3)输出准则:开发完成单元测试
-
提测阶段
(1)测试方案
正常测试:正常情况下,测试人员进行功能测试、接口测试、压力测试、性能测试、回归测试
开发自测:时间紧张、功能点较小、测试人员无法快速测试、开发自己的技术优化情况下,开发自测
回归测试:一般迭代版本,分支测试完成才进行回归测试,如果版本不进行正常测试,直接要回归测试,请开发和测试一起评估
(2)一般的测试流程:测试准备-->分支测试-->master回归测试
(3)测试准备: 测试人员了解需求特性、分析改动点和测试范围 测试人员提供测试分析文档
(4)分支测试: 开发提供测试分支版本号(linke地址) 开发提供测试的服务器
(5)master回归测试:
串行测试:正常情况下,一个迭代版本回归测试完成,下一个版本才能合入master进行回归测试
并行测试:如果任务比较紧急情况下需要并行回归测试,请开发评估风险,再通知测试人员进行回归测试
注:开发请通知测试人员之后,再合入master,勿造成master版本混乱
4. 测试完成阶段 测试人员输出测试报告