前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >规范化测试流程,看这篇就够了~

规范化测试流程,看这篇就够了~

作者头像
苏南
发布2020-12-16 09:44:11
5.2K0
发布2020-12-16 09:44:11
举报
文章被收录于专栏:漫画前端漫画前端

点击上方?“IT平头哥联盟”,选择“置顶或者星标”

您的关注意义重大!

引言

  • 什么是软件测试? 1、利用人工或自动化的手段对软件进行测试,找出bug,从而降低商业风险; 2、正向思维:软件测试是一系列的活动来验证程序是否正常运行,以及是否达到了用户预期的需求; 3、逆向思维:软件测试是为了发现程序的错误或者缺陷而进行的一系列活动; 4、一个软件/应用是由文档需求、数据、程序等部分组成,所以软件测试就不仅仅是对程序进行测试,而是多方位的验证; 小结:测试工程师大概可以归纳为在规定的条件下对程序进行测试操作,了解程序项目需求/正常流程,发现程序的错误、不合格的流程及表现,对项目程序进行评估。
  • 测试的好处?
  • 1、发现程序的错误行为; 2、定位程序的错误表现(UI展示); 3、确认程序的逻辑与产品需求的一致性; 4、确保呈现给用户的是完美无误的程序应用,给用户更好的体验。
  • 测试的目的?
  • 1、寻找项目的缺陷; 2、跟踪修正项目的缺陷; 3、验证修正的项目缺陷; 4、没有完美的代码,也没有完美的应用,那么测试只有通过测试,发现问题才能提升应用程序的完美。

环境说明

  • dev(测试环境):根据开发人员提测的功能块:
  • 按照测试用例优先级,卓条进行测试验证,
  • 发现问题录入禅道系统并知会对应开发人员,
  • 修复完成后再验证;
  • uat(预发环境):dev测试通过后发送测试通过邮件并抄送各组leader知会;且发布预发(uat)环境;
  • uat发布完成后,进行第二轮流程验证测试,反馈发现的bug,修复验证通过后;确认需求不会变更,代码不再提交的前提下,进行回归测试验证(即对整个业务流程进行上线前的再次确认);
  • prd(生产环境):uat确认后,可根据项目要求输出测试报告 ,并发送邮件给各组负责人,项目测试完成可上线。

bug状态标准:提交bug -> 待处理 -> 已确认 -> 已处理 -> 测试验证 -> 已修复(关闭)

需要注意的:有的小公司只有测试环境和生产环境,

bug等级划分

  • bug一般可分为4个等级,根据问题的实际影响正确填写,严禁不区分问题的实际影响随意填写,对应级别如下
  • 致命bug:ID值5分,
  • 关键功能/性能不符合产品需求,或阻碍测试工作(如:项目运行死循环、程序导致的数据库数据丢失);
  • 严重bug:ID值 3分,
  • 部分模块功能缺失遗漏、项目无法测试、接口稳定性(60%)、数据保存后数据库显示错误/未存入、程序接口调用错误、界面严重错乱等;
  • 一般bug:ID值2分,
  • 功能没有完全实现但不影响使用、操作/查询等待时间过长、格式错误、边界条件错误等;
  • 提示bug:ID值0.5分。
  • 界面错乱/重叠、错别字、描述提示语与需求不符;
  • 建议
  • 测试人员觉得体验不好,但流程符合需求的,可以提出建议;

测试流程(目前公司的流程)

  • 1.测试基本流程图
二.测试开始条件
  1. 项目需求阶段,产品提相应的jira,需要召开响应的需求评审会议,测试开始介入,熟悉项目需求,着手设计系统测试用例;
  2. 当所有的模块都开发完毕,研发人员对各个模块进行合成进行自测,自测通过后才可以发布测试版本,接口测试开发需要提供对应的接口文档,测试人员根据需求进行系统测试;
  3. 当新增功能或者版本升级,需要对新增功能及升级模块进行测试,对其他关联模块进行回归测试。
三.测试流程
  • 1.测试启动阶段

产品,项目管理者,测试人员参,研发人员以及和项目有关联的其他人共同参与需求会议,需求评审中需要评估本次需求是否需要性能测试,明确需求及任务完成时间,产品需提供详细的需求文档,产品功能清单,研发人员需向测试人员提供产品项目需求文档、接口文档等,明确测试任务,确定测试周期。需求评审完后由项目经理发出项目计划表,后续项目进展时间节点按照此项目计划表来执行。

测试人员根据项目工作量大小及项目进度编写测试计划书,对本次测试的范围、测试进度、测试策略等内容进行把控。

研发人员在功能开发完成且自测通过后发布测试版本,提交测试申请单,发送提测邮件给测试人员,测试人员进行冒烟测试,冒烟测试通过,进入测试阶段,否则打回测试。测试人员在测试阶段,要做好版本控制,研发人员在这一版本中修复的bug,需要下一个版本中再次验证。

临时新增的紧急需求和改动点,产品需要提供对应的jira,研发需要新增提测单并且填写测试注意点。

  • 2.设计用例阶段

在拿到需求文档,产品功能列表之后,测试人员就开始着手设计测试用例了。测试人员根据产品功能列表后尽量多的设计测试用例,尽可能多的覆盖所有的测试需求。测试用例完成后需进行用例评审,产品和对应的研发人员必须参加,评审会上发现的问题需要及时补充和完善。

  • 3.用例执行阶段

开发提测后,进行冒烟测试用例,冒烟通过率低于80%,测试有权力打回测试,冒烟通过后进入正式测试阶段,测试过程中发现的bug需要记录在jira中,测试人员要争取每个bug都能够重现,便于开发修改;测试人员将bug反馈给相关开发人员,开发人员进行修复,测试人员对已修复的bug进行再次验证,直到bug解决为止,把状态置为关闭,并将测试结果记录。

  • 4.提交测试总结报告

在约定的测试周期内,在所有的用例都执行完,一般及以上的bug都修复完,遗留bug需要记录在jira中便于后续版本的回归,测试人员需要针对本次测试项目编写测试总结报告,将测试结果反馈,以及容易出现bug的模块给予建议,相关负责人在下次开发中予以借鉴,避免类似错误的出现,测试报告可通过邮件形式,让相关研发人员知晓。

四.测试结束
  1. 当所有的用例都被执行完,所有一般及以上的bug都被修复,产品验收通过,测试编写完测试总结报告;
  2. 基本功能都已实现,一些遗留bug可以再下一版本中修复;
  3. 如遇项目紧张,急于上线,测试基本功能没问题,对于用户后续发现的bug可以进行跟踪,并且后续发现的问题记录在jira中。

如果觉得不错,请记得关注我们 公众号哦,第一时间获得最新分享~?

作者:松鼠 - 首席背锅官

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-10-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 画漫画的程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 引言
  • 环境说明
  • bug等级划分
  • 测试流程(目前公司的流程)
    • 二.测试开始条件
      • 三.测试流程
        • 四.测试结束
        相关产品与服务
        项目管理
        CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档