什么是软件测试
什么是软件？
控制计算机硬件工作的工具，分为：
应用软件：计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包
- C/S架构：client-server，需要安装客户端才能够使用的软件，每次更新都需要更新服务端和客户端
- B/S架构：browser-server，只需要更新服务器，通过浏览器访问
系统软件：生成、准备和执行其他程序所需要的一组文件和程序。
软件基本组成
软件是计算机程序、程序所用的数据及相关文档资料。
软件=程序+数据+文档
软件的产生过程：
什么是软件测试？
使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试的目的
- 为了发现程序（软件）存在的代码或业务逻辑错误（找到bug）
- 为了检验产品是否符合用户需求（提升质量）
- 为了提供用户的体验（提高用户体验）
测试的主流技能
- 功能测试：根据文档执行，将反馈结果与预期结果比较。功能测试主要验证程序的功能是否满足需求
- 自动化测试：使用代码或工具代替手工，对项目进行测试
- 接口测试：使用代码或工具对服务端提供的接口进行测试，验证程序中的接口是否访问正常。
- 性能测试-工具实现：模拟多人使用软件，查找服务器缺陷
- 负载测试（Load Testing）：模拟实际用户的使用情况，测试系统在不同负载下的性能表现。
- 压力测试（Stress Testing）：通过逐渐增加负载，测试系统的极限性能，以确定系统在超负荷情况下的表现及其响应能力。
- 容量测试（Capacity Testing）：评估系统在预期负载下的性能，并确定系统是否能够满足预期的容量需求。
- 性能基准测试（Performance Benchmarking）：与已知标准或竞争对手进行比较，评估系统的性能表现。
- 稳定性测试（Stability Testing）：在长时间负载下测试系统的稳定性，以检测潜在的内存泄漏、资源泄漏或其他性能问题。
常见的测试分类
按测试阶段划分
单元测试：为了确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类、函数、方法的测试。bug太多，修复率太低，开发人员自测
集成测试（接口测试）：单元测试后，将各单元组合成完整的体系，测试单位之间的接口是否正确、数据能否正常传递。
- 组件整合：将各个独立开发的模块或组件整合到一个系统中，并测试它们在集成后的行为。
- 接口测试：验证模块之间的接口是否正确地传递数据和调用功能。
- 功能测试：确保整个系统的功能按照规格说明书的要求正常工作。
- 异常处理：测试系统在异常条件下的行为，例如错误输入或非预期操作。
- 性能测试：在集成环境中评估系统的性能，包括响应时间、吞吐量和资源利用率等方面。
集成测试通常分为两种策略：
- 自下而上（Bottom-Up）：从最底层的模块开始测试，逐步向上测试到系统的顶层。这种方法可以尽早发现低层模块的问题，但需要模拟高层模块的行为。
- 自上而下（Top-Down）：从系统的顶层开始测试，逐步向下测试到最底层的模块。这种方法可以更早地测试到系统整体的行为，但需要使用模拟或桩程序替代尚未开发完成的低层模块。
系统测试：把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能是否和用户需求相符合，在系统运行中是否存在漏洞。看做整体进行测试，除功能以外，需求、兼容性也需要考虑。
- 功能测试：验证系统的功能是否符合规格说明书中的要求，包括正常功能和边界情况下的功能。
- 性能测试：评估系统在正常和负载条件下的性能表现，包括响应时间、吞吐量、资源利用率等指标。
- 兼容性测试：测试系统在不同操作系统、浏览器、设备和网络环境下的兼容性。
- 安全性测试：评估系统的安全性，包括数据保护、身份验证、授权和防范潜在攻击的能力。
- 可靠性测试：验证系统在长时间运行和异常条件下的稳定性和可靠性。
- 易用性测试：评估系统的用户界面和交互设计是否符合用户的期望，以及系统是否易于使用和理解。
验收测试（Acceptance Testing）：软件开发生命周期的最后一项测试活动，也是在软件交付给最终用户之前的最后一道关卡。其目的是确保软件系统满足最终用户的需求，并且符合预期的使用情境和业务流程。验收测试通常由最终用户、客户或业务代表来执行，因为他们最了解软件系统应该如何满足业务需求。
- 确认需求满足：验证软件系统是否满足了最初的用户需求和业务规格。
- 功能完整性：确保系统的所有功能都按照规格说明书和用户期望的方式运行。
- 用户体验：评估系统的易用性、用户界面设计、交互流程等，确保用户能够轻松地使用系统。
- 业务流程：验证系统是否支持所需的业务流程，并且在真实的业务环境中能够正常运行。
- 性能：确认系统在预期负载条件下的性能表现是否符合要求。
- α测试：在开发者环境中由客户或最终用户进行测试。测试环境受开发方控制，测试人员不多，测试时间比较集中。执行者：测试人员、用户、公司内部人员
- β测试：在真实的生产环境中由一组选择的最终用户进行测试。
- 合同验收测试：在合同规定的时间和地点由客户和供应商共同进行的测试。
- 一般先做α测试再做β测试
按代码可见度划分
黑盒测试（Black Box Testing）：是一种软件测试方法，它着眼于测试软件的功能性而不考虑其内部结构或实现细节。在黑盒测试中，测试人员不需要了解软件的内部逻辑、算法或源代码，而是将软件看作一个黑盒子，只关注输入与输出之间的关系。针对功能、兼容性进行测试。对应系统测试
在黑盒测试中，测试人员根据软件的需求规格说明书、用户文档和设计文档等外部文档来设计和执行测试用例，以验证软件的功能是否按照预期工作。测试人员主要关注以下几个方面：
- 功能测试：验证软件的功能是否符合规格说明书和用户需求。
- 界面测试：测试软件的用户界面是否符合设计要求，以及用户是否可以轻松地与软件进行交互。
- 用户体验测试：评估软件的易用性、可理解性和用户满意度。
- 输入验证：检查软件对于各种输入的响应是否正确，包括合法输入、非法输入和边界值输入。
- 状态转换测试：测试软件在不同状态下的行为，例如登录状态、注销状态等。
- 错误处理：验证软件对于异常情况的处理是否正确，例如错误输入、系统故障等。
白盒测试（White Box Testing）：又称为结构测试或透明盒测试，是一种软件测试方法，旨在评估软件系统的内部结构和逻辑，以验证其是否按照预期进行操作。白盒测试的重点在于测试软件的内部工作方式，包括代码覆盖率、路径覆盖率以及逻辑覆盖率等方面。
白盒测试的主要特点包括：
- 了解内部结构：测试人员需要深入了解软件的内部结构和源代码，以便设计和执行测试用例。
- 代码覆盖：白盒测试通常包括评估测试用例覆盖的代码范围，例如语句覆盖、分支覆盖、路径覆盖等。
- 逻辑测试：验证软件系统的逻辑是否正确，包括条件语句、循环语句和异常处理等。
- 数据流分析：评估软件中的数据流和变量的使用，以确保数据的正确性和一致性。
- 性能测试：评估系统的性能和资源利用率，包括内存使用、处理时间和吞吐量等方面。
- 安全测试：评估系统的安全性和防御机制，包括对潜在的安全漏洞和攻击面的分析。
白盒测试通常由具有开发或编程经验的测试人员来执行，因为他们需要深入理解软件的内部工作原理和代码结构。白盒测试通常在软件开发的早期阶段进行，以便及早发现和解决潜在的问题，并在软件发布前提供更高的质量保证。
白盒测试与黑盒测试相辅相成，可以共同确保软件系统的质量。白盒测试主要关注软件内部的正确性和结构，而黑盒测试则关注软件的外部功能和用户需求是否得到满足。
灰盒测试（Gray Box Testing）：是介于白盒测试和黑盒测试之间的一种软件测试方法。在灰盒测试中，测试人员部分了解软件的内部结构和实现细节，但不需要深入到源代码的层面。灰盒测试旨在结合黑盒测试的功能性测试和白盒测试的结构性测试，以提高测试覆盖率和效率。
在灰盒测试中，测试人员通常可以访问一些关于系统内部的信息，例如数据库结构、应用程序框架或部分源代码。这种了解使得测试人员可以更有效地设计测试用例，并更好地理解系统的内部运行机制，以便更有针对性地进行测试。
灰盒测试通常涉及以下几个方面：
- 功能测试：类似于黑盒测试，验证系统的功能是否按照规格说明书和用户需求工作。
- 接口测试：验证系统的不同模块之间的接口是否正确，以及数据传递是否正常。
- 性能测试：评估系统在不同负载条件下的性能表现，包括响应时间、吞吐量和资源利用率等指标。
- 安全性测试：评估系统的安全性，包括身份验证、授权、数据保护等方面。
- 代码覆盖率分析：通过部分了解系统内部结构，测试人员可以评估测试覆盖率，并确定哪些部分需要更多的测试。
由于灰盒测试结合了黑盒测试和白盒测试的优点，因此可以更全面地测试软件系统，并发现更多的潜在问题。然而，灰盒测试可能需要测试人员具备更多的技术知识和理解能力，以便更好地利用系统内部信息进行测试。
被测对象是否运行
- 动态测试：运行被测试系统而进行的测试
- 静态测试：不需要运行被测试系统而进行的测试（界面检查、文档检查、代码走查）
包含内容划分
- 功能测试
- 界面测试
- 易用性测试
- 性能测试（负载测试、压力测试）
- 安全测试
其他测试
- 冒烟测试：硬件测试中产生的概念。在进行正式测试前对主要核心功能进行的测试，一般由开发或者测试主管来负责。不通过会发回给开发
- 回归测试：开发对存在问题的功能进行修改后再一次进行的测试，也需要验证相关功能
- 探索性测试/自由测试：根据项目经验进行的随意测试
软件的生命周期
SDLC
Systems Development Life Cycle指的是软件从概念阶段到终止阶段的完整过程。它描述了软件开发团队在设计、开发、测试、部署和维护软件产品时所遵循的步骤和阶段。
SDLC通常包括以下阶段：
- 需求分析（Requirements Analysis）：在这个阶段，团队和利益相关者确定软件系统的功能、性能、安全性等方面的需求，并将其记录在需求规格说明书中。
- 设计（Design）：在这个阶段，基于需求分析的结果，设计团队开始制定软件系统的结构、组件和界面等，通常包括高级设计（High-Level Design）和详细设计（Detailed Design）。
- 实现（Implementation）：在这个阶段，开发团队开始根据设计文档编写和测试代码，创建软件系统的各个功能模块，并逐步集成和测试这些模块。
- 测试（Testing）：在这个阶段，测试团队对软件系统进行功能测试、性能测试、安全测试等，确保系统符合预期的功能和质量标准。
- 部署（Deployment）：在这个阶段，将已经测试通过的软件系统部署到生产环境中，并进行最后的验证和配置。
- 维护（Maintenance）：在这个阶段，团队负责维护软件系统，修复已知的缺陷、更新和升级系统，以确保系统的稳定性和安全性。
瀑布型生命周期
特点：自上而下、有顺序性
缺点：回测成本比较高、测试周期比较长
W模型
- W 模型是一种经典的软件开发和测试模型，它将软件开发和测试分为两个主要阶段：左侧的开发阶段和右侧的测试阶段。在开发阶段，软件需求被转化为软件设计、编码和集成，而在测试阶段，各种测试活动，如单元测试、集成测试、系统测试和验收测试，与相应的开发阶段相对应。
- W 模型强调了测试活动与开发活动的对应关系，同时在测试活动的各个阶段都可以进行相应的验证和确认，以确保软件质量。它适用于大型软件项目和要求高质量的软件开发过程。
- 活动串行：测试与开发同步进行，在V模型的基础上增加了在开发阶段的同步测试
- 局限：不支持迭代，减少了一定错误发生率，但是需按照流水线进行设计、编码和测试
V模型
- V 模型是一种与 W 模型相似的软件测试模型，它强调了软件开发阶段与相应的测试阶段之间的对应关系。与 W 模型不同的是，V 模型将每个开发阶段都与一个相应的测试阶段直接相对应，形成了一个”V”字形的结构。
- V 模型强调了测试活动与开发活动之间的紧密关系，每个开发阶段的产物都可以直接对应一个相应的测试活动，以确保每个阶段的质量控制。它适用于需求明确、项目周期较短的软件开发项目。
- 局限：仅仅把测试过程作为编码之后的一个阶段
需求分析阶段会产生需求规格说明书（SRS），测试根据这个编写测试用例。
V模型开发中，测试在需求阶段就已经介入了，可以降低测试成本，缩短开发周期。
传统、周期长的项目使用V模型
H模型
- H 模型是一种将软件开发和测试交错进行的测试模型，它将软件开发过程和软件测试过程在时间上交错进行，以加快软件交付的速度。在 H 模型中，软件开发和测试活动是同时进行的，并且它们之间会有多次的交互和反馈。
- H 模型强调了软件开发和测试的并行进行，测试活动可以早早地介入到软件开发过程中，及时发现和修复问题。它适用于需要快速迭代和交付的敏捷开发项目。
- 活动并行：过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行。
X模型
- X 模型是一种将软件开发和测试活动交叉进行的测试模型，它强调了开发和测试活动之间的协作和合作。在 X 模型中，开发和测试活动是并行进行的，并且它们之间会有多次的交互和沟通。
- X 模型强调了团队协作和质量管理，在软件开发和测试的过程中，开发团队和测试团队可以紧密合作，共同推动软件的开发和测试工作。它适用于迭代开发和敏捷开发项目。
- 单独的单元设计开发测试，测试完成后凭借接口集成在一起。支持探索性测试。
- 支持需求不断变化，并且加入探索性测试，便于发现测试计划之外，发现更多的缺陷。
敏捷模型
- 强调以人文本，把一个大项目分为多个相互联系但也可以独立运行的小项目并分别完成，在这个过程中软件一直处于可使用状态。
- 开发与测试并行，项目周期快，模块提交快，测试时比较有压力；注重团队沟通，测试人员几乎要参加整个项目组的讨论决策会议；独立完成各项测试计划，测试执行工作；
- 具备良好的自动化测试框架支持进行快速测试；
- 在活动中关注产品需求，产品设计，解读源代码。
- 特点：快，迭代周期短。弱化文档，通过人与人的沟通实现需求
软件生命周期的各阶段
问题的定义及规划
主要确定软件的开发目的及其可行性，制定项目总体开发计划
需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书终版（原型图），提交评审
设计
把需求分析得到的结果转换为软件结构和数据结构，形成系统架构
概要设计：主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务
详细设计：对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明
编码
按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
测试
单元测试、集成测试、系统测试、验收测试
运行维护
是软件生命周期中持续时间最长的阶段，在软件开发完成并投入使用之后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两方面。
质量模型
衡量一个优秀软件的纬度
- 功能性：
- 性能：
- 兼容性：
- 易用性：
- 安全：
- 可靠性：
- 可维护性：核心代码要有说明，该独立的要独立
- 可移植性：
软件测试流程
在什么条件下可以发布？剩余bug数量很少，达到一定的用例执行覆盖率
发布流程：开发打包—>运维/运营/开发—>部署到生产环境（用户的使用环境）
开发环境：开发人员写代码的环境
测试环境：测试人员进行测试的环境（1个或一个以上）
预发布环境（UAT环境）：验收测试（UAT测试）进行的环境。
生产环境：真实用户使用环境
测试方式
灰度测试（Gray Testing）：是软件测试中一种渐进式的测试方法，也被称为渐进式部署测试或金丝雀测试。在灰度测试中，新版本的软件系统被部署到一小部分用户或用户群体中进行测试，而不是立即对所有用户进行全面的部署。灰度测试的主要目的是逐步引入新版本的软件系统，以确保其在真实环境下的稳定性和可靠性。通过将新版本的软件系统部署到一小部分用户中进行测试，可以及早发现和解决潜在的问题，减少对全体用户的影响。
A/B测试：A/B测试是一种在在线环境中常用的实验设计方法，用于比较两个或多个版本的产品或服务，以确定哪个版本能够更好地实现预期的目标。在A/B测试中，将用户随机分成多个组，每个组将被暴露于不同的版本中，并记录用户的行为数据，最后分析数据以确定哪个版本更有效。
二者区别
灰度测试（Gray Testing）和 A/B 测试是两种不同的测试方法，虽然它们都涉及将用户分成不同的组来比较不同版本的产品或服务，但在实践中有着不同的应用场景和目的。
- 目的和应用场景：
- 灰度测试通常用于验证新版本的软件系统在真实生产环境中的稳定性和可靠性。它通过逐步将新版本应用于一小部分用户来测试系统的性能和用户反馈，以减少对整个用户群体的风险。灰度测试的主要目的是确保新版本的软件系统在全面部署之前已经经过了充分的测试和验证。
- A/B 测试主要用于比较两个或多个不同版本的产品或服务，并确定哪个版本能够更有效地实现预期的目标。它通常在在线环境中使用，例如网站、移动应用或电子邮件营销中，通过将用户随机分成多个组，向不同组展示不同版本，并收集用户行为数据来确定哪个版本更有效。
- 用户分组方式：
- 在灰度测试中，用户通常被随机分成不同的组，但是每个组中的用户都暴露于相同的版本。灰度测试的目标是在一小部分用户中测试一个版本的性能，而不是比较不同版本之间的差异。
- 在 A/B 测试中，用户也被随机分成不同的组，但是每个组中的用户将暴露于不同的版本。例如，一个组将看到版本 A，而另一个组将看到版本 B。A/B 测试的目标是比较不同版本之间的差异，并确定哪个版本更有效。
- 测试内容和指标：
- 灰度测试通常关注新版本的软件系统在生产环境中的性能、稳定性和用户反馈等方面的指标。
- A/B 测试通常关注不同版本的产品或服务在用户行为、转化率、点击率等方面的指标。
流程
各个阶段的输出
需求分析——根据需求规格说明书输出项目需求分析测试点列表
用例设计——测试用例文档
执行测试——bug
评估测试——测试报告的输出
- 需求评审
- 参与角色：产品经理、开发、测试
- 目的：需求一致、在各角度对需求进行查漏补缺、知道被测项目有哪些功能模块
- 测试计划
- 测什么、谁来测、怎么测
- 用例设计 针对穷举进行设计
- 用例执行
- 缺陷管理
- 测试报告
测试需求分析
解决测什么的问题，一般来自需求规格说明书中原始需求。测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
功能：业务流程
非功能：界面、文档、兼容性、易用性、性能、安全性
根据需求规格说明书明确的测试的内容提取测试点，测试点是软件的最小单元
测试需求分析的目的
- 测试需求分析是编写测试用例的依据
- 有助于保证测试的质量与进度
- 测试需求是衡量测试覆盖率的重要指标
需求分析的步骤
- 查阅需求规格说明书（原型图），初步熟悉被测软件的核心的业务流程
- 针对某个功能，细化需求，列出测试点
- 根据业务逻辑的先后顺序来进行分析按钮，一般按钮存在（什么条件）操作成功，（什么条件）操作失败，验证操作结果（验证交互功能、即关联功能），验证当前操作的结果的功能
一个页面进行测试需求分析
- 进行页面检查，参考原型图，查看界面是否一致
- 依次分析每个输入项，从上到下从左到右的顺序进行分析约束限制、是否必填、是否重复、隐形需求（如手机号码的格式验证）。
案例
面试题
遇到隐形需求怎么办？
要充分熟悉产品，参考成熟的同类产品，站在用户的角度去考虑，从而挖掘需求
给你一个带logo的水杯，你会如何去测试？
先明确测试的对象，什么样的杯子对应功能：能否装水，是否漏水，能否装热水冰水饮料，是否保温
对应非功能：logo是否与原型图一致，美观，是否掉色，材质是否环保安全
对应易用性：防滑，防烫，是否带手把，边缘是否光滑，携带是否方便
兼容性：是否能装其他液体
安全性：装热水的时候会有毒素吗
性能：（如果是保温杯的化可以保温多久），是否防摔，挤压被子会不会坏，容不容易被水泡软
你会如何测试朋友圈，购物车等熟知的软件产品（支付，优惠券，二维码）
需求评审
需求分析完成后要对需求进行评审，评审是否存在漏测和错测的测试点。
参与人员：测试人员、组内人员、测试主管/组长、产品、开发
测试用例
什么是用例？
用例：用户使用的案例
什么是测试用例？
测试用例：为项目需求而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序是否满足客户需求。每一个测试点的数据设计和步骤设计
测试用例的作用
- 防止漏测
- 实施测试的标准
用例格式标准
用例执行的八大要素
| 用例编号 | 项目/模块 | 用例标题 | 优先级 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 |
用例编号：项目简称_模块简称_编号，产品名-测试阶段（it、st、uat）-测试项-xxx（英文）或者项目+编号
项目/模块：所属项目或模块
用例标题：主要描述测试的目的，输入内容＋结果，用例标题不要重复
优先级：表示用例重要程度或者影响力P0~P4（P0最高，用户使用频率最高为核心功能）。高（主要核心业务功能，冒烟用例）中（错误异常的测试点，如注册失败）低（兼容性、界面错误）
前置条件/预置条件：要执行此条用例，有哪些前置操作。可以用来简化步骤。如果用例不需要其他条件，可以无条件
测试步骤：执行用例步骤
- 路径
- 具体数据
- 操作动作
测试数据：操作的数据，没有的话可以为空（可以和操作步骤分开）
预期结果：按照操作步骤，应该有什么结果，分为一对一（一个步骤对一个结果）和多对一（多个步骤对一个结果）用例执行结果+不同角色隐形结果
实际结果：通过、不通过、阻塞（当前用例无法执行）
（备注）：bugid/测试无法执行原因
（测试版本）
（用例设计者）
（测试时间）
用例是根据测试点进行编辑，但并不是针对每个测试点编辑一条用例，否则会造成重复测试
软件测试八大原则
- 所有的软件测试都应追溯到用户需求
- 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭（在需求阶段介入是最好的）（重复测试挖掘更多bug）
- 完全测试是不可能的，测试需要终止
- 测试无法显示软件潜在的缺陷
- 充分注意测试中的群集现象（80%的bug出现在20%的模块中）
- 开发工程师应避免测试自己的程序
- 尽量避免测试的随意性（容易出现漏测）
- 测试的抗药性