【测试】编写测试用例的思路和方法 |
您所在的位置:网站首页 › 编写测试用例的方法 › 【测试】编写测试用例的思路和方法 |
文章目录
1)什么是测试用例?1.1 测试用例的定义测试用例的内容:
*为什么需要测试用例?测试用例的作用:
1.2 测试用例的元素测试目标(Why):测试对象(What):测试环境(Where):测试前提(When):输入数据(Which):操作步骤(How):
2)测试用例的编写流程2.1 需求分析1、过需求文档:2、根据需求文档,拆分测试点。需求的种类:*什么是产品需求文档?*什么是交互需求文档?*如果没有需求文档,怎么设计测试用例?
2.2 提取测试点【举例】对PC端QQ账号的登录模块,提取测试点:【举例】对CSDN的web端登录界面,提取测试点:
2.3 测试用例的编写2.3.1 编写测试用例该注意什么?测试用例的模板:
2.3.2 测试用例的写作用例编号/ 序号用例说明(检查点)初始条件操作步骤预期结果用例状态优先级*举例:
2.4 测试用例的评审*为什么要进行用例的评审?2.4.1 测试用例评审要点2.4.2 测试用例的维护为什么需要更新测试用例?常见的测试用例管理工具
3)编写测试用例的方法
1)什么是测试用例?
1.1 测试用例的定义
测试用例是对一项特定的软件产品进行测试任务的描述,指定输入,预期结果和一组测试项的执行条件的文档。 它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。体现了测试方案、方法、技术和策略。 测试用例的内容: 内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。具体有: 用例编号、用例名称测试背景前置条件优先级、重要级测试数据测试步骤预期结果、实际结果备注等 *为什么需要测试用例? 测试用例的作用: 检验软件是否满足客户需求体现一个测试人员的工作量展现测试用例的设计思路测试用例是测试人员在测试过程中的重要参考依据。 测试用例可以帮助实施有效的测试,所有被执行的测试都是有意义的,不执行毫无意义的测试操作。 测试用例是一个知识传递的过程,能保持一致、稳定的测试质量。 从项目管理的角度来说,测试用例的通过率是检验代码质量最主要的指标之一。 测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素,从而更加合理地做出测试安排或调整。 良好的测试用例不断地被重复使用,使得测试过程事半功倍。 在软件产品的开发过程中,开发人员不断的推出新的版本,测试人员需要对原有功能进行多次的回归测试,即使在一个版本中,也要进行 2~3次的回归测试。这些回归测试,就要求能重复使用测试用例。 如果没有测试用例,很可能到执行的时候测试点就遗漏了,另外也不便于用例评审,用例总结,对后期测试工作没大的改进作用。 所以测试用例一定要写,颗粒度视情况而定。针对测试人员少,上线时间紧的项目,可只做思维导图列出测试点。 1.2 测试用例的元素测试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤,即 5W1H。 测试目标(Why): 为什么而测?功能、性能、可用性、容错性、兼容性、安全性等。 测试对象(What): 测什么?被测试的项目,如对象、函数、类、菜单、按钮、表格、接口、整个系统等。 测试环境(Where): 在哪里测?测试用例运行时所处的环境,包括系统的配置和设定等要求,也包括操作系统、浏览器、通讯协议等单机或网络环境。 测试前提(When): 什么时候可测?测试用例运行时所处的前提或条件限制。 输入数据(Which): 哪些数据?在操作时,系统所接受的各种可变化的数据,如数字、字符、文件等。 操作步骤(How): 如何测?执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。 2)测试用例的编写流程主要分为以下四步: 需求分析 -> 提取测试点 -> 测试用例编写 -> 测试用例评审 2.1 需求分析如果直接去测试,会发现有很多需求理解的偏差,测试过程中会发现自己理解的需求跟开发实际做出来的功能不一致。 所以拿到需求后: 1、过需求文档: 先自己过一遍需求文档,标出不理解或者可能会有争议的地方。可以借鉴一下同类产品类似的功能是怎样处理的,这样更有助于理解需求。针对有疑义的地方与产品经理和开发人员一起讨论,尽量减少大家对需求理解上的误差。 2、根据需求文档,拆分测试点。 需求的种类: 业务需求:关注系统是否满足业务要求。用户需求:关注系统是否满足用户习惯。功能需求:关注系统是否满足功能要求。 *什么是产品需求文档?产品需求文档就是产品功能说明书,包含大量的功能细节,目的是提高沟通效率,避免研发过程出现误会。 产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。 交互需求文档是给交互设计师看的文档,应该在需求文档之外单独呈现,主要目的是让交互设计师理解产品的交互需求。 交互需求文档主要是对功能的交互设计,包含功能列表,每个功能的交互要点说明,包含元素等等。 *如果没有需求文档,怎么设计测试用例? 查找其他相关文档,来帮助理解所要测试的产品需要完成的目标。尽量多参加项目组内的会议,比如需求讨论、设计讨论、计划讨论等,能够加深对产品的理解。咨询相关人员:项目负责人、市场人员。如果是一款已经上线的产品,可以多使用产品,有不懂的问产品经理。可以去看历史bug,了解到一些需要关注的东西。 2.2 提取测试点对各个功能模块进行测试点分析,提取测试点,再对测试点进行用例编写。 测试点:通过需求分析后,对得出的需求进行测试的具体内容。 【举例】对PC端QQ账号的登录模块,提取测试点:![]() ![]()
评审就是对测试用例进行检查。用例编写完成后,要组织人员进行用例的评审。 评审包括:同行评审、小组评审、部门评审和第三方评审等。参与人员:包括需求人员(如产品经理)、测试人员、开发人员等。评审流程:评审后改进测试用例,再进行评审再改进测试用例,这样一直循环直到评审都通过,这时候才结束评审,也标志着测试用例编写的完成。 *为什么要进行用例的评审?测试用例包含了功能的边边角角,我们不能保证能把所有的测试点都列出来,也不能保证我们所列出来的测试点方向都是正确的,那么就需要其他人来查缺补漏、纠正错误,看一下有没有我们漏掉的点,看一下我们用例的方向是否正确,防止对需求的理解错误。 通过评审发现用例的不足方便测试人员改进用例提高测试质量 2.4.1 测试用例评审要点 根据检查单或检查表(Check List)进行评审。用例“文字校对”:错别字、病句、语句不通顺、含义不清晰、语句有歧义、格式不一致、标点不一致、中英文混合等。用例质量:遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等。确定用例的优先级。规划服务器和客户机。用例的分工执行与人员安排。记录评审过程,记录测试环境规划。 2.4.2 测试用例的维护 为什么需要更新测试用例? 先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究,对某些功能、特性、逻辑等的理解越来越清楚、深刻。所发现的严重的软件缺陷没有被目前的测试用例所覆盖。新的版本中有新功能的需求或者原有功能的增强而需要发生改动。编写的测试用例不规范或者语句错误。旧的测试用例已经不再适用,需要删除。 常见的测试用例管理工具 原始的Excel管理TestLink: 免费开源可扩展性高,可以和bugzilla等缺陷管理工具的整合,适合中小型项目的管理。ZenTao(禅道):免费开源,不过定制能力不足,不好用层级结构管理用例。Bugzilla、ALM等,更详细的可以参考:有哪些比较好的测试用例管理工具?(https://www.zhihu.com/question/26898212) 3)编写测试用例的方法常见的方法有等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。 具体可参考本栏目的《【测试】编写测试用例的常用方法》。(https://blog.csdn.net/m0_37621024/article/details/116860859) 【部分内容参考自】 测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818一份优秀的需求文档:https://www.pianshen.com/article/8729120291/编写测试用例及一个例子:http://www.51testing.com/html/24/n-3727424.html测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |