1. 哪个顺手用哪个，我的经验是开发用啥我用啥，资源不够的时候好抓壮丁
2. 根据需要自己组合就行，哪儿有什么好不好的。。。你这和 java 好还是 python 好这个问题差不多
3. 涉及到第三方多的，一定要便于录制，比如自动录制 mock 数据什么的

我在 LeetCode 刷到过，原题及题解帮你找到了。
https://leetcode-cn.com/problems/department-highest-salary/solution/bu-men-gong-zi-zui-gao-de-yuan-gong-by-leetcode/

毕竟人都是活在预期中的。超出预期一次，就是压榨的开始~

流程跟不上研发节奏，标准化不接团队地气，没有形成团队共识。

这是流程化、标准化的工具的通病，很多流程化、标准化的工具，慢慢的被变化的团队结构和研发流程所遗弃或者选择性使用了。

根据实际情况来吧，有些公司或者个别领导，就要那些用不上自己也不看的玩意儿，或者蹭点数据去做汇报。
美其名曰：数据支撑。实际毛用没有。

发个风险邮件完事儿。测试报告不用自己写的，也没人看，自动生成了。

用的最多的是流水线和 xmind，其他都和代码一起管理了。

ok 了 3Q

我那个可以改下用户名吗，自己改不了。

就是在改邮箱的时候提示的。。。

这个咋整，github 登录的，改不了邮箱

mark 下

看这个错 金额计算用了 double 么

伸手党来了，java 有类似的包吗~

把他们习惯的操作封装成更简单的操作，以及做下易用性兼容

只说我自己的做法哈，可能有一定项目特殊性。

由于我们接口（http 协议基于 XML 交互的接口）请求参数非常多，而且对所有空字符、null 等都很敏感，对所有参数要求和文档定义一致，但是产品给字段定义比较痛快，所以我会在接口还没开发但是给了定义文档的时候，根据这个接口最全的字段做一个请求模板，根据这个模板，程序会按规则依次按照每个 XML 结点空、null、字段范围定义等规则，去跑一些 定义之外 的测试（单因素法）。一般会和开发约定此类报错给一个或者一组错误码，用来验证结果，拼接测试报告。

由于基础规则几乎所有接口都差不太多，所以只需要预设一个请求模板就行。用例设计更多关注业务的参数组合。

1.我一般根据业务场景结合代码来，不影响业务场景的参数正向覆盖就行。另外请不要滥用正交法。。。
2.非法和空等格式校验，定义清楚的情况下，可以自己写个普适性高的工具自己跑，不用单独写用例。

PS：多看代码可以防止纯黑盒的某些场景漏测

截图，图像识别吧。
不过之前论坛有个相关文章，我没咋看懂https://testerhome.com/articles/29521

看起很不错

codeless 会让一些不会代码的人被卷。
code or codeless 说白了只是一个工具而已，死不死是针对的人。
开发任务很重的时候，还让人写一些自动化测试代码，反正我不愿意。

这不就是一个多端、多页面常犯的一个 bug 吗。一般交易支付类都会测试这种场景的啊

建议用来辅助分析，不要看见多因素多水平的就用正交。

得根据实际情况来，有时候正交反而漏测了，有时候单因素实验就够用了。

根据团队短板来。
另外别瞎整些用例数和缺陷数指标，不知道哪个脑残想出来的，测个东西必须达到多少用例，发现多少 BUG，这是人干的事儿？