😏作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
📡主页地址：【Austin_zhai】
🙆目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
💎声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

 
 

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. 题外话

  之前有收到一个测试同学的意见，说博主的有些文章很干，这个干不是干货的干。。。。 而是看博主文章的同时不喝点水貌似看不下去😆。（开个玩笑）

  说内容虽然好，但整体略显单调，他在面对大篇文字类的技术文章有时会有点眼花，建议最好能在文章的段落之间配些图片什么的。真的非常感谢这位同学的意见，其实博主也在琢磨着如何让技术文章变得丰富有趣起来，但实在无奈品味与才艺有限。。。。。。不然也不干技术了不是？哈哈哈，这次就先尝试着在文章内加入一些穿插的图片试试，看看效果，也希望大家可以评论或私信告诉我🙋，你们看下来的整体效果如何？