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

软件测试说明
1.概述 (3)
1.1术语与缩写 (3)
2.测试资源 (5)
2.1人员结构安排 (5)
3.测试流程 (6)
3.1需求分析 (6)
3.2用例设计 (7)
3.2.1测试用例的编写规范 (7)
3.2.2测试用例的管理办法 (7)
3.3用例执行 (9)
4.测试执行 (10)
4.1测试范围与策划 (10)
5.缺陷管理流程 (12)
5.1缺陷过程描述 (12)
5.2缺陷等级定义 (12)
6.测试标准 (14)
制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。

最终目标是实现软件测试规范化，标准化
1.1术语与缩写
2.1人员结构安排
等等……
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功能测试
功能测试侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

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

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

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

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

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

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

4.缺陷管理流程
5.1缺陷过程描述
1）测试人员在规定日期内提交Bug入库，状态置为：New
2）开发组进行判定Bug是否成立，判定Y/N（Yes or No）
3）当开发组判定为N时，状态置为：Rejected
4）当开发组判定为Y时，状态置为：Opened
5）开发工程师在规定周期内解决问题，在测试环境中验证无误后，状态置为：Fixed 6）测试人员在Fixed版本上验证，验证BUG是否已经修复，判定Y/N
7）验证BUG还没被修复，在规定周期内执行Reopen操作，状态重置为：Opened
8）验证BUG已经成功被修复，在规定周期内关闭，状态置为：Closed
5.2缺陷等级定义
5.测试标准
系统测试通过标准
1.系统已经完成软件需求规格说明书中阐述的功能；
2.系统测试用例设计已经通过评审；
3.按照系统测试计划完成了系统测试；
4.在系统测试中发现的错误已经得到修改，各级缺陷关闭率达到标准；
缺陷关闭率标准
1.一、二级错误关闭率应达到100%；
2.三级错误关闭率达到85%以上；
3.四级错误关闭率达到80%以上。