#1 楼
恕我直言，这取决于测试人员在进行此类转换之前所扮演的角色。顺便说一句，我相信我的答案通常适用于DevOps转换，而不仅适用于You build it, you run it范例。如果角色是无人驾驶飞机-盲目地执行测试-必将消失，自动化将吃光这样的工作。
如果角色包括编写测试计划和规范，他们可以继续这样做，甚至可以演变成与开发人员并肩编写相应的自动化脚本。还是独立的-在某些环境中，必须使用与开发所使用的方法/基础设施/人员完全不同的方法进行测试。在许多组织中，测试人员和开发人员一样，都是软件工程师。自动化测试-这也不会改变。
#2 楼
“您构建它，然后运行它”
此引用旨在强调筒仓团队之间的休息，开发的原则是避免筒仓完成一项任务。
虽然这里的想法集中在构建和运行阶段，但重要的想法是将整个团队团结起来，从架构到开发角色。 “开发团队”将由参与软件生命周期的所有角色组成，包括测试人员角色，而团队中没有人处理单个角色。
测试人员的主要变化是学会在敏捷团队中对计划阶段表达自己的意见和反馈，并可能参加一些操作任务。
但总而言之，没有确切的规则，以前在筒仓中的某个人在“发展团队”中会做什么取决于他/她对什么更感兴趣并且更乐于做。这是新组建的团队所面临的挑战之一，即发现每个人的最佳能力以最有效的方式分担负载。
评论
请问您是否具有此处建议的特定DevOps团队拓扑[1]或全部？ web.devopstopologies.com
– Peter Muryshkin
17年6月27日在11:56
并非全部，但是我们拥有或多或少的高级产品团队，一类属于第1类，我们并没有真正的第2类（起初Ops团队的产品太多，但最初的Ops团队太少了），我认为我们有一个团队在抗C型中也。感谢您的链接，这是一个非常有趣的阅读。
–滕西拜
17年6月27日在12:14
别客气;在此内容传播之前-您知道它的发生速度如何-是否有机会通过这个社区提出一个问题来验证这些拓扑，而不会引起麻烦（例如，可能有措辞需要调整，或者添加另一个缺少类型）。就像“这些DevOps拓扑中缺少什么？” ...
– Peter Muryshkin
17年6月27日在15:46
恐怕就已经是意见的事物征求意见不会带来任何有价值的东西。
–滕西拜
17年6月28日在8:08
#3 楼
我是一名高级工程师，我以这种身份聘用。在发展的这一点上，我发现很难聘请一位无法轻松过渡到基础架构工程师职位的测试人员（别人可能将其称为Devops角色）
例如，我不希望测试人员知道JVM多线程的复杂性，或者在python类设计中非常自以为是。我希望他们能够理解他们可能会编写存根代码或生成合成数据的来源。
我希望现代的测试人员能够了解我团队中的devop的基本知识。这将包括：使用我们的CM工具配置裸机服务器，通过各种工件或容器部署代码。
我进一步要求他们在了解数据如何在系统中传输方面具有一定的数据工程师能力。考虑故障的单点位置以及如何模拟故障，节流等。
我从不雇用测试人员来执行模块级测试，我将其定义为少数几个类的交互。 （例如1-20）位于网络障碍后面。
tl; dr我会聘请测试人员来设置环境，通过该环境模拟（或重播）数据并在环境中造成混乱。
评论
感谢Dan-我想了解更多有关突击测试的信息，不知道软件工程领域是否有此类测试
– Peter Muryshkin
17年6月27日在15:15
@ J.Doe我最近听说了这个概念，然后我放弃了这种测试，因为它不可靠，因此不可用。但是我只是将其视为回归检测测试。但是我经过了更多的思考，并且我相信在某些领域这种测试对于开发确实非常有用-例如，对于游戏或其他重型UX应用程序。
–丹·科尼莱斯库（Dan Cornilescu）
17年6月27日在15:24