4.3 实际结果（Actual result）
实际结果是执行复现步骤后软件的现象和产生的行为。
实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。
如果一个动作产生彼此不同的多个缺陷结果。为了易于阅读，这些结果应该使用数字列表分隔开来。例如：
Actual result:
1. Assert “CmdLineofCodeHere…”
2. Assert “AlsoBrokenHere…”
有时，一个动作将产生一个结果，而这个结果又产生另一个结果。这种情况可能难以清晰、简洁地总结。例如：
Actual Result：
1. Assert:“CmdLineofCodeBlahBlah…”
2. When this assert is dismissed, app becomes active but all text is unrecognizable.
3. After selecting the text by dragging the text tool, the text appears normally once again.
对于这些较难处理的情况，有多种使之易于阅读的解决方法：
*尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷；
*在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题；
*在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。
4.4 期望结果（Expected result）
期望结果的描述应该与实际结果的描述方式相同。通常需要列出期望结果的应该是什么，并且给出期望结果的原因，可能是引用的规格说明书、前一版本的表现行为、客户一般需求、排除杂乱信息的需要等等。
为了更清楚地理解良好的期望结果应该包含什么信息，请看下面的例子：
Expected result：
The text that appears should be fully highlighted so that if the user wishes to make changes, they don't have to manually highlight and then type (as in Mac OS 10.x and Windows behavior.)
为什么说这个例子很好呢？因为它包含了如下内容：
*应该产生的正确现象：The text that appears should be fully highlighted
*为什么应该产生：…so that if the user wishes to make changes, they don't have to manually highlight and then type.
*给出了具体得参考对象：As in OS 10.x and Windows behavior.
文章来源于领测软件测试网 https://www.ltesting.net/
