测试基础
软件测试模型
所谓测试模型(Test Model)，是测试和测试对象的基本特征、基本关系的抽象。
软件开发的主要模型有瀑布模型、原型模型、螺旋模型、增量模型以及Rational统一过程(RUP)模型等，
软件测试过程的主要模型有以下几种。
- V模型。
V模型存在一定的局限性，其优缺点如图23-2所示。它将测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，这样会导致需求分析或系统设计阶段隐藏的问题一直到后期的验收测可能已经很难再更改程序的逻辑结构去修正问题，从而导致项目的失败。等到软件编码完成后才开始软件测试工作，那么必须在代码完成后给测试工作预留足够的时间，否则将导致测试不充分，并且开发前期未发现的错误可能会传递并扩散到后面的测试阶段才被发现
V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，导致测试人员很难跨过这些边界来采集测试所需要的信息，并且也阻碍了测试人员从系统描述的不同阶段中取得信息进行综合考虑。 - W模型。
由于V模型在软件开发编码完成后才介入测试工作，导致一些在需求和设计中的问题在后期验收测试中才被发现，这样不能体现“尽早地和不断地进行软件测试”的原则。根据“尽早地和不断地进行软件测试”的基本原则，测试工作应对应软件各开发阶段同步进行，由此演化成一种W模型。
W模型由Evolutif公司提出，相对于V模型，W模型增加了软件各开发阶段中同步进行的验证和确认测试活动。如图23-3所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型相当两个V模型的叠加，一个是开发的V,一个是测试的V，由于在项目中开发和测试的是同步进行，相当于两个V是并列、同步进行的，测试在一定程度上是随着开发的进展而不断向前进行。W模型的优缺点如图23-4所示。
- H模型。
在V模型和W模型中都存在一定的局限性， 它们都把软件的开发过程视为需求、设计、编码等一系列串行的活动，但实际上，这些串行活动之间存在着相互牵制的关系，并且在大部分时间内，他们是可以交叉进行的。虽然软件开发周期期望有清晰的需求、设计和编码阶段，但实践经验告诉我们，严格的阶段划分只是一种理想状况。
为了解决V模型和W模型中存在的上述问题，有专家提出了H模型。H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
软件测试H模型如图23-5所示。
H模型图仅仅演示了在整个生存周期中某个层次上的一次“测试循环”。图中的其他流程可以是任意开发流程,如设计流程和编码流程。也可以是其他非开发流程,如SQA流程，甚至是测试流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。H模型的优缺点如图23-6所示。
H模型揭示了一个原理:软件测试模型是一个独立的流程，贯穿于整个软件产品的周期，与其他流程并发地进行。 - X模型。
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成为可执行的程序。
软件测试X模型如图23-7所示。
X模型的左边描述的是针对单独程序片段进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。已通过集成测试的产品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型的优缺点如图23-8所示。
- 前置测试模型。
前置测试模型是由Robin F.Goldsmith等人提出的，该模型将测试和开发紧密结合，提供了一种轻松的方式，可以使你的项目加快速度。
前置测试模型如图23-9所示。
前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。
前置测试将测试执行和开发结合在一起，并在开发阶段以“编码-测试-编码-测试”的方式来体现。当程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。
与V模型不同的是，前置测试模型认识到验收测试中所包含的3个要素:基于测试的需求、验收标准和验收测试计划，其中基于测试的需求和验收标准都与业务需求定义相联系，但是，验收测试计划则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成，这些定义包括:如何判断验收标准已经达到，以及基于需求的测试已算成功完成。
前置测试模型用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的重要意义。在整个开发过程中，反复使用了各种测试技术以使开发人员、经理和用户节省其时间，简化其工作。
软件测试类型
- 当按照开发阶段划分时，软件测试类型分为单元测试、集成测试、系统测试和验收测试。
1)单元测试
单元测试又称模块测试，是针对软件设计的最小单元(即程序模块)进行正确性检验的工作。
2)集成测试
集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照设计要求(如根据结构图)组装成子系统或系统进行的测试活动
3)系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。
系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方。而且，系统测试还要检验系统的文档等是否完整、有效。
4)验收测试
验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。
按照测试执行者的不同，对不同项目的验收测试的称呼也不同。当测试的执行者是测试内部人员，且待测系统为公司内部产品时，我们称为发布测试或确认测试。当测试的执行者是客户或用户，且待测系统为交付客户的项目时，我们称为验收测试或交付测试 - 当按照测试实施组织划分时，软件测试类型分为开发方测试、用户测试、第三方测试。
1)开发方测试
开发方测试通常也叫“验证测试”或“a测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。
Alpha测试(即a测试)是由一个用户在开发环境下进行的测试，并且在开发者对用户的“指导”下进行测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员(有的地方又说可以让测试人员进行)完成。
2)用户测试
用户测试是在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况下用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
Beta测试(即β测试)通过被看成是一种“用户测试”。Beta测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同的是开发者通常不在Beta测试的现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。
a、β、λ常用来表示软件测试过程中的三个阶段:
a是第一阶段，一般只供内部测试使用:
β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用:
λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行
3)第三方测试
也称为独立测试，是介于软件开发方和用户方之间的测试组织的测试。 - 当按照测试技术划分时，软件测试类型分为黑盒测试、白盒测试和灰盒测试。
1)黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法、正交试验设计法、功能图法、场景分析法等
2)白盒测试
白盒测试又称结构测试，白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。其目的是通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆盖的测试，可以覆盖全部代码、分支、路径和条件。
白盒测试的优点如下。
（1）可以检查内存的泄露。
（2）可以检查异常处理分支语句是否正确。
（3）执行了多少逻辑，可以作为衡量测试是否完整的一个指标。
3)灰盒测试
介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试详细、完整，只是通过一些表征的现象、事件、标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
优点:
（1）能够进行基于需求的覆盖测试和基于程序路径覆盖的测试。
（2）测试结果可以对应到程序内部路径，便于Bug的定位、分析和解决。
（3）能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合。
（4）能够需求或设计不详细或不完整对测试造成的影响。
缺点:
（1）投入的时间比黑盒测试大概多20%~ 40%的时间。
（2）对测试人员的要求比黑盒测试高;灰盒测试要求测试人员清楚系统内部由哪些模块构成，模块之间如何协作。
（3）不如白盒测试深入。
（4）不适用于简单的系统。所谓的简单系统，就是简单到总共只有一个模块。由于灰盒测试关注于系统内部模块之间的交互。如果某个系统简单到只有一个模块，那就没必要进行灰盒测试了。 - 当按照测试执行方式划分时，软件测试类型分为静态测试和动态测试。
1)静态测试
静态测试是指不运行程序，通过人工对程序和文档进行分析与检查;静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码、用户手册等进行非运行的检查。
静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行。因为静态测试方法并不真正运行被测程序，只进行特性分析。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。
2)动态测试
动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
动态方法指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成:编写测试用例，执行程序，分析程序的输出结果。 - 当按照测试对象类型划分时，软件测试类型分为功能测试、界面测试、流程测试、接口测试、安装测试、文档测试、源代码测试、数据库测试、网络测试和性能测试。
1)功能测试
对软件功能进行的测试，主要检查软件功能是否实现了软件功能说明书(软件需求)上的功能要求。
2)界面测试
对软件的用户界面进行的测试，主要检查用户界面的美观度、统一性、易用性等方面的内容。
3)流程测试
按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程，其目的是检查软件在按流程操作时是否能够正确处理。
4)接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
5)安装测试
安装测试包括测试安装代码以及安装手册，安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
6)文档测试
文档测试从交付用户的类型来划分，可分为两类，如图23-15所示。
（1）非交付用户的文档测试。
（2）交付用户的文档测试。
7)源代码测试
通过本类型的测评发现应用程序、源代码中包括OWASP十大Web漏洞在内的安全漏洞，识别、定位存在的安全漏洞，并分析漏洞风险，提出整改建议，提高系统的安全性。
8)数据库测试
数据库测试的主要因素有:数据完整性、数据有效性和数据操作和更新。
9)网络测试
网络测试就是验证网络的建设是否成功的手段。
主要是验证以下几个方面:链路连接情况、错包率、连通性、网络质量、路由策略、备份路由、网管等
10)性能测试
检查系统是否满足需求规格说明书中规定的性能。特别是对于实时系统或做入式系统，软件仅满足功能需求而达不到要求的性能是不行的，所以需要进行性能测试。
(1)负载测试
负载测试，又叫强度测试， 是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
(2)压力测试。
对系统逐渐增加压力的测试，来获得系统能提供的最大的服务级别的测试或者不能接收用户请求的性能点。通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。
(3)稳定性测试。
稳定性测试，也叫疲劳强度测试。通常是采用系统稳定运行情况下的并发用户数,或者日常运行用户数，持续运行较长一段时间，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程。一般情况下，利用稳定性测试来模拟系统日常业务操作。进行稳定性测试的环境中必须要存有一定的数据。 - 当按照质量属性划分时，软件测试类型分为容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、可移植性测试和易用性测试。
1)容错性测试
容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。容错性测试是检查软件在异常条件下的行为。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。
2)兼容性测试
兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。
3)安全性测试
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
4)可靠性测试
软件可靠性测试是指在预期的使用环境中，为检测出软件缺陷，验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件测试。软件可靠性测试是面向故障的测试，每一次测试都由代表用户完成，使得测试成为最终软件产品运行的预演。
5)可用性测试
可用性测试，是评估( 测试)设计方案或者产品的可用性水平
6)维护性测试
可维护性是衡量对已经完成的软件进行调整需要多大的努力。
7)可移植性测试
可移植性指未经修改或修改部分源代码后，应用程序或系统从一种环境移植到另一种环境中还能正常工作的难易程度。
8)易用性测试
易用性测试主要考察评定软件的易学易用性、各个功能是否易于完成、软件界面是否友好等，在很多类型的管理类软件中是非常重要的。 - 当按照测试地域划分时，软件测试类型分为本地化测试和
1)本地化测试
本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。
2)国际化测试
软件国际化的测试就是验证软件产品是否支持一些特性，包括多字节字符集的支持、区域设置、时区设置、界面定制性、内嵌字符串编码和字符串扩展等。
软件测试技术
黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试主要检查程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试的优点主要有以下几点。
(1)比较简单，不需要了解程序内部的代码及实现。
(2)与软件的内部实现无关。
(3)从用户角度出发，能很容易地知道用户会用到哪些功能，会遇到哪些问题。
(4)基于软件开发文档，所以也能知道软件实现了文档中的哪些功能。
(5)在做软件自动化测试时较为方便。
黑盒测试的缺点主要有以下两点。
(1)不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%。
(2)自动化测试的复用性较低。
黑盒测试的测试用例设计方法主要有:测试区域确定法、数据覆盖法、逻辑推断法、业务路径覆盖法等等。
白盒测试法
白盒测试将测试对象看作一个透明的盒子，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。 因此白盒测试又称为结构测试或逻辑驱动测试。
白盒测试允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，是一种穷举路径的测试方法。
信息系统测试管理
测试管理概述
测试管理是为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动。
测试管理的主要因素包括测试策略的制定、测试项目进度跟进、项目风险的评估、测试文档的评审、测试内部和外部的协调沟通、测试人员的培养等。
测试管理内容
测试管理的内容按照管理范围和对象，一般可分为测试部门管理和测试项目管理两种。
测试部门管理包含部门日常事务、部门人员、部门下属项目、部门资产等的跟踪及管理工作。
测试项目管理包含测试人员管理、测试计划及测试策略的编写、测试评审的组织、测试过程的跟进、测试内部和外部的沟通协调、缺陷跟踪等。
测试监控管理
测试监控的且的是为测试活动提供反馈信息和可视性。
测试监控的内容如下。
(1)测试用例执行的进度。
计算公式为:测试用例执行的进度=已执行的数目/总数目。
测试用例执行进度只表明用例执行的进度，不表示测试的成功率。
(2)缺陷的存活时间。
计算公式为:缺陷的存活时间=缺陷从op
open到closed的时间。
缺陷存活时间表明修改缺陷的效率。
(3)缺陷的趋势分析。
按照测试执行的时间顺序(以月、周、天或测试版本为时间单位)，统计被发现的缺陷数量的分布情况。
(4)缺陷分布密度。
计算公式为:缺陷分布密度=对应于一项需求的总缺陷数/对应于该项需求的测试用例总数
(5)缺陷修改质量。
计算公式为:缺陷修改质量=每次修改后发现的缺陷数量(包括重现的缺陷和由修改所引起的新缺陷)。
配置管理
软件测试需要进行充分的测试准备，需要科学的规范的过程管理，有效的配置管理对跟踪和提高测试质量和效率十分重要。测试过程中的配置管理不仅包括搭建满足要求的测试环境。还包括获取正确的测试、发布版本。
测试风险管理
在测试工作中，主要的风险表现为以下几个方面。
(1)需求风险。对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式:另外需求变更导致测试用例变更，同步时存在误差。
(2)测试用例风险。测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求;测试用例没有得到全部执行，有些用例被有意或者无意的遗漏。
(3)缺陷风险。某些缺陷偶发，难以重现，容易被遗漏。
(4)代码质量风险。软件代码质量差，导致缺陷较多，容易出现测试的遗漏。
(5)测试环境风险。有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差。
(6)测试技术风险。某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。
(7)回归测试风险。回归测试一般不运行全部测试用例，可能存在测试不完全。
(8)沟通协调风险。测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期。
(9)其他不可预计风险。一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。
测试人员绩效考核
测试考核基于测试过程进行，因此必须在测试过程结束之后才能进行。按照传统测试周期，测试过程分为:测试计划、测试设计和测试执行三个方面。
测试计划属于测试经理的范畴，测试人员主要是测试设计和测试执行。
1.工作内容考核
(1)参与软件开发过程的工作内容考核。
(2)参与测试文档的准备工作。
(3)执行测试的工作。
(4)测试结果缺陷残留。
(5)测试人员的沟通能力考核。
2.工作效率与工作质量考核
3.对自动化测试人员效率的度量
4.对测试项目负责人效率的度量
(1)测试是否提早介入项目。
(2)开发提交测试的时候，标准是否合理，把关是否严格。
(3)测试计划阶段，评价测试计划的合理性。
(4)项目结束后，评价项且进行阶段中负责人的跟进情况，特殊情况处理，风险触发之后的处理，资源协调、信息收集、共享、沟通、配合等。
5.测试管理的度量
6.考核注意事项
评论区