如果在一开始你就不能成功的使软件行为发生改变，那么利用文档作为一种使bug report继续有效并且有可能改变开发人员情绪的方法，集中精力在描述错误信息的词语和文档上。不一致的矛盾可能可以提供构思错误的线索。
“当我点击文件à打开，应用程序崩溃了，清除了我的硬盘，并且踢到了我的猫。”
这是一个令人信服的bug report。你可能不需要参考用户手册来解释文件à打开功能制造了骚扰你宠物的这一功能不是软件设计的功能。然而每天我们经常处理的那些普通的，严重程度低的错误不是这样的清晰，并且导致组织采取的措施同样也不清楚。
成为bug的拥护者
当你提交一个bug report的时候，你就成为了bug的拥护者－跟进bug以了解bug是否被定位这是你的工作。你写报告的方法影响着软件的行为是否会被更改，文档是否会被更改为和现实的行为相匹配，或者是错误被忽视。许多没有提倡使用精确操作过程的bug report，同样也是很容易被忽视的。思考这份简短的bug report：“当我用没有带任何参数的命令行启动软件时，我得到了一个“错误文件名”的错误，同时应用程序也中止了”。
写这个报告的测试人员是希望没有指定带参数的命令行有一个特定的默认行为吗？或是测试人员希望文档能够更好地解释为什么至少要给予命令行一个参数？或者是她只是希望要一个更好的错误信息呢？可能她并不在乎要修复成什么样，只是要一个用户清楚并且行为和文档相匹配的结果？让我们看看四种能够集中提高修改上面的bug report的机会方法。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
