3.需求分析与测试用例设计方法-海口c网

设计方法

测试点

定义: 测试时需要考虑的可测试方面，不同公司可能称为"检查点"或其它名称
特点: 是需求分析的最后一个环节，用于解决"测哪里"和"怎么测"的问题
举例说明: 如同打架时的各种招数，如直接约架、设陷阱或雇人打群架，每种方法对应一个测试点
与用例关系: 简单的功能（如"退出"按钮）可直接从测试点转化为用例（如"点击退出看软件能否退出"）

场景法概述

核心作用: 主要用于测试系统的业务流程，验证主要功能是否正确实现
测试时机: 拿到测试任务时应首先关注业务流程验证
与其他方法关系: 区别于大纲法的功能拆分作用，属于用例设计方法
方法分类: 属于黑盒测试方法，与等价类、边界值、决策表等方法并列

场景的定义
基本概念: 描述软件操作的路径（先干什么再干什么）
组成要素:
基本流: 正确的业务流程构成的操作路径（模拟正确操作）
备选流: 导致程序出错的操作流程（模拟错误操作）
应用特点: 与业务流程分析相似但不完全相同，更侧重操作路径的模拟
4. 场景法的分析步骤
第一步: 分析软件需求，从用户角度梳理业务流程和业务规则
第二步: 编写基本流场景（正确流程）和备选流场景（错误流程）
实施要点: 需同时考虑正向和反向测试路径，覆盖正常和异常操作
方法论定位: 属于用例设计的大方向规划，不过多涉及细节实现

场景法的分析步骤

分析软件需求: 首先，需要全面分析软件的需求，明确软件要实现的业务流程和业务规则。这是场景法分析的第一步，也是非常重要的一步，因为后续的所有步骤都基于这一步的理解。
写出业务流程和业务规则: 从用户使用情景的角度出发，详细写出软件的业务流程和业务规则。这有助于我们更深入地理解软件的使用场景，为后续的测试设计打下基础。
写出基本流场景和备选流场景: 在明确了业务流程和业务规则后，我们需要写出基本流场景和备选流场景。基本流场景是软件在正常情况下的操作流程，而备选流场景则是软件在异常情况或特殊情况下的操作流程。通过这一步，我们可以更全面地覆盖软件的测试点，提高测试的质量。

描述程序的基本流及备选流

流程步骤：
- 插入银行卡：客户将银行卡插入ATM机的读卡器
- 验证银行卡：ATM机从银行卡的磁条中读取账户代码，检查是否属于可接受的银行卡
- 输入密码：ATM机要求客户输入密码
- 验证密码：系统验证密码是否正确
- 进入主界面：ATM显示可用操作选项
- 选择取款：客户选择"取款"功能并输入金额
- 系统验证：检查账户余额是否充足、总取款金额是否超限、ATM机现金是否足够
- 完成交易：验证通过后更新账户余额，出钞并提示用户取款
关键特征：
- 只包含正常操作路径，不考虑任何异常情况
- 每个步骤都假设输入正确且系统状态正常
- 流程设计应聚焦软件相关操作，排除无关行为（如"步行找ATM机"）

备选流

错误类型及处理：
- 银行卡无效：系统提示错误信息并退卡
- 密码错误：
  - 1-2次错误：提示重新输入
  - 3次错误：直接吞卡（需单独列为不同备选流）
- 账户余额不足：提示错误并退卡
- 超额取款：当日取款总额超限时提示错误并退卡
- ATM现金不足：提示错误并退卡
设计要点：
- 每个异常情况应作为独立备选流处理
- 相同错误类型但处理方式不同（如密码错误次数）需区分
- 结果描述应具体明确（如"吞卡"与"退卡"的区别）

根据基本流和备选流生成不同的场景

场景生成原则：通过分析基本流（正确流程）和备选流（错误流程）来构建测试场景，正确情况通常只有一种，而错误情况可能有多种
表格使用说明：场景分析表格可记录在测试需求分析说明书中作为测试点，表格形式不重要，重点在于明确场景条件和预期结果
有效标识含义：表格中的"V"代表valid（有效），表示该条件需满足正确值，但非必须标注项

场景法练习

三角形类别判断

1. 例题

1）题目描述

题目: 输入三个数，判断它们能否构成三角形，以及若能构成，则进一步判断是什么类型的三角形。

2）题目解析

审题过程:
- 首先，检查输入的三个数是否均为0-1000的实数。
- 然后，判断三边之和是否大于第三边，若不满足，则不能构成三角形。
- 接着，判断三边是否都相等，若是，则为等边三角形。
- 再判断两边是否相等，若是，则为等腰三角形。
- 判断两边平方和是否等于第三边平方，若是，则为直角三角形。
- 若以上条件都不满足，则为普通三角形。
易错点:
- 输入数据不完整或不是实数时，需要提示必须输入实数。
- 输入范围超过0-1000，或小数位数超过三位时，需要报错。
- 注意区分不同类型的三角形判断条件。

等价类划分法

等价类划分核心思想

代表选择原理：类似于人民代表大会制度，将输入数据划分为若干区域后，每个区域选取代表性数据，该数据能等价代表该区域所有数据。
分类基础：根据需求分析将输入域划分为有效等价类（符合需求规范）和无效等价类（违反需求规范）。
测试效率提升：通过代表数据减少测试用例数量，解决穷尽测试不可行的问题，如两位数加法器中测试负99到99的范围时无需测试所有值。

等价类划分的步骤

第一步需求分析：明确被测对象的功能需求，如两位数加法器要求输入范围为−99-99−99到999999的整数。
第二步初步分类：
- 有效等价类：符合输入要求的数据（如000、505050）
- 无效等价类：超出范围或格式错误的数据（如−100-100−100、100.5100.5100.5）
第三步细化分类：结合计算机知识进一步细分，例如：
- 边界值附近单独分类（−99-99−99、999999）
- 特殊字符输入单独分类（如"ab"）
代表值选取原则：每个等价类中选取最能体现该类特征的数据，如无效类中选取−100-100−100代表"小于−99-99−99"的无效情况。

等价类划分练习

需求讲解

核心需求：ATM取款功能测试，要求单笔取款金额最少50元，最多5000元，且必须是50的倍数
特殊说明：案例假设不考虑日累计限额（如现实中的2000元限制），仅测试单笔交易场景。

有效等价类划分
唯一有效类：金额在区间内且为50的倍数的数值（如50、100、4950、5000）
测试要点：只需设计1个测试用例即可覆盖全部有效情况，例如测试取款2500元
3. 无效等价类划分
数值范围违规：
小于下限：的值（如0、49）
大于上限：的值（如5001、10000）
倍数违规：非50倍数的数值（如51、4999）
特殊输入：
空输入（直接点击取款）
字符输入（需确认ATM键盘是否存在字母键）
设备适配原则：若实际ATM键盘无字母键，则字符输入类可不测试

等价类划分注意事项

考虑有效和无效等价类

测试方向：
- 正向测试（有效等价类）：验证功能正常工作情况
- 负向测试（无效等价类）：验证异常处理能力
数量比例：无效类用例通常远多于有效类，比例可能达1:8甚至更高
术语对照：
- 有效等价类 ≈ 正向用例 ≈ 顺向测试
- 无效等价类 ≈ 负向用例 ≈ 逆向测试

2. 注意划分的粗细

过粗风险：
- 将本应分开的类合并（如将空输入和字符输入合并）
- 导致测试遗漏（如漏测边界值4999）
过细风险：
- 过度拆分同类项（如分别测试大写A和小写a）
- 产生冗余测试（如测试200后又测试300）
实践建议：
- 初学者宜稍细划分，避免遗漏缺陷
- 经验积累后可优化分类粒度
审查要点：需检查划分是否覆盖所有需求约束条件（范围、倍数、输入类型等）

例题:等价类划分法应用

有效等价类：输入长度为4-10位字符
无效等价类：
- 长度小于4位
- 长度大于10位
划分依据：根据输入长度要求直接划分，保持每个等价类内部具有相同测试特性

布尔类型等价类划分

有效等价类：
- true（注意大小写要求）
- false（注意大小写要求）
无效等价类：除true/false外的所有输入
注意事项：
- 需确认编程语言对大小写的敏感性
- 若要求大写，则有效类应调整为TRUE/FALSE
- 无效类可适当扩充包含大小写混合情况

例题:组合框等价类划分

有效等价类：
- 从下拉列表选择现有字体
- 手动输入存在的字体名称
无效等价类：输入不存在的字体名称
测试要点：组合框同时支持选择和输入的特性需要分别验证

例题:用户名规范等价类划分 02:40

有效等价类：
- 纯字母组合（长度≤12）
- 字母开头+数字组合（长度≤12）
无效等价类：
- 数字开头
- 长度>12
- 空输入（长度=0）
- 包含特殊字符
复杂需求分析：
- 必须字母开头是核心约束条件
- 长度限制和字符类型限制需要组合验证
- 可合并有效类为"字母开头+字母数字组合"

例题:日期文本框等价类划分

有效等价类（假设需求）：
- 当前/将来日期+"/"分隔符
- 当前/将来日期+"-"分隔符
- 当前/将来日期+无分隔符
无效等价类：
- 过去日期（范围错误）
- 错误分隔符（如空格、字母）
- 日期顺序错误（如月日年）
- 包含非数字字符
- 包含不允许的标点（如点号）
- 非法日期值（如2月30日）
- 世纪数省略（如18代替2018）
测试设计技巧：
- 需明确日期格式要求（年月日/月日年）
- 考虑不同地区的日期表示习惯
- 边界值需结合等价类共同使用
- 无效类可衍生多种测试用例

边界值分析法

标题字数： 0 1 40 41

标题字数 0 40 41 -1不具有可测性！

文本输入域 0 1 255 256

分页，首页点上一页，尾页点上一页，进行边界值测试

决策表

输入组合盲区：等价类划分、边界值等传统测试方法未考虑输入参数的组合情况，例如第一个数输入正数、第二个数输入负数的组合场景。

决策表练习

输入输出分析：
- 输入1：工资制（年薪/月薪）
- 输入2：错误类型（4种情况）
- 输出：扣款比例（计算结果）
必须穷举所有可能组合（年薪×4种错误情况 + 月薪×4种错误情况）
- 年薪制组合：
  - 不犯错误：0%
  - 仅普通：2%
  - 仅严重：6%
  - 两种都犯：8%（2%+6%）
- 月薪制组合：
  - 不犯错误：0%
  - 仅普通：4%
  - 仅严重：8%
  - 两种都犯：12%（4%+8%）

决策表适用范围

决策表一般适用于多种输入存在组合的情况。当存在多个输入，且这些输入之间有各种组合情况时，适合使用决策表。

局限性: 决策表可能导致用例数量爆炸。因为每个输入可能有多种情况，当输入数量增多时，组合情况会呈指数级增长，导致用例数量庞大。

实现均匀覆盖策略

无效等价类应用

需求分析的步骤

收集文档: 需求分析的第一步是收集相关的文档资料。
研读文档: 在收集完文档后，需要仔细研读这些文档，理解其中的内容和要求。
提出问题: 在研读文档的过程中，会产生很多疑问或不明确的地方，需要将这些问题提出来。
整理信息: 将提出的问题以及从文档中获取的信息进行整理，以便后续使用。
功能拆分: 将软件需要实现的所有功能进行拆分，包括大功能和小功能。
信息合并: 将之前整理的信息与功能拆分的结果进行合并，形成完整的需求理解。
编写测试点: 根据需求理解，编写测试点，用于后续的测试工作。测试点可以综合使用场景法、等价类边界值、决策表和错误猜测等方法进行编写。
需求评审: 需求分析的最后一步是进行评审，确保需求理解的准确性和完整性。

需求评审的质量要求

正确性: 需求必须与用户说法一致，确保没有错误的需求描述。
完备性: 需求必须完整无遗漏，避免出现需求缺失的情况。
易理解性: 需求文档要让其他部门和测试人员都能轻松理解，表述必须清晰明确。
一致性: 需求前后描述要一致，不同部门间的理解也要保持一致，避免出现矛盾。
可行性: 需求必须实际可行，如测试资源不足时要及时调整需求（例如公司只有一个路由器时不应影响正常业务）。
可修改性: 需求之间应保持适当关联，修改一个需求时不应导致其他需求大面积受影响。
可测试性: 每个测试点都必须具备可执行性，这是最基本的要求。
可追溯性: 所有需求和测试点都要有明确依据，不能凭空猜测或不合情理。

测试计划

测试计划的定义与原则

文档性质: 测试计划是指导测试过程的纲领性文档，用于统一团队认识并规划测试过程
核心功能: 规定测试范围、途径、资源和进度安排，确认测试项、被测特征、测试任务、人员安排及风险预案
IEEE定义: 叙述预定测试活动的范围、途径、资源及进度安排的文档（1983年标准）
实际作用: 避免测试工作无序进行，明确各阶段任务（如需求分析时长、测试顺序等）

测试计划的编写原则

明确测试的目标，增强测试计划的实用性
核心原则：测试计划不是形式文档，而是后续测试工作的指导依据，必须注重实际可操作性
指导性：测试工作的每一步都将按照计划执行，因此计划内容必须清晰明确
目标导向：需要清楚界定测试的具体要求和预期目标

坚持"5W"规则，明确内容与过程

What(内容)：明确测试范围，如测试登录功能还是注册功能
Why(目标)：确定测试类型，如功能测试、性能测试或可用性测试
When(时机)：既指测试进度安排，也包含测试环境等前提条件准备
Where(环境)：详细说明所需的硬件、软件配置要求
How(方法)：规定测试采用的技术方法，如黑盒/白盒测试
Who(人员)：可额外增加的人员安排说明，实际工作中常与When合并考虑

测试计划的主要内容

确定测试资源: 明确所需的人力资源、硬件资源和软件资源。
工作量估算、里程碑和进度安排: 评估测试工作量，设定关键节点和整体时间表。
风险分析: 识别测试过程中可能遇到的风险，并制定相应的应对措施。
制定测试策略: 根据测试需求和目标，选择合适的测试方法和技术。
编写计划书: 将上述内容整合成文档，作为测试工作的指导和依据。

风险识别

风险评估和风险控制

测试策略

测试策略定义: 测试策略是描述当前测试项目的目标，以及所采用的测试方法。它宏观地概述了测试的内容、方法、阶段和类型。
包含内容:
- 测试目标和方法。
- 规定时间内要完成的测试内容。
- 软件产品的特性或质量在哪些方面得到确认。
- 不同测试阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法。
- 每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）。

分阶段的测试策略

分阶段策略: 将测试分为多个阶段，如单元测试、集成测试、系统测试等。
单元测试: 早期发现问题，保证代码质量。
集成测试: 尽早地发现更多问题，准备自动化测试的BVT（Build Verification Test）。
系统测试: 验证整个软件系统的功能和性能。
优点: 能够在早期发现问题，减少后期修复成本。
BVT（Build Verification Test）:
- 目的: 验证最新软件版本的功能是否完整，主要软件特性是否正确实现。
- 优点: 时间短，快速反馈问题。
- 缺点: 覆盖率较低，不能替代全面的测试。
不能忽略的测试: 安全性测试、可用性测试、配置测试和数据完整性测试。
制定更为详细的UAT（用户验收测试）计划
UAT测试计划:
与测试脚本和培训材料一起提供给用户。
帮助用户快速提高并完成任务。
包含内容:
详细的测试步骤。
用户验收的标准和流程。
培训材料和用户指导。