① 需求阶段
分析和学习阶段,团队去查看这个需求是不是可测的。
② 计划阶段
辨别出哪些活动和资源和测试的目标时匹配的,辨别并追踪这些测试的指标、计划。
③ 分析阶段
通过需求文档等条件辨别测试条件,追溯到需求。
④ 设计阶段
⑤ 编码阶段
创建详细的「测试用例」,进行编码。
⑥ 运行和维护阶段
⑦ 总结阶段
检验完成度和用户满意度。
① 需求评审
阅读需求,理解需求,查看是否有不符合逻辑的需求,明确测试周期。
② 测试计划
根据项目计划和开发人员的时候指定测试计划,包含测试内容、测试规划、测试环境、项目的任务和目的。
③ 设计测试用例
核心模块,设计测试用例常用方式有:等价类、边界值、场景法、判定表等。
④ 用例评审
确认结果的准确性,避免遗漏。
⑤ 执行测试用例
搭建好环境后进行冒烟测试,「功能测试」,兼容性测试,「接口测试」,「性能测试」,「系统测试」等。
⑥ 测试报告
概述项目内容,报告测试用例的执行情况,统计测试结果,测试评估,判断是否符合用户标准。
和2差不多,主要是结合项目把2具体化 例如:
例如:你觉得这个是bug,而开发觉得不是
首先明确一点就是开发和测试对bug的定义不一样,出发的角度不一样,开发可能对bug的敏感度低一点,当出现分歧的时候,应该主动从自己的角度告诉他自己认为这是bug的原因以及可以支撑自己结论的截图等,并让他也说出她的观点和看法,根据产品的需求和最初的测试计划出发,判断这个是不是bug,也可以请来项目经理和产品经理从他们旁观者的角度做出他们的判断
1xx:与信息有关,表示服务器接受信息,可以继续操作;
2xx:成功,服务器成功接受请求并处理;
3xx:重定向;
4xx:客户端错误:输入的url有语法有错;
5xx:服务器端错误。
① 「Java」编译器
eclipse、IDEA
② 「Python」编译器
pycharm
③ 抓包工具
fiddler
④ 「数据库」
SqlServer、「MySQL」、MongoDB
⑤ 接口测试工具
postman、jmeter
⑥ 「压力测试」工具
jmeter
⑦ 单元测试框架
Junit、testng、pytest
⑧ 「自动化测试」框架
appium、uiautomate、「selenium」
⑨ bug管理工具
禅道、bugfree
设置一个全局变量
登录产生的token,通过全局变量传递token的参数
依赖第三方数据的接口可以借助mock虚拟对象或者先返回上一个接口的返回值,在将这个返回这设置为环境变量或者全局变量,再设置下一个参数的类型。
登录后产生的token,将其存放在json等配置文件里,等其他接口想用的时候,直接引入这个配置文件的变量的参数就行,如果是cookie还可以引入session关联
设计一个水杯?
权限测试、安装测试、卸载测试、UI测试、兼容性测试、功能测试、性能测试、回归测试、升级更新测试、用户体验测试
电脑端打开fiddler后,打开浏览器后,fiddler会自动开启本地代理,进行抓包,获取请求和参数
「手机」端需要在网络处进行设置,设置成登录fiddler的电脑的IP地址和8888端口,把fiddler作为代理服务器,连接手机和fiddler后进行抓包
系统在一定压力下,查看CPU、内存、硬盘、网络、并发用户量、响应时间、每秒事物处理量等各项指标,模拟在生产运行下的压力量和使用场合,系统是否满足了生产要求(在一定条件下系统的各项指标)
站在用户角度,在一定条件下,通过不断的改变负载条件,判断软件系统的性能表现,期望是各种指标达到满足,查看是否存在瓶颈
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
- END -