测试架构师修炼之道---第四章总结
1.软件产品质量模型
众所周知，软件测试的一个重要目标，就是“验证产品质量是否满足用户的需求”（还有重要的是发现错误）
1.1软件产品质量六属性
1.2功能性
软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。
| 质量子属性 | 子特性描述 |
|---|---|
| 适合性 | 软件产品为特定的任务和用户目标提供一组合适功能的能力 |
| 准确性 | 软件产品提供具有所需精度的正确或相符的结果及效果的能力 |
| 互操作性 | 软件产品与一个或多个特性、系统相互配合的能力 |
| 安全性 | 软件产品保护信息和数据的能力，以保证为授权的用户或系统不难阅读和修改这些信息与数据，而合法用户或系统不会被拒绝访问 |
| 功能顺从性 | 软件产品符合和该功能相关的标准、规范、规则或特定的能力 |
分析Windows的计算器
适合性：为用户提供“计算”的明确或隐性的功能
“查看”菜单
准确性：计算器的计算结果，涉及四舍五入保留位数等
互操性：不同功能之间、特性之间是否能够正确地互相配合
对于不同操作系统或者工作模式的支持
安全性：不应该包含能够被利用的安全漏洞和“用户权限”相关的内容。
功能顺从性：对于计算器来说是计算机的规则与数学规则一致
1.3可靠性
在特定条件使用下，软件产品维持特定的性能级别的能力
用户对可靠性的要求：
第一层：设备最好不要出故障；
第二层：设备出现故障了不要影响主要的功能和业务；
第三层：如果影响了主要功能和业务，系统可以尽快定位并恢复。
| 质量子属性 | 子特性描述 |
|---|---|
| 成熟性 | 软件产品为避免因软件故障而导致失效的能力 |
| 容错性 | 软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力 |
| 可恢复性 | 软件产品在失效发生的情况下，重建规定的性能级别并恢复受直接影响的数据的能力 |
| 可靠性顺从 | 软件产品遵循与可靠性相关的标准，约定或规定的能力 |
计算器案例：
成熟性：运行一段时间，出现计算方面的错误
容错性：计算器能够有一定的容错处理机制，能够判断用户在使用过程中是否输入了“非法值”，并能针对“非法”输入的内容和原因给出错误提示。不会因为用户的任何错误输入，而引发计算器出现软件无响应、软件重启等异常。
可恢复性：从软件产品恢复的方式来说，能够自动恢复当然是最好的，如产品异常重启后，软件能够自动启动，最好还能恢复到重启前的页面
可靠性顺从性：通信类产品在可靠性顺从性方面就有比较严格的标准，如系统的故障率不能高于多少、故障恢复时间不能长于多少等。
1.4易用性
是指用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。这个能力，简单 地说就是10个字：易懂、易学、易用、漂亮好看。
| 质量子属性 | 子特性描述 |
|---|---|
| 易理解性 | 软件产品使用户能理解软件是否适合以及如何能将软件用于特定的任务和使用环境的能力 |
| 易学性 | 软件产品使用户能学习其应用的能力 |
| 易操作性 | 软件产品使用户能够操作和控制它的能力 |
| 吸引性 | 软件产品吸引用户的能力 |
| 易用性的依从性 | 遵循与易用性相关的标准、约定、风格指南或法规的能力 |
依从性：使用用户习惯的角度来保证产品的易理解性易学性、和易操作性，比如用红十字来代表医院而不是邮局
一般来说易用性考虑的是外部UI
Window计算器体现产品质量属性中的易用性
（1)易理解性：理解按键的意思，表面东西
（2)易学性：帮助文档；计算机的界面形同我们真实的计算器产品
（3)易操作性：不同进制之间的转换对应不同的数值，计算器在用户使用之前就做了相应的调整
（4)吸引性：windows和iphone的计算器在按键风格上的对比，没有统一的标准，根据用户习惯来看
（5）依从性：模拟真实的计算器，是制作计算器产品的标准
1.5效率
在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。（产品性能）
| 质量子属性 | 子特性描述 |
|---|---|
| 时间性 | 在规定条件下，软件产品执行其功能时，提供适当的响应时间以及流量的能力 |
| 资源利用率 | 在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力 |
| 效率依从性 | 遵循与效率相关的标准或约定的能力 |
Windows计算器
（1)时间特性：计算结果的返回时间
（2)资源利用率：占用Windows系统资源值（如CPU和内存）是否合理
（3）依从性：可以理解为”在运行计算器时，对系统的资源占有率不应该高于多少
1.6可维护性
| 质量子属性 | 子特性描述 |
|---|---|
| 可分析性 | 软件产品诊断软件中的缺陷，失败原因或识别待修改部分的能力 |
| 可修改性 | 软件产品能够被修改的能力 |
| 稳定性 | 软件产品不会因为修改而造成意外结果的能力 |
| 可测试性 | 软件产品已修改的部分能够被确认修复的能力 |
| 可维护性的依从性 | 软件产品遵循与维护性相关的标准或约定的能力 |
可测试性:用户需要研发来演示某个bug确实被处理好了。
Windows计算器：
（1）可分析性：在出现错误的情况下，能够捕捉和定位到这些异常信息。帮助开发人员定义复现这些问题
（2）可修改性：通过产品升级来达到最终的目的，功能上的扩展可进行
（3)稳定性：在升级之后，依旧能够稳定工作
（4）可测试性：所有的改动能够被验证，是否正确，符合预期
（5）可维护性的依从性：错误界面的显示
1.6可移植性
软件产品质量属性中的可移植性是指软件产品从一种环境迁移到另
外一种环境的能力。这里的环境，可以理解为硬件、软件或组织等不同的环境。
| 质量子属性 | 子特性描述 |
|---|---|
| 适应性 | 软件产品无须采用额外的活动或手段就可适应不同指定环境的能力 |
| 可安装性 | 软件产品在指定环境中被安装的能力 |
| 共存性 | 软件产品在公共环境中同与分享公共资源的其他独立件共存的能力 |
| 易替换性 | 软件产品在同样的环境下，替换另一个相同用途的指定软件产品的能力 |
| 可移植性的依从性 | 软件产品遵循与可移植相关的标准或约定的能力 |
Windos计算器
（1)适应性
在不同大小的显示屏、计算器的布局、大小、清晰度、按键的排列等是否都能正常的显示
（2)可安装性：顺利安装到Windows操作系统
（3)共存性：与其他软件共存时不会存在资源抢夺的问题
（4）易替换性:不是产品升级，而是新老同时存在
（5）依从性：不是针对某款特定的操作系统开发的，可以在不同的操作系统安装
2.测试类型
从哪些角度去测试产品：结合软件产品的质量属性来进行的，用于确定了思路。（解决一道数学题时，首先需要先确定好这道数学题涉及的类型，比如解微积分、转置矩阵；定位题型）
测试类型：功能测试、性能测试、压力测试、兼容性测试、易用性测试、可靠性测试等
测试属性解决的是从哪些角度去设计产品才能满足用户需求，测试类型要从哪些角度去分析和测试产品。
常见测试类型及其与质量属性关系表
| 名词 | 说明 | 对应的属性 |
|---|---|---|
| 功能测试 | 验证产品是否能够满足用户特定功能要求并作出正确的响应 | 功能性 |
| 安全性测试 | 验证产品是否有保护数据的能力 | 功能性 |
| 兼容性测试 | 验证产品是否能够和其他相关产品顺利对接 | 功能性 |
| 配置测试 | 验证产品是否能够在推荐的配置上流畅运行；验证产品为了完成特定功能的输入是否会出现故障 | 功能性 |
| 可靠性测试 | 验证产品在长时间运行下能否满足保证系统的性能水平 | 可靠性 |
| 易用性测试 | 验证产品是否易于理解、易于学习和易于操作 | 易用性 |
| 性能测试 | 测试产品提供某项功能时的时间和资源使用情况 | 效率 |
| 安装测试 | 产品能否被正确安装并运行 | 可移植性 |
3.测试方法
在拥有了做数学题的思路之后，我们就应该找出解决某一类型题目的方法，比如求解极限（类型）用到洛必达法则，那么在不同的测试类型时我们采用什么样的方法呢？
3.1产品测试车轮图
一个软件测试者要从哪些方面（测试类型）用哪些方法（测试方法）去测试产品（质量属性）。形成一个车轮图
（看到这里发现了测试官问题的答案，想想自己回答的有点沙雕，自己说什么测试的关键点：耐心、细心以及沟通能力，完全从测试者的角度去了，没有定位到测试这件事）
产品测试的两个关键问题：
（1)测试的全面性：最好是测试的点能够覆盖产品六大属性
（2)测试的深度：运用的测试方法最好能够越多越好，表示对产品的测试越深
根据产品的质量目标、产品的风险分析来确定测试的重点和难点、深度和广度，这就是测试策略。
3.2 功能测试方法
功能测试方法，就是对产品功能进行测试的方法。
- 单运行正常值输入法
- 单运行边界值输入法
- 多运行顺序执行法
- 多运行相互作用法
3.2.1运行
从用户的角度来看，有意义的操作或行为
这里的单运行操作可能涉及的行为或操作可能为：用户写了一封邮件、发送了一封邮件等
运行时的操作不能单单指在某些细粒度的功能测试上。
总结运行：通过组合一个或多个功能使其能够达到一种用户能够进行的行为。
3.2.2 单运行正常值输入法
1、单运行正常值输入法就是测试时的输入是系统允许的“正常值”的测试方法。
按照输入个数划分：
遍历法：有限个数； 等价类划分法：无限个数
3.2.3 单运行边界值输入法
假设某处允许的输入值是一个范围[1、10]，这时0、1、10和11就是我们所说 的“边界值”。
边界值输入法：包含了“正常输入”和“非法输入”
3.2.4多运行顺序执行法
举个例子：还是数学题，你在做这一道，突然脑海里冒出另一道的问题的答案，这个时候怎么去取舍？
顺序执行法：分析各个运行之间的顺序性
1、邮件的发送接收过程先发再收；先收再发
在先收再发的过程中，涉及到先接收对应的邮件再转发，是遵循一定的顺序的
2、用户习惯操作上，多运行顺序的执行
3、功能的配置测试上
考虑“修改接口配置”“修改安全区配置”对将接口加入安全区域的影响。
按照以上的思路，对在安全区域配间配置包过滤的测试点可能包括：删除包过滤的配置或修改包过滤的配置等
3.2.5多运行相互作用法
多运行相互作用法是指在功能测试时把多个存在相互关系的运行组 合在一起进行测试的方法
考虑内在和外在的关系：某个业务能够顺利进行需要多个运行之间相互协作、也可以是内在关系，运行会用相同的资源（如内存或其他硬件资源）
功能性的测试只是考虑一个用户的情况下，同时进行多个运行
比如“在打电话的同时收到一条短信；收发邮件同时进行”
多个用户同时进行某些事情是属于可靠性的测试范畴
突然想到这跟操作系统中涉及到的并发任务和并行任务类似，并发是同一时间段多个任务执行，并行是同一时刻一个任务的多个子任务的执行。（不知道描述的对不对）
3.3可靠性测试方法
产品在各种条件下维持规定的性能级别的能力。
前提基础：基本功能能够正常运行
- 异常值输入法
- 故障植入法
- 稳定性测试法
- 压力测试法
- 恢复测试法
3.3.1 异常值输入法
- 一种使用系统不允许用户输入的数值（即异常值）作为测试输入的可靠性测试方法。
- 前面的功能测试中的单运行边界值输入法中边界值的非法输入值也属于异常值输入法
- 一个功能要求输入一组数值或多个参数，对这个功能进行不完整的输入测试，也属于异常值输入法
主要功能是测试系统的容错性，能够测试到系统处理各种错误输入的能力。
3.3.2故障植入法
把系统放在有问题的环境中进行测试的一种可靠性测试法，主要能够测试到质量属性是容错性和成熟性
放在有问题的环境中，输入的是正确值
（1）列出用户的业务环境中有故障、错误或问题的场景，运行正常的业务，观察系统的反应。
出现断网的时候如何解决邮件传递的过程
（2）将软件部署到硬件环境中，考虑当资源不足时系统的反应
（3)考虑系统在软件冲突，驱动不正确的情况下反应是否合理
（4)独立的系统时考虑的是关键器件出现问题时的反应。
3.3.3 稳定性测试法
在一段时间里，长时间大容量运行某种业务。
稳定性测试、压力测试、性能测试存在一定的关系，这个关系的纽带就是产品规格
产品规格：产品承诺的能够处理的最大容量和能力。
性能测试：测试产品真实规格是否和说明书中承诺的需求规格一致。
稳定性测试：低于性能值得前提下测试（模拟普通情况而非极限状态）
压力测试：高于性能值的前提下进行的测试，在这种测试条件下还能够保持符合系统需求的那部分的正确性
四字诀:多、并、复、异
多：增加用户对功能的操作数量
并：并发测试，多个用户同时进行时是否依然稳定
复：让用户反复新建、删除主要时发现系统在资源申请、释放上是否存在问题
异：让一个或多个用户，反复进行异常操作，验证系统是否能够持续做出合理的反应，强调的时反复积累的一个过程。这是有别于故障植入法的。
3.3.4压力测试法
在一段时间内持续使用超过系统规格的负载进行测试的一种可靠性测试方法
采用突发形态的负载模型(用户的真实使用情况是无法预估的）
3.3.5恢复测试法
指使用持续超过规格的负载进行了测试后，再将负载降到规格以内的测试方法。
恢复测试法能够对系统的可恢复性进行测试：即在超负载的情况下正常规格范围内允许出现错误，这一点有别于压力测试，压力测试是正常规格范围内不允许出现错误的
3.4 性能测试方法
测试产品真实规格是否和说明书中承诺的需求规格一致，我们实测出来的性能值，就是系统真正能够处理的最大容量或者能力。
- 测试出系统最好的性能值
可以参考需求规格中的要求作为参考范围
1）系统能够正确处理新业务的最大能力
一个新建的过程，同时满足多少个用户上线登录
回收测试的过程也很重要，一般回收的过程要快于新建的过程
2）系统能够同时正确处理的最大业务能力
一般为并发过程，同时能够满足多少个用户在线，登录等。
要注意测试指标之间的内在关系，在测试一个指标的时候，别的指标不能对这个指标造成影响。
- 分析会影响性能值得各种因素，测试它们对性能的影响
配置和业务都会性能指标产生影响：分析影响性能的因素
比如你在做数学题的时候你一个小时平均能做5道题，那如果这个时候你去打电话了，你的”性能值“就会下降，这个即为影响因素
以邮件发收来测试的话
测试点：邮件大小
测试点：配置的邮件过滤
从多个方面考虑影响性能值的因素：影响因子最大是什么，进一步分析结论；各个影响因子对性能影响趋势。数学中的影响曲线来判断；性能的最坏值，是否会造成系统的瓶颈。
以上是单个影响因素的测试，可以利用数学的方法建立测试模型，通过模型发现一些性能”瓶颈“或问题，在分析问题，实测确认。
多个因素需要结合典型的场景进行。
- 以场景为单位来测试性能
固定某一个值，配置另外的值。
3.5 易用性测试法
用户在理解、使用产品时产品的能力。
- 一致性测试法
测试对象是用户界面（UI测试） 如Web页面、命令行等用户和产品直接进行交互的地方
关注的是产品的用户界面：
可以直接对产品的UI设计原型进行测试，无须等待功能全面集成后进行
界面测试是一个”确认“性质的测试
目的是”证实“，具体方法如下：
需要有一个清查表（check list），让测试人员可以基于对设计规范的理解来进行测试。采用抽测的方式对结果反馈给负责人。
- 可用性测试法
也是界面测试，关注的是产品提供的功能。需要结合功能测试，在特定的场景（测试粒度），以用户的视角进行测试
进行交叉测试：由功能测试人员和非功能测试人员交叉进行
4.测试设计技术
测试用例：一份测试说明书，说明产品在某种输入条件下，应该输出怎样的预期。
4.1测试点不等于测试用例
测试点表中可能存在以下的问题：
- 内容上有重复，存在冗余
- 测试点输入不明确
- 会反复搭建相似的环境，做类似的操作
- 测试点太粗
测试点只是一些散乱的测试思路的集合，测试用例就是一份真正能够指导测试的测试说明书。
4.2 四步测试设计法
测试设计：把测试点加工为测试用例。
测试分析过程，对被测对象按照测试方法进行思考，得到的测试点。
测试设计过程：对测试点进行加工时用到的方法（路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法）
测试分析是一个”发现性“的过程
四步测试设计法用于输出优质的测试用例
1、建模（选模）
针对测试点对其进行分类：
- 流程：流程图
- 参数：输入输出表
- 数据：等价类分析表
- 组合：因子表
2、设计基础测试用例
基础测试用例是对上述的测试模型进行覆盖，所以只是确定了测试条件（在XX情况下，进行XX的测试的描述）
3、补充测试数据
确定测试输入，补充测试数据
4、扩展
根据经验进行补充
4.3对测试点进行分类
分析测试点符合的特征：流程类、参数类、数据类、组合类
1、流程类的特征
能够将测试点绘制成流程图
有时候，一个测试点可能只能绘出一个流程片段，我们可以把与此
相关的测试点放到一起，使其能够表示一个较为完整的流程。
举例说明：
测试点1-4描述的是pc连接wifi时的一些操作，是要放在一起进行分析的。
测试点5：从支持的配置参数角度来看的，不属于流程类的测试点
2、参数类的特征
有两个重要的点：
- ”参数值“的个数是有限的，可以通过遍历的方式来测试覆盖到
- 系统会对不同的”参数值“作出不同的处理或响应
如果有多个测试点就需要将其组合进行测试。
例如上面提及到的测试点5，加密算法的类型是有限的，不同的加密算法会对应不同的加密效果
通过将测试点1-4和测试点5分开的原因是，突出了测试重点，测试流程时不关注参数类，测试参数类不关注流程类。
3、数据类的特征
两个关键点
- 数据的取值是一个范围，通常不能用遍历的方式来测试覆盖
- 系统对允许输入的”数据“作出的处理或响应往往是一样的。
一般来说两个测试点之间是没有关系的，是可以分开进行测试的。如果有关系就需要通过”等价类“和”边界值“的方法将其转化为参数类的测试点。
举个例子：
测试点3属于测试类，而且测试点3的执行离不开测试点1，2（前置条件）所以将其整体归为数据类
4、组合类的特征
结合三面的三种测试类，将其组合在一起然后进行设计相关的测试类。这里的输入数据可能是参数类型或数据类型。
组合类主要是站在系统的角度去思考，而分开测试某些类型的测试点则是为了保证测试的正确性。
4.4流程类测试设计：路径分析法
使用”四步测试设计法“对流程类的测试点进行测试设计，整体方法如图
1、通过绘制业务流程图来建模
建模就是通过绘制测试点代表的业务流程
2、路径分析法
路径：能够覆盖流程的各种路径进行分析，得到一个路径的集合
不同的覆盖策略，能够得到不同的路径集合。
常见的覆盖策略：
- 语句覆盖
- 分支覆盖
- 全覆盖
- 最小线性无关覆盖
1）语句覆盖
指覆盖系统所有判定和过程的最小路径集合。
不考虑流程中的”判定“以及”过程“之间的相互关系
2）分支覆盖
覆盖系统中每个判定的而所有分支所需的最小路径数。
上面的语句覆盖的情况同样为分支覆盖的结果
3)全覆盖
指100%地覆盖系统所有可能的路径的集合。
可以利用组合排列的方式计算出所有的路径集合，适合于微型系统，对大型系统很难进行
4）最小线性无关
仅保证流程图中每个路径片段能够被至少执行一次，在这种覆盖策略下得到的最少路径组合，就是最小线性无关覆盖。
根据上图的算法得到的线性无关路径
要使用上述的算法来获取相应的线性无关路径的前提条件：
- 流程图的入口和出口不作为边数计算。
- 一个”流程图“只有一个”入口点“和一个”出口点“
不满足以上的条件可能会使得上述的等式失效。
对产品的业务功能建模后，如果存在”多个输入“或者”多个输出“要避免出先前提条件2的情况，可以先对流程图进行分解。
这时最小线性无关路径的总数，等于被分解的每个流程中最小线性无关路径的总和：
举个例子：
拆分前
拆分后
利用上述的等式计算：1+1+2+1=5；（利用判定来计算）
第一个流程图有效的判定为d1.d2不存在两个分支路径，不为判定
3、使用路径分析法来设计基础测试用例
一般来说，在单元测试阶段，主要使用语句覆盖或分支覆盖的方式来设计测试用例；在集成或系统测试阶段，使用最小线性无关覆盖；在重要的部分采用全覆盖。
对于上面的PC连接WIFI的业务流程图将其分为两个子流程
 |
 |
|---|
按照分析可以得到以下的无关路径集合
这里有一个疑问？：流程图2中的首选WIFI是否可用只有一个输出？？不属于一个判定？
4、确定测试数据，完成测试用例
为基础测试用例选择一些测试数据（即“输入”），使得能够被正确执行。划分为参数类和数据类。
5、根据经验补充测试用例
4.5参数类测试设计：“输入—输出表”分析法
四步测试设计：
1、使用“输入-输出表”来建模
上述pc连接wifi的情况，有两个条件选其一，可以得到以下的表格
输入–输出表特别适合测试点的多个参数之间存在相互关系。需要对这些参数进行“组合”分析的情况
举个例子：
这些参数之间的约束条件：
1）用户与L1，L1与L2，用户与L2 ，两者的认证方式必须一致，才能通过
2）L2为强制CHAP规则，则用户也必须为CHAP方式
3）认证的顺序：身份认证1-身份认证2-身份认证3
4）这三个阶段有一个失败，整个过程就失败
制作输入-输出表：使用“正交”的方式组合；去重（按照约束条件）；
去重获得的输入输出表
2、覆盖“输入–输出表”，完成测试用例
在建立：输入-输出表“时，就充分考虑了各个参数之间的关系和它们的约束条件，所以要进行100%覆盖
对输入输出表进行整合，就能够得到对应的测试用例
即对的上述的认证过程的输入输出表整理可以得到以下的测试用例
1、等价类和边界值
等价类
对输入值按照测试效果进行划分，将测试效果相同的测试数据归为一类，然后再测试时只需要在每类中选择一些测试样本来进行测试，无须测试所有的值
边界值
参数在输入边界上取值
等价类和边界值经常结合使用，使用等价类对参数进行划分，然后再将每个等价类的边界值作为测试点
举个例子：允许输入为【0，10】，那么首先分为有效和无效两类，然后再细分取边界值
等价类的划分很关键。
2、使用“等价类分析表”来建模
等价类分析表是一张对数据再“xx条件下“，”有效输入“和”无效输入“进行分析的表，见表4-30
可以将相同的等价类分配到不同的条件中去，以减少测试用例的数量，见表4-32（以“有效等价类”相同为例）
举个例子
修改wifi默认的网络名称
考虑测试点3是在测试点1或2成立的情况下进行的，设计以下的等价类分析表
对上面的分析表进行化简，将相同的有效或无效等价类进行合并整合，结果如下
这里面要注意的是有效等价类可以将全部的因素整合在一起进行测试，无需要进行划分，减少测试项目，而在无效等价类的划分时就需要针对单个因素
3、覆盖等价类分析表完成测试用例
在分析好的等价类进行“边界值”分析，确定具体的测试数据，生成测试用例
首先给每个等价类赋值
接着组合测试条件
全部整合后形成测试用例
根据经验补充测试用例
4.7组合类测试设计：正交分析法
1、使用”因子表“来建模
因子表：分析测试点需要考虑哪些方面，并且这些方面需要哪些内容的表
举个例子
拿上面的WIFI连接来进行测试，测试点在上面有讲解到
从中可以总结出以下的测试点
- WIFI网络的选择；
- 加密的选择；
- 加密算法的选择
由于因子之间有约束，在因子2为加密下，因子3才有效所以建立两个因子表
2、使用"PICI工具“来生成测试用例
将其转化为列为因素，水平为因子取值的表
利用如下的命令就能生成相应的正交测试表
C：\Windows\System32>c：\PICT\pict c：\PICT\test.txt>c： \PICT\testcase.xls
将表中的每一行作为一个测试用例即可
将不同的因子表通过PICT工具生成相应的测试用例，然后再整合形成测试用例
3、根据经验补充测试用例
4.8控制用例粒度
1、控制用例粒度
细粒度：容易发现产品功能的设计和实现方面的问题
粗粒度：容易发现产品在系统上、功能交互上和需求方面的问题。
控制用例粒度，要做的事情：
-
控制测试用例的源头–测试点（用于确保统一）
-
不同的粒度的测试用例可以从不同的角度去发现问题
2、策略覆盖
策略覆盖：将某些不是很重要的测试因子或数据的取值，分配到其他测试用例中，作为其他测试用例的测试数据输入或者测试条件。 -
将测试因子作为测试用例的前置条件
上面是采用轮询的方式去分配因子A的，也可以根据内容的重要性来分配
-
将测试数据作为测试用例的输入
-
测试执行的便利性：尽量将和这个测试用例有关的”因子“或”数据“值分配到一起，达到测试用例的时候可以”顺便“测试这个”因子“或”数据“值得效果
举个例子：考虑PC连接WIFI这个过程需要支持不同得操作系统，并给不同的操作系统分配优先级，经过测试覆盖就可以得到以下的测试用例
4.9 错误推断法
根据经验来判断产品在哪些地方容易出现问题，然后针对这些地方来设计测试用例的方法
优点：发现产品缺陷的能力比较高，
缺点：容易遗漏一些基本功能和场景的测试验证，造成测试遗漏
将错误推断法用在四步测试设计的第4步中，补充测试用例。
5、探索式测试
强调测试人员同时开展测试学习，测试设计，测试执行并根据测试结果反馈及时优化的测试方法
优点：强调实践，边学边测，持续改进
缺点：容易将焦点集中在缺陷发现上而偏离对需求的验证，对基本测试点的测试或覆盖容易不足，测试点不易复用，不易积累
5.1 探索式测试的基本思想:CPIE
- 收集（Collection):收集所有关于测试对象的信息并去理解这些信息
- 划分优先级（Prioritization）：对所有需要测试的任务进行优先级的划分
- 分析调研：对测试的任务进行仔细分析，测试可能输出的结果
- 实验：进行测试实验，确认测试结果和预期是否符合。
5.2 选择合适的探索式测试方法
具体步骤：
- 对产品的特性进行”分区“
- 根据不同的分区来选择合适这个分区的探索式测试方法
1、历史区测试方法
针对”老代码“，前几个版本就存在的软件特性，也包括用于修复已知缺陷的代码。旧版本出现错误可能会重复出现错误。
2、商业区测试方法
针对的是产品的销售特性，指产品的重要功能和特性，是测试时需要重点测试的对象。
3、娱乐区测试方法
针对的时辅助特性，就是那些并不是那么重要的特性的测试。
4、破旧区测试方法
针对的是问题的高发特性。
5、旅馆区测试方法
针对的是平台或维护特性。
6、旅游区测试方法
针对的是噱头特性。关注如何快速访问文件的各种功能。
7、其他区测试法
5.3 开展探索式测试
1、确定探索式测试任务
通过三种思路来确定测试任务的范围：
- 思路一：进行全局场景搜索，探索对象是整个系统
- 思路二：进行特性漫游探索，对象是整个特性
- 思路三：进行局部功能点探索，对象是某个具体的功能
结合上面的测试方法和任务范围确定探索式测试任务
2、设计探索地图并执行探索式测试
根据探索式测试任务来设计探索地图：探索地图就是测试者根据被测对象的特点，使用探索式测试方法分析得到的测试点，然后就可以按照测试点对被测对象进行探索式测试， 并记录测试结果。
可以直接使用测试点当作测试用例来执行，由于是边学习边进行的，能够及时进行确认。
利用测试设计方法，来进行探索式测试：建模，设置测试用例等。
探索式测试的优势就是能够根据测试结果及时调整测试点，更有效地发现产品缺陷。
为了避免测试者陷入无休止地探索中，每个探索任务都需要确定一个完成时间，时间到就停止测试。
3、探索式测试总结
6、自动化测试
- 用好已有的自动化–让现有自动化能在产品测试中发挥最大的功效
- 根据产品的测试需要向自动化团队提出合适的自动化需求，和自动化团队保持良好的互动
6.1 自动化测试的优缺点
不盲目乐观，也不妄自菲薄；不盲从于流行，也不限制于传统，能够真正将当前的自动化水平和产品测试结合起来，发挥它最大的作用。
- "需求”要确定得很清楚，特别是用户的输入输出
- “UI”或者“命令行”尽早确认
- 测试用例尽早写出
6.2 如何评估自动化的收益
1.自动化实施成本
自动化实施成本=前期开发成本+后期的维护成本
前期开发成本：
- 人力：和自动化开发人员相关的费用成本
- 时间：自动化准备时间，自动化开发，调试的时间成本
- 金钱：工具购买、开发、维护的费用成本
后期维护成本：
- 产品变更引起的自动化测试脚本变更的成本
- 定位、修复自动化运行环境引起的脚本的健壮性问题的成本
- 定位、修复自动化运行环境的可靠性问题的成本
- 其他任何位置的引起测试脚本变更的因素引发的成本
3.自动化测试的实施成本比
6.3自动化测试工具介绍
- 单元测试
Compuware系列单元测试工具
- UI自动化测试
- 性能测试
参考以下文章查看主流的测试工具
https://blog.csdn.net/glongljl/article/details/88118740