境内外重点院校本科以上哈（一般国内指 985 211）

欢迎投递~

这不正好自己学一下 docker，然后给 tomcat 搞个镜像，把 webapps 映射出来等等

计划会有线上直播，如果讲师允许的话，会分享 PPT

演讲议题已更新~

计划会有线上直播，如果讲师允许的话，会分享 PPT

第六届郑州测试沙龙来啦，欢迎参与主题演讲与交流活动，暂定六月，不见不散！

点赞！持续关注！

提供另外一个角度，从代码走查角度，结合源码去考虑。现在很多框架对于接口的入参都有注解型的检查了，可以看下开发的源码，对应的接口上的注解/或者检查规则是否正确，对应参数上的注解是否完备，规则是否合理等等。如果这些完全没有问题，似乎也可以稍稍的对这个接口放心些。

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

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

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

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

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

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

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

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

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

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

两方面看待：
1.可能确实是和 “具体的测试” 工作无关，但是是质量保障的动作，往往测试人员是熟悉产品的，可能比开发人员更合适，之前听过某老师讲过，测试可能更适合做实施环节，因此编写手册和答疑也似乎合理
2.确实是一些无关工作，那就不发表简介了

docker exec 进去的时候的 root 是 no-login 的 shell ，你进入容器后再 su - root 一下试试，应该就有了，或者把容器内 ssh 服务启动，22 端口对外映射出来，直接通过 xshell 等工具 login 进去，就也是 login 的 shell 了

https://gitee.com/Dray/jacoco

"但对于维护项目来说，测试覆盖点都是增量或修改需求点，那未覆盖的处会很多，那分析测试遗漏就不好搞了"

1. 可以考虑采用增量的方案，只关注本次的变更是否都覆盖到了，虽然 “覆盖率高” 和 “质量好” 画不了等号，但增量（或者说变动代码）的覆盖率低可能说明确实存在遗漏的场景没有执行到，可以进行分析并决定要不要补充。
2. 给测试人员及相关人员提供信心，有时候信心也是一个关键的要素，覆盖率高比覆盖率低总是要多一些信心，多一点信心总是好的。

如果是 Java 的话，一般来说都是 Spring 全家桶需要掌握，最好能自己有开发能力，知道这些组件和框架都怎么用的，并且自己也会用，熟悉了这些机制之后，能够更好的帮你分析代码。

前端访问接口不通，访问的接口应该是宿主机的端口。你用了端口映射，应用内本来是 B，容器启动时映射到宿主机的 A 端口，则前端打包的时候也应该是 A 端口而不是 B 端口，可以考虑把 AB 设置成一样，或者前端重新打包。