软件测试内容整理

1. 软件测试

1.1. 定义

软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

1.2. 行业标准

软件测试已有了行业标准(IEEE/ANSI )，1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其[目的在于]检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。

这个[定义明确指出]:软件测试的[目的是为了]检验软件系统是否满足需求。它[再也不是一个]一次性的，而且只是开发后期的活动，[而是与]整个开发流程融合成一体。

软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

1.3. 软件测试的目标与原则

1.3.1. 软件测试的目的

观点一：

[软件测试]的目的是为了保证[软件产品]的最终质量，在[软件开发]的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、[测试规范]，实施测试，对[测试记录]进行分析，并根据回归测试情况撰写[测试报告]。测试是为了[证明程序]有错，而不能保证程序没有错误。

以最少的时间和人力，尽可能多的发现程序中的错误和缺陷。测试还要证明，软件的功能和性能与需求说明相符合。

[软件测试]的狭义论和广义论——静态和动态的测试软件测试的辨证论——[正向思维]和反向思维
软件测试的风险论——测试是评估
软件测试的经济学观点——为盈利而测试
软件测试的标准论——[验证和确认]

观点二

测试的目的就是以最少的时间和人力找出软件中潜在的各种错误和缺陷，证明软件的功能和性能与需求说明相符，Glenford J.Myers曾提出以下观点：

测试是为了证明程序有错，而不是证明程序无错误
一个好的测试用例能发现至今未发现的错误
一个成功的测试是发现了至今未发现的错误

软件测试的目的往往包含以下内容：

测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进
测试帮助测试人员设计有针对性的测试方法，改善测试的效率和有效性
没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法

1.3.2. 软件测试原则

随处可见的[二八定律]

测试既不要不充分，也不要过分。在通常情况下，在分析，设计、实验阶段的复审和测试工作能够发现和避免80%的bug，而系统的软件测试能找到其余bug的80%，最后约4%（[剩下20%的20%]）的bug只有在用户大范围、长时间的使用后才会暴露出来。应该把“尽早和不断地进行测试”作为开发者的座右铭，问题发现的越早，解决问题的代价就越小。彻底的测试是不可能的，但充分覆盖程序逻辑，并确保软件的所有条件是有可能的。所有的测试都应该追溯到用户需求。测试应从“小规模”开始，逐步转向“大规模”，应针对每个测试结果做全面检查。

软件测试是证伪而非证真
尽早地和不断地进行软件测试
重视无效数据和非预期的测试
应当对每一个测试结果做全面检查
测试现场保护和资料归档
程序员应避免检查自己的程序
充分注意测试中的群集现象
用例要定期评审

1.4. 常见测试与测试分类

1.4.1. 常见测试

[回归测试] [功能测试]
[压力测试] [负载测试]
[性能测试] [易用性测试]
[安装与反安装测试] [恢复测试]
[安全性测试] [兼容性测试]
[内存泄漏测试] [比较测试]
[Alpha测试]

1.4.2. 从软件测试技术角度来分类

1、从是否需要执行被[测试软件]的角度分类（[静态测试]和[动态测试]）。
2、从测试是否针对[软件结构]与算法的角度分类（[白盒测试]和[黑盒测试]）。
3、从测试的不同阶段分类（[单元测试]、[集成测试]、[系统测试]、[验收测试]）。

2. 软件测试的方法

软件测试的方法和技术是多种多样的，从大的分类上来说，分为白盒测试和黑盒测试。

在这里插入图片描述

2.1. 白盒测试

白盒测试是把软件看成一个白盒子，在完全知道软件结果的情况下，通过分析程序内部的逻辑与执行路径来设计测试用户，并对用例进行测试的方法，所以也称结构测试或者数据驱动测试。白盒测试主要用于单元测试，方法有逻辑覆盖和路径测试。其中逻辑覆盖包括:语句覆盖、判定覆盖、条件覆盖、点覆盖、边覆盖等。白盒测试的缺点是投入人力资源的难度很大，执行白盒测试的测试人员要有不亚于开发人员的技术背景和对代码的熟悉程度。

2.2. 黑盒测试

黑盒测试是把软件开成一个黑盒子，不考虑程序的内部结构与执行路径如何，根据输入/输出数据条件来设计测试用例，查看程序的功能是否正确或满足用户要求，因此也称作功能驱动或数据驱动测试方法。黑盒测试主要用于软件确认测试，方法有等价类划分、边界值分析、错误推测法、因果图法等。[黑盒测试对和数要求不高，如何在对系统结构不了解的情况下，设计测试过程才是黑盒测试最核心的部分。]

2.2.1. 黑盒测试可以发现如下几类错误

功能不对或功能遗漏。
界面错误。
数据库访问或者处理错误。
性能问题。

2.2.2. 优点/缺点

优点
- 测试人员不需要了解实现得细节，包括特定的编程语言（没有编程经验的人也可以设计测试用例）；
- 测试人员和编程人员是相互独立的（黑盒测试用例设计与程序如何实现无关）；
- 从用户的角度进行测试，很容易被接受和理解；
- 有助于暴露任何与规格不一致或者歧异的地方；
缺点
- 不能测试程序内部特定部位；
- 如果程序未执行的代码无法发现;
- 不可能做到穷举测试;

2.4. 自动测试

在业务量很大的情况下，需要测试数据或者测试输入时，自动测试就是一个最佳的选择。[自动测试是可重复性的测试并目有着很高的速度与效率]，但是自动测试也有一些缺点。[前期要花费购买工具，并且测试脚本的开发需要投入很多时间和人力。]

2.5. 压力测试

压力测试指为了某个单一的目的，[大强度地重复性的使用软件的某一功能，以发现该功能在压力条件下的性能指标]。软件[上市前]对不够自信的功能进行专项的，不顾逻辑的，无所不用其极的对待待测软件。或者是[软件上市后]对客户反馈的模糊信息进行集中的测试以精确定位问题。

2.6. 功能测试

功能测试是指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。[这种测试的目标]是核实数据的接受，外理和检索是否正确以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户(GUI)与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

2.7. 性能测试

性能测试主要测试软件的性能指标是否达到预期要求。包括[负载测试]，[强度测试]，[数据库容量测试]，以及[基准测试]。

压力测试：给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，包括内部内存、CPU 可用性、磁盘空间和网络带宽。
负载测试：逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
并发测试：主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。

2.8. 安全测试

安全测试是检查系统对非法侵入渗透的防范能力（渗透测试、流量攻击、SQL注入、跨域攻击）

2.9. 兼容性测试

兼容性测试是指要测试的软件在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行、有无异常的测试过程。即是通常说的软件的可移植性。

Web兼容性测试：

浏览器上的兼容性（Google 、saferi、Firefox、opra、Edge、360、QQ、夸克、搜狗…根据市场所占份额，从高到低进行测试）

操作系统测试：

如在传统的桌面端程序，需要对操作系统，x86、x64，运行时环境，甚至是驱动、安装环境。

app兼容性测试

测试（andrid）在不同的系统、不同的屏幕、不同的分辨率、不同的手机品牌等情况下的软件使用情况，手机的选择一般是按照市场占用份额从高到低。ios系统较为简单，可以直接进行测试。

2.10. 用户界面测试(UI测试)

UI测试是对用户界面的风格、图片、背景、文字的测试。用户界面测试用于合适用户与软件之间的交互。一般有这样一些指标，第一是界面的有效性，第二是界面的连贯性，第三是界面传统型。主要包括用户界面的友好性，人性化，易操作性等方面的测试。

2.12. APP专项测试

包括弱网测试、权限测试、场景交互测试、资源争用测试、权限测试、离线测试、安装卸载更新测试、消息推送测试、资源监控测试等

2.12.1. 弱网测试

测试在不同网络状况下，如2g、3g、4g、5g网络环境下，软件的运行情况。

2.12.2. 场景交互测试

测试app在不同使用场景下是否可以保持正常运行，如在使用时来电话收到短信，以及app之间切换后是否正常运行等。

2.12.3. 资源争用测试

测试app的闪存占用、内存占用、cup占用等；如音频播放app在运行时有另外的调用扬声器的app使用时是否正常运行。

2.12.4. 权限测试

测试某些功能在使用前是否会弹出请求授权的弹窗，在关闭权限后下次使用会弹出申请权限弹窗。

2.12.5. 离线测试

测试软件在离线状态下其功能的使用情况。

2.12.6. 安装卸载更新测试

测试app是否可以正常安装、卸载、在有更新时是否会主动弹出更新提示。

2.12.7. 消息推送测试

测试软件在推出后台、弱网、低电量等情况下是否能够正常推送。

2.12.8. 资源监控测试

测试软件的内存、电量、流量等资源的使用情况。

2.11. 文档测试

文档测试是对伴随软件同事提供给用户的各种使用手册，说明书，须知等进行的测试。文档测试是为了避免文档描述和软件系统实际不一致的情况发生。

3. 软件测试的过程

软件测试分为：单元测试、集成测试、确认测试、系统测试

3.1. 单元测试

单元测试也称模块测试，是针对软件设计的最小单元程序模块进行测试的工作。[目的是检查出模块内部的错误，修改这些错误使得程序正确运行。]

在这里插入图片描述

3.2. 集成测试

集成测试也称组装测试，就是按照一定的策略对单元测试的模块进行组装，并在组装过程中进行模块接口与系统功能测试。集成测试的策略主要有两种方式，分为[一次性组装方式]和[增值式组装方式]。

3.3. 确认测试

确认测试也称为有效性测试，目的是验证软件的功能和性能是否满足客户的要求，确认测试是用户参加的测试讨程，采用的测试方法是黑盒测试，为了尽可能多的发现你只有用户在使用系统过程中才能发现的问题。

在这里插入图片描述

3.4. 系统测试

系统测试是经过了前面的测试过程之后，软件系统已经基本符合要求，进行系统测试的目的[是测试软件安装之后，能否与系统的其余部分协调工作，以及对系统运行可能出现的各种情况的处理能力]。系统测试主要是有恢复测试，安全测试，强度测试，性能测试等。

4. 软件测试在项目/产品中的份量

首先软件测试在项目的整个开发过程中是必不可收的部分。软件测试是为了发现和修复潜在的缺陷、错误和问题，以确保软件在发布之前具有高质量、稳定性和可靠性。

但是，[根据项目的特点和需求，调整软件测试在项目管理中的比重是很重要的]。不同的项目可能具有不同的规模、复杂性、时间限制和质量要求，因此，在项目管理中适当地调整测试的比重可以更好地满足项目的实际需求。以下是一些考虑因素：

项目复杂性: 如果项目涉及复杂的功能、集成、数据流等，测试可能需要更多的时间和资源来确保各个部分之间的协调和正确性。
时间限制: 如果项目有紧迫的交付时间，可能需要在测试中投入更多的资源，以确保在有限的时间内发现尽可能多的问题。
质量要求: 如果项目对软件质量有严格的要求，比如高可用性、高安全性等，那么测试在项目中的比重可能需要相应增加，以确保达到这些要求。
变更频率: 如果项目需要经常性的功能迭代和更新，那么持续集成和自动化测试可能需要更多的关注，以便在每次更新后都能保持高质量。
团队经验: 团队成员的测试经验和技能水平也会影响测试在项目中的比重。如果团队中有经验丰富的测试人员，测试可能会更加充分。
资源可用性: 项目可用于测试的资源，包括人员、硬件、软件和测试工具，会影响测试在项目中的比重。
风险管理: 对于具有高风险因素的项目，测试可能需要更多的投入，以最小化潜在的风险。
客户需求: 如果客户对软件质量和稳定性有特别高的要求，测试在项目中的比重可能需要相应增加。
软件本身应用特性: 是否为强应用型(是否为僵尸系统)、多场景、多需求等特征，需要相应的增减测试在项目中比重。

5. 各类软件开发模型中软件测试所处的阶段

软件开发模型的选择会影响软件测试的时间点和方式。不同的软件开发模型强调不同的开发和测试阶段，因此测试在项目中的时间点也会有所不同。

序号	模型名称	测试所在时机
1	（标准）瀑布模型	在软件交付之前
2	瀑布V模型	测试与软件开发前的阶段一一对应，需求分析对应系统测试；总体设计对应集成测试；详细设计对应单元测试
3	演化模型	每个迭代或增量完成后都会有相应的测试阶段
4	演化-原型开发	在原型模型中，初始的原型版本会用于与用户讨论和收集反馈。在这个阶段，测试可以验证原型是否能够正确地演示核心功能，以及用户是否可以与之进行交互。
5	演化-迭代模型	在演化模型中，每个迭代都会产生一个可交付的软件版本。在每个迭代结束时，测试团队会对这个版本进行全面测试，以确保功能的正确性、稳定性和质量。
6	演化-增量模型	每个增量都会包含一部分完整的软件功能。测试团队会在每个增量完成后对其进行测试，以保证每个增量都经过充分的测试。
7	敏捷模型	在敏捷模型中，测试是持续进行的，而不是被限制在特定的阶段。涵盖了整个开发周期。测试在开发团队和测试团队之间是一个协同合作的过程，通过频繁的测试、反馈和调整，确保软件不断地适应变化的需求和达到高质量的标准。
8	融合模型（DevOps）	持续集成和持续交付是关键概念。测试会与开发过程紧密结合，每次代码提交后都会触发自动化测试，以确保代码的质量。