《测试架构师修炼之道》阅读笔记2

4.4 测试设计技术
1、测试点 不等于测试用例
测试用例是一份真正能够指导测试的测试说明书；
2、 四步测试设计法
测试分析是发现性过程，测试设计是创造性过程；
第一步： 建模；
类型1：流程类，绘制“流程图”来建立测试模型；
类型2：参数类，绘制“输入输出表”来建立测试模型；
类型3：数据类，绘制“等价类分析表”来建立测试模型；
类型4：组合类，绘制“因子表”来建立测试模型；
第二步： 设计基础测试用例；
基础测试用例只确定了测试条件；
第三步： 补充测试数据；
为基础测试用例确定测试输入，补充测试数据；
第四步： 扩展；
根据经验，补充用例，增加有效性；
3、对测试点进行 分类
流程类特征：输入的不同进行不同的处理；
参数类特征：参数值是有限的，系统会对不同的参数值作出不同的处理或响应；
数据类特征：数据取值是一个范围，系统对允许输入数据作出的处理或响应往往是一样的；
组合类特征：流程、参数、数据的组合；
4、 流程类测试设计：路径分析法；
绘制流程图-使用路径分析法（语句覆盖、分支覆盖、全覆盖、最小线性无关覆盖（有两条出边是必要条件，为判定数+1））得到测试条件-使用等价类或边界值等技术确定测试条件-其它需要考虑的；
5、 参数类测试设计：输入输出分析法
使用“输入-输出表”-100%覆盖“输入输出表”-其它需要考虑的；
6、 数据类测试设计：等价类和边界值分析法
使用“等价类分析表”-使用“边界值”来为“等价类分析表”确定测试数据-其它需要考虑的；
7、 组合类测试设计：正交分析法
使用“因子表”-使用“正交分析法”来生成测试用例-其它需要考虑的
8、 控制用例粒度：测试点的 组合和拆分
控制用例粒度，是测试设计中非常重要的一项工作。
第一：我们希望整个团队测试用例的总数维持在一个比较合理的范围内，同时达到测试验证产品的效果，需要我们控制测试用例的 源头（测试点），不要过粗或者过细。
第二：不同的用例粒度，可能会发现产品 不同层次的问题（细粒度用例可能更容易发现功能设计和实现方面问题，粗粒度用例可能更容易从系统角度去发现问题），所以我们不同的测试阶段，对测试点进行拆分和组合，不同层次去测试产品，发现问题。
还有一种控制测试用例粒度的方法，就是 策略覆盖，执行的过程中需要考虑内容的重要性和测试执行的便利性。
9、 错误推断法
错误推断法是一种基于 经验的测试设计方法。用到四步测试设计中第四步，作为经验 补充的测试用例，是一个比较推荐的方法。错误推断法中的经验，主要源于对产品缺陷的 分析。定期组织分析活动，分享经验，拓展思路。
4.5 探索式测试
探索式测试非常注重测试思维。
1、探索式测试的 基本思想：CPIE模型；收集C-划分优先级P-分析调研I-实验E；与传统测试相比，探索式测试弱化了流程，强调实践，边学边测，持续改进；优势是快速测试，高效发现产品缺陷，缺点是容易将焦点集中在缺陷发现而偏离对需求的验证，对基本测试覆盖不足，测试点不易复用，不易积累；
2、 选择合适的探索式测试方法：第一步，对产品的特性进行 分区；第二步，根据不同分区选择适合的探索式测试方法；
历史区测试法：老代码，包含修复已知缺陷的代码，多一些时间测试曾经有很多缺陷的代码是特别重要的；包含恶邻测试法（缺陷横行的代码段）、博物馆测试法（老的可执行文件和遗留代码）、上一版本测试法（运行先前版本支持的所有场景和测试用例）；
商业区测试法：销售特性，产品的重要功能和特性，测试的重点测试对象；包含指南针测试法（手册、场景及产品需求）、卖点测试法（吸引用户的特征）、地标测试法（寻找测试点，明确测试项）、极限测试法（向软件提出很多难以回答的问题）、快递测试法（专注于数据）、深夜测试法（不操作时，查看自处理情况）、遍历测试法（最短路径访问对象）；
娱乐区测试法：针对辅助特性，不那么重要的特性；
配角测试法（特定特征，紧邻主要功能）、深巷测试法（最不吸引人的特性，或最流行、最不流行混着测）、通宵测试法（长时间运行）
破旧区测试法：问题高发特性，测试思想就是继续“落井下石”；
破坏测试法（缺陷横行的代码段）、反叛测试法（输入最不可能的数据）、强迫症测试法（强迫一遍又一遍接受同样的数据）；
旅馆区测试法：平台或维护特性，被忽视或者少描述的次要及辅助功能；
取消测试法（启动相关操作，然后停止，查看处理反应）、懒汉测试法（自行处理空字段及默认值）；
旅游区测试法：针对的是噱头特性，关注如何快速访问文件的各个功能，目的是到此一游；
收藏家测试法（通过测试收集软件的输出，将那些可以到达的地方都到达一遍）、长路径测试法（访问离应用程序某个开始点尽可能远的特性）、超模测试法（关心表面的东西，只测试界面）、测一送一测试法（同时处理多个功能时，能否正常）
其他区测试法：无法归类的区域，如产品的可测试性、可维护性等；
内部测试法（需要进行某项功能测试之前完成，收集那些部分对确认测试结果、定位问题有用的内部输出）、变动区测试法（分析当前版本与之前版本内容的变化，针对变化内容进行测试）
3、 开展探索式测试：
3.1、确定探索式测试任务：确认任务范围，三种思路（全局场景探索、特性漫游探索、局部功能点探索）；确定范围后，确定测试方法；
3.2、设计探索地图并执行探索式测试：根据被测对象特点，使用测试方法分析得到测试点，然后执行测试，并记录结果；使用探索式测试是能够直接用测试点来进行产品测试的，也是其速度快、效果高的优势所在；测试过程中可以灵活实时调整测试策略；
3.3、探索式测试总结：哪些方法可以更有效发现产品问题；本次探索测试中的教训；
4.6 自动化测试
用好已有的自动化、根据产品测试需求向自动化团队提出合适的自动化需求；
1、需要知道的一些自动化测试真相
自动化并不廉价，相反，自动化很贵（时间人力技术成本）；自动化脚本往往没有想象中那么可靠（意外发现的缺陷，自动化可能都不会发现；自动化本身可能不可靠）；自动化测试不是单靠自测就能搞定的事情（需求要确定清楚，UI或命令行也需要尽早确定，测试用例也要尽快写出来）；
2、如何评估自动化的收益
自动化测试的实施成本（前期开发成本+后期维护成本）；自动化测试的运行次数（优先选择真正需要多次执行的测试用例）；自动化测试实施成本比；
3、自动化测试工具介绍
单元测试工具、UI测试工具、性能测试工具；
第5章 软件测试架构师的软能力修炼
除了硬能力之外，也需要一些软能力。
5.1 沟通和协商
产品测试中的沟通原则：1、尽早沟通（帮助我们预防分歧）；2、既要对事，也要对人（对人强调的是理解沟通对象，换位思考）；
通过沟通来获得对产品测试有用的信息：1、以测试的视角来读需求、设计文档，来准备沟通的问题（测试的视角，是否可测？怎么测试？怎样才算验证通过？）；2、以需求工程师或开发的视角来问问题（沟通是相互启发的过程）；3、总结、跟踪和确认；
和测试团队成员沟通：主动进行反复的沟通（简介-讲解-举例-总结）；和领导或投资决策者沟通（更关心：产品测试结果和产品的质量评估结论；重要BUG；重要风险；进度）；
5.2 写出漂亮的测试用例
测试用例 模板：测试用例编号、用例标题、预置条件、测试数据、测试步骤、预期结果；合理控制用例的粒度；
测试用例标题要是一个 完整的句子：状语，主语，谓语，宾语，补语（可选）；
用 条件而不是参数来描述测试用例标题：参数更适合在测试用例模板中的测试数据部分体现；
如果一个用例中包含 多个参数，用例中应该是每个参数的取值；
不要在测试用例中 引用别的测试 用例；
避免测试用例中 包含过多的 用户接口细节：用例执行者是专业人士，用例不必写的面面俱到；
明确测试步骤和预期结果的 对应关系：增加简单的标记（如check[]）来明确对应关系；
避免在测试步骤中使用 笼统的词：避免反复、长时间、大量等描述，应该明确；