首页 思维导图 详情

测试用例编写方法

2023-07-07 11:13:25 2 举报
AI智能生成
测试用例编写方法
为你推荐
查看更多
直播测试用例
直播测试用例
[Model] 测试用例模板
[Model] 测试用例模板
接口测试用例设计
接口测试用例设计
测试用例模版
测试用例模版
网上测试用例
网上测试用例
测试用例编写思路
测试用例编写思路
新人如何编写测试用例
新人如何编写测试用例
测试用例框架-日程提醒
测试用例框架-日程提醒
测试用例
测试用例
如何写出漂亮的测试用例
如何写出漂亮的测试用例
测试用例编写方法是一种系统化、规范化的过程，用于验证软件或系统是否满足预定的需求和功能。首先，需要明确测试目标和范围，然后分析需求文档，提取关键功能点。接着，根据功能点编写详细的测试步骤，包括预期结果和实际结果。在编写过程中，要注意覆盖正常情况、异常情况以及边界条件。最后，对测试用例进行评审和优化，确保其完整性和有效性。通过这种方法，可以有效地提高测试的质量和效率，降低软件缺陷的风险。
测试用例
测试
作者其他创作
大纲/内容
•        必须有完整的功能列表
•        需求已经组织评审和澄清
•        必须有完整的需求文档
1.1 确定测试范围
http://note.youdao.com/noteshare?id=c77cb3cbbc603cff1063ab087e0ac4e4&sub=1C5241CAE82A4899A069D520C927AC31
•        遵循“边界值”全覆盖原则
文档：等价类分析法典型案例.note 链接：http://note.youdao.com/noteshare?id=45aef80cc624d4924b5d2a10622a2c35&sub=0563DE824DB84C7BAF851EB7C0D0FEE4
•        遵循”等价类划分场景全覆盖原则”
当出现多个路径时，需要新建用例去覆盖。一条用例仅覆盖一个测试点。降低漏测风险
•        遵循”测试用例路径唯一“原则
假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，下面两种方法来设计测试用例： 方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3， 方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3 方法2，则遵循了“单条用例覆盖最小化”原则 好处，当用例执行失败时，降低复现/定位复杂度。
•        遵循“单条用例覆盖最小化”原则
严谨使用上一条测试用例的结果，做为下一条测试用例的输入。 2、每一条测试用例，应该都是完整独立的。 这样做的好处便于测试用例拉取、复用、可维护。减少后续投入成本。
•        遵循“测试用例与测试用例之间最低耦合度”原则
1.2 用例设计原则
•        正向（正常）场景
•        逆向（异常）场景
1.3.1 功能
1.3.2 非功能
1、性能测试，首先需要有具体的、明确的性能指标需求。
比如SDK、算法、单独性能要求
•        单品（模块）性能
系统集成后的性能要求
•        整体性能
•        网络传输性能
2、性能关注指标： CPU 、Memory、IO、网络传输速率等。
1.3.3 性能
•        时间维度
•        负载稳定性
1.3.4 可靠（稳定）性
•        看门狗
•        异常掉电
•        反复重启
1.3.5 健壮性
•        安装易用性
•        运维易用性
•        功能操作易用性
1.3.6 易用性
比如视频播放效果、操作是否顺手、开机时间等等
1.3.7 客户体验
•        数据存储安全
•        网络传输安全
1.3.8 安全性
1.3 用例设计维度
1 测试用例设计
概述测试用例的主要内容，明确用例测试意图
•        语言简洁，阐明本条用例是干什么
•        一句完整的话
•        遵循“条件/动作"规则，常用的结构“主、谓、宾”
2.2 用例标题
•        测试范围已经确定
•        测试点已经梳理完成
•        用例转换路径：业务需求-功能需求-测试需求-测试点-测试用例
2.1 测试用例编写前提
系统基本功能用例，可用于版本提交时的冒烟测试，可作为版本是否转测试通过和业务验收的依据。 划分依据：该用例执行的失败会导致多处重要功能无法运行的。例如：开关机、升级等。
•        Lve 1 ：基本(～10%)
系统中的重要功能用例。 划分依据：主要包括一些功能交互相关、各种应用场景、客户使用频率较高的正常功能测试用例。 例如：设备上报、录像回放效果、预览等功能。
•        Lve 2：重要（～20%）
系统的一般功能 划分依据：一般功能用例，包括异常路径的测试用例；使用频率低于2级用例。 例如：表单输入边界值、特殊字符的校验等。
•        Lve 3：一般（～60%）
该级别用例一般比较少。主要是一些使用频率非常少的功能等。如果用例执行不通过，不会对系统和业务造成太大的伤害的测试用例 2.划分依据：该用例对应较生僻的预置条件和数据设置。例如：日志记录错误等。
•        Lve 4：生僻（～10%）
2.3 用例级别分布
•        执行测试用例关键必备条件
•        让用例的执行者更加明确系统当前状态
•        预置条件不能阻塞测试用例的执行
2.4 预置条件
•        用例描述中不允许出现二义性语句
•        用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等
•        用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）
•        操作和结果是一一对应的，但操作中不要包含结果的检查
•        操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚
•        操作路径唯一，不唯一则多条用例覆盖（降低耦合）
•        需要明确“测试关键输入”数据
2.5 操作步骤
•        预期结果一定是客观的、可判定的
1、即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果 2、期望结果禁止使用正确，正常，错误之类的含糊主观的字眼
•        每一步操作都有对应的预期结果
•        预期结果一定是确定的
1、即对同样的测试用例，系统的执行结果应当是相同的、确定的
•        预期结果一定是符合需求的
•        结果对应不同输入数据有差别时需分别对应描述清晰
•        结果涉及消息：需明确关键查看内容
•        结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化
•        结果涉及页面，需明确页面提示结果、数据变化
•        结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等
•        一个结果有多个检查点时，确保检查点完整
•        结果中只能包含结果，不能有步骤
•        原则上每个用例必需要有预期结果，结果不能为空
2.6 预期结果
2 测试用例编写格式规范
•        场景图法
•        正交试验设计法
•        判定表驱动法
•        错误推测法
•        边界值分析法
•        等价类划分法
3.1 黑盒测试用例
•        符号测试
•        域测试
•        基本路径覆盖测试法
•        逻辑覆盖法
•        静态质量度量法
•        静态结构分析法
•        代码检查法
3.2 白盒测试用例
3 测试用例编写方法
•        大量数据并发测试的准备
•        应考虑存在跨年、跨月的数据
•        应尽可能覆盖程序的各种路径
4.1 全面性
•        预期结果应与测试数据发生的业务吻合
•        输入界面后的数据应与测试文档所记录的数据一致
4.2 正确性
•        兼顾各种业务变化的可能
•        测试数据应符合用户实际工作业务流程
4.3 符合正常业务惯例
•        对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系
•        对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系
4.4 系统性
•        对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。
•        对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确。
4.5 连贯性
•        人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例
•        从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求
4.6 仿真性
•        测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果
4.7 可操作性
4 测试用例编写原则
通过测试人员自己的分析、 理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。
5.1 测试需求分析
•        项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件
•        对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）
•        分析了解被测试项目所属的行业及其业务知识
5.2 业务流程分析
•        在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况
•        主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等
5.3 测试用例设计
由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员、产品及其他相关的测试人员
5.4 测试用例评审
•        在软件交付使用后客户反馈的软件缺陷（BUG），而缺陷（BUG）又是因测试用例存在漏洞造成，也需要对测试用例进行完善
•        在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善
•        测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后， 测试用例必须配套修改更新
5.5 测试用例完善
5 用例设计步骤
•        建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）
•        扩展 - 多类型测试（性能、安全、异常等等） ：基于业务经验
•        细分 - 测试用例/数据（设计：测试用例）
•        设计 - 测试场景
6.1 分析与设计过程
•        第一步：根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围
i.      基本流程
1.    场景拆分
a.   正常数据、异常数据
b.   破坏性数据
c.    并发性数据
2.    场景正向逆向分析
ii.     备选流程
事件流程
•        第二步：业务流程梳理（业务场景）
￮       在有限的条件下，尽可能梳理多的场景流程，涵盖
•        梳理场景、流程
•        回归场景、流程
￮       结合实际的需求场景、客户场景
•        整合场景、流程
•        第三步：场景串联
6.2 测试场景分析实施
•        异：用非正常输入值进行用例测试。验证结果的正确性
•        复：重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期
•        并：针对测试用例进行大数据量同时执行，验证并发下的测试结果
•        多：针对测试用例进行大数据量覆盖测试
6.3 非功能性设计扩展
6 测试分析与设计
测试用例编写方法
评论
0 条评论
回复 删除
取消
回复
下一页