小酋测试:版本提测,你需要知道的事儿

在产品测试中,开发提测版本时过于简单,信息传递不明确,容易造成测试后期执行不顺畅,从而增加测试与开发沟通成本,如以下案例:

1、某一功能优化,服务器端新旧功能由两个不同的开发完成,涉及两个不用的测试服务器。新功能提测的时候,开发未说明测试环境,测试延用之前的旧服务器,发现部分功能异常,测试针对该问题进行定位、沟通占用了较长时间,最终确认是测试环境问题~
2、开发提测模块list信息不详细,测试无法明确哪些提测了?哪些没提测?

问题虽小,但积累多了就占用成本,于是需要测试与开发约定提测内容规范。

小酋测试:版本提测,你需要知道的事儿

下面对版本提测内容做下总结:
1、基本内容
要求说明:
版本号及版本提交的时间
②本次版本(每次迭代也算一个小版本)实现(修改)的功能点一一列出
各功能负责开发人员
④未提测模块及预计提测时间说明;

2、对应版本的代码分支路径信息、打包路径或编译后的文件(如Android应用apk包)等。

3、如果涉及到配置安装软件或环境的,还应该有相应的部署手册(或环境配置说明)。
部署手册(环境配置说明)测试要求:
①应该尽可能详尽,如果测试人员发现bug,也应记入缺陷管理系统。
②测试人员严格按部署手册进行环境部署,如因部署手册出现问题导致后续步骤无法进行的,应打回相应开发人员重新提交版本,并邮件通知大家(包括直属领导和项目决策人)。
③如果部署手册出现问题,但因为项目时间紧急,测试人员能自行搞定的,也可以部署后把缺陷记录上,在下次回归时做测试。
④部署手册不能由测试人员修改,部署手册出现严重问题影响用户安装部署环境的,测试可反对发布,并邮件通知大家。

4、如果涉及到数据导入(比如大量数据测试),还应该提供相应的sql执行语句;还包括数据库的定时任务、储存过程等。

5、开发单元测试用例和自测报告。

6、如果涉及到用户使用手册、还应该附上用户手册等。

7、版本其他(如shell脚本、涉及到的插件等)。

8、影响范围,即代码实现(或变更)的影响范围说明。

以上都应该分类固化下来,过后每次提交版本后都应该有一个版本检查测试。根据实际情况,以上版本内容可以经过大家一致同意后做适当的增减

最后,提测申请应该以邮件的形式发送给大家(包括测试负责人,测试执行人,项目决策人)。

当测试拿到提测版本后,首先需要检查提测内容项是否完整、齐备,无误后则开始做冒烟测试。

其中某一个环出现问题(如功能出现大缺陷,导致后面功能不能使用。或部署手册有问题,不能按上面完成环境部署等),导致后续没法测试或测试困难的,直接打回开发重提版本

烟测试通过后,再进入正式测试阶段。这样规避了开发提测质量过差,浪费过多的时间沟通。



留言