软件测试执行基础

软件测试的管理就是对每一种具体测试任务、流程、体系、结果、工具等进行具体监督和管理。
分类：比较常见把软件测试管理分为8类:
1.软件测试需求管理
2.软件测试质量管理
3.软件测试团队管理
4.软件测试文档管理
5.软件测试缺陷管理
6.软件测试环境管理
7.软件测试流程管理
8.软件测试执行管理
9.其它（计划、用例、报告、成本、风险）

一、软件测试执行基础

1，软件测试执行的内容：主要包括4项任务：

    • 执行测试计划预定的测试，包括执行所有已设计的测试用例
    • 记录原始测试数据
    • 记录缺陷
    • 对所发现的缺陷进行跟踪、管理和监控

软件测试的执行包括：手动测试，自动测试
软件测试执行的内容：就是要决定怎样执行测试 和 测试什么决定测试执行的内容需要明确以下信息：
a.测试执行依据的文档
b.制定测试执行计划
c.记录测试执行的结果
d.执行测试的过程
e.测试执行活动结束或终止
f.核实测试结果并报告缺陷
g.测试执行的准备
h.测试执行过程

2，影响测试执行的因素：

实际软件测试过程中，测试资源、测试质量、测试时间之间相互制约【也包含需求、开发、测试 整体阶段的制约】
软件测试执行影响因素：
• 测试计划
• 测试环境准备
• 测试实现

测试执行进度计划的影响因素：
• 过程成熟度
• 测试的时间
• 测试的规模
• 测试的资源
• 产品的质量
• 测试的文档

3，测试执行管理要考虑和关注的环节

1)戴明环指导测试执行
2)测试执行的起始
• 记录测试执行结果
• 测试执行的流程
• 测试执行入口准则
• 测试执行关键信息
3)测试执行的结束
• 确保所有的测试工作全部完成
• 移交测试工作产品
• 总结经验教训
• 在配置管理系统中归档所有的结果、记录、报表和其他文档及交付物

4，软件测试执行的控制

1)测试执行控制阶段的主要测试活动：
按预定的计划执行测试
确定测试执行范围和风险
确定测试执行目的
确定测试执行方法
确定测试执行资源
计划测试执行的进度
确定测试执行入口准则和出口准则
监控和记录测试执行过程
度量和分析测试结果
修正测试执行计划
做出决定
2)常用的度量指标
a 在测试分析和设计中发现的缺陷数
b 测试用例设计完成率
c 测试环境准备的进度
d 测试用例执行情况(如：测试用例执行率、测试用例通过率)
e 缺陷信息(如：缺陷密度、发现和修改的缺陷比例、再测试的通过率)
f 需求、风险或代码的测试覆盖率
g 测试的成本
3)对测试实现和执行阶段进行监控的度量方法：
1.测试环境配置的百分比。
2.测试数据装载的百分比。
3.测试条件和测试用例执行的百分比。
4.测试用例自动化的百分比。
4)评估出口准则和报告阶段涉及的度量：
1.测试需求的覆盖率。
2.测试用例的覆盖率。
3.测试用例执行通过/失败的数目。
4.提交的缺陷数目，根据缺陷的严重程度和优先级进行的分类。
5.提交的缺陷数目，接受的缺陷和被拒绝的缺陷的比例。
6.计划成本支出和实际成本支出的偏差。
7.计划花费时间和实际花费时间的偏差。
8.测试中识别的风险和处理的风险数目。
9.由于事件制约因素浪费的时间。

二、软件测试执行结果的评估

1，测试通过与失败：测试执行对每一项要测试的内容都必须有个结论。即测试是否通过。

答案为“是(Yes)”或者“否(No)”。
通过：测试实际输出结果和测试期望结果一致
未通过：测试实际输出结果和测试期望结果不一致
• 测试结果的不一致或者失败并不一定是由于测试对象的缺陷引起的，也许是因为测试环境出错、测试人员执行测试时人为误差等。
• 如果是由于测试对象引起的不一致，那么测试人员需要提交相应的缺测试
结果的比较：手动比较；自动比较

2， 测试覆盖率与通过率：测试执行人员应该正确理解四个度量指标

测试覆盖率：是用来度量测试完整性的一个指标
测试执行率：指实际执行过程中确定已经执行的测试用例比率
测试通过率：用来度量测试执行结果的一个指标
缺陷解决率：指某个阶段已关闭缺陷占缺陷总数的比率

3，测试通过标准

出口准则(Exit Criteria):
•可用于报告和计划什么时候可以停止测试
•与利益相关者达成一致的通用和专门的条件，用于正式定义一个过程的结束点
•出口准则的目的可以防止将没有完成的任务错误地看成任务已经完成评估测试
出口准则和报告阶段的主要测试活动有:
•将测试状态和测试计划中的出口准则进行比较。
•评估是否需要更多的测试执行，或者是否需要更改测试出口准则。
•输出测试总结报告。
评估测试出口准则和报告阶段的主要输入:
1)测试状态报告、缺陷状态报告、风险状态报告、项目测试周报告/月报告、测试出口准则和测试计划。
2)回归测试所运行的用例全部通过。
3)缺陷经过验证。
4)所有缺陷都被指明处理方式。
5)同行审查没有新的缺陷或没有严重缺陷产生。

对测试组所测试项目或产品的测试审查工作的基本原则:
1)不依据所设计测试用例,进行自由测试。
2)测试时间保持在3个正常工作日以内。
3)如发现严重缺陷,则一轮测试结束后,更新版本并执行回归测试。
4)提交当日测试纪录。
5)编写同行审查总结报告(报告以简单为好)。

一种定义缺陷分类的

方法1：

A类—— 严重错误
(1)由于程序所引起的死机,非法退出
(2)死循环
(3)导致数据库发生死锁
(4)数据通讯错误
(5)严重的数值计算错误
B类—— 较严重错误
(1)功能不符
(2)数据流错误
(3)程序接口错误
(4)轻微的数值计算错误
C类—— 一般性错误
(1)界面错误(详细文档)
(2)打印内容、格式错误
(3)简单的输入限制未放在前台进行控制
(4)删除操作未给出提示
D类——较小错误
(1)辅助说明描述不清楚
(2)显示格式不规范
(3)长时间操作未给用户进度提示
(4)提示窗口文字未采用行业术语
(5)可输入区域和只读区域没有明显的区分标志
(6)系统处理未优化
E类——测试建议(非缺陷)

方法2：【缺陷分类和级别定义】

测试过程中发现的缺陷一般分为如下几类：
代码问题：不满足需求、功能实现错误；对产品或项目质量有影响的bug可统一划入；
设计缺陷：页面美观性、协调性、错别字等
用户体验：对产品、项目的建议性意见，不强制要求修改
性能问题：进行性能测试时使用，暂定：网络延时、内存问题、CPU占用、硬盘问题
安全问题：业务功能存在的安全问题
接口问题: 涉及有模块间数据传递时使用
配置问题: 由于提供的配置不当或者配置不能够满足实际要求而出现的问题

根据各类缺陷的严重程度将缺陷分为5个等级，具体如下：
1、低(Low) -建议类错误，对软件的改进意见或者建议。如：
　　a、功能建议
b、操作建议
c、校验建议
　　d、说明建议
　　e、UI建议

2、中(Medium) -使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。如：
　界面错误：
　　a、使操作者不方便或者遇到麻烦，但不影响执行工作功能的实现
　　b、界面、控件的摆布、图标、输入输出不规范
提示类错误：
　　a、删除操作未给出提示
　　b、长时间操作未给出提示
　　c、提示窗口文字未采用行业术语
　　d、出错没有提示
其他错误
　　a、不符合编码标准
　　b、辅助说明描述不清楚、不规范
　　c、快捷键无效，快捷键错误操作
　　d、打印内容、格式错误

3、高(High) -影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用。如：
数据库缺陷：数据库设计未达到第三范式的要求或需求规格说明的格式水平
操作错误：因错误操作迫使程序中断
功能错误：
　　a、程序功能无法实现
　　b、程序功能实现错误
其他错误：
　　a、脚本错误
　　b、软件产品的编译，打包，安装，卸载错误

4、非常高(Very High) - 规定的功能没有实现或不完整或产生错误结果；设计不合理造成性能低下，影响系统的运营；使系统不稳定、或破坏数据；而且是常规操作中经常发生或非常规操作中不可避免的主要问题，且没有办法更正（重新安装或重新启动软件不属更正办法），须尽快修正，如：
数据缺陷：
　　a、数据计算错误
　　b、数据约束错误
　　c、数据输入、输出错误
数据库缺陷：
　　a、数据库发生死锁
　　b、数据库的表、业务规则、缺省值未加完整性等约束条件
　　c、数据库连接错误
　　d、数据通讯错误
接口缺陷：
　　a、程序接口错误
　　b、硬件接口、通讯错误
功能错误：
　　a、程序功能无法实现
　　b、程序功能实现错误

5、紧急(Critical) -不能执行正常工作或重要功能，使系统崩溃或资源严重不足，数据丢失（金币，包子）非常死机等导致系统不能继续运行须马上修正，如：
　　a、由于程序所引起的死机，非法退出
　　b、程序死循环
　　c、性能与需求不一致（压力测试）
　　d、存在安全性与保密性问题
　　e、文件打开与保存错误

总结：
1级-建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
2级—较小错误的软件缺陷（Minor），使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。
3级—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
4级—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
5级—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。

方法3：【缺陷的定义级别、优先级及状态】

一、软件缺陷的定义及主要类型

我们对软件缺陷分析一下,所谓"软件缺陷（bug）"，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。

进行软件缺陷分析后,软件缺陷的主要可以分为以下几种类型：

（1）设计不合理;
（2）功能、特性没有实现或部分实现;
（3）运行出错，包括运行中断、系统崩溃、界面混乱等;
（4）与需求不一致，在执行TestCase时则为实际结果和预期结果不一致;
（5）用户不能接受的其他问题，如存取时间过长、界面不美观;
（6）软件实现了需求未提到的功能。

二、软件缺陷的级别、优先级及状态

软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。

A类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等

B类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件

C类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等

D类—较小错误的软件缺陷（Minor）:使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚

E类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

常用的软件缺陷的优先级表示方法可分为：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。

正确评估和区分软件缺陷的严重性和优先级，是测试人员和开发人员以及全体项目组人员的一件大事。这既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该要引起足够的重视。这里介绍三种常用的技术工具供大家参考。

（1）20/80原则

管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些软件缺陷是最重要的，哪些软件缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则—分清轻重缓急，把测试活动用在最有生产力的事情上。

（2）ABC法则

古人云：事有先后，用有缓急。测试工作其实也是如此，分清软件缺陷的轻重缓急，不但做处理软件缺陷来井井有条，完成后的效果也是不同凡响。因此，我们在测试工作中要时时记住一点，手边的软件缺陷并不一定就具有第一优先处理的重要性。只有正确的判断，才可将测试活动效率增加数倍。

ABC法则是设定软件缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据软件缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类软件缺陷作为测试最重要的最有价值的最关键的缺陷，并保证首先把A类软件缺陷先处理。其次是B类软件缺陷，然后是C类软件缺陷，然后是其它的，还有一些不紧急不重要的软件缺陷根本没有必要去做。

（3）四象限原则，把软件缺陷进行分类

在处理测试软件缺陷中，常会遇到千头万绪、问题繁多的情况，有些测试人员会被测试出来众多的软件缺陷所压垮，有些人则是悠然自得、高效完成。到底是什么原因造成这种区别呢？原因在于对软件缺陷分类是否合理。

那么，我们该如何对软件缺陷进行合理的分类呢？其实很简单，在一张坐标纸上，先划分好四个象限，然后只需记住四个字就行，那就是"轻重缓急"。“轻”，指的是相对重要但不紧急的软件缺陷；“重”，是指最重要也是最紧急的软件缺陷；“缓”，指的是不重要也不紧急的软件缺陷；“急”，则是指不是最重要但却最为紧急的软件缺陷。理清这种关系之后，就算同时测试许多不同类型的软件缺陷，也会很快清楚哪些软件缺陷是必须马上完成，哪些缺陷是可以暂时缓一缓，这样也就不会被堆积如山的软件缺陷所压垮，测试效率自然也会得到很大的提高。

4， 测试执行结果报告：
定义：测试执行总结报告是将数据收集和分析结果进行文档化，并且提交给相应的团队作为以后项目的参考文档。测试执行总结报告是进行软件测试过程评估和改进的重要输入，也是进行相关开发过程改进和测试度量数据库更新的主要输入。
测试执行结果报告包含：
·一个测试执行的结果报告模板；
·缺陷状态报表；
·验收测试结果报告
测试执行总结报告主要构成部分：
• 概要信息
• 测试风险
• 测试工作量
• 测试执行

三、软件测试执行的最佳实践

1，测试执行注意事项

~全方位的观察测试用例执行结果
~加强测试过程记录
~及时确认发现的问题
~与开发人员良好的沟通
~及时更新测试用例

2，提高测试执行水平的十个注意点:

工作效率、耐心、责任心、排查问题的能力、回归测试的覆盖度、敏捷测试模式的效率、注意细节、提高自动化测试覆盖度、不断自我提高、提高业务熟练度