沈阳网站建设方案报价,制作简历的app免费,做网站都需要买什么,网站建设开发ppt模板下载前言
这篇文章主要是想要写给测试小伙伴们的#xff0c;因为我发现还是有很多小伙伴在遇到写测试用例的时候无从下手#xff0c;我就想和大家简单的聊聊#xff0c;分享一下我的一些见解和经验。
用例的五个构成元素#xff1a;
用例标题前置条件测试步骤期望结果后置条…前言
这篇文章主要是想要写给测试小伙伴们的因为我发现还是有很多小伙伴在遇到写测试用例的时候无从下手我就想和大家简单的聊聊分享一下我的一些见解和经验。
用例的五个构成元素
用例标题前置条件测试步骤期望结果后置条件
下面从这五个元素的角度去剖析如何编写测试用例
用例标题
用例标题就是测试点名称。用例标题是用来说明这个用例的测试目的的好的用例标题是别人看完你这个用例标题后就知道你这个用例是测什么的。但并不是标题越详细越好。既然是标题就要言简意赅能多简洁就多简洁但简洁的同时又要能体现你的测试目的。用例的标题最好不要超过30个字太长会让人看起来很累也很不专业。一般可以遵循这样的公式主体(可省略) 动词 名词 结果(可省略)(即谁做了什么有什么影响)但很多时候是动词 名词的形式。要注意我们写的每一个案例对应的就是要测试的一个点。其实每个点都是用户的一种操作行为。
前置条件
用例的前置条件就是在测这个用例之前你要先准备的环境和数据。同时我们需要将前置条件和测试步骤区分开来但怎么区分呢是不是还是比较模糊我们从用例标题入手我们的用例标题是动作名词嘛那我们的测试重点是动作那产生这个动作之前的所需的所有环境和数据都算是前置条件产生这个动作和这个动作带来的后果都算是测试步骤。这样是不是就比较清晰了。 前置条件只是说明测试这个用例需要准备的环境和数据故前置条件不用像步骤那样写得那么详细但也不能太过于简洁不能有歧义。
测试步骤
测试步骤是一个用例的精髓用例标题体现测试的目的用例步骤就是如何来测从而达到测试的目的。即然是步骤那就是一步一步的操作过程但这个操作过程并不是写得越详细越好。我们的步骤是来体现我们的测试目的的即要怎样做什么操作这个操作后要如何检查产生的结果。这个操作可能是一步也可能是几步也可能是来回循环。不管是什么操作都是告诉别人如何去做如何去检查。但步骤不能写得过于详细如【登录控制台打开xx页面点击xx按钮】这种就没必要写上去因为这种既是浪费时间也会给用例的维护带来成本。只需精简明确地告诉别人在哪做什么操作即可同时写案例时需要遵循一些准则规范 用例规范 每个文件夹下不能超过10个测试用例每个用例的步骤不能超过8步(算整个案例测试步骤比如测试步骤和后置条件中执行1-3步)测试用例不写“编号”和“测试步骤名称”每个测试用例一个测试点用例标题不宜过长需要精简明了详细测试需求点、测试步骤和预期结果必须体现测试目的和测试重点测试用例中需要用到附件的需附上文件和文件存放路径(附件大于1M可指定路径预期结果要量化和直接化减少用例执行的沟通成本测试用例设计时需考虑测试执行效率功能用例执行10分钟原则用例里用到的数据或样本、脚本需要在备注里附上“测试步骤”和“预期结果”必须可实现和可执行测试用例需验证客户业务不能只检查配置和页面除非为纯页面测试体现强关联去掉弱关联强关联案例中缺少此步骤就无法达到案例目的弱关联案例中缺少此步骤可以达到案例目的对于大家都知道或应该清楚的点不用体现在用例中测试用例需要有正反对比验证开和关的对比、匹配和不匹配对比、输出结果的对比等这种用例可以合并减少用例冗余提示内容不用写的太具体说明大概意思即可后面修改了提示需要返工用例用例里不能有具体的版本号模块备注尽可能详细便于测试和观察测试点测试方法可实现测试数据贴近于用户环境和其它功能、第三方之间有关联的测试场景有没有遗漏标题精简需要体现测试目的模块目录中的备注是否足够详细能支撑其它人快速理解特性和提高测试效率测试结果的检查有没有站在客户的角度进行测试和验证页面的测试需要覆盖多款浏览器的测试不用把所有检查点放在一个用例上这样会出现执行漏测或前面失败了后面就不执行了问题发现滞后若多个案例之间在步骤上就是互相覆盖的需要合并如测最长字符和包含特殊字符这两个测试点可以合并为一个案例用例里不能出现有歧义的词阐述需要清晰不能两个人执行同样的 案例可能会产生两种执行结果用例需要专业性不能出现口语化的词语期望结果需要明确性不能出现模糊的词语如可能、如果、符合要求等 可维护性规范
测试用例中不能出现页面配置路径如系统配置-网络配置-网络接口测试用例中不能出现操作过程比如打开XX目录下文件点击什么直接写需做的操作即可测试用例需用到的例行检查点、公共检查点、后台、调试、配置文件等查看方法统一写到模块备注 期望结果
期望结果对应的是测试步骤每一个测试步骤都对应一个期望结果即做了这个操作后希望它产生的后果。即大家在用例里看到的测试步骤里的1,2,3对应期望结果里的1,2,3。理论上每一个测试步骤都需要有一个对应的期望结果但有些测试步骤我们并不关注这一步骤的操作后果那这样的期望结果可写可不写。
这里需要注意期望两字期望的意思是说要从用户的角度出发我用户做了这个操作后我希望它能给我反馈的结果。这个结果不是开发程序代码返回的结果开发程序代码返回的结果是实际结果执行用例时只有实际结果与用例期望结果一致时案例才能标pass。所以在写案例或执行案例时得到实际结果与期望结果不一致时不要轻易被开发忽悠了一切以用户主。
后置条件
与前置条件对应即执行完这个用例后需要还原环境否则会给下个用例带来影响。一般写功能用例时后置条件基本不用太关注因为测试环境本来就需要多样化才能模拟用户的环境若每次执行用例都保持一个纯净环境则带来的测试工作量也大而且也不能很好地体现测试环境的多样性。后置条件一般是自动化需要做的因为自动化需要保持环境的独立性彼此不依赖执行完一个案例后需要将这个案例创建的数据、策略等全部清空防止影响下一个案例。
如何划分用例等级
现用例等级是怎么划分的
一般在一个模块里的案例按照等级进行划分时遵循下面的比例
BVT(10%)模块最基本的功能验证(含常用部署、基本关联)推荐1级用例的20%左右Leve1(30%)基本需求点基本逻辑基本可靠性基本关联基本用户场景Leve2(40%)常见功能/逻辑细化点/专项细化点常见关联/容错/边界值/用户场景Leve3(20%)错误提示极少测试的用例非常见部署方式/用户场景/容错/边界值等
我们在划分用例等级时为什么要这样划分
BVT的案例应该是最基本最简单的案例如一个功能模块的增删改就是最基本的
level1是基本的功能需求基本操作相关的如上面说的增删改增可能有多种增加方式BVT只是最基本的操作level1是对BVT的一种补充
level2是一些内部逻辑细化点或一些常见的异常操作。Level2的异常是对用户来是比较常见的是很大概率上会遇到的
level3是可能会出现但出现概率很低的一些操作或异常场景。level3的异常是很极端的异常是很小概率会发生的如不断重启之类的。
这样划分的意义何在
这样划分是有意义的从这个等级划分的原则上看就知道BVT是最好执行的然后等级越高难度系数越大特别是level3这种可能涉及到很复杂的网络部署或很异常的环境构造。
不同等级的案例需要消耗的时间和带来的影响是不一样的。当一个模块转测后我们希望的是能快速验收这个模块的质量那如何验收不就是它的基本功能是不是完成了它的基本操作是不是都能顺畅执行在这些基本功能基本操作都没问题的情况下再来检视内部逻辑细节处理是不是到位最后再检视各种异常场景下的处理是不是已经合理。即从简单到困难先保障基本功能再检验其他的发散点。 感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
