如何正确的书写测试用例? 本人由于学业不精,有大佬帮助我一下吗 以ECShop前台应用中用户注册、用户登陆、商品搜索等功能为例介绍测试用例设计活动。4.2.1用户注册 用户注册功能需求如图4- 4所示。 图4- 4用户注册需求用户注册需求共涉及4个输入项和1个选择项。针对于输入项,利用等价类及边界值用例设计方法进行设计,选择项则无须设计在步骤中,在测试执行时分别执行勾选与不勾选即可。01.用户名用户名共有三个条件:必填、不少于3个字元、不能重复,分别构造有效等价类及无效等价类,具体如表4- 1所示。 敏捷测试用例根据实际测试需要,不一定写的非常细致,如「用户名」包含字元类型,此处无须再划分纯字母、纯汉字、特殊符号等,构造数据时可混搭。02.email email有两个条件:必填、符合规定格式,分别构造有效等价类及无效等价类,如表4- 2所示。 03.密码密码有两个条件:必填、不少于6个字元,分别构造有效等价类及无效等价类,如表4- 3所示。 04.确认密码确认密码有两个条件:必填、与密码一致,分别构造有效等价类及无效等价类,如表4- 4所示。 测试工程师利用禅道设计用例,如图4- 5所示。 图4- 5用户注册功能测试用例4.2.2 用户登录用户登陆需求如图4- 6所示。 图4- 6用户登陆需求用户登陆共有三个栏位:用户名、密码、保存登陆信息,其中用户名、密码为输入框,保存登陆信息为选择框。因该需求比较简单,故无须分析过程,直接进行用例设计,如图4- 7所示。 图4- 7用户登陆功能测试用例4.2.3 商品搜索商品搜索需求如图4- 8所示。 图4- 8商品搜索需求通过需求分析,商品搜索功能较为简单,测试用例设计时只需考虑一个搜索条件的测试,测试工程师从搜索功能开发角度考虑。对于系统而言,如果资料库中存在某个关键字的商品,则应该显示,否则应当提示没有匹配的商品,故搜索用例设计不需要使用复杂的用例设计方法,测试工程师只需根据经验设计用例即可。对于显示方式,存在显示方式、排序条件、排序方式三种,显示方式又分为小图列表、大图列表、文字,排序条件有按上架时间、按价格、按更新时间,排序方式有升序与降序,如果完全组合则有3*3*2=18种组合,测试工程师可利用正交试验用例设计方法进行设计。通过分析,共有3个参数,每个参数分别有3、3、2个取值,因此需选择因子数、水平数都3,且试验次数最少的正交表。查询正交表,4因子3水平正交表符合条件,如表4- 5所示。 替换参数,得到表4- 6。 多余因子4舍弃不用,排序方式中的3,可使用升序或降序任意填充,由于4因子3水平表中没有全部取2与3的情况,因此根据经验再补充两条,最终得到表4- 7所示的正交表。 表4- 7优化后的商品显示测试组合结合搜索条件,利用禅道设计用例如图4- 9所示。 图4- 9商品搜索功能测试用例 上述测试用例案例读者可参考《附录二 ECShop测试用例案例列表》。通过上述过程,测试工程师完成测试用例的设计工作,评审通过后等待测试版本发布,然后进行测试用例执行、跟踪处理缺陷等活动。Tips:作为一名软体测试工程师,本人日常也会分享一些关于软测的干货专栏文章(如下方的app自动化测试),感兴趣的话不妨关注一波哈?汇智动力IT学院:App自动化测试用例格式和App的启动与关闭?zhuanlan.zhihu.com 我是汇智妹,一枚软体测试工程师萌妹纸,每天除分享IT技术干货之外,也会聊聊IT圈热议的那些事儿;公号【汇智动力】——职场技能提升、助你加薪升职,有对IT行业感兴趣的小伙伴记得关注/私信我吧~比心? 注意以下几点,测试用例规范,小白也能搞定! 测试用例编写规范 主要分为三大部分:基本信息、主体信息、执行结果用例的基本信息:功能模块、编写人、编写时间用例的主体信息:编号,测试对象,测试点,预置条件,测试步骤,测试数据,预期结果,用例优先顺序用例的执行结果:执行通过/不通过/未执行/无法执行 测试用例的原则 百分之百的覆盖需求(尽可能的覆盖需求) 测试用例的编写方法 等价类:根据需求,将所有的输入数据合理的划分等价类。边界值:一般是用最大值,最小值,最小值-1,最大值+1作为边界值。场景法:通过对每个用例的场景进行场景分析,逐步实现测试用例的构造,通常采用思维导图工具梳理业务流程图一般准则:至少覆盖所有状态一次,至少覆盖所有事件一次,至少覆盖所有路径一次。 错误推断法:是根据经验或直觉推测可能存在的各种错误。正则表达式:通常被用来检索、替换哪些符号某个规则的文本(如手机号码、邮箱)因果图:适合检查程序输入各个条件的各种组合情况。因果图转为判定表。一般使用在输入条件的的各种组合判定表:与因果图结合使用 大纲法:拆分系统模块(一般原型图已经拆分) 主要用在测试计划正交法:一般不用这种方式测试(因为太过繁琐,需要将所有输入和结果进行组合) 方法选择(借鉴别人的打油诗,仅供参考)所有输入选等价给定范围加边界条件孤立想判定指定常量取正交跨界操作流程法 多种状态迁移图条件组合出因果测试充分全覆盖多种方法不唯一 测试用例优先顺序划分 高 :用户经常执行的业务逻辑操作,涉及金钱的功能等中 :用例多数包括边界值、逆向逻辑等低 :很少被用户执行的操作 下面是目录,可以根据自己的需求来选择性阅读哈→→测试用例是什么?→→测试用例有什么必备的方面?→→写测试用例的方法有哪些?→→测试用例怎么写?→→测试用例用什么写? 1.测试用例是什么? 测试用例是指对一项特定的软体产品进行测试任务的描述,体现测试方案、方法、技术和策略。简单地认为,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软体需求 2.测试用例有什么必备的方面? 编写测试用例的八大要素有:用例编号,所属模块,测试标题,重要级别,前置条件,测试输入,操作步骤,预期结果 3.写测试用例的方法有哪些? 知道了什么是测试用例,那该怎么写测试用例呢?不著急,先来学习一下测试用例的方法有哪些 (1) 等价类划分 原作者:xuping511_to原文链接:https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#来源:百度文库 将测试中所有可能的输入数据(有效的和无效的)划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,测试用例由有效等价类和无效等价类的代表组成,从而保证测试用例具有完整性和代表性 举个栗子:输入框要求输入1-100的数有效等价类:可以输入1-100之间的数来验证,如:2、6……99无效等价类:可以输入1-100之外的任意字元验证,如:250、字母、下划线、特殊符号、空格、回车..... (2) 边界值 原作者:xuping511_to原文链接:https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#来源:百度文库 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。 实践告诉我们:大量的错误是出在输入输出的边界价上。我们还拿上面的例子,一个输入框要求输入1-100之间的数。我们要测它有没有超出这个范围,如:0、-1、-2、10、101.....等等,来判定是否超出了我们的范围。 (3)因果图 用图解的方法表示输入的各种组合关系,写出判定表,从而设计相应的测试用例。最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。原文链接:https://www.docin.com/p-2173458956.html原作者:边雄刚原文出处:豆丁 例子:有一个处理单价为5角钱的饮料的自动售货机软体测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。 解析:如题可知,可分析出原因和结果原因:1. 售货机有零钱找2. 投入1元硬币3. 投入5角硬币4. 按下橙汁按钮5. 按下啤酒按钮结果:10.售货机【零钱找完】灯亮11.退还1元硬币12.退还5角硬币13.送出橙汁饮料14.送出啤酒饮料中间结点:6.选商品7.应该找零钱8.能够找零钱9.钱已付清如下所示↓:画出因果图(原因结点列在左边,所有结果结点列在右边,中间节点表示处理的中间状态) 自动售货机的因果分析图 (4) 错误推测法 基于经验和直觉推测出系统可能存在的错误,从而有针对性的设计测试用例的方法 (5) 其它方法 除了上面几种常用的,其它的方法还有:状态迁移图、流程分析法、正交验证法等等我在逛博客园的时候看到一首打油诗,我觉得非常合适: 所有输入选等价 给定范围加边界 条件孤立想判定 指定常量取正交 跨界操作流程法 多种状态迁移图 条件组合出因果 4.测试用例怎么写? 当~当~当~终于来到重头戏了,让我们来看看怎么写一个合格的测试用例吧 我在百度上随便找的一个登录页面,下面我们就根据这个图片来写测试用例吧用例编号:唯一标识用例的序号。一般是数字或者模块字母+数字组合。如:L001,L表示登录,001表示用例序号所属模块:所测功能模块的名称,如:登录模块用例名称:就是这个用例是什么意思。如:输入账号前置条件:前置条件可以保障后面的测试步骤正常进行,可以理解为执行当前用例的前提条件。比如:只有注册过的用户才能登录测试输入:用例执行期间输入的外部信息。根据用例的种类不同,测试输入也有所不同。包括数据、图片、手工操作、文件、资料库记录等类型测试步骤:详细完整的把你测试的过程描述出来预期结果:对当前用例的输出做一个预期值。预期结果是根据软体需求所得出的,相当于一个衡量标准。在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。实际结果:实际测出来的结果(可能会和预期结果不符)另外,有些公司可能会要求在用例后面添加优先顺序、用例人员姓名、测试日期、用例修改日期、测试结果(Pass、Fail、Block)等等,这个得根据公司的会实际情况来看我根据上面的登录页面写了一个登录模块的测试用例,如下表所示,你们可以参考一下: 登录模块的测试用例PS:都看到这里了,真的不考虑给这么用心的我 @可乐豆一个点赞、关注吗?(*?▽?*) 5.测试用例用什么写? 测试用例可以以Word或者Excel的方式呈现,主要用到的工具有禅道、testlink等等 另外,网上有很多软体测试的模板。(本来这里有一个博客园模板的链接,知乎告诉我违规了,想要的可以私我,当然你们也可以去博客园自己找)对了,关于软体测试的学习路线,可以看一下我之前写的文章,里面非常详细的写了软体测试的技术学习路线和每个阶段该具体该学什么:2020最全软体测试学习路线和资料分享好了,终于写完了这篇文章。如果你喜欢这篇文章就请点赞关注一下@可乐豆吧。总之,关注可乐,入股不亏~(笔芯)后续,可乐也会发布关于软体测试的相关文章 安装卸载测试?安装程序是第三方的还是自己写的?第三方的简单,好的情况他都处理好了,只要确保调用正常就可以。案例检查配置文件需要修改的地方是不是配置正确。自己写的要测的就多了。一 界面一共几个界面,界面元素,位置,文字,是否有效二 安装1.预设安装安装完成后启动成功拷贝的文件位置正确,数量正确,文件完整,许可权正确创建文件成功,位置正确,内容正确,许可权正确链接文件创建成功,链接正确,许可权正确注册表修改成功,内容正确安装日志无报错2.自定义安装安装路径创建成功自定义配置正确3.安装失败错误处理:许可权不足,空间不足,文件拷贝不全……安装日志内容正确手动取消,退回上一步,退出安装程序,清除已安装文件4.再次安装,覆盖已有文件或升级已有文件三 卸载目标文件已删除注册表内容修改成功卸载日志内容正确另外,如图,存在帮助,调用帮助成功就测试案例来说,明确测试目的,测试点是否已覆盖,测试步骤明确可操作,测试结果明确可验证,必要时辅助测试数据再复杂一些,说明所使用的测试方法,测试工具,自制脚步……最终目的,使其他测试人员能复现整个测试过程,查找没有覆盖的测试点,优化测试数据,测试方法,测试工具,更有效的保证软体质量 哈喽我来了 感谢邀请!! 在企业的实际工作当中,为了提高测试的覆盖率,提高测试过程的可追溯性,我们往往需要通过需求分析从而编写大量的测试用例,看似简单的测试用例其实隐藏著众多逻辑和技巧在内,写出一份优质的测试用例能够大大的提高测试质量,从而发现更多的BUG,写好测试用例其实并不容易!下面我来说说到底如何编写一个测试用例呢?步骤是怎么样的?作为测试新人,如何实现测试用例的设计一直是大家共同的困惑,在工作中我们该如何展开测试用例的编写工作呢?我们先来梳理一个测试用例的设计步骤。 前提: 再去编写测试用例之前我们要对我们的项目需求进行了解,按照什么顺序测试,去测什么?覆盖哪些内容和需求都要自己心里有数,作为测试用例的编写者不仅了解要有工作当中常见的测试用例编写方法,同时需要了解被测软体的设计、功能规格说明、用户试用场景以及程序/模块的结构。 步骤: 1、测试需求分析需求分析就是要弄清楚用户需要的是什么功能,用户会怎样使用系统。这样我们测试的时候才能更加清楚的知道系统该怎么样运行,才能更好的设计测试用例,才能更好的测试。测试需求分析是测试工作的第一步,经过需求分析,对原始需求列表中列出的每一个需求点,找到我们需要测试的测试要点;针对所确定的测试要点,分析测试执行时对应的测试方案/方法。 2、业务流程分析 分析完需求后,明确每一个功能的业务处理流程,不同的功能点作业务的组合,以及项目的隐式需求。如遇复杂的测试用例设计前,先画出软体的业务流程。 从业务流程上,应得到以下信息: A、 主流程是什么? B、 条件备选流程是什么? C、 数据流向是什么? D、 关键的判断条件是什么?例如:app测试流程及业务流程 3、测试用例设计 完成以上两步则可进行测试用例设计,功能测试用例,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。4.编写完成后自我检查以及部门内部评审 5.测试用例更新完善 测试用例编写完成之后需要不断完善,如遇需求更改或功能新增时,测试用例必须配套修改更新,同时在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软体交付使用后客户反馈的软体缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。好的测试用例是怎么样的? 一.质量属性 1.正确性:确保测试标题描述部分的内容正确性。 2.经济性:只为确定需要的目的设计相应的测试步骤 3.适应性:既能适应短期需要,又能考虑长远需要。 4.可追踪性:用例能追踪到一个具体的需求。 5.自我清理性:单个用例不会影响整个测试环境,即用例执行完了可以恢复原有的测试环境。 二.结构化和可测试性 1.含有规范的测试标题和编号。 2.含有一个确定的测试某一个特定需求的目的。 3.含有关于测试方法的描述。 4.指定条件信息-环境、数据、预置的条件测试、安全入口等。 5.含有操作步骤和预期结果。 6.陈述任何辅助证据,例如截图报告并确保这些东西妥善保存。 7.确保测试环境的干净(即用例不会影响整个环境)。 8.描述时使用主动语气结构。 9.操作步骤不要超过15步 10.确保单个用例测试执行时用时不超过20分钟。 11.自动化脚本用例添加必要的注释,比如目的、输入和期望结果。 12.如果可能,建议提供可选择性的预置条件测试。 13.用例之间的先后顺序是否跟业务流程一致,即用例在业务流程中的彼此顺序关系是否合理。 三.配置管理 1.采用命名和编号规范归档。 2.保存为特定的格式,文件类型。 3.用例版本是否与当前被测试软体版本一致(对应)。 4.包含用例需要的相应测试对象,如特定资料库。 5.存档阅读。 6.存档时按角色控制访问方式希望可以帮到题主有什么问题私信我,还有免费资料可以领取! 测试用例组成部分一般是:前置条件,测试步骤,期望结果,用例等级,用例类型等等。具体要怎么写就太宽泛了,一般是根据需求点去写,灵活运用等价类划分、边界值分析、组合覆盖、逻辑推断、业务路径覆盖等等设计方法,并在测试中不断完善和新增…… 推荐阅读: 相关文章 {{#data}} {{title}} {{/data}}