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.
4.5 注释（Notes）
注释应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。
注释部分可以包含以下各方面的内容：
- 截取缺陷特征图像文件（Screenshots）；
- 测试过程需要使用的测试文件；
- 测试附加的打印机驱动程序；
- 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
- 再次指明该缺陷是否在前一版本已经存在；
- 多个平台之间是否具有不同表现；
- 注释包含缺陷的隔离信息，指出缺陷的具体影响范围。
例如，缺陷的注释可能包含下面的内容：
Notes：
- Text displays outside frame in Win2000 and WinXP, but not Win98.
- Does not happen after screen has redrawn.
- Does not occur when two documents are open.
- Refer to attached screenshots and testing file
5. 缺陷报告的写作注意事项
提高缺陷报告的写作水平是不断积累经验，循序渐进的过程。在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，避免很多不必要的错误。
5.1 自我检查和提问
- 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
- 一个缺陷报告中是否之报告了一种缺陷？
- 读者是否能容易的搜索该缺陷？
- 步骤是否可以完全复现而且表达清楚吗？
- 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
- 缺陷的标题是按照原因与结果的方式书写的吗？
- 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？
5.2 避免常见的错误
- 使用“I（我）”、“You（你）”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替；
- 使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
- 使用诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含义模糊的词汇，而需要报告确定的缺陷结果；
- 包含认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可；
- 将不确定的测试问题（Issues）放在缺陷管理数据库中。如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性。
