您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 测试用例 > 正文

改造功能测试用例时的一点思考(1)

发表于:2017-08-06 作者:海37度思念 来源:

  最近公司的酒店业务线要增加一个新的分类,跟原来的分类相差不大,不过由于从供应商、服务器架构、接口等都有较大的改动,因此还是需要对新增加的这个分类进行全量测试。
  同时,由于整体流程和功能与原来的与原来的分类大致相同,在综合考虑后,决定沿用之前分类的测试用例,于是,需要对之前的用例进行增、删、改,根据新的需求和新版本,即时更新之前的用例。
  在仔细的看过之前的用例之后,发现用例是从一个页面一个页面一个功能一个功能写的,然后再跑了十几个业务流程。
  对于这种设计思路,有以下几点思考:
  (1)、这种设计思路整体上来说是先功能、后流程,以功能为主,流程次之,功能和业务流程用例有区分,在执行时,能够让测试人员专注于某一个页面或某一个功能进行测试,不至于因为测试过程中频繁的去关注功能和流程直减的切换而分心。
  (2)、单独功能和页面有充分测试。对于每一个页面、每一个功能都有测试用例,对于功能和页面的测试比较充分,这方面遗漏比较少,充分保证了功能测试的全面。
  (3)、对编写人员和新人深入了解所有页面和功能有较大的促进作用。根据每一个页面的每一个功能来编写的用例,所以对于所有可能存在的页面和功能都有着比较可靠而完整测试,无论是对于编写用例的老员工还是新人,在促进深入了解功能方面,都有很大的帮助。
  (4)、对编写人员对于业务流程的理解要求非常高,学习成本相对较高,而对于编写的整个过程,是相对比较简单流畅的。用例编写的时候,需要编写的人对整体业务流程、每种可能出现的页面都要有非常深入的了解,这一般需要一段相对较长的时间,学习成本相对比较高,对于新人快速了解整体业务流程和用例的设计思路有较大的阻力。不过,只要对页面和功能有足够的了解,在编写用例的时候,则是相对比较简单流畅的。
  (5)、频繁切换测试入口,增加执行成本和步骤,导致执行时间无法准确有效评估。每一个页面或功能相关的用例都是相互关联的,而与其他流程之间的用例,则相对过于独立,所以经常就会出现前面一个用例测完离提交订单只有一步之遥了,而到下一个用例的时候,就莫名其妙的跳到了另一个分类的提交订单页面,而步骤却少的可怜,只有预置条件中说了一句处于某个分类的填写订单页面,而且用例之间还相互关联,甚至依赖。这样频繁的切换入口,无形中增加了测试用例的执行难度和执行步骤,对于根据用例数量来评估执行时间进而评估整体测试时间是不利的。
  (6)、流程测试相对不够充分。在算上为了进行功能测试而同时执行过的业务流程,再加上专门执行的业务流程用例,一共执行了20来个业务流程用例,而在根据整体业务流程各个条件进行组合后发现,若将所有条件都考虑进来,则有上千个业务流程组合,在尽可能压缩条件的情况下进行交叉组合,也存在一百来个业务流程,即使去掉重复或不存在的流程,也至少存在大几十甚至上百的可能组合。很明显,之前的用例对于业务流程的组合情况考虑的不够充分,存在业务流程的遗漏。
  (7)、在执行流程测试的时候,难免会存在对功能测试的重复执行。
  为了避免流程遗漏,执行时间可控,决定花时间对用例进行整体改造。
  最初的想法比较简单,既然之前的用例是以功能为主,流程次之,那么就想当然的认为改成流程为主,功能次之。不过存在以下几个问题:
  (1)、业务流程会比较充分的测试了,不过对于页面和功能,则难免会存在遗漏,尤其是有些出现机会很少的例外页面以及功能。而且,对于页面和功能的测试则难免会不够充分。如何确定两者之间的关系?
  (2)、对于页面和功能的测试,是单独拧出来,还是穿插着测试?单独拧出来,会不会出现重复执行,会不会遗漏?
  (3)、怎么去筛选流程,才能尽可能的保证流程测试比较充分?怎么确定流程就充分测试了?
  (4)、怎么平衡用例数量和测试的充分性?如果要充分的、全量测试,光流程都有上千了,量太大,执行起来更加要怀疑人生了。对于数量和充分的平衡点,怎么确定?