因为你考虑的黑客里面，不包括黑产，黑客。思考下这方面就知道了

首先，不要觉得医疗这个行业做嵌入式测试以后的前景差，医疗这个行业和银行类似，你进入了行业后，在同为医疗的其他公司，就很容易进。再然后做测试这行其实也很吃业务经验的，经验丰富的人，要转行都简单。

其实这个里面还会有个问题就是，选座之后，座位不是纯色，现在有的是广告 LOGO，随时都有可能变化的。

买的腾讯云应该也应该需要测试下，主要目的不是测试腾讯云那块的，是测试你们自己的

早上看到显示 23-8 点宵禁，实际上是 23-9

Elasticsearch 本身就是个数据库，所以有对应的查询语言，Logstash 如果设置收集速度快一点的话，可能会好一点，基本没啥太大延迟，而且你本身自己自动化的时候，就可以稍微延迟一点再验证这个日志嘛

我帮回复下这条吧，如果有日志，那么可以借助 ELK 这种日志收集系统，自动收集和归档日志，然后你再用 ELK 的接口查询日志就可以了了，所以其实是可以实现自动化的。ELK 这个也挺成熟的。不过这个可能遇到的问题就是 ELK 收集日志可能会有一点延迟。

AWS 也有这个服务我记得

针对小程序，python 应该是有对应的 sdk 和 API。你可以通过 API 来获取 code 和 session_key、openid。这个是临时凭证。

官方文档：https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/login/auth.code2Session.html

两个方法，用时间 hash 之类的算法规避，或者每次用例执行完删除本次执行的数据

DEVOPS 的一系列工具：gitlab+drone+docker+k8s，测试搭配 YAPI、Junit 等测试工具，超绝完美体验。基本是现阶段的标配了，基本都是开源，K8S 可以用 Rancher 搞，一条命令搞定，简单。

AWS 就有呀，你可以看看

这个你运行多个 CI 任务就行了，每个 CI 任务一个环境。这里的多个 CI 任务应该不能并行运行，我没测试过这个情况

这个是因为，接口用例在使用用例集的时候，会出现有的用例集跑的速度快，导致调用参数还没生成就开始跑下一个用例集了，然后参数就会错误，这个问题暂时还没优化。这个用例集的并发模式用的是 go 的多线程技术，是同时并发执行的，并不是按顺序的，主要是为了让速度更快一点。之后我再加个选项，可以选择是按序执行或者同时并发执行吧。

这个不需要安装，可以直接运行的。按照说明，直接启动 docker 就是一次用例运行

1、对细节再怎么极致追求，仍然会出现问题。
2、敏捷迭代下，应该追求的是无明显缺陷，无明显安全漏洞和缺陷快速反应机制。
3、遗留问题要保持追踪，直到关闭。

其实对用户和口碑的伤害，无论是产品问题，还是设计缺陷，肯定是有伤害的。现在大多数情况下主要是考验的是，出现问题的次数是否相对同行少，出现问题的应急反应措施是否可以最大限度的减少伤害。
测试在这里面，主要就是减少出错的次数。

说下我对测试左移和右移的理解：

• 左移：通过对代码的静态扫描，安全扫描，组织评审等方式，提前解决一些可能的代码质量问题。其主要是在于质量问题，是代码质量的补充手段。这里我认为不是和开发抢饭碗，而是让开发更加专注业务层面的事情。

• 右移：通过对测试环境（开发环境、生产环境或许也有）的管理和质量维度的监控，实现上线前、上线后的质量保证。这里其实一般的测试主要是保证测试环境的质量。但是我觉得，对生产环境的质量监控是非常重要的，这是测试了解生产真实情况的最佳途径。右移我认为也不是抢运维的饭碗，也是对产品质量的保证补充。

传统以往的研发和运维体系，其实是缺失了这一部分的质量保证。研发没有从代码层面监控质量，运维没有从生产上监控软件质量。以前的运维，只要服务器不出问题，软件正常跑，其他就不管了。
但是现在微服务的发展，需要非常细的颗粒度去监控整个软件的运行，所以有了全链路追踪。全链路追踪这里可以认为是运维应该做的，也可以认为测试应该做的，因为测试的职责是把控质量，而链路追踪恰巧可以给测试了解到软件运行过程中非常多的质量问题，这也是以前没有的。所以现在很多公司是测试在做这块，运维没啥动力。

每家公司的情况都有很大的不同，有的公司可能开发规范，开发自然而然的就把我们需要左移的事情都做了，那测试就可以作为质量监督者把控下即可。如果是公司没有，那么测试做，可以提高自己。运维的活同理。

其实作为测试，我觉得无论如何，首先要准确的认识到自己做的事情是为了什么。无论是左移还是右移，目的都在于更好的产品质量。我们用的所有手段，所有技术，都是为了提高测试过程中的效率，准确判断产品质量问题。如果偏移了这个中心，那么我觉得测试就不再是测试了。

这里的代码权限指的是查看代码的权限还是可以修改代码的权限。对于代码权限还是需要细分下的。如果是测试，其实查看，下载代码的权限就可以了。一般不太需要修改代码的权限

接口校验这个你可以参考下社区的一些帖子，基本是自己写程序校验的。校验这个事情可以放到 pipeline 里面，pipeline 是流水线步骤，本身是没有校验功能的，pipeline 是帮你运行你写好的程序。

建议是先看看是否可以做接口类的，然后做持续集成，只有吧持续集成做起来了，才有精力做其他的。不然你每天就光跑脚本了。做了持续集成开发其实也解放了，他可以开发一部分功能或者修改一些 bug，提交代码之后自动编译，自动部署。这中间他就可以并行做其他的事情了，你也不用说是盯着他编译浪费时间了。部署完成之后来个通知，你直接去验证就完事了。

其实现在无论怎么样，都建议吧持续集成做了，这个带来的收益太大了。可能你现在投入精力，花个几个月时间，搞出来之后节约的时间远远不止。我们以前没做持续集成，开发都是基本改完所有 bug 再提测的，这花费的时间就 1-2 天了，测试这段时间基本就是写用例，现在基本 2-3 小时开发就改完，然后缺陷基本都验证完了。

而且做了持续集成之后，接口类的都是全自动校验，后台只要提交代码就自动校验所有以前的接口，避免以前的接口出现问题。我觉得这个挺关键的，也确实遇到过好几次开发无意间改了之前的接口的问题。UI 层面的我们公司是暂时不做的，因为涉及到的人力和物力有点多，这方面不划算，所以我们没做。这方面我是没啥经验的

你公司用 go，你如果用 go 的话方便，其实现在招聘 go 的也很多。不用担心找不到工作。

监控很有必要，具体监控的颗粒度得看你们的业务。

https://yapi.com.cn/ 这个地址是一个示范，并不真实存在。这里实际需要修改为你的 yapi 地址，可以是 ip 也可以是域名。比如，你访问 yapi 是http://192.168.1.1:8000 那么这个PLUGIN_HOST=http://yapi.com.cn参数就应该改为PLUGIN_HOST=http://192.168.1.1:8000

不要用左键点，用鼠标中间点就好了，就是滚轮按下去。养成习惯就 ok

接口测试一般是在服务部署完成之后，再开始运行的。所以这里需要一个检测手段，首先检测新服务部署成功，然后就是版本正确。检测完毕之后就可以开始接口测试脚本了