测试流程(测试流程和测试方法)

 2021-11-19 5:25    77  

测试需求分析阶段测试流程:阅读需求,理解需求,主要就是对业务的学习,分析需求点,参与需求评审会议测试计划阶段:主要任务就是编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试范围(来自需求文档),进度安排,人力物力的分配,整体测试策略的制定。风险评估与规避措施有一个制定。

测试设计阶段测试流程:主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。测试执行阶段:搭建环境,执行冒烟测试(预测试)-然后进入正式测试,bug管理直到测试结束测试评估阶段:出测试报告,确认是否可以上线

需要学习的话,可以去优就业了解一下,最近免费课程学习.

也可以直接看这里:/class-101341/?scode=HZLOFZ

软件测试流程如何构建呢?

  一)上周,manager告诉我,为了便于公司内部对版本进行管理,以后版本实现每日构建测试流程。每日构建的意思是,以每几天为一个周期,对版本进行需求提交、程序开发、修改、测试等一系列过程。

软件的版本问题,似乎是所有软件公司的问题,因为版本的混乱导致了很多本来就不该发生的问题。
  在以前的公司,就出现过这个事情,程序开发完了,也通过测试了,但提交给用户的却还是以往的版本。

现在最常用的配置管理工具,可以实现版本的管理,如VSS、CVS、SVN等。我接触过两个,VSS和SVN,平时用的功能很少,就是ADD、GETVERSION、CHECKOUT和CHECKIN。
  VSS可能是最常用的工具之一吧,操作简单,易学,但是当代码增多时进行MERGE的时候,就出现了一系列读取速度过慢等问题,SVN呢,可以解决这方面的问题,但是在操作上,不太符合一直以来的使用习惯,总之我是觉得在实用程序上,SVN不如VSS好用,可是功能上却强大的多。
  

(二)每日构建的周期暂定为五天一个周期,进行程序的版本提交,需求的整理和上一个版本的测试报告的提交。现在手上负责的产品A,应用到了不同的项目中,根据项目的需求又分出不同的项目版本,以A作为主线,其他项目暂且叫做A-1,A-2。。。。。以此类推。
  

周四,该是版本的提交日,到了下午,跑到开发那边,提醒了一下按时间提交。开发与测试之间似乎总是敌对的,没办法,立场不同,都是为了工作,虽然有的时候增加了部分工作量,但公司规定就是这样,也没办法。

前段时间为了进行产品发布,对A的图标和界面做了调整,单个的图标和界面之前看过,很不错。
  拿到版本的时候,心想,终于可以不看以前那个灰灰的界面。满怀欣喜的打开后,差点没晕过去,图标一个没变,主体界面是变了,怎么变得更别扭了。又跑到开发那边,问图标怎么回事,答曰没时间改,下个版本再改。BUG呢,修改了没,答曰也没。

头晕了一阵,打开邮箱,给程序经理发了封邮件,告之具体情况,请他配合解决。
  天知道,这封邮件有没有用。不过,该做的还是要做的。

产品没有更新,看项目版本吧,打开了其中的一个项目版本A-1,看了一下开发提交的版本说明,都按项目计划中的完成的。于是对照了需求说明,进行一一的验证。心里还在想,负责这个项目的开发人员,真是利落,完全按计划完成了。
  结果。。。。。。

又找到负责这个项目的开发人员,询问项目的修改情况。问完了,回来盯着电脑几分钟,打开WORD写了个版本提交样稿说明,发给开发人员了。

A-2之前和项目组、开发开过会,将所有的BUG分为几个周期修改,这次提交的是第一周期完成的,对照了一下,还不错,完成了80%,唯一的遗憾是没写BUG未修复原因和处理情况。
  

(三)又到了版本提交日,早上来了之后,跑到配置管理员处询问程序提交了没有,只有A提交了,其他没交,又跑到开发处催促版本提交。一圈下来,打开提交的版本开始研究。软件测试

界面终于改了,感觉不错,上个版本的BUG也大部分修复了,心里一高兴,又拉着其他同事一起过来看程序的新界面,指点了一番。
  

(四)经过了几周的试运行,版本可以按照规定的日期提交,并且提交相应的版本说明。虽然存在一些小问题,但整个流程可以按照预想的执行。

END:项目验收并试运行后,仍存在一些小BUG,按照预选设定的修复周期定期修改后提交版本。

本文标签:软件测试流程构建

原文链接:https://www.xgfox.com/dmfx/34602.html

本文版权:如无特别标注,本站文章均为原创。