软件bug是指软件程序的漏洞和缺陷,测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等
生命周期中缺陷状态:新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
界面相关,排版错乱,文案错误等问题都属于前端bug
出现样式问题的都是css的bug
出现文本问题的都是html的bug
出现交互有问题的都是js的bug
功能相关,抓包分析,从接口 请求url 参数 接口响应来分析
未发送请求,属于前端bug
接口请求url错误,传参错误,属于前端bug
接口返回数据错误,属于后端bug
性能相关
页面加载慢或者提交表单慢,抓包查看请求耗时,如果耗时长,就属于后端bug
接口测试就和普通功能测试没什么区别,区别就是功能测试是在页面上输入值,提交数据看结果,而接口测试没有页面,通过接口规范文档上的调用地址,请求参数,拼接报文,然后发送请求,检查返回结果。
步骤
打开postman,填写接口信息
结合测试用例,组合变换参数信息后,查看返回的json数据与prd(产品需求文档)是否一致
功能测试
单接口测试
正常参数
全部必填参数
全部参数(必填+非必填)
全部参数(必填+ 部分非必填)
异常参数
数据异常:长度,类型是否为空,不满足业务等
参数异常:多参,少参,无参,错误参数(password写成pass)等
多接口测试(业务场景测试,用在冒烟测试里)
概述(包括项目背景,需求分析)
测试时间,测试环境
测试过程(评审记录,测试范围,测试用例)
功能实现清单(列出是否已经按照测试计划实现功能)
缺陷统计(测试缺陷统计,测试用例执行情况统计)
测试统计情况(资源统计,执行情况,问题统计,问题列表,遗留的问题)
测试总结(测试结论(是否通过),测试内容,测试用例的覆盖程度,bug的解决程序)
测试风险
黑盒(等价类划分,边界分析,因果图和错误猜测)
白盒(逻辑覆盖,循环测试路径选择,基本路径测试)
测试用例完全执行,测试用例覆盖到所有的测试点,并且缺陷的密度达到客户的需求
没有实现的功能
完成了用户需求的功能,但是运行时会出现一些功能或性能上的问题
实现了用户不需求的多余功能
阅读相关技术文档
参加需求评审会议
根据最终确定的需求文档编写测试计划
编写测试用例
用例评审
开发提交代码
执行测试用例,记录发现的问题
验证bug与回归测试
编写测试报告
产品上线
通过某些方式定位到我们要执行的对象,目标
对这个对象进行什么操作
通过操作对定位到的对象赋值
添加断言操作
冒烟测试就是在每日构建版本后,对系统的基本功能进行简单的测试,这种测试强调程序的主要功能进行的验证,而不会对具体功能进行更深入的测试
web项目是b/s架构,基于浏览器的,web测试只要更新了服务器端,客户端就会同步更新
app项目,c/s架构, 必须要有客户端,app修改了服务端,客户端用户所有核心版本都需要进行回归测试
web项目需要监测响应时间,cpu ,内存
app项目除了监测响应时间,cpu,内存外,还需要监测流量,电量
web基于浏览器,一般选择不同浏览器内核进行测试,app必须依赖于手机或者pad,分辨率,尺寸,设备系统
一条bug记录最基本应包含:编号,bug所属模块,bug描述,bug级别,发现日期,发现人,修改日期,修改人,修改方法,回归结果
要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,然后再向外发布如此才能提高提交 Bug 的质量。
添加请求
线程组配置-----设置线程组--------设置循环次数--------------设置压测持续时间
添加聚合报告
执行分析结果----主要看:请求数,响应时间(越小越好),tps(服务器每秒钟处理的请求数,数值越大越好)
测试效率不同
完成同等数目的测试,启动自动化速度更快,手工测试则需要消费更多的时间,但是自动化测试的脚本开发比用例开发耗时长,包括编写脚本、调试脚本、维护脚本,而手工测试虽然也要对测试用例进行撰写、评审、修订,由于用例编写更多为自然语言,时间上会少
执行可靠性不同
自动化测试中可靠的按脚本执行,后续定位,复现有明确的配置路径可寻,而手工测试往往会因为自己的判断导致测试出错,并且在测出来的问题上有一部分是不能复现的。但是自动化的稳定来源于其死板,而人的智慧体现在思维的跳跃,跳跃的思维也会导致后期不易定位。
覆盖率不同
在同等时间内,启动自动化测试能够覆盖更多的功能,而手工测试只能覆盖小部分功能。但是自动化测试适合回归测试,开发中的功能不划算。对于开发中功能,需求或者实现的更改,都会导致自动化脚本的变更,开发中的功能更适合手工测试。
了解被测系统,被测功能和各个功能的业务逻辑
分析需求文档,整理测试点
测试方法设计,将测试方法用到项目中
编写测试用例
拿到被测软件后,执行测试,提交bug,有效的进行回归测试
测试总结
limit 返回查询条件的前几条或者中间某几行的数据,可接收两个参数, 第一个参数表示从第几行数据开始查,第二个参数表示查几条数据。注:初始记录行的偏移量是 0
用法
SELECT * FROM table LIMIT 5,10; // 检索记录行 6-15
SELECT * FROM table LIMIT 95,-1; // 检索记录行 96-last.
SELECT * FROM table LIMIT 5; //检索前 5 个记录行 相当于limit 0,5
界面
形状,大小 是否符合要求
是否有灯光显示
是否有产品logo显示,开关是否显示标识
功能
带线鼠标的话,连接在机箱上是否能使用,连接在笔记本上是否能使用
蓝牙鼠标的话,不插入连接器是否能使用;电脑打开蓝牙,是否能连接成功;鼠标没电,是否还能继续使用
鼠标左键是否能点击,点击后页面是否有反应
鼠标左键是否能选中文本
鼠标右键,是否显示刷新,复制等功能
鼠标滚轴是否可以滑动页面
鼠标点住左键是否可以拖动文件
鼠标是否可以双击
性能
鼠标左右键最多能够使用多久
电池可以支持多久
鼠标摔了之后是否还能正常使用
开发人员说不是bug,有两种情况
需求没有明确,这个时候可以找到产品人员进行确认,需不需要改动
这种情况不可能发生,所以不需要修改。这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。
测试类型:功能测试,性能测试,界面测试,UI测试、接口测试、安全测试、兼容性测试、易用性测试、压力测试、负载测试