测试用例设计中，期望结果的明确性至关重要，但实践中往往面临诸多挑战。即使基于完整的需求规格，验证如文件创建成功的具体标准也可能模糊；不完善的需求让确定期望结果更为困难，需要依赖测试人员的经验；某些测试类型如易用性的评估难以量化；部分测试目的是获取实际结果而非验证预期；明确的期望结果可能导致其他潜在问题被忽视。
测试用例的期望结果：看着很美但有时很无奈
在评估什么是好的测试用例过程中，测试用例是否包含了期望结果是评估测试用例质量的一个重要参考因素。而在测试实践过程中，测试用例包含期望结果也是看着容易，但有时候也是很难很无奈的。
首先，从理论上讲，测试对象的需求规格说明是进行测试用例设计的主要参考之一，且每条需求至少有1个或者多个测试用例进行覆盖。即使提供了完善的需求规格说明，有时候确定测试的期望结果也是不容易的，例如：需求定义测试对象可以创建一个文件。测试人员设计的测试用例应该如何定义期望结果，“文件成功创建”作为期望结果？这个期望结果看着很简单，但是测试人员应该如何去验证文件创建成功了呢？文件可以在列表中找到了？可以打开且编辑该文件？这个时候，从需求中直接得到的结果，并不一定适合作为测试用例的期望结果。
其次，测试对象的需求规格说明是很难完善的，这时候设计测试用例很难，确定期望结果会更加困难。此时，测试人员的经验就会显得非常重要，除了需要参考显性需求之外的其他一些隐性需求，例如：类似产品的行为等。
第三，有些测试类型的测试用例，定义期望结果会更加不容易。例如：测试产品的易用性等质量属性，如何在测试用例中定义期望结果呢？
第四，有时候执行某些测试用例的目的并不是为了验证期望的结果，而是为了得到测试对象的实际结果，例如：测试对象在10000个用户同时在线的时候，其响应速度是多少？尽管我们可以定义其响应速度必须小于1s，但我们更需要知道的是响应速度到底是多少？1s，0.86s，还是1.2s？
第五，测试用例中明确了期望结果，往往就遗漏了其他可能的期望结果类型。例如：在进行容量测试过程中，要创建4094个VLAN，测试用例中定义的期望结果是“4094个VLAN可以成功创建”。但是
最低0.47元/天 解锁文章
扫一扫
870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
