测试流程规范

  • 格式:docx
  • 大小:114.90 KB
  • 文档页数:10

下载文档原格式

  / 10
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一、项目立项

立项阶段的主要任务是确认立项的理由,提出立项建议,使立项建议成为正式项目。

二、软件开发

软件开发阶段分为:项目规划—需求分析—概要设计—详细设计—代码编写—代码实现—测试交接—实施测试—回归测试—同行审查—测试总结—项目发布、跟踪

项目确定后,需求人员设计详细需求文档及产品原型,并制定项目计划。项目计划是一个用来协调所有其他计划,以指导项目执行和控制的可操作文件。它体现了对需求的理解,是开展项目活动的基础,也是软件项目跟踪与监控的依据。开发人员根据需求文档及产品原型编写代码。在开发阶段如果需求发生变更时,应及时以文档形式说明。

三、软件测试

项目测试的目的是检查系统是否符合项目需求规定的要求。主要进行功能测试、健壮性测试、易用性测试、用户界面测试、性能测试等(根据项目要求选择不同测试方法)测试过程在测试环境中进行。

四、基本流程

立项

主要对项目的可行性进行分析,并且确定项目是否需要测试

需求评审

需求定义完成,开发人员和测试人员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题,相关人员解答并确认。需求人员在对需求进行修改的同时,应以文档形式告知开发及测试人员。

测试工作启动

在正式测试任务下达前,开发团队应在项目(产品)开发计划完成后及时向测试团队下达预通知,告之较为确切的测试日期,提供当前最新的相关资料。部门经理和测试组长组建测试小组,并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试人员可预先熟悉必要的项目(产品)资料。针对需求分析文档和项目开发计划文档测试完成后,测试组需要确定测试过程中的风险,并设计出合理的规避分险的策略,为后续的测试工作提供直接的指导。

否 是

需求

产品人员 开发人员 测试人员 发布 是否测产品人员确认

软件测试流程

软件项目的前要工作主要是需求分析。事实上一个软件项目或产品的成败与需求分析有着非常重要的联系。因此在没有明确用户需求的情况下盲目地进行开发和测试都不能够取得理想的效果。若具备条件,测试人员应从客户需求调研阶段就介入到项目中。软件产品需求调研阶段工作流程如图所示

通过软件产品需求调研阶段工作流程图可以看到,在这一阶段有两个与软件测试相关的输出,它们分别是软件总体测试计划和系统测试方案。它们的作用是将软件细化为可检验的测试需求。一般情况下要重点考虑以下问题

1、 产品基本情况调研

这部分应包括产品的一些基本情况介绍,例如产品的运行平台和应用的领域,产品的特点和主要的功能模块等。对于大的测试项目,还要包括测试的目的和侧重点。具体的要点如表所示。

目的 重点描述如何使测试建立在客观的基础上,定义测试的策略及测试的配置,粗略地估计测试大致需要的周期和最终测试报告递交的时间 变更

说明有可能会导致测试计划变更的事件。包括测试工具改进了,测试环境改变了,或者是添加了新的功能 技术结构 可以借助画图,将要测试的软件划分成几个组成部分,规划成一个适

用于测试的完整的系统,包括数据是如何存储的,如何传递的,每一

个部分的测试是要达到什么样的目的,每一个部分是怎么实现数据更

新的。还有就是常规性的技术要求,比如运行平台、需要什么样的数

据库等

产品规格 制造商和产品版本号的说明

测试范围 简单地描述如何搭建测试平台,以及测试的潜在风险

项目信息

说明要测试的项目的相关资料。例如,用户文档、产品描述、主要功

能的举例说明

2、 测试需求说明

这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。有了测试需求说明,可以帮助我们了解被测试软件所有功能项当前的测需求工作培训 编写需求文档 进入下一阶段 需求评审 需求变更 需求说明书 系统测试方案,软件总体测试计

试情况如何,即所有功能项中测了什么和没测什么。具体要点如表所示。

3、测试策略和记录

这是整个测试计划的重点所在,要描述如何公正客观地开展测试,要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能地考虑到细节,越详细越好,并制作测试记录文档的模板,为即将开始的测试做准备,测试记录的

4、测试资源配置

项目资源计划:制定一个项目资源计划,包含的是每一个阶段的任务、所需要的资源,当发生类似到了使用期限或者资源共享的事情的时候,要更新这个计划。

5、计划表

测试的计划表可以做成一个或多个项目通用的形式,根据大致的时间估计来制作,操作流程要以软件测试的常规周期作为参考,也可以是根据什么时候应该测试哪一个模块来制定。

6、配置测试环境

配置测试环境是测试实施的一个重要环节,会直接影响测试过程的效率和最终测试结果的真实性和正确性。测试环境包括硬件环境和软件环境,硬件环境指测试必要的服务器、客户端、网络连接设备,以及打印机/扫描仪等辅助硬件设备所构成的环境;软件环境指被测软件运行时的操作系统、数据库及其它应用软件构成的环境。在实际测试中,软件环境又可分为主测试环境和辅助测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说,配置主测试环境可遵循下列原则。

◇符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。

◇选用比较普及的操作系统和软件平台。

◇营造相对简单、独立的测试环境。除了操作系统外,测试机上只安装软件运行和测试必需的软件,以免不相关的软件影响测试实施。

◇无毒环境。利用有效的正版杀毒软件检测软件环境,保证测试环境中没有病毒。

辅助测试环境常常用来满足一些特殊的测试需求或测试项目。

◇兼容性测试:在满足软件运行要求的范围内,可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。

◇模拟真实环境测试:有些软件,特别是面向大众的商品化软件,在测试时常常需要考查在真实环境中的表现。

◇横向对比测试:利用辅助测试环境“克隆”出完全一致的测试环境,从而保证横向对比测试结果的可靠性。

7、设计用例

测试用例的设计过程可以是一个由简到繁逐步细化的过程,即一个从简单的测试描述(测试功能点、测试需求等)逐步细化到能够去依照执行的测试用例的过程。

如果没有测试用例或者仅有简单的测试功能描述,测试过程难以控制,测试结果将毫无可靠性可言,同时简单的测试用例可靠性低、重用性差,并且有可能导致不同人员的理解不同。详细的测试用例就不同了,它的可靠性高,而且便于执行所需时间,易于控制。

但是,要写出详细的测试用例,付出的人力、物力的代价是很大的。因此测试用例到底细化、详细到什么程度,就要综合考虑各种因素。例如,在时间要求上确定测试时间是否充足,测试执行者对系统的了解程度如何,将测试用例交给其人人执行时是否需要过多的解释等各个方面的问题。

8、问题跟踪报告

在测试的计划阶段,应该明确如何准备去做一个问题报告,以及如何去界定一个问题性质。问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试用例测出该问题,以及明区问题产生的测试环境。问题描述尽可能是定量地、分门别类地列举,问题有如表所示的3种。

9、测试计划的评审

测试计划的评审,在测试真正实施开展之前,必须要认真负责地检查一遍,并获得整个测试部门人员的认同,包括部门负责人的同意和签字。

需求调研阶段完成后,人们会根据需求说明书的要求开始设计软件。首先是概要设计,之后是详细设计,最后开发人员根据产品的详细设计进行编码。这一过程叫做软件设计和编码阶段。软件设计和编码阶段的工作流程如图所示