软件测试分类与分级

4.1软件测试分类

4.1.1是否关心内部结构：

（1）白盒测试（白盒测试一般是静态测试）

注重于内部结构，又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

（2）黑盒测试（黑盒测试基本上都是动态测试）

注重于软件的功能，把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性.

（3）灰盒测试：介于白盒和黑盒之间，它不像白盒那样详细、完整、但比黑盒更注重于内部逻辑

4.1.2.开发过程级别：

（1）单元测试：偏向于白盒测试，它测试的是每个单元模块的程序结构

（2）集成测试：集成是单元和单元拼在一起，不注重单元与单元之间的内部结构，而更注重于单元和单元拼在一起后的接口是否正确，一般用灰盒来测

（3）系统测试：测试的是软件的一些功能，用黑盒来测

（1）验收测试：又称为用户测试，关注用户的需求

4.1.3.是否执行程序：

（1）静态测试：静态测试是指不运行被测程序本身，通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。其被测对象是各种与软件相关的有必要进行测试的产物，是对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态测试可以手工进行，充分发挥人的思维的优势，并且不需要特别的条件，容易展开，但是静态测试对测试人员的要求较高，至少测试人员需要具有编程经验。

静态测试包含的内容：

静态测试主要包括各阶段的评审、代码检查、程序分析、软件质量度量等，用于对被测程序进行特性分析。其中评审通常有人来执行；代码检查程序分析、软件质量度量等即可人工完成，也可用工具来完成，但工具的作用和效果相对更大更好一些。

（2）动态测试：通过运行被测程序来检查运行结果与预期结果的差异；

4.1.4执行过程是否要人工干预：

（1）手动测试（规模、复用性小）

（2）自动测试（规模大的产品）

4.1.5测试实施组织：开发测试、用户测试、第三方测试

4.2.功能测试与非功能测试

（1）功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。功能性测试又叫作黑盒测试；

（2）非功能性测试包括：性能、安全性、可使用性、兼容性、并发性；

4.3软件测试分级

（1）组件测试：针对单个软件单元的测试都可以称为组件测试，是在程序级别进行的测试。目的：①保证各个模块的正确进行；

      ②保证整个流程在各个模块能按照正确的逻辑进行执行；

（2）集成测试：也叫组装测试、联合测试，是一种旨在暴露接口以及集成组件/系统间交互时存在缺陷的测试。在保证组件测试的前提下还要保证各个模块的兼容性；

（3）配置项测试：测试的对象是计算机软件配置项，配置项测试可根据软件测评任务书、合同或其他等效文件及软件配置项的重要性、安全性关键等级对要求进行裁剪，但必须说明理由。

（4）系统测试：将已经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。

（5）验收测试：指确认一统是否符合设计规格或需求内容的测试。通常由使用系统的用户来进行测试。

（6）维护测试：指软件被市场接受后，再运行一段时间后，在需要做某些修正、改变或扩展的情况下进行的维护测试。

软件缺陷管理

5.1.软件缺陷概念：符合下面5个规则中的一个，就是软件缺陷

（1）软件未实现产品说明书要求的功能

（2）软件出现了产品说明书指明不应该出现的错误

（3）软件实现了产品说明书未提到的功能

（4）软件未实现产品说明书虽未明确提及但应该实现的目标

（5）软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

5.2.软件错误、软件失效、软件故障；

①软件错误：导致期望的运行结果和实际运行结果间出现差异的一些问题；

②软件故障：指软件运行过程中出现的一种不希望或不可接受的内部状态；

③ 软件失效：软件无法满足日益发展的需求；

5.3.缺陷产生的原因：需求分析、设计、编码等阶段产生缺陷（出现缺陷的最大原因在需求分析阶段，其次是在设计阶段）；

5.4.软件缺陷管理目标：

  确保每个被发现的缺陷都能及时得到处理，是测试工作的一项重要内容。

（1）确保每个被发现的缺陷都能被解决。

（2）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段。

（3）收集缺陷数据并进行数据分析，作为组织的过程财富。

5.5.缺陷的基本信息：

（1）缺陷标题 （2）标识 （3）报告人 （4）报告日期 

（5）程序的名称 （6）版本号 （7）配置 （8）缺陷类型 （9）严重性 （10）优先级 

（11）关键词 （12）缺陷描述 （13）重现步骤 （14）结果对比 （15）附件

5.6. 缺陷严重度和优先级

5.6.1软件缺陷的严重度：

Critical：不能执行正常功能或重要功能，或者危及人身安全；

Major：严重的影响系统要求或基本功能的实现，且无法更正（重新安装或重新启动该软件不属于更正办法）；

Minor:严重影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）；

Cosmetic：造成操作者不便或遇到麻烦，但不影响执行工作或重要功能；

Other：其它错误

5.6.2软件缺陷的优先级：

High：指应该被立刻解决的缺陷。

Middle：指缺陷需要正常排队等待修复或列入软件发布清单。

Low：指缺陷可以在方便的时候被纠正。

5.6.3关系：

缺陷的严重度和优先级是含义不同但相互联系密切的两个概念，从不同的侧面描述了软件缺陷对软件质量、最终用户、开发过程的影响程度和处理方式。

一般来说，严重度高的的缺陷具有较高的优先级，严重度高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不尽善尽美，可以稍后处理。

但是优先级和严重度并不总是一一对应，但也存在低优先级、高严重度的缺陷，或者高优先级、低严重度的软件缺陷。

5.7.缺陷管理的基本流程

 

（1）首先项目创建并初始化；

（2）测试人员发现错误，提交错误报告，此时缺陷状态为New；

（3）项目经理收到测试人员提交的错误报告，对其进行确认，并分配给开发人员，此时缺陷状态为Open；

（4）开发人员收到分配的错误，对其进行修正，并将缺陷状态改为Fixed，再次将缺陷发送给测试人员进行确认；

（5）测试人员对修复的错误进行验证，错误消除，缺陷状态改为Closed，否则错误状态将重启；

（6）如果错误暂时无法修改或者开发员认为无必要修改，错误将提交给评审委员会进行检查是否有必要对其进行修改，如果没有必要进行修改，则关闭项目缺陷；

（7）如果有必要进行修改则返回（4）；

 

 

 

测试人员：缺陷发现者

项目经理：项目的负责人

开发人员：执行开发任务的人员，主要完成设计、编码工作

评审委员会：起仲裁作用

5.8.软件缺陷报告：

缺陷报告是软件测试过程中最重要的文档；是缺陷被修正的唯一方法，记录了缺陷发生的环境，如各种资源的配置情况；

缺陷的再现步骤以及缺陷性质的说明记录着缺陷的处理过程和状态；

缺陷的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程

5.9.缺陷报告的基本信息：

编号		编号
1	缺陷标题	8	缺陷的类型
2	缺陷ＩＤ	9	严重性
3	报告人	10	优先级
4	报告日期	11	关键词
5	程序的名称	12	缺陷描述
6	版本号	13	重现步骤
7	配置	14	结果对比

 

5.10.缺陷报告的5C准则：

（1）准确：每个组成部分的描述准确不会引起误解。

（2）简洁：只包含必不可少的信息，不包括任何多余的内容。

（3）清晰：每个组成部分的描述清晰，易于理解。

（4）完整：包含复现该缺陷的完整步骤和其他本质信息。

（5）一致：按照一致的格式书写全部缺陷报告。

5.11. 5W1H原则

（1）Why——为什么干这件事？（目的）； 

（2）What——怎么回事？（对象）； 

（3）Where——在什么地方执行？（地点）； 

（4）When——什么时间执行？什么时间完成？（时间）； 

（5）Who——由谁执行？（人员）； 

（6）How——怎样执行？采取哪些有效措施？（方法）。 

以上六个问题的英文第一个字母为5个W和1个H，所以简称5W1H工作法。运用这种方法分析问题时，先将这六个问题列出，得到回答后，再考虑列出一些小问题，又得到回答后，便可进行取消、合并、重排和简化工作，对问题进行综合分析研究，从而产生更新的创造性设想或决策。