• 仅楼主可见
  • 机器学习结果的准确率,应该都是先有一个人工确认过的正确集,然后和模型跑出来结果做比对吧。没有一个 100% 正确的集合,也无法知道模型跑出来对不对、准确率如何。

    这个正确集本身是训练数据的一环,这类数据有一些公共的数据集对应不同领域的(包含原始数据、人工确认过的 100% 正确集),可以去找下,拿一些合适的来直接使用。不过领域如果比较特殊,估计也不一定有这类公开的数据可用,毕竟这些收集这些数据成本是不低的。

  • 接口测试的一些感悟 at 2019年10月09日

    哪里晕?

  • 把你的详细步骤发下?包括怎么启动 repeater 的。

    从你的步骤没看出问题,有可能问题在其它步骤里。

  • 非常清晰的思路和过程,点赞!

  • 你这几个截图有点奇怪,第二个图就已经没有工作经验,只有工作性质了。而你选中的也是工作性质里的 “应届”

  • 功能测试有框架吗? at 2019年10月08日

    脉脉原帖地址或者内容贴下?

  • 那这是另一个范畴了,和你的题目差异比较大。。。

    可以看看小红书 MTSC 2018 的一个 topic ,介绍他们怎么测试客户端埋点的,做得比较全和自动化。

  • 一般定时任务,我会选择交给 jenkins ,配置起来很方便,而且执行日志啥的也很齐全,便于大家使用时随时通过日志了解任务执行情况。
    jenkins 有提供 api 给程序创建和修改 job 。

  • 这个是另一个话题了。所以这里也只是推荐,并非强制要求。

    对于贡献要求里带有 rebase 这一项的项目,大部分也同样会要求单个 PR 提交的东西不应该太复杂以至于影响 review 。若有这种情况,说明一次 PR 内容过多,需要拆开每个独立功能单独 PR 。

  • 这个自己二次开发 console 。
    而且说实话,重复的请求如果不是非常多,不会额外造成太多的执行耗时,其实重复又何妨?

  • 加精理由: 非常鼓励这种 发现 - 解决 - 分享 的方式,内容也很完整可参考

  • 哈哈,共勉,加油!

  • 好的,已记录。
    最近加班比较多,周末修复下。

  • 很难得的完整云测平台开源项目,TTF 也非常希望能帮助推广这样的优秀开源项目。我把这个帖子置顶 2 周,让更多同学可以看到和参与到这个项目中吧。

    另外,也建议到社区 开源项目 板块,记录下这个平台,我们把它放到推荐位,便于大家可以更及时看到。

  • 先确认一个点:你这个库,使用的项目是要必须把源代码放到自己的项目目录的吗?

    你截图里这种情况,目前能想到的一种可能,是 app_auto_run-0.0.3 里面直到 adr 这个类文件之间的路径,有部分文件夹里缺少了 __init__.py ,导致这个文件夹没有被 python 认为是一个有效的 module 。

    如果代码不敏感,可以把你截图里整个项目(包括 tmp.py、自建库)都上传 github 之类的地方,整体看下?

  • 移动端兼容性测试 (上) at 2019年09月22日

    作为这个账号的第一个帖子,这么大的二维码,广告引流味道有点重了呀。文章感觉也只是个开头,不完整。。。
    建议先给出几篇干货文章,让大家认识这个账号,形成影响力,然后再通过这个影响力宣传你的公众号?

  • 在其他工程中使用上面的方式,使用自建库,模块安装没有报错,可是 import 报错,引不进来

    可以看看,用不了自建库和用得了的项目之间,有什么差异?import 报错,报错的具体错误提示发一下?虽然步骤说得很详细,但关键的日志和代码信息没给出,其实还是不足以协助排查定位问题的。

  • 我们以前曾经尝试在项目中试点 cdc(消费者驱动的契约测试),技术用的是 spring cloud contract ,但后面发现用处不大。

    主要原因是,实际项目中虽然微服务间通讯很多,但服务间基本都是通过使用 rpc 的方式来调用(例如 dubbo),schema 是以 java 代码(service 定义接口,model 定义具体数据内容)形式定义并把所有抽离成单独的 Jar 包供所有使用方以依赖项形式引入。双方都通过同样的 java 代码相互调用,基本不大会存在契约被破坏的情况。即使是一个 provider 多个 consumer ,由于用的 java 代码一致,也不存在契约字段数量、类型等对不上契约测试关注的问题点。

    至于 provider 或者 consumer 单方面调整协议导致另一方无法通讯,只要 provider 在修改时保证向下兼容即可(如 service 和 model 都只做增加),实在无法兼容的,通知对应所有契约使用方更新依赖 jar 包版本也可以解决。

    当然,也有一个很大的原因时,我们微服务的总服务数量不多,在 20 个以内,provider 提供的契约最多也就给 2-3 个服务使用,且都是同一个团队或者沟通非常密切的团队。所以契约测试里提到的沟通不顺畅、同步不到位导致部分服务无辜被契约变更受累的问题也基本不怎么会出现。

  • 访问 testerhome 报 403 了 at 2019年09月21日

    查了下 ip 地址的地理信息:11.241.9.247来自美国

    截图里的确认是公网 ip ?如果不一定,建议找下运维部门了解下你连接网络的公网出口 ip 是啥。一般一个公司或者一个大楼会公用少数几个出口 ip 的。

  • 请专业地报 bug 或问题。可参考 https://testerhome.com/topics/20226

    现在给出的信息实在是太少了。

  • 一般我们是直接通过 code review 来确认重要地方有打印 log 的代码 + 功能测试的时候留意下是不是真的有打印。正常来说一个用户请求或操作,在一个系统内部打印的 log 在 10 条以内,所以人工看工作量倒不会很大。

    听你的描述,这种 log 更类似于用户操作或者客户端各类操作的事件埋点?

  • 已解决。

    问题原因是这个帖子原来所属的节点已经被去掉了,导致回复时发现帖子缺少节点,内部数据库搜索结果为空,因此返回 404 了。
    现在通过编辑给它加上了一个有效的节点,问题解决了。

  • 是的。

    这篇文章说的就是 repeater-console 这种方式如何进行 mock 和回放。

  • 我对版本的理解 at 2019年09月16日

    好奇问下,花厂是哪家?