关闭

浅谈ACC测试建模

标签: 框架测试
1015人阅读 评论(0) 收藏 举报
分类:

浅谈ACC测试建模

1、黔驴技穷

随着测试新鲜血液的引入,如何在测试领域站稳脚跟,成为一名老司机是很多测试人头疼的问题,之前听过一个课程讲过测试人员发展的心路历程(图1-1),从手动测试,脚本测试、框架关键字驱动(自动化测试),测试建模,建模自动生成可执行路径,我们大部分测试人员处于底下三层,所以想要成为测试老司机的作习,还任重道远。

图1-1

2、浅尝初试

什么叫做测试建模?关于模型,模型有很多种类型,接触比较多的应该是数学模型,展示成各种公式,但是模型不仅仅只有数学模型,还有语义模型(自然语言表达),物质模型(物体构成的),图像模型(二维的图像、图形等模型)。模型的好处有千千万万,举个栗子:物理学家做了太阳系的模型,可以让我们更了解,直观的看到我们太阳系有9大星球,并且围着太阳转的事实。
为了让我们直观、清楚、了解测试的风险,测试内容,测试过程也有测试模型,测试模型。测试模型没有明确的定义,个人理解是通过建设的测试模型,我们可以直观的分析、了解到我们的测试内容。比如状态图,状态图是一种模型,可以直接了解这个状态到这个状态需要经过的测试路径。
我这次挑选了google ACC建模测试方法进行分享,讲解如何使用ACC建模测试,以及ACC建模方法的适用场景。

3、登堂入室

ACC(Attributes Components Compatibilities)是Google测试团队使用的一种建模方法,详情ACC的使用可以参考文章:http://www.cnblogs.com/liangshi/archive/2012/04/23/2465897.html ,按照文章的内容对测试内容进行划分属性(A),部件(C),组成能力表(C),引导大家做正确的测试策略。这里因为文章写的挺详细的,所以就不照搬文章的内容再讲述一遍,重点跟大家描述ACC建模的适用测试场景。

4、举不胜举

那么ACC可以帮助我们解决什么问题呢?

测试时间短的时候,如何快速选出正确的测试策略

前Google测试总监James Whittaker 提出的《The 10 Minute Test Plan》里面讲述了一个很有趣的实验。现实中,当我们在做测试的时候,从产品需求评审后,到需求变更,测试人员需要不断的更新测试计划,维护测试内容;用例评审之后,我们还可能需要再修改测试内容,对用例再进行二次维护,表露出被这些繁琐的测试文档所束缚。这应该也是很多FT目前面临的问题。

思考一下测试内容需要花那么多心思去更新,并且不断的维护测试策略,在实践中它也发挥真正的发挥到实际的价值?给你带来很强大的风险评估?抑或给你减少了很多测试资源冲突的问题?
如果强迫自己在10分钟内对测试内容提出测试策略,你,可以做到么?

ACC可以帮你快速的做出正确的测试策略。实践ACC的过程中,个人觉得产品的属性决定了产品的功能,也决定了产品功能的重要性。比如一个”社交”的产品P,产品的属性(A)是方便的,信息安全的,UI操作简单的,那么P产品的功能(C)是会尽可能往这些属性上靠拢,功能呈现出能比较被小白用户容易使用的特性(C)。

实例化一个产品:手机管家,手机管家对crash比例要求很高,那么管家的产品属性是要求是稳定的:功能稳定、框架基础稳定。在管家出现crash是需要优先解决的,因为会往这个属性上靠拢,并且各种路径希望能够触发到各种异常出现crash现象;管家对卡顿问题也要求也非常高,制作流畅度的指标来监控各个页面的卡顿,那么也可以给产品定个属性是顺畅的:功能顺畅,页面不卡顿,开发、测试过程也需要观察是否出现卡顿现场。

上述例子中ACC策略是站在产品层面,可能范围有点大。平常测试内容都是一个插件跟模块为单位的,其实也是一样的原理。比如病毒查杀,病毒查杀模块希望它在杀毒方面是全面的,那么也就是各种各样的病毒都能被检查出来,并且做出对应的处理;病毒查杀在交互上肯定是简单的,直接点击查杀,可以帮助手机把有病毒问题一次性检测出来。

下面是我根据launcher桌面应用做的ACC的heap maps ,根据heaps可以得到我们测试时间应该是从深到浅的渐变,如果制作一个跟金钱有关系的软件,你会发现钱涉及的功能的集中了ACC表格的大部分深红,解决问题也是优先解决跟金钱有关系的功能。

测试内容多,繁杂时候,如何做出快速的测试策略

测试过程中,我们经常遇到测试点多,而且细小且繁杂的时候,一堆堆的测试任务涌过来,请花10分钟做一个ACC建模的测试分析再安排测试,先思考再干活。
根据提测的内容在热力图上面的颜色深浅进行测试任务优先级安排,是一种成熟的测试策略。因为深颜色的功能点从优先级,功能属性上都比较重要,所以测试时间上也是需要花比较多的时间。
测试策略没有详尽的测试内容,根据测试点再展开测试用例设计,是一个blingbling的好方法,有根有据,不会被混乱的现状冲昏了头脑,对个人处事风格有优化,格调直逼高大上。妈妈再也不用担心我繁杂的测试任务。

而且针对需求变更比较多的模块内容,前期的维护测试计划的维护需要花很多的时间,而且它并不一定给你评估到如意的完美的测试风险,既然这样子,何不完全抛开这些内容,从ACC的角度来做测试策略。

用例精简

其实ACC也是可以做用例精简,是不是觉得就像万花油一样,测试过程哪里疼就抹哪里。用例精简要从热力图开始说起,热力图罗列了优先级的测试点,这些颜色浅的功能点,大胆放开的去删减用例。因为在整个产品功能里面,它的执行时间占比少,那么对应的用例肯定少。如果一个功能不重要,但是用例写了很多,这个需要反思一下是不是测试策略定位有问题。

综上所讲的内容是在ACC实践的过程中,这些场景可以用这个模型进行尝试。本文只是抛砖引玉,真正成为测试领域的老司机不是一朝一夕的事情,也不是浅尝辄止。需要不断的学习各种Test Model,找到适用的场景,并且得心应手。


TMQ(腾讯移动品质中心)是腾讯最早专注在移动APP测试的团队
网站专注于移动测试技术精华,饱含腾讯多款亿级APP的品质秘密,文章皆独家原创,我们不谈虚的,只谈干货!

扫一扫 关注TMQ

精彩分享不断

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:100327次
    • 积分:2190
    • 等级:
    • 排名:第19022名
    • 原创:120篇
    • 转载:0篇
    • 译文:2篇
    • 评论:15条
    最新评论