期1.1

没有这个报告项目是不能上线的如果上线出了问题一定是上线的那个人背锅

描述bug

bug的描述是很重要的如果你只是指出开发人员的代码的一个bug让他现在就改他不得骂死你所以你应该描述清清楚楚这个bug

具体描述bug

开发人员需要知道出现问题的版本才能够获取对应版本的代码来重现故障并且版本的表示也有利于统计和分析每个版本的质量

在哪个环境下发现问题

127.0.0.1访问但是别人访问不了我们要部署到服务器上这样别人就访问到了这就是两个不同的环境

重现故障

要求测试人员描述好bug的出现流程否则开发可能会找不到bug说你乱提bug描述问题重现的最短、最清楚的步骤

在短信列表中选择短信进行删除删除失败了在短信列表中选择一条短信进行查看在查看页面进行删除删除失败

要让开发人员指导怎么样才是正确的尤其要以用户的角度来描述程序的行为是怎样的。

如果是依据需求提出的故障能写明需求的来源是最好的要相信测试人员是最懂需求的。

描述错误的现象。

crash等可以上传logUI问题可以有截图。

某些公司会有一些其他的要求例如故障的分类功能故障界面故障兼容性故障等bug复现的前置条件、bug给谁…有些有优先级的分类严重影响测试需要开发人员优先修改的可以设置优先级为高

不要把多个bug放到一起

此时还有三个bug但是来不及了三个bug不能都修复好所以我们需要给bug进行级别划分影响更严重的我们要优先处理~

3.2

阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失等问题如代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等该问题在测试中较少出现一旦出现应立即中止当前版本测试。

Critical严重

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失一级功能菜单不能使用但是不影响其他功能的测试功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用冲突安全问题、稳定性等如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序接口错误数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试。

Major一般/主要

功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性如操作时间长、查询时间长、格式错误、边界条件错误删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多

Minor次要

界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等如错别字、界面格式不规范页面显示重叠、不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置不正确用户体验感受不好可以优化性能的方案等此类问题在测试初期较多优先程度较低在测试后期出现较少应及时处理

如果发现崩溃级别的bug那么此时我们就需要停止测试测试打回测试打回特别恶劣

写一个报告打回给开发开发就需要进行修复修复完之后自己得仔细地测试一下不然想着再次被打回吗

bug状态转换图:

缺陷状态变更流程每个项目团队的实际做法可能不大一样并且需要结合实际的开发流程和协作流程来使用

产生争执这么怎么办处理人际关系

ASSURANC发现一个bug提交给老油条开发人员RD但是开发脸皮很厚一直没处理

前提一定不能吵架

先从自身出发测试人员要保证自己操作没有问题确保自己对需求理解的没有问题沟通层面好好说话高情商礼貌去交流站在用户角度考虑问题

应该让开发人员了解到Bug对用户可能造成的困扰这样才能促使开发人员

更加积极地、高质量地修Bug。

在争执时可以问一句如果你是用户你可以接受么例如删除某一篇文章但是却把所有的文章都删了用户直接炸毛了呀

拉上相关人那个开发和他的领导、我的领导、产品经理PM…开一个第三方会议

开会之前但是我(测试)一定要明确问题产生原因问题是什么解决方案是什么开会之后问题要不要解决如果要解决何时解决谁去解决知道这些才能散会有时确实不得不开否则自己的领导就要追责你了~

如何开始第一次测试

技术文档项目功能问题可以去问产品模块底层如何实现问开发尽可能多地参加各种项目会议阅读已有地测试方案和测试案例熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式阅读旧有的bug库了解系统功能尤其是团队保持一致的bug优先级规定了解公司的规范要求特别是用例编写用例执行规范…

确定测试计划执行测试