如何发现及准确描述BUG

如何发现及准确描述BUG安网测试二部郭晨2014/05/24目标什么是BUG如何发现BUG如何准确清晰的描述BUG什么是BUG什么问题能定义为BUG？产品说明书规定要做的，却没有实现；产品说明书规定不要做的，却实现了；产品说明书没有提到的事情，也实现了的；产品说明书中没有提到但是是必须要做的事情，没有实现；很难理解，很难去使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。如何发现BUG首先，要有好奇心。其次，要坚信：我测的东西一定有BUG。如何发现BUG将分为常规方法、特殊方法和高速法三个个方面介绍。如何发现BUG一、常规方法：1.1命令行测试1.1.1列出模块所有待测的命令行，举例：1.新增的配置命令。address-familyIPv6unicastredistribute{connected|ospf|rip|static}[metric<0–4294967295>]neighbor{X:X:X:X::X|A.B.C.D}{activate|default-originate|description|ebgp-multihop|fall-over|filter-list|next-hop-self|password|peer-group|remote-as|route-map|sedn-community|shutdown|timers|update-source}2.新增的show命令。showipbgpipv6unicast{vroutervrname|x:x:x:x::x/0-128}showipbgpipv6unicastneighborshowipbgpipv6unicastsummary3.新增的debug命令。1.1.2命令行测试的关注点测试命令行的自动补齐功能。测试命令行大小写，以及大小写混用。测试命令行的在线帮助功能。测试命令行的参数边界值，合法输入和非法输入，输入不完整和输入完整时的检查。测试show（包括新增的show命令和showrunningconfig）命令显示。所有命令都配置后保存配置并重启。命令行测试较少出现bug，但属于用户常用操作，需要覆盖完全。相较而言较容易出现bug的地方：在线帮助信息不正确、规范；非法输入时系统异常；边界值或越界时系统异常；show命令输出信息不规范、缺失；重启后配置丢失。如何发现BUG1.2功能验证1.2.1功能测试一功能覆盖：根据设计实现进行功能覆盖。测试的重心在于此，Bug的最多产出也在于此。测试根据用例执行，但不应限于用例，我们需要随时保持一个发散的思维。模块集成、组合测试：强相关模块的组合测试，例如NAT和ALG、NAT和IPSecVPN。异常、容错性测试：异常的输入（非命令行的非法输入）或流量，如异常的分片报文、无效的ICMPcode/type、无效的用户名、密码登陆；超负荷运行，如超过系统容忍的并发连接；隧道场景：功能相关流量在tunnel中的转发。如何发现BUG1.2.2功能测试二HA场景：AP、AA模式下功能相关配置、状态能够正确同步，主备倒换时流量是否中断。基于流的考虑：例如ALG的FTP控制报文为分片报文时，能否正确创建pinhole、非对称路由。VLAN场景：在二层流量下报文带tag时对模块的影响。VSYS场景：若支持，进行功能验证；若不支持，查看配置是否屏蔽。与SOC互通：……Bug产出多在功能测试，覆盖的粒度和bug数量成正比。如何发现BUG1.3平台相关性考虑功能支持的平台类型：通常是全平台，在功能测试时组网考虑多种平台的覆盖。低端平台考虑：低端平台由于内存、CPU的限制，在一些场景下更容易出现问题。测试环境中最好能有一台低端平台。如何发现BUG1.4模块化平台相关测试在不同板卡不同槽位不同接口上功能下发或流量转发。例如，第一个槽位的第一和最后一个接口；最后一个槽位的第一和最后一个接口；正面板槽位和后面板槽位等。如何发现BUG1.5多CPU架构考虑有的平台CPU为奇数，有的平台CPU为偶数。大部分程序在偶数核时都能正常运行，但奇数核有时会因为代码没有考虑到而导致设备异常。如何发现BUG1.6License控制测试License是否生效。License限制值是否生效。License的时效。如何发现BUG二、特殊方法2.1压力测试长时间测试。反复操作，反复的配置操作，如配置增、删、改。配置的压力测试对一般模块基本都适用，属于必选测试项。大量并发操作，如大量用户同时上、下线。资源使用极限条件下功能模块的工作情况测试，这些极限条件可能是：高CPU、内存利用率等。批量操作，如一条命令导致的大量信息的添加、删除（noxxxall）等。压力测试常能发现较为严重的bug。如何发现BUG2.2规格测试规格数量下的配置的保存和加载。保存后查看配置是否丢失，加载时观察是否有配置无法加载。重启查看配置是否丢失。验证规格数量下功能的正常工作。如10000个VPN隧道（假设规格为10000个VPN）能否建立并转发流量，有些功能如果无法验证规格数量下功能工作情况，则至少应该选取其中部分实体进行验证，如配置1024个地址薄后，检查其中任意被引用的地址薄工作是否正常。通常这里都是有bug的，而且都是4-5级bug。如何发现BUG2.3性能测试性能对比：通常要求新建、吞吐、时延比上主线版本下降小于5%。性能评估：对版本在不同平台上的性能进行摸底测试，输出性能评估报告。如果性能下降较多，说明代码需要优化，必须报bug。如何发现BUG2.4内存检查找到触发内存申请、释放的地方进行测试，并进行压力测试，防止有内存泄漏的情况；了解功能的内存使用基本单位，（如：创建一条session将占用内存x字节）计算该功能最大消耗内存的数值，可能是其满负荷运行或达到规格数时处于最大内存占用点，在这个点进行测试；测试在d-plane内存剩余很小的情况下，模块申请内存失败后是否能够正确处理或返回。如dpmemory剩余很小的时候创建QoSIPqueue失败，是否能够正确返回；由于每种硬件平台的内存配备不同，因此需要针对不同平台考虑测试。如内存配置小的平台更容易达到内存使用极限。内存泄露也是常见的严重bug，常会导致进程、系统异常，最终导致功能不可用。如何发现BUG2.5通用性检查选用上一个主线版本或者不支持该特性的版本进行配置的降级验证。正常情况下不支持的特性的配置应该是加载失败，如果出现其他情况都是异常。如何发现BUG2.6Debug测试模块相关的debug是否存在；模块相关的debug是否可以开关；模块相关的debug输出的信息是否具有高可读性、语法正确；模块相关的debug是否能够导出到相关指定的位置：buffer、terminal、syslog等。如何发现BUG2.7易用性测试从易用性角度考虑功能实现上可以增强的地方，包括用户界面的友好性、操作的高效、适时的用户指导和帮助信息。这一类bug需要测试人员足够的敏感和站在客户角度考虑问题。通常这一类bug在功能上没有问题，只是不符合人们使用习惯、操作不便等。如何发现BUG2.8互通性测试与友商设备（如，cisco、华为）互联，功能验证；与同平台不同版本互联，功能验证。前面所有测试都只是保证在同一个版本上功能的可用性，但不能忽视和友商之间的互联，现网中充斥着各个厂商的设备，如果我们的实现或者友商的实现不符合规范将导致连通性的问题，只有在互通性测试时才能发现。经验不够丰富的测试人员通常会遗漏这个测试点。如何发现BUG三、高速法：查看QC系统中的BUG，学习别人的思路。发散思路常能发现bug。如何发现BUG祝大家好运！发现bug后该做些什么？不确定问题原因甚至不确定是否是bug及bug很严重，如，进程crash时应找开发人员定位；若能够明确认定是bug，需要找复现条件，确认是否是必现bug；若非必现，则需要多次复现bug，准确描述复现概率。明确bug阅读对象是谁？修改该bug的开发：模块开发人员、开发经理；验证该bug的测试：自己或回归该bug的测试人员、测试经理；所有对bug感兴趣的人员：前端、PM、文档等。如何准确清晰的描述BUG如何准确清晰的描述BUG一个例子：最后再来讨论Summary（摘要）该如何写？简单明了，便于理解长度一般不超过30个字尽可能讲明：什么情况，导致了什么问题如何准确清晰的描述BUGDescription（描述）该如何写？1)复现步骤（Actions）详细描述重现该问题的关键步骤；省略无关的操作，力求做到：所有重现步骤是充分的和必要的；容易理解的常规步骤，可以一句话带过，比如以管理员身份登录，进入后台用户管理页面；与环境有关的问题，给出特定的条件，比如：某某操作系统，某某浏览器。2)实际结果（ActualResult）描述实际出现的错误结果；可借助截屏来表达；不是总能重现的Bug，给出发生频率或规律；3)预期结果（ExpectedResult）当设计文档上没有对实现结果做详细要求时，用于测试人员表达自己的看法，一般是对比常规做法或其他模块的类似实现。如何准确清晰的描述BUG（Attachment）截屏/附件针对文字难以表达的或UI方面的问题；图片格式使用JPG格式；Windows画图工具的默认BMP图片太大，不建议使用；在图片上用醒目的颜色，标出问题所在区域；也可考虑配上简短的文字或截图的文件名中描述。如何准确清晰的描述BUG（other）其它注意事项：对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug。Bug严重程度(Seve