辛苦

辛苦

但是我有点忧虑，由于是收费，整个测试过程必需得用这个工具全程操控，感觉灵活性受到限制，对于组织上千个测试用例来说会不会很不友好？

灵活性受到怎样的限制了？组织上万个测试用例都没问题。既然收费，咨询下官方就会明白这是多余的忧虑。

前端页面关注哪些性能指标？

折腾这么多，还是没绕过。

其二，采用无监督学习的方式构建样本，该方式通过大量正样本的学习来识别异常样本，此类方式能节约大量的人工标注时间和成本，非常值得进一步探究，也将成为后续我们重要的研究方向。

公安干警们通过大量良好市民的观察学习总结，终于彻底摸清了犯罪团伙的作案规律

手工操作费时费力还易错，脚本运行省时省力又可靠。
脚本缺点：需要成本开发。

该 ui 自动化平台侧重点是在功能测试的同时抓取 cpu 和 mem 等性能数据并进行分析

性能测试通常在 API 层面进行，选 UI 层面是不是方向错误？

最好问下运维的同学

似乎说了很多，又似乎什么都没说。。

辛苦

如果行为不符合产品经理的预期，提 bug 即可

这种场景不适合自动化测试

没有可能，Junit/TestNg 设计如此

质量保证

在这一版本中，我们新增了公共用例库功能（X-Pack），用户可以将部分功能用例添加到公共用例库中，位于公共用例库中的用例可以被工作空间下的其他项目所共享；

在未来版本中，我们将废弃公共用例库功能（X-Pack）。用户不可以将部分功能用例添加到公共用例库中，工作空间下的项目间不共享用例；

辛苦

断言是编程术语，表示为一些布尔表达。编写代码时，我们总是会做出一些假设，断言就是用于在代码中捕捉这些假设。断言表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。——来自百科

自动化测试本质是 (用于测试目的的) 编程，断言不区分同步或异步接口。

不应包含在自动化测试框架里的功能如下：
1、接口覆盖率统计
2、分层

1. 合并分开其实差不多，总体工作量相当。
2. 不冗余，UI 能模拟真实用户的行为，接口做不到。

还有一点就是个人感觉测试的上限还是要比开发低一些。
个人做了 7,8 年的测试了，感觉快到测试的上限了。

——愚昧之巅

老师举着一张白纸，上面有一个非著名的公式，他问全班同学，你们看到了什么？台下几乎所有人都回答，看到了一头猪。老师笑了笑摇摇头，说道，难道还有这么大一张白纸你们看不见吗？

直接甩了个几千个用例的文档，让我挑出来能实现的用代码翻译

1. 让你挑
2. 挑能实现的

有这么大的主动权了，还难吗？

跟手工执行统计方法一样。
自动化只是换了执行手段。

有动态参数，没动态传参