resultType="Integer" 这里至少和你声明的返回类型不一样，改对之后，不清楚还会不会有这个报错，可以试试

奔溃 崩溃， 以及经常见到的 视屏 视频

免费版并发应该没有限制的，可以自己配置其他机器作为施压机器，官方的微信公众号里面有教程，我用免费版搞过性能测试

开发->测试->运维 以测试角度来说，左移我觉得就可以是向开发靠近，关注开发关注的内容，以测试人员的视角提出独特的观点，举例来说：开发实现了一段前端代码，开发人员做 review 的时候也觉得没什么问题，但测试同事可能更关注代码的可测试性，会提出一些意见（举个不一定恰当的例子：UI 自动化的元素定位有多种方式，开发如果给元素加了 id，后期测试写自动化会更容易一些，直接 findById，也会比较稳定，开发的这个 id 可能完全没有什么业务作用，纯粹是为了给 UI 自动化定位用的，这就是可测试性的一个例子）。

测试左移，可以以测试人员的视角有独特的关注点

架构设计是否合理（一般适用于新项目），帮开发写单测（？有待讨论），代码扫描，参与 CodeReview，质量门禁与质量卡点，每次交付给测试进行系统测试之前，用自动化跑一遍作为冒烟（如果有自动化的话），能做的事挺多的

我们公司内部环境还算不错：
1.领导都是懂行的人，不会有外行指挥内行的情况，知道这个东西有价值，也愿意投入资源让我们尝试
2.之前有成功的案例，于是大家现在也都愿意去当这个种子团队，形成了良性的循环了，持续积累

对落地过程深有体会，概括来说：
内部有痛点，外部有方法，取其精华去其糟粕，进行 “本地化” 改造。
综合考虑人员能力水平，项目开展方式，选择种子团队，自动化（非自动化测试，而是将方案以平台或者脚本方式提供）以降低门槛，保姆式的手把手教学，练习并持续的改进方案，与用户（测试团队）共同获益，种子团队试点成功，进一步向其他团队推广，种子团队失败，分析问题，重头再来。整个过程会持续 1-2 年，对推动者来说是极大的考验，对团队来说是肉眼可见的成长，绝非一朝一夕之力，浅尝辄止之能。

具体正确性的定义是什么呢？如果是满足某种业务规则的话，你也可以写个脚本读库然后校验

数据库 + 文件系统。数据库保存元数据，文件系统保存具体的用例内容。采用这种结合的方式既方便平台管理，也方便实际使用。