软件测试解说(术语+流程+规范_第1页
软件测试解说(术语+流程+规范_第2页
软件测试解说(术语+流程+规范_第3页
软件测试解说(术语+流程+规范_第4页
软件测试解说(术语+流程+规范_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、软件测试说明版本标识注 释作 者日 期V1.0周霸王2018.10.11 目录1.概述31.1术语与缩写32.测试资源42.1人员结构安排43.测试流程53.1需求分析53.2用例设计63.2.1测试用例的编写规范63.2.2测试用例的管理办法63.3用例执行84.测试执行94.1测试范围与策划95.缺陷管理流程115.1缺陷过程描述115.2缺陷等级定义116.测试标准121. 概述制定完整且具体的测试路线和流程,为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化,标准化1.1 术语与缩写术语、缩写解 释问题、缺陷、BUG软件工作产品中的一种情况,它将导致软件产生不

2、令人满意或非预期的结果。测试计划定义一个测试项目的过程,以便能够正确的度量和控制测试测试设计描述系统需要测试的特性、方法、测试环境的规划、测试工具的设计和选用方案和测试代码的设计方案测试实现根据测试方案,对测试用例、工具和代码加以具体的实现测试策略描述测试工程的总体方法和目标白盒测试又称结构测试、逻辑测试,是一种基于程序内部结构的一种测试方法黑盒测试基于规格说明书和用户手册的要求,是一种从用户观点出发的测试方法单元测试(Unit Testing)又称模块测试,着重于程序内部的结构,多用白盒方法进行测试集成测试(Integration Testing)组合不同功能模块而形成一个大的功能进行测试确

3、认测试(Validation Testing)又称有效性测试,目的验证软件的功能和性能以及其特性是否与用户的要求一致系统测试(System Testing)将通过确认测试的软件作为整个计算机系统的一个元素,结合硬件、外设、其它支持软件、数据和人员待系统元素,在实际的运行环境下,对计算机系统进行一系列的集成测试和确认测试验收测试以用户为主,使用生产实际数据作为测试数据在真实环境下进行测试,实际上是对整个测试计划进行一种走查功能测试对所有可直接追踪到用例或业务功能和业务规则的测试需求用户界面测试通过浏览用户界面测试对象是否正确反映业务的功能和需求容错性测试测试系统的错误处理、错误保护是否正确文档审

4、查检查用户文档的完整性、正确性、一致性、易理解性和易浏览性测试在软件组织内部验收前,由测试部门进行集成测试测试在实际使用环境下进行的测试由典型用户从用户的角度出发,按用户需求进行测试,一般在Alpha测试达到一定可靠程度下才开始进行Ad Hot测试对系统进行随机测试Closed关闭状态,表示BUG已经测试确认被解决了回归测试检查上一阶段测试发现的Bug是否已被解决了。2测试资源2.1 人员结构安排工作人员角色职责前端应用工程师1. 分小组分模块对其他开发人员编写的代码进行代码走查;2. 配合测试小组的测试工作,修改各自模块的测试缺陷;后台数据工程师1. 分小组分模块对其他实施人员编写的代码和S

5、QL语句进行复查,执行单元测试;2. 根据需求文档+原型编写测试代码,验证系统各个模块之间的接口、与外部系统之间接口的正确性;3. 配合测试小组的测试工作,修改各自模块的测试缺陷;测试工程师1. 制定测试规格说明和测试计划文档,定义测试需求,设计并实现测试用例和测试脚本,设计并实现测试数据集,备份并归档所有测试文档和资料。2. 制定测试计划,测试分工安排,测试进度管理,软件质量评估,测试工具开发、与项目经理、上层领导的沟通等。3. 定期向项目经理汇报测试进展情况和问题,并与开发组、质量专员保持及时有效沟通。4. 编写模块的测试用例,执行测试用例,观察记录测试结果。等等2. 测试流程3.1 需求

6、分析需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面,需求分析以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面,需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。3.2 用例设计3.2.1测试用例的编写规范测试用例的格式:测试用例需要包括以下要素:用例ID、功能模块、测试要点/检查点、变更类型、前置条件、优先级、输入数据/步骤、预期结果、实际结果、执行状态、执行人、执行日期、备注。3.2.2测试用例的管理办法项目的测试用例,用EXCEL工具进行管理

7、。已通过审批的测试用例需要变更,分不同的等级进行管理。等级变更范围审批流程高需求增加,需对新需求编写测试用例项目经理和技术总监共同审核中需求变更,修改已有的测试用例或发现原测试用例,不符合原有的需求,需要变更测试用例。项目经理和技术总监共同审核低修改测试用例的错别字不需要审核。评审组成员包括但不限于:项目经理、需求分析师、技术总监、测试工程师。 功能或流程划分是,一定要简单、清晰,一个测试用例只检查一个功能点或者一个流程。 测试用例的步骤描述要简单、清晰,一步就是一步。 测试用例的数据要明确,特别是输入数据和期望结果。 测试用例需要保障唯一性,即功能用例之间不存在重叠,流程用例不存在包含关系。

8、 描述要清晰、包括特定的场合、对象和术语,没有含糊的概念和一般性的描述 测试用例中需要有充分的异常测试数据,考虑大数据量测试时的数据准备。 测试用例应确保覆盖详细设计中的所有功能。 对于无输入的操作,应该详细描述其具体的操作步骤的结果。 测试用例需要保障数据的正确性和操作的正确性。3.2.1 等价类划分法等价类划分法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。3.2.2 边界值分析法边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其

9、测试用例来自等价类的边界。3.2.3 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。3.2.4 因果图法因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。3.2.5 判定表驱动法判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。3.2.6 场景法用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易

10、理解和执行。3.3 用例执行根据已有的测试用例,按照里面的步骤一步一步的执行查看预期结果与实际结果是否一致。 注意前置条件和特殊说明 测试用例要全部执行 不要忽视任何偶然现象 加强测试过程记录 详细记录预期与实际的不一致 及时更新测试用例3. 测试执行4.1 测试范围与策划系统测试包括用户确认测试和功能测试两个阶段。用户确认测试主要由用户方来检验系统所有模块的功能和其它特性是否真正无误实现,重点在于检验功能、业务流程、算法等实现是否正确,用户界面是否符合操作性。系统的基准测试;核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当 4.2.1 功能测试功能测试侧重于所有可直接追踪到用例

11、或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要。测试目标确保测试的功能正常,如导航,数据输入,处理、检索是否正确,以及业务规则的实施是否恰当。方法利用有效的和无效的数据来执行各个用例,以核实以下内容:在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准按所准备的测试用例完成全部测试测试重点和优先级1.

12、 算法的准确性2. 输入数据的完整性3. 输出数据的完整性4. 功能的完整性5. 流程的合理性4.2.2 错容性测试容错性测试是对程序的错误保护是否足够进行的测试,要求把每个需要有错误保护的点都进行容错测试,确保系统对误操作或错误数据有充分的错误保护。屏蔽用户错误考察对用户常见的误操作的提示和屏蔽情况,例如可否有效避免日期的录入错误或写入无效的日期。出错提示考察出错提示是否正确。当用户操作错误或软件发生错误时,能否有准确清晰的提示,使用户知道造成错误的原因。例如当用户未输入完有效信息时存盘,系统应当给出关于未输入项的提示。重要数据删除提示考察是否有警告及确认提示。输入数据检查当用户输入的数据有

13、错时,考察软件是否能判断数据的有效性,避免无效数据的生成,或避免不合要求的数据进入数据库。输入非法值考察系统是否能识别输入非法值,并有相应的错误提示。4.2.3 回归测试回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。测试目标验证之前出现过但已经修复好的缺陷不再重新出现。方法重复上轮测试发现缺陷时使用的测试方法;此外还需要测试因修改本缺陷可能受影响的所有功能。完成标准上轮测试出现BUG的功能点已经修复,缺陷没有重现。4. 缺陷管理流程5.1 缺陷过程描述1) 测试人员在规定日期内提交Bug入

14、库,状态置为:New2) 开发组进行判定Bug是否成立,判定Y/N(Yes or No)3) 当开发组判定为N时,状态置为:Rejected4) 当开发组判定为Y时,状态置为:Opened5) 开发工程师在规定周期内解决问题,在测试环境中验证无误后,状态置为:Fixed6) 测试人员在Fixed版本上验证,验证BUG是否已经修复,判定Y/N7) 验证BUG还没被修复,在规定周期内执行Reopen操作,状态重置为:Opened8) 验证BUG已经成功被修复,在规定周期内关闭,状态置为:Closed5.2 缺陷等级定义等级说明描述1) Urgent严重错误l 由于程序所引起的操作系统崩溃,造成数据

15、库死锁、数据丢失、资料破坏、内存泄漏等;2) Very High较严重错误l 出现错误后,所有测试工作无法继续执行。3) High一般性错误l 菜单或按钮没有实现其本来的作用,不能进入所链接的页面,影响其它功能的实现。如添加,修改按钮不起作用。l 影响下一个流程的操作。如不能保存数据。l 按钮实现了不属于自已本身的功能。如确定按钮实现了保存功能。l 遗漏了功能。l 主要功能未实现或与产品需求规格书不符。l 对数据约束的功能没有实现或实现不一致。l JavaScript错误。4) Medium较小错误l 系统满足主要页面要求,对功能有较小影响;l 辅助说明描述不清楚;l 显示格式不规范;l 长时间操作未给用户进度提示;l 提示窗口文字未采用行业术语;l 可输入区域和只读区域没有明显的区分标志;l

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论