浅谈ACC测试建模

来源：互联网发布：ubuntu jdk rpm 编辑：程序博客网时间：2024/04/26 11:19

浅谈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，找到适用的场景，并且得心应手。