测试设计就像一座桥，桥的一端是殷殷期望——当测试做的不够快、上线后出问题、后面的版本发现了前面版本潜藏的缺陷……几乎当研发主管们觉得测试在质量、成本、效率上存在任何问题时，都会条件反射般的建议测试通过提升测试设计能力改善这些问题，达到幸福的彼岸。因为好的测试设计的标准是“用较少的用例达到符合要求的质量”。
然而，当测试用路径、逻辑判定、等价类、边界值、数据组合、N-switch……那些方法设计了“覆盖完整”的测试用例后，发现这样做通往的并非幸福的彼岸，那些期望中想要解决的问题依然照旧。
这个场景相信对很多测试人来说，都不陌生。
So，问题出在哪里呢？
首先，测试设计实际上有三部分内容。
顶层的测试设计明确测试的范围：这个版本或者特性是就验证基本功能就好？还是需要深入的进行参数、流程、逻辑、特性组合等方面的测试；是否需要验证性能？是验证响应速度还是并发量；是否需要验证安装、帮助、安全性、可靠性、耗电、下载途径等……
这方面的测试设计，我们称之为“测试策略分析”。
测试策略直接决定了总体上测试需要花多少时间，哪些方面的问题必然无法发现，这是测试设计最重要的“纲”。但是，现实项目中这部分设计并不会太花精力，因为在大部分情况下，按照产品的“惯例”确定测试范围就足够了。
中间层的测试设计思考的是产品/特性在什么环境（机器、网络）、什么场景（什么时候，谁，由于什么目的，做一件什么事情，怎么做的）下使用，使用的时候业务流、数据流是怎样的，有哪些数据和特性参与了这个处理过程，如何产生影响。
这方面的测试设计，我们称之为“测试对象分析”或者“测试分析”。
测试对象分析直接影响了测试的覆盖程度，即测试的质量，这是测试设计最核心的分析内容。不过，在大部分情况下，性能或其他DFX的测试工程师更重视测试分析，而功能测试的测试工程师花在测试分析上的精力很少，其原因后面会讨论。
底层的测试设计决定测试哪些流程、参数、组合需要测试。
我们所说的“测试设计”、“测试设计方法”，很多时候就是指的这部分内容。后面“测试设计”一词，专指这里狭义上的、底层的测试设计。
测试设计生产出了测试执行所需要的用例，通常在测试项目中会精心管理、反复使用的，就是这些测试用例，这也是测试工程师最熟悉、花精力最多的设计工作。
其次，测试分析才是测试的“质量担当”。
很多时候，让测试工程师觉得“耻辱”的并非系统对异常的处理不当导致的问题，而是明明很正常的输入，只要覆盖到了就一定会发现的缺陷，但是测试的时候就是没覆盖到。
在用户那里发现的大部分问题，也并不需要复杂的操作、奇怪的数据，或者对系统进行攻击，就是用户想要实现某个挺合理的目的，进行了正常的操作。
分支组合、条件组合、边界值和数据组合这些测试设计方法的应用，很难覆盖上述问题，因为这些方法着眼的是代码的覆盖，而质量问题，常常是需要改善需求或者概要设计层面的覆盖，这是测试分析的责任。
但现实中，测试工程师往往不会花太多精力在测试分析上，也很少对测试分析进行精雕细琢，究其原因，大概有：
1、进度压力，因为测试分析之后还有大量的测试设计、编写用例、自动化的工作等着，不允许测试工程师在测试分析环节上逗留太久。
2、设计变更，特性的设计方案常常是在编码完成之前，都在不断修改的，而测试分析主要依据的就是这些设计方案，同步变更时非常累人的事情。
3、再好的测试分析结果都是一个过程输出件，测试执行时是否都覆盖到了，观察点是否足够，是否有错误被忽略了，这些对测试质量的影响也很大，也有许多问题是后面这些原因导致的遗漏。所以，潜意识里，测试工程师并不觉得测试分析至关重要，后面还有很多环节可以修正、补充。
4、做好测试分析太难，而做得好不好又不便衡量。我认为这是测试不受重视的深层原因。
前面的那些问题，我刚刚开始做问题分析的时候，也觉得不可思议，这么正常的数据，怎么就会漏了？态度原因？但是，真正把自己放到那个环境中，却发现自己也不一定就能保证不遗漏。
测试分析的方法建设比较弱，不像测试设计的方法（如，分支组合、条件组合、边界值和数据组合）可操作性比较强，基本上应用这些方法是能够保证这个层次的覆盖的。测试分析的方法（如，判定表、分类树、状态转换、活动图、数据周期等）都是表示方法，不是操作方法，做不到跟着某个方法一步步走，就可以确保这个层次的覆盖。测试分析本质上是需要一个测试人员对无数用户可能的行为及其参数进行建模，以考察这些行为对系统的影响，而测试领域也还没有形成针对不同领域，不同特性类别的建模模式。所以，测试分析方面的方法是不够的。
此外，做好测试分析需要非常多的信息，除了新特性的设计文档，至少还有关于需求的应用场景、使用目的、风险、用户背景等等；关于设计的业务流、数据流、控制逻辑、接口、数据结构；关于架构的相关模块、层次关系等。最要命的是，对经验也有很强的依赖，过往是否有类似、相关、相斥的需求，这些需求在测试和应用中出过什么样的问题等。
可以看出来，除非有技术方面革命性的突破，否则测试分析的难题，唯有通过时间和项目经验的积累来解决。测试分析的难点也正在于这里，做好测试分析可能是测试人的终身修炼。
当然，在测试设计开始之前先做好测试分析，这并不是改善测试覆盖的唯一方法（事实上，这是瀑布模式下的做法）。录制回放真实用户的操作过程可以改善产品常见应用场景的覆盖。通过未覆盖代码倒推未覆盖参数或场景，可以改善对设计方案的覆盖。利用测试分析要素清单（或脑图），改善某个特定的设计要素的覆盖。探索式测试可以在测试执行过程中，通过不断的试错和修正提升覆盖（其实是将测试分析延续到测试执行中）……
总之，测试做的不够快、上线后出问题、后面的版本发现了前面版本潜藏的缺陷……，这些问题是需要通过测试的各种设计活动来根本解决的，但解决的计划必须视情况而定。
如果通过强化测试设计就能解决，那么你可以期望这个问题较快的解决，因为测试设计的方法相对比较成熟，也不难掌握。
如果需要调整测试策略，扩展测试范围，那么这个问题解决起来会慢一点，因为新的测试内容往往需要新的工具、新的知识，需要花一些时间入门。此外，DFX测试通常都既耗资源又耗时间，因此，实施起来也会慢一些。
大部分情况下，我们没有那么幸运，需要改善的是测试分析，那么这个问题只能一块一块的啃，根据问题的不同制定不同的解决对策，无法期望这类问题一过性、彻底的解决。
题外话，时下比较流行的探索式测试、MBT都将测试分析延续到测试执行，很可能是由于这种做法符合软件开发的规律。
作者个人简介：杨晓慧
前华为技术有限公司-软件公司首席测试专家。1999年进入华为公司，先后主持过产品测试、测试流程改造、测试工程师职业发展等工作。2007年以后主管软件公司的测试技术架构设计、实现、应用，通过帮助产品持续积累和提升测试技术能力，实现研发的效率和质量提升
个人出书的购买地址如下，请大家支持：
https://item.jd.com/12085936.html
http://product.china-pub.com/5035410
http://product.dangdang.com/24160890.html
杨晓慧个人的公众号：
