这块应该可以忽略掉。 你看看容器是不是已经起来了

恩恩， 我演示的那个镜像的mariadb也是配套的，这块我也是忘了跟你们强调了。

恩恩，一起加油哈，这个行业里的人越多，行业才能蓬勃发展~~ 以后咱们跳槽加薪也容易 哈哈哈

我很负责任的说。。。。这可能是个bug。。。

互联网前后的变化

楼主开篇也提到了在进入互联网前后经历的瀑布式和敏捷式的开发模式。 我也是工作了7年半的人了，经历过楼主描述的过程。 先讲述一段关于小故事吧。 小步快跑，试错迭代的思想在上个世纪漫威的崛起中就已经有成熟的应用了(我是漫威迷 )，斯坦李可不是一口气直接创造了漫威宇宙。而是在一开始尝试性的创建了有性格缺陷的神奇四侠。在斯坦李的笔下，石头人敏感易怒、霹雳火轻佻自负……超级英雄终于不再是高高在上的神话故事，而是一群有血有肉的普通人。(不同于DC的超人蝙蝠侠神奇女侠，他们几乎是完美的) 这种设定迅速激起了年轻人的共鸣，《神奇四侠》大受欢迎，拯救了处于垂死边缘的漫威。随后，斯坦李用这种更加贴近人性的配方，开始用流水线大规模地生产超级英雄。斯坦李一个超级英雄一个超级英雄的试错，一点点找到大众更喜欢的角色。 然后1940年的一期漫画，海王和霹雳火在漫画pk了起来，漫威的超级英雄第一次有了交集，之后是美队和霹雳火和那摩等集结打纳粹。再然后漫威宇宙一发不可收拾，原著中的内战涉及的超级英雄之多令人咂舌。漫威宇宙2000多位超级英雄就是这么被创造出来的。 跟大家说漫威的故事就是想说明这个模式。这种小步快跑，试错迭代的思想被充分的利用在了互联网里。 因为它能更快，更有效率的找到用户更需要什么，如果漫威一开始就设计一个恢弘庞大的漫威宇宙，那它当初早就被DC干死了。 尤其是在互联网中竞争对手无处不在，抢时间抢用户抢地盘。慢一步，步步慢。 当初阿里云诞生之初把评估的工作排期直接压缩了2倍，誓师大会上所有人喝酒宣誓，3月前必须上线。 所有杭州团队的人直接飞北京，光差旅费就花了百万以上，没需求文档没设计文档什么都没有，沟通全靠吼。就是要快，当初的目的就是赶在腾讯云之前上线。如果慢了，很可能就没有现在阿里云的传奇了。 所以在这种商业背景下，传统软件的研发模式必然是淘汰的结局。 这是互联网对传统研发模式的打击。 同时互联网对传统软件公司也造成了一种降维打击。即便是我们这种TO B业务的公司，也或多或少的走这种模式。因为你慢了，你就死了。

所以在这种背景下，像以前一样那么长周期的测试活动肯定是不会存在的了。TO B企业还好一些，互联网就完全是快节奏。 所以才需要大量的自动化来缩短测试周期，也许这时候的测试是不完全的，但这时候的测试是能满足用户需要的。测试人员需要转换一种思维，就是我们的目的是做一个能满足用户需求的产品，而不是一个完美的产品。 经常能看到一些开发吐槽，比如都什么时候了还在这跟我提这些无关痛痒的bug。这就是测试人员还活在自己世界中的表现，也是没有产品意识的表现。 一个成功的技术团队(包括产品，研发，测试，设计等) 要有一个共同的目的，在这个共同的目标下，所有人都要互相妥协。 最后的产出，就是各方为了这个目的互相妥协出来的。 所以像以前那样，质量部门产品部门研发部门互相独立的团队很难存活下去。 现在已不是单打独斗的时代。 相比测试思维，我们更加需要团队思维，整体思维和产品思维。

关于测试人员规范流程的事

根据之前说的，测试人员要跳出纯测试的框框来，从整个团队考虑。 测试人员介入流程规范，约束开发这个事其实没毛病。 有能力就可以做。 我的测试manager现在兼职管着PMO的事，管着TS(技术支持)的团队。而我现在是CICD的owner，老大了我一帮子比我技术好的研发人员做为我的资源让我搞。 产品上，所有关于k8s的需求和设计由我组织，甚至好多需求是我本人提的。 运维上，一些k8s和hadoop集群也是我和我同事在维护。 你看我们的工作涉及到了多少非测试的事？ 不止是QA，我们的研发多少跨界客串一把产品人员的， 客串一把交付人员的。 我觉得一个好的团队是不会给团队划分固定角色的，谁有能力做，谁有时间做，谁愿意去做，那谁就可以去做。 每个人都有自己擅长的领域。 那在自己擅长的领域里跨一把界，是对团队有好处的。 比如我们这种技术架构这么复杂的产品， 有些模块，让研发人员去做产品的角色就是比产品人员自己搞来的高效，正确。

关于测试人员背锅

关于线上出问题了以后让QA背锅，这个是要分情况的，要case by case的分析，但这种无脑背锅的事倒是存在的，一个不成熟的团队会有这种不成熟的思维。 质量是所有人的，不是QA的，有时候该怼就怼。 做QA要是还怕得罪人，还玩个蛋了。

关于测试人员的技术

这个楼主去面试的时候是碰到不太好的团队了。 做到不懂代码的人员也可用的这种思维是无奈之举，一定是团队中不会写代码的人太多了。 没办法而为之的。 但基本上这种关键字驱动框架我就没见过有人做好的。 最后规模大了都是维护噩梦。 只能测测业务层，而且是小规模的。 case多了能累死人。 一个测试人员追求技术是没毛病的。

至于开发人员吐槽你一个测试跟我们聊什么技术。 那还是因为测试的技术没有给他们带来价值，不信你来我们公司看看，会有人吐槽测试的技术么？ 技术不在于有多高明，而是它能为你带来多少价值。 当你的技术能力，产品能力，团队能力达到了一个点的时候，就会呈现出爆发的姿态。

关于思维

我一直建议测试人员跳出测试活动这个小框框来，往整体上看，往产品上看，往团队上看。 思维跳出来以后就会发现，你可以为了产品质量做很多很多事。 不要为自己设限。

这种情况和link还有你创建的network没有关系。 要docker logs 看一下这个容器的日志。 看看发生了什么事情。 应该启动容器的脚本，也就是entrypoint抛错了。

恩，docker inspect能够看容器的元数据。 但其实你有更方便的方式。 在mysql的官方镜像文档里有很详细的说明

你真把我当算法工程师了 。

对了，算子的测试一般不是要高并发的~~ 一般不会这么测的。 就是单个算子在环境里跑。 这样能测出这个算子的baseline

基本上机器学习的所有测试类型都跟数据有关。 所以做性能测试最关注的是数据的构造。 不同的模型对不同的数据有着不同的性能表现。 最简单例子比如你可以把高维特征(海量离散特征，比如1亿维)喂给LR算法也没什么问题。但是喂给GBDT几百维都能慢的像蜗牛一样，几万维特征给GBDT能把集群撑爆了。 所以要构建不同数据规模，数据分布，数据类型的数据。 同时算子运行的参数也很重要。 最常见的影响参数是batch size，learning rate， 训练轮数等。