走进标准化测试

一、引言

为避免大篇幅的概念介绍，我们直接从项目实践入手，为读者朋友理解标准化测试。在开始，只要理解标准化测试是为了解决项目测试实际问题而产生的测试方案即可。

二、背景介绍

手机QQ浏览器（iPhone）项目测试在2014年采用探索式测试改革后取得了不错的效果，但是近两年来项目发布节奏加速，测试任务量剧增，与之对应的测试人员编制并无扩大，且外包流动性很大，如何在原有的基础上继续提升测试效率和质量是一直以来我们一直在琢磨的事。我们面临的主要问题包括：

2.1新旧外包交替

新旧外包交替，隐性经验传承不够好。

大外界环境竞争比较激烈的情况下，外包测试的流动性比较高，在新旧人交接过程中不可避免的存在一些经验损耗问题，例如被测app在横屏模式下特别容易出现错位的问题，这些在交接过程中是甚少涉及的。

2.2二维表的形式指导测试

二维表的形式指导测试，颗粒度太粗，测试过程未知风险多。

在过去的自由测试阶段，我们通常采用二维表的方式来指导探索式测试活动，主要是将公共模块和特性模块交叉测试。因为特性模块之间也可能存在耦合影响问题，后期又想发展到N维表，但是没有切实可行的方案。这个方案颗粒度比较粗，虽然赋予了测试人员较高的自由度，但是缺乏了强有力的指导性，导致测试结果强依赖于测试人员的自觉性和经验。

2.3对测试记录的态度比较含糊

对测试记录的态度比较含糊，控制不好成本。

测试记录是把双刃剑，大家都知道多做测试记录能够更好的管理和优化测试过程，存在的弊端是测试记录会导致测试思路中断，或者导致测试耗时，在没有找到合适的测试记录方式前，我们没有对测试记录做硬性要求。

2.4测试策略制定不够灵活多变

测试策略制定不够灵活多变，对需求变更或者发布节奏变动适应不佳。

随着大资讯时代的到来，手机浏览器呈现出一种越来越多元化的面貌，要随时能够响应时下热门需求，又要应对苹果时时更新的Appstore规则。计划可能是40天发布一个版本，实际上可能40天需要发布3个版本来响应市场变化。这种情况下的测试时间和人数并没有可增加的空间，只能通过测试策略的调整来应对。之前的测试分析并没有考虑过制作随时可变得测试策略，而是针对迭代、集成、上线这种模式做的相对固定的测试策略。现在要求集成测试这种类型的测试要能随时提供1天、1.5天、2天、3天等不同时间，不同测试范围和重点的测试模式。迭代测试也要能够提供含用例测试、速测（例如半个小时无用例验证）、顺便测（测试某模块的时候关注下是否影响其他模块）等不同的测试模式。这些变化都要求更为灵活的测试策略，更为透明的风险提示。

重点摘要

这些问题的出现，反映了我们测试活动中虽然有很多方法和工具，但是还是缺少一种隐形的指导标准。大到测试策略的选择，小到具体测试内容，都有一个看不见的手在指引着。我们本着解决实际问题的初衷做了一系列的应对策略后，最终将这个隐形的手作为一种测试标准化呈现。

三、应对策略

接下来针对上述问题，手机QQ浏览器（iPhone）项目的测试采用了三个基于的方案。这些方案不全部是近半年的创新，也有对过去旧有技术、方式的继承。

3.1基于用户

通常一个新人熟悉被测产品是通过阅读和执行用例的方式，这些用例当初设计是根据历次需求文档转换而成，具有比较鲜明的版本特色，不能很系统的表述产品可提供的服务特性。而系统的描述产品特性是能够有效指导自由测试阶段探索式测试思路的。之前有特性描述二维表的形式，在这个基础上我们进行了进一步扩展和细化。

3.1.1 九大用户维度

在历次版本的海量用户反馈中，我们积累和提炼出了手机浏览器九个基于用户使用维度的价值点：获取信息、编辑、下载、社交分享、播放阅读、隐私安全、商业能力、杀手应用、多快好省。解释下各个价值点的意义。

①获取信息

浏览器最重要也是最直观的价值，就是能为用户提供获取信息的渠道。落地到具体的模块举例看，就是搜索服务要能够正常使用，获取到用户想要的内容，不可以白屏，不可以点击搜索崩溃，页面展示要能够完整无越界，书签能够跳转到对应的链接等等。这些是浏览器的核心质量，不可以出一点问题。

②编辑

编辑是一般APP都具备的价值，被测APP上能够提供给用户可编辑的界面和工具。例如下载好的内容可以保存重命名、删除，书签快链可以添加删除，搜索引擎可以设置，小说可以在书架里移动位置等等。编辑属于浏览器或者一般APP所具备的必备价值。

③下载

下载是很多应用类app提供的能力，浏览器可以提供文件类的下载，也可以提供部分视频的下载。这是一个卖点价值，包括很多视频播放类软件、应用分发类软件都应具备这种能力。这种下载使得APP能为用户提供无网络状态下的服务。从下载这个价值点维度上看，浏览器下载在很多模块中都或多或少有涉及。

④社交分享

社交分享是很多内容类应用常见的能力。浏览器作为内容呈现的容器，必然要有社交分享这个价值点，可以分享、传播到第三方APP。当然也包含了账号登录体系，内容同步，在游戏里还涉及了账号体系里的好友竞技。

⑤播放阅读

播放阅读是着重强调可播性可读性的价值点，例如文档类的解压阅读、视频的播放、小说阅读的流畅性等等。播放阅读是浏览器是否好用的一个非常重要的指标，因此可以列入价值点的一个分类中。一些小说阅读软件、微博产品在这方面都可以参考借鉴。

⑥隐私安全

隐私安全是价值点中不可不说的一个维度。一款好的APP在保护用户隐私方面应该不遗余力，对于浏览器来说，要检测危险站点，要保护用户阅读记录。这些隐私安全体现在各个模块的各个角落，单独列出来，特别关注新增功能和旧有功能对隐私安全方面的质量要求。

⑦商业能力

商业能力是指APP中涉及到用户付费或者运营广告的地方。因为付费环节是APP开发者的主要收入来源，也是用户比较敏感的环节，所以需要格外关注。广告运营也是APP盈利的一种模式，需要特别关注。在商业能力方面任何一个地方出现问题，都会引起极大的经济损失，并损害用户利益，所以需要特别关注。

⑧杀手应用

杀手应用是指APP为提升用户活跃度做的功能，例如下载该APP，可以提供免费wifi，又或者能够帮助用户拦截恶意电话之类的。给用户带来附加值，是有效提升日活和拉新的重要。因此称之为杀手应用，对杀手应用的测试也十分关键。杀手应用也可能存在于各个模块中，所以也单列为一个价值点维度。

⑨多快好省

多快好省更强调指性能方面的要求，倡导内容丰富（多）、速度流畅（快）、使用便捷（好）、省流省电（省）。这样通过多快好省就把测试范围从功能测试扩大到性能指标一起考虑了。

3.1.2 大纲级别质量标准

这些价值点作为表格横轴，纵轴上是手机浏览器各个FT（或者模块），我们称之为承载体。每个承载体在不同的价值点上都可能承担一定的实现。我们将横纵列表交叉的空间写上质量标准，如下表1所示，由于篇幅所限，不能详细列出九大维度在全部FT的全部质量标准。例如在内核重构时，我们需要验证网页浏览的问题，表格中在就大维度都给出了详细的质量验收标准。

表1 大纲级别质量标准

承载体的划分在手机QQ浏览器（iPhone）上分了几大模块，分别是：小说、视频、搜索、资讯、书签、历史、游戏、活动类、文件、TOP网页、识别。将浏览器设置相关的内容都放到变量里。各个承载体都有多个入口，这里就不一一介绍。读者朋友对自己需要测试的APP也可以按照属性进行承载体划分。

重点摘要

价值点和承载体交叉的部分是质量标准。每个模块在对应的价值点都其要达到的质量标准，这个质量标准对我们的测试起到的作用就是简洁的概括了测试目标，具体的内容还得看细化承载体和价值点。

举个例子看下，比如小说在信息获取这个价值点的质量标准阐述就是：支持书城内搜索小说、push更新。看起来比较像“黑话”，实质上给常用浏览器的人来说就比较清晰了，就是小说这个模块需要提供搜索小说的能力，对小说的更新提醒也要实现正确。这里可能就会有疑问了，如果是新人如何快速看懂，不要急，我们在细化承载体和价值点上进行更具体的说明。

3.1.3 细化质量标准

细化的承载体和价值点，是指在大模块的承载体下，进行细化，每个组成大模块的具体模块都承载着价值点的具体实现。举例如下表2所示，由于格式所限，不能看完整的。用文字给读者朋友具体来说明下。搜索这个承载体细化分，可以分为：切换搜索引擎、搜索直达、匹配和推荐、垂直分类、搜索记录、搜索结果页、网页内搜索。

表2 细化质量标准

这些细化的承载体简单看就是各个入口、各种功能实现分类。通过这些组合而成的搜索大承载体。每个承载体在价值点上具体的质量标准，这些细化的质量标准就是进一步指导探索式测试的启发式列表。有些价值点在承载体上不涉及，就可以直接标注不涉及。

还是举例来细看，在搜索的细化承载体“切换搜索引擎”在价值点“编辑”上的质量标准如下：

1）搜索框切换搜索引擎

2）搜索过程中，仍可自由切换搜索引擎

3）重启、前后台切换、升级后保持搜索引擎

上述三条描述，列举了具体的切换搜索引擎的场景，但是怎么样自由的切换搜索引擎，以及如何保持搜索引擎设置，就需要结合经验来选取不同变量来不断尝试了。

3.2基于经验

前面基于用户，我们尝试在测试中细化测试标准，从全新角度定义测试出发点。那么有了好的出发点，能否有效进行测试，还要基于测试人员的应变和经验能力。这也是背景介绍里提到的问题之一：如何传承隐形经验。口授的形式固然是好，只是信息损失比较大，也存在一时想不起来的经验。为此我们特地对各大重点FT的特性可变变量以及浏览器通用变量做了整理和分类，以期能将测试过程中的经验有效传达。

3.2.1 变量因子

通用变量如表3、4所示，我们把变量分为APP设置、手机设置、外部环境、输入操作四个部分，每个部分又有不同的分类和变化内容。APP设置主要是来自于被测APP的一些公共模块，各个功能模块都或多或少的涉及了一些，因此不作为价值承载体，而是作为变量单独列出。手机设置是指能够影响被测APP使用的设置项，例如横竖屏锁定、机型系统等等。外部环境是指被测APP所处的环境，例如网络、测试环境等等。还有一个重要的变量，我们称之为输入操作，是指对一些APP常出现问题的操作做个归类，用于指导和提醒测试人员测试过程中多多尝试这些操作，例如连续点击、快速后退等操作。

表3 通用变量表

表4 通用变量表

除了通用变量，一些模块也有自己独特的变量环境，例如手机QQ浏览器中小说书架，就有其特有的变量，如表5所示是小说模块的变量部分表。模式里就含了书架的宫格模式和列表模式，文件格式变量也格外强调了小说类型的格式例如epub格式。

表5 小说FT变量表

3.2.2 测试策略

使用变量，涉及到测试策略选择的问题。我们推荐在测试过程中思考下一步操作。同样的，测试策略也作为启发式列表提供给测试者。分为通用策略和推荐策略。通用策略按照模型分为漫游模型策略和场景模型策略。由于篇幅所限，如表6所示是漫游模型的部分策略说明，我们将漫游模型中比较接近的方法归类到一起使用，为了增加趣味性，我们将这些策略印在扑克牌上，将策略的说明放在扑克牌正面，举例放在扑克牌的反面。除了趣味性还有个好处，就是可以不断补充扑克牌的内容，鼓励测试人员每个个体发展新的策略，拥有独特的扑克牌，时间长了就知道哪些扑克牌在哪些场景下更适用，更多地发现bug。

表6 漫游模型表

除了漫游模型，还有场景模型如表7所示，也是采用扑克牌记录方式。场景模型策略的使用也是很方便灵活，在测试过程缺乏思路的时候可以随时运用场景模型的策略进行变化，结合不同变量因子更是可以产生出不同的路径效果。

表7 模型操作表

3.2.3 动态测试

有了上述的质量标准和变量、策略，具体怎么实践测试内容的可以参考下面的例子。

手机QQ浏览器（iPhone）有个功能叫做空间清理功能，如图1左图所示，在工具栏——文件入口最下方有空间清理入口，点击进入可以看到如图1右图所示的界面，可以清理大文件，整理图片。现在就以测试这个功能为示例，进行说明动态思考的过程。

图1

如图2所示，切入点是文件承载体的细化承载体“空间清理”在价值点“信息获取”上的质量标准：能够扫描到目标文件。第一步操作就是点击进入空间清理界面，观察结果，显示大小为0B，根据这个结果进行思考：会不会是这次启动或者过程操作有问题，再进入一次会怎样？按照图示的过程反复进行“思考→执行→观察→思考→执行”的循环。思考的灵感可以来自于漫游模型或者场景模型的策略启发，执行的时候选择不同的变量操作。

图2

动态测试持续进行中如图3所示。这里关注的是过程记录，就是在测试过程中可能产生多个疑问需要确认，也可能需要小伙伴协助验证，也可能偏离主思路有很多想法，发现一些测试策略制定时没想到的内容或者风险，这些都可以记录下来。疑问需要确认的可以先留言给开发，需要小伙伴验证的可以丢到群里，偏离主思路的可以先记录，等完成主思路验证后再进行，过程中发现的风险也可以给测试负责人以及其他结对测试的同学以参考，给项目组最终的报告也可以有所注明风险。

图3

测试继续，如图4和5所示，在图5中涉及到了支线思路，这部分内容可以邀请同事一起来结对测试，也可以记录下来等后期有时间再测试。另外就是对过程中提出来的问题，要有所思考，对疑问点的可能回复要有所预期，如果是回复是某种预期答案，那么自己的进一步问题要及时提出来。当然，根据SBTM模型，测试过程这个时间窗是不受干扰的时间，所以这些疑问也可以等着测程结束一起提交确认。

图4

图5

通过历次测试过程的bug积累、用户反馈、客观存在的变量进行经验汇集，再结合优秀测试人员的测试经验集合，最终为当前测试人员提供了相对详实的经验库。

3.3基于风险

有了基于用户的质量标准，基于经验的变量和策略，实践中还需要根据实际情况相机而动，就是所谓的兵无常势，水无常形。这里涉及到每次测试策略的制定标准，这个标准的制定我们选择了基于风险。毕竟测试资源是有限的，不可能穷尽测试，要把资源和时间投入到风险最高的地方，基于当前的情况灵活制定测试策略，达到最佳测试效果。

既然是基于风险，那么风险有哪些途径获得，获得了风险后又是怎么指导测试的呢？我们参考了下James Bach于1999年提出Heuristic Risk-Based Testing（基于风险的启发式测试）理论，风险的两种分析方法Inside-Out和Outside-In，我们在这两个分析方法的基础上进行扩展和引申，可以帮助我们梳理测试活动。

3.3.1 Inside-Out

本意是从内到外，用到测试风险上就是分析被测对象内在的风险，映射到外在的表现风险。这种内在的风险跟被测对象的版本有着强关联性，会基于版本、基于代码、基于需求。一般来说我们获取内在风险的方式主要有需求分析、代码分析、缺陷分析。如下图6所示。

图6

①需求分析是根据被测对象当前版本的需求进行评估，例如引入了分享的功能，就要考虑到跨版本跨平台分享的打开成功率问题、考虑分享回调的问题等等，从这个需求分析可以引申出大量的外在表现风险验证问题。通过对需求分析，可以将测试活动有根据有方向的展开。

②代码分析是根据当前编写的代码自身存在的风险进行评估。这个工作一般由该模块对应的开发或者有代码分析经验的测试人员进行，精准测试比较成熟的项目可以用精准分析的方式来自动评估出影响范围。例如重构了网页预加载机制，开发根据自己的代码评估可能会影响到一些浏览器自有页面的打开问题、影响到一些搜索直达页面的打开问题，影响到页面打开速度和内存问题。通过代码分析，可以清楚获取当前被测对象内部的修改可能会影响到的外在表现，为测试活动提供了风险范围。

③缺陷分析是根据当前或者相关模块已经发现的Bug来对被测模块进行风险评估。例如已知书签文件夹存在URL为空的问题，那么对应的spotlight搜索功能就应该着重检查下书签文件夹和书签两种形式的搜索。从已知bug着手，可以快速定位风险范围，一般用于测试后的bug分析经验积累，以及回归测试阶段的bug相关风险验证。

3.3.2 Outside- In

本意是从外向内，用到测试风险上就是将通用的风险列表一一映射被测对象，检验被测对象是否有这样的风险问题。这种通用的风险是历次积累的风险列表，与被测对象的版本没有强关联性，被称之为外在风险。通常来说，我们获取外在风险的形式主要有两种，如下图7所示：一是测试用例，二是风险检查点。

图7

①测试用例，区别于需求分析设计出来的用例，它是已有的用例，也即上一版本保留下来的仍然有效的用例。通过对之前的用例的执行来检查被测对象新版本是否引发了已有功能的问题。

②风险检查点，主要是依据被测对象必须能够给用户提供的能力来进行的风险排查列表检查。常见的形式有：上线前测试核心能力检查列表、集成测试必测检查点列表、全系统覆盖测试检查点列表等等。这种检查点列表所罗列的内容比较粗线条，给测试人员以比较大的发挥空间。

3.3.3 提测和回执

手机QQ浏览器（iPhone）项目中，如下图8所示，基于每日自动化测试BVT之上，我们按照基于风险的分析方式将测试活动分为Inside-Out和Outside-In两部分。Inside-Out部分的分析可以帮助指导Outside-In的内容调整，反向的，Outside-In这部分的实践结果也会推动Inside-Out的评估。

图8

图中左侧的Inside-Out内容在风险分析里基本都解释过了，右侧的Outside-In的内容看起来比较陌生，逐一解释下。

①基础用例测试。这里的基础用例和Outside-In中的测试用例的定义基本一致，是指历次版本保留下来的有效用例，当然了新增用例在经过测试后也会合入这部分中。不同的是基础用例里只包含了对需求验收级别的用例，换言之，就是比较少有需求描述之外的用例，例如复杂场景或者多模块组合测试的用例。执行基础用例测试后可以保证被测对象的主路径是经过检查可以得到最基础的质量保证。这部分工作采用人工测试还是自动化测试的方式要视项目组的实际情况来决定。如果存在需求经常变动的情况，只把历次版本基本不会动的核心功能做好自动化测试，其余基础路径还是采用手工执行的方式，类似手机QQ浏览器（iPhone）项目。但如果项目周期比较长，UI改动比较小，或者有稳定的接口，就可以尽量采用自动化测试的方式来进行基础用例测试。

②用户维度的质量标准。这部分其实是基于用户维度介绍的大纲级别和细化的质量标准。

③变量因子及策略推荐。这部分是基于经验的变量因子，以及漫游模型和场景模型中的各种测试策略。

重点摘要

实际在提测的时候，结合Inside-Out的内容动态调整Outside-In的内容，例如需求变动会调整基础用例的内容，代码变更会帮助圈出哪些质量标准和变量因子需要格外加重测试力度。Outside-In是一个相对独立于版本之外的通用测试指南，随着每次版本更新来做动态修正和补充，更好的应用于后续的测试活动。

还是举例来看，由于集成测试需要覆盖的承载体比较多，根据最近的代码变动、新增风险需求、bug分析产生的推测风险，与对应开发勾兑后，我们圈出重点测试的承载体、结合再结合经验推荐一些高风险变量因子和测试策略，将不需要覆盖的内容可以置灰，需要特别关注的可以标红，下表8所示。

表8 某次提测表

推荐策略和变量可以另外附表提测，由于截图比较大，此处不全面罗列。只给举例介绍，举例手机浏览器的文件模块，因为文件常见的路径是下载和编辑，因此常用破坏测试法、极限测试法来对被测内容进行检测，还会采用竞争对手测试法，检查对文件不同格式的支持。因此推荐的策略是：破坏测试法、极限测试法、竞争对手测试法。当然不同的测试负责人推荐的策略可能不同，这些推荐策略只是给执行的测试工程师以指导，而非只用这些策略。对于变量的推荐，可以考虑网络环境的变更会影响下载，机型的大小可能会影响显示等等。因此推荐的变量因子是：网络、机型系统等，具体的每个不同模块还可以采用更多的变量，决定权在于执行的测试人员。

具体的测试过程可以参考基于经验的动态测试测程。

在动态测试内容结束后，要集合每个测试人员的测试结果汇总。如下表9所示，是某次集成测试回执。从该回执表中可以很明晰的看出各个主题测试的负责人、机型系统覆盖度、发现缺陷严重比例、风险疑问以及对策略的补充。

表9 集成测试回执表

从表中还可以获取数据可以指导今后的测试调优。

①从发现缺陷数量上可以观察那些测试人员发现缺陷的数量总是落后于平均水平，哪些测试人员擅长发现严重缺陷，可以进行人员调优。

②这个表中没有写上时间的分配状况，是因为集成测试的时间相对集中，都是在制定时间窗中进行的，如果是迭代测试可能就会被干扰比较多，如果从回收的表格中发现被干扰时间长的情况就需要进行时间调优处理了。

③可以从风险问题中确认测试环节被什么干扰或者说影响到，可以进行测试内容优化。例如表中提到了测试频繁换包，影响测试。这点就可以和项目组进行沟通协商，如果无法避免，有什么方法能最大程度的降低换包带来的负面影响。

四、实践收益

4.1充分利用动态思维

手工测试目前来说还是要存在相当长一段时间，尤其在iOS测试上。在这个事实基础上，如何有效利用手工测试的优势，就成为了有效开展手工测试的必然研究课题。从探索式测试兴起之初，人们就发先偏离预设脚本的测试能够发现更多的问题，这种偏离预设脚本的测试是基于人脑的即时判断和丰富的经验联想，我们将其称之为动态思维，这种动态思维是短时间内人工智能所无法追及的，也是人工测试独特而无法取代的魅力。通过标准化测试中的动态测试测程设计，我们可以放大这种动态思维的优势。主要通过三个方面来进行辅助和完善测试人员的动态思维。

4.1.1 有章法

我们提供了承载体和价值点对应的质量标准，让测试不会漫无目的。这点在传统测试中也会有所涉及，比如提供一些风险点来指导自由测试。在标准化测试中并不是一种创新，而是将这个质量标准的选定和实施做了标准化，使后加入项目的人也能够快速理解和制定质量标准，将之形成一种规则，而不是可选项或者有经验人的独有方法。

4.1.2 有提示

在大家都了解测试的验证目标后，在过程中为了辅助测试人员的动态思维，我们提供了启发式列表，例如变量因子和策略。在测试人员思考过程中，如果经验老道，根据测试现象能够自发的联想下一步操作，可以不必参考我们的提示列表。但是对于新人或者思路中断的测试人员来说，变量因子就是测试线索，策略就是组合线索的方式，在观察到一种测试现象后，不断自我提问和验证结果，使思维活动进行下去。

这个提示就像是登山时的拐杖一样，能够确保测试活动的流畅。另外一方面，以前经常出现问题的变量因子或者在该模块经常容易发现问题的策略，都可以标记为高风险因子上并做特别说明，测试人员一定要覆盖到这些因子，也即有些坑坑洼洼的地方登山拐杖必须要使用。

4.1.3 有记录

手工测试过程中，遇到了问题，或者思路出现几个分支的时候，都需要及时记录下来，有记录这点其实也是一种要求，我们对测试记录的要求要做定性定量的规定，哪些内容要记录，哪些内容可以简化。做记录的要求是尽量降低记录的成本，真实有效反馈过程问题。在这个记录成本上看，测程回执表的记录在多个版本多人次的实践结果来看，成本几乎降低为零，原因是测试记录标准化后，形成一种自然而然的过程记录习惯，不会造成额外的负担。

重点摘要

上述三方面本质上是保持人工测试的动态思维流畅性，并利用过往经验对高风险问题进行重点覆盖。这三个方面没有特别独特的创新，只是在现在测试已经有的一些思考上进行了标准化定义和规范，使之能够尽可能的辅助测试活动，保持思路的灵活，降低学习和使用成本，规避过渡发散。

针对动态思维的辅助作用，分别从学习成本（了解标准化测试方案的目的、方式）、启发式信息使用率（含质量标准、变量、策略）和使用成本增加（过程记录耗时）对手机QQ浏览器（iPhone）测试团队进行采访获得如表10所示数据。可以看出关于学习成本实际情况要超出我们的预期，新人比有经验者更加依赖于启发式信息，有经验者更倾向于顺着自己的思路进行测试，而在增加的使用成本方面，基本都认为不存在什么增加。当然样本比较小，不足10人的团队，仅供参考。

表10 采访数据

4.2标建立用户角度测试模型

黑盒测试的困惑在于不知道软件内部结构，是一种盲目的“触探”。很多人都知道黑盒测试的弊端，却很少有人想到黑盒测试的好处。放大黑盒测试的好处，就可以有效扬长避短。黑盒测试的好处在于测试成本低廉，只要会用户操作就可以进行，由于不了解内部结构，就不会受到内部设计思路限制，完全从用户角度出发进行扫“扫雷”。

标准化测试方案的承载体和价值点就是从用户角度进行选取的，建立的是一种基于用户视角的测试模型，这种测试模型脱离了最初的需求设计说明思路束缚，也没有再去细究代码实现函数是否规范，而是真的跳出了研发团队，从用户的角度重新审视产品能够用户带来的功能，抽象定义了几种大类价值点。然后再从被测软件的各个模块在这几大类的价值点上实现做一个质量标准的定义。这些质量标准就像是航行中的灯塔，指明了测试人员在探索式测试活动中所应该持有的质量原则。

从实践数据来看，在用户视角的测试模型指导进行测试能够发现更多的问题。传统的测试在用例之外展开的自由测试，很大程度上会受到用例的束缚，往往自由测试中还是会在一个圈子里无法走出，发现问题就不会很多。另一方面，通过用户角度的测试模型的建立，还能够帮助测试人员快速制定测试方案，基于已有的质量模型和变量策略，能够快速圈定测试重点和风险点。如表11的对比数据来看，采用标准化的用户模型可以在缺陷挖掘效率、测试设计耗时（临时变更需求和大规模功能测试前的测试方案设计）方面有明显的提升。

表11 是否采用用户模型对比数据

4.3标测试过程及管理优化

外包模式的困惑在于对异地工作或者多人合作测试模式下的过程控制和管理。这个困惑的解决，最佳的方式就是有过程记录，这点应该都有共识，这个过程记录的优劣又会直接影响了测试效率和质量。标准化测试方案中对测试过程的记录有硬性要求，成为必选项，并且对具体记录的形式和内容有着明确的要求，能够帮助测试人员做好过程管理和优化，更多的暴露过程中的风险，为优化效果提供数据支撑。

如表12是采用标准化测试方案后的测试过程记录的效果对比，可以看出没有采用良好的过程记录，测试人员暴露出的风险和建议都是很少的，被采纳的建议和被评估的风险就更少了。直接导致了测试负责人或者项目组对测试活动的管理和优化缺乏有效数据和材料。外包测试模式下，通过采用科学的测试记录指标和记录方式，能够有效提升过程反馈率，无论是对测试质量的提升、测试活动调优、还是对风险的暴露都有好处。

表12 测试记录对比数据

通过良好的过程记录，能够将外包测试模式的弊端进行规避和解决，降低沟通成本，将整个测试过程变得更加可控。

五、普适原则

5.1标准化测试定义

到这个环节，需要提炼总结一下标准化测试的概念了。从上文可以看出手机QQ浏览器（iPhone）项目的测试改进思路是从实际问题为出发点，找到一些不明晰或者隐形的规则，使之明朗化，再加以业界的先进理论辅助，使得测试活动更加精细灵活。这个测试过程看起来像是有一个标准在指导着进行，这就是命名标准化的原因。然后此标准并非流水线标准，而是一种思路引导，每个角色在测试活动中都有章可依。

5.2思路梳理样例

好东西要分享，但是却不能直接拿来使用，每个项目都有自己的特点，需要根据项目实际进行借鉴参考。如果要实现普适，尤其是方法论和思路的普适，很容抽象提炼出“真理”，难于理解又不易应用。这里笔者给大家大致抽炼总结下手机QQ浏览器（iPhone）项目标准化测试的实践思路。

对背景介绍的内容做个总结，该项目测试的主体背景有两个：测试质量强依赖于自由测试阶段测试人员的缺陷挖掘能力、测试策略要随时跟着版本发布节奏快速调整。这样下手改进的点就由这两处入手，如何提升测试人员的自由测试阶段发现bug能力，并有效传承这种能力，如何快速制定测试策略来调整测试活动适应日益多变的发布节奏。

我们基于用户维度重新定义了测试视角，为自由测试阶段的提供了精细的质量验收标准。基于经验将测试人员历次积累的高发风险变量、方法思路做了归类整理，对动态测试的过程做了标准示范。基于风险划分测试活动类型，由内而外的风险指导测试策略制定，定义了相对灵活的策略制定标准。

收益方面要回归原始问题，是否解决或者改善了自由测试阶段测试阶段的种种问题，是否能够给项目组带来好的测试体验，配合版本稳定发布。

5.3其它项目启示

换一个项目，可能焦点问题不在于自由测试，也不在于变化的发布节奏，有可能是外包测试的基础素质，又或者是对技术问题的理解力，不断变化的需求等等。由于笔者没有真的在这些项目中实践过，所以不能一下给出详细的改革建议，但是道理是相通的，哪里有问题就深挖哪里，看看能不能找到其中隐藏的标准。

例如对技术的理解力问题，就多从有经验的人身上研究为什么他/她能够快速关联到测试内容，其他人是欠缺了哪些知识积累，或者是缺了哪些思考方向，能否将这部分内容作为list，或者做个思考过程标准demo，通过这些尝试渐渐让技术门槛变得有阶梯可攀登。

再举例如果是每次测试内容都不断变化，是否尝试“以不变应万变”，每次内容变动获得信息的来源是哪里，在于相关人沟通测试内容是否有一套基础的沟通规则，对提测人的每次提测是否能整理出一套可执行的标准，让提测内容变得更加好操作。

重点摘要

总体来说，标准化测试应该可以走进各种项目中去，需要的就是测试人员不断的去思考问题，想到契合自己项目实际的入手点进行精细化改进。找到变化中的不变，找到杂乱中的有序，使之形成可见标准，造福项目测试。

六、番外

在这个长篇大论的最后，忍不住写个番外。从研究标准化测试之初，iPhone浏览器测试同学就开始玩起跳棋，可以说研究了多长时间的标准化测试，就对应跳棋这个活动在我们这里兴起多久。有时候想，标准化测试和跳棋之间有没有什么关联呢？想着想着，还真的发现有神奇的共性。

跳棋规则简单易学，几乎玩过的都能快速掌握。测试这个工作呢，看起来似乎也是人人都可以做。跳棋要想取胜要看开局（测试策略）、过程局势变化（根据上一步测试结果决定下一步方向）、旁人提点（辅助工具），最后取胜之时还要看胜出了几步和耗时多久（测试效率和发布节奏）。跳棋要想下好绝不是无章法可依，要在实践中不断琢磨研究一套克敌制胜的套路（标准化），还要视棋友（被测对象）的不同风格和水平（项目复特殊性和杂度）变化出不同的招数（定制化）。这个套路（测试标准）做得好了是一本好的棋谱，可以帮助人快速上手跳棋（测试），但是套路也不是唯一的，因此还需要下棋人（测试人员）能够灵活掌握。

还有个大胆的设想，如果棋谱足够完善和智能，可能真的就是测试人员需要退出历史舞台的时候了，相当于人工智能测试时代的到来了。只是目前为止，套路（标准）是可以提炼，但是只是书面的棋谱，暂时不能取代人脑的思考和判断选择。