软件测试解说术语+流程+规范.docx

软件测试解说术语+流程+规范.docx

《软件测试解说术语+流程+规范.docx》由会员分享，可在线阅读，更多相关《软件测试解说术语+流程+规范.docx（13页珍藏版）》请在冰豆网上搜索。

软件测试解说术语+流程+规范

-标准化文件发布号：

（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

软件测试解说（术语+流程+规范）

软件测试说明

版本标识

注释

作者

日期

V1.0

周霸王

2018.10.1

1.概述

制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。

最终目标是实现软件测试规范化，标准化

1.1术语与缩写

术语、缩写

解释

问题、缺陷、BUG

软件工作产品中的一种情况，它将导致软件产生不令人满意或非预期的结果。

测试计划

定义一个测试项目的过程，以便能够正确的度量和控制测试

测试设计

描述系统需要测试的特性、方法、测试环境的规划、测试工具的设计和选用方案和测试代码的设计方案

测试实现

根据测试方案，对测试用例、工具和代码加以具体的实现

测试策略

描述测试工程的总体方法和目标

白盒测试

又称结构测试、逻辑测试，是一种基于程序内部结构的一种测试方法

黑盒测试

基于规格说明书和用户手册的要求，是一种从用户观点出发的测试方法

单元测试

（UnitTesting）

又称模块测试，着重于程序内部的结构，多用白盒方法进行测试

集成测试

（IntegrationTesting）

组合不同功能模块而形成一个大的功能进行测试

确认测试

（ValidationTesting）

又称有效性测试，目的验证软件的功能和性能以及其特性是否与用户的要求一致

系统测试

（SystemTesting）

将通过确认测试的软件作为整个计算机系统的一个元素，结合硬件、外设、其它支持软件、数据和人员待系统元素，在实际的运行环境下，对计算机系统进行一系列的集成测试和确认测试

验收测试

以用户为主，使用生产实际数据作为测试数据在真实环境下进行测试，实际上是对整个测试计划进行一种走查

功能测试

对所有可直接追踪到用例或业务功能和业务规则的测试需求

用户界面测试

通过浏览用户界面测试对象是否正确反映业务的功能和需求

容错性测试

测试系统的错误处理、错误保护是否正确

文档审查

检查用户文档的完整性、正确性、一致性、易理解性和易浏览性

α测试

在软件组织内部验收前，由测试部门进行集成测试

β测试

在实际使用环境下进行的测试由典型用户从用户的角度出发，按用户需求进行测试，一般在Alpha测试达到一定可靠程度下才开始进行

AdHot测试

对系统进行随机测试

Closed

关闭状态，表示BUG已经测试确认被解决了

回归测试

检查上一阶段测试发现的Bug是否已被解决了。

2测试资源

2.1人员结构安排

工作人员

角色

职责

前端应用工程师

1.分小组分模块对其他开发人员编写的代码进行代码走查；

2.配合测试小组的测试工作，修改各自模块的测试缺陷；

后台数据工程师

1.分小组分模块对其他实施人员编写的代码和SQL语句进行复查，执行单元测试；

2.根据《需求文档+原型》编写测试代码，验证系统各个模块之间的接口、与外部系统之间接口的正确性；

3.配合测试小组的测试工作，修改各自模块的测试缺陷；

测试工程师

1.制定测试规格说明和测试计划文档，定义测试需求，设计并实现测试用例和测试脚本，设计并实现测试数据集，备份并归档所有测试文档和资料。

2.制定测试计划，测试分工安排，测试进度管理，软件质量评估，测试工具开发、与项目经理、上层领导的沟通等。

3.定期向项目经理汇报测试进展情况和问题，并与开发组、质量专员保持及时有效沟通。

4.编写模块的测试用例，执行测试用例，观察记录测试结果。

等等……

2.测试流程

3.1需求分析

需求分析是介于系统分析和软件设计阶段之间的桥梁。

一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。

良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

3.2用例设计

3.2.1测试用例的编写规范

测试用例的格式：

测试用例需要包括以下要素：

用例ID、功能模块、测试要点/检查点、变更类型、前置条件、优先级、输入数据/步骤、预期结果、实际结果、执行状态、执行人、执行日期、备注。

3.2.2测试用例的管理办法

项目的测试用例，用EXCEL工具进行管理。

已通过审批的测试用例需要变更，分不同的等级进行管理。

等级

变更范围

审批流程

高

需求增加，需对新需求编写测试用例

项目经理和技术总监共同审核

中

需求变更，修改已有的测试用例或发现原测试用例，不符合原有的需求，需要变更测试用例。

项目经理和技术总监共同审核

低

修改测试用例的错别字

不需要审核。

评审组成员包括但不限于：

项目经理、需求分析师、技术总监、测试工程师。

Ø功能或流程划分是，一定要简单、清晰，一个测试用例只检查一个功能点或者一个流程。

Ø测试用例的步骤描述要简单、清晰，一步就是一步。

Ø测试用例的数据要明确，特别是输入数据和期望结果。

Ø测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。

Ø描述要清晰、包括特定的场合、对象和术语，没有含糊的概念和一般性的描述

Ø测试用例中需要有充分的异常测试数据，考虑大数据量测试时的数据准备。

Ø测试用例应确保覆盖详细设计中的所有功能。

Ø对于无输入的操作，应该详细描述其具体的操作步骤的结果。

Ø测试用例需要保障数据的正确性和操作的正确性。

3.2.1等价类划分法

等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

每一类的代表性数据在测试中的作用等价于这一类中的其他值。

3.2.2边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3.2.3错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

3.2.4因果图法

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

3.2.5判定表驱动法

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

3.2.6场景法

用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

3.3用例执行

根据已有的测试用例，按照里面的步骤一步一步的执行查看预期结果与实际结果是否一致。

Ø注意前置条件和特殊说明

Ø测试用例要全部执行

Ø不要忽视任何偶然现象

Ø加强测试过程记录

Ø详细记录预期与实际的不一致

Ø及时更新测试用例

3.测试执行

4.1测试范围与策划

系统测试包括用户确认测试和功能测试两个阶段。

用户确认测试主要由用户方来检验系统所有模块的功能和其它特性是否真正无误实现，重点在于检验功能、业务流程、算法等实现是否正确，用户界面是否符合操作性。

系统的基准测试；

核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当

4.2.1功能测试

功能测试侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

此类测试基于黑盒技术，该技术通过图形用户界面与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

以下为各种应用程序列出了推荐使用的测试概要。

测试目标

确保测试的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是否恰当。

方法

利用有效的和无效的数据来执行各个用例，以核实以下内容：

在使用有效数据时得到预期的结果。

在使用无效数据时显示相应的错误消息或警告消息。

各业务规则都得到了正确的应用。

完成标准

按所准备的测试用例完成全部测试

测试重点和优先级

1.算法的准确性

2.输入数据的完整性

3.输出数据的完整性

4.功能的完整性

5.流程的合理性

4.2.2错容性测试

容错性测试是对程序的错误保护是否足够进行的测试，要求把每个需要有错误保护的点都进行容错测试，确保系统对误操作或错误数据有充分的错误保护。

屏蔽用户错误

考察对用户常见的误操作的提示和屏蔽情况，例如可否有效避免日期的录入错误或写入无效的日期。

出错提示

考察出错提示是否正确。

当用户操作错误或软件发生错误时，能否有准确清晰的提示，使用户知道造成错误的原因。

例如当用户未输入完有效信息时存盘，系统应当给出关于未输入项的提示。

重要数据删除提示

考察是否有警告及确认提示。

输入数据检查

当用户输入的数据有错时，考察软件是否能判断数据的有效性，避免无效数据的生成，或避免不合要求的数据进入数据库。

输入非法值

考察系统是否能识别输入非法值，并有相应的错误提示。

4.2.3回归测试

回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。

软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

测试目标

验证之前出现过但已经修复好的缺陷不再重新出现。

方法

重复上轮测试发现缺陷时使用的测试方法；此外还需要测试因修改本缺陷可能受影响的所有功能。

完成标准

上轮测试出现BUG的功能点已经修复，缺陷没有重现。

4.缺陷管理流程

5.1缺陷过程描述

1）测试人员在规定日期内提交Bug入库，状态置为：

New

2）开发组进行判定Bug是否成立，判定Y/N（YesorNo）

3）当开发组判定为N时，状态置为：

Rejected

4）当开发组判定为Y时，状态置为：

Opened

5）开发工程师在规定周期内解决问题，在测试环境中验证无误后，状态置为：

Fixed

6）测试人员在Fixed版本上验证，验证BUG是否已经修复，判定Y/N

7）验证BUG还没被修复，在规定周期内执行Reopen操作，状态重置为：

Opened

8）验证BUG已经成功被修复，在规定周期内关闭，状态置为：

Closed

5.2缺陷等级定义

等级

说明

描述

1）Urgent

严重错误

●由于程序所引起的操作系统崩溃，造成数据库死锁、数据丢失、资料破坏、内存泄漏等；

2）VeryHigh

较严重错误

●出现错误后，所有测试工作无法继续执行。

3）High

一般性错误

●菜单或按钮没有实现其本来的作用，不能进入所链接的页面，影响其它功能的实现。

如添加，修改按钮不起作用。

●影响下一个流程的操作。

如不能保存数据。

●按钮实现了不属于自已本身的功能。

如确定按钮实现了保存功能。

●遗漏了功能。

●主要功能未实现或与产品需求规格书不符。

●对数据约束的功能没有实现或实现不一致。

●JavaScript错误。

4）Medium

较小错误

●系统满足主要页面要求，对功能有较小影响；

●辅助说明描述不清楚；

●显示格式不规范；

●长时间操作未给用户进度提示；

●提示窗口文字未采用行业术语；

●可输入区域和只读区域没有明显的区分标志；

●系统处理未优化：

系统易用性方面的问题，例如报表查询条件值为空时通常默认为查询全部，如果还需要用户选择查询条件为“全部”则可以认为系统处理未优化。

5.测试标准

系统测试通过标准

1.系统已经完成软件需求规格说明书中阐述的功能；

2.系统测试用例设计已经通过评审；

3.按照系统测试计划完成了系统测试；

4.在系统测试中发现的错误已经得到修改，各级缺陷关闭率达到标准；

缺陷关闭率标准

1.一、二级错误关闭率应达到100%；

2.三级错误关闭率达到85%以上；

3.四级错误关闭率达到80%以上。