检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
强调从客户的角度，即从使用系统的用户角度来测试系统。 重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试。同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。 组织挑战 接下来让我们看看
测试右移是指要把测试活动的覆盖范围尽量向后蔓延。我们现在的测试只进行到了版本发布之前，测好之后发布一个软件包，而测试右移就要求我们要把软件包发布到生产环境，以及到线上运营环节，都要去做测试。 在这两个方面也有一些相应的实践，例如线上拨测，主动线上监控用户的一些行为，并从行为轨迹里面快速捕捉相应的问题，
运行效率越低，修复和维护的成本都很高，复杂性也随之升高，应该做的频度越少。 事实上，我们有双层的金字塔结构，上面是线上环境的测试，包括拨测、捣乱猴子测试，以及各类的性能和安全测试。 刚才说应该测试前移，投入更多的在短周期的活动；同时又说，测试要延展到生产环境，覆盖发布和线上的运
错，而是适合与不适合。所以，要思考的是哪种方式更适合你的团队。 物理看板的优势和劣势 优势 成本低：几乎不需要成本，办公室允许粘贴的玻璃墙、白墙或者白板均可，再准备点便签和笔。 入门快：只要团队想好了怎么做，立刻可以做到工作的可视化，特别适合刚刚使用看板的入门级团队。 更改方便：
间的隔阂，无法真正的将价值持续的交付给客户。 开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定、安全和可靠的服务。更重要的，两者的KPI度量指标，绩效考核激励机制不同，决
计，因此，原本因为物理空间受限以及可读性原因存在的物理白板的弊端，反而可以作为细化程度的一个有效限制原则（正如著名的两个披萨原则）：以物理墙/白板为影响地图的最大边界。 相对于我们通常关心的业务功能/营销活动，即影响地图的第四层What，我们更应该把注意力放在前三层目标、角色和影
的分离而造成的管理混乱，开发要不断的迭代新版本上线新功能，但是运维关注的是稳定，这两种需求实际上是矛盾的。但DevOps旨在打破这道混乱之墙，让开发、运维、测试协同作战，提高研发效率，实现高效交付，解决传统模式下的运维之痛。 事实证明，DevOps确实能够较好的解决开发和运维之间
开发的工作与运维的工作应该解耦，运维更多是将IT运维任务转变为自助、自动化服务，把基础架构的配置能力交给开发，因为没有人比我们更清楚应用的运行环境。 保证每个环境（开发调测环境、测试环境、QA环境、生产环境）都保持一致，避免因为环境不一致导致的各种问题。后面统一使用Docker的方式将应用与环境统一打包到镜像保持环境一致。
看板，设计、开发、测试、上线，所有流程，到了什么环节所有人都看得非常清楚。产品经理每天就可以盯着看板上的需求流到了什么环节，如果到了转测就到转测环境里验收，如果已经上线了就在线上环境再验收一遍。每个服务都会有自己的看板。做了微服务和全功能团队之后，服务之间偶尔会有依赖，会需要另一
导致生产环境未做相应升级而引发失败。为了避免因为环境不一致导致的各种问题，本样例项目中将各微服务应用与环境统一打包到镜像，保持环境（开发调测环境、测试环境、QA环境、生产环境）一致。 通过本章节，您将了解开发人员Chris如何构建并归档镜像和软件包。 预置任务简介 样例项目中预置了以下5个构建任务。
长按/截图保存，微信识别二维码
或者关注公众号“华为云”
