1.8 错误推测法
错误推测法是基于以往的经验和直觉，参照以往的软件系统出现的错误，推测程序中所有可能存在的各种缺陷和错误，从而有针对性地设计测试用例。
错误推测法的基本思路是：列举出程序中所有可能的错误和容易发生错误的特殊情况，根据可能出现的错误情况选择测试用例。
例如：
1）单元测试中列出许多在模块中常见的错误、以前产品测试中曾经发现的错误等。 2）输入数据为0或字符为空。 3）各种情况在产品说明中常常被忽视，也可能被程序员遗忘，但是在实际使用中却经常发生。测试人员要站在用户的角度，考虑他们要输入的信息，而不管这些信息看起来是合法的输入还是非法的输入。 |
2.2 测试用例组织结构
建议的用例组织方式为，以功能为拆分，通过大功能，小功能，功能点，树状向下分割，在功能点末端，展开相应的测试类型。
Paste_Image.png
Paste_Image.png
示例：
Paste_Image.png
2.1 Basic – 基本功能测试
即MRD到case的转译
2.2 Boundary – 边界分析测试
在基本功能的基础上，开始考虑各种输入输出的影响。一般的，基本功能容易在边界附近出问题。主要采用等价类划分方法，边界值分析方法。用例组织上，可以梳理已经产出的基本功能草图，确定哪些部分存在边界问题。并构造测试用例，执行测试工作。
●边界类型数值大小 ，输入的数值的范围
●字串长短，Null-max-max+1
●内容有无
●支持与否，（保留字符，特殊字符，计划外字符。
在此非常郑重的提示各位新同学，写测试用例时，很多都能考虑到边界值分析，但是一般都只是分析输入，而对于我们来说bug真正容易出现的地方是输出。这里是输出是广义的，任何被我们能获得的信息都是客户端的输出，比如字符超长，内容超长，图片超大等等。
Memory – 存储测试
主要测试涉及存储空间读写的部分。最大的问题还是memory leak。用例组织上，主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题：
●比如旋转屏幕—响应G sensor，画面需要重新载入，重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。
●连续加载页面
●开多个窗口—比较典型的，如浏览器
●应用多次的互相调用—应用之间的相互调用，调用传递之间，可能存在问题，另外要特别注意“重入”；所谓重入，是指一个应用A叫起了应用B，但是应用B又可以再次叫起应用A，如message编辑时插入图片可以叫起camera，拍摄之后，camera可以不直接返回message编辑器窗口，而是通过点击分享-message，重入message编辑器，由此产生循环的栈叠加，也容易发生内存问题。
●多线程下载
Performance – 响应速度，资源占用
考虑方式参考memory的测试思路，注意在判断是否合格或者满足预期上，要参考竞品的表现
●相同移动客户端不同应用；在同一个移动客户端上，被测试应用和benchmark做比对，看选取的核心数据差异性
●相同应用不同移动客户端；在不同的移动客户端上，被测试应用分别安装，检验被测试应用，在不同平台环境中的表现能力。
Stress – 压力测试
可以简单理解为，在基本功能上的提升负载，速度，吞吐量等性能指标。一般的，移动客户端通过monkey之类的测试工具加以覆盖，以及录制回放工具之类的测试来实现压力检验。
Capability – 兼容性测试
移动客户端常见的兼容性测试测项
●网络兼容性测试（各种运行商，各种接入点）
●平台兼容性测试 （如android，从cupcake到donut到éclair到froyo到gingerbread到honeycomb）
●分辨率兼容性测试 （各种不同的分辨率）
其他可能会涉及移动客户端兼容性测试测项
●操作系统兼容性测试 （如实现一个手机到pc的通信工具，则各种pc操作系统需要被检验其兼容性）
●蓝牙设备兼容性测试 （如果是一款使用蓝牙的应用）
●存储卡兼容性测试（比如文件管理器）
Interrupt – 中断功能测试
别的应用对当前应用的中断，体现应用的被动型
Interaction – 交互功能测试
应用主动叫起其他的应用，体现应用的主动性，比如share via message，比如叫起camera，该部分详细的内容，如何开展交互和中断测试，将另行分享。
3. 测试用例书写方法
测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
测试用例的可执行特点：在测试前提符合的情况下，依照测试步骤，每一个测试用例都能够顺利地使程序运行，同时呈现相应的期望结果。
测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
3.1 用例书写技巧
正如上面提到的用例的四个特点，书写测试用例目的执行测试，一方面我们要提高测试用例的全面性，另外一方面，我们要考虑测试用例的可读性，即，用例很容易的被其他执行人员所掌握，执行结果和书写人执行基本一致。举个例子，
一个人A去找C同学，发现C同学不在，问B同学说：B同学，怎么不见C同学， B同学头也不抬：C已经不在人shi了 A同学大呼：我是听说过他要离开人shi，没想到走的这么快 B：虽然他不方便上来找你，但是你可以下去找他呀 |
你看完这段对话的第一反应是什么，可能很多人的第一反应是，C同学已经撒手人寰了。事实不然，C同学之前和B同学都在楼上人事部工作，后来人事调动，C同学去了楼下行政部。A来找C的时候发现他已经走了，而C工作比较忙，没有时间上楼来见A。
作为测试用例的撰写，我们也要注意这些内容，避免想当然，避免条件的遗漏。特别是初始的条件。
用例撰写一个容易苦恼的地方就是路径可能过长，基于经验，我们一般建议单条case的步长不超过五步，功能点仅涵盖一个。
比如一个音乐播放器，进入文件管理器相关的功能，使文件为空，添加一个曲目，然后查看后续的功能。这三个步骤，但是这三个步骤，可以做拓展，怎么使文件为空，我们可以拔掉SD换一张空卡回来，我们可以格式化SD，我们可以通过文件管理器删除全部，我们可以通过播放器删除全部……，第二步如何添加一个曲目，我们可以通过播放器下载一个，可以通过浏览器下载一个，可以通过蓝牙传输一个，可以通过录音机这个应用录制一个……，第三步对存在但个曲目的操作，是播放，删除，修改，查看详情……，如果按照路径遍历，单纯这几个点，就可以拓展为4X4X4，64条用例。但是事实上，我们并不需要这么做，首先我们会分析依赖关系，对于前一步骤各类操作产生的结果对下一步骤的影响一致，则用例可以被切割，统一成前一类步骤的一个结果为后一步骤的初始条件。所以这个功能会被拆分为三组测试用例，大约十二个。让文件管理器变空的若干条测试用例，然后以文件管理器为空做前提，看接收文件的刷新显示，第三条查看仅有一个曲目时的基本功能。
3.2 如何实现从MRD到测试用例
下图给出的是按照MRD，我们分析需求—转换用例---评审用例—最终生成完整用例的一个过程，下图体现的主要是初稿的撰写流程，突出的是，QA-PM-RD之间在基于测试用例为主线的协作关系。下面我们将从MRD出发，以点连线，说明下测试用例的撰写过程。
首先一个问题，什么是MRD？市场需求文档，（英文全称 Market Requirement Document，MRD）。该文档在产品项目过程中属于“过程性”文档。MRD文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。对MRD的认识，你觉得准确么？把MRD和PRD混为一谈，MRD是PRD的基础，PRD是MRD在产品功能上的具体化。产品需求文档(Product Requirement Document，PRD)的英文简称。是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
通过前面一段的简单分析，我们在项目立项的时候，其实就应该明晰MRD对我们的作用，以及我们要做的功课有哪些，下面我们就这几个部分做一下阐述：
基本需求这里是指，明确的以viso，脑图，文字明确下来的需求。这个概念比较好理解，因为这些内容会相对直白的表达出来，对于这部分，我们需要做的是，以评审讨论的方式了解相关的需求是否正如你对字面的理解那样。因为文字的表达难免会有一定的局限性，每个人的理解都不一样。正如上图中需求分析的部分。
通过适当的评审，将需求明确，避免理解偏差，具体的操作方式可以参考流程。
举例，下面是wenku android关于搜索功能的MRD需求
功能需求：
1.【在线】搜索范围是文库
2.【本地】搜索范围是已导入的本地书籍索引。
3.【本地搜索】默认界面，给出已有本地书籍索引
4. 本地搜索无结果时，提示在线搜索，点触立即切换至在线结果。
按照MRD，可以依照UI界面切分为大的功能块，然后在大功能块下再切分小功能块，最后到功能点，在功能点basic的部分，将图像化的，表格化的或者文字化的MRD需求分类逐条填充到basic内容。具体的方法，可以先构造脑图，然后脑图转化为组织构架图的模式，然后按照点逐条转换测试用例。
除了基本需求，我们还有读出MRD之外的隐含需求和扩展需求。
隐含需求指的是不明确写在MRD文档当中，但是作为某一款产品自身的需求，或者某些基本需求的视线，这部分内容必须实现。
对于隐含需求有两种可能，一种称之为约定俗成的需求，一种称之为支撑性的需求。
关于约定俗成的需求，对于某一款产品，必须存在的内容，比如描述做一款音乐播放器，对mp3 wma这样的解码支持虽然没有写在MRD需求文档中，但是你如果不支持这部分隐含未表述的需求，则你做出来的东西可能称不上是音乐播放器。
关于支撑性的需求，多是若实现a，则必须实现b，若b实现上存在问题，则a的功能不完整。有些时候a作为明确的需求写出，但是b不会。举个例子，比如播放器要支持蓝牙线控技术了，那么线控作为MMI的交互功能，在实现上需要更多的支撑，比如支持不同的蓝牙音视频控制协议，比如兼容不同的蓝牙线控设备。因为MRD更多的是面向市场的，所以另外还有一部分的扩展需求是在产品一级的，比如，在文件管理器为空的时候做操作，一般MRD都不会明确定义如何实现，但是需要我们将这部分作为需求转化为测试用例。
扩展需求体现的主要是一部分优化，更多的可能体现一个策略性的东西。比如输入法，针对错误的输入有一个识别过程，比如输入zhognguo可以自动识别成zhongguo，并显示为中国。对于这些模糊输入的逻辑实现，依赖于某个算法，而具体的算法可能是需要扩展的。
一般的需求拆分主要考虑两个方向，一个是宏观的，一个是微观的。
宏观的方式是基于功能块的拆分，按照一定的功能，将需求拆分成若干个大功能块，然后大功能块拆分成小功能块，再逐步柴扉为功能点。
微观的方式主要至考虑功能点的具体实现流程。
如baidu文库在线搜索：我们可以明确，在线搜索，搜索的文库web端的资源，从而我们可以分析出这部分的依赖内容，web端api接口，内容返回，网络连接本身，内容展示……逐点的分析才能确保我们测试用例的准确描述。
另外要借助MRD的评审会，了解具体的需求，从需求中理清楚功能。从源头上减少理解的偏差，才能后续的测试用例撰写减少遗漏。
3.3 如何确认覆盖度
确认覆盖度，首先是确认对需求检验的覆盖度，必要的流程是MRD评审和测试用例评审。通过MRD评审，QA可以充分了解PM对产品的需求以及主观上想要产品的功能，在评审过程中，QA应该提前阅读MRD文档，并在会上抛出自己的问题，以及人为描述遗漏的地方。之后QA进入测试用例撰写阶段，结合前面所述的，先将测试用例撰写为check list，checklist可以理解为测试用例的大纲，并发起测试用例评审，通过集体智慧确保在基本功能测试上，用例能确保全面性。
在时间允许的条件下，请组内其他同仁review，特别是老鸟，避免绊倒他们的石头再把你绊倒。
3.4 如何创建测试用例
每个公司和团队都有自己测试用例设计的规范，这个就不说啥了。主要几个要求无外乎以下几点：
用例描述（case名称）：简要的对用例的功能进行说明，也就是用例的标题 测试说明：简要说明运行该测试用例后能够达到的目的，这部分内容应来自MRD或者详细设计文档。 初始条件 测试步骤：详细描述该测试用例的执行步骤。 预期结果：按照测试步骤执行完毕后预期获得的结果，是判断测试用例运行成功或失败的准则 |
3.5 如何修改测试用例
测试用例的修改是必然的，一方面需求总会调整，这个尤其在维护过自动化测试用例的同学会深有体会。另外一方面，用例很难一次就撰写的很完美，需要我们持续的打磨。包括用例评审，需求的再次走查，ET发现的bug，用户反馈的特殊场景等等。这里需要提醒一句：一定要记得，被人给你提的一个意见，用户发现的一个bug都代表你一类型测试覆盖的不足，所以在补充测试用例时，要注意自己是那个方面有缺失和不足。
3.6 如何确保描述准确性并提高可移植性
测试用例的撰写过程，类似写代码一样，我们如果每一个项目都从头写一遍，那花在测试用的时间上将非常长，也不利于我们较好的传承其他项目或者之前项目上总结提炼的内容。
描述的准确性和用例的可移植性，这看上去其实是一对矛盾的话题。如果再加上测试用例的可执行性问题，那两个case的提升点将更缺乏支撑力。所以这个小结，仅作一个探讨。
关于提高描述的准确性，这个毋庸置疑，需要大家做到的是通过尽量少的描述，尽量快速的让阅读测试用例的人，把握该用例的为什么做，怎么做，做成什么样。但是描述的准确性，往往意味着在交互上，我们更加明确的点出来，如何执行一步一步的操作，但是在后续的应用上，实现类似的功能，也许有完全不同的交互方式。所以单一测试用例的描述准确性，必然降低可移植性。
所以，我们可以尝试，UI一级的测试用例和功能一级的测试用例分离。这会导致测试用例的增加，但是UI一级的测试用例，在多次往复的系统测试中，可以遍历一次后被搁置，在其他系统一级的测试用例保留。总的执行上，应该可以减少执行成本。而功能一级的测试用例，可以被我们做抽象，抽象后的用例，可以在项目的项目升级，或者不同项目的相似功能模块之间复用。
这里需要定义这两个概念，什么是功能级测试用例，什么时候UI一级测试用例。UI一级的测试用例，测试步骤上突出执行的步骤，如点某某按键到实现什么，检查点突出检查的是画面的展现以及页面之间的跳转。功能一级的测试用例，不突出形态，而是就某一项功能是否实现。
也许这里，我们可以借鉴两个概念类和多态。类这个概念，可以被理解成被我们抽象出来的功能模块，这些功能模块对于某一类产品，就特点上是固定的，多态可以被理解成是该功能的展现方式。
打个比方，播放模块可以被封装的功能有：播放-暂停-前一个-后一个-快进-快退-播放进度，这个“类”在被不同的音乐播放器上有不同的展销效果，比如有的播放器可以通过拖拽进度条实现快进快退，有的通过按键点击实现快进快退。
4. 测试用例和补充测试手段
如前文已经提到的，测试用例一定是无法一次性就写得很完整，即便是一只QA老鸟，即便经过了评审和认证，还是会有我们遗漏的问题。就如同积累了丰富的经验，我们仍旧无法预测地震一样。
因为在产品实际做出来之前，我们的case撰写本身就是一个闭门造车的过程，即便已经很严密了，仍旧有很多实际问题我们是开始阶段无法想到的。
另外有一些问题，本身我们不可能完全转换为测试用例，因为一些具体的bug一旦描述被抽象后，很难表达给执行人。所以在测试过程中，需要使用一定的补充测试手段，用以补足测试覆盖。
4.1 ad hoc test
Ad hoc test主要在各轮bug验证以及系统测试的补充，在执行ad时主要要考虑三点：
第一：更改了什么内容，可能引发什么side effect
第二：新增了什么内容，那些交互上容易出现水土不服
第三：执行测试时的新发现，比如测试执行中，你发现某些可能实现上有可能出现瓶颈的东东，为了防止的思维发飘，可以先记录下来，然后到系统测试结束后，执行ad hoc test。
4.2 User trail
用户体验，在功能大架子完成，基本上没有S0-S1的bug，S2的bug也趋向低水品后，可以发动内测，通过内测去发现更多的问题。内测的排期，通常在项目立项之时就会做好估计，此时QA需要约定好内测触发的版本条件。千万避免版本质量不够好，为了内测而内测，未解决的问题过多，那内测问题重复率将加倍放大，QA PM会在筛选bug上浪费时间，所以必须确保内测版本质量。与此同时也不必过于强求版本质量，而花费太多时间在版本稳定上，造成项目整体时间的不可控。
一般建议S0-S1的bug应该是0，S2的bug修复率应该在95%以上，一般的vsm项目，到内测时的bug大约为150个，所以一般最后尚未解决的bug大致在5个左右。注意，此数据仅供参考。在实际执行中，需要灵活处理，合适的调整约束条件，比如有些S1crash的问题，被用户发现的概率非常低，可以降低其修复的优先级，可以暂时接受不修改。
内测阶段，可以通过创建内测群，内测邮件组等方式，第一时间关注内测问题，另外一方面积极关注PM手机的问题反馈，确认属于bug还是建议，bug的部分，那些是未发现的，那些是已经发现的；建议的部分，那些是合理的，合理的建议哪些是需要被采纳的。
在内测阶段，需要注意良好的沟通方式，内测的同学一般都不是专门的QA，书写描述可能不够仔细、翔实。需要沟通问题发生的硬件版本，软件版本，所处的各种相关环境，在一些特有条件下发生的问题，需要特别注意这些。
可以有目的的引导执行内测，覆盖一些我们不容易发现的问题。这可能算是一个比较高阶的问题，困难来自于两方面，如何驱动用户接受你的引导完成你需要的测试；第二个问题是，如何使用整理你需要协助完成的测试内容，无论是测试项还是反馈形式。
很多公司和团队内测完全是放任自由主义，任由自由之花尽情绽放，不过和自然界一样，果树想多长果实，打定摘心的诱导还是必须的。QA就是内测这棵自由之树将来打顶摘心的人。对，我说的是将来。因为展开内测首先以上的两个问题如何解决。第二个和交由新人第一次写测试用例一样，这个可以准备，但是不能苛求全面，在实践活动中，我们才可能充实起来。关键是第一个问题，如果引导内测用户和获得较大的反馈收益，这个具体可以参考后续topic--内测执行建议规范。
大致的流程为：PM收集用户的反馈，并由PM筛选将bug的部分转交给QA，建议和功能改善的部分由PM-UE发起讨论。QA拿到内测反馈的问题，先分析是否为bug，是bug的话是否已经提交，针对未提交的部分，我们需要积极和发现问题的用户做沟通，特别是就在我们周边的同时。分析用户发现这一问题的场景和复现步骤。对可疑拆分为系统测试的内容点，需要转为测试用例，并强化到测试用例集中。在此基础之上，转化步骤，可以参考ad hoc test的后转化动作。
4.3 Project Handover
项目交换，这里讲的不是将项目执行一段时间后，交换负责人，而是在项目的系统测试结束之后。通过半天的时间，由组内甚至组外其他同仁介入做一次ad hoc test。此方法的目的旨在减少个人思维的瓶颈，并利用交流机会，一方面减少测试点遗漏，另外一方面开拓思路。
很多团队对测试项目的轮转 -- 这个还没有形成规范，建议在系统测试结束，整体提测试前。
Project handover会由同仁帮忙发现一些疏漏的问题，首先可以以点代面，了解别人的思路，并由此整理测试用例。在此基础之上，转化步骤，可以参考ad hoc test的后转化动作。
