Paste_Image.png 6. 测试用例和j9九游会老哥俱乐部appbug提交的关系 测试用例的书写是先验的，并不知道未来发生的事情，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其他的方式展现给用户。