操作系统：Centos※,Freebsd,Ubuntu,Redhatlinux,suselinux
网站服务：apache※,nginx※,lighttpd,php※,tomcat※,resin※
数据库：Mysql※,PostgreSQL,Mysql-proxy,MariaDB
代理相关：lvs,keepalived,haproxy,nginx,apache,heartbeat（此行都是※）
网站缓存：squid※,nginx※,varnish
内存缓存：memcached※,memcachedb,TokyoTyrant※,MongoDB,Cassandra※,redis※,tair,CouchDB
存储相关：Nfs※,Moosefs※,Hadoop※,gfs※,lustre,FastDFS
版本管理：cvs,svn※,git※
监控报警：mboy,mrtg,nagios※,cacti※,zabbix,munin※,hyperic※
域名解析：bind※,powerdns,dnsmq※
同步软件：rsync,inotify,sersync,drbd,csync2,union,lsyncd,scp（此行都是※）
分发工具：Secboy※,expect※,puppet※,cfengine※,ssh+rsync+sersync※
虚拟软件：xen※,kvm
内网软件：iptables※,zebra※,iftraf,ntop※,tc※,iftop
邮件软件：qmail※,posfix※,sendmail
远程拨号：openvpn※,pptp,openswan※,ipip※
统一认证：ldap(可结合微软活动目录)※
队列工具：ActiveMQ※,RabbitMQ,MemcacheQ
打包发布：mvn※,ants※,jenkins※
测试软件：apacheab,smokeping,siege,JMeter,Webbench,LoadRunner（此行都是※）
日志相关：syslog,rsyslog,Awstats
DB代理：mysql-proxy,amoeba（更多还是程序实现读写分离）
搜索软件：Sphinx,Xapian（大公司会自己开发类似百度的小规模内部搜索引擎）

提示：
1）以上所有软件都是老男孩用过或测试过的。
2）带※的为老男孩最近几年用的比较多，可信任使用的。也是近年来linux运维的大众。
3）有了功能分类和软件名，大家有需求，可以按功能找软件直接G就知道了。
4）学习要有舍有得，什么都抓必然短时间都不会精，希望大家能抓重点，抓精髓，大众软件（带※）先熟练了，这是基础加提高，在研究小众软件（不带※），这是高手之路，最后在研究偏门的，世外高手之路，当然前提是先掌握前面的大众和小众。
5）当然还有一些没有大众开源的有一些也很棒，如审计堡垒机程序。

还有用的多的，老男孩落下的，大家补充啊。

本文出自 “老男孩linux运维” 博客，请务必保留此出处http://oldboy.blog.51cto.com/2561410/775056

2.     Dmalloc－Debug Malloc Library.

3.     Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。

4.     Leaky－Linux下检测内存泄漏的程序。

5.     LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。

6.     MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。

7.     Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.

8.     KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree.

9.     Leak Monitor－一个Firefox扩展，能找出跟Firefox相关的泄漏类型。

10. IE Leak Detector (Drip/IE Sieve)－Drip和IE Sieve leak detectors帮助网页开发员提升动态网页性能通过报告可避免的因为IE局限的内存泄漏。

11. Windows Leaks Detector－探测任何Win32应用程序中的任何资源泄漏(内存，句柄等)，基于Win API调用钩子。

12. SAP Memory Analyzer－是一款开源的JAVA内存分析软件，可用于辅助查找JAVA程序的内存泄漏，能容易找到大块内存并验证谁在一直占用它，它是基于Eclipse RCP(Rich Client Platform)，可以下载RCP的独立版本或者Eclipse的插件。

13. DTrace－即动态跟踪Dynamic Tracing，是一款开源软件，能在Unix类似平台运行，用户能够动态检测操作系统内核和用户进程，以更精确地掌握系统的资源使用状况，提高系统性能，减少支持成本，并进行有效的调节。

14. IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。

15. Parasoft Insure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft Visual C++的一个插件运行。

16. Compuware DevPartner for Visual C++ BoundsChecker Suite－为C++开发者设计的运行错误检测和调试工具软件。作为Microsoft Visual Studio和C++ 6.0的一个插件运行。

17. Electric Software GlowCode－包括内存泄漏检查，code profiler，函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。

18. Compuware DevPartner Java Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。

19. Quest JProbe－分析Java的内存泄漏。

20. ej-technologies JProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。JProfiler可提供许多IDE整合和应用服务器整合用途。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存泄漏、并解决执行绪的问题。4.3.2注册码：A-G666#76114F-1olm9mv1i5uuly#0126

21. BEA JRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。

22. SciTech Software AB .NET Memory Profiler－找到内存泄漏并优化内存使用针对C#，VB.Net，或其它.Net程序。

23. YourKit .NET & Java Profiler－业界领先的Java和.NET程序性能分析工具。

24. AutomatedQA AQTime－AutomatedQA的获奖产品performance profiling和memory debugging工具集的下一代替换产品，支持Microsoft, Borland, Intel, Compaq 和 GNU编译器。可以为.NET和Windows程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题。支持.Net 1.0,1.1,2.0,3.0和Windows 32/64位应用程序。

25. JavaScript Memory Leak Detector－微软全球产品开发欧洲团队(Global Product Development- Europe team, GPDE) 发布的一款调试工具，用来探测JavaScript代码中的内存泄漏，运行为IE系列的一个插件。

附录：内存泄漏的发生方式

1.     常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。

2.     偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

3.     一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块且仅有一块内存发生泄漏。

4.     隐 式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是 对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

什么是系统资源？

当应用程序在Windows中运行时，Windows必须实时"跟踪"该应用程序的运行，并保留与之相关的许多信息，如按钮、光标、菜单的位置和位图、窗口的状况等，这些信息由Windows保留在一种叫堆的内存块中，堆的英文为Heap。简单地说，堆是采用特殊机制管理的内存块。由Windows的一个系统内核User.exe管理的堆叫做User资源堆（User Resource Heap），由另一个系统内核Gdi.exe管理的堆叫做GDI资源堆（Graphical Device Interface Resource Heap，简称GDI Resource Heap），User资源堆和GDI资源堆合称为系统资源堆（System Resource Heap），习惯上就把它们叫做系统资源（System Resource）。

　　微软将Windows的系统资源（堆）分为五个堆，其中User资源堆为三个，而GDI资源堆为两个。

　　三个User资源堆分别是：16位的用户堆（User Heap，64KB）；32位的窗口堆（Windows Heap，2MB）；32位的用户菜单堆（User Menu Heap，2MB）。

　　两个GDI资源堆分别是：16位的GDI堆（GDI Heap，64KB）；32位的GDI堆（GDI，2MB）。

　　从这里的系统资源分类和大小我们应该明白，不管CPU是P4还是486，内存是8M还是1G，所有Windows的用户都拥有同样大小的系统资源（堆），用户不能自已增加或减少系统资源的大小，这是由操作系统决定的，与硬件档次没有任何关系。

来自: http://hi.baidu.com/jrckkyy/blog/item/6947f42332ec80589922ed6d.html 

从2000年开始从事软件测试，逐渐形成自己的软件测试思想，而第一次比较清晰呈现自己的测试的思想是2007年出版的《全程软件测试》，正如前言所叙：“从项目启动的第一天起到需求和设计的评审阶段，从后期的缺陷修正到产品维护——在整个软件生命周期中，开发人员和测试人员愉快地合作、共同努力，将软件产品的开发效率和质量推到一个新的高度。”，这些思想在测试管理工作的体现就是让测试人员更早地融入项目中，更主动、更密切地与开发人员协作，与项目相关利益者合作，确保项目按时按质地完成，即：

• 测试人员越快地发现缺陷，项目越能尽早结束；
• 测试人员尽可能多地发现Bug，遗留在产品中的Bug就会越少，产品的质量就会越高； 
• 测试人员和自己（开发人员）的工作都是为了相同的目标——按时、高质量地发布产品； 

而此后和业界的测试人员、开发人员交流更多，思考得更多，在测试上的思想更清晰，于是在2012年9月5日在新浪微博（http://weibo.com/1652927771/yArIqoCKW ）上发表了自己的个人软件测试宣言：

宣言发布后，得到不少网友的肯定。最给力的，要属@培根芝士牛蛙堡:感觉总结的太到位，can’t agree more了，最近在看《软测之魂》，很多观点都是异曲同工啊，虽说就简单四句话，但是每一句话展开去都能写一本书。还有@让测试飞起来：又见右下八卦图亮点。每当遇到左、右难以分辩时就想到它，并以此为基点，偿试思考再进一步，思丝多而力争不乱。分割线不是直的哟，似乎体现开发中有测试(调试)，测试中有开发，而又不完全符合对立统一。

当然，也有不同声音，例如：@胡争辉：首先应当强调产品工程，然后在产品工程中强调需求工程，其次在需求工程的基础上强调品质保证工程。脱离的产品工程的品质保证工程是无本之木，无源之水。这实际和我宣言没有关系，这里丝毫没有否定产品工程，也没有否定需求工程，实际第一句“更鼓励事先确定验证的标准并以此来驱动开发”就是强调需求的重要性。需求是软件开发的源泉，而这里关注点是“软件测试”，比较局限于测试自身的内涵和测试与开发的关系。如果拓展出去，我需要发表我的“软件工程宣言”了。

还有其它有意义的补充：

•  @程序员邹欣：值得开发，测试，项目管理人员思考。 认可内部测试的重要性, 但更重视产品对用户的长期影响；
•  @王立杰-WangLijie：认可测试对质量的改善，但更提倡质量是內建的；
•  与@Testin-Daiyibin 讨论之后，增加一条，即：认可自动化测试的价值，但更提倡测试分析和设计的创造性和系统性。

那下面回归主题，就我自己的软件测试宣言，逐条分别进行说明，并简要阐述如何将它们应用于实际的软件开发工作之中。

1. 认可测试的价值，但更鼓励事先确定验证的标准并以此来驱动开发 

首先认识测试的价值，测试是质量保证的重要手段之一，正如在我的博客中所讨论的“软件测试究竟发挥什么作用？”：

• 对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息；
• 通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本；
• 通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。
• 通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的

所以软件测试的价值不容忽视，但是我们一直提倡“质量更是內建的（Quality is built in）”，软件产品的质量是在需求分析、功能设计、系统设计、编程等过程中逐渐形成的，事先清楚客户的需求，明确软件产品的验收标准，基于这些需求和验收标准来开发，开发人员清楚自己要实现的目标、清楚待实现系统的要求和限制，在工作中能够第一次将事情做对，或者说，第一次将事情做对的可能性会显著提高，在需求、设计、代码中引入的缺陷就会大大减少。理解这一点并不难，如果还是不能很好理解，就看看砖墙是如何砌成的？是先拉上水准线再墙砌，还是墙砌好之后再拉线来检测？

而且，对测试人员说，全生命周期的测试依据也明确了，能够及时提供明确的质量反馈，测试与开发之间也不容易引起的争议，测试效率也会明显改善。本句宣言和验收测试驱动开发（Acceptance Test Driven Development, ATDD）拥有共同的思想和内涵，无论是在传统研发流程中还是在敏捷过程中，都可以尝试这样去做。虽然在某些项目上需求不够清楚、或需求变化比较大，但也不能成为“自己懒于彻底分析需求”的借口，能明确60%的需求，也不能做到30%就停下来了。 否则，无论是“迭代”、还是“重构”，都是“返工”美化之后的代名词。难道企业希望自己团队常犯错误而不断修正吗？

2. 认可专业测试人员的不可替代的价值，但更鼓励开发人员做好测试

上一句已经回答了测试的价值，而这里是讨论测试工作由谁来做？测试有价值，但不一定由专职的测试人员来做，正如一些公司（如facebook）没有专职的测试人员，软件产品的研发也能正常开展。也许在某些初创的企业、特殊商业模式的软件服务、某些移动终端的且免费的产品等可以不要专职的测试人员，但对大多数软件产品、软件企业还是需要专业的测试人员，因为系统复杂、业务更复杂的原因，更可能是测试本身更需要方法和技术。当我们不能简单地掌握软件产品（系统）的测试方法和技术，就需要专业的测试人员。即使在相对低端的制造业，掌握其工作技能不是很难，但熟练工人的工作效率也是初级操作工的几倍。而软件测试所涉及的方法、技术与工具，从功能测试到性能测试、安全性测试、兼容测试、可达性测试到可靠性测试等，从测试计划、测试分析与设计到测试结果分析，从等价类划分、判定表、因果图到基于模型的测试、自动化测试等，已形成一个庞大的体系，没有专注，很难做得精，不能精通测试，又如何有良好的测试效率呢？没有专业的测试技能，测试的风险也很大。这些内容，在我的另一篇博客“专业测试团队会消亡还是新生”进行了充分讨论。正如网友在本博客上还评论说：“如果没有专业的测试团队，那么天上的飞机一定会无缘无故地掉下来，ICU里面的心电监护仪罢工也不会是新闻，核弹未接收到真正的发射命令而自行启动也不是没有可能，这个世界将不再是安全的世界。”

为什么更鼓励开发人员做好测试呢？这是因为：

• 单元测试是基础，没有单元的质量，如何有系统的质量？而单元测试主要是在代码层次上展开，而且和编程交织在一起，编程和单元测试难以分开处理，所以单元测试最好由开发人员来做，确保良好的工作效率与工作质量；
• 如果开发了一个测试工具，先让开发人员用起来好，还是只让测试人员用？无论是功能测试工具还是性能测试、安全性测试工具，都可以让开发人员先用，测试的效率会更高。一边构建、一边验证，更能及时发现问题，能更快调试和修正问题，将问题消除在萌芽之中。这也就是为什么我们一直提倡持续构建、持续测试；
• 如果开发人员做更多测试，就更能认识到自己的问题，了解问题产生的原因，将来在设计、编程中更好地避免同样问题的发生，预防缺陷效果更好。

这里鼓励开发人员做的测试，主要集中在单元测试（功能、性能方面的测试）、集成测试等方面。而系统的测试、用户需求的进一步验证和确认、大规模的性能测试、兼容性测试、安全性测试等则有专业的测试人员完成。

3. 认可测试计划的价值，但更强调计划是一个基于风险不断调整的过程

这点比较容易理解，做一件事，如果没有计划就比较盲目，失败的可能性就很大。测试计划目的就是明确测试的目标、测试的需求（包括测试范围、测试任务优先级等）、测试风险、测试资源和进度安排等，但同时需求会发生变更、开发的设计与代码质量超出我们的预料、测试工作量估算不足以及其它新的测试风险等各种因素的影响，我们可能需要不断调整测试计划，以适应新的测试需求等。计划重要，但不是一成不变的，也就是我们强调：

• 测试计划不能停留在文档上面，它是对测试过程的规划与指导，使测试工作开展得更顺利、更有效；
• 测试计划不是一个文档，而是一个计划的过程，适时调整以及时满足项目新的需求；
• 对测试计划的调整也是学习的过程，有利于将来（为下一个项目）制定出更可靠的测试计划。

4. 认可探索式测试的价值，但更希望测试是具有系统方法的、相对规范的过程

我们都知道，测试不能穷尽，测试不能做到百分之百，总是有不能测到的地方，总是有缺陷遗留下来，这就给我们留下了足够的探索空间。探索式测试（Exploratory Testing，ET）的出现正是因为在软件系统中存在许多未知的东西难以得到快速、简单的验证，需要我们转变思路，不要以固定的模式来完成测试，而是要换一种新的模式来进行测试，以提高测试效率。因为需求不清楚、时间紧等各种原因，探索式测试才更有效，在一定程度上是因为软件开发本身的问题，所以，我也戏称“敏捷开发”为“探索式开发”。从这个意义上讲，探索式测试方法是不得已而为之的一种方式。在传统行业，没有看到一种“探索式检验”（除了食品安全检验，在我国还不够成熟，可能会采用探索式检验，哈哈），而是有明确的技术规格，有相应的检测仪器或方法进行检验，可以明确地给出检查结果。

探索式测试作为明确的术语或概念，最早是由测试专家CemKaner博士在1983年提出的，距今天差不多有30年，但绝大多数测试人只是最近几年才听到或熟知这个概念。说明其价值是有限的，如果价值很高，也不至于我们现在才比较关注的。但最近几年探索式测试很热，为什么？

一方面要感谢James A. Whittaker撰写的《ExploratorySoftware Testing》一书，比较全面地介绍了探索式软件测试（国内是2010年引进本书的，但也有不足，我在为史亮和高翔写的《探索式测试实践之路》的序中谈到这一点），对推广探索式测试有很大的促进作用。另方面，在互联网时代，需求衍变越来越快；软件已经成为一种服务（SaaS），迭代周期越来越频繁。敏捷方法开始流行，被软件企业广泛采用，敏捷测试随之而生，正是探索式测试用武之时。而且探索式测试的确给人一些新鲜的感觉，将测试工作变成更有趣的探索式活动，在享受工作的同时完成测试，容易受到测试工程师的欢迎。

探索式测试也在不断发展，人们试图帮助它建立一套方法体系，例如James Bach提出的基于会话的测试管理(Session Based Test Management,简称 SBTM)。该管理方法将测试任务分解成一系列会话(Sessions，发生在特定时间盒内的会话活动，对软件系统的测试就是看成不断地问系统的过程，从系统那里获得答案，探索式测试的会话特征更为明显),测试人员在会话过程中完成一个特定测试任务的设计、执行和记录。

但从探索式测试的“探索”概念本身来看，还是强调“设计与执行”同时发生的特点来看，探索式测试更多强调人的创造性，强调随软件功能的使用对其理解不断深入来发现问题，更强调这种上下文驱动的思维模式，而对验收的标准、验证的具体指标缺乏关注，更谈不上测试需求的分析、测试的系统设计，在系统性和规范性方面有很大的欠缺，所以难以得到国际标准的支持，在多数软件产品的测试工作中探索式测试只能起着辅助、补充的作用。

任何严重的缺陷的遗漏可能给公司带来不可估量的损失，软件测试更注重对软件质量的全面评估，最大程度地减少软件产品的质量风险，从这个意义看，测试目标、测试需求、测试风险等都是非常重要的，需要认真分析，然后在此基础上进行系统的测试设计。测试的结果需要严格的覆盖率衡量，而要确保高覆盖率，需要事先进行精心的设计，从业务流程、数据流程、用户场景等各个方面进行细致分析，采用合适的测试方法设计出相应的测试用例来覆盖流程路径、数据输入空间以及各种产品使用的场景。事先能从需求覆盖出发来设计测试用例，事后还可以从代码覆盖来检验测试的效果。当然，更理想的方式是用基于模型的测试或形式化方法来验证系统的需求，给出更客观的、更准确的质量评估，我们对产品的发布就更有信心，客户就能得到高质量的产品或服务。

5. 认可发现缺陷的价值，但更重视对软件产品质量的全面评估与持续反馈

发现一个缺陷并得到修正，产品的质量就减少一份风险；在当前产品中发现的缺陷越多，就能更多地消除产品的质量风险，这是软件测试价值之一个方面的体现。但我们不能有这样的思想：测试人员发现的缺陷越多，测试人员的价值越大。例如，我们不能一直等开发人员把设计、代码都工作全部完成之后，我们再来发现问题，以体现测试的价值。我们更不能明明看着开发人员犯错误、或者明明知道开发人员可能会在某些地方犯错误，我们也不给予提醒、不给予帮助，而是等到他们做完工作，我们再把问题发现出来，以体现我们的价值。

正确的做法则是及时提供有关质量的反馈，可能是一种质量风险的提示，也可能是一种质量担心的倾诉，更可能是一种有关质量改进的、积极的建议。例如：

• 在需求分析时，发现需求不够清晰，发现可能给开发、测试带来困惑的地方，都要及时指出来，并帮助纠正。
• 如果发现文档中新增加的功能没有多大意义，或者是自己难以看清楚其功能对客户的价值，就要主动和产品经理沟通，建议拿掉这个功能，或让产品经理解释清楚、说服自己。
• 如果觉得开发任务安排不合理，或觉得开发之前的讨论、培训不够，对业务理解还很肤浅，就要及时和开发沟通，帮忙消除这种潜在的质量风险；
• 如果发现开发不重视单元测试、或者单元测试做得很少，就要协助开发做好单元测试，提供单元测试指导，提供单元测试框架，提供一切可以帮助开发改善单元测试的服务。
• 如果发现个别的开发工程师不遵守编程规范，就要启动质量反馈机制…
•  … …

这意味着：

• 测试工作不是软件开发生命周期的某个环境、某个阶段性的工作，而是贯穿整个软件软件开发生命周期，测试人员无时无刻不在关注质量；
• 测试人员不仅仅要关注已经存在的产品缺陷的问题，还要关注可能导致缺陷发生的问题，尽量帮助产品需求人员、设计人员、编程人员预防质量问题的发生。
• 测试不仅仅是测试人员的工作，而且和软件开发的其他团队（人员）有关系；测试工作不是测试团队内部的事，而是整个开发团队的事。

在微软或其它一些软件公司中惯例是：每日构造并做“冒烟测试”。每天都对已完成的源程序进行编译，然后连接组合成可执行的程序，并做“冒烟测试”，以简单的检查该执行程序在运行时是否会“冒烟”。

带来的好处

虽然这是一个非常简单的过程，但却有非常重要的意义：

1、能最小化集成风险

项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。

2、能减小产品低质量的风险

    这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。

3、能简单化错误诊断

当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。

4、能极大鼓舞项目组的士气

看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。

进行每日构造和冒烟测试

虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：

1、每天坚持

每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。

有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。

2、严格检查每一次build

要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。

对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。

一个好的build起码应该具备以下条件：

●能够成功编译所有的文件、库，以及其它相关组件；

●能够成功链接所有的文件、库，以及其它相关组件；

●不能存在任何使得系统无法运行或者运行出错的高级别故障；

●当然，必须通过冒烟测试

3、每天进行冒烟测试

冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。

不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。

冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

4、建立一个专门的build小组

    在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。

5、为build增加修订，如果这样做有意义的话

    一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。

6、规定一些导致build失败的惩罚措施

很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。

有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。

有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。

7、即使在压力下也需坚持每日构造和冒烟测试

当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。

为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。

谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。