首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

对功能测试的一些思考

功能测试可以说是件简单的事情,但是想要做好却并不那么容易。笔者所测的业务是商业化广告相关的CRM系统,整条业务线有18个子系统,很多子系统的流程相当长且繁复,功能逻辑复杂,想要上线后没有漏测着实不容易。不过从我接手以来,有幸还没有发生大的漏测问题。今天笔者就来聊聊自己对于功能测试的一些个人经验和思考。

接到需求后,我一般会将需要做的工作分为三部分,分别为:需求分析、测试用例、以及测试执行。当然,有一个很重要的大前提,那就是要足够熟悉你所测的系统。下面就分别来聊聊这三部分。

需求分析+设计分析

拿到一个需求,第一步应该做的就是需求分析。这个环节很多人不在乎,觉得这不是测试的工作,而是产品应该的工作,测试只是把需求文档简单的直接翻译为了自己的测试用例,当测试过程中发现需求文档不完善的时候说产品没做好等等。但对我个人工作经验来讲,需求分析这一步至关重要,俗话说磨刀不误砍柴工,只有做了详细的需求分析,才能写出有意义的、正确的测试用例,这就是我个人常说的“需求测试”。

需求测试的第一步,需要了解做这个需求是为了什么?你可能会怀疑,产品说做就做呗,测试管那么多干嘛?其实了解需求本身的动机在于以下几点:

1、有些需求是“一次性”的,对于一次性的需求是否有别的方式来实现,如果有我们则可以不去做无用功。所以需求评审的时候,我们可以提出质疑并给出合理的解决方案,减少“一次性”的工作量;

2、更好的理解需求本身,该需求是给什么角色的业务人员使用的,测试可以“站在对方的角度”考虑问题。

3、解惑,对于一个需求文档,很多时候测试做不到百分百的理解的,如果没有完全理解需求的话,在写测试用例的时候很有可能给出错误的测试用例,或者给出一个粗枝大叶的测试用例,这都不是我们想要的。

4、把握测试粒度,以便于正确评估测试工期。例如,一个是给业务人员做的excel上传功能,一个是给系统管理员做的excel上传功能,两者测试粒度是不一样的。业务人员的功能实现必须详尽准确,并要覆盖各种异常处理,而对于项目系统管理员所需的使用上传功能,大部分时候只要保证正常功能OK,不要求易用性,也不要求各种异常情况处理;

5、绘画需求宏图,只有根据需求文档和原型,可以在脑子里画出系统最终实现的各种功能时,才能够说明真正的吃透了这个需求,这时测试用例自然而然就出来了。

需求分析的第二步,就是需求中业务功能的实现,一般分为两部分:

一是页面实现,页面上每个模块的实现,每个模块中每个字段的实现,这里我会做一个工作量比较大的梳理,就是每个字段的取值逻辑,具体到数据库-数据表-数据字段,这有的时候可能要在开发做完详细设计后才能从开发那获取;

二是功能实现,哪个页面上要做什么样的一个功能,以及统计各种业务场景,以及该功能使用的数据库-数据表-数据字段以及数据的变化过程。

现在很多项目没有设计评审,这也是目前笔者正在项目内推进落实的一个环节。如果说一个比较大的项目既没有设计文档,也没有设计评审,到最后你会发现,真的好坑啊,专坑测试,有木有~,比如多个开发相互合作但是最后发现确实各自为政,到联调时发现一堆问题,很容易出现延期提测或者提测质量不达标,还比如一期实现不考虑二期三期,到二期三期时发现一期实现有问题等等;像这种情况,测试有多苦笔者就不说了,自己体会吧~~

所以如果没有设计评审,我也会坐在开发旁边跟他核对实现方案,包括实现逻辑、配置文件以及使用的数据库-数据表-数据字段,以及数据整体的一个流转过程,也方便书写测试用例。根据经验,这个时候其实就已经可以发现开发的一些逻辑bug或者需求理解不一致导致的问题,开发在提测前就能对这些问题做一个修复。这个时候问题解决成本很低,而且对测试而言是一个很大的提升机会,能够让测试更加熟悉了解该需求并掌握开发的实现逻辑,有助于测试过程中定位bug产生原因。

测试用例

目前传统的测试用例越来越少,大多数都是思维导图方式写下测试点,笔者写测试用例主要包括四个方面:

1、UI:界面测试,需求要求的各个模块各个元素,以及隐含的各个元素的通用测试用例;

2、业务功能点:对业务功能点的拆分,笔者一般会覆盖所有的业务场景,包括正向和反向的测试用例,也就是尽量覆盖到开发的所有代码分支。

3、数据库:涉及到的数据表-数据字段;

4、配置文件:测试熟悉掌握配置文件,一方面是能够方便自己排查问题,一方面是提醒开发无遗漏配置文件上线(个人经验,作用不大但是很重要)。

其实这四个方面也是我需求分析、设计分析的四个方面,需求分析做完了,测试用例呼之欲出了。目前总结线上问题,通用测试用例遗漏比较多,例如项目之前没有考虑过广告主名称双引号问题,通用测试用例没有考虑各种特殊符号测试,当真的有了带双引号的广告主时,现有平台不支持。至于功能点的遗漏一般比较少,除非产品、开发、测试都不熟悉业务,造成功能点遗漏或者影响其他功能。

执行测试

这里笔者主要讲下个人的经验,每个人的想法和做法不尽相同,仅供参考。笔者一般将测试分为四个阶段测试:

第一阶段:冒烟测试,主流程正向测试用例,不要上来就执行你的详细测试用例,这样你会常常受伤。

第二阶段:就是一轮详细测试,一轮详细测试的时候,按照模块,尽量一次执行完该模块下的所有测试用例再更新代码,不要测试过程中开发修改bug后立马就更新代码,这样你回去验证bug的时候可能打断了你原有的测试思路;个人习惯是,每天早晨更新代码,然后模块测试结束后更新代码。

第三阶段:二轮测试,我一般称之为bug回归测试,对一轮发现的bug进行回归测试,以及bug周边相关功能的再次详细测试;

第四阶段:回归测试,对第三阶段发现的bug进行回归测试(一般比较少,改一个bug带三个bug的开发虽然有,不过也不常见),以及所有功能的再次详细测试。

以上仅为笔者个人功能测试实施过程中的一些经验和思考,也欢迎各位测试同仁留言探讨。

Qtest是360旗下的专业测试团队!

是WEB平台部测试技术平台化、效率化的先锋力量!

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180312G1J0N500?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券