（3）测试环境：发现Bug的测试环境

　　（4）测试步骤：详细描述发现Bug的操作步骤和流程

　　（5）实际结果：按照测试步骤测试后实际出来的操作结果

　　（6）预期结果：按照测试步骤测试后原本预期的操作结果

　　（7）测试结论：通过对比实际结果和预期结果，“诊断”程序出错原因

　　（8）归纳引申：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

　　举例：

　　（1）试点：检查点对点互通（简称P2P）网关系统短信过滤模块smfilter在大压力业务的时候是否有内存泄露或CPU暴涨。、

　　（2）测试配置：将系统所有模块的配置都调整到最优化配置，数据库中导入100万个手机过滤黑名单和50万个过滤关键词。

　　（3）测试环境：smfilter安装在10.3.3.92，其余业务模块安装在10.3.3.91，测试工具安装在10.3.3.96，均为suse9操作系统；数据库安装在10.3.3.96，为oracle9204版本。

　　（4）测试步骤：

　　A、清理测试环境，确保测试环境干净。

　　B、使用top查看系统各模块资源在正常范围之内：smfilter的内存使用5%（10M），CPU使用率为6%。

　　C、使用手机模拟测试工具向P2P网关发送1000万条MO短信，同时使用网关模拟工具向P2P网关系统前转1000万条MT短信；其中各有200万条MO/MT短信含有是黑名单号码，200万条MO/MT短信内容含有关键词。

　　D、观察smilter的内存使用率和CPU使用率是否上涨，发现CPU使用率在正常范围之内缓慢上升，但内存使用率则不断狂涨。

　　（4）实际结果：短信发送高峰期，CPU使用率为56%，短信发送完毕CPU使用率恢复到8%；而内存使用则从原来的10M一直上涨到1.6G，且短信发送完毕也没有下降。

　　（5）预期结果：在压力测试过程中，CPU和内存应该在正常范围内缓慢上升，短信发送完毕应该恢复到测试开始时的使用率。

　　（6）测试结论：smfilter在大压力的情况下出现内存泄露的情况，请及时查找原因并解决。

　　3、 新需求Bug描述

　　在后期维护中，对于新的需求，也作为Bug记录进Bug跟踪管理系统。在作为一个Bug增加进系统之前，应该由项目经理、开发人员和测试人员对新需求进行了评估和讨论，最终决定了解决方案。在这个过程中，测试人员充当着一个非常重要的角色，需要对需求非常明确，而且应该从系统的高度和设计的高度全面考虑需求的实现。此时作为Bug的描述，应该包括（根据实际情况选择）：

　　（1）求说明：详细的需求要点。

　　（2）配置说明：是否需要增加或修改配置，如果需要则详细说明应该增加或修改的配置。

　　（3）数据库结构：是否需要新增或修改数据库表结构，如果需要则详细说明新的数据库结构。

　　（4）实现方法：实现新需求采取的策略或技术，这部分通常是在讨论的时候由项目经理和开发人员决定的，当然，测试人员应该审核采取这样的技术是否真的合理，这就要求测试人员有比较强的技术背景了。

　　（5）业务流程：新需求在处理过程的业务流程，对于业务流程该如何处理，测试人员事先一定要先确认，并在Bug描述中进行详细的描述，使开发实现新需求以及测试人员验证新需求提供有效的依据。根据经验，有些时候，开发也不会很全面考虑整个系统的业务流程，经常会出现新增功能增加之后新问题又出来的情况，如果测试人员可以在描述中清楚说明整个业务的处理流程，就可以大大减轻开发工作量和测试工作量了。当然，前提是测试人员自己一定要对业务流程有一个非常清晰的概念，对于一些不能确认的流程，在事先可以征求项目经理的意见或与开发讨论确认。

　　（6）异常处理：在新增一个功能的时候，需要考虑这个功能可能会出现什么异常，这些异常出现的时候系统该如何处理。

　　举例：

　　（1）需求点：为了提高高峰期点对点互通网关短信状态报告处理效率，增加状态报告缓存处理功能