测试分析不等于测试设计
一般测试分析与设计，最终以输出一个测试设计结束，容易忽略测试分析，将测试分析和测试设计混淆。实际上，测试分析与测试设计是不同的，更不用说等价了。
测试分析是一种分析活动，输入可以是前期对系统、设计有帮助的任何信息，如需求、场景、架构、设计、规范、友商信息等。通过测试分析，希望对被测系统能有深入的理解，获得测试点，明确测试深度和广度。
测试点即测试中需要关注的地方，包含测试条件、测试数据、测试观察点、测试预期、测试约束和限制等。
测试设计是一种设计活动，是依据测试点按照一定的方法和规范要求，得到测试执行依据（即测试用例）的过程。
测试用例是测试执行的依据，一般包含预置条件、部署、标题、步骤、测试数据、预期结果等。
测试点不等于测试用例
测试分析时，思维是活跃、发散的，得到的测试点难免会重复、冗余，也就无法保证测试点描述的粒度是一致的，很有可能有些测试点描述得很粗，有些又写得特别细。如果直接将测试点作为测试用例来执行，会发现执行起来会有各种不顺。
以发送电子邮件的测试点为例
问题1：不同的测试点在内容上容易存在重复或者冗余。
问题2：一些测试点的测试输入不明确，让测试执行者不知道要怎么执行测试。
测试点1，并不知道要测试哪些正常的输入，有多少种输入参数类别，这些参数之间是不是存在约束关系、是否需要组合。在存在这些问题的情况下，若还执行测试就会很容易遗漏测试点或者出现过度测试的情况。
问题3：测试点不同但搭建的总是相似的环境，做类似的操作。
很多测试点之间都存在一定的顺序关系，需要把这类测试点放在一起测试，这样不仅可以提高测试效率，还有利于发现测试问题。
测试点6和测试点11，如果先执行测试点6，再立马执行测试点11，就可以最大限度地利用测试点6的测试环境。但如果在测试时没注意到这一点，执行完测试点6后执行测试点7，等到执行测试点11时，还要再搭一次和测试点6一样的环境，再做一遍和测试点6一样的操作，这会严重影响测试效率。
问题4：测试点描述得太粗或太细。
有些测试点写得很粗，不知道测试目的、输入、预期是什么。测试点4，除了设计者本人，其他测试者看到这个测试项，可能并不知道把“用户发送电子邮件”和“用户接收的电子邮件”放在一起究竟要测什么，是需要构造特殊电子邮件来进行测试，还是随便发送一封邮件来测试就可以。
有些测试点又写得很细，测试点13，测试者在执行这个测试点的时候会感到很死板，有可能陷入细节中，忽视了对系统其他地方的观察，失去手工测试的主观能动性。
测试点并不等于测试用例，希望的测试用例是一份能够详细指导测试执行的测试说明书，其应说明产品在怎样的条件下工作，预期是什么。要想得到测试用例，就需要对测试点进行再加工。
跟刘老师学到了，什么是测试分析，什么是测试设计，以及二者的区别是什么？测试分析的输入是什么，输出是什么？测试设计的输入是什么，输出是什么？
一般项目内，会输出测试设计和测试用例，往往少了测试分析的过程，这部分也很重要，可以复制和分享学习。测试分析不到位，测试设计肯定会不到位。测试设计也很关键，输入是测试分析的测试点，输出是可执行的测试用例。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
