没用过这个啊

时隔这么长时间我也有点忘了哈， 在 inline 里你可以写 sql 去做删除和更改，你想恢复什么样的数据自己写 sql 就好了。 不过我现在的做法是用 assertJ-DB。 监控数据的变化，然后自动的把数据恢复到之前的状态。 你可以看看我之前还写过一个文章。 说 AssertJ-DB 的

那个是 selenied 的方法。

数据质量差是常态。 我门都习惯了。 我门的建模工程师更习惯了。 有困难就客服困难么。 既然他们都能用这破数据建出模来。我门业就能测试

这个还真没有~~ 这些都是我自己意淫出来的~

你可以看看 selenide， 一个基于 selenium 的开源项目

？ 你是不是留错言了。。。

额，一年半前的帖子有人来挖坟了哈哈哈。 我们一直用着呢。 还不错的感觉。

基本上没什么公司还区分这些了。 都哪年的老黄历了

python 圈的福音啊

现在的薪水都这么恐怖了

好快~

终于看到跟一样的职位在招聘了

我就是举个例子

最主要的还是看 bug 的严重程度和触发条件。 如果容易触发，严重程度也很高。 这样的 bug 漏测一个都是不行的。 相反的如果 bug 的严重程度很低，例如就是个简单样式问题，而且触发条件极其苛刻。这样的 bug 来 10 几个 20 个都可以忍受

当然是测试管，运维主要是辅助，提供一些基础服务，做一些支持。 很多地方是运维管理测试环境，那是因为测试水平太次，想管也管不了。

恩恩，以后有机会欢迎来探讨

还好哈哈，大家多跟我说说话就热闹多了

坚持坚持~~ 再坚持~~

谢谢~~ 总算有点人气儿了~~哈哈

是有点孤独~ 不过好在工作上用的到， 坚持的下去。 也算给自己的工作留下点足迹吧。

差不多是这种感觉

写 shell 就好了。 或者写 python 都行。 参数化构建后你在 Jenkins 里可以用 $ 符号引用了。 下面设置构建任务的时候，弄一个构建前的 shell 脚本。 把参数写进去就行了

楼主在数据采集这边做的不错，也是费了不少心思了。这应该是一个多分类的模型场景吧。 我看楼主也是有意识的统计 TP,TN,FP,FN。 只是分类模型不能只看准确率 (accuracy) 的, 应该算出测试集的 AUC， 列出混淆矩阵。 算出精准率 (precision),召回 (recall) 和 F1 Score。 这样的评估报告才是比较权威一点的。建议楼主看看我写的一篇帖子：https://testerhome.com/topics/11153

都可以~