如何提交高质量的bug资料.pptx

如何提交高质量的bug 我的测试小经验@2016 目录 2、如何提价高质量的bug 3、小结 1、浅谈测试 目的 测试是发现错误而执行程序的过程。 测试的目的是为了尽早发现尽可能多的缺陷。 一个成功的测试就是发现了至今为止尚未发现的Bug的测试。 原则 所有的测试都应追溯到用户需求。 应尽早地和不断地进行软件测试。 测试只能证明软件存在错误而不能证明软件没有错误。 完全测试是不可能的，测试需要适时终止。 保障质量、成本、利润。 我对软件测试的理解 以一个IT工作者的身份，站在用户使用的角度，检测软件的准确性、完整性、规范性、易用性。 纠错 评价 变化 态度 能力 热望 探索 我心中的测试 目录 2、如何提交高质量的bug 3、小结 1、浅谈测试 如何找到更好更多的bug？ 一个产品从设计到开发，凝聚了所有系统架构师、产品经理、设计人员、开发人员、管理人员的心血。从另一个方面来讲，这些不同的环节和不同人的工作，确是导致bug的原因。举例来说，可能出现bug的情况有： Bug从哪里来？ 需求变化 设计错误 开发工具 测试环境 缺乏交流 时间压力 文档缺乏 … … 测试前的准备工作 考虑到上述bug产生的各种因素，为了高效高质地完成一个项目的测试，在测试前我们应该做好以下的准备工作： 熟悉客户需求 熟悉产品设计 熟悉开发工具（最好部署） 熟悉测试环境（了解差异） 熟悉数据库结构（了解数据流转） 设计合理的测试用例 Bug分析 序号 Bug类型 占比 优先级 严重程度 发现难度 分析 1 报错类 流程类 高 高 严重 易 这类最影响系统自身功能的问题一般很容易发现，也很容易被置为无效bug，为了减少彼此的无效工作量需注意：1)确认bug可以复现；2)排除配置问题；3)排除网络、系统更新问题 2 业务逻辑类 数据准确性 高 中 严重 难 这类是最难发现但最能保障软件质量的bug，要发现这类bug除了细心之外还要加强测试人员本身的素质，最重要的两点是：1)IT专业技术能力；2)对业务的理解力 3 易用性 优化建议类 较高 低 不严重 一般 这类问题虽然不影响系统正常使用，但是产品交付后会影响客户体验，也是客户最容易提出改进建议的地方，为了提高客户满意度，需要测试人员站在用户体验的角度，切身感受系统的操作细节，提出可实现的优化建议，让系统界面更友好 我的测试思路 首先，找到影响系统正常运转的报错类、流程类问题，让系统可以正常运转； 其次，根据业务背景寻找不符合业务逻辑的功能和错误数据，保证系统的数据准确性； 最后，站在全局角度通测软件功能，考虑前三步测试点的同时，结合自身的经验和想法尽可能多地发现软件本身的漏洞。 再次，站在用户角度检测交互界面是否友好、易用，让系统干更规范和智能； 提高测试质量的小建议：（1）首先测试程序的核心功能，然后测试辅助功能；（2）首先测试功能，然后测试性能；（3）首先测试正常情况，然后测试异常情况；（4）首先测试经过变更的部分，然后测试没有变更的部分；（5）首先测试影响大的问题，然后测试影响小的问题。 如何提交高质量的bug？ 研发（追查半小时后） 是服务器环境配置的问题（外部原因） 客户的需求就是这样的（设计如此） 我测试几遍都好着呢啊（无法复现） 测试发现问题后，匆忙提交Bug到禅道，然后找到研发说：不好了，你的程序出问题了！ 你是否遇到这样的场景 如何提交bug？ 研发喜欢什么样的bug？ 研发： 赞，最喜欢改你的bug，一目了然，还有产生原因和解决方案，我省了老大劲儿了！ 测试发现问题后，经过一系列分析判断找到研发： 1、程序某部分出问题了，初步判定是某分支的某逻辑和另一分支的某逻辑冲突了，应该把某的判断条件一改就好了。 --定位精准 2、程序某部分出问题了，过去某产品就成出现过这个问题，是某函数用错了，导致前端某数据输入的情况下，出现异常。 --经验丰富 3、程序某部分出问题了，问题截屏、日志、系统资源情况、复现步骤都记录在禅道里了，有看不懂的地方可以问我。 --有理有据 √ 我们的bug复现 经常听研发说道： 这个bug我都看了两遍了，怎么就是看不懂呢？ 那么如何提交让研发能看懂的Bug？ 好的缺陷描述应该包括： 1、标题： 用一两句话简洁但全面地描述此bug的核心问题。 Bug提交标准化 2、项目、所属模块：归属明确 5、复现步骤： 逻辑清晰、条理清楚地描述问题的复现步骤，帮助研发还原问题场景。 7、问题分析（可选）： 对问题产生原因的分析，需要对业务理解透彻，对技术有一定的了解。 3、优先级： 1级-马上解决；2级-高度重视；3级-正常处理；4级-可延期处理。 6、截图/附件： 截图让问题一目了然，附件可以对问题进行补充说明。 8、改进建议（可选）： 对问题的修复建议，需要相关测试、业