测试理论基础

什么是软件测试？

软件测试是通过静态检查和动态执行等方式，对软件产品及相关文档进行验证和确认，发现缺陷，并对软件质量进行评估的过程。

软件测试的目的是什么？

（1）发现软件中的缺陷和错误

（2）为软件质量提供评价信息

（3）验证软件是否满足用户需求和使用预期

重点：软件测试的重点是尽可能发现缺陷和风险，并不是证明软件没有 bug。

黑盒与白盒的定义

白盒测试：

要求测试人员了解程序的内部结构和处理过程，按照程序内部逻辑设计和执行测试，检查语句、分支、条件、路径等是否按预期工作。它主要关注被测程序的源代码和内部实现，但也需要结合需求和预期结果判断是否正确。
黑盒测试：

基于需求、规格说明和外部行为来设计测试，把测试对象看作一个黑盒子。测试时主要关注输入、输出和功能/业务行为，不依赖软件产品的内部结构和处理过程。黑盒测试常用于功能测试，也可用于部分非功能测试。

白盒测试用例设计常用方法

常见的白盒测试用例设计方法主要是逻辑覆盖法，包括：语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

常见覆盖标准可这样理解：

语句覆盖：每条可执行语句至少执行一次。
判定覆盖：每个判定的每个分支至少执行一次。
条件覆盖：每个判定中的每个条件都至少取到一次真和一次假。
判定/条件覆盖：同时满足判定覆盖和条件覆盖。
条件组合覆盖：每个判定中各条件取值的各种组合至少执行一次。
路径覆盖：使程序中每一条可能的路径至少执行一次。

说明： 条件覆盖和判定覆盖之间没有绝对的强弱包含关系；路径覆盖理论上最强，但实际中常因为路径数量过多而难以完全做到。

补充：

静态测试：不运行被测对象，如需求评审、设计评审、代码走查、静态分析等。
动态测试：需要执行被测对象，如单元测试、接口测试、系统测试、性能测试等。

黑盒测试用例设计常用方法

等价类划分、边界值分析、错误推测法、判定表分析法、因果图法、正交试验设计法、场景法、状态迁移图法等。

等价类划分：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误是等效的。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中选取少量代表性数据作为测试输入。等价类通常分为有效等价类和无效等价类。
边界值分析法：对等价类划分法的补充。经验表明，大量错误容易出现在输入或输出范围的边界附近，因此要重点设计边界值、边界内侧值和边界外侧值等测试数据。
错误猜测法：基于经验和直觉推测程序中可能存在的各种错误，从而有针对性地设计测试用例的方法。
判定表分析法：适用于多个输入条件之间存在组合关系、不同条件组合会触发不同输出或操作的场景。它通常通过条件桩、动作桩和规则列来设计测试用例。
因果图法：适用于输入条件之间存在制约关系、输入与输出之间存在因果关系的场景。因果图通常可以进一步转换为判定表，因此两者关系紧密，但不是简单的”完全等价”。
正交试验设计法：当参数很多、组合数量很大，且各因素优先级差异不明显时，可以利用正交表选择有代表性的组合，以较少的用例覆盖较大的组合范围。
场景法：根据用户实际业务场景来设计测试，一般围绕基本流、备选流和异常流展开。
状态迁移图法：适用于存在明确状态和状态切换规则的场景，重点验证状态之间的有效迁移和无效迁移是否符合预期。

什么是灰盒测试？

灰盒测试是介于白盒测试与黑盒测试之间的一种测试方式。测试人员不必完全掌握源代码实现，但会利用接口定义、数据库结构、日志、架构设计等内部信息来辅助设计和执行测试。它常见于接口测试、集成测试、系统联调等场景。

列举出你所了解的软件测试方式

按测试级别划分：单元测试、集成测试、系统测试、验收测试。
按变更相关类型划分：回归测试、确认测试。
按测试关注点划分：功能测试、性能测试、稳定性测试、易用性测试、安全性测试。
按测试参与者或环境划分：α 测试、β 测试、第三方测试。
按测试设计方法划分：白盒测试、黑盒测试、灰盒测试。
按测试分析方式划分：静态测试、动态测试。
按测试执行方式划分：手工测试、自动化测试。
按测试对象划分：程序测试、文档测试。

什么是单元测试？

单元测试是对最小可测试单元（函数、方法、类、模块等）进行验证，检查其逻辑是否正确。它通常发生在开发阶段，多数需要执行代码，常以白盒测试为主，也可以结合黑盒思想设计输入输出。代码检查和静态分析属于静态测试，但不等于单元测试。

单元测试、集成测试、系统测试、验收测试、回归测试这几步最重要的是哪一步？

这些测试分别在不同阶段或不同场景下发挥作用，没有绝对最重要的一步，缺一不可。如果从完整交付质量的角度回答，系统测试通常很关键，因为它面向完整系统，验证功能、业务流程以及性能、安全、兼容性等是否满足需求。

注意： 回归测试并不是固定的某一个阶段，它通常贯穿在需求变更、缺陷修复和版本迭代之后。

集成测试和系统测试的区别，以及应用场景分别是什么？

区别：

执行顺序：先执行集成测试，待集成测试问题修复后，再做系统测试。
用例粒度：集成测试比系统测试用例更详细，集成测试对于接口部分也要重点写，而系统测试的用例更接近用户接受的测试用例。

应用场景：

集成测试：一般包含接口测试，对程序的提测部分进行测试。测试方法一般选用黑盒测试和白盒测试相结合。
系统测试：针对整个产品的全面测试，既包含各模块的验证性测试和功能性测试，又包含对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。测试方法一般采用黑盒测试法。

测试开发需要哪些知识？具备哪些能力？

需要的知识：

软件测试基础理论知识，如黑盒测试、白盒测试等；
编程语言基础，如 C/C++、Java、Python 等；
自动化测试工具，如 Selenium、Appium 等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试框架，如 JUnit、Pytest、Unittest 等。

具备的能力：

业务分析能力、缺陷洞察能力、团队协作能力、专业技术能力、逻辑思考能力、问题解决能力、沟通表达能力和宏观把控能力。

请说一下手动测试与自动化测试的优缺点

手工测试的优点：

测试人员具有经验和对错误的猜测能力。
测试人员具有审美能力和心理体验。
测试人员具有是非判断和逻辑推理能力。

手工测试的缺点：

重复的手工回归测试，代价昂贵、容易出错。
依赖于软件测试人员的能力。

自动化测试的优点：

对程序的回归测试更方便。
可以运行更多更繁琐的测试。
可以执行一些手工测试困难或不可能进行的测试。
更好地利用资源。
测试具有一致性和可重复性。
测试的复用性。
增加软件的信任度。

自动化测试的缺点：

不能完全取代手工测试。
初期投入较高，需要搭建框架、编写脚本和维护环境。
对需求稳定性、环境稳定性和可测试性有要求。
UI 自动化在界面频繁变化时较脆弱，维护成本较高。
对探索性测试、体验类问题和临时复杂场景支持不如手工测试灵活。
工具本身不会思考，场景设计和结果判断仍依赖人。

自动化测试的定义、前提条件、适用的测试类型

定义：

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

前提条件：

实施自动化测试之前需要对软件开发过程进行分析，以判断其是否适合使用自动化测试。通常在以下条件下更适合推进自动化测试：

软件需求变动不频繁。 测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架。如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
项目周期足够长。 由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
自动化测试脚本可重复使用。 如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

适用的测试类型：

单元测试：验证独立函数、类或模块的正确性。常用框架有 Java 的 JUnit、TestNG，以及 Python 的 unittest、pytest 等。一般由开发人员编写测试代码。
集成/接口测试：验证模块之间或系统之间的交互是否正确。这个阶段很适合做接口自动化测试，也可以根据需要补充 UI 自动化测试。
回归测试：验证原有正常功能在修改后是否仍然保持正常。目标是发现变更是否在未修改区域引入了新的缺陷，或暴露了原本潜在的问题。单元测试、集成测试、系统测试甚至验收测试中的既有用例，都可以成为回归测试的一部分。
功能测试：验证系统是否满足功能需求。
性能/压力测试：验证系统在预期负载或高压力下的表现。
稳定性巡检：定时运行关键链路检查线上核心功能是否正常。
用户验收测试（UAT）：一般在项目后期进行，由产品、业务、客户代表或最终用户根据验收标准判断系统是否可以被接收。UAT 的核心是业务验收，不等同于 UI 测试；其中部分高频、稳定的验收场景可以用自动化辅助，但通常不会完全替代人工验收。

注意： 代码覆盖率统计通常作为自动化测试的辅助度量指标，不单独算一种测试类型。

自动化测试的运用场景举例

线上巡检（UI + 接口）
简单场景监控
稳定性测试（Monkey + 遍历测试）

软件测试的核心竞争力是什么？

早发现问题和发现别人无法发现的问题。

测试和开发要怎么结合才能使软件的质量得到更好的保障？

测试和开发可以参考 V 模型或 W 模型来协同。V 模型强调开发阶段与测试阶段一一对应；W 模型更强调测试前移，让需求、设计阶段就开始介入测试活动。在实际项目中，如果团队强调尽早发现问题，通常会更接近 W 模型或测试左移的做法。

V 模型：

开发活动与测试活动一一对应，通常体现为：用户需求对应验收测试，需求分析/系统设计对应系统测试，概要设计对应集成测试，详细设计对应单元测试，编码位于 V 字底部。它的优点是阶段清晰，缺点是很多测试执行活动仍集中在编码后。

W 模型：

在 V 模型基础上强调测试前移，测试不仅针对程序，也覆盖需求和设计文档。需求阶段就做需求评审，设计阶段就做设计评审，编码阶段再继续做单元、集成和系统测试。这样更有利于尽早发现问题，降低修复成本。

怎么实施自动化测试（过程）

首先判断项目适不适合进行自动化测试。
对项目做需求分析。
制定测试计划和测试方案。
搭建自动化测试框架。
设计或编写测试用例。
执行自动化测试。
评估测试效果。

测试的相关流程

按 W 模型：

需求评审/需求验证 → 概要设计评审 → 详细设计评审 → 单元测试 → 集成测试 → 系统测试 → 验收测试

工作中实际测试流程：

需求评审 → 技术评审 → case 评审 → 开发自测以及冒烟测试 → 整体提测（集成测试） → 回归测试 → 系统测试 → 验收测试

通用测试流程：

了解用户需求 → 制定测试计划（测试范围、人力物力、时间进度安排） → 编写测试用例 → 评审用例 → 搭建环境 → 冒烟测试 → 正式测试 → bug 管理 → 测试结束并输出报告（决定是否上线） → 版本上线 → 面向用户

测试项目具体工作是什么？

搭建测试环境
撰写测试用例
执行测试用例
写测试计划、测试报告
测试并提交 BUG
跟踪 BUG 修改情况
自动化测试
性能测试、压力测试、安全测试等其他测试

BUG 分级

常见会从两个维度去划分，不同公司和不同缺陷管理工具的定义可能略有差异。

按 BUG 严重程度划分等级：

blocker：系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，系统不稳定。常见的：严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、服务器 500 等。
critical：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统的稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错别字或拼写错误。
major：界面、性能缺陷、兼容性。常见的有：操作界面错误、边界条件错误、提示信息错误，长时间操作无法提示、系统未优化、兼容性问题。
minor/trivial：易用性及建议性的问题。

按 BUG 处理优先级划分：

immediate：马上解决
urgent：急需解决
high：高度重视，有时间马上解决
low：在系统发布前解决或确认可以不用解决

性能指标有哪些？

从外部看，主要有：

吞吐量：每秒钟系统能够处理的请求数、事务数或任务数
响应时间：服务处理一个请求或一个任务的耗时
错误率：一批请求中结果出错的请求所占比例

从服务器的角度看：

性能测试还会关注 CPU、内存、服务器负载、网络、磁盘 IO 等资源指标。

常用的压测和监控工具可以根据项目选择，如 JMeter、Locust、Gatling，以及各类云监控/APM 工具。

APP 性能指标有哪些？

内存、CPU、流量、电量、启动速度、页面渲染/滑动流畅度、界面切换速度，以及与服务器交互时的网络耗时和稳定性。

APP 测试工具有哪些？

接口测试：Postman
性能测试：JMeter
抓包工具：Charles、Fiddler
UI 自动化：UIAutomator2、Appium、ATX
稳定性测试：Monkey、Maxim、UICrawler、AppCrawler
兼容性测试：WeTest、Testin
内存/CPU/电量测试：GT、SoloPi
弱网测试：Charles、系统弱网工具

BUG 的生命周期

不同公司的缺陷生命周期不完全一样，下面是常见版本。

复杂版：

New（新的）
Assigned（已指派）
Open（打开的）
Fixed / Resolved（已修复）
Pending Retest（待复测）
Retest（复测）
Closed（已关闭）
Reopen（再次打开）
Rejected（被拒绝的）
Postponed（延期）

简单版：

创建 bug
分配 bug
修复完待测试
关闭
重新开启
无效

什么是 α 测试和 β 测试？

α 测试：在开发者可控的环境下进行，通常由潜在用户、客户代表或独立测试人员在开发现场参与测试，常作为内部验收测试的一种形式。
β 测试：在开发者不可控或较少干预的真实使用环境下进行，由真实用户或客户使用系统并反馈问题，常作为外部验收或市场反馈的一部分。

谈谈对敏捷的理解

四种开发模型：

瀑布式开发：从制定计划 → 需求分析 → 系统设计 → 编码 → 测试 → 提交到运维的流程，要求每一个开发阶段都要做到最好。
迭代式开发：不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间、最少的损失先完成一个”不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个”不完美的成果物”上逐步进行完善。
螺旋开发：很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发：相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

敏捷测试：

敏捷开发也对应着有敏捷测试，测试环节贯穿整个迭代周期，从需求评审到发布上线，都离不开测试快速跟进。

测试左移：需求评审、用例设计、自测工具、静态代码扫描等；
测试中：业务测试，接口测试，性能测试等；
测试右移：稳定性测试，回归测试，灰度测试等。

什么是压力测试？压力测试需要考虑哪些因素？

压力测试是一种性能测试，重点是在接近或超过系统预期负载上限、或在资源受限的条件下运行系统，观其稳定性、错误率、性能瓶颈和恢复能力。常见场景包括高并发、大数据量、资源受限、长时间运行等。

在做压力测试时，一般要考虑环境因素、压测模型、性能指标、运行时间等要素。

压测环境：最好尽量接近生产环境；如果必须在生产环境压测，要控制时间窗口、做好数据隔离，并避免影响真实用户。
压测模型：需要明确并发用户数、QPS、数据量、持续时间、升压方式等。
性能指标：通常包括响应时间、吞吐量、错误率，以及 CPU、内存、网络流量等资源指标。
运行时间：压测往往需要持续一段时间，便于观察性能拐点、资源泄漏和系统恢复情况。

Web 测试和 APP 测试的不同？

系统架构方面：

Web 项目通常是 B/S 架构，依赖浏览器；App 项目通常是 C/S 架构，需要安装客户端。
Web 发布一般以服务端和前端静态资源发布为主；App 除服务端外，还可能涉及客户端发版、应用商店审核、升级和兼容旧版本。

性能方面：

Web 端通常关注页面响应时间、首屏时间、接口耗时、浏览器资源占用等。
App 除响应时间外，还要重点关注启动速度、流量、电量、CPU、内存、FPS/卡顿、前后台切换等移动端指标。

兼容方面：

Web 重点关注不同浏览器、浏览器版本、操作系统、分辨率下的兼容性。
App 重点关注不同机型、系统版本、屏幕尺寸、厂商 ROM、权限和网络环境下的兼容性。

其他方面：

Web 一般不涉及安装卸载，但要关注缓存、刷新、回退、多标签页、版本覆盖等问题。
App 需要重点测试安装、更新、卸载，以及异常中断、弱网、来电、前后台切换、推送、权限、适配等移动端专项场景。

Lonestar's 知识库

探索