前言：
我对测试的最新理解：通过一系列包含但不限于测试的手段，提高软件质量(初级)，提升用户体验(中级)，解决需求方的痛点(高级)。
Index：
1、需求分析9大角度
2、用例设计9大方法
3、接口自动化脚本规范-yapi版(口诀)
4、pytest框架-PO模型规范(口诀)
5、环境搭建常见问题
6、测试套路
7、项目总结
8、仅根据个人经验，印象深刻的bug
1、需求分析9大角度
①需求角度（SRS+ISO25010软件质量模型）;
②测试角度（写用例的9大用例设计方法-等价类边界值[内外边界次边界]/判定表因果图/正交表[正交试验法]/状态迁移法/流程分析法/输入域法/输出域法/异常分析法/错误猜测法;
③增删查改角度（技术分析）-比如：组合查询bug多，null空 空格 大小写等;
④用户业务角度(时间空间等)；
⑤多用户交互角度-比如：后台增删改查，前台显示与操作，职位变动，权限变动等;
⑥经验角度(职业经验积累-错误猜测等);
⑦互联网资源角度(大数据查漏);
⑧异常角度(非人类非主流场景);
⑨与人交流后的天马行空(不要闭门造车，要思想碰撞)。
> ISO 25010软件质量模型，几十个子类不一定记得完，但大类要清楚，方便查阅资料与全程关注：
功能，性能，安全，兼容，可维护性，可扩展性(可移植性)，可靠性，易用性。
（结合工作经验，这8大特性在软件设计阶段就要都考虑到然后做综合取舍）
PS:面试时，水杯测试、纸杯测试、铅笔测试、电梯测试(状态转换法)等都可以套用，实际工作中也可以用来查漏补缺，防止漏测
2、用例设计9大方法
①等价类(有效等价类/无效等价类)+边界值(内边界/外边界/次边界);
②判定表+因果图;
③正交表(正交试验法，如同幂等测试，都是纯数学手段，覆盖全部的两两交叉组合);
④状态迁移法（电梯，播放器等）;
⑤流程分析法（即业务场景法，如银行业务场景等）;
⑥输入域法;
⑦输出域法;
⑧异常分析法：专门制造异常，看软件在这时的表现如何，断电断网，落网打断，硬件破坏，数据破坏，内存破坏等；
⑨错误猜测法（吃经验，吃现有的bug集-项目组积累的历史bug）
> 等价类边界值、错误猜测法、流程分析法（即业务场景法)，这三大方法最强大最常用，直接覆盖95%以上的用例设计情况。
3、接口自动化脚本规范-yapi版(口诀)
ID打头Key收尾，接口标记且断言；
随机数据发请求，限量数据来回收；(limit)
明细排序必断言，数据还原空对空。(数据量，不允许空对空)
4、pytest框架-PO模型规范(口诀)
主要考量可扩展性、可维护性，代码越简单越好：
> 框架模型：
封装层：common（selenium方法等），tools(数据库方法，接口方法等)
配置层：config(sonstants，logging.txt，pytest.ini等)
page层：page（页面操作方法）
data层：csv，txt，xlsx等
用例层：testcase（用例模块）
执行层：run（py文件，bat文件，个性化批量文件等）
报告层：report(html报告等)，screenshot(异常截图等)
> 规范口诀：
模块内容要格式，命名规范多注释；（类的专属格式-大驼峰，注释要求后来者容易上手）
只可高层调底层，不可同级陷循环；（同级必须相互对立，不可相互调用）
元素定位不重写，重复执行先还原；（前一次运行错误不影响当次重跑）
路径菜单相对应，元素在前方法后；（page层文件路径要和页面菜单对应）
导包必须到具体，脚本结束OS；
(必须具体导入，不能import *，方便维护排查问题；os.system(“taskkill /f /im chromedriver.exe”))
5、环境搭建常见问题
①未设置环境变量；
②未关闭防火墙或Linux安全机制(SeLinux)；
③缺少依赖主键；
④未重启或flush；
⑤中文路径、正文，编码字符集问题；
⑥地址错误；
⑦版本不匹配；
6、测试套路
接口套路：鉴权，合法，非法，空，空格，大小写，单值查询，组合查询，空值查询，全量查询→接口名称，接口作用，前端入口，接口类型，数据准备，发送报文，请求结果，检查数据库，数据还原。
前端套路：1、权限配置检查→初始化，菜单等；2、页面检查（静态检查）→布局，按钮，输入框，选择框，下拉框，查询条件，分页，页码，结果列表，数据检查→列名，连接，颜色，按钮，标题，排序，超链接；3、操作检查（动态检查）→流程，按钮详情，超链接详情，单值查询组合查询空值查询全量查询的数据量和明细，比对数据库。 测试套路
用户多用户异常测试增删改查-循环重复交叉空空格越权排序-等价类边界值错误猜测历史数据等
页面检查：浏览器内缩放，浏览器整体缩放，刷新9次
错误猜测：带着之前的数据访问下个服务功能，带着前一个用户的cookie修改url查询其他用户数据，比如带着大页码、容量访问小页码、容量；
错误猜测法：
①用户多用户异常测试增删改差循环重复交叉空空格：
②多人多岗位交叉，多页签交叉，web端移动端交叉，前后端交叉
7、项目总结
①报表数据校验时，数据量、明细、排序、校验和、随机校验、算法校验、清单校验不可省；
②关键数据 一定要考虑取值范围，异常数据、脏数据的处理机制2
③需求实现时一定要考虑可扩展性 、可维护性（ISO25010软件质量模型是真的有用啊，可以指导工作）
④回归测试千万要多想想，当成第一次测试处理（回归/后续修改产生的bug和生产问题还少吗？请严阵以待，别让维护失利成为bug的温床）
⑤UI自动化测试只能用来防守，很难拿来进攻，实际经验来说，接口自动化价值更大；
8、仅根据个人经验，印象深刻的bug
前端举例：空 空格 大小写 整体缩放与内部缩放后，界面回不去 特定缩放界面一直抖动
后端举例：数据问题(异常数据，脏数据) 搞半天结果是数据问题 气死了 比如映射关系有重复 没去重 没排null 数据范围不匹配(A口径分子大于100无意义，但保存A时范围是小于200)
计算口径：跨年 跨月 重算报表、重算指标 等等问题
XML/DAO层数据转换问题：计算SQL都是对的，java自动任务计算时断点抓SQL也是对的，最后就是算不准(跨项目人员每月1号既请假又休假的那一周的标准工作量) 就这破问题，开发同学研究一天终于在大家的努力下定位到了问题点 哈哈哈哈
安全方面：fiddler抓包修改后服务器通过了， 权限校验时改了url就可以看其他用户的个人中心(后续倒是校验了用户id)
流程类bug：居然可重复执行， 被退货的商品居然可以被再次退货，被驳回的工单再次提交时无法添加附件（本意是避免不同办理阶段的附件独立）
前端性能：图表库的图标展示是通过性能自适应的 ，浏览器缩放导致图标计算占用CPU超过90%，最终崩溃（也就我这种喜欢用小屏幕电脑频繁缩放的人容易发现这个bug，哈哈哈）
