dnf怎么做钓鱼网站,徐州做汽车销售的公司网站,为什么找别人做网站,如何自己做网站并开发软件【测试开发】基础篇 文章目录 【测试开发】基础篇1. 软件测试生命周期1.1 软件生命周期1.2 软件测试生命周期 2. 描述bug3. 如何定义bug的级别3.1 为什么要对bug进行级别划分3.2 bug的一些常见级别 4. bug的生命周期5. 产生争执这么怎么办#xff08;处理人际关系#xff09;… 【测试开发】基础篇 文章目录 【测试开发】基础篇1. 软件测试生命周期1.1 软件生命周期1.2 软件测试生命周期 2. 描述bug3. 如何定义bug的级别3.1 为什么要对bug进行级别划分3.2 bug的一些常见级别 4. bug的生命周期5. 产生争执这么怎么办处理人际关系6. 如何开始第一次测试7. 测试的执行和bug管理8. 如何发现更多bug 【测试开发】基础篇
1. 软件测试生命周期
1.1 软件生命周期
需求分析计划设计编码测试运行维护停服
博文链接【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_s:103的博客-CSDN博客
1.2 软件测试生命周期 需求分析 需求是否完整需求是否正确 测试计划 确定软件由谁测试什么时候测试什么时候结束测试测试哪些模块 测试设计、测试开发 写测试用例手工测试用例自动化测试用例编写测试工具 测试执行 执行测试用例 测试评估 测试人员产生一个测试报告 测试报告 没有这个报告项目是不能上线的如果上线出了问题一定是上线的那个人背锅 2. 描述bug 博文链接【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_s:103的博客-CSDN博客 bug的描述是很重要的如果你只是指出开发人员的代码的一个bug让他现在就改他不得骂死你所以你应该描述清清楚楚这个bug
具体描述bug
在哪个版本下发现问题 开发人员需要知道出现问题的版本才能够获取对应版本的代码来重现故障并且版本的表示也有利于统计和分析每个版本的质量 在哪个环境下发现问题
博客系统 127.0.0.1访问但是别人访问不了我们要部署到服务器上这样别人就访问到了这就是两个不同的环境 重现故障 要求测试人员描述好bug的出现流程否则开发可能会找不到bug说你乱提bug描述问题重现的最短、最清楚的步骤 例如以下bug描述 在短信列表中选择短信进行删除删除失败了在短信列表中选择一条短信进行查看在查看页面进行删除删除失败 √ 显然后者的描述更加精准因为列表页和详情页删除是不一样的地点 我们要准确描述bug如何出现的 预期行为的描述 要让开发人员指导怎么样才是正确的尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障能写明需求的来源是最好的要相信测试人员是最懂需求的。 错误行为的描述 描述错误的现象。crash等可以上传logUI问题可以有截图。 其他 某些公司会有一些其他的要求例如故障的分类功能故障界面故障兼容性故障等bug复现的前置条件、bug给谁…有些有优先级的分类严重影响测试需要开发人员优先修改的可以设置优先级为高 不要把多个bug放到一起 在无法确认是同一段代码造成的故障时不要将bug放在一起提交
3. 如何定义bug的级别 不同公司可能不一致~ 3.1 为什么要对bug进行级别划分
现在有一个项目要在9点上线
此时还有三个bug但是来不及了三个bug不能都修复好所以我们需要给bug进行级别划分影响更严重的我们要优先处理~
3.2 bug的一些常见级别 Blocker崩溃 阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失等问题如代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等该问题在测试中较少出现一旦出现应立即中止当前版本测试。 Critical严重 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失一级功能菜单不能使用但是不影响其他功能的测试功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用冲突安全问题、稳定性等如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序接口错误数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试。 Major一般/主要 功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性如操作时间长、查询时间长、格式错误、边界条件错误删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多 Minor次要 界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等如错别字、界面格式不规范页面显示重叠、不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置不正确用户体验感受不好可以优化性能的方案等此类问题在测试初期较多优先程度较低在测试后期出现较少应及时处理
强调
如果发现崩溃级别的bug那么此时我们就需要停止测试测试打回测试打回特别恶劣 写一个报告打回给开发开发就需要进行修复修复完之后自己得仔细地测试一下不然想着再次被打回吗
4. bug的生命周期
bug状态转换图: 缺陷状态变更流程每个项目团队的实际做法可能不大一样并且需要结合实际的开发流程和协作流程来使用
5. 产生争执这么怎么办处理人际关系 背景某一天萌新测试人员QA-- 测试(QUALITY ASSURANC发现一个bug提交给老油条开发人员RD但是开发脸皮很厚一直没处理 前提一定不能吵架
先从自身出发测试人员要保证自己操作没有问题确保自己对需求理解的没有问题沟通层面好好说话高情商礼貌去交流站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰这样才能促使开发人员 更加积极地、高质量地修Bug。在争执时可以问一句如果你是用户你可以接受么例如删除某一篇文章但是却把所有的文章都删了用户直接炸毛了呀 不光要发现问题提出解决问题的方案
如果你都做到这份上了开发人员还是不好好处理就可以这样
拉上相关人那个开发和他的领导、我的领导、产品经理PM…开一个第三方会议 开会之前但是我(测试)一定要明确问题产生原因问题是什么解决方案是什么开会之后问题要不要解决如果要解决何时解决谁去解决知道这些才能散会有时确实不得不开否则自己的领导就要追责你了~
6. 如何开始第一次测试
能自己解决就尽量自己解决
充分理解需求 文档产品文档 技术文档项目功能问题可以去问产品模块底层如何实现问开发尽可能多地参加各种项目会议阅读已有地测试方案和测试案例熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式阅读旧有的bug库了解系统功能尤其是团队保持一致的bug优先级规定了解公司的规范要求特别是用例编写用例执行规范… 确定测试计划执行测试 bug开发修复了之后一定要验收 项目上线 维护
7. 测试的执行和bug管理 8. 如何发现更多bug 软件测试同样存在二八原则80%的故障集中于20%的模块 如果某部分问题较多加强测试广度和深度 开发人员也存在二八原则80%的故障集中于20%的开发人员 如果某些开发人员的bug较多加强他开发模块的测试广度和深度 多进行逆向思维和发散性的思维 依赖测试人员的经验多去写测试用例多看优秀的人写的测试用例 不要局限于用例和需求文档尽早介入项目, 不要等到开发的差不多了再介入项目 尽早介入需求就会尽早理解需求 和深度 多进行逆向思维和发散性的思维 依赖测试人员的经验多去写测试用例多看优秀的人写的测试用例 不要局限于用例和需求文档尽早介入项目, 不要等到开发的差不多了再介入项目 尽早介入需求就会尽早理解需求 文章到此结束谢谢观看 可以叫我 小马我可能写的不好或者有错误但是一起加油鸭 重点软件测试生命周期 · bug的描述 · bug的级别 · bug的生命周期 · 处理争执
