再说APP测试设计（2）
接上回继续分享：《再说说APP测试设计-1》
5. 测试用例与测试类型以及测试深度
我们一般的用例组织会依照功能块作为基本拆分点，测试类型作为二次拆分点。所以在测试用例库完成后，在执行时，我们仍有一个问题测试用例的选取，对一个产品的测试阶段来说，我们有很多轮的测试，考虑到投入产出的关系，我们不可能每一回合的测试都执行全部的测试用例项。所以我们会根据不同的测试阶段选取测试用例，以及根据不同的需求选取测试用例。
Paste_Image.png
上图是一个一般的执行流程，下面会介绍一下每个测试执行的侧重点，用例选取参考方式。
5.1 准入测试用例
准入测试，抑或者称之为Saint Test，Smoke Test。其主要目的是检验RD提交给QA的版本是否符合预期。既然说到预期，这里的预期望内容就需要给出，其中一部分就是准入测试用例，另外一部分为“其他约束条件”。
准入测试用例，面向于最基本功能的验证，检验主要的功能分支，无特殊输入输出，无特殊中断交互，无高压，无兼容性，用例的覆盖面向于该用例的fail不会引起较多的用例被block。
书写方式上，用例相比系统级测试用例，撰写内容经过抽象，单条用例的覆盖面高于一般的系统测试用例。面向于功能的检查，而暂时忽略展现的检查。
这部分用例，需要QA在RD提测前一周左右，提交到icafe并发起审核，RD和PM需要确认该用例的合理性以及完整性。
准入测试出了准入测试用例还有另外一部分称之为“其他约束条件”。在测试执行时，测试对版本的需求会一轮高过一轮，准入的条件也会在准入用例基础上层层叠加。如：在执行网络兼容性测试前，需要增加各个接入点都可以访问得到数据的约束；对于稳定性测试前，比如android会先约束per-monkey的时间超过某个值，如半小时；对于sprint迭代的版本，要约束前一sprint的bug修复率；对于最终版本整体体测前，需要约束所有的bug修复，检验未修复的直接打回。
5.2 系统测试用例
系统测试用例，system test case，不用累述，指的是全面的，完整的测试用例，无论是执行步骤，还是检查点都达到细致全面。
5.3 Bug验证测试用例
Bug验证测试用例，Defect （bug） verify test，bug回归更准确地叫做bug验证测试，主要面向于RD已修复的bug的验证工作，主要依赖的是在提交bug是书写的bug report，详见后文。
5.4 基本功能回归测试用例
基本功能回归测试用例，basic function regression test。功能回归测试是在多轮的系统测试结束后，整个系统已经达到一定的稳定度（这里在测试执行时，一般需要系统测试用例pass rate 98%+，no S0-S1 issue，其余的bug的修复率为95%+）
基本功能回归测试，内容上无边界检验，无特殊中断交互，无压力测试。和准入测试用例的覆盖类型相当，用例为系统测试的一部分，通常为标记各个功能点下basic的测试内容，然后适当选取强关联的中断，比如热插拔SD之于音乐播放器。
5.5 功能+bug回归测试用例
功能+bug回归测试用例，RGDVT，Regression defect verify test。接近于RGT+DVT，但这里的DVT不是本轮次的bug，而是标记在测试用例执行中，被标记出现过bug的用例。一般在版本升级后，前一部分内容的验证；在重构后，对重构部分的检验。以上的几种情况，会认为系统测试没有必要，故而采用功能+bug回归测试的方法。（提示，使用该方式时，最好和PM和RD做好确认，这依赖于变更大小，以及项目排期的冲突）
下表为几种测试用例的要素整理：
| 类型 | 覆盖范围 | 用例规模 | 特点 |
|---|---|---|---|
| SNT-SmokeTest | 最基本功能的验证，无特殊输入输出，无特殊中断交互，无高压，无兼容性 | 大约为系统级测试用例的10-15% | 用例相比系统级测试用例，撰写内容经过抽象，单条用例的覆盖面高于一般的系统测试用例 |
| ST | 全面的，完整的测试用例 | 视app的规模， | 用例撰写详细，全面，细致点出检查点 |
| DVT | 面向已经修复的bug，检验其是否修复，有无side effect | 无测试用例 | 参考内容为bug report |
| RGT | 基本功能测试，无边界检验，无特殊中断交互，无压力测试 | 大约为系统级测试用例的25-35% | 和准入测试用例的覆盖类型相当，用例为系统测试的一部分， |
| RGDVT | 接近于RGT+DVT，但这里的DVT不是本轮次的bug，而是标记在测试用例执行中，被标记出现过bug的用例 | 用例规模的40-50% | 在RGT的基础上，验收版本曾发生过的问题的用例 |
下表为几种类型测试用例的选取参考：
| 类型 | 覆盖范围 | 用例规模 |
|---|---|---|
| 平台兼容性测试 | 面向于平台适配，用例范围一般为RGTC | 大约为系统级测试用例的10-15% |
| 分辨率兼容性测试 | 面向于分辨率适配，用例范围一般为RGTC，确保个页面展现 | 大约为系统级测试用例的10-15% |
| 网络兼容性测试 | 面向于网络接口适配，用例范围一般为RGTC，确保个接口的覆盖 | 大约为系统级测试用例的10-15% |
Paste_Image.png
6. 测试用例和bug提交的关系
测试用例的书写是先验的，并不知道未来发生的事情，bug report是后验的，面向的是已经发生事件的陈述。Case的书写都面向于一个一个的步骤，突出检查的内容，在发生问题的时候，我们需要先将复现问题的路径截断，找到最短路径。可以等价的内容作为前提条件写出。
6.1 如何书写bug report
【传统模式】
当前提交bug的内容大概包含一些几个方面；
- Title，就是bug的简单描述，用一句话大概描述清楚问题是什么。
- 复现步骤，是我们能将bug复现的操作路径。操作路径要求简明清晰，并且尽量找到最短、最必然的复现路径。
- 正确的操作后预期，一般写明按照以上的操作步骤之后，应该看到的现象应该是如何的。
- 当前问题的操作结果，一般写明当前的操作导致了那些不能接受的后果。
- 附件，一般是错误产生时候的系统log以及不方便描述时上传的图片或者视频等，方便RD同仁debug。
【客户端需要注意的】
- Add 1—在移动产品测试部分，我们应该加入问题发生时使用的手机平台版本、型号以及相关的网络环境等等。
当前习惯使用的bug提交习惯，更多的是参考以往的基于服务器搜索业务相关的习惯来提报的。以往更多的问题并不是依靠上层MMI层面的操作来发现bug的。而是相对靠下的，在同样的平台上，同样的接口上来实现一些功能。所以很多平台相关的东西都是默认的配置。这部分却是没有写入bug report的必要。但是在移动产品一段，我们最大的烦恼就是平台过于灵活了。比如android，我们跨平台的要测试从1.6-2.1-2.2-2.3将来还会有3.0-3.1更或者4.0.每个平台的接口都会有升级，都会有改变。换言之，在这个手机，这个平台版本上发现的问题，相同的应用在另外的手机上有可能是没有的。所以我们提供这方面的咨讯有利于RD快速定位问题。而在RD寻求帮助时，我们也能知道在哪一只手机上，我们能更快的复现该问题。
- Add2—写清楚该问题被复现的概率有多大，比如2-20，表示我复现了20次，我能复现两次该问题。
在写bug report的时候，我们要尽量写清楚前因后果，每个QA都应该坚信任何问题都是可以找到必然复现的路径的，但是有时候我们却是很难复现某一个问题，抑或者我们称之为小概率事件。对此类bug，我们最好能写明该问题复现的概率多大。一方面我们好针对概率极小的问题，降低其debug的优先级（很难浮现的问题，真的可能需要花费大量的时间在查找导致发生的蛛丝马迹上）。另外一方面就是，在我们验证这个问题的时候，知道该问题，我需要执行多少次的验证的。特别在不同人员一起测试同一个项目的时候，一个人测试另外一个人提报的bug，不会因为对小概率的bug复现次数过少而导致可能未解决的bug被轻易关闭，从而造成隐患。
-
Add3—note，一些关于修改的建议，或者该问题可能导致的更多问题
-
Add4—基于前两条，在验证bug是，一定标记验证使用的手机型号、版本相关的网络环境，复现多少次而判定通过的
我们可能面临一个问题就是，在起初发现的一个问题，在当时也许所有的平台上都会发现，但是在验证时却是该问题在某一只收集上解掉了。但是在另外一只手机上，过段日子你用的时候，发现又有这个问题。因为我们却是有比较小的可能，不同的平台版本上，有的函数高版本有，低版本没有；有的函数不同版本用法有差异。虽然都是小概率时间，但是我们的标记非常有利于将来定位问题。
【建议模板】
【问题描述】“一句话总结一些问题”
【手机版本】Galaxy S7 （android 7.0）+ CU4G
【初始化条件】“bug复现必要准备的动作”
【复现频率】X-Y
【复现步骤】
1st
2nd
3rd
【预期结果】
【实际问题】
【note】
这么写bug会不会太累了，尤其我们一天有时候一下提报十多个bug，这时候我们可以制作一个模板，具体模板创建方式见下文。而对那些诸如MRD不符的bug，你知道他化成灰也在那里，建议的模板也不必拘泥于形式。
参考范本：
Paste_Image.png
Paste_Image.png
【附件的使用】
在提交bug时，难免越到一些不太方便描述的问题，或者容易描述，但是不容易第一时间定位问题的位置。附件的内容：
Crash log，crash有些时候作为非必然复现的问题，一定要记得添加log到附件中
截图，视频，容易提示问题的症结点，另外一些不好描述的操作，可以通过视频清晰展现。
如图:如果我的描述单纯是告诉RD，播放的icon未能同步，你觉得不看图能一下子就定位问题吗？
Paste_Image.png
【更多想法】
向RD发出request，
-
Add1—在RD修复bug是写明root cause，就是写明该问题发生的原因。QA的职责在于发现问题，进而定位问题，最终是给出修改意见。透过现象看本质，不同的复现步骤导致的问题可能源于相同的问题，相同复现步骤以及相同的表象也可能源于不同错误。所有向RD了解问题的症结点是我们能快速提高经验，并在以后的测试中强化问题定位能力的不错办法。
-
Add2—在RD修复bug时写明解决方案，在1的基础上写明如何解决该问题。写明解决方案的好处不只是在于能了解某些症结点如何被修复、回避，也能逐渐思考该解决办法是不是可能导致 side effect而导致其他问题。
以上两点，有些习惯好的RD是会写在note里的。但是明显人总是会懒惰的，更多的RD并没有写，这方面出了能期望他们写好note外。我们也可以抽出来一些时间和RD坐下来一起review bug，不但RD能在沟通中减少对bug的误解，也能让QA参与到bug修复的讨论中，从而获益。
6.2 如何映射bug到测试用例
【操作意义】
先验到后验的转型。书写测试用例，或者执行测试之前，我们的每一条用例都会认为是等概率的认为，可以发现问题。但是在一定的执行经验积累后，我们会倾向于认为，某些特定的功能容易发生问题，这部分对应的用例也就成了我们有限去执行测试的对象。
这个适用于相同类型的产品或者不同产品但是其中相同的模块间，以往发生的问题仍旧有较大的风险发生在当前的项目上。
6.3 如何利用bug强化用例
在执行测试用例的时候，我们可以在fail后，关联相关的bug，而那些没有被关联的，我们需要分析他们是不是能被我们转化为测试用例，方便以后提高测试覆盖度。
测试工作中，我们应该执行一个 case撰写—>case评审—>case执行—>bug review-->强化测试用例—>case评审—>case执行的循环过程。随着不停的case迭代，覆盖度会越来越高，迭代周期也会变长，越来越有保障。
基于ad hoc
Ad hoc的发起一般是认为case有疏漏的，或者case无法描述的。所以ad hoc之后，要根据执行的ad hoc test补充测试用例。注意不单单是那些发现了bug的测项，我们要根据bug report反馈去添加到测试用例中，那些没有发现bug的case，我们也要做梳理。因为相同的测试内容，此次没有问题，不代表以后的改动不会影响到他。
基于用户体验
用户体验章节，我们已经简单描述过，可以将内测用户作为小白鼠帮忙实现某些低概率问题的测试覆盖。另外用户体验时候又会反馈一些我们想不到的内容。所以这部分我们会分为两部分工作，第一控制用户体验（升华内容，试验阶段），第二用户问题转化测试用例。
第一部分，我们可以以用例的方式，一开始就准备相应的用例，作为督促用户实现检验覆盖
第二部分，用户的反馈会有两部分，bug和建议，bug看是否为遗漏，遗漏的内容需要做case补充，如果是建议且被采纳，相应的功能调整也需要修缮测试用例。
7. 测试用例技巧
7.1 测试用例复用
测试用例的复用，依赖于已存在项目，相近模块的相似度。越接近的模块，其复用的成本越小。不过往往理想很丰满，现实很骨感。在复用别人已经写好的测试用例前，还是先衡量可用的比例多大，成本多高，如果复用的成本比重写还高，那就自己动手吧。
7.2 通用测试用例
虽然龙有九子，九子各不同，但还是有些功能模块是在各个产品上都可以复用的，为此组织产出了通用测试用例，在撰写新的测试用例前，可以参考通用测试用例，减少一些时间开支。
不过切记，通用测试用例是经过抽象的用例，而且也只是公共模块中相对通用的测试内容，所以需要我们摘除不需要的部分，添加自身特制的部分，并将其丰富化。
7.3 RGDVT
之前提到了RGDVT在一定程度上代替ST而存在的使用前提，在使用方法，有时候我也可以不拘泥于看那些bug映射到了case的部分。如果是强关联的，比如相对功能接近的ting和musicbox，可以将之前的bug直接导出作为测试用例使用，快速而且集中的发现问题。
7.4 BO2
BO2是Box open 2的缩写，一般是在产品检验时候使用的一种测试手段。在我们的产品走渠道的时候，一般会遇到这样类似的问题，怎么保证我们所给出的几十个安装包都是ok的，一般会认为既然都从母包过来，一个过就应该全过了吧。对一般是这样的，但是总有不是一般的时候，那要一个一个全验证么？这个可以参考抽样检验的方式，对同一批给出的若干安装包，抽检其中2个来确保这一批的产出都是OK的。
7.5 思考方式（公式化书写）
【Case构思公式】
供思路提炼的公式：一个aa的MRD需求，（按bb条件为前提），（在cc平台上）通过dd的手段支持用户以（ee的方式）实现ff功能，（最终以gg的方式展现在用户面前）
一个曲目切换的MRD需求，以该平台支持BTAVRCP为前提，在android+BT2.1 EDR平台上，通过蓝牙耳机接入方式支持用户以点击按键的方式实现切歌功能，最终以beep提示音和页面水平平滑跳转的方式展现在用户面前。
切记：此公式并非要大家直接套用，书写累赘的测试用例，而是要提炼大家的思路。比如：
需求aa：切换曲目
按bb条件为前提：针对蓝牙这样的方式需要支持BTAVRCP，如果是手势切换，可能要考虑Gsensor
在cc平台上：同样的需求，当前在android上测试，同样为将来移植到ios而准备
通过dd的手段：蓝牙耳机是一种线控方式，也许还可以支持蓝牙遥控器等
已ee的方式：按键是一种方式，也许还可以声控
实现ff功能：切歌也分多种状况，播放中切换，暂停时切换，快进快退时切换
gg的方式展现：提示音也许可有可无，但是MRD需要给定义，亦或者是mrd其他的方式展现给用户。
今天的先写到这里了，下周我们再一起看一个实例
相关文章：
《再说说APP测试设计-1》
《再说APP测试设计-2》
《关于ad hoc test》
《干了这碗蛋炒饭 继续APP性能提升-1》
《突破测试的墨菲定律 -- 有感于一次UAT组织》
