本文主要是介绍测试总监,让我们用这份《测试用例规范》,再也没加班过,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
经常看到无论是刚入职场的新人,还是工作了一段时间的老人,都会对编写测试用例感到困扰?例如:
固然,编写一份好的测试用例需要:充分的需求分析能力 + 理论及经验加持,作为测试职场摸爬打滚的老人,给大家分享一些用例编写的心得,接下来我会从以下几个方面展开来讲:
1、为什么要写测试用例?
- 是测试工作的指导,是软件测试质量稳定的根本保障,评估测试结果的基准。
- 有一份用例来指导测试执行,可以在测试人员疲累的时候起到一个牵引作用。
- 编写用例的过程中,通过熟悉需求,对系统架构或业务有更深入理解
- 可避免测试背锅
2、测试用例模板:每家公司模板可能会有差异性,一般大致包含以下内容
- 用例编号:唯一性,一般规则:产品名_测试阶段(it st uat)_测试项_数字
- 测试项目:对应一个功能或子功能模块
- 测试标题:一句话总结当前测试的用意和目的
- 重要级别:高/中/低
- 预置条件:需要满足一些前提条件,否则用例无法执行
- 测试输入:需要加工的输入信息,跟步骤结合起来一定要具有指导性意义
- 操作步骤:明确给出每个步骤的描述,执行人员可以根据该步骤完成执行工作
- 预期结果:根据预期输出比对实际结果,来判断被测对象是否符合需求
- 实际结果:通过测试执行后的实际结果,写用例时为空。
3、测试用例编写形式
- 通过 Excel 编写,上述给出的模板就是该种形式 ,适用于项目开发时间比较充分的情况下
- 通过 Xmind 梳理测试点,适用于项目开发时间紧急情况下
- 项目管理平台例如禅道上编写,不常用
如何编写测试用例
大体思路分为三步:
第 1 步:依据需求梳理功能及功能点
第 2 步:通过测试理论方法及经验,梳理测试点
第 3 步:挖掘隐性需求,覆盖非功能测试层面
总结
编写用例虽然不是那么简单的事,但是通过以上,是不是发现还是有方法可循的?不会写的先模仿着来写,日积月累,通过项目中测试思维的长期训练,工作中出现 bug 的经验总结,相信某一天你会发现编写测试用例也没有那么难!
公司新来的字节大佬把设计用例规范的整理成下面的PDF文档,包含了测试用例原则,测试用例主要元素,测试用例编写规范,测试用例编写细则,测试用例编写方法。看完这个PDF,你的测试用例再也不用担心出问题了。
1.目的
统一测试用例编写的规范,为测试设计人员提供测试用例编写的指导,提高编写的测试用例的可读性,可执行性、合理性。为测试执行人员更好执行测试,提高测试效率,最终提高公司整个产品的质量。
2.范围
适用于集成测试用例和系统测试用例的编写,现在编写用例的辅助工具为TestDirector 8.0
3.术语解释
集成测试:
集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。
系统测试:
系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。
4.测试用例原则
系统性
1.对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;
2.对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系;
连贯性
1.对于系统业务流程来说,各个子系统之间是如何连接在一起,如果需要接口,各个子系统之间是否有正确的接口;如果是依靠页面链接,页面链接是否正确;
2.对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系统,其内部功能接口是否连贯;
全面性
1.应尽可能覆盖程序的各种路径
2.应尽可能覆盖系统的各个业务
3.应考虑存在跨年、跨月的数据
4.大量数据并发测试的准备
正确性
1.输入界面后的数据应与测试文档所记录的数据一致
2.预期结果应与测试数据发生的业务吻合
符合正常业务惯例
1.测试数据应符合用户实际工作业务流程
2.兼顾各种业务变化的可能
3.要符合当前业务行业法律,法规。
仿真性
人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例;不允许出现与知名人士、小说中人物名等雷同情况。
可操作性
测试用例中应写清测试的操作步骤,不同的操作步骤相对应的操作结果。
文档获取方式:
这份文档,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点击下方小卡片免费获取。
这篇关于测试总监,让我们用这份《测试用例规范》,再也没加班过的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!