软考中级—软件评测师 备考笔记：测试基础

目录软件测试基础基本概念检验与确认软件测试的原则产品质量模型使用质量模型测试用例测试策略软件测试的原则测试过程相关模型V模型W模型H模型敏捷测试模型软件测试的分类按工程阶段划分按是否执行代码划分按测试实施主体划分按是否关联代码划分软件质量特性划分按符合性评价要求划分回归测试软件测试相关标准公共标准与私有标准工作量及成本评估标准软件测试过程和管理软件测试基础基本概念需求分析和设计阶段产生的缺陷很隐蔽缺陷从产生到发现的间隔时间越短修复的代价就越小保证软件质量的措施和手段有很多测试是其中一种软件测试更多的表现为技术性活动而软件质量保证保证则是管理性活动更明显检验与确认验证是检验软件是否满足规格说明的需求确认是检验软件师傅有效是否满足用户的预期用途和应用需求通过验证的软件不一定能够通过确认软件测试的原则溯源性原则测试应当溯源到原始需求工程性原则测试贯穿软件生产的各阶段应尽早开展测试独立性原则避免开发工程师测试自己的程序合理性原则无法对软件开展穷举式的测试不完全性原则测试都不能暴露全部的缺陷相关性原则缺陷常常有聚集现象可接受性原则已发现的缺陷不一定全部修复风险性原则测试本身也是有风险的产品质量模型特性“字”特性子特性“词”子特性八大特性功效简易全靠位置功能性、性能效率、兼容性、易用性、信息安全性、可靠性、维护性、可移植性功功能性功能完备正确适合功能完备性、功能准确性、功能适合性、功能性的依从性效性能效率时间、资源的容量时间特性、资源利用率、容量、性能效率的依从性简兼容性共存互操作共存性、互操作性、兼容性的依从性易易用性辨识学习易操作、以防界面出差错可辨识性、易学性、易操作性、易访问性、用户界面舒适性、用户差错防御性、易用性的依从性全信息安全性保密完整抗抵赖全为核查真实性保密性、完整性、抗抵赖性、可核查性、真实性、信息安全性的依从性靠可靠性恢复容错成熟可用易恢复性、容错性、成熟性、可用性、可靠性的依从性位维护性为了测试各模块分析修改可重用易测试性、模块化、易分析性、易修改性、可重用性、维护性的依从性置可移植性适应安装易替换适应性、易安装性、易替换性、可移植性的依从性完备性完成需求情况正确性正确实现情况适合性完备且正确兼容性与其他软件是否兼容是否支持其他软件共存、互相调用、交换信息等操作易访问性无障碍跨语言能力保密性访问控制性内容保密、最小权限原则数据加密正确性数据保密可移植性在其他设备是否可以使用跨平台使用真实性认证机制唯一标识可核查性确定是谁做的即谁干了什么实体的活动可以被唯一地追溯到该实体的程度抗抵赖性确定身份不可否认。使用数字签名确定发送和接收事实对事务进行数字签名可为数据原发者或接收者提供数据原发和接收证据符合性符合声明使用的标准、认证依从性执行相关法规、标准使用质量模型特性“字”特性子特性“词”子特性使用质量模型效效满抗周境覆盖有效性、效率、满意度、抗风险、周境覆盖效有效性有效性效效率效率满满意度用信舒愉有用性、可信性、舒适性、愉悦性抗抗风险缓解经济及环境依赖健康和安全经济风险缓解性、环境风险缓解性、健康和安全风险缓解性周境覆盖周境覆盖周境完备还灵活周境完备性、灵活性测试用例输入、执行条件及预期结果避免测试的随意性和盲目性测试用例是软件企业的一类资产是企业成熟度的一个表现测试策略平衡测试时间、测试技术、测试人力、质量要求之间的平衡软件测试的原则1.溯源性原则测试应当溯源到原始需求而不仅仅只盯着眼前。工程性原则贯穿软件生产的各阶段。即全生命周期。独立性原则应当避免开发工程师测试自己的程序对同一内容开发与测试角色要拆开避免灯下黑。合理性原则对软件进行完全测试是不合理的。不完全性原则测试不能暴露全部缺陷。相关性原则缺陷常常有聚集现象。可接受性原则可以允许某些缺陷遗留在软件中。风险性原则测试本身也是有风险的。测试过程相关模型V模型编码之后才开始测试活动W模型两个V的叠加一个V描述开发过程一个V描述测试过程开发过程测试过程关注重点需求分析测试目标概要设计测试计划详细设计用例设计编码单元测试仅专注于当前的单元代码单元测试时很少关心功能设计的内容和需求的内容。寻找代码缺陷如笔误或代码级别的逻辑错误。常见的误区之一是将所有的软件缺陷都归结为代码错误。编码笔误、变量、逻辑错误。最大的单元是模块最小的单元是函数。缺陷修复集成测试识别功能设计或架构设计的错误造成的风险。设计错误。对于复杂度较低的系统不安排集成测试也非常常见。缺陷修复系统测试发现软件需求的错误。缺陷修复验收测试W模型实际是两个V的叠加将开发测试的混合V模型拆分成一个V描述需求设计和开发一个V描述测试阶段合二为一成为W。H模型H模型将开发流程和测试流程都独立出来只要测试条件环境满足即开展测试。敏捷测试模型主张简单、拥抱变化、递增和快速反馈需要与开发流程良好融合软件测试的分类按工程阶段划分单元测试模块接口测试局部数据结构测试路径测试错误处理测试边界测试也称模块测试测试一个模块具有数据输入、处理及输出的基本特征各个模块可以并行进行可能需要构造驱动模块或桩模块来支持单元测试调用触发驱动模块待测模块桩模块log也是一种插桩集成测试一次性组装方式增殖式组装方式集成测试的主要任务是发现单元之间的接口验证数据协议是否一致可能存在的问题即验证模块之间的通信协议是否一致系统测试系统测试的目标是确认软件的应用系统能否如预期工作并满足应用的需求系统测试不能由开发团队实施但一般仍由开发方实施相当于团队内部验收确认测试焦点由系统正常运行改为与交付相关的验证和确认上与系统测试相似确认测试又称有效性测试由软件开发方组织验收测试焦点由系统正常运行改为与交付相关的验证和确认上与系统测试相似由用户方组织按是否执行代码划分动态测试通过运行软件来发现错误或验证程序是否符合预期要求静态测试静态测试不运行代码测试对象包括需求文档、设计文档、产品规格说明书以及代码即各类文件文档及代码源码可以及时发现更多的错误减少动态测试的压力降低错误修改的成本更好的保证软件质量静态评审包括内部评审和外部评审内部评审对程序逻辑偏重技术层面。外部评审对需求分析不关心实现外部评审需要用户代表参加也可以邀请领域专家参加按测试实施主体划分开发方供方测试开发方测试注重开发过程中测试涵盖软件生产及交付的各个阶段强调对软件“证真”能够高效与开发团队沟通容易遗漏对软件缺陷的暴露或者忽视用户的需求用户方需方测试只能进行黑盒测试用户方测试只能验收测试缺乏专业人员更好地确认软件是否符合自身的需求第三方独立评价方测试只能进行黑盒测试第三方测试以专业素养对已完成系统进行测试公平公正的地位高度专业化的团队丰富的测试经验完备的测试工具主要开展确认测试开发方委托、验收测试用户方委托、符合性测试也可接受其他用途的委托测试按是否关联代码划分白盒测试也称结构化测试、逻辑驱动测试、基于代码的测试能看见内部实现对程序完全覆盖是不可能的黑盒测试又称功能测试、基于规格说明的测试无法看到内部实现只关心程序的输入和输出依据需求规格说明用户方测试和第三方测试只能进行黑盒测试速记:白盒看代码黑盒看需求灰盒测试较多运用于集成测试中软件质量特性划分功能性测试性能效率测试兼容性测试易用性测试信息安全性测试可靠性测试维护性测试可移植性测试按符合性评价要求划分判定软件是否符合事先已经明确的文件性要求和约束即文件符合性最好由具备资质的第三方测试机构开展更类似于系统测试、确认测试、验收测试需要具备系统完备性才可进行测试。接受需方的验收测试也是一种符合性测试合同符合性测试依据招投标文件或合同相关约定要有准确的描述不能模棱两可需要详细到可以在不同时期进行验证例如运行环境等等条件约束。回归测试只要软件发生了变化都应该进行回归测试原来正确的功能可能受到影响由改动点扩散到周边进行测试每一次回归测试可能需要设计一些新的测试用例同时也会复用已经建立的许多测试用例软件测试相关标准公共标准与私有标准公共标准 国际标准国家标准行业标准地方标准等公共标准的宗旨是维护公共秩序私有标准行业标准、企业标准属于私有标准提高竞争力获取实施标准带来的收益获取收益是私有标准国际标准–国家标准–行业标准–地方标准–团体标准–企业标准工作量及成本评估标准对软件系统进行穷尽测试是一项不可能完成的任务软件测试成本包含直接成本和间接成本直接成本测试人力成本产品说明评审、用户文档集评审、软件测试三部分测试环境成本测试执行过程中所需的软硬件环境、测试设计和实现过程中所需的软硬件环境测试环境成本指的是人力成本即搭建环境所需的人力开销而不是软硬件设备本身的成本测试工具成本是测试过程中所使用到的软硬件工具的成本间接成本办公成本和管理成本软件测试过程和管理组织级测试过程组织级测试过程是一个通用过程不面向具体项目而是适用于整个组织的测试单个测试覆盖项可以实现多个测试条件在一个测试用例中组合多个测试覆盖项的覆盖范围这可以减少测试执行时间。