jdbc 里面默认 bigint 就会转 Long ，官方文档：
https://docs.oracle.com/cd/E19830-01/819-4721/beajw/index.html

PS：如果你用的是 spring ，强烈推荐用 https://github.com/davidfantasy/mybatis-plus-generator-ui 来自动生成所有数据库表的实体类 + 增删改查接口逻辑。省力且避免手写代码出错，比你这么手写要简便高效很多。

嗯嗯，这个认同。

这个和私单还不大一样。我以前遇到过好几次需求评审完，都确认下来后，产品周会开完，这个需求需要承载更多的业务目标，那需求又产生调整的（嗯嗯，拥抱变化）。所以光靠需求评审卡严，其实很难，总会有我们想象不到的地方产生变化。

既然本质问题是业务节奏快，产品没法把需求想得面面俱到再开干，那我们的解决方案，就是围绕着更深度了解需求，便于按照一致的出发点补足细节来。比如：
1、建立需求初审制度，技术也一起参与了解需求的出发点。需求文档初稿出来后各个技术、测试组长先审，快速明确需求价值、技术可行性。
2、正式需求评审通过后，每天早会产品必须一起参加并同步是否有调整，同步后现场评估技术成本。调整成本超过 1 天影响排期的，一律走需求变更流程，变更排期。
3、需求描述不明或者前后矛盾导致的 bug，测试也会记录并把类型设置为 需求问题 ，让产品澄清。测试报告里会体现这类型问题的数量及严重程度，并在复盘时一起沟通，看大家有什么好招减少或者避免这类问题产生。

不同的组织结构、不同的问题根因，会产生不同的解决方案。所以我前面说复盘只是找到了需求质量差，但没找准根本原因（一般根本原因都和人员能力或者组织结构有关），需求混乱直接就加强需求评审，卡得更严，真的不一定能解决问题，甚至可能激发矛盾。

考虑到答复里有同学回复了不错的内容，所以这个帖子暂时先不屏蔽。

也请 @ 捉虫子的小强 后续发帖前，先看看精华帖或者其它问答帖是怎么讨论的。分享观点就应该正文里写观点，提问就应该正文里写清楚上下文和想寻求帮助。现在这种正文一堆没有上下文的问题，自己的回复一味抛外部链接，帮助不了解决问题，反而阅读体验非常差。

社区不想随便屏蔽任何人花时间发出的帖子，但也希望大家讨论时保持好一种诚心学习交流的气氛。请大家一起维护好这个气氛。

如果发帖目的是想解决实际问题，建议分享下你的实践经验和思考吧，这样才能真的帮助的大家。

只是发各种不同文章的链接，也没有你自己的思考（比如你觉得里面哪部分说得有道理，哪部分觉得没啥道理），对于帮助解决实际问题，真的帮助不大。而且你已经连续好几天发同类型文章了，如果有诚意想分享经验，请看看别的分享文章怎么写的，调整下你的写法把。

是 bug，这个是业务规则漏洞。前后端应该要保持一致。

没出问题 != 没有问题，不知道你这里具体业务场景是啥，但既然不允许删除订单，那应该是业务规则是基于此时订单无法删除来设计的。那如果此时实际出现了订单删除，我理解你其它业务逻辑也可能会跟着一起出错，甚至连整个帐一起出错，到时候修起来就非常累了。

当然一步到位全部发现全部改好很难，可以按安全风险一批一批检查和修改，但这个风险要明确暴露出来，让项目团队明确知道，并进行评估决策。

前面帖子正文里的复盘，是不是可以进行更深入的根因分析？

需求问题应该已经是问了几个 why 后得到的了，但我理解还可以再继续深入下？需求质量不高，就直接加强需求评审，有点担心会治标不治本。

不知道你现在心情怎样，如果还比较平静，那可以像我前面说的，写一下年度总结，总结下最近一年做了什么，然后把你脑子里印象最深的得到快感最明显的 2-3 件事也列出来。两个比较一下，找到落差在哪里，然后想办法填平这个落差。

一般迷茫来自于没有成就感，没有成就感来自于事情太碎或者太重复，没有挑战，所以印象不深，感觉好像没干啥，也没啥进步。所以需要你自己额外花时间去总结下你到底做了啥，为何没有成就感，以前做的有成就感的事情是怎样的，是否适合后面再继续做。

如果你已经比较焦虑，一想这问题就脑壳疼，那先找点别的事情做，减缓下焦虑感吧。刚好接近国庆假期，可以去做些自己喜欢做的事情（比如我自己会喜欢通过打羽毛球、骑单车走走远路来解压），转换下心情，平静下来，再去做前面的分析。

...我自己都忘了当时这句话是怎么想出来的，大伙就不要关注这个点了。

没留意到用户名不一样，误会了。。。不好意思

hmm，不知道你是准备怎么度过这段迷茫期呢？

建议你先想好你到底对商城业务线到底是不是真的喜欢，里面是否真的有自己的发挥空间，再决定是否去认怂问机会吧。你前面这番迷之操作，估计会让你的领导心里留下一个疙瘩，得花一些经历去消除。如果你去了又发现实际不是自己喜欢的，最后也是得跳槽，而且还顺带让你领导留下你不负责任的印象。。。

今天说完，后天就得正式接手的那种

下次遇到这类突发且对你影响很大，你一时间也想不清楚的，你说你需要慎重考虑下，给你 1-2 天时间再答复就好了。然后这个时间里认真做思考，有必要就多问问你领导一些新业务的规划细节，有助于你做决定。这种事情会慌乱很正常，凡是都有第一次，吸取教训，下次改善就好了。

尝试一下跳槽，自己是自信但又不自信的人，面试又会怯场，学历硬伤，工作经验也才 3 年多，怕出去后找到的比原来的还差。。。

这个问题倒是你要花心思去解决的，以后一定会遇到跳槽要出去面试的，不能总是心里留着这个疙瘩，怕这个怕那个然后就不敢出去面，继续留。可以去练一练，不管有没有面过，这个经历都会给你不同于你目前公司的收获的，所以个人还是比较建议你出去面一下，哪怕 1 家都好，看看外面的世界。

可以试着写一下年度总结，总结下最近一年做了什么，然后把你脑子里印象最深的得到快感最明显的 2-3 件事也列出来。两个比较一下，应该就可以找到原因了。

没找到原因前，不要轻易行动，要不到时候骑虎难下更痛苦。

希望大家给点意见，QA 能干多久？

这个问题我表示没法回答。。。就像你问互联网还能活多久，没有人能准确预知这个未来。我只能说，QA 目前在持续变化，能取得不错成效的话还是可以活挺久的。就像运维借助 DevOps 从一个每天重复敲命令上线的体力劳动者变为一个做生产资源管理 + 自助上线赋能的技术工作者（现在这类岗位好像叫运维开发，其实也基本是一个产品 + 开发 + 测试 + 运维都要做的 one man one team 型岗位），测试也在寻求从每天重复点点点的体力劳动者变为做质量管理 + 质量保障赋能的技术工作者。只是质量这个事情业务特性更强，不像运维上线那么容易标准化和自动化。

如果不是 QA 那么转岗还来得及嘛？

我觉得关键不是是否来得及，而是你是否有足够的决心去承受转岗带来的落差。我建议你先想清楚你想要啥，然后再看通过什么方案可以达到你想要的？既然能坚持做这么多年 QA，至少应该是不讨厌 QA 工作的吧，方便的话可以分享下你现在具体遇到什么瓶颈，困在哪里？

1、方案上 tidevice 实现了不依赖 xcode 就可以启动 wda ，进而执行自动化脚本。但请注意只是 “启动” ，即你的手机里需要事先装好 wda 。而你这里在做的是 “编译” 中的依赖库安装，编译目前应该还是只有 mac 可以支持（编译暂时没见到可以绕过 xcode 的，而 xcode 只支持 mac ）

2、如果需要加上 appium ，需要调整 appium 的 desired_capabilities ，使其使用 tidevice 启动好的 wda 对应端口，而非默认的自行通过 xcodebuild 命令去启动 wda 。详细可以参考 https://testerhome.com/topics/30422#reply-195820。且由于 appium 本身内置了通过 ideviceinstaller 校验 bundleId 是否存在的逻辑，ideviceinstaller 不确定在 linux 上 appium 安装脚本是否会自行安装，建议你手动安装下。

发 http 请求的那个 sample 的配置截图发一下？试过搜索引擎里找到的哪些方法，使用后表现有什么变化，也可以发下？

问题直接一图流不是个好习惯，提供多点数据也有助于更全面了解问题。

业务方需要忽略掉只是变更了空格和格式的内容

这个细节挺不错，我们之前没留意到。确实需要加上。

是否可以先发下：

1、你这个互转，具体需求是什么？给个 yaml 和 excel 互转的示例？
2、你目前找到了哪些库？
3、这些库你试用后，具体哪部分灵活度不满足你需要，最好附上你当时写的 demo 代码？

灵活这个词太概括了，不知道你到底要怎么样程度的灵活，所以你先多给一些资料吧

要看系统对于 token 的具体实现吧，单纯这么问不好说差别有多大。

然后如果确实区别很大必须多个用户，那找开发协助，绕过实名认证直接造用户就好了？

大部分理解和我理解是一致的，有一小部分不大一样

就需要针对不同的业务上的场景设计不同的用例，来监测这些场景下的 TPS 值，最终通过分析这些值来确定整个系统的性能的指标以及需要的服务器的大致配置

根据不同场景设计不同用例这个是对的，但基于这些场景下的 TPS 值分析确定系统性能指标这个不大对。

性能指标应该是基于真实业务场景分析来制定的，而不应该是基于压测结果制定。比如同样 TPS 数据，线上的 TPS 数据，代表真实业务情况，所以可以作为场景分析的参考数据，而你自行压测得到的 TPS，只是你自己模拟得出的数据，可以用于验证性能是否达标，但不能用于作为场景分析的参考数据。实在没有线上数据可供参考，那和产品开发一起讨论，一起推敲出一个值也行。

感觉你目前在概念层面上有些理解不大对，需要有比较完善的文章或者示例，而不仅仅是我在这里只言片语的答复。建议可以看看楼上贴的 服务端性能测试 - 入门指南 ，或者去极客时间看看高楼老师的课程。目前是支持任选几讲免费试读的，你可以选关于基于业务场景制定性能指标的章节看下。

也许在你这个场景下，实际对性能要求并不那么高（PV 17W，对一个线上系统来说应该不算高负荷），但这些理念尽量入门时要了解好，避免后面走偏。性能测试的场景和目标指标制定是非常关键的，没做好，很可能会引起你性能测试结论是通过，但线上真正达到预计范围内的高峰期时系统却扛不住挂掉，那你这个性能测试基本就是白做了。我们之前就遇到过，花了快一个月专项做性能测试，结果上线后流量来了，就各种扛不住（我们当时是监管要求必须切新系统，所以不可能小流量慢慢上，一上来就是全量），后面研发就各种吐槽当时花那么多时间做的性能测试和调优，一点效果没有。

微信截图已删

bug 也记录了：https://github.com/testerhome/homeland/issues/136

。。。那就是 bug 。

你要删哪些楼层的，和我说一下，我帮你删吧。

进入回复内容编辑页，左下角有删除按钮：

公式： PV*80% / 3600*20% =TPS 的值 3600 代表 1 个小时 3600 秒】

看了下，你这个公式好奇怪，为啥直接用一天的 PV 去除以一个小时的 20% 时间？一天 80% 的接口访问量都在 12 分钟内灌进来？这个比例有点夸张了吧。

日 PV 是一天的量，性能测试里常说的二八原则一般是指 24 小时里，80% 的访问集中在 20% 的高峰期，按照这个去推算，峰值 TPS 应该是 日 PV*80% / (24 小时 *3600 秒 *20%) ，按你这里 17W PV ，算出来应该是 7.8 左右 ？

PS：TPS 是接口维度的数据，PV 是用户维度的数据，用户和接口是一对多的映射关系，而且随着活跃度差异、接口逻辑差异，这个一对多比例也会产生很大差异。所以你直接拿 PV 来算，算出来最多就是一个当天首次访问获取 token 这个接口的 TPS，并不能代表整个系统各个接口的 TPS 要求哦（比如平均一个用户会查看 10 个商品，那商品查看接口的累计访问量应该是 PV 的 10 倍。个人了解电商购物类网站，商品查看一般调用频率也是最高的，所以也是最需要做缓存、性能优化的地方）。

如楼上所说，不结合业务场景和逻辑，单靠一个 UV/PV ，实际是算不出系统各个接口的 TPS 目标值数据的，这样得到的数据大部分情况下会比实际值小，就算达到了也不代表能满足实际业务需要（比如按照前面的假设，商商品查看接口 TPS 目标不应该只有 7.8）。建议先理清楚核心业务流程背后接口调用时序，然后顺着业务逻辑来评估几个调用量比较大的接口的目标 TPS 吧。