[开发测试]西工大软件测试2021复习提纲

蓝色的是考点

书上找不到的

SDL

软件安全开发周期，微软提出，从安全角度指导软件开发过程的管理模式

模糊测试

向目标系统提供非预期输入并监视结果来发现系统的漏洞

渗透测试

模拟恶意黑客攻击，评估软件网络安全

正确性测试

正确性测试就是检查软件的功能是否符合规格说明的测试

第一章 软件测试基础

1.1 软件测试基本概念

软件测试定义[软件测试]

测试是评错:在特定的条件下运行系统或构件，观察或记录结果，做出评价

测试是做度量:分析某个软件项现存的和要求的条件之差别（即错误）并评价此软件项的特性

软件测试的特征

• 可以从需求开始，而不仅仅是代码（广义测试/静态测试）

• 即是静态活动也是动态活动

  • 静态活动

    • 代码静态检查

    • 帮助信息

    • 不执行程序所做的一些评审文档的操作

  • 动态活动

    • 设计测试用例执行的结果与预期结果的差别

• 用来预防失效

  • 尽早发现软件的一些错误，使它尽可能少的产生错误，产生一些不可避免的结果

• 有助于在软件生命周期中尽早发现问题，以降低修复缺陷所需的成本

• 过程中应创建可重用的测试件

  • 某些测试用例会反复执行，很多软件有很多版本，他们的测试项是完全相似的，所以设计测试用例要考虑可重用

软件测试目的

Glenford J.Myers观点

• 测试是程序执行的过程，目的在于发现错误。

• 测试是为了证明程序有错，而不是证明程序无错。

• 一个好的测试用例在于能够发现至今未发现的错误。

• 一个成功的测试是发现了至今未发现的错误的测试。

Bill Hetzelt观点

• 软件测试的目的不仅仅是为了发现软件缺陷与错误，同时也对软件进行度量和评估，提高软件质量。

软件测试目的总结

• 以最少的人力、物力、时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避潜在的软件错误和缺陷给软件造成的商业风险。

• 通过分析测试过程中发现的问题可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进；同时通过对测试结果的分析整理，可修正软件开发规则，并为软件可靠性分析提供相关依据。

• 评价程序或系统的属性，对软件质量进行度量和评估，以验证软件的质量满足用户的需求，为用户选择、接收软件提供有力的依据。

软件测试的关键问题（原则）

• 软件测试是为了证伪而非证真

• 要尽早开始并持续进行软件测试

• 重视无效和非预期使用习惯的测试

• 避免检查自己的程序（应使用第三方测试）

• 注意测试中的错误群集现象（二八原则，发现某个程序段的错误，接下来的部分还可能有连续错误）

• 要定期评审测试用例

• 全面检查每个测试结果（强检测和弱检测）

• 保护测试现场，归档资料（可以再现这个错误，环境、路径等等）

• 要注意软件测试的经济性原则（穷尽测试花的代价可能比开发还要大得多）

• 完全测试是不可能的

• 测试一定是有风险的（没有测试所有情况，就是有风险的）

• 测试不可能找出所有隐藏的软件故障

• 测试进行的越多，程序免疫能力越强（杀虫剂抗性现象）

• 并非所有故障都能修复

• 不要丢弃测试用例

软件测试与软件质量保证

• 软件质量保证是贯穿软件项目整个生命周期的有计划和有系统的活动，经常针对整个项目质量计划执行情况进行评估，检查和改进，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。

• 确保软件项目的过程遵循了对应的标准及规范要求且产生了合适的文档和精确反映项目情况的报告,其目的是通过评价项目质量建立项目达到质量要求的信心。软件质量保证活动主要包括评审项目过程、审计软件产品，就软件项目是否真正遵循已经制定的计划、标准和规程等，给管理者提供可视性项目和产品可视化的管理报告。

软件测试是获取度量值的一种重要手段

?

1.2 软件测试的分类

黑盒测试、白盒测试以及二者关系

• 黑盒：

  • 从软件外部对软件实施的测试，也称为功能测试或基于规格说明的测试

  • 通过使用整个软件或某种软件功能严格测试，不检查程序源代码，不了解源代码程序的设计。

  • 只通过输入和输出了解软件的工作。

  • 测试软件的整体功能和性能

• 白盒：

  • 又称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试

  • 通过源代码进行测试而不是用户界面。

  • 寻找内部代码在算法、溢出、路径、条件等地方的缺陷并加以修正。

• 二者关系/比较：

  • 黑盒侧重功能，与白盒互补，容易发现白盒不易被发现的类型测试。

  • 在已知产品的因素方面：

    • 黑盒：已知程序的功能需求、设计规格，可以通过测试验证程序需要的功能是否已被实现，是否复合要求。

    • 白盒：已知程序的内部工作结构，可以通过测试验证程序的内部结构是否符合要求，是否含有缺陷。

  • 在检查测试的主要内容方面：

    • 黑盒检查：

      • 功能是否都满足需求；是否有功能出现缺陷

      • 接口上是否能正确接受输入；输出结果是否正确

      • 是否有数据结构信息或者外部信息访问错误

      • 是否有初始化或终止性错误

    • 白盒检查：

      • 所有程序模块的独立路径都需要至少被测试一遍

      • 所有的逻辑判定的真值与假值都需要被至少测试一遍

      • 在运行的边界内和循环的边界上执行循环体

      • 测试内部数据结构是否有效

  • 在静态测试方法方面：

    • 静态黑盒：产品需求文档、用户手册、帮助文件等

    • 静态白盒：走查、复审、评审程序源代码、数据字典、系统设计文档、环境设置、软件配置项等

  • 在动态测试方法方面：

    • 动态黑盒：通过数据输入并运行程序来检验输出结果，如功能测试、验收测试和一些性能测试（或安全性、兼容性）等

    • 动态白盒：通过驱动程序来调用，如进行单元测试、集成测试、部分性能测试（或恢复性、可靠性）等

  • 其它关系：

    • 黑盒测试与白盒测试是设计测试用例的两种基本方法

    • 在集成测试阶段采用黑盒测试与白盒测试相结合的方法

    • 应用系统负载压力测试一般采用黑盒测试方法

    • 白盒测试是在已知产品的内部工作过程的情况下对产品进行测试，黑盒测试则不考虑产品的内部工作过程

    • 白盒测试主要测试每种内部操作是否符合设计要求，黑盒测试则测试每个功能是否符合需求;白盒测试主要由开发人员实施

白盒测试常用工具，各适用于什么情况?

• 静态测试工具：对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码质量，生成系统的调用关系图等。

  • CodeWizard：C++，静态代码分析

• 动态测试工具：一般采用"插桩"的方式向代码生成的可执行文件中插入一些检测代码，用来统计程序运行时的数据。

  • JTest：Java单元测试

  • JContract：系统级验证类部件是否被正常使用，对Jtest的延伸

  • C++ Test： 不用编写用例，自动测试，帮开发者预防错误。是单元测试工具，还可以用来黑盒测试

  • Insure++：C++，检测内存错误、内存泄露，以及覆盖性分析

  • Robot、QTP等

其它测试工具

• LoadRunner——性能测试测试工具

• Bugzilla——缺陷管理测试工具

• Junit——单元测试测试工具

插桩程序设计

一般采用"插桩"的方式向代码生成的可执行文件中插入一些检测代码，用来统计程序运行时的数据。

不破坏原来的逻辑完整性，在相对应位置上插入探针，输出程序运行特征数据，并进行分析。

如果我们想要了解一个程序在某次运行中可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法就是利用插桩技术，它在软件测试技术上占有非常高的地位。最简单的插桩：在程序中插入打印语句printf(“ ...”)语句。

插桩策略：

1. 语句覆盖探针（基本块探针）：在基本块的入口和出口处，分别植入相应的探针，以确定程序执行时该基本块是否被覆盖。　

2. 分支覆盖探针：c/c++语言中，分支由分支点确定。对于每个分支，在其开始处植入一个相应的探针，以确定程序执行时该分支是否被覆盖。

3. 条件覆盖探针：c/c++语言中，if, swich,while, do-while, for 几种语法结构都支持条件判定，在每个条件表达式的布尔表达式处植入探针，进行变量跟踪取值，以确定其被覆盖情况。

静态测试、动态测试

静态测试：指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。

• 代码测试：主要测试代码是否符合相应的标准和规范。

• 界面测试：主要测试软件的与需求中的说明是否相符。

• 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求。

• 程序分析

• 工具，（Logiscope)Telelogic，可用作Java/C++等规范。

动态测试：指实际运行被测程序，按照预先顺序输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。

• 动态测试是结构和正确性测试。

• 动态测试工具Robot、QTP等。

单元测试、集成测试、系统测试、验收测试

1. 单元测试：

• 又称为模块测试，针对软件设计中的最小单位——程序模块,进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

• 单元定义：C中指一个函数，Java中指一个类，在图形化软件中，单元指1个窗口，1个菜单。

• 单元测试原则

  尽早进行、保证可重复性、采用自动化手段

• 单元测试的重要性和目的

  重要性：大大减少调试的时间，提高效率，提高质量，减少bug，快速定位bug，可以放心地修改、重构

  目的：尽早发现错误，检查代码规范

• 单元测试的六个问题(主要问题)：

  • 什么时候进行单元测试？

    • 编码后，编译通过后进行。

  • 由谁来做单元测试？

    • 白盒测试工程师或者开发工程师，最好不要自己做自己代码的测试。

  • 单元测试的依据是什么？

    • 源程序（代码+注释）+《详细设计文档》

  • 单元测试的通过标准是什么？

    • 程序通过所有单元测试用例

    • 语句的覆盖率达到100%

    • 分支的覆盖率达到85%

  • 如何进行单元测试？

    • 单元测试主要用白盒测试，先静态地检查代码是否符合规范，然后动态运行代码，检查其实际运行结果，检查程序的运行结果是否正确是一个最基本的要求，还要关注容错处理，程序的边界值处理等。

  • 国内单元测试的现状不容乐观

    • 简单+没有单元测试计划、单元测试用例和代码覆盖率统计

  • 检查代码是否符合规范

  • 动态运行代码，检查其实际运行结果，检查程序的运行结果是否正确是一个最基本的要求

  • 还要关注容错处理，程序的边界值处理等。

  • 接口功能、局部数据结构（不常用）、边界条件、独立执行通路、错误处理通路

2. 集成测试：

• 又称为组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

• 集成测试内容：

  • 将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失。

  • 判断各个子功能组合起来是否能够达到预期要求的父功能。

  • 检查一个模块的功能是否对其他模块的功能产生不良影响。

  • 检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改。

  • 单个模块的误差累计起来，是否会放大到不可接受的程度。

• 集成测试方法：

  • 自顶向下：由上而下的集成测试方法要求首先测试和集成最高级别的模块。

  • 自底向上：由下而上的方法要求首先测试和集成最低级别的单元。

  • 第三种方法（有时也称为伞形方法）要求测试沿功能性数据和控制流路径进行。

    主要采用黑盒测试方法来设计测试用例，一些关键软件可能还利用白盒测试来补充测试用例

• 什么时候进行集成测试？

  • 单元测试&集成测试同步进行，理论上先有单元测试。

• 由谁来做集成测试？

  • 白盒测试工程师或者开发工程师

• 集成测试的依据

  • 单元测试的模块+《概要设计》文档

3. 系统测试：

• 指将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。

  目前系统测试主要由黑盒测试工程师在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。

• 与用户测试的区别：

  • 系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。

  • 用户测试是以用户为中心设计流程中的一种设计验证方法。通过观察和询问用户（被测试者），记录产品的真实使用情况，界定出可用性问题。

• 主要内容：

  • 功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。

  • 健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

• 常见系统测试方法

  • 黑盒测试。系统测试多采用黑盒测试，主要包括多任务测试、临界测试、中断测试、等价划分测试等。

  • 白盒测试。白盒测试主要有逻辑驱动、基路测试等。

4. 验收测试：

• 验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。验收签字,收钱。

  • α测试：指由用户，测试人员、开发人员等共同参与的内部测试。用户在测试、开发人员指导下，在开发环境下进行测试。

  • α测试目的：评价软件产品的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重产品的界面和特色。

  • α测试时间：程序编写结束之时开始，或在模块（子系统）测试完成之后开始，也可以在产品达到一定的稳定性和可靠程度之后再开始。

  • α测试即为非正式验收测试。

  • β测试：指内测后的公测，即完全交给最终用户测试。用户在实际使用场景下进行测试。开发者不在现场。由用户记录下所有问题。

  • β测试目的：衡量软件产品的FLURPS，注重产品支持性，包括文档，客户培训和支持产品生产能力。

  • 正式验收测试

功能测试，性能测试，安装测试，兼容性测试、负载测试、压力测试

1.功能测试

• 是黑盒测试的一方面，检查实际软件的功能是否符合用户的需求。

  • 逻辑功能测试

  • 界面测试

  • 易用性测试

  • 安装测试

  • 兼容性测试

    软件之间能否正确交互以及共享信息

    软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何

2.性能测试

软件是否达到需求规格说明中规定的各类性能指标，并满足相关的约束和限制条件

用自动化工具，模拟多种负载条件对系统性能指标进行测试

• 软件测试的高端领域

  • 时间性能（事务响应时间等）

  • 空间性能（系统资源消耗）

  • 一般性能测试

  • 可靠性测试

  • 负载测试

    不限制软件运行资源，测试软件吞吐量上限来发现设计上的错误和系统的承载能力。

    负载测试是模拟在超负荷环境中运行，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。

  • 压力测试

    不断施加压力，确定系统瓶颈，获得系统能提供最大的服务级别

    模拟实际软硬件环境和用户系统负荷，长时间或高负荷运行软件

    • 与容量测试的区别

      • 压力测试（强度测试）：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

      • 容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

      • 负载测试、容量测试、压力测试、强度测试都属于性能测试，性能测试是指在给定条件基准的前提下能达到的运行程度，测试软件在系统中的运行性能，度量系统与预定义目标的差距。

回归测试、冒烟测试、随机测试

1. 回归测试

• 指软件被修改后重新进行的测试，执行旧测试用例，保证对软件所作的修改没有引入新的错误。

2. 冒烟测试

• 是指在对一个新版本进行系统大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。

• 将代码更改嵌入产品的源树中之前对这些更改进行验证的过程。确定和修复缺陷最经济的方法。用于确认代码中的更改会按预期执行，且不会破坏整体稳定性。

3. 随机测试

• 测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

恢复测试

对导致恢复和重构的情况进行测试，验证软件自身运行、软件控制、系统控制的恢复与重构

强度测试

在软件设计能力的极限下，以及超过此状态运行，检测对异常的抵抗能力

确认测试

对象：通过组合测试的软件

目的：表面软件可工作，符合软件需求说明书中的规定的全部功能和性能要求

安全测试

产品开发基本完成时，对产品进行检验以验证安全需求定义和产品质量标准的过程

1.3 软件缺陷管理

软件缺陷的概念

软件或者程序中存在的某些破坏正常运行能力的问题、错误或隐藏的功能缺陷。

从内部来看：开发和维护过程中的错误、毛病。

从外部来看：系统某项功能的失效或者违背。

软件缺陷的几种情况

1. 软件未达到产品说明书中标明的功能。

2. 软件出现了产品说明书中指明的不会出现的功能。

3. 软件功能超出了产品说明书中指明的范围。

4. 软件未达到产品说明书中指明应达到的目标。

5. 软件测试人员认为软件难以理解和使用、运行速度慢，或最终用户认为不好。

目标

确保每个被发现的缺陷都能够被有效的解决。

（注意：这里的解决不一定是被修复，也可以是其它处理方式，如在下一版本修正或不修正，但是每个bug的处理方式必须能在开发组织中达成一致。 ）

软件缺陷属性

软件缺陷单

软件缺陷状态

软件缺陷生命周期

?

测试人员识别缺陷，初始状态是“新建”；

项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”；

指定的工程师解决缺陷，将其状态跟踪到“已解决”；

测试人员回归该缺陷，如果回归通过，则关闭缺陷，如果回归不通过，则重新打开该缺陷("Reopen"状态)。

缺陷管理常见问题

• 测试提交的缺陷开发不认可怎么办？

• 软件缺陷无法重现怎么办？

• 缺陷太多怎么办？

• 如何减少无效缺陷的提交？

• 如何防止重复缺陷重复提交？

• 测试和开发如何客观有效的进行缺陷沟通？

1.4 软件质量及软件测试相关特性

软件质量保证

建立一套有计划、有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能正确的被项目采用

目的：软件过程对于管理人员可见

常用到的软件质量模型

常见模型McCall 、Boehm 、FURPS 、Dromey 、 ISO/IEC 9126 -1991

?

功能 在指定条件下，满足明确和隐含功能

可靠 在指定条件下，维持规定性能级别

可使用 在指定条件下，软件被理解、学习、使用和吸引用户的能力

效率 在指定条件下，相对于所用的资源数量，软件提供适当性能的能力，空间效率和时间效率

可维护 软件可被修改能力

可移植性 软件从一个环境迁移到另一个环境的能力

软件质量特性

静态质量特性

包括结构化的、可维护的、可测试的代码以及正确而又完整的文档。

【代码风格、可维护性、可测试性、结构化是否合理】

【需求文档、设计文档、测试文档、用户帮助手册、说明书等等】

动态质量特性

包括正确性、可靠性、完整性、一致性、易用性、性能等。

• 正确性：如果软件针对其输入域中的每个元素都能得到预期的结果，则称该软件是正确的。

• 可靠性：

  • 定义一：软件在给定时间间隔和给定条件下无故障运行的概率。【这里的概率依赖于程序输入的分布情况，这种输入分布经常被称作操作剖面，是对软件使用方式的数值描述。】

  • 定义二：软件在预期环境下无故障运行的概率。【这里环境是指软件运行所需的硬件及软件要素，包括硬件设备、操作系统以及其它必需的应用程序。这个定义只与软件功能正确性相关，没有操作剖面的定义，整个输入域被认为是均匀分布的。】

• 一致性：指软件对常规惯例和假设的遵循程度。例如，用户界面中所有按钮遵从统一的颜色编码规定。

• 性能：可以简单理解为软件完成规定任务所花费的时间。例如，一个编译系统的性能需求可能会用编译一组数值计算程序所需的最少平均时间来描述。

软件测试特性

复杂性

• 黑盒测试复杂性

  • 测试所需要的输入量太大

  • 测试的输出结果太多

  • 软件实现的途径太多

  • 软件规格说明没有一个客观标准

• 白盒测试复杂性

  • 穷举路径测试不能保证程序实现符合规格说明的要求

  • 穷举路径测试不能查出程序中因遗漏路径而出现的错误

  • 穷举路径测试可能发现不了有关数据的故障

经济性

E.W.Dijkstra——“软件测试只能证明故障的存在，但不能证明故障不存在”。

经济性原则：

• 根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；

• 认真研究测试策略，以便开发出尽可能少的测试用例，发现尽可能多的软件故障。

1.5 软件测试充分性及测试停止标准

软件测试充分性

“充分性”就是用来度量一个给定的测试集T是否能验证软件P满足其需求R。充分性度量是相对于具体的测试充分性准则C的。

当一个测试集T满足准则C时，即认为T相对于C是充分的。

相反，如果T不能完全满足C，那么就认为用例集T对于C是不充分的。

因此，确定程序P的测试集T是否满足充分性准则C，是依赖于准则自身的。

测试充分性度量

• 覆盖域

  • 测试集的充分性评估是由一个有限集来度量，根据所依赖的充分性准则，有限集中的元素由软件需求或代码导出。对于每一个测试准则C，我们都可以得到一个有限集，称之为覆盖域Ce。

  • 如果覆盖域Ce仅依赖于被测试软件的代码，则称准则C为一个白盒测试充分性准则；如语句覆盖、分支覆盖、路径覆盖、角色覆盖等。

  • 如果覆盖域Ce仅依赖于被测试软件的需求，则称准则C是一个黑盒测试充分性准则。

  • 其他的测试充分性准则都是二者的混合。

• 测试覆盖率

  • 给定测试集T，覆盖标准C，覆盖域Ce，假设Ce包含n个元素，我们说T覆盖Ce，是指对于Ce中的每一元素e，在T中都至少有一个测试用例测试了它。如果T覆盖了Ce中所有的元素，则称T相对于C是充分的；如果T只覆盖了Ce中的k个元素，则称T相对于C是不充分的。分数k/n代表了T对C的充分度，也称为T对于C，P以及R的覆盖率。

• 测试充分性准则C2

  • 如果软件P中的每一条路径都被遍历至少一次，则认为测试集T针对(P，R)是充分的。

• 除了基于被测软件需求、控制流、数据流这样一些常规测试充分性评价准则之外，还有其它一些测试充分性评价技术，如符号执行、变异测试。

软件测试终止准则

软件消亡之前，如果没有测试结束标准，那么软件测试就永无休止。软件测试终止条件需要依据项目具体情况来指定，一般而言，其遵循以下终止准则：

1. 基于测试阶段的原则

   每个软件都经过单元测试、集成测试、系统测试这几个测试阶段，我们可以对单元测试、集成测试、系统测试制定各自具体的测试结束标准，当每个阶段的测试结束标准都符合时，我们认为该软件达到测试停止标准。

2. 基于测试用例的原则

   测试设计人员设计测试用例，并请项目组成成员参与用例评审，一旦评审通过，就可以作为后面测试结束的一个参考标准。比如测试过程中如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。再比如可以制定功能测试用例通过率100%，非功能性测试用例通过率达到95%以上，即可允许正常测试结束。该准则的关键在于测试用例质量的把握。

3. 基于缺陷收敛趋势及缺陷修复率原则

   可以通过软件缺陷测试的趋势图的走向，确定测试是否可以结束；缺陷修复率也是常用的一个指标，如严重级别错误和主要级别错误要100%修复，较小缺陷修复率达85%以上。

4. 基于验收测试的原则

   即项目通过验收测试，并得到验收测试通过结论，即可结束该项目的测试活动。

5. 基于覆盖率的原则

   如需求覆盖率达100%，测试用例执行覆盖率达100%，单元测试中语句覆盖率不低于85%等这些准则在软件测试活动中都是比较常用的。

6. 软件项目暂停或终止，则测试活动也应响应暂停或终止

   如在开发生命周期内出现重大估算、进度偏差，需要暂停调整或终止项目，那么测试活动也随之暂停或终止，并备份相应测试数据。

第二章 软件测试策略

2.1 软件开发过程及模型

软件开发过程

是软件开发与维护的工作流程和工艺流程，是软件工程的重要组成部分。

软件开发模型

2.3软件测试与软件开发的关系

软件测试与软件开发各阶段的关系[软件测试与软件开发过程的关系]

?

1. 项目规划阶段：负责控制整个测试

2. 需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么。同时制定测试计划。

3. 概要设计和详细设计阶段：制定集成测试计划和单元测试计划

4. 程序编写阶段：开发相应的测试代码和测试脚本

5. 测试阶段：实施测试，并提交相应的测试报告

第三章 黑盒测试与测试用例设计

测试用例

为某个特殊目标编制的一组测试输入、执行条件，以及预期结果,测试某个路径或核实某个功能是否满足要求。

目的：确定某个特性是否正常工作

黑盒测试用例设计[测试用例的设计]

等价类，边界值、因果图、正交

白盒测试用例设计[测试用例的设计]

逻辑覆盖、基本路径覆盖、数据流测试、变异测试

3.1 测试用例综述[测试用例的设计]

测试用例设计原则

1. 最小化

2. 替代产品文档功能

3. 单次投入成本和多次投入成本

4. 测试结果和调试最简单化

5. 正确

6. 全面

7. 整体连贯

8. 可维护

9. 可判定和可再现

测试用例设计步骤

1. 需求分析

2. 业务流程分析

3. 测试用例设计

   注意点：

   1. 确定测试套件

   2. 确定一个或多个基本流程和可选流程，即测试场景

   3. 针对每个测试场景，确定一个到多个测试用例

   4. 增加测试数据，完成测试用例

4. 用例评审

5. 用例更新完善

3.2等价类设计方法[测试用例的设计] [常见的黑盒测试用例的设计方法？并简单介绍以下各自的思想]

选择适当子集代表整个数据集。通过降低测试数目，实现合理覆盖。

等价类划分

1. 有效等价类：合理的输入数据集

2. 无效等价类：不合理的输入数据集

   （我不太能拿捏无效等价类和非法等价类的区别，我在讨论区提问了，可以搜到）

3. 弱一般等价类：单缺陷假设，不讨论异常区域（即无效等价类那一部分）

4. 强一般等价类：多缺陷假设，不讨论异常区域

5. 弱健壮等价类：单缺陷假设，要讨论异常区域

6. 强健壮等价类：多缺陷假设，要讨论异常区域，即一个全笛卡尔乘积

   单缺陷假设：假设程序错误极少是由两个及以上的错误同时发生引起的，也就是设计测试用例时，只有一个变量取极值值，其它变量取正常值

   多缺陷假设：多个变量取极值

   这里的解释和书后面的例子有矛盾，建议看书P49的后四个划分实例，做题就那样做

等价类划分方法

1. 规定了输入值范围，得到3个等价类，1个合法等价类（值域内），两个非法等价类（一个小于值域，一个大于值域）

2. 其它几种划分方法比较抽象，建议找ppt或者P50到P54例题看

3.3边界值设计方法[测试用例的设计] [常见的黑盒测试用例的设计方法？并简单介绍以下各自的思想]

对输入输出边界值进行测试。在等价类的极端情况下工作。

边界值分析法原理

1. 边界值测试原理

   在等价类的极端情况下考虑软件测试工作

2. 边界条件

   输入定义域或输出定义域的边界

3. 边界值分析法的优缺点

   优点：简单易行，成本低

   缺点：用例不充分，不能发现测试用例间的依赖关系。

边界值分析原则[测试用例生成原则]

1. 两种：合法边界，非法边界

2. 其余几种还是建议看例题，P57

健壮性分析

边界值分析法的测试运用

3.4因果图设计法[测试用例的设计] [常见的黑盒测试用例的设计方法？并简单介绍以下各自的思想]

利用图解法分析输入的各种组合情况。适用于输入条件的各种组合，考虑了输入情况的组合以及相互制约。

因果图原理

因果图法应用

决策表法

3.5正交试验设计方法[测试用例的设计] [常见的黑盒测试用例的设计方法？并简单介绍以下各自的思想]

根据正交性从全面试验中挑出部分有代表性的点进行测试。“均匀分散，齐整可比”。高效、快速、经济。

正交试验设计法原理

利用正交实验法设计测试用例

第四章 白盒测试

4.2逻辑覆盖测试

逻辑覆盖

以程序内部逻辑结构为基础，对测试完成度的测评。

语句、判定、条件、条件|判定组合、多条件、修正条件、组合、路径覆盖

1. 语句覆盖

   又称行覆盖/段覆盖/基本块覆盖，使每个可执行语句至少执行一次

   语句覆盖率=可执行的语句总数/被评价到的语句数量（什么是被评价到的语句数量？）

2. 判定覆盖

   又称分支覆盖，使每个判断语句至少获得一次“真”和一次“假”。无需细分每个判定语句，然而往往大部分的分支（判定）语句是由多个逻辑条件组合而成

   <span style="background-color:#dadada"><span style="color:#008855">int</span> <span style="color:#000000">i</span><span style="color:#981a1a">=</span><span style="color:#116644">0</span>,<span style="color:#000000">j</span><span style="color:#981a1a">=</span><span style="color:#116644">0</span>;
   <span style="color:#770088">while</span>(<span style="color:#000000">i</span><span style="color:#981a1a"><</span><span style="color:#116644">8</span><span style="color:#981a1a">&&</span><span style="color:#000000">j</span><span style="color:#981a1a"><</span><span style="color:#116644">8</span>)<span style="color:#aa5500">//由两个逻辑条件组合而成</span>
   {
    ?  ........
   }</span>

3. 条件覆盖

   使每个判断语句中每个条件的可能取值至少满足一次。不一定同时符合判定覆盖。可能是T||F与F||T，最终只是考虑了T的情况，注意和多条件覆盖区分

4. 条件/判定组合覆盖

   使每个判断语句中的每个条件的可能取值至少满足一次，并使每个判断语句的"真"和"假"至少满足一次。一定同时符合条件覆盖和判定覆盖

5. 多条件覆盖

   使每个判断语句中每个条件的可能取值的所有可能组合至少出现一次

6. 修正条件判定覆盖

7. 组合覆盖

   使每个判断语句中每个条件的可能取值的所有可能组合至少出现一次

8. 路径覆盖

   覆盖程序中的所有路径

测试覆盖准则

逻辑覆盖：

语句、判定、条件、判定|条件、条件组合、路径

循环覆盖

基本路径测试

1. ESTCA错误敏感测试用例分析

   

   1. ——这是为了检测程序语句中的错误，如应该引用某一变量而错成引用另一个常量。

   2. ——这是为了检测“差1”之类的错误，如“A>1”错写成“A>0”。

   3. ——这是为了检测逻辑符号写错的情况，如将“A<B”错写为“A>B”。

2. LCSAJ线性代码序列与跳转

?

?

?

4.5变异测试

采用变异技术来评价测试集的充分性或者增强测试集的活动，称为变异测试。

变异和变体

变异：轻微变更程序的行为。变更后的叫变体M，原版本为父体P。比如将+号变成-号。

一阶变体：仅经过一次变异

n阶变体：由n-1阶变体经过一次一阶变异得到

高阶变体：超过一阶的变体

强变异和弱变异

测试用例检测变异体的方式：

• 强变异检测

  • 给定被测程序P和其变体M，若测试用例T在P和M上运行的结果不一样，称T可以强变异检测到变异体M。

  • 外部观察模式，主要观察程序返回值，全局变量值，数据文件的变化

  • 测试用例执行满足了可达性和必要性条件，还需要额外满足充分性条件

• 弱变异检测（提高变异检测效率）

  • 被测程序P由n个子程序构成S={S1,S2,……,Sn}，使Sm变异，则P变成变异体M，若测试用例T在P和M上运行后程序状态不一致，则称T可以弱变异检测到变异体M。

  • 内部观察模式

  • 测试用例执行满足了可达性和必要性条件

• 测试用例可以强变异检测到变异体，则一定可以弱变异检测到该变异体，反之不然

用变异技术进行测试评价（变异分析）

步骤：

1. 执行程序

2. 生成变体

3. 选取下一个变体

4. 选取下一个测试用例

5. 变体的执行和分类

6. 活跃变体

7. 等价变体

8. 变异值的计算

变异算子

定义了从原有程序生成差别极小程序的转换规则

变异算子的设计

1. 语法正确性：一个变异算子必须产生语法正确的程序

2. 典型性：一个变异算子必须能模拟一个简单的共性错误

3. 最小性和有效性：变异算子的集合应该是最小且有效的集合

4. 精确定义：必须明确定义变异算子的域和范围

变异测试的基本原则

1. 熟练程序员假设

2. 耦合效应假设

第五章 软件测试的过程管理

文档测试主要测试内容[这里有冲突]

• 测试方案(主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用列表)

• 测试执行策略(可以主要包括哪些可以先测试，哪些可以放在一起测试之类的)

• 测试用例(主要根据测试用例列表，写出每一个用例的操作步骤和紧急程度，和预置结果)

• bug描述报告(主要可以包括，测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息)

• 整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)

• 软件测试过程中生成的文档，以需求规格说明书、软件设计、用户手册、安装手册为主，检查文档是否与具体实际有区别（不用写测试用例）

5.3测试计划

是描述测试目的、范围、方法、资源、进度和软件测试的重点等的文档。

是整个过程的路由图，随项目发展不断调整、获得完善，按照标准的格式和内容编写。

确定了测试项、被测特性、测试任务、谁执行任务、各种可能的风险，作为关于质量的重要报告呈现给管理层

制定软件测试计划的原则

• 为测试活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

• 为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

• 开发有效的测试模型，能正确的验证正在开发的软件系统。

• 确定测试所需要的时间和资源，以保证其可获得性、有效性。

• 确立每个测试阶段测试完成，以及测试成功的标准、要实现的目标。

• 识别出测试活动中各个风险，并消除可能存在的风险，降低有不可能消除的风险所带来的损失。

• 制定计划尽早开始

• 保持测试计划简介易读

• 争取多渠道评审测试计划

• 计算测试的投入

制定软件测试计划的步骤

计划、准备、检查、修改、继续

5.4测试设计及测试用例

测试用例设计原则

第七章 系统测试技术

7.1软件自动化测试

自动化测试概念

通过自动化测试工具，按照测试工程师的预定计划进行自动化测试，用程序测程序，用脚本运行代替手工测试。

自动化测试的优缺点

1. 手工测试的好处

   1. 测试人员的经验和对错误的判断能力是不可替代的

   2. 界面和用户体验测试，审美观和心理学体验是不可替代的

   3. 正确性检查，逻辑推断能力是不可替代的

2. 手工测试的局限性

   1. 容易遗漏，不可能百分百覆盖软件功能

   2. 人工重复回归测试难度大

   3. 人工无法模拟可靠性测试时系统的长时间运行

   4. 手工测试精确性差

   5. 价格昂贵，对测试人员检验要求高

3. 自动化测试的好处

   1. 方便回归测试

   2. 减少失误，解放测试人员，有效利用有限的人力资源

   3. 增强测试质量和覆盖率

   4. 执行手工测试不可能完成的系统可靠性测试、性能测试、负载测试

4. 自动化测试局限性

   1. 没有思维

   2. 发现的问题和缺陷比手工少

   3. 不能用于测试周期很短的项目，不能测试不稳定软件，不能测试易用性

7.3Web测试

Web测试概述[Web测试]

• 用户界面测试：确保向用户实现了正确的界面显示，使用户能够进行正确的操作。

  • 导航测试

  • 图形测试

  • 内容测试

  • 表格测试

• 功能测试：软件功能符合用户要求

  • 链接测试

  • 表单测试

  • Cookie测试

  • 数据库测试

• 性能测试：连接速度、负载、压力测试

  • 连接速度测试

  • 负载测试

  • 压力测试

• 兼容性测试：平台、浏览器、分辨率、Modem连接速率、打印机兼容

  • 平台兼容性测试

  • 浏览器兼容性测试

  • 分辨率兼容性测试

  • 组合兼容性测试

• 安全性测试：系统中的安全保密性措施能否发挥作用

  • 目录设置

  • SSL

  • 登录

  • 日志文件

  • 脚本语言

第九章 第三方测试

9.1基本概念与测试过程

介于开发商和用户之间的第三方测试组织，在模拟用户环境条件下进行的确认测试。又称独立测试，有独立验证和测试活动。

第三方测试的意义和模式

意义

• 严格掌握软件质量，减少软件维护成本

• 在独立性、客观性、专业性、权威性等方面都具有优势

• 保证软件市场的公平竞争，降低中小软件企业的测试成本

模式

• 用户主导测试模式

?

• 开发团队主导的测试模式

?

第三方测试的相关概念

1. 定义：第三方测试是由开发者和用户以外的第三方进行的软件测试，保证测试的客观性

2. 实施主体：狭义理解是独立的第三方机构国家级软件测评中心，各省软件测评中心，有资质的软件评测企业。广义的是非本软件的开发人员。（QA部门人员测试、公司内部交叉测试）

3. 相关概念：

   1. 开发方测试：思维定势、心理因素、利益驱动

   2. 用户测试：很难进行全面的功能性测试，其它的性能、并发等方面的测试比较困难

   3. 外包测试：利益不同，外包测试代表着开发团队的利益

4. 职责：

   1. 验证软件是否符合需求和设计

   2. 检测错误

   3. 对错误进行分类分析，将分析结果反馈给开发人员以改进软件过程管理

5. 涵盖测试范围：

   1. 第三方测试主要使用黑盒测试，手工加自动化测试

   2. 不负责单元测试

第三方测试的测试过程

1. 制定测试计划

2. 测试设计

3. 测试实施

4. 测试总结

第十章 公有云测试质量评估与退出方法

10.2云可靠性度量

软件可靠性

• 规定条件下，规定时间内，软件完成规定功能而不引起系统错误的概率

• 规定的时间周期里，在所述条件下程序执行所要求的功能的能力

1. 软件可靠性基础理论

   软件可靠性是软件发生故障的概率

2. 传统软件可靠性模型

   软件可靠性可以使用软件可靠性模型进行估计和预测

   1. 输入域的软件可靠性模型

      Nelson模型

      Browmn-Lipow模型

      假定软件故障不被修复

   2. 时间域的软件可靠性模型/软件可靠性增长模型(SRGM)

      在软件系统的运行过程中，修复暴露出的软件故障，从而提升软件系统可靠性的过程

      GO模型

      S型模型

      MO模型

   3. 结合时间域和输入域的可靠性模型/树形可靠性模型（TBRM）

3. Web软件可靠性模型

   度量内部的软件缺陷来度量系统的可靠性

第十一章 软件测试的拓展与提高

11.1企业测试实践

测试人员组织[如何组织软件测试团队]

• 软件测试团队分为四种类型：融合型，相对独立型，完全独立型，相互制约型。

  • 融合型软件测试团队是指软件测试人员和软件开发人员融为一体。

  • 相对独立型软件测试团队是指软件测试人员和软件开发人员同属于一个部门，但属于不同的小组。

  • 完全独立型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门。

  • 相互制约型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门，但测试人员和开发人员之间存在互相评价工作质量的关系。

• 从融合型到相互制约型，测试质量提高的同时成本也会增大。

• 一个理想的测试团队应该既有软件开发人员，又有测试人员，既有技术人员，又要有精通行业知识的领域专家，而且测试团队要有明确的职责和分工

  • 软件开发人员可能会倾向于设计执行证明软件可以正常工作而不是不能正常工作的测试。

    软件开发人员思维倾向于程序逻辑而不是用户的角度，会对测试造成负面影响。

    软件开发人员了解程序内部结构，能够以较低的成本发现问题。

    软件开发人员需要参与单元测试和集成测试。

  • 测试人员和软件开发人员结合交流贯穿整个测试过程，这样才能保证全面的测试能够得到执行，错误得到及时的改正。

  • 技术人员需要和领域专家进行合作交流，需要领域专家解决需求文档中比较复杂的领域专业问题，保证软件能够满足用户的工作需要。

软件测试人员的培养方法

• 测试人员要能清晰准确地表述BUG，帮助开发准确定位问题，提高效率。

• 测试与开发之间要建立起信任和默契，要在坚持原则的基础上和开发保持良好关系，让开发人员理解并支持我们的工作。

• 提高测试人员在沟通方面的能力。

• 让测试人员参加客服和开发组织的产品及业务背景培训，通过加大培训量和培训深度来提高测试人员的业务理解能力。

• 测试人员要懂数据库；测试人员也要具备一定的编程技能；测试人员应不断学习新的技术。

11.3基于搜索的软件测试SBSE

（Search-Based Software Engineering）基于搜索的软件工程

从问题的解空间出发，将传统的软件工程问题转化为优化问题，并使用高性能的搜索算法，在问题所有可能解的空间中，寻找最优解或者近似最优解。

智能搜索算法

1. 遗传算法

2. 改进遗传算法

3. 人工鱼群算法

4. 禁忌搜索算法

5. 人工免疫算法

6. 粒子群算法

7. 爬山算法

8. 模拟退火算法

搜索技术在软件测试中的应用

1. 基于搜索的测试用例自动生成

2. 基于搜索的测试用例优化

3. 基于搜索的变异测试技术