自动化测试如何区分用例聚集及编写规范

         目录
媒介
业务量和复杂度增长现状是什么？
如何区分自动化测试的用例聚集？
区分用例聚集的过程要注意什么？
自动化测试用例选择
自动化测试用例编写
用例编写规范
结语

---

媒介

前面的文章介绍过如何设计自动化测试case，有同砚在背景问到：业务比力复杂，有很多串行并行甚至组合的业务场景，执行case时常常碰到由于前后依赖导致的case失败问题，该如那边理？
当业务复杂度和工作量上来之后，在具体的实践中这是个避不开的问题。那如何办理这个问题？我建议可以通过按照业务和场景区分用例聚集的方式来办理。

业务量和复杂度增长现状是什么？

以我的亲身经历而言，当业务发作式增长时，测试团队会面临如下几点变革和调整：

对比项	业务增长前	业务增长后
团队构造架构	大团队	大团队小team，按照业务域划分不同小团队
团队协作方式	互相协作，沟通成本低	跨team协作频次变高，构成成本高
团队技能栈构成	比力单一，学习和迁移成本低	技能栈多样，学习和迁移成本高
测试case覆盖率	只覆盖焦点场景，包管主流程正向流程	PO/P1/P2场景，正向逆向场景都覆盖
测试人员职责划分	每个人都认识整体业务流程和场景	每个人只认识岗位职责内的业务流程和场景

这里我们只讨论和自动化测试case相关的区别。
业务增长天然而然带来的是流程的复杂度提升和业务场景的多样性，同时用户体验和线上的小问题影响范围，也会扩大。
因此在测试case的覆盖率上，覆盖的颗粒度会更细致。
以电商下单场景为例：焦点流程在case设计和执行以及效果校验时，主要会关心商品库存、是否使用优惠券、是否加入运动以及订单数据是否入库到之后的是否付出乐成，这是一个正向的焦点场景case。如下图所示：

正常的下单流程能否走下去，主要依赖于上图的几个校验点。
假设，团队按照不同的业务域拆分为好多个小团队，职责和界限划分更细致时，该怎么做呢？

如何区分自动化测试的用例聚集？

还是以电商的主要业务流程为例说明，假设团队拆分的更细致，业务链路依赖更复杂，怎么办？如下图：

可以看到每个链路都会依赖于上下游链路的部门数据或者调用关系。面对如此复杂的场景和跨团队协调，这个时候区分用例聚集的好处就体现了出来。那么如何区分用例聚集呢？看下图：

如上图所示，如果团队是按照业务域或者业务链路做了区分，团队内同砚负责的模块也不一致，区分的大致思路如上。
如何理解呢？就是每个人只负责设计自己所负责模块的case，思量好正向逆向流程的校验点，然后调用和依赖模块对应的场景和数据，和对方约定好，遵循互信原则即可。

区分用例聚集的过程要注意什么？

区分用例聚集的注意事项，主要参考如下几点：

• 业务团队按照肯定的原则划分，而不是混乱；
  
• 每个团队之间要明白好业务界限和职责界限；
  
• 调用依赖和界限遵循同一的调用方式（如restful）；
  
• 测试数据的存储和校验建议同一维护而非各自独立；
  
• 测试用例要按照不同条件做区分（类似打标签形式）；
  
• 连续集成任务要按照前后依赖做好执行时序的区分；
  

自动化测试用例选择

自动化测试主要应用于基础功能的验证和回归，对于在项目迭代过程中不停修改的功能来说，手工测试的服从是大大高于自动化测试的。
因此，我们在举行自动化之前，要挑选基础功能来举行自动化。
在这个过程中，我们可以从手工测试用例中举行挑选，也可以专门为自动化编写一套用例。
在自动化初期，建议从手工测试用例中举行挑选。一方面手工测试用例的覆盖度最为全面，可以包管测试的全面性；
另一方面，也会提高测试服从。
我们挑选用例的原则是：清晰、简朴、基础、改动小的功能。


自动化测试用例编写

挑选完符合的用例之后，就是通过代码编写自动化用例的过程。这个过程主要包括数据预置、用例编写和用例后置三个步骤。
1、数据预置
在举行用例编写之前，我们须要准备一些数据，包管用例能够真正的执行起来。比如，我们在测试一个网页登录功能，我们须要系统的URL参数、须要一个可以登录的用户名和暗码；
我们须要测试删除文件的功能，就须要提前上传一个文件，这个文件可以提前预置，也可以在执行删除利用之前，执行一个上传利用；通过哪种方式预置数据，须要根据项目的现实环境选择。
我们将数据预置和用例编写分开是为了减少用例之间的耦合度，包管上一个用例执行的效果不会对下一条用例产生影响。别的，有利于用例的维护和修改。
2、用例编写
我们准备好测试数据后，就要开始自动化用例的编写，在编写过程中须要注意以下几个方面：
认识业务。自动化测试是为了业务系统服务的，只有充分的了解业务，明白如何将手工测试用例通过自动化实现，才气包管用例质量。
使用变量。通常，我们须要将变量同一管理，写入配置文件，如许方便同一修改。比方：我们须要测试一个业务系统，这个系统包含测试环境和生产环境，我们须要将自动化脚本灵活的适用于每个环境，这个时候，我们就须要将url等系统参数写入配置文件，方便修改和迁移。
写明利用过程。在编写利用过程时，代码解释必不可少。每一步都是怎么利用的，须要验证什么功能。
设置检查点。在编写测试用例的过程中，须要设置公道的检查点，添加断言，判断用例是否执行乐成。在用例执行后，将预期效果和现实效果举行对比，输出测试效果，明白功能是否执行乐成，是自动化测试的关键。不添加断言的用例执行，是没有任何意义的。
3、用例后置
用例后置时指用例执行完成之后的利用，与数据预置相对应，是为了自动化能够循环执行。
比如：我们须要测试文件上传功能，在用例执行通过之后，须要将文件删除，便于下一次自动执行。
别的，我们应该在用例后置之后举行一些公道的检查，比如上个步骤中，我们如果删除文件失败的话，依然会影响下一次的利用。因此，我们须要结合项目现实环境，对一些焦点文件举行检查，包管自动化的顺利执行。


用例编写规范

在用例编写过程中，我们须要服从一些规范来提高用例质量。主要包括：连续性、独立性、完整性、可重用性、可维护性和逻辑分块。
1、连续性
包管用例之间的连续性，包管用例可以批量执行。比如，我们在举行UI自动化时，要包管上一个利用之后进入下一个利用的执行界面。
2、独立性
用例之间要相互独立，包管上一个用例的执行效果不会对下一个用例的执行产生影响。如许，才气更清晰的定位到问题。别的，须要包管一个用例的执行不会修改到下一个用例的数据。
3、完整性
每一个用例都须要有数据准备、利用过程，断言和用例后置的全部过程，能够根据用例明白具体的测试内容。
4、可重用性
类似于开发的公共代码，我们要抽象出自动化测试的原子利用，提供给其他用例调用，如许可以减少开发成本
5、可维护性
用例名要清晰，做到见名知意；对每个步骤、每个变量添加明白的解释；对哪些是预置数据、哪些是检查项、预期效果都有明白的说明；用例步骤要简朴明白
6、逻辑分块
根据肯定的规则举行逻辑分块（比方可以根据不同功能划分），包管逻辑块的独立性，可以抽出单个功能用例举行验证。
 
结语

这篇贴子到这里就竣事了，末了，希望看这篇帖子的朋友能够有所劳绩。
如果你觉得文章还不错，请大家 点赞、分享、留言 下，由于这将是我连续输出更多优质文章的最强动力！
------------------------------------------------------------
感谢每一个认真阅读我文章的人！！！
如果下面这些资料用得到的话可以直接拿走：

 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。