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

mark 下

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

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

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

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

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

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

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

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

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

看起很不错

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

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

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

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

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

1.可以实现自动化吧

Sikuli X 吧

page object 重点不是 page 么，抽象出来就是组件 object 了

登录一次就行了吧。。。用的是不同的 driver 并发在跑吗？

你要镀金就去大厂

武器的测试和软件测试两码事吧，比如测试核武器，冒烟也是炸，性能也是炸。

游戏公司看能活几年~

二次开发很多是定制的，另外一些公众号会分享二次开发的。

打杂的，啥都干。

我倒是觉得，其实是为了问下到底有没有好好准备以及自身计算机基础，哈哈。

xmind 还好吧，不是很卡。
工具始终是工具，有些人喜欢，有些人不喜欢。其实哪个工具都可以通用，只是不喜欢罢了。

只用 java，和开发代码同源。项目没用 go，所以也没机会用。