本文分为两部分:前半部分是理想情况下完整的测试流程,后半部分是精简后的必要流程。
一、完整的项目测试流程:
在理想情况下,完整的项目流程是这样的:
如图,根据项目阶段,划分了产品、开发、测试等主要角色在项目的不同阶段对应的工作内容。
1、需求阶段
在这个阶段中,产品经理主导,测试跟开发参与需求评审。
在需求评审的过程中,需要了解需求的细节和设计逻辑,同时对于有疑问的地方要提出疑问,达成对需求理解的一致。
需求评审结束后,开发先评估工时,然后测试要根据需求文档并结合开发的工作量,来完成测试工时的评估。
排期表规范:
包含角色:产品、设计、前后端、测试等(根据具体的项目来定)
关键时间节点:
- 产品:需求串讲时间,项目上线时间
- 开发:开发起止时间,前后端联调时间
- 测试:提测时间,测试起止时间
2、开发阶段
排期定好之后,就进入开发阶段了。
首先,开发同学会先出一个整体的技术设计方案,包含本次需求的设计思路和实现逻辑等。
这时一般会有技术评审的环节(开发主导,产品和测试参与),在技术评审的时候,可以对开发的技术设计提出疑问,从而获得更加全面的了解,了解越多,测试用例设计才会更全面。
技术评审之后,测试要制定测试方案(测试范围、测试手段、测试时间等)。
然后编写测试用例是很重要的一部分。
编写用例可以用excel或xmind,建议测试团队统一标准。
测试用例完成后,需要跟开发和产品拉会,进行用例评审。
用例评审的目的是找出遗漏点和逻辑理解不一致的地方,最终统一对预期效果的理解。
3、测试阶段
开发完成后,接下来就是提测。
在提测环节,建议制定测试准入(也称为提测规范)。
为什么要制定提测规范:为了规范开发的提测质量,加强前期质量控制,降低提测后因提测质量问题造成的风险。
测试准入标准(根据实际业务增减):
- 开发人员按需求及原型图完成软件的业务流程及功能的开发
- 开发人员编码结束,并已完成单元测试,并提供自测功能报告
- 软件的基本业务流程可以运行通过(冒烟测试),功能操作正确,且符合需求
- 开发人员需提供软件的最新版本,并安装测试通过
- 开发人员需提供接口文档、部署文档、提测申请、提测功能列表
提测质量达标之后,就正式进入测试了。
测试一般分为后端测试(接口测试)和前端测试,后端测试通过之后再进行前端测试。
怎样才算合格的测试,同样也需要制定测试准出标准(测试完成标准)
测试准出标准:
- 所有功能和业务流程都按需求实现
- 测试用例都已经执行完成,测试执行覆盖率为100%
- 测试发现的所有 BUG 问题中,致命、严重、都已被修复且被验证通过
- 允许遗留不影响业务流程的轻微bug,但是需要有解决方案及时间点
- 完成测试后,出具测试报告
4、发布阶段
测试完成后,就进入发布阶段。
发布规范包含以下几点:
- 发布时间:为了避免上线后有问题及时修复,发布日期建议避开周五及节假日前两天,上线时间避开用户活跃高峰期
- 发布流量控制:为了避免线上问题影响到线上用户,建议小流量灰度发布,在线上回归没有问题后再逐步放量
项目上线后,建议做一次项目复盘,看看那些地方做得不好,要分析原因并找到解决方案;那些地方做得好,以后继续保持。
通过复盘这个环节,可以总结经验并更好地规范项目流程。
二、从0到1怎么做
从0到1 基本意味着以往的流程不规范,开发人员不愿意配合等问题。
所以想要在短时间内落实很细致完整的测试流程是很有一定难度的,那么就需要先从一些必要的和容易的环节入手,逐步完善。
1. 必要的环节:对项目的流程和效率影响大
2.容易的环节:产品或开发等角色容易做的,愿意配合的
下面,我们从【 需求→ 开发 →测试 → 发布】这个流程来理一下头绪
-
需求阶段:
- 需求文档:要落实为文档,而非口头的,方便产品、开发、测试对需求有统一的理解和依据(有必要)
- 需求评审:开发、测试拿到产品的PRD⽂档后,需要提前阅读并标出有疑问的地⽅,在需求评审上提出并沟通达到⼀致。保证产品、开发、测试对需求的理解⼀致,前期的修改成本是最低的。
- 定排期:评估工作量,方便对整体进度有把控(有必要、落实难度不大)
-
开发阶段:
- 开发设计:测试有条件的话应该参与到开发的设计评审和接⼝评审中,⼀⽅⾯可以达到理解开发设计的思路和逻辑,对之后的⽤例设计起到帮助,另⼀⽅⾯可以及早的发现开发设计上的错误和遗漏,将维护成本降到最低(建议做)
- 接口文档:开发要写接口文档,方便测试过程中查阅(有必要,落实难度一般)
- ⽤例设计:根据需求分解出测试功能点并标出优先级,根据功能点设计测试⽤例。
- ⽤例评审:测试⼈员针对需求写出测试⽤例之后,再让产品和开发review一遍,⽬的还是发现需求的遗漏点(建议做)
- 单元测试(开发自测):在开发的过程中要做单元测试,避免小错误造成大的影响(落实难度一般)
-
测试阶段:
- 提测:开发提测的质量也是⾄关重要的,如果出现⼀些流程性的问题,将影响到整个测试进度。接收到提测单后先将冒烟测试⽤例过⼀遍,没有问题⽅可开始测试,否则打回重新开发直到符合标准(有必要)
- 部署测试环境:需要跟开发同学沟通协助(有必要,落实难度可能较大)
- 测试并追踪bug:上线前需要开发修复完所有bug(必要环节)
- 测试报告:当项⽬达到上线标准时,应该出具测试报告发送⾄整个项⽬组,说明测试结果及存在的风险,并告知产品和运营进⾏验收测试,保证项⽬功能是符合预期的(必要环节)
-
发布阶段
- 发布时间:选择合适的上线时间,出现问题方便及时修复(容易落实)
- 上线后跟踪:如果线上有反馈问题,测试应该及时跟进,通知对应开发最快速度修复和总结出问题出现的场景和原因(有必要)
- 总结复盘:把本次的问题总结归纳,下次项目流程中应该重点关注(建议做)
最后来一张图总结一下
如上,大致思路应该有了。
建议根据实际状况,先做容易的和必要的,推动公司产品和开发等角色共同完成基础测试流程的搭建,然后在后续的迭代中,逐步完善和优化,最终形成适合自己公司的测试流程。
精选干货文章推荐:
入行软件测试需要掌握啥?
对于一个即将上线的网站,如何测试?
如何做一份精致的性能测试报告?
版权声明:本文为博主作者:阿尔卑斯下的泰戈尔原创文章,版权归属原作者,如果侵权,请联系我们删除!
原文链接:https://blog.csdn.net/weixin_44203158/article/details/124827037