qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试流程规划

 一、引言
  本文档规范了软件测试过程中的整体流程,明确了软件测试从开始到结束的各个阶段,以及在各阶段中的负责人、具体工作内容和必需的输入输出文档。另外,本文还介绍了各测试阶段需要的测试工具、测试点和测试步骤,并提供了各类测试文档的参考模板。
  二、测试流程概述
  1、流程介绍
  一般来讲,软件测试是伴随着项目的立项而开始的。也就是说,软件项目一旦确立,测试工作也就开始了。在测试的过程中,前后要经过以下主要环节:
  需求分析—>制定测试计划—>搭建测试环境—>测试用例设计—>测试执行—>BUG回归测试—>测试总结—>软件发布
  对于以上流程环节,一般而言,需求分析属于需求分析人员的工作范畴,环境搭建、用例设计、测试执行以及回归测试等属于测试人员的工作范畴,测试负责人负责制定测试计划以及对各个环节的跟踪、实施、管理等。
  2、流程图
  功能测试
  项目开始
  需求阶段
  测试计划
  测试阶段
  性能测试
  用户界面测试
  兼容性测试
  安全性测试
  接口测试
  测试总结
  软件发布
  三、需求阶段
  在这个阶段,主要是对于需求的收集、分析以及评估。
  1.由需求分析人员统一收集需求,并整理成文档格式转发给项目经理、开发经理和测试经理;
  2.项目经理召集开发经理、测试经理和需求分析人员进行会议讨论,了解具体每个需求的实际含义,并且明确各需求的有效性和可用性;
  3.小组会议讨论,确定最终实现的需求和功能点,并整理出重点需求;
  4.项目经理根据会议讨论结果编写需求说明,并且再次召集小组开会讨论,对需求说明进行修复、完善,并最终确定《需求规格说明书》。
  负责人:项目经理
  输入文档:需求说明文档
  输出文档:《需求规格说明书》
  四、测试计划阶段
  作为测试的起始步骤和重要环节,测试计划是对测试全过程的组织、资源、原则等进行规定和约束,并制定测试全过程各个阶段的任务以及时间进度安排,并提出对各项任务的评估、风险分析和管理需求。用一句话概括就是:测试计划是从管理角度对整个测试活动进行规划和控制。
  测试计划的主要内容可分以下几个方面:
  1.测试概述(介绍项目测试的范围、目的以及组织形式)
  2.测试进度(测试时间周期的安排)
  3.测试策略(包括测试环境、测试工具及测试方法)
  4.需求跟踪(确定系统测试项与需求之间的对应关系)
  5.测试通过失败标准(指明测试何时通过何时结束)
  6.测试挂起恢复标准(指明当测试过程无法进行下去时测试活动挂起以及恢复的标准)
  7.资源分配(工作量的统计以及工作任务的安排)
  8.应交付测试工作产品(明确测试需要提交的各类工作文档)
  9.风险评估(预估测试存在的风险)

测试经理根据项目的总体进度、发布时间以及需求规格说明、开发计划制定相应的测试计划,完成后提交给项目经理。项目经理组织讨论会,连同开发经理、测试经理以及各模块负责人,对测试计划进行评审并确定。
  负责人:测试经理
  输入文档:《需求规格说明书》、《软件开发计划》
  输出文档:《软件测试计划》
  五、测试阶段
  测试阶段按照不同的测试要求可分为以下几点:
  · 功能测试
  · 性能测试
  · 用户界面测试
  · 系统兼容性测试
  · 系统安全性测试
  · 系统接口测试
  负责人:测试工程师
  输入文档:《需求规格说明书》、《软件测试计划》、《软件设计文档》
  输出文档:《***测试用例》、《***缺陷报告》、《***测试报告》
  1、测试前提条件
  当研发部门完成了软件项目的开发任务之后,软件产品开始进入测试环节。在开发人员提交测试之前,需要遵守测试的前提条件,如果没有限定测试前的前提条件,测试人员需要花费大量的时间去完成一些简单的并且很容易发现的错误,这样会造成很大的人员浪费。因此,对于开发部门提交给测试部门的软件产品,除领导亲自特批外,均必须满足以下条件才允许提交:
  (1)开发部门完成软件的白盒测试。
  (2)开发部门完成软件的冒烟测试。
  (3)必须提供软件产品的需求文档以及软件开发的设计文档(包括概设和详设文档)。
  (4)对于新增功能,必须提供功能列表、功能详细说明、流程明细以及关联的模块;对于修改功能,必须提供修改功能列表、具体修改内容以及影响的模块。
  (5)对于没有完成的功能,不能提交测试,必须在代码中注释掉。
  (6)对于需要与其他系统进行集成测试的软件,需要明确测试环境以及参数的配置,并且详细说明系统间具体是如何集成的。
  (7)对于需要进行性能测试的部分,提供详细说明以及需要达到的各项性能指标。
  2、系统功能测试
  2.1测试工具
  主要采用手工测试,但对于重复性功能点的测试可采用QuickTest Professional作为自动化测试工具。另外,使用公司Dynamix系统作为测试用例和BUG管理工具。
  2.2测试点
  2.2.1链接测试
  链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,测试web应用系统上是否有孤立的页面。
  2.2.2表单测试
  当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如:用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性,例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在的城市是否匹配等。如果使用了默认值,还要校验默认值得正确性。如果表单只能接受指定的某些值,则也要进行测试。如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
  2.2.3 Cookie测试
  如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
  2.2.4数据校验测试
  如果系统中根据业务规则需要对用户的输入进行校验,那么就必须要保证这些校验功能正常工作。例如,省份的字段可以用一个有效列表进行校验。在这种情况下,需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值,确定系统能够接受这个测试值)。
  2.2.5程序功能点的测试
  尝试用户的所有操作,这是用户之所以使用网站的原因,必须确保:
  1、各个功能点是否能正确使用;
  2、流程是否能正常运转。
  2.3测试步骤
  2.3.1测试环境的搭建
  根据实际情况,搭建相应的测试环境,包括软件环境和硬件环境。
  2.3.2用例设计
  测试工程师根据“需求规格说明书”、“测试计划”以及开发提供的“软件设计文档”来设计各个模块以及功能点的测试用例,完成后提交给测试经理。测试经理组织各模块开发以及测试人员进行开会讨论,评估设计好的测试用例。
  2.3.3测试执行
  在这一阶段,测试工程师对之前设计好的测试用例进行执行操作,找出系统软件的BUG并且提交给开发人员进行修复。
  2.3.4回归测试
  测试工程师对于那些已被开发修复的BUG,做回归测试以验证其是否得到正确修复。确认修复的,就将BUG关闭,否则重新提交给开发人员修复。
  回归测试需要注意一下两点:
  1.BUG是否得到正确修复;
  2.是否引入了新的BUG。
  2.4测试报告
  测试工程师对功能测试结果进行总结分析,完成《功能测试报告》。
  3、系统性能测试
  性能测试是测试过程中不可或缺的一个环节,它是通过自动化的测试工具模拟多种正常、峰值以及异常条件来对系统的各项性能指标进行测试。
版权声明:本文出自 Giant321 的51Testing软件测试博客:http://www.51testing.com/?506499
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

posted on 2014-01-02 09:45 顺其自然EVO 阅读(263) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年1月>
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜