导图社区 信息系统综合测试与管理
- 44
- 4
- 1
- 举报
信息系统综合测试与管理
简单概况描述了信息系统的测试基础知识和测试管理的基本知识，适合准备考信息系统项目管理师的同学或者想从事软件测试的同学
编辑于2022-02-01 14:54:45- 测试管理
- 相似推荐
- 大纲
测试基础与管理
软件测试模型
V模型
V模型反映了测试活动与分析和设计的关系
V模型左边标示开发过程的各阶段，右边标示测试过程中的各阶段
软件测试V模型示意图
优点
将复杂的测试工作按阶段划分为各个小阶段来实现
从多角度测试系统找出更多的缺陷
缺点
软件测试容易误导为软件开发的最后一个阶段
在开发编码完成后才介入测试，导致一些在需求和设计中的问题在后期验收测试中才被发现
需求、设计阶段产生的问题不能很早发现
质量控制和测试效率无高效发挥
V模型失败的原因
是它把系统开发过程划分为具有固定边界的不同阶段，导致测试人员很难跨过这些边界来采集测试所需要的信息，并且阻碍了测试人员从系统描述的不同阶段中取得信息进行综合考虑
W模型
W模型增加了软件各开发阶段中同步进行的验证和确认测试活动
软件测试W模型
优点
测试和开发同步进行，有利尽早发现问题
增加非程序角度测试系统的思想
测试准备及设计工作提前，提高测试质量及效率
缺点
把软件开发视为需求、设计、编码等一些列串行的活动
开发和测试保持一种线性的前后关系
无法支持迭代、自发性及变更调整
H模型
H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
软件测试H模型
优点
将测试从开发中独立出来，利于研究更深的测试技术
同时测试多个项目，可对测试技术重复利用
高效调整测试人员
缺陷修复时不受项目组内部人员限制
缺点
独立的测试组对系统不够深入
影响测试质量及测试效率
X模型
X模型是对V模型的改进，提出针对单独的程序片段进行相互分离的编码和测试
通过频繁的交接和集成最终合成可执行的程序
软件测试X模型
优点
强调单元测试及集成测试的重要性
引入探索性测试使测试模型与现实更接近
缺陷修复时不受项目组内部人员限制
缺点
只强调测试过程中的部分内容
没有对需求测试、验收测试等内容进行说明
前置测试模型
前置测试模型
前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为
在开发阶段以“编码--测试--编码--测试”的方式来体现
对每一个交付内容进行测试
在设计阶段机芯测试计划和测试设计
验收测试独立于技术测试，包含3个要素：基于测试的需求、验收标准和验收测试计划
技术测试主要是针对开发代码的测试，例如单元测试、集成测试、系统测试
前置测试增加了静态审查，以及独立的QA测试
前置测试模型用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的重要意义
软件测试类型
按照开发阶段划分
单元测试
定义
单元测试又称模块测试，是针对软件设计的最小单元（即程序模块）进行正确性验证的工作
单元测试的原则
应该尽早进行软件单元测试
应该保证单元测试的可重复性
尽可能采用测试自动化的手段来支持单元测试活动
单元测试的内容
单元功能测试
单元接口测试
单元局部数据结构测试
单元中重要的执行路径测试
单元的各类错误处理路径测试
单元边界条件测试
集成测试
定义
集成测试又称组装测试、联合测试、子系统测试或部件测试
集成测试是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动
集成测试关注的是模块间的接口，接口之间的数据传递关系
集成测试的内容
模块间接口测试
模块间数据传递
全局数据结构测试
集成测试的目的
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失
一个模块的功能是否会对另一个模块的功能产生不利的影响
各个子功能组合起来，能否达到预期要求的父功能
全局数据结构是否有问题
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度
在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统
集成策略
非增值式策略
增值式策略
系统测试
系统测试的内容
从用户角度对系统做功能性的验证
非功能性的验证
系统测试概述
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求
系统测试检查软件的行为和输出是否正确
系统测试的对象不仅包括需要测试的产品系统的软件，还要包括软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口
系统测试更多程度上是站在用户的角度上对系统功能性的验证，以及非功能性的验证（包括压力测试、测试设计、安全性测试、容错测试、恢复性测试等）
系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估等几个阶段
系统测试的依据主要是需求规格说明书、各种规范、标准和协议等
系统测试的目的
是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与设计不符合的地方
系统测试还有检验系统的文档等是否完整、有效
系统测试的测试用例根据需求分析说明书来设计，并在实际使用环境下运行
系统测试一般使用黑盒测试技术，并由独立的测试人员完成
系统测试的意义
系统测试的环境是软件真实运行环境的最逼真模拟
通常系统测试的困难在于不容易从系统目标直接生成测试用例
验收测试
验收测试的内容
对整个系统的测试与评审
根据验收通过准则分析测试结果
决定是否接收系统及测试评价
验收测试概述
验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动
是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试
验收测试是按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收系统
验收结果评价
测试项目通过
测试项目没有通过，并且不存在变通方法，需要作很大的修改
测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进
测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说清楚，应该修改测试计划
验收测试的方法
易用性测试
兼容性测试
安装测试
文档（如用户手册、操作手册等）
验收测试完成的标准
完全执行了验收测试计划中的每个测试用例
在验收测试中发现的错误已经得到修改并且通过了测试
完成软件验收测试报告
验收测试注意点
必须编写正式的、单独的验收测试计划
验收测试必须在实际的用户运行环境中运行
由用户和测试部门共同执行比较好
按照测试实施组织划分
开发测试
由公司内部的用户进行的受控测试
证实软件满足规定的需求
注重产品的界面和特色
概述
开发方测试也叫“验证测试”或者“Alpha测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求
Alpha测试不能由程序员或测试员完成
Alpha是由一个用户在开发环境下进行的测试，并且在开发者对用户的“指导”下进行测试
用户测试
由最终用户在客户场所进行验证
不受开发者控制
注重产品的支持性
用户测试是在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符号自己预期的要求
用户测试不是指用户的“验收测试”，而使指用户的使用性测试，对使用质量进行评价
Beta 测试通常被看成是一种“用户测试”，Beta 测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件
Beta 测试由软件的最终用户们在一个或多个客户场所进行
Beta 测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力
只有当Alpha测试达到一定的可靠程度后，才能开始Beta 测试
Beta 测试不能由程序员或测试人员完成
Alpha是第一阶段，一般只供内部测试使用
Beta 测试是第二阶段，已经消除 软件中大部分的不完善之处，但仍可能有缺陷，一般只提供给特定的用户群来测试使用
l是第三阶段，产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行
第三方测试
介于开发方和用户方间的组织的测试
保证测试工作的客观性
评审需求、设计、用户类文档
单元测试、功能测试、性能测试等
概述
也称为独立测试，是介于软件开发方和用户方之间的测试组织的测试
在模拟用户真实应用环境下，进行软件确认测试
第三方测试工作的主要内容
需求分析审查
设计审查
代码审查
单元测试
功能测试
性能测试
可恢复性测试
资源消耗测试
并发测试
健壮性测试
安全测试
安装配置测试
可移植性测试
文档测试以及最终的验收测试
按照测试技术划分
黑盒测试
概述
黑盒测试也称为功能测试，是通过测试来检测每个功能是否都正常使用
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的
测试内容
对界面测试
对功能测试
从用户的角度触发
黑盒测试发现的错误类型
功能不正确或遗漏
界面错误
输入和输出错误
数据库访问错误
性能错误
初始化和终止错误等
黑盒测试用例设计方法
等价类划分
边界值分析法
错误推测法
因果图法
判定表法
正交试验设计法
功能图法
场景分析法
白盒测试
测试内容
检查所有的结构及路径是否正确
检查软件内部动作是否按规定进行
概述
白盒测试又称结构测试，是检查是否所有的结构及路径都是正确的
检查软件内部动作是否按照设计说明书的规定正常进行
目的
通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆盖测试
可以覆盖全部代码、分支、路径和条件
优点
可以检查内存的泄露
可以检查异常处理分支语句是否正确
执行了多少逻辑，可以作为衡量测试是否完整的一个指标
白盒测试与黑盒测试的联系
用白盒测试验证单元的基本功能，同黑盒测试的思考方法设计测试用例
黑盒测试中使用白盒测试的手段，常称为“灰盒测试”
白盒测试需要对程序的内部实现十分熟悉，黑盒测试是完全基于对系统需求的了解
仅仅使用白盒测试，或者仅仅使用黑盒测试都不能系统地全面测试一个软件
灰盒测试
测试内容
关注输出对于输入的正确性
关注内部表现
介于白盒和黑盒测试之间
概述
灰盒测试关乎输出对输入的正确性，同时也关注内部表现
灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例
执行程序并采集程序路径执行信息和外部用户结构结果的测试技术
优点
能够进行基于需求的覆盖测试和基于程序路径覆盖的测试
测试结果可以对应到程序内部路径，便于BUG的定位、分析和解决
能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合
能够需求或设计不详细或不完整对测试造成的影响
缺点
投入的时间比黑盒测试大概多20%~40%的时间
对测试人员的要求比黑盒测试高，灰盒测试要求测试人员清楚系统内部由哪些模块构成，模块之间如何协作
不如白盒测试深入
不适用于简单系统
按照测试执行方式划分
静态测试
概述
静态测试是指不运行程序，通过人工对程序和文档进行分析与检查
对软件中的需求说明书、设计说明书、程序源代码、用户手册等进行检查
测试内容
代码检查
静态结构分析
代码质量度量
动态测试
测试内容
编写测试用例
执行程序
分析程序的输出结果
按照测试对象类型划分
功能测试
概述
功能测试主要检查软件功能是否实现 软件功能说明书（软件需求）上的功能要求
功能测试的主要内容
每一个界面的菜单功能、工具栏、按钮、切换/链接/快捷键、单选/复选按钮，业务流程等选择项功能正确
如果有多个界面，多个界面之间切换/下拉框正确
检查数据项的关联与限制功能是否正确
找出设计文档中要求的未被包含在上述几项测试中的功能，逐项测试检查是否达到设计和需求的要求的功能
有增删改查等功能的，还应该手工打数据库表检查
界面测试
用户界面（UI）测试用于核实用户与软件之间的交互
用户操作界面、输出报表的格式以及代码的命名应符合统一的规则
用户操作界面、输出报表的字段位置、长度、类型应与UI设计文档的要求一致
用户操作界面、输出报表的风格一致、协调
提示、菜单、帮助的格式是否一致
提示、菜单、帮助中的术语是否一致
各个控件之间的对齐方式是否一致
输入界面和输出界面在外观、布局、交互方式上是否一致
功能类似的相关界面在外观、布局、交互方式上是否一致
同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文字大小、字体、颜色、对齐方式是否一致，字体大小是否与界面的大小比例协调
多次连续界面依次出现的情况下，界面的外观、操作方式是否一致
系统是否拒绝客户的错误输入并做出提示
系统是否在用户完成操作时给出操作成功的提示
用户界面是否存在空白控件，没有空白空间的界面是杂乱无章的
各个控件的间隔是否一致，垂直和水平方向上是否对齐
是否允许动作的可逆性，返回原有操作
流程测试
流程测试关注的是业务操作的流程
按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程
目的是检查软件在按流程操作时是否能够正确处理
流程测试要有基本数据，以便系统测试多次使用
流程测试不必覆盖到所有功能点，因为流程测试是功能测试的一个补充
流程不要被具体的模块所限制，各个模块可以交叉
流程可大可小，但每一个流程都要是一个典型的业务操作
接口测试
概述
根据系统的需求说明书，以实体（即具体业务处理）为对象，主要按业务的需求测试其输入、处理、输出是否满足需求
验证每个业务既符合实际工作的需要，又验证业务的处理过程是正确的，输出的结果是正确的
接口测试是测试系统组件间接口的一种测试
接口测试主要用于检测外部系统与系统之间以及内部各个系统之间的交互点
接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等
安装测试
安装测试包括测试安装代码以及安装手册，安装手册如何提供进行安装，安装代码提供安装一些程序能够运行的基础数据
安装测试注意要点
软件在不同操作系统下安装的过程
软件安装后是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里
软件安装各个选项的组合是否符合概要设计说明
软件安装向导的UI测试
软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
软件安装过程中意外情况的处理是否符合要求（如死机、重启、断电）
安装过程是否可以回溯的（即是否可以点上一步重新选择）
软件安装过程中是否支持快捷键，快捷键的设置是否符合用户要求
对某些软件要考虑客户端的安装、服务器的安装、数据库的安装及单机版和网络版的安装
卸载系统注意要点
直接删除安装文件夹卸载的提示是否与概要设计说明一致
测试使用系统自带的添加删除程序卸载的情况
测试软件自带的卸载程序
测试卸载后文件是否全部删除包括安装文件夹、注册表、系统环境变量
卸载过程中出现的意外情况的测试（如死机、断电、重启）
卸载是否支持取消功能，单击取消后软件卸载的情况
软件自带卸载程序的UI测试
如果软件有调用系统文件，单击取消后软件卸载的情况
系统升级注意要点
测试升级后的功能是否与需求说明一样
测试与升级模块相关的模块的功能是否与需求一致
升级安装意外情况的测试（如死机、断电、重启）
升级界面的UI测试
不同系统间的升级测试
文档测试
非交付用户的文档测试
交付用户的文档测试
源代码测试
性能测试
概述
性能测试是检查系统是否满足需求规格说明书中规定的性能
特别是对于实时系统或嵌入式系统
性能测试通常是和强度测试结合起来进行，并通常要求同时进行硬件和软件的检测
性能测试的表现
对资源利用（如内存、处理机周期等）进行的精确度量
对执行间隔
日志事件（如中断）
响应时间
吞吐量（TPS）
辅助存储区（例如缓冲区、工作区的大小等）
处理精度等进行的检测
负载测试
是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试
负载测试也是检查在系统运行环境不正常到发生故障的情况下、系统可以运行到何种程度的测试
负载测试的目标：确定并确保系统在超出最大预期工作量的情况下仍能正常运行
压力测试
并发测试
主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用等
几乎所有的性能测试都会涉及并发测试
并发测试的目的：不是为了获得性能指标，而是为了发现并引起的问题
并发测试有随机并发测试、共享并发测试和同步并发测试
并发用户数计算公式：C=NL/T（N是用户数量，L是平均时长，T是考察的时间长度）
大数据量测试
大数据测试包括独立的数据量测试和综合数据量测试两类
大数据量测试主要分为三种
实时大数据量
极限状态下的测试
前面两种的 结合
大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据
稳定性测试
通常是采用系统稳定运行情况下的并发用户数或者日常运用用户数
稳定性测试可以反映出系统的性能问题，例如内存泄漏
数据库测试
数据库测试的主要因素有：数据完整性、数据有效性和数据操作和更新
数据完整性
测试的重点是检测数据损坏程序
数据有效性
数据有效性能确保信息的正确性，使得前台用户和数据库之间传送的数据是准确的
数据操作和更新
根据数据的特性，数据库管理员可以对数据进行各种不受限制的管理操作，具体包括：增加记录、删除记录、更新某些特定的字段
网络测试
网络测试就是验证网络的建设是否成功的手段
主要验证的几个方面
链路连接情况、错包率、连通性、网络质量、路由策略、备份路由、网管等
网络测试主要是利用Ping、traceroute、sh ip route、sh ip route vrp、sh int命令和网管软件结合起来完成测试工作
网络测试内容
链路测试
测试范围包括广域网中的每一条链路，利用PING工具验证这些链路的状况
错包率测试
测试范围包括广域网中的每一个网络设备
利用Cisco和ISO命令show interface测试这些设备的在用断开的错包率
连通性测试
测试范围包括自治区的服务器到下面各个地州的工作站之间的连通情况
利用PING工具验证这些路径的连通情况
质量测试
测试范围包括每条广域网链路的时延和丢包率
利用PING工具测试这些的链路的质量
路由策略测试
进入广域网中的每一个路由器查看它们的MPLS路由表和VPN路由表
增加一台路由器，查看相应域的路由表的收敛速度
减少一台路由器，查看相应域的路由表的收敛速度
利用Cisco的ISO命令show ip route、show ip route vrf、ping、traceroute等工具来测试这些内容
备份路由测试
查看当前路由情况
断开主路由测试备份路由的启用情况，包括路由收敛速度
重新接上主路由测试主路由的恢复情况，包括路由收敛速度
利用ping、traceroute等工具、测试备份路由
按照质量属性划分
容错性测试
容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段
容错性测试包括两方面
输入异常数据或进行异常操作，以检验系统的保护性
灾难恢复性测试
兼容性测试
兼容性测试分为软件兼容性测试、硬件兼容性测试和数据兼容性测试
目的
测试软件是否能在不同的操作系统平台上正常运行
测试软件是否能在同一操作平台的不同版本上正常运行
软件本身能否向前或向后兼容
测试软件能否与其他相关的软件兼容
数据兼容性测试，主要是指数据能否共享
安全性测试
安全性的两个关键方面
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问
安全性模拟测试
正面攻击或从侧面、背面攻击系统中易受损坏的部分
以系统输入为突破口，利用输入的容错性进行正面攻击
申请和占用过多的资源压垮系统，以破坏安全措施、从而进入系统
故意使系统出错，利用恢复系统的过程，窃取用户口令及其他信息
通过浏览器残留在计算机上的垃圾信息，以窃取口令、安全码、译码关键字等重要信息
浏览全局数据，期望从中找到安全信息
浏览那些逻辑上不存在，但在物理上存在的各种记录和资料
假如有充分的时间和资源，好的安全性测试最终应该突破保护、进入系统
可靠性测试
概述
可靠性测试是指在预期的使用环境中，为检测出软件缺陷，验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件
软件可靠性是面向故障的测试，每一次测试都由代表用户完成，使得测试称为最终软件产品运行的预演
软件可靠性测试包括可靠性增长测试和可靠性验证测试
可靠性增长测试
测试以迭代方式进行，根据测试过程中检出和跟踪到的故障，使用基于软件可靠性增长模型和统计推理的可靠性评估方法，进行故障强度和测试进展跟踪
可靠性验证测试
是软件产品发布前进行的最后测试，是最终检验而不是调试
目标是确定一个软件产品在风险限度之内的可接收程度
验证软件可靠性满足一定的要求
通过对软件可靠性测试中观测到的失效情况进行分析，可以验证软件可靠性的定量要求是否得到满足
可用性测试
可用性测试是评估测试设计方案或者产品的可用性水平
常用的评估指标
用户没有帮助的情况下完成任务的比例
完成任务所用的时间
用户寻求帮助的次数
维护性测试
可维护性是衡量对已完成的软件进行调整需要多大的努力
软件维护包括三大类
纠正性维护：主要是纠正软件存在的错误
适应性维护：主要是为能适应变化的外部环境，对软件应用程序做出修改
完善性维护
提高软件可维护性
提升软件工程模块化和质量技术
创建精密的软件品质目标和优先级
选有可维护的程序设计语言
可移植性测试
可移植性指未经修改或修改部分源代码后，应用程序或系统从一种环境移植到另一种环境中还能正常工作的难易程度
可移植性的主要周期
移植可行性分析
分析测试的需求
设计测试用例
制订测试计划
搭建测试环境
执行测试
分析测试结果
代码变更测试
安装测试
多种软硬件环境的安装测试
多种安装设置时的测试
安装路径
安装类型
安装顺序测试
安装后启动测试
修复安装测试和卸载测试
更新包测试
用户界面测试
功能测试
易用性测试
易用性测试主要考察评定软件易学易用性、各个功能是否易于完成、软件界面是否友好等在很多类型的管理软件中是非常重要的
导航测试
图形测试
内容测试
整体界面测试
按照测试地域划分
本地化测试
软件界面测试
基本功能测试
安装/卸载测试
文档测试
国际化测试
设计评审
代码审查
对源语言的功能测试
对伪翻译版本的测试
软件测试技术
黑盒测试法
黑盒测试用例设计方法
测试区域确定法
等价类划分法
在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。例如0-100，那么0<=x<=100就是有效 等价类，x>100和x<0，就是2个无效等价类
在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，确立一个有效等价类和一个无效等价。
在输入条件是一个布尔量的情况下，确定一个有效等价类和一个无效等价类
在规定了输入数据的一组值（假定n个），程序要对每一个输入值分别处理的情况，确定n个有效等价类和一个无效等价类
在规定了输入数据必须遵守的规则的情况下，确定一个有效等价类和若干个无效等价类
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类
6个方面
边界值分析法
如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据
组合覆盖法
组合覆盖是覆盖率很高的覆盖法
全组合覆盖法
每个因素的值都至少遍历一次
全组合法覆盖率比较高，但测试用例量较大，会产生冗余
成对组合覆盖法
成对组合覆盖要求任意两个因素（输入条件）的所有水平组合至少要被覆盖1次
正交实验设计法
正交试验设计法，是使用已经造好了的表格（正交表）来安排试验并进行数据分析的一种方法
数据覆盖法
设计尽可能少的测试用例，使每个被测元素在设计中的各类数据都被至少执行一次
逻辑推断法
因果图法
因果分析图，是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况
每种组合条件就是“因”，它必然有一个输出的结果，就是“果”
因果图法最终生产的就是判定表，它适合于检查程序输入条件的各种组合情况
使用因果图法的优点
考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系
能够帮助测试人员按照一定的步骤，高效率的开发测试用例
因果图法是将自然语言规格说明转化成形成语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性
判定表法
基于判定表的测试是最为严格、最具有逻辑性的测试方法
4个组成部分
条件桩：列出问题的所有条件
条件项：针对条件桩给出的条件列出所欲可能的取值
动作桩：列出问题规定的可能采取的操作
动作项：指出在条件项的各组取值情况下应采取的动作
判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来
判定表能够设计出完整的测试用例集合
大纲法
将需求转化为大纲的形式
业务路径覆盖法
场景分析法
场景分析法是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法
正常的用例场景
备选的用例场景
异常的用例场景
假定推测的场景
场景主要包括的4种类型
场景法的设计步骤
根据说明，描述出程序的基本流及各项备选流
根据基本流和各项备选流生成不同的场景
对每一个场景生成相应的测试用例
对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
功能图法
功能图法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例
功能图法是一种黑盒白盒混合用例设计方法
黑盒测试方法选择策略
首先进行等价类划分，包括输入条件和输出条件的等价划分
在任何情况下都必须使用边界值分析方法，这种方法发现程序错误的能力最强
可以用错误推测法追加一些测试用例
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度
如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选择因果图法和判定表驱动法
对于参数配置类的软件或对多条件查询功能进行测试时，要用正交试验法选择较少的组合方式达到最佳效果
对于业务清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法
白盒测试法
白盒测试遵循的原则
保证一个模块中的所有独立路径至少被测试场一次
所有逻辑值均需要测试真（true）和假（false）两种情况
检查程序的内部数据结构，保证其结构的有效性
在上下边界及可操作范围内运行所有循环
白盒测试的工具
内存泄漏检查工具
代码覆盖率检查工具
性能测试工具
白盒测试方法
静态白盒测试
概述
静态白盒测试是在不执行的条件下，有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程
静态白盒测试的优点
尽早发现软件缺陷
静态测试技术
代码检查法
发现违背程序编写标准的问题
发现程序中不安全、不明确和模糊的部分
找出程序中不可移植部分
违背程序风格的问题，包括变量检查、命名和类型审查、程序逻辑审查
静态结构分析法
静态质量度量法
功能性、可靠性、易用性、有效性、可维护性、可移植性
动态白盒测试
概述
动态白盒测试又称结构测试，因为软件测试员可以查看并使用代码内部结构，从而设计和执行测试
覆盖测试
包括逻辑覆盖和面向对象的覆盖
控制结构测试
控制结构测试包括基于路径的测试和循环测试
其他白盒测试方法
程序插桩
程序变异测试
测试管理
测试管理概述
测试管理的主要因素包括：测试策略的制定、测试项目进度跟进、项目风险的评估、测试文档的评审、测试内部和外部的协调沟通、测试人员的培养等
测试管理内容
按照范围和对象划分
测试部门管理
部门日常事务
部门人员
部门下属项目
部门资产等的跟及管理工作
测试项目管理
测试人员管理、测试计划及测试策略的编写
测试评审的组织
测试过程的跟进
测试内部和外部的沟通协调、缺陷跟踪等
测试管理内容
测试目标的明确，进行测试计划及过程监控准则的制订
测试团队搭建和测试人员管理
测试实施过程的监控，包括测试计划执行的跟踪和测试人员的工作安排等内容
测试风险的评估和风险的应对策略
测试外部的沟通协调和测试问题的确认处理
测试资产、测试产品的统一管理
测试规范的制定
测试绩效考核的制定与考评
监控管理
目的
为测试活动提供反馈信息和可视性
测试监控的任务
记录和管理测试用例的执行状态
根据当前的执行状态，判定测试用例的设计质量和效率
根据发现的缺陷分布，判定结束测试的条件是否成熟
评估测试软件的质量，根据缺陷的数量、严重程度和种类来判断质量
评估开发过程的质量，根据缺陷的分布、修复缺陷的时间、回归测试中发现缺陷数据来判断质量
评估测试工程师的表现，如是否按计划完成测试任务，发现的缺陷的数量及质量
测试监控的内容
测试用例执行的进度
计算公式：测试用例执行的进度=已执行的数目/总数目
测试用例执行进度只表明用例执行的进度，不表示测试的成功率
缺陷的存活时间
计算公式：缺陷的存活时间=缺陷从open到closed的时间
缺陷存活时间表明修改缺陷的效率
缺陷的趋势分析
统计被发现的缺陷数量的分布情况
缺陷存在的问题有几类
代码修改引发新的缺陷
前一版本的测试存在覆盖率的问题，新的测试发现了原先未发现的缺陷
必须先修改某些缺陷后才能继续测试，然后才发现其他的缺陷
缺陷分布密度
计算公式：缺陷分布密度=对应于一项需求的总缺陷数/对应于该项需求的测试用例总数
需要考虑缺陷的优先级和严重程度
如果过多的缺陷集中在某项需求上，可能会存在以下问题
该项功能需求是否过于复杂
该项的需求设计、实现是否有问题
分配给该项的开发资源是否不足
缺陷修改质量
计算公式：缺陷修改质量=每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷）
配置管理
概述
测试过程中的配置管理不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本
如何做
选取适合的配置管理工具
整理配置项，明确相应管理流程
将配置项作为一个整体进行配置管理
增加发布前验收测试环节
采用并行开发方式区分不同的开发活动
明确角色与职责
测试风险管理
主要的风险
需求风险
测试用例风险
缺陷风险
某些缺陷偶发，难以重现，容易被遗漏
代码质量风险
测试环境风险
测试技术风险
回归测试风险
回归测试一般不运行全部测试用例，可能存在测试不完全
沟通协调风险
其他不可预计风险
人员绩效考核
工作内容考核
参与软件开发过程的工作内容考核
参与测试文档的准备工作
执行测试的工作
测试结果缺陷残留
测试人员的沟通能力考核
工作效率与工作质量考核
测试设计中工作效率指标
文档产出率
用于考核测试人员测试用例文档的生产率发小
公式：测试用例文档页数（页）/编写测试用例文档有效时间（小时）
参考指标：根据项目汇总得出平均在1.14页/小时左右
用例产出率
用于考察测试人员测试用例产出率大小
公式：测试用例数（个）/编写测试用例文档有效时间（小时）
参考指标：平均4.21个用例/小时
测试设计工作中工作质量相关指标
需求覆盖率
主要查看是否有功能点遗漏测试的情况
公式：测试用例数（个）/功能点
参考指标：100%。如果连功能指标都不能满足100%覆盖，起码说明测试不充分
文档质量
此指标考察测试人员文档编写的质量如何
公式：缺陷数（评审和同行评审）（个）/测试用例文档页数（页）
参考指标：由于评审是发现的缺陷数是不固定的，这个指标没有可供参考的数值
文档有效率
公式：缺陷数（系统测试）（个）/测试用例文档页数（页）
参考指标：平均2.18个缺陷/页
用例有效率
用于考察用例质量是否较高
公式：缺陷数（系统测试）（个）/测试用例数（个）
参考指标：平均0.59个缺陷用例，也就是说每执行2个用例才得到1个缺陷
评审问题数
测试执行中工作效率相关指标
执行效率
用于获得工作中测试人员每小时执行测试的速度
公式：测试用例文档页数（页）/执行系统测试的有效时间（小时）
参考指标：平均0.53页/小时，1.95个用例/小时
执行效率高不代表测试质量也高
进度偏离度
检查计划时间与实际时间的进度
用于考察测试人员进度情况，监控测试是否按照日程进行，是否满足了工程的进度要求
公式：（（计划开始时间-实际开始时间）+（计划结束时间-实际结束时间））/总工时
参考指标：15%进度偏离是个相对的指标，可能偏离了20个工作日
缺陷发现率
公式：缺陷数（系统测试）（个）/执行系统测试的有效时间（小时）
参考指标：平均1.1个缺陷/小时
测试执行中工作质量相关指标
缺陷数
有效缺陷数/率
该指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或百分百，数和比率越底测试质量越高
公式：缺陷数（系统测试中被拒绝和删除的）（个）/缺陷数（系统测试）（个）
参考指标：平均21.9%（测试人员发现的每100个缺陷中平均有22个缺陷不被开发者确认，认为不是“缺陷”或者错误录入缺陷）
严重缺陷率
参考指标：严重~10% 一般~70% 微小~20%
模块缺陷率
参考指标：平均3.74个缺陷/功能点
遗漏缺陷率
发布后的线上故障，现阶段测试相关的故障主要都是因为测试遗漏，有遗漏就说明我们的测试还是效率不高，可以改进
公式：遗漏缺陷数/（遗漏缺陷数+遗漏版本发现缺陷数）
BUG发现的时间点，BUG曲线的收敛性
理想的效率高的模式应该是前多后少，慢慢收敛的
缺陷定位和可读性
对自动化测试人员效率的度量
自动化测试的引入和使用是否合理
自动化测试，特别是性能测试结束之后，分析部分测试结果，测试结果的分析水平也可以作为衡量测试效率的一个指标
对测试项目负责人效率的度量
测试是否提早介入项目
开发提交测试的时候，标准是否合理，把关是否严格
测试计划阶段，评价测试计划的合理性。包括：任务细分、资源安排、风险预估等
项目结束后，评价项目进行阶段中负责人的跟进情况
测试管理的度量
计划质量
成本质量
成本度量主要放在工作量这块
公式：测试活动计划工作量（估算人日）/测试活动的实际工作量（人日）
参考指标：原则上不能偏离计划的15%~20%左右的上下幅度
对于一个大的项目来说，估算值往往差距非常大，阶段统计时可能有500%左右的上下幅度，需要考虑调整计划
考核注意事项
挑选能够横向对比的指标，分阶段、分任务评定
参与测试的时间长短要重视，加班也要作为特殊考虑因素
测试经理的测试设计和执行部分和项目测试人员一起考核，但测试管理工作要单独考核，作为另外的加分
考核前要考虑向的实际情况
供参考的比例
测试团队发现的bug和所有bug之间的比例
spec设计造成的bug
重复或者误提交的bug所占的比例
每周发现的bug的趋势图
bug严重等级的构成比例
bug从提交到解决的平均需要时间
bug从解决到关闭的平均需要时间