Why need AD HOC?

• 测试用例甚至是MRD有遗漏的地方
• 某些功能需要进行类似排列组合的方法进行测试，如果都写成Case会使测试用例的冗余，并影响测试时间
• 测试人员的疏忽，导致与问题擦肩而过。尽量减少和避免疏忽是我们必须努力去做到的，但是也要承认这个问题也是难免的。

Who do AD HOC?

System test engineers or other team member；每个测试工程师自然不能放过用ad hoc补足系统测试可能的遗漏，在被测软件得到一定的稳定度之后还可以考虑请其他的组员帮忙检验，从而避免自身可能存在的思维瓶颈。

What is AD HOC?

以下内容摘自百度百科

软件测试中的ad-hoc “Ad-Hoc” 原意是指 “特定的，一次性的”，这里专指“随机的，自由的”测试。

在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效 方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功 能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试 (Regression testing)一起进行。

理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体 的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。

词汇Ad Hoc是一个拉丁词汇，在拉丁语中的意思是“即兴，临时（improvised, impromptu）”
AD HOC(抑或者叫做Free Style Test)是我们系统测试中的一个测试阶段，是对ST和Regression test的补充，也是对我们ST Case的补漏和完善。AD HOC没有相应TC，是测试工程师凭借经验和对产品的熟悉程度完成的测试，目的是找出系统测试和回归测试覆盖范围以外的问题。（类似于ET，如何让这种测试方法化，将人为因素减小到最小程度，并适用于所有功能。但这些方法是建立在对产品设计足够熟悉的条件下进行的）

When do AD HOC?

存在于进入ST到版本release前的整个时间段。一般出现在ST第一轮以后，对ST和regression test补充测试（如果有资源，也可以和ST和RGT同时进行）；也可根据实际需要安排时间点，功能，次数等。

注：ST后的ad hoc test一般都以测试用例的不足处为考量点出发，另外就是认为软件比较不稳定的功能展开。另外RGT时候的ad hoc test一般是以改动的功能点出发特别注重，修改的方案是不是会导致其他的side effect。

Where to AD HOC?

Not only in office, but in anywhere and anytime!――除了在办公室里完成的AD HOC，其实下班后的User Trail（Free Trail）也是很重要的一部分。作为基于网络的服务的应用，我们其实一般系统测试很难去覆盖的一个问题就是动态测试，主要针对实际网络中的切换，断网恢复等。

How to AD HOC?

制定并执行AD HOC CP（ad hoc Test check Point）

• 在写Case时
  a.遇到需要排列组合的情况时，将组合和主要排列写在TC中，其他排列情况则转换成AD HO（特别的可以使用热推中的smart）。
  b.列出需要做多重Interruption和Interaction的点，规则请参考6.1.4
  c.列出需要做重复操作的点（小于5次），比如：比如在音乐播放器下载音乐时提示空间满，无视提示重复执行一些操作。
  d.针对不同运营商的区别点，一般的兼容性测试，我们只跑一次网络兼容性测试，为了避免后续一些bug修复引起side effect，可以实时的切换不同的手机简单执行ad hoc，确保在各个运营商下是可用的。
  e.一轮功能测试已经结束后Update的TC
• 在bug regression test时
  a.记录Design Change较大的小Function执行AD HOC，比如：比如在音乐盒上功能测试第一轮后增加了专辑随机播放功能。
  b.将没有时间做Side Effect验证而有必要做的bug进行记录并转换成AD HOC（一些bug在修复时可能引入的resolution比较复杂，在验证bug的之后一般的需要查看有无side effect，但是如果遇到时间不足导致的执行冲突，应该列出该问题后续补充以Ad hoc test）。
  注：在时间允许的前提下，对每个被验证bug进行Side Effect验证。因为这时候做比在AD HOC和RGT做更有针对性，发现问题也更早。
• 在AD HOC前
  Owner根据功能目前的状态（过去的测试阶段的执行情况、bug状态、Design Change的情况等）列出所需的AD HOC，比如：PM UE等修改了一些处理流程（上层UI可能没有太大变化）。
• TC和AD HOC在多重Interruption和Interaction中的划分规则
  a. 2重及2重以下Interrupt写在TC中，2重以上则列入AD HOC
  b. 3重以下包括3重Interaction写在TC中，3重以上则列入AD HOC

AD HOC的测试方法

• 边界值法，当处于边界值时继续进行操作，或是从其他的相关功能处尝试同样的操作。
• 采用更多Device(其他Brand手机，BT设备，FMR设备，SIM卡，Operator等)进行IOT，注意PC系统与手机系统间文件格式，交互命令等的差异，或是语言的差异，如一般我们都选择在中文操作语言下选择覆盖功能测试，但是在ad hoc的时候，我们可以着重切换到中文繁体或者英文的语言界面查看一下。
• 长时间不重启手机，连续测试，验证Stack Leak, Heap Memory, Partition等
• 不相关功能设置后对被测功能的影响，比如：Display Settings, Audio Settings, Profile Settings, Power Saving Mode, Flight Mode, Charging, Insert earphone, MP3/WMA/FM Radio background play, Language, Network Settings, Security Settings …….
• 寻找更多格式的Image/Audio/Video进行测试
• 快速操作，对按键相应顺序和Scenario之间的快速切换进行测试,在编辑窗口中的高强度按键输入，挑战处理速度。（很对monkey的随机性，以及测试脚本执行的延迟特性，发挥人手和人脑的极致）
• 容错性测试，验证手机对于错误的操作步骤，无效的操作，错误的文件格式的处理能力。（有一种变态的手法是，同时按好几个手机上的按键，比如方向键，上下一起按）
• 性能测试，验证手机对多个任务同时处理的能力。比如测试download曲目，（背景让BT下载，Browser下载，其他文件也在传输，还背景播放着歌曲）
• 同一资源的争夺，如不同的文件类管理ap去处理同一个文件（比如音乐盒正在播放曲目，我最小化后用文件管理器去修改这个文件）。
• 多个功能的中断，scenario的叠加，是否能正常的返回初始功能。
• 要对操作中的时间把握的很准确，主要进行一些操作的时间点，如在一个显示时间很短的scenario下MT call打断。
• 注意有些时候操作单个文件并没有问题，但是当同时对包含这个文件的多个文件作操作时就容易出现问题。
• 画UI Flow，帮助整理思路，发现逻辑或未测Scenario的问题

其他测试

• 对比UI Review Note，检查是否符合当初讨论的结果
• 对比相类似的市面产品（不怕不识货就怕货比货，做测试也是一样）
• 手机处于负载较大的情况下

后续动作

• 测试结果处理：将AD HOC发现的Bug分类，是TC遗漏的就加入TC中
• 看看别的项目组都怎么测试的，找找灵感，好让ad hoc能稳-准-狠。

相关文章：

《再说说APP测试设计-1》
《再说APP测试设计-2》
《关于ad hoc test》
《干了这碗蛋炒饭 继续APP性能提升-1》
《突破测试的墨菲定律 -- 有感于一次UAT组织》