软件测试:分类
2017-01-18 15:07
246 查看
按测试阶段来分类:
1. 单元测试
对软件中的最小可测试单元进行检车和验证。
对于我们来说就是后台类或者前台功能项的测试,一般由开发人员或者结对编程人员来完成。
益处:能尽早发现缺陷,有利于重构,简化集成,减少文档,用于设计
限制:每行代码一般需要3~5行测试代码,所以存在投入与产出的一个平衡
2. 集成测试
是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块,子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
主要测试模块间接口
3. 系统测试
是将集成测试的软件,作为计算机系统的一个部分,与系统其他部分结合起来,在实际运行环境下对计算机系统进行的一系列严格有效的测试,以发现软件潜在的问题,保证系统的正常运行。
单元测试和集成测试一般在模拟环境下测试,系统测试则是在运行环境下进行的测试
测试岗位针对的是系统测试,系统测试是从业务角度来进行的测试
4. 验收测试
也称交付测试。针对用户需求、业务流程的正式的测试,确定系统是否满足验收标准,由用户、客户或者其他授权机构决定是否接受系统。
细分:用户验收测试(开发方来做),运行验收测试(运维人员),合同和规范运行测试,alpha测试(开发者提供的场所和环境由用户来进行的测试),beta测试(用户的环境的测试)
===============================================
按测试手段来分类
1. 黑盒测试,白盒测试
黑盒测试的优势:容易实施,不需要关注内部实现;更贴近用户的使用角度;
黑盒测试的劣势:测试覆盖率低,一般只能覆盖到代码量的不到40%;针对黑盒的自动化测试,复用率较低,维护成本高;
系统测试用黑盒测试较多
黑盒测试主要设计方法:等价类划分法,边界值分析法,错误推测法,因果图法,正交试验分析法,状态迁移图法,流程分析法
白盒测试针对逻辑结构来进行设计的测试,内部逻辑可见
单元测试和集成测试用白盒测试较多
白盒测试优势:迫使测试人员去自习思考软件的实现,理解原理;可以检测代码中的每条分支和路径;可以揭示隐藏在代码中的错误;对代码的测试比较彻底
白盒测试缺点:昂贵(较高的覆盖率);无法检测代码中遗漏的路径和数据敏感性错误;不能直接验证需求的正确性
白盒测试主要设计方法:代码检测法;静态结构分析法;静态质量度量法;逻辑覆盖法;基本路径测试法
2. 静态测试,动态测试
静态测试:无须执行被测程序,而是通过评审软件文档或代码,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不足之处,减少错误出现的概率。
方式:互审,走查,会议
动态测试:通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等
3. 手工测试,自动化测试
手工测试优点:易发现缺陷,容易实施,创造性、灵活性
手工测试缺点:覆盖量化难,重复测试效率低,不一致性、可靠性低,人力资源依赖
自动化测试优点:高效率、速度快,高复用性,覆盖率容易度量,准确,可靠,不知疲劳
自动化测试缺点:机械,发现缺陷率低,一次性投入较大
================================================
按测试模式分类:
1. 瀑布模型
项目计划=》需求分析=》软件设计=》程序开发=》软件测试=》集成维护
文档:项目计划书,需求规格说明,概要设计书,详细设计书,产品使用说明书,维护手册
瀑布模型优点:强调需求、设计的作用;前一阶段完成后,只需关注后续阶段;为项目提供按阶段划分的检查点,里程碑清晰;文档规范
瀑布模型缺点:难以适应需求的频繁变化;项目周期后段才能看到成果;强制的里程碑、完成时间点;文档工作量大
软件测试只是补救的阶段,并不能体现其价值
2. 敏捷测试
敏捷宣言:个体与交互重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划
特点:强调从客户角度进行测试;重点关注迭代测试新功能,不再强调测试阶段;尽早测试,不间断测试,具备条件即测试;强调持续反馈;预防缺陷重于发现缺陷;
传统测试:测试是质量的最后保护者;严格的变更管理;预先的计划和细节的准备;重量级文档;
各阶段测试严格的入口和出口标准;更多在回归测试时进行重量级的自动化测试;严格依赖流程执行;测试团队和开发团队是相互独立的;
敏捷测试:开发和测试人员是紧密合作的,大家都有责任对软件负责;变更是可接受的,拥抱变更;计划随着进展时常调整;只需要绝对必要的文档
各迭代之间已经没有明显的入口和出口标准;所有阶段都需要自动测试,每个人都需要做,是项目集成的一部分;流程不再需要严格执行;团队合作 是无缝隙合作
3. 基于脚本的测试(ST)
参照测试用例来测试
特点:系统性强;容易管理、控制;设计在线、执行在后;主要是验证自己的思路;可预见性
4. 探索式测试(ET)
完全抛开测试用例的测试。它是一种测试风格、思维而不是一种测试技术
特点:自由灵活;和ST是互补的;执行和设计(思考)并行;不断和系统交互,带着问题测试;学习的过程;
优点:更能激发测试人员的创造性和工作乐趣;增加了发现新的或较深入BUG的可能性;在较短时间内找到更多BUG以及对软件做一个快速的评估;有利于更加有效地实施自动化;更加适用于敏捷项目;减少了在简单、繁复用例的无谓编写时间
缺点:测试管理上有局限性,较难协调和控制;对于BUG的重复利用和重现上作用有限;对测试人员的测试技能和业务知识深度依赖较大;只有在被测系统在完全可用的前提下才更有作用;ET的生产率很难定义;ET本身较难进行自动化;
5. 基于风险的测试
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型
1. 单元测试
对软件中的最小可测试单元进行检车和验证。
对于我们来说就是后台类或者前台功能项的测试,一般由开发人员或者结对编程人员来完成。
益处:能尽早发现缺陷,有利于重构,简化集成,减少文档,用于设计
限制:每行代码一般需要3~5行测试代码,所以存在投入与产出的一个平衡
2. 集成测试
是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块,子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
主要测试模块间接口
3. 系统测试
是将集成测试的软件,作为计算机系统的一个部分,与系统其他部分结合起来,在实际运行环境下对计算机系统进行的一系列严格有效的测试,以发现软件潜在的问题,保证系统的正常运行。
单元测试和集成测试一般在模拟环境下测试,系统测试则是在运行环境下进行的测试
测试岗位针对的是系统测试,系统测试是从业务角度来进行的测试
4. 验收测试
也称交付测试。针对用户需求、业务流程的正式的测试,确定系统是否满足验收标准,由用户、客户或者其他授权机构决定是否接受系统。
细分:用户验收测试(开发方来做),运行验收测试(运维人员),合同和规范运行测试,alpha测试(开发者提供的场所和环境由用户来进行的测试),beta测试(用户的环境的测试)
===============================================
按测试手段来分类
1. 黑盒测试,白盒测试
黑盒测试的优势:容易实施,不需要关注内部实现;更贴近用户的使用角度;
黑盒测试的劣势:测试覆盖率低,一般只能覆盖到代码量的不到40%;针对黑盒的自动化测试,复用率较低,维护成本高;
系统测试用黑盒测试较多
黑盒测试主要设计方法:等价类划分法,边界值分析法,错误推测法,因果图法,正交试验分析法,状态迁移图法,流程分析法
白盒测试针对逻辑结构来进行设计的测试,内部逻辑可见
单元测试和集成测试用白盒测试较多
白盒测试优势:迫使测试人员去自习思考软件的实现,理解原理;可以检测代码中的每条分支和路径;可以揭示隐藏在代码中的错误;对代码的测试比较彻底
白盒测试缺点:昂贵(较高的覆盖率);无法检测代码中遗漏的路径和数据敏感性错误;不能直接验证需求的正确性
白盒测试主要设计方法:代码检测法;静态结构分析法;静态质量度量法;逻辑覆盖法;基本路径测试法
2. 静态测试,动态测试
静态测试:无须执行被测程序,而是通过评审软件文档或代码,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不足之处,减少错误出现的概率。
方式:互审,走查,会议
动态测试:通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等
3. 手工测试,自动化测试
手工测试优点:易发现缺陷,容易实施,创造性、灵活性
手工测试缺点:覆盖量化难,重复测试效率低,不一致性、可靠性低,人力资源依赖
自动化测试优点:高效率、速度快,高复用性,覆盖率容易度量,准确,可靠,不知疲劳
自动化测试缺点:机械,发现缺陷率低,一次性投入较大
================================================
按测试模式分类:
1. 瀑布模型
项目计划=》需求分析=》软件设计=》程序开发=》软件测试=》集成维护
文档:项目计划书,需求规格说明,概要设计书,详细设计书,产品使用说明书,维护手册
瀑布模型优点:强调需求、设计的作用;前一阶段完成后,只需关注后续阶段;为项目提供按阶段划分的检查点,里程碑清晰;文档规范
瀑布模型缺点:难以适应需求的频繁变化;项目周期后段才能看到成果;强制的里程碑、完成时间点;文档工作量大
软件测试只是补救的阶段,并不能体现其价值
2. 敏捷测试
敏捷宣言:个体与交互重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划
特点:强调从客户角度进行测试;重点关注迭代测试新功能,不再强调测试阶段;尽早测试,不间断测试,具备条件即测试;强调持续反馈;预防缺陷重于发现缺陷;
传统测试:测试是质量的最后保护者;严格的变更管理;预先的计划和细节的准备;重量级文档;
各阶段测试严格的入口和出口标准;更多在回归测试时进行重量级的自动化测试;严格依赖流程执行;测试团队和开发团队是相互独立的;
敏捷测试:开发和测试人员是紧密合作的,大家都有责任对软件负责;变更是可接受的,拥抱变更;计划随着进展时常调整;只需要绝对必要的文档
各迭代之间已经没有明显的入口和出口标准;所有阶段都需要自动测试,每个人都需要做,是项目集成的一部分;流程不再需要严格执行;团队合作 是无缝隙合作
3. 基于脚本的测试(ST)
参照测试用例来测试
特点:系统性强;容易管理、控制;设计在线、执行在后;主要是验证自己的思路;可预见性
4. 探索式测试(ET)
完全抛开测试用例的测试。它是一种测试风格、思维而不是一种测试技术
特点:自由灵活;和ST是互补的;执行和设计(思考)并行;不断和系统交互,带着问题测试;学习的过程;
优点:更能激发测试人员的创造性和工作乐趣;增加了发现新的或较深入BUG的可能性;在较短时间内找到更多BUG以及对软件做一个快速的评估;有利于更加有效地实施自动化;更加适用于敏捷项目;减少了在简单、繁复用例的无谓编写时间
缺点:测试管理上有局限性,较难协调和控制;对于BUG的重复利用和重现上作用有限;对测试人员的测试技能和业务知识深度依赖较大;只有在被测系统在完全可用的前提下才更有作用;ET的生产率很难定义;ET本身较难进行自动化;
5. 基于风险的测试
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型