测试流程规范(功能)

刚入门,理解有限,欢迎讨论

这里将测试流程简单分为4个阶段:需求阶段、测试准备阶段、测试执行阶段、总结阶段

每个阶段对应不同的“目的、测试工作内容、关注点、产出”

每个阶段的工作内容,可以视项目紧急程度适当灵活调整

 

一、需求阶段(目的:让项目多方人员对需求的理解达成一致,方便后续工作交流)

内容1:阅读需求文档,结合产品设计图理解需求

  关注1:需求不合理的点

  关注2:需求不明确的点

  关注3:自己不明确的点

内容2:参加需求评审,在评审过程中提出自己的疑惑点

  关注1:解决上述疑惑点

  关注2:深入理解需求

  关注3:记录评审过程中未解决的点

内容3:梳理需求,将需求不明确的点以文档形式记录,同时进一步熟悉需求

  关注1:记录上述未解决的点

  关注2:记录梳理需求中不明确的点

    产出:《测试需求反馈表》

内容4:反馈跟踪需求,将上述产出提交给产品,持续跟踪反馈结果

  关注1:根据公司对应流程进行提交(例如:通过Ones以bug的形式提交给对应产品)

  关注2:若元素需求有变动,需提醒产品更新到需求文档,需提醒设计更新设计图

内容5:明确测试任务

  关注1:测试时间和测试范围

  关注2:对应开发人员及产品

 

二、测试准备阶段(目的:尽可能覆盖所有测试点,保障软件质量)

内容1:根据最新的需求文档和设计图,编写测试用例或提取测试点

  关注1:根据时间来确定是编写用例还是提取测试点

  关注2:测试人员应确定回归测试的范围,体现在测试用例(测试点)中

内容2:组织人员进行用例评审

  关注1:完善测试用例(测试点)

  关注2:提高设计用例的能力

内容3:熟悉对应的数据库

  关注1:梳理本次功能涉及的数据表

  关注2:梳理表中各字段的意义以及数据流向

 

三、测试执行阶段(目的:有条不紊的执行测试,推进软件开发完善的过程,保障最终能成功上线)

内容1:开发交测后,先进行一轮冒烟测试

  关注点1:确保主流程畅通,如果不通,以文档形式记录下来

    产出:《冒烟测试反馈表》

内容2:对接开发,沟通本次迭代修改的范围及可能影响的功能,完善回归测试

内容3:按照测试用例(测试点)执行功能测试,发现与预期不符的地方以bug的形式在平台上提交给对应人员

  关注1:确定好修复优先级

  关注2:标题和描述尽量清晰简洁

内容4:测试过程中,遇到未覆盖的点,及时补充到测试用例中(测试点)

  关注1:与已执行的用例做好区分

内容5:验证已修复的bug

  关注1:验证前跟开发确认,测试环境是否为最新代码

  关注2:验证时间在开发解决并发包的第二天之内完成

  关注3:bug解决过程中,如有分歧,记录下来,将该问题和产品、开发形成三方解决方案

内容6:所测模块的bug全部验证后,进行回归测试

  关注1:根据上线时间灵活决定是否全部修复(未正式上线项目)

  关注2:回归测试包括上述关联功能的回归以及固定流程的回归

内容7:不同功能负责人进行交叉测试

内容8:上线前验证(再次回归)

  关注1:上线内容

  关注2:回归内容

内容9:上线后测试(线上测试,一天时间)

  关注1:上线内容

  关注2:回归内容

  关注3:随机测试

 

四、总结阶段(目的:逐步修复自身的测试盲点,提升测试水平)

内容1:项目基本信息

  关注1:项目名称、测试时间、测试内容(具体到功能或需求点)

内容2:数据总结

  关注1:测试用例数(测试点可不做统计)

  关注2:补充用例数

  关注3:漏测bug数

内容3:经验总结

  关注1:测试思路的梳理补充

  关注2:测试过程中遇到的问题以及解决方案

内容4:产出《测试报告》

posted @   Gemoo  阅读(98)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示