如何发现及准确描述BUG.pptVIP

* * * * * * * * * * * * * * * 1.6License控制 测试License是否生效。 License限制值是否生效。 License的时效。 如何发现BUG 二、特殊方法 2.1压力测试 长时间测试。 反复操作，反复的配置操作，如配置增、删、改。配置的压力测试对一般模块基本都适用，属于必选测试项。 大量并发操作，如大量用户同时上、下线。 资源使用极限条件下功能模块的工作情况测试，这些极限条件可能是：高CPU、内存利用率等。 批量操作，如一条命令导致的大量信息的添加、删除（no xxx all）等。 压力测试常能发现较为严重的bug。 如何发现BUG 2.2规格测试 规格数量下的配置的保存和加载。保存后查看配置是否丢失，加载时观察是否有配置无法加载。重启查看配置是否丢失。 验证规格数量下功能的正常工作。如10000个VPN隧道（假设规格为10000个VPN）能否建立并转发流量，有些功能如果无法验证规格数量下功能工作情况，则至少应该选取其中部分实体进行验证，如配置1024个地址薄后，检查其中任意被引用的地址薄工作是否正常。 通常这里都是有bug的，而且都是4-5级bug。 如何发现BUG 2.3性能测试 性能对比：通常要求新建、吞吐、时延比上主线版本下降小于5%。 性能评估：对版本在不同平台上的性能进行摸底测试，输出性能评估报告。 如果性能下降较多，说明代码需要优化，必须报bug。 如何发现BUG 2.4内存检查 找到触发内存申请、释放的地方进行测试，并进行压力测试，防止有内存泄漏的情况； 了解功能的内存使用基本单位，（如：创建一条session将占用内存x字节）计算该功能最大消耗内存的数值，可能是其满负荷运行或达到规格数时处于最大内存占用点，在这个点进行测试； 测试在d-plane内存剩余很小的情况下，模块申请内存失败后是否能够正确处理或返回。如dp memory剩余很小的时候创建QoS IP queue失败，是否能够正确返回； 由于每种硬件平台的内存配备不同，因此需要针对不同平台考虑测试。如内存配置小的平台更容易达到内存使用极限。 内存泄露也是常见的严重bug，常会导致进程、系统异常，最终导致功能不可用。 如何发现BUG 2.5通用性检查 选用上一个主线版本或者不支持该特性的版本进行配置的降级验证。正常情况下不支持的特性的配置应该是加载失败，如果出现其他情况都是异常。 如何发现BUG 2.6Debug测试 模块相关的debug是否存在； 模块相关的debug是否可以开关； 模块相关的debug输出的信息是否具有高可读性、语法正确； 模块相关的debug是否能够导出到相关指定的位置：buffer、terminal、syslog等。 如何发现BUG 2.7易用性测试 从易用性角度考虑功能实现上可以增强的地方，包括用户界面的友好性、操作的高效、适时的用户指导和帮助信息。 这一类bug需要测试人员足够的敏感和站在客户角度考虑问题。通常这一类bug在功能上没有问题，只是不符合人们使用习惯、操作不便等。 如何发现BUG 2.8互通性测试 与友商设备（如，cisco、华为）互联，功能验证； 与同平台不同版本互联，功能验证。 前面所有测试都只是保证在同一个版本上功能的可用性，但不能忽视和友商之间的互联，现网中充斥着各个厂商的设备，如果我们的实现或者友商的实现不符合规范将导致连通性的问题，只有在互通性测试时才能发现。经验不够丰富的测试人员通常会遗漏这个测试点。 如何发现BUG 三、高速法： 查看QC系统中的BUG，学习别人的思路。发散思路常能发现bug。 如何发现BUG 祝大家好运！ 发现bug后该做些什么？ 不确定问题原因甚至不确定是否是bug及bug很严重，如，进程crash时应找开发人员定位； 若能够明确认定是bug，需要找复现条件，确认是否是必现bug； 若非必现，则需要多次复现bug，准确描述复现概率。 明确bug阅读对象是谁？ 修改该bug的开发：模块开发人员、开发经理； 验证该bug的测试：自己或回归该bug的测试人员、测试经理； 所有对bug感兴趣的人员：前端、PM、文档等。 如何准确清晰的描述BUG 如何准确清晰的描述BUG 一个例子：最后再来讨论 Summary（摘要）该如何写？ 简单明了，便于理解 长度一般不超过30个字 尽可能讲明：什么情况，导致了什么问题 如何准确清晰的描述BUG Description（描述）该如何写？ 1)复现步骤（Actions） 详细描述重现该问题的关键步骤； 省略无关的操作，力求做到：所有重现步骤是充分的和必要的； 容易理解的常规步骤，可以一句话带过，比如以管理员身份登录，进入后台用户管理页面； 与环境有关的问题，给出特定的条件，比如：某某操作系统