软考-高项-第二十三章 信息系统综合测试与管理

标签：黑盒 白盒 综合测试 模型 软考 高项 测试 软件 测试用例

23.1测试基础 23.1.1软件测试模型

1. V模型

 

 

2. W模型

 

 

1. 由于V模型在软件开发编码完成后才接入测试工作，导致一些在需求和设计中的问题在后期验收测试中才被发现，这一不能体现“尽早地和不断地进行软件测试”的原则。由此演化成一种W模型
2. 相对于V模型，W模型增加了软件各开发阶段中同步进行的验证和确认测试活动。W模型由两个V自行模型组成，分别代表测试与开发过程，表示出了他们的并行关系
3. ⭐W模型相当两个V模型的叠加，一个开发的V，一个是测试的V，由于在项目中开发和测试是同步进行的，相当于两个V是并列、同步进行的，测试在一定程度上是随着开发的进展而不断向前进行。
4. 在V模型和W模型中都存在一定的局限性，他们都把软件的开发过程视为需求、设计、编码等一系列串行的活动，但实际上，这些串行活动之间存在着相互牵制的关系，并且在大部分时间内，他们是可以交叉进行的。
• H模型

 

 

 

 

1. ⭐H模型是将测试活动完全独立出来，形成一个完全独立的流程
2. H模型图仅仅演示了在整个生存周期中某个层次上的一次“测试循环”。途中的其他流程可以是任意开发流程，如涉及流程和编码流程。也可以是其他非开发流程，如SQA流程，甚至是测试流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了
3. H模型揭示了一个原理：软件测试模型是一个独立的流程，贯穿于整个软件产品的周期，与其他流程并发地进行。
• X模型

 

 

 

 

1. 对V模型的最主要批评是V模型无法引导项目的全部过程。X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合称为可执行的程序
2. X模型的左边描述的是针对单独程序片段进行的相互分离的编码和测试
3. ⭐X模型还定位了探索性测试，这是不进行实现计划的特殊类型的测试
• 前置测试模型

 

 

1. 前置测试模型将测试和开发紧密结合，提供了一种轻松的方式，可以使你的项目加快速度
2. 前置测试模型将开发和测试的生命周期结合在一起，标识了项目生命周期从开始到结束之间的关键行为
3. 前置测试将测试执行和开发结合在一起，并在开发阶段以“编码-测试-编码-测试”的方式来体现。当程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。
4. 与V模型不同的是，前置测试模型认识到验收测试中所包含的3各要素：基于测试的需求、验收的标准和验收测试计划，其中基于测试的需求和验收测试标准都与业务需求定义相联系，但是，验收测试计划则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成
5. 前置测试模型用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的重要意义。在整个开发过程中，反复使用了各种测试技术以使开发人员、经理和用户节省其时间，简化其工作。

  23.1.2软件测试类型

1. 按照开发阶段划分

1. 单元测试⭐
1. 又称模块测试，是针对软件设计的最小单元（即程序模块）进行正确性检验的工作
2. 单元测试的原则
1. 应该尽早进行软件单元测试
2. 应该保证单元测试的可重复性
3. 尽可能采用测试自动化的手段来支持单元测试活动
2. 集成测试⭐ 集成测试又称组装测试、联合测试、子系统测试或者部件测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试活动
3. 系统测试⭐ 是对已经集成好的软件系统进行彻底的测试，已验证软件系统的正确性和性能等是否满足其规约所制定的要求。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些技术软件及其接口等。系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，验证完整性的软件配置项能否和系统正确连接，发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方
4. 验收测试⭐
1. 验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，也成为交付测试、发布测试或确认测试
2. 通常会有四种结果
1. 测试项目通过
2. 测试项目没有通过，并且不存在变通方法，需要作很大的修改
3. 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进
4. 测试项目无法平湖或者无法给出完整的评估。此时必须给出原因，如果是因为该测试项目没有说清楚，应该修改测计划
3. 其他称呼
1. 发布测试或验证测试 当测试的执行者是测试内部人员，且待测试系统为公司内部产品时。
2. 验收测试或交付测试 当测试的执行者时客户或用户，且待测试系统为交付客户的项目时
• 按照测试实施组织划分

 

 

1. 开发方测试 Alpha测试⭐

开发方测试通常也叫“验证测试”或α测试。Alpha测试是由一个用户在开发环境下进行的测试，不能由程序员或测试员（有的地方又说可以让测试人员进行）完成。测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。

2. 用户测试
1. Beta测试⭐
1. 用户测试时在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况下用户测试不是指用户的“验收测试”，而是指用户的使用性测试，Beta测试（即β测试）通过被看成时一种“用户测试”。Beta测试由软件的最终用户们在一个或多个客户场所进行
2. 与Alpha测试不同的是开发者通常不再Beta测试现场，Beta测试是在开发者无法控制的环境下进行的软件现场应用
2. 三个阶段
1. α是第一阶段 一般只供内部测试使用
2. β是第二阶段 已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群体来测试使用
3. γ是第三阶段 此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行
3. 第三方测试
1. 第三方测试也称为独立测试，是介于软件开发方和用户方之间的测试组织的测试
2. 一般情况下是再模拟用户真实应用环境下，进行软件确认测试。第三方测试有别于开发人员或用户进行测试，其目的是为了保证测试工作的客观性
3. 从国外的经验来看，测试逐渐由专业的第三方承担，同时第三方测试还可适当兼顾初级监理的功能，第三方测试以合同的形式制约了测试方，使得它与开发方存在某种“对立”的关系，所以它不会可以维护开发方的利益，保证了测试工作再一开始就具有客观性，
• 按照测试技术划分

 

 

1. 黑盒测试⭐
1. ⭐黑盒测试也称功能测试，它是通过测试来检验每个功能是否能正常使用，黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试
2. 黑盒测试是以用户的角度是以用户角度，从输入数据与输出数据的对应关系出发进行测试的
3. 从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。
4. ⭐具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法、正交验证设计法、功能图法、场景分析
2. 白盒测试⭐
1. 白盒测试又称结构测试其目的是通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆盖的测试，可以覆盖全部代码、分支、路径和条件。
2. 白盒测试和黑盒测试的联系
1. 用白盒测试验证单元的基本功能；用黑盒测试的思考方法设计测试用例
2. 黑盒测试中使用白盒测试的手段，常称为“灰盒测试”
3. 白盒测试需要对程序的内部实现十分熟悉，黑盒测试是完全基于对系统需求的了解
4. 仅仅使用白盒测试，或者仅仅使用黑盒测试都不能系统地全面测试一个软件
3. 灰盒测试
1. 灰盒测试是介于白盒测试和黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试详细、完整，只是通过一些表征的现象、事件、标志来判断内部的运行状态
2. 灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计测试用例，执行程序并采集程序路径执行信息和外部用户接口的测试技术
3. 缺点
1. 投入的时间比黑盒测试大概多20~40%的时间
2. 对测试人员的要求比黑盒测试高；灰盒测试要求测试人员清楚系统内部由哪些模块构成，模块之间如何协作
3. 不如白盒测试深入
4. 不适用于简单的系统。所谓的简单系统，就是简单到总共只有一个模块。由于灰黑测试关注于系统内部模块之间的交互，如果某个系统简单到只有一个模块，那就没必要进行灰盒测试了
• 按照测试执行方式划分

 

 

1. 静态测试⭐
1. 静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码、用户手册等进行非运行的检查。
2. 静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行
2. 动态测试⭐
1. 动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现
2. 动态方法指通过运行被测试程序，检查运行结果与预期见过的差异，并分析运行效率结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：编写测试用例，执行程序，分析程序的输出结果
3. 静态测试与动态测试的区别
1. 静态测试是用于预防的，动态测试是用于校正的
2. 多次的静态测试比动态测试要效率高
3. 静态测试综合测试程序代码
4. 再相当短的时间里，静态测试的覆盖率达到100%，而动态测试经常是只能达到50%左右
5. 动态测试比静态测试更花时间
6. 静态测试比动态测试更能发现bug
7. 静态测试的执行可以再程序编码编译前，动态测试只能在编译后才能执行
• 按照测试对象类型划分

 

 

1. 功能测试 对软件功能进行的测试，主要检查软件功能是否实现了软件功能说明书（软件需求）上的功能要求
2. 界面测试 对软件的用户界面进行的测试，主要检查用户界面的美观度，统一性，易用性等方面的内容
3. 流程测试 按操作流程进行的测试，主要由业务流程、数据流程、逻辑流程，其目的是检查软件在按流程操作时是否能够正确处理
4. 接口测试
1. 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各子系统之间的交互点
2. 测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
5. 安装测试 安装测试包括测试安装代码以及安装手册，安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
6. 文档测试

 

 

7. 源代码测试 通过本类型的测试发现应用程序、源代码包括OWASP十大Web漏洞在内的安全漏洞，识别、定位存在的安全漏洞，并分析漏洞风险，提出整改建议，提高风险的安全性。
8. 数据库测试 数据库测试的主要因素有：数据完整性、数据有效性和数据操作和更新
9. 网络测试 网络测试主要是验证以下几方面：链路连接情况、错包率、连通性、网络质量、路由策略、备份路由、网关等。
10. 压力测试
1. 负载测试
1. 负载测试，又叫强度测试，是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试
2. ⭐负载测试的目标是确定并确保系统在超过最大预期工作量的情况下仍能正常工作
3. 此外，负载测试还要评估性能特征，例如，响应时间、事物处理速率和其他与时间相关的方面
2. 压力测试
1. ⭐对系统逐渐增加压力的测试，来获得系统能够提供的最大的服务级别的测试或者不能接收用户请求的性能点
2. 通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会变
3. 包括
1. 并发测试 主要指当测试多用户并发访问同一应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用等问题，几乎所有的性能测试都会涉及并发测试，并发测试目的不是为了获得性能指标，而是为了发现并发引起的问题
2. 大数据量测试 大数据量测试包括独立的数据量测试和综合数据量测试两类。独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行的大数量测试。
3. 稳定性测试
1. ⭐也叫疲劳强度测试。通常是采用系统稳定运行情况下的并发用户数，或者日常运行用户数，持续运行较长一段时间，保证达到系统疲劳轻度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量轻度性能的过程。
2. 稳定性测试时概率性的测试，也就是说即使稳定性测试通过，也不能保证系统实际运行的时候不会出问题。所以要尽可能提高测试的可靠性。可以通过多久测试，延长测试时间，增大测试压力来提高测试的可靠性。
• 按照质量属性划分
1. 容错性测试 容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
2. 兼容性测试 兼容性测试时指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行和测试。
3. 安全性测试 安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检测已验证产品符合安全需求定义和产品质量标准的过程。
4. 可靠性测试 软件可靠性测试是指在预期的使用环境中，为检测出软件缺陷，验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件测试。
5. 维护性测试 是评估（测试）涉及方案或者产品的可用性水平
6. 可移植性测试
1. 可维护性是衡量对已经完成的软件进行调整需要多大的努力
2. 可移植性指未经修改或修改部分源代码后，应用程序或系统从一种环境移植到另一种环境中还能正常工作的难易程度。
3. 根据可移植性测试类型与指标体系结构的对应关系，可移植性测试类型包括代码变更测试、安装测试、用户界面测试和功能测试
7. 易用性测试 易用性测试主要考察评定软件的易学易用性、各个功能是否易于完成、软件界面是否友好等导航帮助要准备
• 按照测试地域划分
1. 本地化测试 本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量
2. 国际化测试 软件国际化的测试就是验证软件产品是否支持一些特征，包括多字节字符集的支持，区域设置、时区设置、界面定制化、内嵌字符串编码和字符串扩展等。设计评审和代码评审国家化测试中最有效的方法。

  23.2软件测试技术 软件测试技术主要包括白盒测试和黑盒测试技术，然而随着近些年测试技术的不断应用及实践，功能自动化测试技术、接口测试技术、性能测试技术以及探索式测试技术都被人们越来越重视。 23.2.1黑盒测试法⭐

1. ⭐黑盒测试主要检查程序外部结构，不考虑内部逻辑结构
2. 黑盒测试的优点
1. 比较简单，不需要了解程序内部的代码及实现
2. 与软件的内部实现无关
3. 从用户角度出发，能很容易地指导用户会用到哪些功能，会遇到哪些问题
4. 基于软件开发文档，所以也能指导软件实现了文档中的哪些功能
5. 在做软件自动化测试时较为方便
3. 黑盒测试的缺点
1. 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%
2. 自动化测试的复用性较低
4. 测试用例设计方法
1. 测试区域确定法
1. ⭐等价类划分法
1. 等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例
2. 每一类的代表性数据在测试中的作用等价于这一类中的其他值
2. 边界值分析法
1. 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
2. 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误。
3. 两者的区别
1. 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件
2. 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况
2. 组合覆盖法
3. 逻辑推断法
4. 业务路径覆盖法

23.2.2白盒测试法⭐ 白盒测试又称为结构测试或逻辑驱动测试 白盒测试原则

1. 保证一个模块中的所有独立路径都至少被测试一次
2. 所有逻辑值均需测试真和假两种情况
3. 检查程序的内部数据结构，保证其结构的有效性
4. 在上下边界及可操作范围内运行所有循环

白盒测试分类

1. 静态白盒测试
1. 静态白盒测试是在不执行的条件下，有条理地仔细审查软件设计、体系结构和代码从而找出软件缺陷的过程
2. 优点
1. 尽早发现软件缺陷
2. 为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路
2. 动态白盒测试 动态白盒测试又称结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试

  23.3信息系统测试管理 23.3.1测试管理概述

1. 测试管理是为了实现测试工作预期目标，已测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动。
2. 测试管理的主要因素包括测试策略的制定、测试项目进度跟进、项目风险的评估、测试文档的评审、测试内部和外部的协调沟通、测试人员的培养等

23.3.2测试管理内容

1. 测试部门管理（管人）
1. 部门日常事物
2. 部门人员
3. 部门下属项目
4. 部门资产等
2. 测试项目管理（管事）
1. 测试人员管理
2. 测试计划
3. 测试策略的编写
4. 测试评审的组织
5. 测试过程的跟进
6. 测试内部和外部的沟通协调
7. 缺陷跟踪

23.3.3测试监控管理

1. 测试监控的目的是为测试活动提供反馈信息和可视性
2. 测试监控的内容⭐
1. 测试用例执行的进度
2. 缺陷存活时间
3. 缺陷的趋势分析
4. 缺陷分布密度
5. 缺陷修改质量

23.3.4配置管理 测试过程中的配置管理不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本。 23.3.5测试风险管理⭐

1. 需求风险⭐
1. 对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方法
2. 另外需求的变更导致的测试用例变更，同步时存在误差
2. 测试用例风险⭐
1. 测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求
2. 测试用例没有得到全部执行，有些用例被有意或无意的遗漏
3. 缺陷风险 某些缺陷偶发，难以复现，容易被遗漏
4. 代码质量风险 软件代码质量差，导致缺陷较多，容易出现测试的遗漏
5. 测试环境风险⭐ 有一些情况下测试环境和生产环境不能完全一致，导致测试结果存在误差
6. 测试技术风险 某些项目存在技术难度，测试能力和水平导致测试进度缓慢，项目延期
7. 回归测试风险⭐ 回归测试一般不运行全部测试用例，可能存在测试不完全
8. 沟通协调风险 测试过程中涉及的角色较多，存在不同人员，角色之间的沟通，协作，难免存在误解、沟通不畅的情况，导致项目延期
9. 其他不可预计风险 一些突发情况下，不可抗力等也构成风险因素，且难以预估和避免

23.3.6测试人员绩效考核

1. 工作内容考核
1. 参与软件开发过程的工作内容考核
2. 参与测试文档的准备工作
3. 执行测试的工作
4. 测试结果缺陷残留
5. 测试人员的沟通能力考核
2. 工作效率与工作质量考核
1. 测试设计中效率相关指标
1. 文档产出率
2. 用例产出率
2. 测试设计中工作质量相关的指标
1. 需求覆盖率
2. 文档质量
3. 文档有效率
4. 用例有效率
5. 评审问题数
3. 测试执行中工作效率相关指标⭐
1. 执行效率
2. 进度偏移度
3. 缺陷发现率
4. 测试执行中工作质量的相关指标
1. 缺陷数
2. 有效缺陷数/率
3. 严重缺陷率
4. 模块缺陷率
5. 遗漏缺陷率
6. Bug发现的时间点，Bug缺陷的收敛率
7. 缺陷定位和可读性
3. 对自动化测试人员效率的度量
1. 自动化测试的引入和实例是否合理，不是每个项目都合适做自动化的，自动化不能保证效率提高，用5小时开发的自动脚本替换3个小时的手动测试并不合算，自动化测试需要评审，按照项目的大小不同，必要的情况下引入自动化测试
2. 自动化测试，特别是性能测试结束之后，我们要分析部分测试结果，测试结果的分析水平，也可以作为衡量测试效率的一个指标
4. 对测试项目负责人效率的度量
1. 测试是否提高的介入项目
2. 开发提交测试的时候，标准是否合理，把关是否严格。如果开发的质量不行，坚决要退回，不然会影响测试的效率和进度
3. 测试计划阶段，评价测试计划的合理性
4. 项目结束后，评价项目进行阶段中负责人的跟进情况，特殊情况处理，风险触发之后的处理，资源协调，信息的收集，共享，沟通，配合
5. 测试管理的度量
1. 计划质量
2. 成本质量

  补充

1. 确认测试 主要用于检测软件的功能、性能和其他特性是否与用户需求一致
2. 黑盒测试又叫功能测试

标签：黑盒,白盒,综合测试,模型,软考,高项,测试,软件,测试用例
From： https://www.cnblogs.com/pangzili/p/16704196.html