摘要：有句话说道：“质量是设计出来的，而不是测出来的。”这其实就是在追根溯源bug的产生，因为只有知道了其根源才可以行之有效的解决这一问题。因此要将测试左移到软件最初的设计阶段，并贯穿整个研发活动的始终。
本文分享自华为云社区《测试左移》，作者：华为云PaaS服务小智 。
在传统的软件研发周期中，有个比较著名的模式叫“瀑布模式”，在这个模式中，项目周期被清晰的分为“制定计划->需求分析->软件设计->程序编码->软件测试->运行维护”等六个基本活动。
并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。如果我们看上面从左到右的顺序，测试阶段就是软件生命周期中的一个特定阶段，并且这个阶段处于比较靠右的一个阶段（如上图软件测试在第五个阶段）。
随着时代的进步，人们慢慢意识到软件测试的重要性，并且“靠右”的软件测试阶段发现的缺陷修复成本会非常高，戴明曾提出“问题发现得越早，修复的成本越低”，有数据指出85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。
在《The Shift-Left Approach to Software Testing》中提出，假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的。
于是，软件行业出现了变革，从研发完成后测试才介入的方式，变成从制定计划，需求分析的阶段测试就开始参与进入，从“链条”上看，测试的工作“左移”了。测试左移也就意味着不是在最后阶段进行测试，而是一直持续测试。
要将传统的测试阶段，移至左端的制定计划、需求分析、软件设计、程序编码阶段中，然后相关人员参与相应活动，这里的相关人员主要指测试人员和开发人员（因多数公司组织情况和篇幅等其他原因，仅指出这两种角色）。
对于测试人员而言，需要在项目初始阶段尽早参与，了解项目的需求并和业务人员进行沟通彼此达成共识，也为测试策略及工具等提前准备。测试人员需要参加设计评审会议，需求分析等会议，理解产品设计和结构，识别设计缺陷，建议不同的设计选项，相应的分解设计创建测试场景，要和开发人员紧密合作，除了口头上的及时共同澄清，还需要指导开发人员编写单元测试，也可在用户故事上提供测试场景、意见和反馈等供所有相干人了解查看，预防缺陷，达到预防效果。
对于开发人员而言，要提高自测意识，借助单元测试或者质量分析工具等提升质量，在编码阶段应开展相关活动，如TDD、结对编程，以及长期和坚持开展代码的review活动等，代码的监视活动不单是可以提升代码质量预防缺陷的产生，还可以提升开发人员的编码能力及意识。
总之，测试左移的原则就是测试活动在软件开发周期早期的各个阶段都开展进行，以保障各个阶段的活动都是“安全可靠”的。
基于上面的分析，测试左移的具体实践活动和方法大致如下，每个组织也可需要根据实践情况进行裁剪和调整。
在项目的规划设计上，建议测试和开发人员都参与，并共同输出设计规划。以软件开发平台 DevCloud 为例，可以通过项目管理中的规划进行需求的计划和设计。项目管理根据常用的规划方式提供了甘特图、思维导图两种。
在澄清需求时，测试人员、开发人员和产品负责人等干系人应共同进行需求分析，彼此达成共识。以软件开发平台DevCloud 为例，在描述信息和评论中进行需求的澄清和记录。
需求分析澄清后，测试人员在测试用例设计开发工作上，设计测试用例，完成测试代码的开发、测试数据的准备，并及时与开发人员沟通软件接口，确保测试代码能够成功驱动业务代码。以软件开发平台DevCloud 为例，可以在User Story下关联相关的用例。
并在用例中填写前置条件、测试步骤、预期结果等相关信息。
需求分析澄清后，开发人员根据分析后的功能、验收标准等，以TDD的方式开始开发工作，当代码开发完成或以其他原则结束后，提交代码到代码仓库，由相关人员对代码进行评审，以DevCloud为例，代码提交采用合并请求的方式，可由一人或多人参与代码的评审，根据情况给出评审意见，最后完成代码的合并提交。
当开发人员完成功能开发后，测试人员开始功能测试活动，若发现bug，及时沟通，并协助定位bug。以DevCloud为例，可以通过创建Bug的工作项和User Story关联，以完成测试的执行和分析工作。
当开发修复完bug后，可以对所有代码进行完整的回归测试。在DevCloud中，可以通过单独运行测试套件完成回归测试，或者流水线完成全量的接口测试以实现回归测试。
此外，DevCloud作为一套完整的DevOps工具链，当代码进行集成时，可以通过流水线的能力实现持续集成和测试的能力。当代码提交后，触发流水线中的集成阶段，完成集成的测试工作，集成测试以接口测试为主，可以通过DevCloud中的接口测试得以实现。具体如下：
有句话说道：“质量是设计出来的，而不是测出来的。”这其实就是在追根溯源bug的产生，因为只有知道了其根源才可以行之有效的解决这一问题。因此要将测试左移到软件最初的设计阶段，并贯穿整个研发活动的始终。
很好奇，就使用rubyonrails自动化单元测试而言，你们正在做什么？您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您？git中的预提交Hook？只是手动调用？我完全理解测试，但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的，并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您？ 最佳答案 不确定您到底想听什么，但是有几个级别的自动代码库控制:在处理某项功能时，您可以使用类似autotest的内容获得关于哪些有效，哪些无效的即时反馈。要确保您的提
我正在编写一个包含C扩展的gem。通常当我写一个gem时，我会遵循TDD的过程，我会写一个失败的规范，然后处理代码直到它通过，等等......在“ext/mygem/mygem.c”中我的C扩展和在gemspec的“扩展”中配置的有效extconf.rb，如何运行我的规范并仍然加载我的C扩展？当我更改C代码时，我需要采取哪些步骤来重新编译代码？这可能是个愚蠢的问题，但是从我的gem的开发源代码树中输入“bundleinstall”不会构建任何native扩展。当我手动运行rubyext/mygem/extconf.rb时，我确实得到了一个Makefile(在整个项目的根目录中)，然后当
我有一个围绕一些对象的包装类，我想将这些对象用作散列中的键。包装对象和解包装对象应映射到相同的键。一个简单的例子是这样的:classAattr_reader:xdefinitialize(inner)@inner=innerenddefx;@inner.x;enddef==(other)@inner.x==other.xendenda=A.new(o)#oisjustanyobjectthatallowso.xb=A.new(o)h={a=>5}ph[a]#5ph[b]#nil,shouldbe5ph[o]#nil,shouldbe5我试过==、===、eq?并散列所有无济于事。
我有一些Ruby代码，如下所示:Something.createdo|x|x.foo=barend我想编写一个测试，它使用double代替block参数x，这样我就可以调用:x_double.should_receive(:foo).with("whatever").这可能吗？ 最佳答案 specify'something'dox=doublex.should_receive(:foo=).with("whatever")Something.should_receive(:create).and_yield(x)#callthere
Sinatra新手；我正在运行一些rspec测试，但在日志中收到了一堆不需要的噪音。如何消除日志中过多的噪音？我仔细检查了环境是否设置为:test，这意味着记录器级别应设置为WARN而不是DEBUG。spec_helper:require"./app"require"sinatra"require"rspec"require"rack/test"require"database_cleaner"require"factory_girl"set:environment,:testFactoryGirl.definition_file_paths=%w{./factories./test/
我遵循MichaelHartl的“RubyonRails教程:学习Web开发”，并创建了检查用户名和电子邮件长度有效性的测试(名称最多50个字符，电子邮件最多255个字符)。test/helpers/application_helper_test.rb的内容是:require'test_helper'classApplicationHelperTest在运行bundleexecraketest时，所有测试都通过了，但我看到以下消息在最后被标记为错误:ERROR["test_full_title_helper",ApplicationHelperTest,1.820016791]test
我已经构建了一些serverspec代码来在多个主机上运行一组测试。问题是当任何测试失败时，测试会在当前主机停止。即使测试失败，我也希望它继续在所有主机上运行。Rakefile:namespace:specdotask:all=>hosts.map{|h|'spec:'+h.split('.')[0]}hosts.eachdo|host|begindesc"Runserverspecto#{host}"RSpec::Core::RakeTask.new(host)do|t|ENV['TARGET_HOST']=hostt.pattern="spec/cfengine3/*_spec.r
我在app/helpers/sessions_helper.rb中有一个帮助程序文件，其中包含一个方法my_preference，它返回当前登录用户的首选项。我想在集成测试中访问该方法。例如，这样我就可以在测试中使用getuser_path(my_preference)。在其他帖子中，我读到这可以通过在测试文件中包含requiresessions_helper来实现，但我仍然收到错误NameError:undefinedlocalvariableormethod'my_preference'.我做错了什么？require'test_helper'require'sessions_hel
只是想确保我理解了事情。据我目前收集到的信息，Cucumber只是一个“包装器”，或者是一种通过将事物分类为功能和步骤来组织测试的好方法，其中实际的单元测试处于步骤阶段。它允许您根据事物的工作方式组织您的测试。对吗？ 最佳答案 有点。它是一种组织测试的方式，但不仅如此。它的行为就像最初的Rails集成测试一样，但更易于使用。这里最大的好处是您的session在整个Scenario中保持透明。关于Cucumber的另一件事是您(应该)从使用您的代码的浏览器或客户端的角度进行测试。如果您愿意，您可以使用步骤来构建对象和设置状态，但通常您
我有:When/^(?:|I)follow"([^"]*)"(?:within"([^"]*)")?$/do|link,selector|with_scope(selector)doclick_link(link)endend我打电话的地方:Background:GivenIamanexistingadminuserWhenIfollow"CLIENTS"我的HTML是这样的:CLIENTS我一直收到这个错误:.F-.F--U-----U(::)failedsteps(::)nolinkwithtitle,idortext'CLIENTS'found(Capybara::Element
