4.2 复现步骤（Reproducible Steps）  

    复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

    但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于以下三个方面：

    *复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解；
    *复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员；
    *测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。

    为了避免出现这些问题，良好的复现步骤应该包含本质的信息，并按照下列方式书写：

    *提供测试的预备步骤和信息；
        &环境变量。例如，如果默认项或预设、调试版本或发布版本等存在问题，请指明使用的操作系统和应用程序的环境变量；
        &设置变量：指明哪种打印机、字体或驱动程序是复现Bug所必需的信息；
        &复现路径。如果有多种方法触发该缺陷，请在步骤中包含这些方法。同样地，如果某些路径不触发该缺陷，也要包含这些路径。
    *简单地一步一步地引导复现该缺陷；
    *每一个步骤尽量只记录一个操作；
    *每一个步骤前使用数字对步骤编号；
    *尽量使用短语和短句，避免复杂句型和句式；
    *复现的操作步骤要完整，准确，简短；
    *没有缺漏任何操作步骤；
    *每个步骤都是准确无误的；
    *没有任何多余的步骤；
    *将常见步骤合并为较少步骤，例如：
       1. Create text frame.
       2. Add text.

    可以简单的合并成一步：

    1. Create a new text frame and add text.

    *只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果
    需要再次引起注意的是，缺陷报告的读者对技术有基本的了解，但是对软件测试的细节可能所知有限。因此，一方面，没有必要在缺陷报告中告诉启动产品或者如何打开一个文件等简单操作方法。另一方面，不要包含软件测试过分详细的技术细节，除非这些是缺陷至关重要的信息。

    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.

    4.5 注释（Notes）

    注释应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。

    注释部分可以包含以下各方面的内容：

    *截取缺陷特征图像文件（Screenshots）；
    *测试过程需要使用的测试文件；
    *测试附加的打印机驱动程序；
    *再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
    *再次指明该缺陷是否在前一版本已经存在；
    *多个平台之间是否具有不同表现；
    *注释包含缺陷的隔离信息，指出缺陷的具体影响范围。

    例如，缺陷的注释可能包含下面的内容：

    Notes：

    1.Text displays outside frame in Win2000 and WinXP, but not Win98.
    2.Does not happen after screen has redrawn.
    3.Does not occur when two documents are open.
    4.Refer to attached screenshots and testing file
 
    5. 缺陷报告的写作注意事项

    提高缺陷报告的写作水平是不断积累经验，循序渐进的过程。在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，避免很多不必要的错误。

    5.1 自我检查和提问

    *缺陷报告已经向读者包含完整、准确、必要的信息了吗？
    *一个缺陷报告中是否之报告了一种缺陷？
    *读者是否能容易的搜索该缺陷？
    *步骤是否可以完全复现而且表达清楚吗？
    *是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
    *缺陷的标题是按照原因与结果的方式书写的吗？
    *实际结果和期望结果是否描述不够清楚而容易引起歧义吗？
 
    5.2 避免常见的错误

    *使用“I（我）”、“You（你）”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替；
    *使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
    *使用诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含义模糊的词汇，而需要报告确定的缺陷结果；
    *包含认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可；
    *将不确定的测试问题（Issues）放在缺陷管理数据库中。如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性。