无文档情况下的测试
这是一个非常现实且常见的问题。在很多中小企业或敏捷团队中，正式的需求文档（PRD）确实可能缺失或不完善。但这并不意味着测试无法进行，反而对测试人员提出了更高的要求——从“需求验证者”转变为“需求挖掘者和质量共建者”。
在这种情况下，您可以遵循下图所示的策略来主动挖掘和分析测试点：
下面我们来详细解读图中的各种方法：
核心心态转变：从被动接受到主动共建
测试人员的角色：
- 需求澄清者：你的提问能帮助产品和开发理清思路。
- 信息整合者：将碎片化的信息拼凑成完整的需求图谱。
- 用户代言人：始终从用户角度思考功能的合理性和易用性。
一、沟通与提问：把嘴皮子磨破
这是最重要、最有效的方法。你需要主动去“要”信息。
- 直接与产品经理/负责人沟通：
- 问核心价值：“这个功能是为了解决用户的什么问题？”“目标用户是谁？”
- 问业务规则：“这个规则的边界情况是什么？比如满100减20，折扣商品参与吗？”
- 问异常流程：“如果用户支付到一半关闭了页面，订单应该是什么状态？”
- 直接与开发人员沟通：
- 阅读代码注释或Git提交信息：这常常包含了开发人员对功能的理解。
- 咨询设计逻辑：“这个功能是怎么实现的？”“有哪些关键参数或配置？”
- 理解代码变更范围：通过Git等版本控制工具看代码改动，了解影响范围。
二、利用一切现有资料：寻找“替代性文档”
虽然没有PRD，但总会有一些线索。
- UI设计稿或原型图：
- 仔细查看每个UI元素：每个按钮、输入框、链接、提示文字都是测试点。
- 对比设计与实现：开发出来的功能是否和设计稿一致？（这本身就是重要的测试点）。
- 用户故事或任务卡片：
- 即使在敏捷团队中，也会有简短的描述。仔细分析句子中的每一个名词和动词。
- 例如：“作为一个用户，我想通过手机号登录，以便快速进入系统。”
- 测试点分析：“手机号”（输入框格式校验、是否存在、是否绑定他人）、“登录”（按钮动作、成功后的跳转）、“快速”（性能要求？）。
- 竞品分析或旧版本功能：
- 如果是一个新功能，去看看类似的竞品是怎么做的，理解通用的业务逻辑。
- 如果是对旧功能的优化，那旧功能就是最好的需求文档。测试新功能时，必须考虑对旧功能的回归测试。
三、基于测试技术和方法：你的专业武器
当信息不全时，标准化的测试设计技术能帮你系统性地推导出测试点。
- 基础测试方法永不过时：
- 等价类划分与边界值分析：只要存在输入，就一定有有效和无效的类别，也一定有边界。这是最可靠的测试点来源。
- 状态迁移法：如果一个对象有状态（如订单：待支付、已支付、已发货），那么所有状态变化的路径都是测试点。
- 场景法：想象一个真实用户会如何操作，画出他的操作流程（正常流程、备选流程、异常流程）。
- 探索性测试：
- 这是无文档测试的利器！ 核心思想是测试学习、测试设计、测试执行并行。
- 具体做法：不要写详细的测试用例，而是设定一个“测试任务”（如：测试新用户注册流程）。然后一边操作，一边观察，一边思考，一边记录发现的问题和新的测试想法。这种方法能快速深入理解软件，发现大量隐蔽缺陷。
- 错误猜测：
- 依靠你的经验和直觉，预测哪些地方容易出问题。
- 常见雷区：数据加密、分页查询、多线程并发、文件上传下载、网络中断、缓存失效等。
四、实践流程建议
- 测试前：
- 尽可能多地收集信息（沟通、看原型、读代码）。
- 用思维导图快速列出你能想到的所有测试点和疑问。
- 拿着思维导图去找产品和开发确认，填补信息缺口。
- 测试中：
- 先进行一轮冒烟测试，确保主干功能通畅。
- 然后进行一轮探索性测试，深入理解系统并发现逻辑缺陷。
- 最后，根据探索的结果，再系统性地用等价类、边界值等方法补充测试，并记录下关键的测试场景，作为回归测试的依据。
- 测试后：
- 将你的测试点/用例补充到知识库（如Confluence、Wiki）。这次你“无文档”测试，但你的测试成果就是下一个测试人员最好的“文档”。这会形成一个良性循环。
总结
在中小企业无需求文档的情况下，测试点分析更像是一场侦探工作：通过主动沟通获取线索，利用现有资料寻找证据，最后运用专业的测试技术进行推理和验证。
这虽然充满挑战，但也是测试工程师提升业务理解能力、沟通协调能力和专业技术能力的绝佳机会。当你能够在这种环境下游刃有余时，你就成为一名非常优秀的测试工程师了。
测试用例编辑规划
Excel：xxx项目测试用例
| 用例ID | 模块|功能 | 用例标题 | 优先级 | 预置条件 | 操作步骤 | 预期结果 | 备注 | 设计人 | 测试结果 |
|---|---|---|---|---|---|---|---|---|---|
| 必须 | 必须 | 必须 | 必须 | 必须 | 必须 | ||||
| 用户管理_001 | 用户管理/登录 | 登录页面界面检查 | 低 | 检查界面对比原型图 | 与原图一致 | xxx | |||
| 用户管理_002 | 用户管理/登录 | 用户可编辑 | 中 | 用户名：admin | 用户名可编辑 |
用例ID：格式：模块_ID或者直接ID
模块|功能：一个项目有多个模块，一个模块有多个功能，一个功能对应一个多个测试点
用例标题：描述测试目的。参考格式：条件+动作+预期结果，不能重复，言简意赅。
优先级：表示方式：高中低；通过数字表示123
- 高：核心业务（冒烟用例）
- 中：一般流程，异常流程
- 低：界面，兼容性
预置条件：执行当前用例的前提条件。比如：测试登录成功，前置条件就是存在有效账户
操作步骤：
- 路径：页面1>页面2
- 输入什么数据
- 做了什么操作
预期结果：实际结果是什么
问题：
- 重复测试：如测试可编辑和测试登录就重复了
- 测试点和测试用例是一一对应吗：
- 测试数据可以随便编写吗
目的：
我们的目的是在最少的时间找到最多的bug
测试用例设计方法
等价类和边界值是测试用例设计中最基础、最核心的两种方法。它们经常被同时使用，是每一位测试工程师必须掌握的技能。
下面我将详细解释这两种方法，并补充其他重要的测试用例设计方法，形成一个完整的体系。
一、等价类划分法
1. 核心思想：
将程序的输入域划分为若干个子集合（等价类），认为同一等价类中的每个输入数据对揭露程序错误的能力是等效的。也就是说，如果这个集合中的一个输入数据能发现缺陷，那么其他的也能；如果一个不能，那么其他的也不能。
2. 为什么要用？
为了减少测试用例的数量，避免穷举测试，同时保证测试覆盖率。
3. 具体步骤：
- 划分有效等价类：满足程序输入要求的、合理的输入数据集合。主要用来验证程序是否实现了预期功能。
- 划分无效等价类：不满足程序输入要求的、不合理、非法的输入数据集合。主要用来验证程序的异常处理能力。
- 为每个等价类设计测试用例：
- 每个有效等价类可以设计一个用例（可以合并）。
- 每个无效等价类必须单独设计一个用例，因为程序可能一次只处理一个错误。
5. 实战案例： 测试一个“用户名”输入框，要求长度为3-10个字符。
- 有效等价类：长度在3-10之间的字符串（如 “abc”）。
- 无效等价类1：长度<3（如 “ab”）。
- 无效等价类2：长度>10（如 “abcdefghijk”）。
- 无效等价类3：输入为空（null）。
- 无效等价类4：输入特殊字符（如 “@#$”）。
二、边界值分析法
1. 核心思想：
大量的错误往往发生在输入或输出的边界上，而不是在输入范围的内部。因此，针对边界值及其附近的值进行测试，发现缺陷的概率会更高。
2. 为什么有效？
开发人员在编写代码时，经常在边界条件上犯错，例如在循环或条件判断中使用 >、>=、<、<=时容易混淆。
3. 边界值的取点规则（最常用的是“三值法”）：
对于任何一个边界，取边界点本身、刚刚超过边界点、刚刚低于边界点这三个值。
- 例如，假设输入范围是
[1, 100]（闭区间，包含1和100）- 上点：就是边界点本身，即
1和100。 - 离点：紧邻边界点外侧的点，即
0和101。 - 内点：范围内的任意一点，即
50。
- 上点：就是边界点本身，即
4. 实战案例（接上例）： 用户名长度要求 [3, 10]。
-
边界分析：
-
下边界：3
- 上点：3（如 “abc”）
- 离点：2（如 “ab”）
- 内点：5（如 “abcde”）
上边界：10
- 上点：10（如10个字符的字符串）
- 离点：11（如11个字符的字符串）
- 内点：7（如7个字符的字符串）
-
5. 等价类与边界值的结合使用：
在实际设计中，我们总是先划分等价类，再分析每个等价类的边界。上面的案例就是两者结合的完美体现。
三、其他重要的测试用例设计方法
为了让你有一个全面的了解，这里列出其他关键方法：
3. 判定表法
- 适用场景：存在多个输入条件，这些条件之间存在逻辑依赖关系，并且不同的组合会对应不同的输出结果。
- 核心思想：用表格形式列出所有可能的条件组合及其对应的动作（结果）。
- 案例：飞机票折扣规则，涉及身份（普通、儿童、会员）、舱位（经济、商务）、季节（淡、旺）等多个条件。
4. 因果图法
- 说明：是判定表法的前身，通过图形化（因果图）分析输入（因）和输出（果）之间的关系，再转换为判定表。现在更常用判定表。
5. 场景法
- 适用场景：适合测试业务流程或用户操作流程。
- 核心思想：基于用户使用场景来设计用例，尤其是不同流程路径的组合。
- 案例：测试“在线支付”功能，场景包括：
- 正常流：支付成功。
- 备选流1：支付密码错误 -> 重试 -> 成功。
- 备选流2：支付密码错误 -> 重试 -> 锁定。
- 异常流：支付过程中网络中断。
6. 状态迁移法
- 适用场景：测试那些具有明显状态变化的软件功能。
- 核心思想：找出所有的状态，以及触发状态迁移的事件和动作，设计用例覆盖所有的状态迁移路径。
- 案例：MP3播放器（状态：关机、待机、播放、暂停），电梯运行等。
7. 错误推测法
- 适用场景：依靠测试人员的经验、直觉和对系统的深入理解。
- 核心思想：猜测程序在哪些地方可能容易出错，并据此设计测试用例。
- 案例：测试文件上传功能，凭经验会测试：超大文件、0字节文件、文件名含特殊字符、重复上传同名文件等。
8. 探索性测试
- 说明：这不是一种具体的用例设计技术，而是一种测试风格。它强调在测试过程中同时进行学习、设计、执行，将测试者的智力思考与测试操作高度结合，常用于发现那些通过脚本无法发现的、隐蔽的缺陷。
总结与选择
| 方法 | 核心思想 | 适用场景 | 优点 |
|---|---|---|---|
| 等价类划分 | 同一类数据效果等效 | 有大量输入数据需要测试 | 大幅减少用例数量，避免穷举 |
| 边界值分析 | 错误常发生在边界 | 输入存在明确的边界（数字、范围） | 针对性强，发现缺陷效率高 |
| 判定表/因果图 | 分析输入条件组合 | 业务规则复杂，条件逻辑依赖强 | 能覆盖复杂的条件组合，避免遗漏 |
| 场景法 | 模拟用户真实操作流程 | 业务流程测试、功能交互测试 | 贴近用户，易理解 |
| 状态迁移法 | 覆盖所有状态变化路径 | 对象状态清晰的功能（如订单、工单） | 路径覆盖全面 |
最佳实践是组合使用这些方法：例如，先用场景法梳理主流程，再用等价类/边界值 设计具体字段的用例，对于复杂的业务规则使用判定表，最后依靠错误推测法进行补充。
BUG的管理流程
这是一个非常核心的软件测试话题。一个清晰、高效的Bug管理流程是保证软件质量和团队协作的基石。下面我将为您详细解析Bug的定义、生命周期和完整的管理流程。
一、Bug（缺陷）的定义
一个明确的Bug通常包含以下几个核心要素：
- 标题： 简短清晰地描述问题。例如：“在购物车页面，点击‘结算’按钮后页面无响应”。
- 前置条件： 执行操作前系统所处的状态。例如：“用户已登录，购物车中有至少一件商品”。
- 复现步骤： 详细、清晰、可重复的操作序列。这是最重要的部分。
- 例：1) 进入商品详情页 2) 点击“加入购物车” 3) 点击右上角购物车图标 4) 点击“结算”按钮。
- 预期结果： 按照需求，系统应该出现的行为。例如：“页面应跳转到订单确认页面”。
- 实际结果： 系统实际表现出的错误行为。例如：“页面无任何跳转，控制台报JavaScript错误”。
- 附件： 帮助定位问题的材料，如截图、屏幕录像、错误日志、接口返回数据等。
- 严重程度： Bug对系统功能的影响程度。
- 优先级： Bug需要被修复的紧急程度。
常见误区：严重程度 vs. 优先级
| 维度 | 定义 | 举例 |
|---|---|---|
| 严重程度 | 技术视角：Bug对软件功能的破坏程度。 | 致命：系统崩溃、数据丢失。 严重：主要功能失效。 一般：次要功能问题。 轻微：错别字、UI轻微错位。 |
| 优先级 | 业务视角：修复Bug的紧急和重要程度。 | 紧急：必须立即修复，否则阻塞开发或测试。 高：必须在当前版本修复。 中：可以在下个版本修复。 低：可以在有时间时修复。 |
关系：严重程度高的Bug优先级通常也高，但并非绝对。例如，一个错别字（严重程度-轻微）出现在公司Logo上，其优先级可能就是-高。
二、Bug的生命周期
Bug的生命周期指的是一个Bug从被发现到被关闭的整个过程中，所经历的一系列状态变化。下图清晰地展示了一个标准的Bug生命周期流程：
流程详解：
- 新建： 测试人员发现并提交一个Bug，状态为“新建”。
- 已打开/已分配： 测试负责人或开发负责人确认Bug有效，将其分配给相应的开发工程师，状态变为“已打开”或“已分配”。
- 已修复： 开发工程师修复Bug后，将状态改为“已修复”，并指派给测试人员。
- 待验证/待测试： 测试人员看到Bug状态为“已修复”后，准备进行回归测试。
- 验证未通过 -> 重新打开： 如果测试人员验证发现Bug没有完全修复，则将状态改为“重新打开”或直接打回给开发人员（流程上等同于回到“新建”或“已打开”状态）。
- 验证通过 -> 已关闭： 如果验证通过，测试人员将Bug状态改为“已关闭”。
- 拒绝： 如果开发人员认为不是Bug（如需求理解不同、无法复现等），可将状态改为“拒绝”。此时需要测试和开发进行沟通，若达成一致确非Bug，则关闭；若确为Bug，则重新打开。
三、完整的Bug管理流程
这不仅仅是状态流转，更是一个涉及团队协作的完整流程。
-
发现与报告：
- 测试人员（或开发、产品、用户）通过测试或使用发现Bug。
- 按照Bug定义的标准格式，在缺陷管理工具（如Jira、禅道、Tapd等）中清晰、准确地提交Bug报告。
-
分析与分配：
- 测试负责人/开发负责人对新建的Bug进行确认和初步分析。
- 根据Bug所属的功能模块，将其分配给相应的开发工程师。
-
修复与验证：
- 开发工程师收到Bug后，进行修复，并填写修复说明（如修复方式、影响范围）。
- 将状态改为“已修复”并指派给对应的测试人员。
- 测试人员在对应的测试环境中进行回归测试：
- 验证Bug是否已修复。
- 验证修复是否引入了新的问题。
-
跟踪与报告：
- 测试人员需要持续跟踪Bug的状态，直到其关闭。
- 测试负责人定期（如每日/每周）生成Bug报告，包括：Bug数量、严重等级分布、模块分布、趋势图、重新打开的Bug等，为项目决策提供数据支持。
-
关闭与归档：
- 验证通过的Bug被关闭。
- 整个版本的测试结束后，所有相关的Bug信息被归档，作为项目文档的一部分，用于后续复盘和经验积累。
总结
一个高效的Bug管理流程能确保：
- 问题可追溯： 每个Bug的来龙去脉都清晰可见。
- 责任到人： 每个环节都有明确的负责人。
- 流程规范： 团队协作有章可循，减少推诿和误解。
- 质量可视： 通过数据报告，让软件质量变得可衡量、可评估。
掌握Bug的管理流程、定义和生命周期，是成为一名专业测试工程师的关键一步。
、ISNULL()、NULLIF()函数用法说明)
)
