再说APP测试设计（2）

摘要

5 测试用例与测试类型以及测试深度我们一般的用例组织会依照功能块作为基本拆分点，测试类型作为二次拆分点。所以在测试用例库完成后，在

我们一般的用例组织会依照功能块作为基本拆分点，测试类型作为二次拆分点。所以在测试用例库完成后，在执行时，我们仍有一个问题测试用例的选取，对一个产品的测试阶段来说，我们有很多轮的测试，考虑到投入产出的关系，我们不可能每一回合的测试都执行全部的测试用例项。所以我们会根据不同的测试阶段选取测试用例，以及根据不同的需求选取测试用例。 上图是一个一般的执行流程，下面会介绍一下每个测试执行的侧重点，用例选取参考方式。
准入测试，抑或者称之为Saint Test，Smoke Test。其主要目的是检验RD提交给QA的版本是否符合预期。既然说到预期，这里的预期望内容就需要给出，其中一部分就是准入测试用例，另外一部分为“其他约束条件”。
准入测试用例，面向于最基本功能的验证，检验主要的功能分支，无特殊输入输出，无特殊中断交互，无高压，无兼容性，用例的覆盖面向于该用例的fail不会引起较多的用例被block。
书写方式上，用例相比系统级测试用例，撰写内容经过抽象，单条用例的覆盖面高于一般的系统测试用例。面向于功能的检查，而暂时忽略展现的检查。
这部分用例，需要QA在RD提测前一周左右，提交到icafe并发起审核，RD和PM需要确认该用例的合理性以及完整性。
准入测试出了准入测试用例还有另外一部分称之为“其他约束条件”。在测试执行时，测试对版本的需求会一轮高过一轮，准入的条件也会在准入用例基础上层层叠加。如：在执行网络兼容性测试前，需要增加各个接入点都可以访问得到数据的约束；对于稳定性测试前，比如android会先约束per-monkey的时间超过某个值，如半小时；对于sprint迭代的版本，要约束前一sprint的bug修复率；对于最终版本整体体测前，需要约束所有的bug修复，检验未修复的直接打回。
系统测试用例，system test case，不用累述，指的是全面的，完整的测试用例，无论是执行步骤，还是检查点都达到细致全面。
Bug验证测试用例，Defect （bug） verify test，bug回归更准确地叫做bug验证测试，主要面向于RD已修复的bug的验证工作，主要依赖的是在提交bug是书写的bug report，详见后文。
基本功能回归测试用例，basic function regression test。功能回归测试是在多轮的系统测试结束后，整个系统已经达到一定的稳定度（这里在测试执行时，一般需要系统测试用例pass rate 98%+，no S0-S1 issue，其余的bug的修复率为95%+）
基本功能回归测试，内容上无边界检验，无特殊中断交互，无压力测试。和准入测试用例的覆盖类型相当，用例为系统测试的一部分，通常为标记各个功能点下basic的测试内容，然后适当选取强关联的中断，比如热插拔SD之于音乐播放器。
功能+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%

测试用例的书写是先验的，并不知道未来发生的事情，bug report是后验的，面向的是已经发生事件的陈述。Case的书写都面向于一个一个的步骤，突出检查的内容，在发生问题的时候，我们需要先将复现问题的路径截断，找到最短路径。可以等价的内容作为前提条件写出。
【传统模式】
当前提交bug的内容大概包含一些几个方面；

1. Title，就是bug的简单描述，用一句话大概描述清楚问题是什么。
2. 复现步骤，是我们能将bug复现的操作路径。操作路径要求简明清晰，并且尽量找到最短、最必然的复现路径。
3. 正确的操作后预期，一般写明按照以上的操作步骤之后，应该看到的现象应该是如何的。
4. 当前问题的操作结果，一般写明当前的操作导致了那些不能接受的后果。
5. 附件，一般是错误产生时候的系统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，你知道他化成灰也在那里，建议的模板也不必拘泥于形式。
参考范本： 【附件的使用】
在提交bug时，难免越到一些不太方便描述的问题，或者容易描述，但是不容易第一时间定位问题的位置。附件的内容：
Crash log，crash有些时候作为非必然复现的问题，一定要记得添加log到附件中
截图，视频，容易提示问题的症结点，另外一些不好描述的操作，可以通过视频清晰展现。
如图:如果我的描述单纯是告诉RD，播放的icon未能同步，你觉得不看图能一下子就定位问题吗？ 【更多想法】
向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修复的讨论中，从而获益。
【操作意义】
先验到后验的转型。书写测试用例，或者执行测试之前，我们的每一条用例都会认为是等概率的认为，可以发现问题。但是在一定的执行经验积累后，我们会倾向于认为，某些特定的功能容易发生问题，这部分对应的用例也就成了我们有限去执行测试的对象。
这个适用于相同类型的产品或者不同产品但是其中相同的模块间，以往发生的问题仍旧有较大的风险发生在当前的项目上。
在执行测试用例的时候，我们可以在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补充，如果是建议且被采纳，相应的功能调整也需要修缮测试用例。
测试用例的复用，依赖于已存在项目，相近模块的相似度。越接近的模块，其复用的成本越小。不过往往理想很丰满，现实很骨感。在复用别人已经写好的测试用例前，还是先衡量可用的比例多大，成本多高，如果复用的成本比重写还高，那就自己动手吧。
虽然龙有九子，九子各不同，但还是有些功能模块是在各个产品上都可以复用的，为此组织产出了通用测试用例，在撰写新的测试用例前，可以参考通用测试用例，减少一些时间开支。
不过切记，通用测试用例是经过抽象的用例，而且也只是公共模块中相对通用的测试内容，所以需要我们摘除不需要的部分，添加自身特制的部分，并将其丰富化。
之前提到了RGDVT在一定程度上代替ST而存在的使用前提，在使用方法，有时候我也可以不拘泥于看那些bug映射到了case的部分。如果是强关联的，比如相对功能接近的ting和musicbox，可以将之前的bug直接导出作为测试用例使用，快速而且集中的发现问题。
BO2是Box open 2的缩写，一般是在产品检验时候使用的一种测试手段。在我们的产品走渠道的时候，一般会遇到这样类似的问题，怎么保证我们所给出的几十个安装包都是ok的，一般会认为既然都从母包过来，一个过就应该全过了吧。对一般是这样的，但是总有不是一般的时候，那要一个一个全验证么？这个可以参考抽样检验的方式，对同一批给出的若干安装包，抽检其中2个来确保这一批的产出都是OK的。
【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其他的方式展现给用户。