测试基础 聊一聊测试流程

kisom · 2020年12月25日 · 168 次阅读

到了新公司,由于是企业内部孵化的创业项目,各项流程不够完善,总架让我梳理下功能测试流程。
其实测试的工作是会贯穿于各个阶段的,所以一梳理,发现把整个流程都梳理出来了。由于现在还没有预发布/堡垒环境,项目要年后才会对外发布,所以只写到验收阶段。
因为一直使用的流程管理工具都是禅道,所以我们这边很多工作是围绕禅道的。
说得不好的地方欢迎各位大佬指正和各位同学给出更好的意见~
总流程图:

需求阶段:

需求设计阶段,需求设计出原型初稿;
需求评审阶段,前/后端开发负责人、测试负责人及相关人员参与评审,并给出评审意见;(尤其是那种只写一句话但涵盖很多内容的需求一定要打回去)
需求修改阶段,根据评审意见修改原型设计,并更新保真图;
需求拆分阶段,进行需求拆分,在禅道对应项目下建好任务;
ps:之前看 MSTC 大会 2019 的资料,其中科大讯飞的孙玉老师提到需求拆分最后应该是小而精,耦合度低且拆分到最基础的单位。
开发根据拆分的需求任务制定开发计划;
测试根据拆分的需求任务制定测试计划以及测试策略(走几轮测试?是否交叉测试?是否需要做专项测试?是否需要压测?)

设计阶段:

开发完成:程序设计、数据库设计等
测试开展工作:编写测试用例->用例评审->修改用例->用例终稿(在开发自测前完成)

开发阶段:

开发编码,根据禅道中指派的任务按时完成对应模块的编码任务;
开发联调,前/后端联调代码;
开发自测,根据测试给的用例进行自测,保证主流程正常;
当然有些做得好的公司还会搞 codereview、单元测试、代码扫描等保证编码质量;
最后,对应项目负责人在禅道建 “发布” 任务给测试,任务描述清晰描述所要发布内容(配置文件修改/数据库脚本),并指派相应测试人员;

测试阶段:

发布 test,根据开发禅道所建任务内容发布到 test 环境;
新功能测试,根据用例终稿,完成功能测试;
集成/回归/专项/兼容/性能测试(根据测试策略决定开展哪几项):
集成测试基本上必走
回归测试的程度需要视项目的内容而定,多数情况下回归主流程和重点功能,但如果是程序底层优化改造或者是环境迁移那种,就需要全回归
专项测试,主要是 app 弱网测试、app 音/视频质量那些
兼容测试,移动端就是 IOS 版本、Android 版本和各种机型的兼容性,Web 端主要是浏览器兼容性,如果是那种后台系统且大家使用的浏览器比较统一,可以 不去关注兼容性
性能测试,尤其是一些针对促销的版本,必走性能,其他的根据项目特性再做评估

验收阶段:

测试环境测试完成达到验收标准/到了预定发 UAT 的日期 (某个项目验收周期比较长,test 环境的工作未完全收尾,节点日期先发布到 UAT 环境以保证进度),进行 UAT 发版;
发布 UAT:会根据之前禅道创建的发 test 任务建一个发 UAT 的任务,进行发版;
测试会先在 UAT 环境上走一轮,以确保 UAT 发布的内容与 test 一致,如果有问题,UAT 环境重新发版;
若产品/用户验收时发现问题,直接提给测试;若测试判定为 bug,转给对应开发并在
测试环境验证通过后重新发版 UAT;若属于需求中未提及的内容,指给产品做需求变更;
若是用户操作错误、环境异常等引起的问题,测试直接关闭 bug。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册