【软件测试】软件测试总结笔记（2）

关于第三部分 软件测试过程（内容）

1.单元测试

⭐单元测试也称模块测试，这是针对最小的可测试软件元素-模块进行测试工作。

单元测试目的在于发现各模块内部可能存在的各种差错。

基本概念

“单元”：明确的功能、规格定义，与其他部分明确的接口定义

A.结构化程序设计：函数或子过程

B.面向对象：类或者类的方法

C.一个菜单、屏幕显示界面或对话框等

定义

• 单元测试的依据是详细设计描述
• 单元测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为
• 通常我们用白盒测试方法测试单元的内部结构，用黑盒测试方法测试单元的功能和可观测的行为

⭐单元测试环境

单元测试时，如果模块不是独立的程序，需要辅助测试模块：

• 驱动模块(Driver)：所测模块的主程序：它接收测试数据，把这些数据传递给所测试模块，最后再输出实测结果。当被测试模块能完成一定功能时，也可以不要驱动模块。
• 桩模块(Stub)：用来代替所测模块调用的子模块。

🔺被测试模块、驱动模块和桩模块共同构成一个测试环境

⭐单元测试内容

• 模块接口测试

I/O 参数值的个数、类型、次序、格式是否正确，I/O文件属性、操作是否正确等。

• 边界条件测试

边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。

• 错误处理测试

检查“错误处理程序”本身的错误。

• 局部数据结构测试

数据说明是否正确、一致，变量及其初值定义是否正确等。

• 重要路径测试

重要路径通常是指完成模块功能的主要路径，一般是控制结构。

单元测试用例的设计思路

• 为系统运行设计用例
• 为正向测试设计用例
• 为逆向测试设计用例
• 为满足特殊需求设计用例
• 为代码覆盖设计用例
• 为覆盖率指标完成设计用例

⭐单元测试的过程

过程:

1. 在详细设计阶段完成单元测试计划。
2. 建立单元测试环境，完成测试设计和开发。
3. 执行单元测试用例，并且详细记录测试结果。
4. 判定测试用例是否通过。
5. 提交《单元测试报告》

2. 集成测试

定义

⭐集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。选择集成测试数据是为了确保系统的组件或子系统正确地协同工作。测试用例将探索组件之间的不同交互，并确保产生正确的结果

集成测试内容

确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括单元间的接口以及集成后的功能。

集成测试优点

• 单元测试具有不彻底性，对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。
• 同系统测试相比，由于集成测试用例是从程序结构出发的，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高。
• 能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况；
• 定位问题较快，由于集成测试具有可重复强、对测试人员透明的特点，发现问题后容易定位，所以能够有效地加快进度，减少隐患。

⭐集成测试层次

• 模块内集成测试
• 子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
• 子系统间集成测试：子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。

集成测试方法

• 静态测试技术：针对概要设计的测试
• 动态测试技术：灰盒测试

灰盒测试优点：

• 能够进行基于需求的测试和基于路径的覆盖测试。
• 可深入被测对象的内部，便于错误的识别分析和解决。
• 能够保证设计的黑盒测试用例的完整性，防止功能或功能组合的遗漏
• 能够减小需求或设计不详细或不完整性对测试有效性造成影响。

Drivers and Stubs

Drivers and Stubs是临时软件组件
§Drivers调用被测软件，将测试数据作为输入传递
在手动测试中，如果系统接口尚未完成，则在其位置使用test Driver来提供测试用户和被测软件之间的接口

Drivers

• §Drivers 的复杂程度各不相同。
• §可以对其进行硬编码，以运行一系列固定的输入值，从准备好的文件中读取数据，包含合适的随机数生成器等。集成测试-驱动程序

Stubs

• §stub是被测试软件正常运行所需的临时或伪软件。
• §这是一个一次性版本，允许进行测试。
• §它将提供一组固定或有限的值，以传递给测试中的软件

⭐集成策略（基于分解的集成）

指在测试对象分析基础上，描述软件模块集成的方式、方法。

非增量式集成策略——一步到位（Big Bang Integration）

所有模块进行分别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。又叫大爆炸集成。

优点：

①方法简单
②允许多测试人员同时并行工作，人力物力资源利用率较高

缺点：

①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高
②一旦集成后包含多种错误，难以纠正

• 增量式集成策略——逐步实现

逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。

自顶向下增量式测试 Top-down integration

①主控模块作为测试驱动器test drivers。
②根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。
③在每个模块被集成时，都必须进行单元测试。重复第2步，直到整个系统被测试完成。

优点：

①较早地验证了主要控制和判断点；
②按深度优先可以首先实现和验证一个完整的软件功能；
③功能较早证实，带来信心；
④只需一个驱动，减少driver开发的费用；
⑤支持故障隔离。

缺点：

①桩的开发量大；
②底层验证被推迟；
③底层组件测试不充分。

适用范围：

①产品控制结构比较清晰和稳定；
②高层接口变化较小；
③底层接口未定义或经常可能被修改；
④产口控制组件具有较大的技术风险，需要尽早被验证；
⑤希望尽早能看到产品的系统功能行为。

自底向上增量式测试 Bottom-up integration

从具有最小依赖性的底层组件开始，按照依赖关系树的结构，逐层向上集成，以检验系统的稳定性。最常用的集成策略。

步骤：

①起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试
②使用驱动模块对步骤１选定的模块（或模块组）进行测试
③用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试
④重复上面的行为，直到系统最顶层模块被加入到已测系统中

优点：

①对底层组件行为较早验证；
②工作最初可以并行集成，比自顶向下效率高；
③减少了桩的工作量；
④能较好锁定软件故障所在位置。

缺点：

①驱动的开发工作量大；
②对高层的验证被推迟，设计上的错误不能被及时发现。
③完整的系统到后期才能呈现

适用范围：

①适应于底层接口比较稳定；
②高层接口变化比较频繁；
③底层组件较早被完成。

三明治增量式测试（混合增量式测试）Sandwich integration

把系统划分成三层，中间一层为目标层，目标层之上采用自顶向下（stub）集成，之下采用自底向上（driver）集成

优点：

合了自顶向下和自底向上两种策略的优点
顶层和底层可以并行完成
所需的存根和驱动程序较少
难以隔离问题

缺点：

中间层测试不充分
测试收敛到中间、集成会话的数量可能不同

适用范围：

适应于大部分软件开发项目

测试生命周期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QBPBR0EP-1685610313898)(https://github.com/Pangxiaox/2019-FinalExam-Notes/blob/master/软件测试图片/pic7.PNG)]

3. 单元测试框架

JUnit

• Junit框架让我们继承TestCase类，用java来编写自动执行、自动验证的测试。这些测试在Junit中称作“测试用例”。

• JUnit提供一个机制能够把相关测试用例组合到一起，称之为“测试套件“（test suite）

• JUnit还提供了一个“运行器”来执行一个测试套件。

①如果有测试失败了，这个测试运行器就报告出来
②如果没有失败，就会显示“OK”

使用JUnit的好处：

• 提高开发速度：测试是以自动化方式执行的，提升了测试代码的执行效率。
• 提高软件代码质量：它从使用小版本发布至整个系统集成，便于实现人员排除错误。同时引入重构概念，让代码更干净和富有弹性。
• 提升系统的可信赖度：它是回归测试的一种。支持修复或更正后的“再测试”，可确保代码的正确性。

使用JUnit：

注意JUnit对于测试用例的命名法是“test”+ TestCaseName测试用例的名字

例如：testDivideByZero() ：public、void、无方法参数

测试置具

常常有这样的情况，会我们写的几个测试都用到同一个或同一组对象。

①如果在每个测试里各自写这样的对象，将造成代码冗余，不利于维护。
②把这样的代码分离出来单独写，让所有的测试都可以利用这些对象代码。
③在JUnit框架里，把这些对象称为“测试置具”（test fixture）。

⭐JUnit框架小结

4. 系统测试

⭐系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的BUG，保证系统的正常运行。

系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下进行测试。

系统测试的内容

• 性能测试

1.评估系统的能力

2.识别系统中的弱点

3.系统调优

• 压力测试

模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。

通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以此来获得系统性能提供的最大服务级别的测试。

• 容量测试

采用特定手段，检测系统能够承载处理任务的极限值所进行的测试工作。

目的是使系统承受超额的数据容量来检测它是否能够正确处理，通过测试，分析出反映软件系统应用特征的某项指标的极限值，确定系统在其极限值状态下还能否保持其主要功能正常运行。

• 健壮性测试

用于测试系统抵御错误的能力。测试重点为当出现故障时，系统是否能够自动恢复或忽略故障继续运行。健壮性包括两层含义：一是高可靠性（软件系统的质量）；二是从错误中恢复的能力（软件系统的适应性）。

• 安全性测试

安全测试检查系统对非法侵入的防范能力。目的是为了发现软件系统中是否存在安全漏洞。

安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息等等。

• 恢复性测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。

恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。

对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

• 备份测试

恢复性测试的一个补充，目的是验证系统在发生软件或者硬件失败时备份数据的能力。

从以下几个角度来进行设计：备份文件并且比较备份文件与最初文件的区别；存储文件和数据；完善系统备份工作的步骤；备份检查点数据；备份引起系统性能的衰减程度；手工备份的有效性；系统备份“触发器”的检测；备份期间的安全性；备份过程日志。

• 兼容性测试

兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。

测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

• 安装性测试

软件如要实现其功能（除嵌入式软件外），第一步是安装操作。理想情况下，一个软件的安装程序应当可以较好的与已有系统相兼容，并有相应的提示界面供用户参考，安装完毕并实现其功能。若事先没有正确的安装测试，导致软件安装错误或失败，则软件根本就谈不上正确的执行，因此安装测试就显得相当重要。

安装性测试的目的就是要验证系统成功安装的能力，并保证程序安装后能正常运行。因此清晰且简单的安装过程是系统文档中最重要的部分。

• GUI测试

GUI测试是对图形用户界面进行的测试。

• Alpha测试

⭐α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

⭐α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

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

• Beta测试

⭐Beta测试由软件的最终用户们在一个或多个客户场所进行。

⭐与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

Beta测试优点：

①测试由最终用户实施

②大量的潜在测试资源

③提高客户对参与人员的满意程度

④与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷

性能测试

是一种测试类型，用于检查应用程序或软件在工作负载下的响应性和稳定性。
性能测试的目标是识别并消除应用程序的性能瓶颈。它是性能工程的一个子集。
此测试主要用于检查软件是否满足应用程序速度、可扩展性和稳定性的预期要求。
速度–确定应用程序是否快速响应
可扩展性–确定软件应用程序可以处理的最大用户负载。
稳定性–确定应用程序在不同负载下是否稳定

• 评估系统的能力。测试中得到的负荷和响应时间等数据可以被用于验证所计划的模型的能力，并帮助做出决策。
• 识别系统中的弱点。受控的负荷可以被增加到一个极端的水平并突破它，从而修复系统的瓶颈或薄弱的地方。
• 系统调优。重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能，检测软件中的问题。

压力测试

是在一种需要反常数量、频率或资源的方式下，执行可重复的负载测试或强度测试，以检查对异常情况的抵抗能力，找出性能瓶颈

负载测试

检查应用程序在预期用户负载下执行的能力。目标是在软件应用程序投入使用之前确定性能瓶颈。

压力测试、负载测试和性能测试的不同点

性能测试：
To set the benchmark and standards for the application.
为应用程序设置基准和标准
负载测试：为了确定系统的上限，设置应用程序的SLA，并查看系统如何处理大工作负荷下的容器。

负载测试：

回归测试

⭐回归测试是在软件发生变动时保证原有功能正常运作的一种测试策略和方法。

①所做的修改达到了预期的目的，例如缺陷得到了修改，新增加的功能得到了实现

②软件的修改没有引入新的缺陷，没有影响原有的功能实现

⭐回归测试不需要进行全面的测试，而是根据修改的情况进行有选择性的测试。

单元、集成、系统测试对比

5. 软件测试自动化

手工测试与自动测试的对比

手工测试

耗费时间、低可靠性、人力资源有限、不一致性、对于一次性的测试有益

⭐自动测试

• 显著降低重复手工测试的时间
• 建立可靠、重复的测试，减少人为错误
• 增强测试范围和覆盖率

但它不能：

• 完全替代手工测试和手工测试工程师
• 保证100%的测试覆盖率
• 弥补测试实践的不足

自动化测试的优点和缺点：优点：
§支持重复测试用例的执行
§有助于测试大型测试矩阵
§允许并行执行
§鼓励无人值守执行
§提高准确性，从而减少人为错误
§节省时间和金钱
缺点：
§自动化仪器通常很昂贵；
§它在测试应用程序中的用户体验方面是无效的；
§编码知识和经验是必须的

⭐🍉 在系统功能测试、验收测试、适用性测试、涉及物理交互性测试时，多采用黑盒测试的手工测试方法；单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用自动化测试。

测试自动化普遍存在的问题

• 不正确的观念或不现实的期望
• 测试工具本身的问题影响测试的质量
• 没有进行有效的、充分的培训
• 没有考虑到公司的实际情况，盲目引入测试工具
• 没有形成一个良好的使用测试工具的环境
• 其他技术问题和组织问题

功能测试工具(QTP、UFT)

QTP测试过程

定制测试计划 👉创建测试脚本👉增强测试脚本功能👉运行测试👉分析测试结果

QTP测试对象管理机制

• 创建测试：获取被操作对象的属性信息。使用唯一的对象名在对象仓库中记录该对象。将对象的全部属性信息存放在数据仓库中。标识关键属性信息。在脚本中记录对象名称和相应的动作。
• 运行测试：从脚本中获得对象名称。在对象仓库中定位对象，并获取其关键属性。根据关键属性信息在被测应用中定位对象。根据脚本中录入的动作执行相应的操作。

QTP八种检查点

标准检查点、图片检查点、图像检查点、文本/文本区域检查点、网页检查点、表格检查点、数据库检查点、XML检查点

性能（压力）测试工具 (LoadRunner)

解决测试资源的限制

• 利用“Virtual Users"代替实际测试人员
• 运行大量的”Virtual Users“在不同的机器上
• 通过”Controller“管理”Vusers“
• 利用图表工具分析测试结果
• 利用录制的脚本进行回归测试

LoadRunner工作流程

👉Virtual Users Generator创建脚本
👉Controller调度虚拟用户
👉运行脚本
👉分析测试结果