不要再把测试点和测试用例搞混啦

 一、用户发送电子邮件的测试点

用户使用正常的输入数据来发送电子邮件

用户使用边界值来发送电子邮件

用户收到一封电子邮件后，再接着发送这封收到的电子邮件

用户正在发送电子邮件的过程中，同时又接收到了电子邮件

用户使用异常的输入数据来发送电子邮件

在存在网络故障的情况下发送电子邮件

一个用户持续发送1000封电子邮件

500个用户同时发送电子邮件（稳定性测试）

500个用户反复进行登录邮箱、编写邮件、发送邮件、退出邮箱操作的测试

用户持续（如1天、1周）发送接收邮件地址是非法输入值的邮件

用户在长时间（如1天、1周）处于网络故障的情况下

1000个用户发送电子邮件（性能规格测试）

以每5分钟为一个周期，在一个周期里，前4分钟为400个用户同时发送电子邮件，后1分钟为1100

用户同时发送电子邮件，持续测试1天

600个用户同时发送电子邮件，持续测试1天

二、测试点不等同于测试用例

测试点和测试用例是不同的，如果我们拿测试点来进行测试，会发现很多困惑的问题。

问题1：这些测试点在内容上有重复，存在冗余

例如：发送邮件测试点1和测试点4都会测试到“正确发送邮件”。

问题2：一些测试点的测试输入不明确，不知道测试时要测试哪些

例如：发送邮件测试点1时，我们并不知道我们要测试哪些“正常的输入数据”。存在类似问题的测试点5。

问题3：总是在搭相似的环境，做类似的操作

有些测试点之间存在一定的执行顺序，需要把这些测试点放在一起测试。例如，先执行测试点6，再紧接着执行测试点11，可以最大限度地利用之前的测试环境和测试结果。

问题4：测试点描述得太粗，不知道是不是测对了。

有些测试点写得很粗，我们不知道测试目标是什么，或是该关注哪些地方。例如，测试点4，我们不知道将“用户发送电子邮件”和“用户接收电子邮件”这两个操作放在一起，它们的“交互点”在哪里？我们需要发送特殊的电子邮件，还是随便发送一篇就可以了？这使得测试人员可能会漏掉一些关键内容，测不到点子上。

三、测试点是测试者在测试时需要关注的地方

虽然我们在分析测试点时，会使用各种测试方法，但这些方法在思路和操作上都是不同的，一些方法得到的测试点要细一些、具体一些，一些方法得到的测试点粗一些、泛一些是非常正常的。另外，谁也不能保证这些测试点之间不会重复或是相互包含。

四、测试用例是在测试点“加工”的基础上得到的

总结为以下3个要点：

去重：首先去掉重复的内容

合并：然后把太细的测试点合并起来

细化：接着把太泛的测试点说清楚、说具体

经过上面的整理后，再确定各个测试点的前置条件、测试数据、执行步骤和预期结果。如果说测试点像是一些散乱的测试思路集合，那么测试用例就是一份真正能够指导测试的详细说明书。