前端这边流程管理非常强，她们严格控制自己的输入，工作上给自己留足够的余地。重视协议文档化，不认可在线的协议文档。不同功能的接口以自己的理解进行混用。
优点：严格把控自己的输入，能够更好地控制输出
缺点：沟通成本高、项目推动进度受制约 经验教训：
1、重流程《=== 做自己分类的事儿，紧跟前端步伐；
2、协议文档化《=== 先简易实现功能，一次性生成文档，不可在导出文档里修改，否则会引入修改协议不全、与自己的自动生成文档相左，导致后续接口功能不可用。如若修改协议，在代码里修改，然后导出协议。
3、混用接口：明确功能，如混用坚决制止，按单一接口单一功能提供，否则引入未知bug
测试资源测试手段通知、验收方案不明确、转测用例未评审、转测用例描述不明确、测试仅后端实现的功能、问题单修改引入、提示语
1、测试手段、方案 《=== 项目开启前需要知晓(功能测试+性能+稳定性+渗透)，根据测试方案在写代码的时候进行规避，如若不知，渗透、性能会引出很多严重bug
2、转测用例未评审 《=== 牺牲进度保证转测用例是值得的，否则会有未同步的地方，转测要求澄清
3、转测用例描述不明确《=== 转测用例描述存在隐含意思，转测扯皮，评审
4、测试仅后端实现的功能 《=== 前端未实现的功能，验收应仅限于功能存在
5、修改引入《=== 及时跟进问题单，自查后及时处理
6、提示语《=== 提示语bug，业务提示语需要和测试、项目经理等同事商定，自发挥可能引入bug
项目需求变更多次、需求不明确、需求被裁剪
1、迭代二：需求变更三次，每轮测试期间都有很大调整
2、迭代三：前端裁剪需求、与ui实现差别大，第一轮测试期间需求大变更，几乎涉及平台所有业务
其他1、性能保证：尽量不要有大事务，否则导致性能差、数据库连接池打满、大量接口请求阻塞甚至失败、死锁、undo log膨胀 、回滚时间长《=== 大事务拆分，读放在事务之外；避免一次处理太多数据；非DB更新操作、非DB操作放在事务外
2、前端精度：雪花算法生成的id，精度丢失，转成string给前端(JS能表示的最大整数：9007199254740992)
3、文件压缩：同名文件处理时，系统不是删除，而是覆盖，可能出现文件夹里的文件没有被覆盖
4、稳定性测试：指定JVM内存信息、进行相关参数指定，如：java -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gc.log -XX:+HeapDumponOutOfMemoryError -XX:NativeMemoryTracking=detail -Xms2048m -Xmx2048m -jar ***.jar
5、性能摸底：服务器配置、io等信息 6、左移位超过31位隐含地对移位量执行模运算，错误：In expression "1 << 53", left shifting by more than 31 bits implicitly performs a modulus operation on the shift amount. The shift amount is 53.
7、集合使用，框架的或者jdk自带的，在使用时需要看下接口描述，保证使用集合时集合非空
8、模糊匹配使用instr而不是concat，否则%和_会出现全匹配
9、BigDecimal类使用，处理精度问题
10、拦截器里不可随意获取JSON数据，获取时就需要读取输入流。 ========> 读取了Request数据之后，请求的数据不见了
11、流的关闭，finally里面记住要再次释放
总结1、严格把控输入、方可更好地控制输出。
1.1、重流程，程流程匹配
1.2、需求变更，明确需求，细化到点上
1.3、测试用例，逐条评审
1.4、及早识别风险
2、不断充电、提升自己
2.1、考证驱动，拓展能力
2.2、博客驱动，记录心路历程，免再次入坑
2.3、多请教、多分享，不断成长
2.4、流程或者其他部门的知识要熟悉(如：什么情况视为修改引入)
质量保证1、时间足：全用例测试、交叉测试
2、时间紧：转测用例测试，交叉测试，不宜测熟悉的模快
3、问题单：测试需描述清晰，笼统描述不客气。开发验证，涉及问题修改，全场景测试
4、修改范围较大，全用例测试
疑问我仅做自己分内事儿，保证我的KPI可取么？
多做意味着多错么？
经验按流程办事儿时刻牢记，不可跨越红线！
