在评估什么是好的测试用例过程中，测试用例是否包含了期望结果是评估测试用例质量的一个重要参考因素。而在测试实践过程中，测试用例包含期望结果也是看着容易，但有时候也是很难很无奈的。
首先，从理论上讲，测试对象的需求规格说明是进行测试用例设计的主要参考之一，且每条需求至少有1个或者多个测试用例进行覆盖。即使提供了完善的需求规格说明，有时候确定测试的期望结果也是不容易的，例如：需求定义测试对象可以创建一个文件。测试人员设计的测试用例应该如何定义期望结果，“文件成功创建”作为期望结果？这个期望结果看着很简单，但是测试人员应该如何去验证文件创建成功了呢？文件可以在列表中找到了？可以打开且编辑该文件？这个时候，从需求中直接得到的结果，并不一定适合作为测试用例的期望结果。
其次，测试对象的需求规格说明是很难完善的，这时候设计测试用例很难，确定期望结果会更加困难。此时，测试人员的经验就会显得非常重要，除了需要参考显性需求之外的其他一些隐性需求，例如：类似产品的行为等。
第三，有些测试类型的测试用例，定义期望结果会更加不容易。例如：测试产品的易用性等质量属性，如何在测试用例中定义期望结果呢？
第四，有时候执行某些测试用例的目的并不是为了验证期望的结果，而是为了得到测试对象的实际结果，例如：测试对象在10000个用户同时在线的时候，其响应速度是多少？尽管我们可以定义其响应速度必须小于1s，但我们更需要知道的是响应速度到底是多少？1s，0.86s，还是1.2s？
第五，测试用例中明确了期望结果，往往就遗漏了其他可能的期望结果类型。例如：在进行容量测试过程中，要创建4094个VLAN，测试用例中定义的期望结果是“4094个VLAN可以成功创建”。但是在实际测试过程中发现4094个VLAN可以成功创建，但是测试对象的相应速度急剧下降。说明期望结果的定义很难是完善的。
[文章来源]：专注于测试能力改进
