为什么需要持续集成与尽早测试？

为什么现在提倡单元测试——大家还是想让测试更深入，提升质量，不是玩cool
Z1i`}6Z2X+]"`*G72047为什么要闹着上持续集成——也许是赶潮流玩敏捷概念，也许说是支撑自动化测试，但在喧闹之后冷静分析，最早在敏捷中引入持续集成的大师们也是在为了提升测试质量，持续集成体现的最大价值是尽早测试的测试原则，尽早测试是通过尽早暴露和发现软件系统存在的质量风险，来加快项目进度，减少全局测试成本。而尽早测试又不仅仅限于代码级测试（单元测试和静态代码扫描），还包含未编码前的测试怎么做？对需求，架构和设计文档的测试，尽早发现这里面的缺陷——而这靠什么？工具——发现需求、架构和设计缺陷的高效方法论；内功——大量系统级测试bug的经验（很多人偏见的黑盒测试、手工测试发现的缺陷），只有编码缺陷经验的人很难积累需求、架构和设计的缺陷经验，当然丰富软件设计经验的架构师除外。为什么丰富的架构设计经验者能发现这些缺陷？是因为他多年的软件工程经验积累了太多软件失效的经验（改bug，因bug改架构，改设计，改需求），是这种负向经验的积累让他能高效检视需求、架构、设计中的缺陷。但幸运的是：长期从事黑盒手工测试的一线测试人员，通过黑盒手工测试来发现需求和设计的缺陷，从而在无形之中也在积累软件失效的负向经验，如果在平时的测试执行工作中用心去参加bug根因定位分析则又可以积累起软件失效根因的经验，这样通过3-4年的积累，再辅助早期测试的工具（方法论），可以用更短的时间具备快速发现需求，架构和设计缺陷的测试能力（而这也是一种测试技术），这种测试能力产生的尽早测试的价值是单元测试发现bug的10倍（为什么是10倍，请网上搜索这个行业规则）。|#VoRP'A No5sU\7204751Testing软件测试网4KMR#V*CY