软件测试(二)

测试用例

什么是测试用例：

• 测试⽤例（Test Case）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

设计测试用例：一般为功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试。

• 功能测试：功能测试是⼀个试图发现程序与其外部规格说明书之间存在不⼀致的过程。外部规格说明书是⼀份从最终用户的⻆度对程序⾏为的精确描述。功能测试通常是⼀项黑盒操作。
• 界⾯测试：对软件界⾯上所有的内容都需要进行测试。要求整体界面测试界面的实现与设计图要求⼀致。
• 性能测试：性能测试和功能测试的区别是：功能测试检查软件是否做了，⽽性能测试测试软件做的好不好。
• 兼容性测试：软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动端打开；移动端⼜分为IOS系统和Android系统，且市⾯上⼿机⼜有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运⾏需要测试⼈员进行验证。
• 易⽤性测试：易⽤性测试的标准是检查产品是否具备简单易上手的属性。假如测试⼈员从来没有安装或使⽤过该产品，作为⼀个新用户，对当前产品是否能够快速适⽤产品的使⽤流程。
• 安全测试：安全测试和性能测试⼀样都是⽐较⼤的领域。常⻅的安全问题如：隐私数据明⽂显⽰；参数未强校验导致SQL注⼊；越权：普通用户也可以执⾏管理员权限的操作。
• 除了上面常用的测试方法，还有弱网测试和安装卸载测试。
• 弱网测试推荐使用fiddler抓包工具。配置步骤如下：

设计方法

等价类：

• 是一种非常经典的黑盒测试技术
• 核心思想：依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
• 等价类的两大分类：
• 有效等价类（Valid Equivalence Class）：
  • 符合程序规格说明、合理的输入数据集合。
  • 用于验证程序是否实现了它应该做的功能。
• 无效等价类（Invalid Equivalence Class）：
  • 不符合规格说明、不合理或非法的输入。
  • 用于验证程序的容错性和健壮性，确保程序不会因为错误输入而崩溃。

边界值：

• 边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法，是对等价类划分法的补充。它不是从等价类中随便挑一个典型值，而是专门盯着等价类的边缘进行测试。
• 边界值包含：边界值+次边界值
• 通常我们关注以下五个点：最小值（Min）、略大于最小值（Min+）、正常值（Nominal）、略小于最大值（Max-）、最大值（Max）
• 因此等价类往往和“边界值”一起用

正交法：

• 正交法是利用数学上的“正交表”来安排测试。它的核心特质是：均匀分散、齐整可比。 简单来说，它保证了：任意一列中，每个状态出现的次数一样多。任意两列中，所有可能的组合都出现过，且次数一样多。
• 这意味着你不需要测遍所有组合，只需要测这些“均匀分布”的点，就能发现大部分由于多个参数交互引起的Bug。
• 正交表的三个要素正交表通常用符号\(L_n(k^m)\)表示：
  • L：正交表的代号。
  • n（行数）：需要进行的测试用例个数。
  • k（水平数）：每个因素下的不同取值个数。
  • m（因素数）：变量的个数（即有多少个输入框/配置项）。
• 正交法的操作步骤:
  • 提取因素（Factor）：确定有哪些输入变量。
  • 确定水平（Level）：每个变量有哪些取值（等价类）。
  • 选择正交表：根据因素数和水平数去查标准的正交表工具（通常有现成的对照表）。如果找不到完全匹配的，选一个稍微大一点的再进行裁剪。
  • 变量映射：把实际的测试值填入表中的 1, 2, 3 占位符。
  • 编写用例：每一行就是一条测试用例。
• 推荐使用allpairs工具来生成正交表。

判定表法：

• 当输入条件（原因）之间存在复杂的逻辑依赖或组合关系，且不同的组合会触发不同的动作（结果）时，等价类和边界值就不够用了。这时我们需要使用判定表法（Decision Table Testing）。
• 判定表是最严谨、最能逻辑覆盖的一种黑盒测试方法。
• 判定表的四个组成部分：
  • 条件桩（Condition Stub）：列出问题的所有输入条件。
  • 动作桩（Action Stub）：列出程序可能采取的所有操作/结果。
  • 条件项（Condition Entry）：列出针对条件的各种取值组合（通常用 Y/N 或 T/F 表示）。
  • 动作项（Action Entry）：列出在某种条件组合下，对应的动作是否发生。
• 判定表的设计步骤：
  • 判定表的设计步骤确定原因和结果：找出所有的输入条件和输出动作。
  • 计算规则数量：如果有n个条件，每个条件有两种取值（是/否），那么组合数就是 \(2^n\)。
  • 填入条件组合：穷举所有可能的 Y/N 组合。
  • 填入动作：根据业务逻辑，确定每种组合对应的结果。
  • 简化判定表：如果某些条件的取值不影响最终动作，可以进行合并。
• 案例：欠费停机逻辑。需求：如果用户欠费（条件1）且 未办理延时缴费服务（条件2），则执行停机（结果）；否则不予停机。
  初始判定表

组成部分	因素/动作	规则1	规则 2	规则 3	规则 4
条件桩	是否欠费	Y	Y	N	N
	是否办理延时	Y	N	Y	N
动作桩	执行停机		X
	维持正常状态	X		X	X

判定表的简化（合并）

• 在上面的例子中，我们发现：只要“是否欠费”为 N（不欠费），无论“是否办理延时”是 Y 还是 N，结果都是“维持正常状态”。用 - 表示“无关紧要”：

因素/动作	规则 1	规则 2	规则 3/4
是否欠费	Y	Y	N
是否办理延时	Y	N	-
结果	正常	停机	正常

场景法：

• 现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流。通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。
• 是一种基于业务流程的黑盒测试技术。
• 基本流与备选流
  基本流（Main Flow / Happy Path）：
  • 用户最常用、最顺利的一条完整业务路径。
  • 没有任何错误发生，一路通关，最终达到目标。
    备选流（Alternative Flow）：
  • 在基本流基础上分叉出来的路径。
  • 可能是由于错误输入触发（例如密码错误），也可能是由于特殊业务选择触发（例如余额不足）。

错误猜测法：

• 错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽针对性地设计测试⽤例的⽅法。
• 这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。
• 错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产出比很⾼，被⼴泛应⽤于测试。

---

测试分类

为什么要对软件测试进⾏分类

• 软件测试是软件⽣命周期中的⼀个重要环节，具有较⾼的复杂性，对于软件测试，可以从不同的⻆度加以分类，使开发者在软件开发过程中的不同层次、不同阶段对测试⼯作进⾏更好的执行和管理测试的分类⽅法。

按照测试⽬标分类

界⾯测试（简称UI测试)：

• 指按照界⾯的需求（⼀般是UI设计稿）和界⾯的设计规则，对我们软件界⾯所展⽰的全部内容进⾏测试和检查，⼀般包括如下内容：
  • 验证界⾯内容显⽰的完整性，⼀致性，准确性，友好性。⽐如界⾯内容对屏幕⼤⼩的⾃适应，换⾏，内容是否全部清晰展⽰；
  • 验证整个界⾯布局和排版是否合理，不同板块字体的设计，图⽚的展⽰是否符合需求；
  • 对界⾯不同控件的测试，⽐如，对话框，⽂本框，滚动条，选项按钮等是否可以正常使⽤，有效和⽆效的状态是否设计合理；
  • 界⾯的布局和⾊调符合当下时事的发展。

功能测试：

• 功能测试就是对产品的各功能进⾏验证，根据功能测试⽤例，逐项测试，检查产品是否达到用户要求的功能。
• 如何进⾏功能测试---设计功能测试⽤例，参考产品规格说明书进⾏⽤例的编写，具体的测试⽤例需要使⽤⿊盒设计测试⽤例的⽅法，如等价类、边界值、判定表法、正交法、场景法、错误猜测法等。
• 性能测试的核心指标：
  • 响应时间 (Response Time)：从用户发送请求到收到服务器响应的时间。
  • 并发用户数 (Concurrent Users)：同一时刻与服务器进行交互的用户数量。
  • 吞吐量 (Throughput / TPS)：系统每秒处理的事务数量。这是衡量服务器处理能力的关键指标。
  • 资源利用率：系统在高负载下对 CPU、内存、磁盘 I/O 和网络带宽的占用情况。

可靠性测试：

• 可靠性（Availability）即可⽤性，是指系统正常运⾏的能⼒或者程度，⼀般⽤正常向用户提供软件服务的时间占总时间的百分⽐表⽰。
• 可⽤性指标⼀般要求达到4个或5个“9”，即99.99%或者99.999%

安全性测试

• 安全性是指信息安全，是指计算机系统或⽹络保护用户数据隐私，完整，保护数据正常传输和抵御⿊客，病毒攻击的能⼒。
• 安全性测试属于⾮功能性测试很重要的⼀个⽅⾯，系统常⻅的安全漏洞和威胁如下：
  • 输⼊域，如输⼊恶性或者带有病毒的脚本或⻓字符串；
  • 代码中的安全性问题，如SQL/XML注⼊
  • 不安全的数据存储或者传递
  • 数据⽂件，邮件⽂件，系统配置⽂件等⾥⾯有危害系统的信息或者数据；
  • 有问题的访问控制，权限分配等
  • 假冒ID：⾝份欺骗
  • 篡改，对数据的恶意修改，破坏数据的完整性

易⽤性测试：

• 易⽤性包含七个要素：符合标准和规范，直观性，⼀致性，灵活性，舒适性，正确性和实⽤性。

按照执行方式分类

静态测试：

• 所谓静态测试（static testing）就是不实际运⾏被测软件，⽽只是静态地检查程序代码、界⾯或⽂档中可能存在的错误的过程。
• 不以测试数据的执⾏⽽是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码⻛格和规格等来检查程序的正确性。
• 常⻅的静态测试⽅式有代码⾛查，代码扫描⼯具等。

动态测试：

• 动态测试（dynamic testing），指的是实际运⾏被测程序，输⼊相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断⼀个测试属于动态测试还是静态的，唯⼀的标准就是看是否运⾏程序。
• ⼤多数软件测试⼯作都属于动态测试
• 动态测试的三大要素：输入 (Input) + 运行 (Execution) + 比较 (Comparison)
  • 输入：使用等价类、边界值等方法设计的测试数据。
  • 运行：在特定的测试环境下启动软件执行操作。
  • 比较：将软件输出的“实际结果”与需求文档中的“预期结果”进行比对。

按照测试方法

白盒测试（White-Box Testing）

• 白盒测试⼜称为结构测试或逻辑测试，它⼀般⽤来分析程序的内部结构，针对程序的逻辑结构来设计测试⽤例进⾏测试。
• 白盒测试的测试⽬的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进⾏覆盖测试；在程序不同地⽅设⽴检查点，检查程序的状态，以确定实际运⾏状态与预期状态是否⼀致。
• 白盒测试主要分为静态测试和动态测试两种。
  • 静态测试常⻅于桌⾯检查、代码审查、代码⾛查、代码扫描⼯具
  • 动态测试⽅法主要包含六种测试⽅法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
• 白盒测试主要应⽤于软件开发单元测试阶段（早期阶段）

黑盒测试

• 黑盒测试（Black-Box Testing），也被称为功能测试或数据驱动测试，是软件测试中最直观的一种方法。
• 核心理念是：将程序看作一个不能打开的黑盒子。测试人员完全不关心程序内部的代码结构和运行逻辑，只根据需求规格说明书，通过输入数据并观察输出结果来验证功能是否正确。
• 黑盒测试关注的问题：
  • 功能缺失或错误：程序是否漏掉了需求中的功能，或者实现得不对。
  • 界面错误：按钮、排版、文字显示是否美观且符合规范。
  • 数据结构或外部数据库访问错误：数据存取是否准确。
  • 性能问题：系统处理请求的速度是否达标。
  • 初始化和终止错误：程序启动和关闭时是否正常。

灰盒测试（Gray-Box Testing）

• 灰盒测试（Gray-Box Testing）是一种介于白盒测试与黑盒测试之间的测试方法。
• 灰盒测试的核心定义：在灰盒测试中，测试人员不需要像白盒测试那样精通每一行代码，但需要了解系统的架构、数据库设计、API 接口定义以及数据的流转过程。
  • 黑盒视角：验证功能是否符合用户需求。
  • 白盒视角：查看内部组件如何交互。
  • 灰盒综合：输入数据后，不仅看前端结果，还要进数据库看数据存得对不对，进日志看有没有隐藏报错。
• 灰盒测试的主要关注点
  • 接口测试 (API Testing)：这是灰盒测试最典型的场景。测试人员根据接口文档（知道参数名、数据类型等内部约定）发送请求，检查返回的JSON或XML数据。
  • 端到端数据校验：在UI界面操作后，通过SQL查询后端数据库，确认数据的一致性和完整性。
  • 集成测试：检查不同模块（如订单模块和库存模块）之间的消息传递是否准确。
  • 日志分析：在执行功能路径时，观察服务器日志中是否有异常堆栈信息，即使前端显示“成功”。
• 灰盒 vs 黑盒 vs 白盒

维度	黑盒测试	灰盒测试	白盒测试
知识背景	仅需求文档	需求文档 + 架构/接口文档	源代码 + 内部设计
测试目标	用户功能验证	接口、集成、数据流	逻辑路径、语句覆盖
常用工具	浏览器、手机	"Postman, JMeter, SQL"	"JUnit, Pytest, SonarQube"
效率/成本	低成本、高速度	性价比最高（发现深层问题）	高成本、专业性极强