厦门功夫广告设计网站建设工作室,杭州公司注销网站备案,在58做网站推广有用没,网站及邮件系统建设#x1f60f;作者简介#xff1a;博主是一位测试管理者#xff0c;同时也是一名对外企业兼职讲师。 #x1f4e1;主页地址#xff1a;【Austin_zhai】 #x1f646;目的与景愿#xff1a;旨在于能帮助更多的测试行业人员提升软硬技能#xff0c;分享行业相关最新信息。… 作者简介博主是一位测试管理者同时也是一名对外企业兼职讲师。 主页地址【Austin_zhai】 目的与景愿旨在于能帮助更多的测试行业人员提升软硬技能分享行业相关最新信息。 声明博主日常工作较为繁忙文章会不定期更新各类行业或职场问题欢迎大家私信有空必回。 阅读目录1. 目的2. 写好自动化测试用例的因素2.1 万物皆对象2.2 业务强关联2.3 正向场景2.4 多场景构建2.5 强针对性2.6 独立测试功能点2.7 完整设计3. 题外话1. 目的 之前我们介绍了要写好黑盒测试用例的一些相关因素相信大家应该能从其中或多或少的感悟到各自对于黑盒测试的全新理解与思路拓展。那么紧接着之前的内容我们就该详细的聊一聊另一种形式的测试用例了它在我们的自动化测试活动中也扮演着举足轻重的角色。 2. 写好自动化测试用例的因素 因自动化测试的种类比较繁多故相关的自动化测试用例的设计方法、呈现方式、执行过程也是五花八门。那我们就在其中挑几种比较主流的来进行讨论其中也可能不免会有一些不同之处大家可以按需斟酌阅读。 那么开正式开始介绍之前我们需要搞明白自动化测试的必要性和存在意义其中最浅显的一点就是可以提高我们的测试效率因为是机器来帮我们执行测试活动这个观点当然没错但也还是有很多的公司仍然停留在这个认知层面中就如我之前的一篇文章内阐述过很多公司或团队仍然会以KPI或晋升目标作为动机来开展自动化测试和与之相关的建设活动。这个也就是我们圈内说的“为了自动化而自动化”。在这样的大基调下自动化能带给我们的益处与提升是什么也就不得而知了更多的则是人力与时间成本的大幅消耗与极为不成正比的投入产出比。 博主自己所理解的自动化测试的存在意义就四个层面来说分为公司、产品、团队、个人。首先就公司而言投入自动化测试的本质其实是要降本增效这里大概会有人提出疑问怎么会是降本呢无论是招聘专业人员还是投入对应硬件怎么看都是增本呀。其实这里有一个误区就我们个人而言看到的现象的确如此但对于公司来说只要是有明确的战略目标、长足的远见规划以及一定的投入从长远来看这其实是一笔稳赚不亏的决定。这里就要结合我们的第二个层面的“产品”来说一说了。众所周知在互联网行业中无论是同行业亦或是跨行业软件的激烈竞争从来就未停歇过一款产品的及时面世与稳定迭代更新更是抢占有效市场的先决条件。试想一下一家仅靠纯手工测试的产品能做到上述的要求吗毕竟人为的工作还是具有一定的不确定性的这个和执行者的情绪、环境、主观想法、惰性有着密不可分的关系任何一个因素都有可能影响整个产品的质量表现。所以公司的前期投入是显性投入但后期的自动化测试亦或是更近一层的CI/CD带来的收益则都是隐性的可能最后大家真正能见到的将会是产品销量、收益的增长。当然不是投入了自动化测试就一定会让产品的质量与销量取得成功其中的很多因素都必须明确并选择正确。诸如投入后解决什么样的问题或矛盾、技术栈的选择、框架的设计、日常维护、专人专岗、硬件支撑、投入产出比的审查、后期优化等等等等。 对于团队来说拥有自动化测试能力无疑会让团队的外界评价更上一个层次现在业界内对于测试人员的要求越来越高大家都有目共睹。一个只有手工测试人员的团队与可长期稳定支撑开发人员且能自主执行自动化测试活动的团队不用我说也就高下立见了。也正因如此专业的团队可以在公司内拿到更多更好的资源也就无可厚非有了这些实质性的支撑相信团队的规模亦或是实力也将会是越来越强。那么在个人层面上掌握了自动化测试能力无疑是增加了自己的一份核心竞争力增强竞争力的根本出发点无非就是让我们可以在测试的道路上走的更稳更远升职加薪自不必多说。再则加上如今AI、大数据依然成为了主流趋势一个没有编程能力并且没有设计理念的测试必然会被社会与时代淘汰。 2.1 万物皆对象 学过java或python的同学应该都知道这句话吧没错在我们设计自动化测试用例的时候也需要这个理念。毕竟和黑盒测试用例不同自动化测试用例不是给人类执行的我们需要使用对应的开发语言来进行用例的编写。在编写测试用例脚本的时候时时刻刻需要把这个理念贯彻其中。当然编写用例的过程与其他开发人员的编码工作没有什么本质上的区别也别指望用例脚本可以一次性的编写到位脚本大多数都是需要一次又一次的优化起初写的效率低一点也没关系我们先确保可以跑通复用性和健壮性可以稍微差点。但是跑通之后我们就应该着眼于性能方面如果你用的python跑几条用例是完全没有问题的因为python是动态语言变量指向对象的时候编译器无法做任何预测另外加上他本身是解释执行所以是在跑大量测试用例的情况下一定会出现运行周期时间长与意外报错的情况出现此时提高代码的性能就成为了重中之重算法时间复杂度的优化、内置方法的合理使用、避免全局变量、减少循环等等都可以为我们的代码提供相应的性能提升。 2.2 业务强关联 与黑盒测试用例不同自动化测试用例内的业务关联性会很强。其实我们从其本质形态来考虑的话也就能探究一二它需要解决的本来就是一些功能稳定、业务路径明确的正向测试场景测试用例脚本不可能只操作某个业务界面中的某一个功能这样就太浪费了。一般来说测试脚本都需要覆盖某一个正常业务的整条流程这样我们才可以在其运行的过程中加入自己所需的各类断言来验证多条用例中的测试预期结果。另外由于和黑盒测试用例的本质不同也就更好的印证了自动化测试用例可以快速进行业务验证与归回、冒烟。 2.3 正向场景 对于自动化测试来说最恐怖的情形就是将所有的正向、逆向测试场景一股脑的塞进自动化测试框架。有些人会本能的认为既然是自动化执行为什么不可以执行逆向测试用例呢只要设计好合适的参数、编写进测试用例真的就万无一失了吗其实逆向测试场景与测试用例被适合放入自动化测试的原因就在于它本身的不确定性这种不确定性会影响自动化测试的最终运行结果。做过自动化测试的同学都知道对于执行自动化测试来说真正可怕的不是逆向测试用例而是那种不知道什么时候就会报错的测试场景和用例而这种测试用例的所在场景绝大多数会出现在逆向测试场景中。我们要知道自动化测试不是帮测试人员把什么事情都干了。所以针对功能稳定、需求变动不多的正向测试场景我们可以放心的将自动化测试投入其中但逆向的测试场景就不建议如此操作了。如果真的要放也只建议放入比较不重要的功能模块一些业务复杂和重要的功能模块的逆向场景还是需要经验丰富的测试人员去进行手工确认来的更为的稳妥。一般来说自动化测试主要覆盖产品的主体happy path即可无需设计过多的逆向场景在其中影响自动化测试活动的稳定性。不要忘记了自动化测试的主要作用还是让我们的测试人员从繁杂重复的测试工作中脱离出来把精力投入更重要、更复杂的模块和业务测试中去。 2.4 多场景构建 这里的多场景构建理念是希望可以充分的利用自动化测试的优势以更少的运行次数来尽可能的覆盖更多的测试场景。举个例子一个自动化测试脚本中存在多条测试用例那么我们在设计用例的过程中需要充分的利用脚本中的业务界面来进行多个场景的组合构建。诸如CRM我们都会在客户信息界面中验证客户的各类信息、增删改查操作而这些操作如果可能尽量放在页面的一次性操作中除非和后面的业务有强关联后续操作的必要数据否则基本都是按照这个原则。这也就是上面说的尽量在一遍中将可以验证的业务场景组合在一起而非跑多轮同样的业务线却只是验证的测试点不同。 2.5 强针对性 一般来说我们设计自动化测试用例来源的基础都是我们之前设计的黑盒测试用例普遍的做法是将P0与P1级别的正向测试用例加入到自动化测试用例中。这样做是完全没有问题的不过我们还需要注意的是针对不同的测试类型我们的自动化测试用例不是一成不变的。例如自动化测试中最常配到的冒烟和回归测试这两类的自动化测试用例就不应该相同。冒烟测试的测试用例应该更倾向于快速的将主流程进行验证确保当前版本的提测质量值得开展接下去的测试活动也更注重于老用例的套用。回归测试则是针对部分功能修复后对于整体功能与延展部分模块的正常运行是否会有影响这块需要在已修复的功能模块和测试认为有必要开展的相关模块间开展自动化测试所以自动化测试用例会有和冒烟部分重叠的情况出现同时也会新增用于确认相关延展部分的功能正常运行的用例。 2.6 独立测试功能点 这个也很好理解和黑盒测试用例没有区别虽然脚本里会设计某个页面当前整体的线性业务操作但是我们仍旧要确保好每条自动化测试用例中只验证一个功能点切不可图方便把一条用例中放入多个功能点进行确认。这时一定有人会问我多放几个断言不就可以进行多功能确认了吗其实这个观点是违背了测试用例设计的初衷的多个断言自然可以判断多个功能点但大家试想一下一条测试用例中有多个验证点是否会让用例本身的步骤变多且无法拆解这个和写黑盒测试用例不一样的地方就在于你的代码是无法独立拆解出来的。那么接下来的问题就是同样是测试用例是一堆组合后的测试用例复用度高还是独立测试功能点的用例复用度高大家都不用细想答案就已经很明显了。就好比是乐高积木如果需要你设计一座城堡是一整块不规则形状的大积木好还是一小块一小块规整的小积木好 2.7 完整设计 我们除了设计基本的测试用例之外同样也可以利用自动化的优势来进行一些额外的用例扩展设计。在日常工作中我们的自动化测试也不是只要设计相关的功能测试点即可的这里还包括了相关的一些测试数据操作。那么测试数据的前后置操作也就理所当然的变成了设计测试用例中必须的步骤之一了。在黑盒测试中我们的测试数据都会在我们执行前定义或创建好在执行的过程中就会比较的顺畅。而自动化测试中这个操作我们就无需再手动提前进行操作了一般来说我们会把需要生成的测试数据提前的放入某个独立的测试用例内进行预先创建这个称为前置操作其实也就是我们所说的前提条件。而同样的我们在执行完某些操作或业务流之后也可以将这些测试数据进行回收、删除这被称为后置操作。这样我们就可以时刻保证我们的测试环境可以重复的进行同样的测试用例而不会担心环境或数据等因素发生改变。另外因为我们的测试过程是“过不留痕”所以在重要的用例与断言处可以使用截图函数、打印日志等方式留下测试证据以便在出现Bug时方便排查与定位。 好了以上就是关于自动化测试用例的一些设计因素与心得希望可以帮助到大家更好的总结出各自的心得体验。 3. 题外话 之前有收到一个测试同学的意见说博主的有些文章很干这个干不是干货的干。。。。 而是看博主文章的同时不喝点水貌似看不下去。开个玩笑 说内容虽然好但整体略显单调他在面对大篇文字类的技术文章有时会有点眼花建议最好能在文章的段落之间配些图片什么的。真的非常感谢这位同学的意见其实博主也在琢磨着如何让技术文章变得丰富有趣起来但实在无奈品味与才艺有限。。。。。。不然也不干技术了不是哈哈哈这次就先尝试着在文章内加入一些穿插的图片试试看看效果也希望大家可以评论或私信告诉我你们看下来的整体效果如何
