摘要：随着计算机技术的发展，软件工程也取得了较大发展。人们希望软件工程像工业产品一样形成一定的标准和规范，但是在对软件工程的研究中只注重软件工程技术，而忽视了软件工程管理的研究。本文通过分析软件工程质量管理的标准、涵义和现状，就如何加强软件工程的质量管理提出了几点建议，希望能够使软件产品更具竞争力。
关键词：软件工程；标准；质量管理
软件工程开发的目的就是将软件工程技术大规模用于实际生活中，那么软件工程的质量就成为软件工程能否大规模运用的重中之重，软件工程应该遵循什么样的质量标准，如何加强软件工程的质量管理就成为一个重要课题。目前我国软件工程开发行业软件质量管理还不成熟，因此必须加强软件工程质量管理。
1、软件工程质量管理的涵义
软件工程是研究如何系统规范的开发和维护程序，主要包括两个方面：软件工程技术研究和软件工程管理研究。软件工程技术研究是对软件工程开发方法、开发工具和开发环境的研究，随着软件工程技术的不断完善，出现了快速原型法、瀑布模型法等研究方法，促进了软件工程技术的进一步发展；软件工程管理研究是对质量管理、费用管理和配置管理的研究，在管理过程中需要控制软件的开发成本、资源、质量、进度等因素。
软件工程质量管理是指对软件产品和软件开发过程的管理，其中软件产品包括中间软件产品、最终软件产品和附属软件产品。软件工程的质量主要取决于软件的设计和开发过程，而不是对软件产品的保证和测试，因此软件工程质量的提高依赖于软件工程质量管理水平的提高。
2、我国软件工程质量管理的现状
国外很多软件工程开发企业由于管理经验丰富，对软件工程质量管理已经成熟，而我国软件工程质量管理却始终处于一个比较低的水平。虽然我国对软件工程质量研究比较晚，但是最主要的原因还是软件工程研究的思想比较陈旧，尤其是软件工程质量管理的思想跟不上国际发展的步伐。值得庆幸的是，目前国内许多软件工程研究人员逐渐意识到软件工程质量管理的重要性，尤其是软件工程开发过程管理的重要性。鉴于软件工程质量管理的复杂性，必须制定一套完善的软件质量评估标准，有效控制软件的质量，为软件工程质量设置一定的标准。
3、软件工程质量标准的产生
根据国家标准GB3935的规定，标准是对重复性事物和概念所做的统一规定。它是以科学技术和实践经验为基础，经有关方面协商，由主管机构批准，并以特定形式发布的作为共同遵守的准则和依据。这里讲的“重复性”指的是同一事物和概念反复出现，例如批量生产的产品在生产过程中的重复投入，重复加工，重复检验等；同一类技术管理活动中出现同一概念的术语、符号、代号被反复利用等。只有当事物和概念重复出现并处于相对稳定状态时才有制定标准的必要。标准不是凭空制定的，而是把科学技术和实践经验经过分析、比较、综合和验证，加以规范化。制定标准的最终目的是促进产品的合理流通，实现社会资源的优化配置，促进社会的进步和发展。
随着国际贸易的扩大和全球化进程的加快，国际标准应运而生。随着互联网技术的发展，计算机软件工程成为一项全球化的产品，因此也需要制定相应的国际标准才能保证软件工程的质量。于是制定一套成熟的软件工程质量标准就成为当务之急。
4、软件工程质量管理的措施
4.1 加强对软件工程开发人员的培训和管理
软件工程质量管理主要是对软件工程开发过程的管理，而这些工作最终是由人完成的，因此需要加强对员工的培训与管理。第一，定期对技术人员和管理人员进行培训，使他们具备过硬的技术知识和管理知识，并定期考核；第二，引进先进的软件工程质量管理人才，学习国外先进的管理经验，避免管理上的漏洞。
4.2 完善软件工程质量管理程序
软件工程质量管理最终要将软件工程进行大规模工业化生产，这就需要一套完善的软件工程质量管理程序。第一，建立软件工程产品质量需求。产品质量需求必须符合所有客户的要求，并把客户的这些要求转换成具体的标准进行说明，并时刻关注这些要求的变化，随时对软件工程进行补充设计。第二，建立一整套开发、维护软件产品的方法。通过指定一套实施规范和标准加强对方法的支持，并通过共同的合作管理来实现。第三，建立软件工程的评价体系。在完成软件工程的开发后，要对软件产品进行复查、评估、检验，并作出评价，目的在于确认软件产品是否符合软件所要求的质量标准。
4.3 做好软件工程质量保证和质量控制
软件工程质量保证SQA是Software Quality Assurance的简称，主要检验软件产品在开发过程中是否符合工程质量标准。它主要负责对软件产品、设施和工具进行审查，评审软件开发过程，进行技术和管理评审，做SQA报告和度量。基本的流程如下：第一，建立SQA小组；第二，确定SQA所要进行的质量保证活动；第三，制定SQA计划，明确整个软件开发的每个步骤及关系；第四，不断完善SQA的过程，防止过程中出现的不足。其中，SQA小组是一个完全独立的个体，它有权对软件产品开发过程中出现的质量问题越级上报，这就对软件开发人员起到了一定的威慑作用，有效的保证了软件工程的质量。而软件工程质量控制是对软件开发过程中无法避免的缺陷进行消除，主要包括需求评审、系统测试、验收测试等过程，以使软件产品最终达到零缺陷。
5、结论
软件工程在开发过程中往往会出现低质量软件和难以避免的缺陷，这就要求软件工程产品在开发过程中制定一套完善的软件工程质量标准，要做好软件工程质量保证和质量控制。软件工程质量管理对软件工程产品的开发起着不可替代的作用，因此需要采取必要的措施加强软件工程质量管理，最终保证软件工程产品的质量。
图片验证码（Captcha）问题在自动化测试中是一个很常见的问题，也是一个很棘手的问题。图片验证码设计的初衷其实就是为了防自动化，防止一些人利用自动工具恶意攻击网站，而很不幸的是，我们所使用的一些自动化测试工具也包含在内。当然了，对付验证码也不是一点办法都没有，方法还是有很多的，只是我们需要跳出技术层面去思考问题。废话少说，先来看下几种常见的解决办法：
1、识别法（技术）
识别法就是对验证码的图片进行字符识别，其原理就是通过识别算法解析图片，其解析的精准度取决于图片的复杂程度。
熟悉QTP的同学应该都知道，在做文本检查点和文本区域检查点的时候会用到一种叫OCR识别的技术，OCR的全称是Optical Character Recognition，中文叫光学字符识别。OCR指电子设备（例如扫描仪或数码相机）检查纸上打印的字符，通过检测暗、亮的模式确定其形状，然后用字符识别方法将形状翻译成计算机文字的过程；即，对文本资料进行扫描，然后对图像文件进行分析处理，获取文字及版面信息的过程。
根据本人经验，如果图片中的字符方方正正的并且图片背景比较单调的话，那么OCR识别率会非常高。比如类似于以下这种验证码的图片可以被OCR识别出来：
但是对于一些复杂的图片：字体歪歪扭扭、字体颜色和图片背景很花哨、有故意干扰的曲直线、甚至包括计算等等，如果碰到这种情况，那么OCR识别率将非常低甚至无能为力，比如：
新浪微博注册页面的验证图片
淘宝注册页面的验证图片
神级的验证图片。。。
我们可以看到，通过OCR这种技术来识别验证码图片中的字符不失为一种好的方法，但是它也有很多局限性，只适用于一些简单的图片。如果你的项目中的验证图片很复杂，果断放弃这种方法吧。
2、接口法（技术）
接口法就是让开发人员提供一个测试接口，通过这个接口可以获取到图片验证码。这种方法的具体实现又可以有很多种，比如在服务端提供一个可被客户端使用的接口，只要客户端传递过来自己的SessionID，该接口就返回此时正确的Session，这种方法就可以很容易地让自动测试工具直接获取到正确的应该提交的验证码内容；或者在网页中隐藏一个验证码内容的标签，通过读取这个网页标签内的值就可以轻松获取到验证码内容。
增加了获取验证码的接口，势必会增加非常大的安全风险，所以这种方法只适合在测试环境使用。
3、移除法（非技术）
所谓移除法非常简单，就是把图片验证码的功能去掉，这是最省力的一种方法，但是需要开发人员的配合和领导的同意。但是需要注意的一点是这种方法也只适合在测试环境使用，软件产品上线时需要把图片验证码功能还原，否则会有巨大的安全隐患。
4、暗号法（非技术）
顾名思义，暗号法就是通过事先达成的一种秘密协议进行沟通，在这里是指让开发人员提供一个“万能验证码”，不论图片如何变化，只要输入万能验证码就能通过。但是这种方式同样会产生安全隐患，如果验证码被攻击者知道的话，所以这种方法也只适合在测试环境使用。
以上是Web自动化测试中对付图片验证码问题的一些常用方法，这些方法本身都有一定优缺点和局限性，至于采取何种方式则需要结果具体的项目情况和需求进行考虑，记住，没有最好的方法，只有最适合的方法！
诊断问题是程序调试的关键，这个阶段，我们可以开始解决缺陷问题了，你可以了解看到的运行结果背后的根本原因。
真正有效的缺陷修复要求思维方式既开放又有条不紊，解决方法既创新又注重全面综合，这和软件开发的其他很多方面是一样的。
一种调试方法：提出一个可能提供解释的假设，然后再构建实验去证明你的假设，如下：
1、按照你对软件运行情况的理解，提出一个可以导致这种运行状况的假设
2、设计一个实验，证明你的假设正确与否
3、如果你设计的实验不能证明你的假设，那么重新设计一个实验，然后再次进行实验
4、如果实验支持你的假设，那么继续进行实验，直到能证明或伪证你的假设
这种方法十分有效，但却十分抽象，怎么才能把它转化为实际行动呢？
不同类型的实验：首先，你可以检查该软件内部状态的某个方面（直接运行程序，利用调试器运行等），然后你可以改变软件运行的某个方式（改变输入参数，换一个运行环境等），看它的结果是否有所不同，最后，你可以改变软件本身编码的逻辑，检查这种变化的影响。
做出什么样的选择要由你的假设的性质而定，而能否做出最佳的选择取决于你的经验和直觉，记住：你的实验必须要有一个明确的目标。
实验必须起到验证的作用：如果假设始终成立，尽了最大的努力也无法推翻它，那么可以底气十足的宣称你的假设坚不可摧。
每次只做一个修改：多个修改会导致错误的结论。此规则适用于任何可能影响软件运行的要素。
记录你所做过的调试：定期回顾你已经尝试过的实验和学到的东西。
不要忽略任何的细节：凡是你不明白的都是潜在的缺陷。
相关策略
插桩：最简单，最直接的方法，充分利用语言环境，收集和整理数据，评估任何代码，测试相关条件。
假设你正在追踪java代码中数据结构方面的错误，并依次处理各个节点：
while(node != null)
{
node.process();
node = node.getNext();
} |
会得到提示：有节点被处理了多次，但我们并不知道不止一次返回的是哪些节点，此时可以使用插桩技术解决这个问题：
HashSet processed = new HashSet();
while(node != null)
{
if(!processed.add(node))
{
System.out.printfln("The problem node is:" + node);
}
node.process();
node.getNext();
} |
我们可以使用插桩技术编写出自调试软件。
分而治之：二分法，是一种搜索策略，但是不要太依赖于这种方法，只有当你的搜索空间可以被均分成两部分时才是最有效的。
利用原代码控制工具：有时我们会陷入回归状态，即，一个缺陷本来不影响正常运行，但做了改变之后却变成了实实在在的缺陷，此时在回归跟踪时有一个特别有价值的工具——源代码控制系统。
聚焦差异：通过比对差异寻找出最有可能的问题。
向他人学习：许多缺陷只在你的代码中发生，但有时缺陷设计广泛的使用技术，这些技术可能其他人在你之前就已经遇到过，此时，你需要做的就是向他人学习。
奥卡姆剃刀：其他条件相同的情况下，最简单的解释是最好的。
调试器：在代码运行的时候对代码进行检验、设置断点、单步调试、检查程序运行状态。
为什么要使用调试器？
1、在开发过程的初期，调试器是非常有帮助的，对代码进行单步调试由助于使我们确信软件运行的结果和我们想要的实现时一致的。
2、如果我们想让代码以一种特定的方式运行，就可以使用调试器来确认或反驳这个想法。
3、最后，调试器可以帮助我们探究看不懂的代码。
然而，随着时间的推移，会发现我们使用调试器的时间越来越少，而更多的是编写一个测试程序，因为调试会话是短暂的，而测试是永久性的。测试不仅现在证明了代码是工作的，而且今后仍能证明，还能被其他的团队成员运行甚至改善。
在诊断期间有无数的方法会误导人，因此这里我们来一起看看所谓的陷阱。
你做的修改是正确的吗？如果你做的修改似乎没有任何效果，那么你并没有改到点子上，因此要在潜意识里时刻提高警惕。
验证假设：了解你正在做什么样的假设，对它们进行严格的检验。
多重原因：面临多种原因的最常见信号是一种你处于模糊状态的感觉——发生了一些似乎没有明显解释的怪事情，最富有成效的解决多原因缺陷的办法是 对问题进行隔离，并找到一个方法来重现缺陷，重现的缺陷产生的原因只依赖于多个原因中的一个，而不依赖于其他原因。另一个方法是开始先找寻同一区域内其他 较明显的缺陷，处理这些缺陷有时可以扫清障碍，让你理解得更透彻，使初始问题更加凸显。
流沙：模糊感觉产生的另一个原因是一个不断变化的基础系统。面对一个不断变化的基础系统，停下手头工作并弄清是什么在变化，为什么在变化。
调试是很艰苦的，有时简直苦不堪言，当你看不清前进的方向的时候可以试试以下的技巧：
旁观调试法：最有效的一个扫除障碍的策略就是向其他人求助，解释问题会帮助你理清思路。
角色扮演：角色扮演在解释和探讨问题时十分有用，特别在涉及那些互相独立的系统之间相互作用的问题时。
换换脑筋：让潜意识帮助自己。
做些改变：有时候，完全陷入困境之中，做些改变是十分必要的，任何改变都可以，也许它不会告诉你任何东西，但有时它会让你感到惊奇，让你惊奇的事总会教给你一些东西。
福尔摩斯原则：当你排除了一切不可能后，无论剩下什么，无论它多么不可思议，也一定是真相。
坚持：虽然有时候看起来不是这样，但实际上任何一个缺陷都是可以被诊断的。只要有足够的时间，付出足够的精力和决心，一定会解决的。
无论如何，当你诊断出了问题的所在，在进行修复之前，务必要验证诊断，可以向其他人解释你的诊断，也可以检查源代码的原始副本，尝试和他人讨论并假设自己是错误的，这样可以让你信任自己所做的诊断，也就可以开始着手进行修复了。
本章至此告一段落，一旦确诊，接下来的我们就该聊聊修复的问题了~
相关链接：
软件测试修炼之道之——重现问题
【
摘要】本文指出了
软件开发过程中质量控制的重要性，通过分析开发过程中存在的问题，提出了一些提高软件开发质量的方法的对策措施。
【关键词】软件开发；软件工程；质量控制
软件质量是指开发出来的软件不仅可以满足客户明确提出来的要求还要满足某些没有明确提出来的要求，软件质量越高，客户需求满足度就越高。软件项目质量控 制不仅仅是控制软件设计的最终结果，它其实要求贯穿于软件设计项目的全过程，从软件开发初期的客户需求调查，到最终的软件交付评审，每个阶段都要进行仔细 的控制，才能提高软件开发的质量。
一、软件开发过程的问题分析
1、不能明确分析软件的需求
软件的需求是决定软件质量的一个非常关键的因素，如果不能够准确明了的分析软件需求，就达不到软件应有的效果，从而不能真正满足客户的要求。然而软件的 需求不是显而易见的，它需要软件开发人员和客户或者业务人员之间进行充分有效地沟通和交流，使得在软件开发一开始就能够将需求提得既明确又充分，这样才能 为以后的工作打好基础，避免在一开始就偏离了软件开发的方向。在设计开发的过程中也要不断与客户进行沟通和交流，及时按照客户的意见调整软件，才能提高软件开发的质量。
2、软件开发工作不规范
由于软件质量许多指标不能量化，因此，软件开发的质量好坏也没有办法直接考核软件开发人员的责任，这样就致使软件开发人员不会很重视软件开发的质量，往 往更关心项目开发的成本和进度。此外，软件开发人员没有制定软件开发计划或者并不能按照软件开发的计划进行工作，为了赶进度经常跨阶段进行开发工作，这样 就没法保证软件开发过程的科学性和系统性，软件开发的质量也不能得到保证。软件开发管理人员和技术人员也会影响软件开发的质量。软件开发工作需要他们之间 进行频繁的沟通和交流，倘若不能及时沟通，对开发过程中出现的不同认识和误解等等问题不能及时消除，就势必会影响到软件产品的质量。此外，软件开发人员在 开发过程中一旦出现流动，就会给软件开发工作带来很大的影响，也不利于提高软件产品的质量。
二、提高软件开发质量方法和对策
1、软件产品质量控制方法
（1）软件工程方法
软件工程的基本方法就是把软件开发过程划分为若干个阶段，在每个阶段开发过程中都设置不同的目标、成本、时间等验收标准，在前一阶段工作通过验收后才能 开始下一阶段的工作，这样就会达到提高软件开发的质量的目标。软件工程将开发过程分为软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理等8个阶段，每个阶段都以软件质量控制为核心，规范每个操作流程，从而提高软件开发产品的质量。
（2）ISO9000-3标准
ISO9000系列标准原本并不能直接用于管理软件制作，而是为制造硬件产品而制定的标准。后推行的ISO9000-3标准为使软件产品达到质量要求， 要求软件开发机构建立质量保证体系，明确供需双方的职责，针对所有可能影响软件质量的各个因素都要采取有力措施，作出如何加强管理和控制的对策和措施。 ISO9000-3标准叙述了需方和供方应如何进行有组织的质量保证活动，规定了从双方签订开发合同到设计、实现以至维护整个软件生存期中应当实施的质量 保证活动，但并没有规定具体的质量管理和质量检验方法和步骤。
（3）CMM认证
CMM是一种专门针对软件产品开发及服务的高效管理方法，强调软件开发过程的不断改进和提高，在软件企业中引入CMM，有助于解决软件开发过程中质量控 制方面出现的问题。CMM不仅对软件企业工程能力进行评估，更着重于软件开发过程的管理，强调“对软件开发过程进行持续的改进”。CMM通过优化企业开发 流程，改善现有的规范、团队配合工作方法，来弥补软件企业对某个项目经理或开发工程师的单纯依赖。软件能力成熟度模型重点是从组织管理方面研究评估软件生 产过程，从而提高软件质量。
2、软件开发质量控制对策 （1）合理规划并严格按照计划执行
在进行软件开发之前首先要制定一个提高软件开发质量的保证计划，在开发过程中严格按照计划执行，不急于抢进度，保证软件开发的质量。建立文档记录需要跟踪的工作以及保证软件开发质量所需要的信息。
（2）坚持软件评审制度
坚持软件评审是保证软件质量的重要方法，软件开发过程按阶段可大致分为软件需求分析、软件设计、编码和单元测试、软件部件测试、软件验收六个阶 段。软件评审工作要贯穿于软件开发的整个过程中，在软件开发的各个阶段都要进行评审，当前软件开发阶段的工作成果达到计划要求以后才能开始下阶段的工作。 评审工作可以以会议的形式组织开展，会议要各方面人员都要参加，包括客户、软件管理人员以及软件开发人员等等，通过会议进行沟通交流，最终给出评审结果。 在每个阶段评审过程中产生的问题要尽快在本阶段解决，没有解决之前不能进入下阶段工作，这样就可以保证软件开发过程中每个阶段的工作质量都能得到提高。
（3）采用先进的软件设计技术和方法
在软件开发过程中应尽量采用先进的设计技术和方法，如面向对象和基于构件的方法，来提高软件设计产品的质量。面向对象的方法优点是能够提高软件 的重复利用性，将错误和缺憾最小化，还有利于用户的参与，能够很好的提高软件产品的质量。基于构件的开发方法又称为“即插即用编程”方法，构件可以向软件 供应商购买，也可以自行开发，而且可以重复多次使用，然后将编制好的构件插入到设计好的框架中去，从而形成一个大型的软件。如果某个构件不符合开发的要 求，可以对某个构件进行修改，不会对其他构件造成影响，也不会影响到整个系统功能。
（4）软件质量控制的关键――软件测试
在软件开发过程中，软件测试也是软件质量控制的关键，软件测试主要包括单元测试、集成测试、确认测试和系统测试。在开发的每个阶段都要通过测 试，如果测试结果与预期结果不一致，就要查找出软件中存在的问题，针对问题提出解决方案，不断改进软件质量。通过软件测试不仅可以寻找出软件中存在的与软 件客户需求不一致的错误和缺陷，还可以节省大量的时间和人力，确保软件开发的质量。开始测试之前要制定好测试计划，确定好测试的范围方法等等。在测试过程 中要做好记录，详细记录每个测试过程中的数据，而且每个阶段测试的结果都要进行存档，如果测试过程中出现错误，就要编写错误问题的报告，经过调试解决所发 现的问题以后才能进行下阶段工作。
（5）注重文档管理
目前很多软件开发商都忽视了软件开发过程中的文档管理，其实文档管理在软件开发过程中起着非常重要的作用，在软件开发的过程中建立并保存文档， 有利于软件的使用和维护，有益于软件质量的提高。文档管理要贯穿于整个软件开发的全过程，即软件在每阶段的开发、测试、评估都要保存相关的文档，这样有利 于软件的开发和维护，出现了错误有章可循，有助于软件开发质量控制。文档要提供给参与软件开发的各个小组，不仅利于软件开发过程中的交流和沟通，还可以通 过文档来控制软件开发的进度，避免赶进度、跨进度工作。在整个软件设计开发过程中，文档会不断进行生成、修改、补充完善，要做好文档的记录保存工作。
（6）客户要参与到软件开发中去
软件客户要参与到软件开发的全过程中去，在开发之初对软件的需求不是很明确的情况下，要加强与软件开发人员的沟通和交流，不断了解自身更深层次 的需求。软件开发需要多方参与，尤其是软件客户方面的人，在需求调查和分析阶段，软件客户要将自己的需求和软件开发人员进行有效地沟通，使得软件开发人员 能够最大限度的了解客户需求，才能按照需求目标开发出令客户满意的软件。在软件测试和评审阶段，客户应按照自己的需求对设计开发的软件进行检测和评审，提 出自己的意见和建议，以便在得出结论以后能够尽快及时的得到修正。软件开发人员对于客户提出的意见和建议要按照要求进行修改和完善，及早与用户进行沟通， 避免影响验收。
Team刚刚完成了一个
敏捷项目，做一下项目总结，以备以后借鉴和提高。
需求 - 沟通 – 人 - 过程 - 工具
项目要成功的最关键因素是什么？软件要快速高效又高质量的提交靠的是什么？有人说最关键是项目经理，关键是沟通，有人说是技术设计，有人说是对需求的把 握… … 从我看来，都是盲人摸象，项目要成功，软件要快速高效又高质量的提交，靠的是多重因素的整合和平衡；首先要对需求的准确理解和把握，贯穿全流程的沟通，做 项目靠人，对人/士兵的管理（物质、心理），适合组织的先进的过程（开发，测试，评审，组织，考核），还有工具的运用和整合大大提升组织效率，缺少那一样都是不行的。成功的模式只有一个，而失败却有各式各样，就是这个道理。
沟通，随时随地，全方位立体的，有效的，及时的沟通
沟通，沟通，随时随地，全方位立体的沟通。面对面、站立会议、咖啡间、IM、Email、文档、电话。上下级、跨部门、客户，沟通，直到双方的理解没有 Gap（鸿沟），没有Misunderstanding（误解）。主动沟通，有问题随时反馈。对被动的同事，主动问他。注意沟通的效率和时间表，不要一个 会议开两个小时。如果有必要，尽量让少的人参与，除非是kick-off会议。此外，沟通会影响时间表，比如你有个问题要问某人，而这个人下周开始休假 了，要早做预防。否则，吃亏的是自己。
白板，任务板，Sketch，Prototype
Team位置必须坐在一起，最好是圆圈式的座位，旁边有玻璃白板，上面画好下一个里程碑和Release的Roadmap，玻璃白板便于马上沟通。任务 板便于大家清楚当前致力的目标和Release。对于Sketch要用好，在产品或者功能还没有做出来以前，先把Sketch或者Prototype发给 客户看一下是否认可，获得用好Remarks，然后再开始动手；毕竟动手了再修改代价就更大了。所以一定要用好Sketch草图。
Stand up meeting要不要
很多人说到Scrum就要每日晨会Stand Up Meeting，但我们Team的实践来看，并不是必须的，其实敏捷也是根据组织和项目实际情况因人而异的（有人说敏捷对结对开发人员的能力要求很高，我 觉得敏捷是一种境界，良好的架构，代码规范，成员间非常好的默契，才能敏捷的起来）。不能拘泥于形式主义，我主张实用主义。现在不是有反敏捷、有瀑布敏捷 （Water-Scrum-Fall）、实用敏捷吗？关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开 发流程，而只是依葫芦画瓢学个一招半式，那就真的不是敏捷了。我听到有人说，敏捷只适用于产品型公司和小型项目，还有人说敏捷只适合于需求不稳定的项目， 还有人说敏捷了就等于速度快，就等于客户报价可以低一些，还有人说敏捷说的什么迭代持续集成和重构都是理论，没有考虑到实际执行起来的风险……都没有错， 关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开发流程，而只是依葫芦画瓢学个一招半式，在这儿讨论， 说白了还是理论，坐而论道不如起而行，所以积极实践，加深对敏捷内涵的深刻理解，寻找适合自己组织的最佳敏捷实践方法才是良策。这样子思想理顺了，我们就 不会拘泥于Stand Up Meeting到底要不要的问题了。
保证代码质量
如何获得高代码质量？打个比方，现在要打仗了，如何打个漂亮的胜仗。我想你肯定知道答案了。那就是你的队伍必须各个是精兵，能力强，平时训练有素，而且还有实战经验，这样的一个兵强马壮的精兵队伍你拉出去，只要指挥好，士气高，就能打漂亮的胜仗。OK，现在你明白了，软件开发何不如此？你手下的程序员是不是技术能力很强，是不是平时就对技术研究很深，对某科技术有很深的理解，还有很多项目经验，是不是干劲十足，是不是对他们做了培训，是不是做了编程规范的要求，都明白了命名规范、异常处理、日志处理、安全性、用户权限、配置文件、设计模式、线程安全、单元测试、调试技巧、条件编译等项目标准处理；如果还没有这些标准的贯彻，那你的士兵还需要培训（训练），这样子上战场会很危险。当然，有个变通办法，让资深程序员带小弟，小弟在一边看着，下个项目备用。当然。除了培训以外，分享、知识库都是团队很重要的机制。
基础不扎实的程序员代码质量不会高起来，比如有的C#程序员根本理解Task.Factory.StartNew这句话是异步执行的线程池起线程，就把 它放到同步的循环里面，导致问题。再比如，有的程序员用匿名函数，不懂闭包，导致放在循环里面每次取到的都是最后一个值。再比如有的程序员不深刻理解 Session，就认为浏览器关了Session就没有了。再比如有的C#程序员不理解GC以为一个类只要实现了IDisposable接口就一定会内存 释放……举不胜举，都是项目中遇到过的（注：对基础不扎实的程序员进行代码Review管用吗？我们项目实践来看不管用，因为资深程序员很忙，不可能一行 一行去看去调试。）……所以，优秀的程序员都是建立在对该技术的深入理解的基础上的。优秀的成熟的程序员员工都有专业化（技术方面）、职业化（服务意识、 协作能力、解决问题的能力和态度）和商业化（替客户思考和解决问题）多方面的优秀特质，才能真正的为业务创造价值。
保证代码质量的另外一个非常重要的方面就是测试，一定要写单元测试，使用Moq做单元测试。这可以培养程序员面向接口的思维方式，如果代码不能做单元测试往往是耦合度很高的代码，所以单元测试能发现代码质量的问题。此外，测试组的工作要及早介入，对业务的深刻理解，重复利用bug管理工具，敏捷测试。
为需求变化和维护早作准备 在系统设计的时候，要考虑到未来可能的需求变化，做好面向变化的架构设计。但不要过度设计。（这需要深入理解商业需求）
为维护早作准备，意思是说，在编码阶段，就要考虑到系统的可维护性，设想你自己就是将来维护这个系统和这段代码的人，这种意识很重要。有的程序 员以为系统提交了上线了就没他的事情了，结果到头来上线了出现问题，系统又没有很好的log和trace，导致问题极难线上调试，而线下又不能模拟真实的 环境，这种情况下必须为维护而设计，提升系统的可维护性、可追溯性、可管理性。
不要过度设计和过早优化
过度设计是敏捷开发应该避免的，很多工程师都有过度设计的冲动。例如，在一个web系统还没有看到被大规模使用的曙光以前，就设计了系统规模 化，什么集群、负载均衡、读写分离、分布式缓存系统……说真的，这些东西确实是好东西，但也很贵。在系统还没有被大规模的用户接受和喜爱之前，这样做是否 会抵消了我们把专注点放在核心功能和简练和简单的努力呢？时间是有限的，投资也是有限的。我们必须把有限的时间和有限的金钱用在当前最核心的功能和体验 上。有时候系统初期，可能一两台服务器就足够了。只有在看到产品有被大规模使用和用户喜爱的曙光之后，才来增加功能和规模量。当然，你的网站功能，在你只 有 10 万用户的时候，可能和你有 1 亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。系统架构需要及早规划，但不要提前实施和过早优 化。
关注非功能性需求
也许大多数客户和咨询师也会听说过神马TDD、迭代、原型、持续集成和持续部署、Agile等时髦的词语，这些也让管理者很兴奋，以为软件产品 是可以在很短的时间内高质量的完成的，即使完不成也可以在后面用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。这听起来好像很 美好。但其中有个很大的陷阱，那就是客户和咨询师，还有原型、TDD大都只关注功能性需求，而忽略了非功能性需求，比如性能问题，高可用性问题，系统维护 问题（模块的耦合问题），等等。客户和咨询师在项目前期闭口不提这些或很少提及，但一旦功能性需求都做完了他们就会抱怨这些隐藏的非功能性需求。而像性能 问题，高可用性问题，系统维护问题（模块的耦合问题）等并不是很容易重构，往往涉及到Re-design， re-architect；因此这些问题往往都在后期会成为重构噩梦，甚至可以让你的软件设计重新来过！更加糟糕的是，大多数客户不愿意为这些隐藏的功能 重构而付钱。笔者曾经遇到过前期只注重功能性需求而后期发现性能不好而进行re-design， re-architect，这对项目管理来说有很大的挑战，因为不单单是程序和架构重构的困难，还要面对时间和人力成本的增加，最难的是你还要面对的是团 队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。这是一个很大的陷阱。
所以，前期就要关注非功能性需求，不要急于动手，如果你能有多一些时间去和客户讨论一下需求和未来可能的变化，去调查一下实现的技术难点和细 节，去和其他有经验的人讨论并推敲一下架构和设计，去思考设计上的缺陷，那么，你的coding会变得非常地直，直到你一眼就看到尽头，你的测试案例也会 写得非常地好，你会几乎不需要重构，于是，你会在未来少写很多代码，从而你的软件开发会越来越轻松，直到技术开始换代。这就好像我们修路造桥一样，我们需 要花大量的时间勘测地形地质，分析数据，思考可能出现的各种问题（各种自然灾害），评估不同的设计方案，而不是先尽快建好再说。（：磨刀不误砍柴工） 说到这里，有些反敏捷（反Scrum），没错，好的程序员要会做权衡/平衡，好的架构师要会做平衡，好的项目经理也要会做平衡，这非常重要。
再补充一点，有资深经验的工程师/架构师对非功能性需求的设计和平衡很有经验，这些经验对系统设计和项目成功至关重要。如果你很不幸，手头没有 这些有经验有价值的人，而只有一堆码农，那么恭喜你，你可以在一张白纸上画画了。就开发他们的潜力吧，做好这个项目给他们积累经验的心理准备吧，量力而行 吧，小马过河吧……实在不行你就自己上吧，毕竟公司要求用最少的钱在最短的时间内出来最优秀的东西；如果你有话语权，那就把你的困难及早让上层知晓。
严格控制需求和范围，和进度权衡，不出现资源空闲
领导一般会给项目经理压力，要求在什么时间提交一个版本赶进度等，这时候项目经理要么能调整一些需求和范围（Scope），要么就把可能出现的 问题进行报忧，因为现在如果不这样做，你就等着现在报喜，后期报忧吧。所以项目经理一定要严格控制需求和范围（scope），和进度，和质量权衡。同时要 合理调配资源，不要出现项目进行中资源空闲的情况（这个在Project工具中可以看出）。
项目风险管控
项目经理要有项目风险管控能力，及时在项目进行的各个阶段进行风险的预识别和管理。项目一般是前期工期松，风险低；而后期工期紧，风险高。所以 项目经理要尽可能在项目早期能列出大部分的风险，这样在项目的风险应该是倒三角形状的，就是前期风险多，后期风险少。要预先把下阶段可能的风险明确告诉客 户，让客户提供帮助来控制风险的发生，同时迫使客户加强风险意识，不让需求任意扩散和蔓延。在各个阶段都要有双方风险认知的会议纪要记录。一般情况下，项 目的外部依赖条件是最不可管控的风险（比如要和第三方联调，要第三方提供API等）。其次是需求的不明确和需求蔓延的风险（需求问题占项目成功的40%因 素以上，你能控制需求，你就成功60%了）。然后还有资源的可用性（如：项目进行中核心人员流失，要知道项目进行中间换人和加人都很是问题）。
资源提供者和问题解决者
大家都知道，打仗的时候什么最重要？对了，补给（后勤保障）。士兵上战场了，谁做后勤？项目经理。每天都要问大家，你下一步需要什么，你还缺什 么输入？你有什么问题需要我这边配合的？程序员旁边有垃圾了，项目经理去扫一下地，这就是后勤补给。所以管理者首先要理顺管理者和人的关系，调整好服务的 意识，做好资源源源不断的提供、帮助大家解决问题，系统就有了润滑剂，有了源源不断的输入，就能顺畅的开展。否则，千里马到你手里也跑不快的。
管理用户期望
对每一个Sprint提交，谨慎选择功能集合，多和客户沟通，管理好用户期望，他下一阶段希望有什么功能，这些功能的优先级如何，实现难度如何，及早告诉他下一个版本会友什么，不会有什么。
增加团队成员之间的亲密感
有时候如果一个团队成员里面有多个牛人，大家都是很有主见的人，就很容易在一些问题上争执，甚至产生内部竞争。两个聪明人意见采取谁的呢？紧张 关系在所难免。这种纠结的合作和竞争关系是同事关系的主线。但要保持合作为重点。所以，要把这样的状况保持在一个健康的状态，需要加深团队成员的亲密感。 具体来说，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加亲密感的方法，这样拉近人与人的距离，就不会觉得有什么竞争的紧张感了。
管理团队目标和情绪
Scrum有一个优点就是短周期快速迭代，每周大家都有明确的目标，因为Release周期很短，大家Vision很明确，所以为什么 Sprint就是冲刺的意思。管理好团队的目标、Vision，有明确的目标，有冲刺的干劲。及时发现团队的情绪波动，采取应对措施（休整，腐败，激 励）。
保持耐心，不断调整
技术上要重构，架构改进和提炼等。信任程序员，给他们时间来重构，来调整和优化架构等。管理上要重构，代码促进委员会，评审组等等。改进适合组 织规模和业务发展的流程，目标是获得持续、快速、更好质量的交付产品和更好的客户满意度、更低的成本和更高的效率。总之，要不断努力，不断调整，不断尝试 新的方法，做的越来越好。要保持耐心，给员工/系统的成长/成熟一点信任和时间。
项目经理的人格魅力和以德服人
作为项目经理您必须与同事以团队合作方式才能保证项目的顺利完成，如何鼓舞团队成员的士气？让大家心甘情愿的与你朝着共同的目标努力。要做到这 一点，人格魅力非常重要。但要让大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主动配合你的工作，但是你自己如果没有首先要求自己主动配合 大家，你就不会赢得大家的尊重。这只是一个例子而已，很多点滴细微之处会让大家感觉到你的人格魅力，究竟是一个值得尊敬的人，还是一个不值得尊敬的、自我 的、高高在上的发布命令者。总之，做人是最要紧的，做人没做好，做事肯定做不好了，项目多半要搞砸。
但就项目经理的项目管理能力来说，也关系到项目的成败，比如能否引导客户需求、对问题的透彻理解、对复杂的任务紧密跟踪并设定轻重缓急、利用各 种渠道和方法来沟通解决问题、有能力做出适当的取舍、说服客户或领导的能力、推销自己解决方案的能力、突破性格制约的沟通技巧、面向全局思考的思维方式、 如何合理动态分配大家的工作项使不被Block住……
总结
先写这么多吧，想到了再补充。
一般都说
测试先做
单元测试，然后做集成测试，然后做
系统测试之类的，其实说白了，也可以理解成将最基本的测试步骤，或者说测试环境使用一定的方法组合以后再生成新的
测试用例。因为人工组合，第一比较费神，第二是有时要么是设计了几个等价的测试用例，重复执行这些等价的测试用例，比较费时。这里有一个比较好的测试技术，叫做配对（pair-wise）测试，它可以根据你设定的条件，自动生成在测试时间（即
工作量）和测试覆盖率之间做出平衡的组合。
配对测试的基本理念是，虽然程序的某个组件，或者程序自己会接受很多的输入，但大部分情况下，程序的bug不是因为这些输入同时作用而产生的，而是由一 到两个输入条件同时作用导致的。因此配对测试在生成测试组合的时候，主要关注将每个条件与其它条件至少配对一次，而不是试图生成全组合，这样就可以大大减 少需要测试的组合数，尽而节省测试工作量，同时又能达到满意的测试覆盖率。
当然不能期望配对测试是万能的，即我们仅依赖于配对测试自动生成的测试用例就可以了，使用配对测试的目的是为了减少测试人员浪费在执行太多的等价组合的时间，将宝贵的时间尽可能地放在设计符合用户使用场景的测试用例上。
具体示例（手工步骤）
废话少说，先看一个具体的示例，假设我们有下面一个产品，界面如下：
对于上面这个产品（假设文本框接受1到100之间的整数），可以将测试条件划分为下面这样子：
当然，文本框的条件我们还可以再细分一下，但是为了描述简单，我把条件设置的比较粗糙，如果按照全组合的用例设置方式，需要 6 (下拉框控件可能的条件) * 2 (复选框可能的条件) * 2 (单选框可能的条件) * 6 (文本框可能的条件) = 144个组合。
我们来看使用配对方式设计组合的方式：
1、先将上面的条件输入到Excel里，并在列头标明可能出现的条件的个数，并按条件的个数将各个输入参数排序，如下图所示：
2、先将第二个和第三个参数的各个条件组合一次，这里为了省事起见，我先去掉第一个参数，只介绍第二、三、四个参数的配对组合方法：
3、然后再将第二个参数和第四个参数的各个条件组合一次，如下图所示：
4、为了确保第四个参数跟第三个参数的各个条件都有一次组合，可以使用Excel提供的过滤功能来判断，例如下图中，很明显，两个参数没有一个完全组合：
5、解决方案很简单，只需要再添加两行，将两个参数中没有组合的条件各自组合一次好了（当然，你也可以将第四个参数的条件稍微调整一下达到相同的目的）：
自动化步骤
上面的工作还是有点繁琐，实际上早已有人将这个过程自动化了，这里介绍一个免费开源的工具allpairs.exe，请于下面这个链接里下载：http://www.satisfice.com/tools/pairs.zip
对于上面的例子，使用allpairs生成组合的方式是：
1、先将上面的条件输入到Excel里，如下图所示（因为这个工具是老外写得，没有考虑支持中文的问题，所以最好全部用英文表示）：
2、将Excel文件保存为以Tab键作为分隔符的文本文件：
3、然后使用allpairs.exe处理这个文件：
allpairs.exe test.txt > output.txt
4、在output.txt里，PAIRING DETAILS下面的东西都是没有用的，可以直接删掉，删掉以后，结果如下：
你可以在设计测试环境矩阵还有组合测试用例的时候使用allpairs这个技术，当然，你不能完全依赖这个技术，除了allpairs组合的测试用例以外，你最好再根据测试覆盖率和用户场景覆盖率入手，补充更有价值的测试用例。
另外，使用配对测试的算法，我们有可能结合Behavior Driven Design技术，直接从需求自动生成测试用例，加之如果我们将基本的测试用例自动化以后，完全可以使用这个技术将自动化过的测试用例配对组合（当然需要 加上一些限制条件），在节省测试时间的同时，达到满意的测试覆盖率，当然，这样做要求我们自己写一个测试工具来实现这个技术—至少到现在我还没有看到现成 的工具，而且这个技术应该要比模型驱动测试更容易使用，因为模型驱动测试的问题是建模太困难。
春节刚刚过去，也是各大公司开始抢人的时刻。最近帮忙准备几个自动化相关的题目，以前参加
面试的时候总被问到些奇怪的问题，所以我出题本着开放的原则，题目本身没有什么答案，要的是你能说服我，或者让我知道你比较关注于技术圈子的事情。知识面我觉得很重要，呵呵…
1、如何理解自动化测试，用测试工具进行测试等于自动化测试这句话对不对？
关注点：测试工具的使用是自动化测试的一部分工作， 但“用测试工具进行测试”不等于“自动化测试”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的 测试脚本自动地测试软件。 自动化测试，强调借助工具（不仅仅是工具，有时包括策略和工件）来完成测试的执行，也就是用工具来帮助或辅助测试。但是用测试工具进行测试有可能是自动 化，半自动化，或者手工测试。
2、介绍下比较了解的自动化框架，watir，selenium，QTP…..任选一个说说，这个框架的工作原理是什么？
随便选取一个，重要的是原理，而不是使用。大家在用这些框架的时候，一定要关注背后的执行原理.看源码是一个比较简单的途径。
3、介绍下SoapUI，如果你用着的话。这个框架需要注意什么？
soapUI是一款桌面应用程序，能够监测、触发、模仿以及测试（功能和负载）基于SOAP/WSDL和REST/EADL的HTTP网络服务。
和大多数的工具一样，都是使用HTTPREQUEST对相应的资源进行请求很提取。再得到response之后进行相应的处理，对XML进行XPATH 定位。注意的是SOAP方法中包含GET，POST的方法，POST的方法主要使用Application/xml的MIME形式发送相应的POST数 据。
4、对webservice层面的自动化测试，你认为比较重要的是什么？
对webservice的测试主要分为两个阶段，首先是对WEB Ui层面的数据XML Response与webservice的schema进行对比测试，其次是web Ui层面的数据与数据库服务器中相应的数据进行验证。
5、对持续集成工具有了解过吗？类似于Jenkins（hudsoon）/Bamboo/Teamcity这些持续集成的工具，有了解过这些吗？
目前比较这几个还算比较流行，阿里主要集中在用hudson。Teamcity在以前的公司了解过。
6、桌面自动化测试和WEB 自动化测试的区别？
驱动方式不同，C/S架构（或者桌面类型）界面自动化测试，采取的方式可以调用操作系统本身的API（windows桌面软件）来构建自动化测试或者可以采用虚拟机内（java swing程序）的事件处理机制来完成了。
WEB 自动化测试 B/S架构，原理就是依靠JS来进行客户端的操作，然后寻找对象是采用了DOM解析技术，将web方面的节点进行解析定位
7、自动化测试碰到比较难解决的问题是什么？如果出现这些问题给出你的解决方案？
重点引导到测试结果定位准确这个角度上来， 在自动化程度比较高，case很多，就会存在排查失败的case过程。
解决方案； case错误分类，有效的log日志，异常信息的抓取
8、IOS支持UI自动化，主要有2种方式，介绍下这2种方式？
1）苹果官方提供的技术， UI Automation。
2）就是在应用中注入测试代码。
Instrument uiautomation 是苹果官方提供的iPhone手机应用的自动化测试工具。控件元素的识别准确，属性获取，元素操作的API丰富。可以很方便的录制测试脚本、回放和查看运行结果。
本文地址：http://www.wangyuxiong.com/archives/51901
所有的TCP/IP调优参数都位于/proc/sys/net/目录。例如，下面是最重要的一些调优参数，后面是它们的含义：
1、/proc/sys/net/core/rmem_max — 最大的TCP数据接收缓冲
2、/proc/sys/net/core/wmem_max — 最大的TCP数据发送缓冲
3、/proc/sys/net/ipv4/tcp_timestamps — 时间戳在(请参考RFC 1323)TCP的包头增加12个字节
4、/proc/sys/net/ipv4/tcp_sack — 有选择的应答
5、/proc/sys/net/ipv4/tcp_window_scaling — 支持更大的TCP窗口. 如果TCP窗口最大超过65535(64K), 必须设置该数值为1
6、rmem_default — 默认的接收窗口大小
7、rmem_max — 接收窗口的最大大小
8、wmem_default — 默认的发送窗口大小
9. wmem_max — 发送窗口的最大大小 |
/proc目录下的所有内容都是临时性的，所以重启动系统后任何修改都会丢失.
建议在系统启动时自动修改TCP/IP参数：
把下面代码增加到/etc/rc.local文件，然后保存文件，系统重新引导的时候会自动修改下面的TCP/IP参数：
echo 256960 > /proc/sys/net/core/rmem_default
echo 256960 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_default
echo 256960 > /proc/sys/net/core/wmem_max
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling |
TCP/IP参数都是自解释的，TCP窗口大小设置为256960，禁止TCP的时间戳（取消在每个数据包的头中增加12字节），支持更大的TCP窗口和TCP有选择的应答。
上面数值的设定是根据互连网连接和最大带宽/延迟率来决定。
注：上面实例中的数值可以实际应用， 但它只包含了一部分参数。
另外一个方法：使用 /etc/sysctl。conf 在系统启动时将参数配置成您所设置的值：
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack =1
net.ipv4.tcp_window_scaling = 1 |
----------------------------------------------------------------
该文件指定超级块处理程序的最大数目。挂装的任何文件系统需要使用超级块，所以如果挂装了大量文件系统，则可能会用尽超级块处理程序。
缺省设置：256
该文件显示当前已分配超级块的数目。该文件是只读的，仅用于显示信息。
/proc/sys/kernel
/proc/sys/kernel/acct |
该文件有三个可配置值，根据包含日志的文件系统上可用空间的数量（以百分比表示），这些值控制何时开始进行进程记帐：
● 如果可用空间低于这个百分比值，则停止进程记帐
● 如果可用空间高于这个百分比值，则开始进程记帐
● 检查上面两个值的频率（以秒为单位）
● 要更改这个文件的某个值，应该回送用空格分隔开的一串数字。
缺省设置：2 4 30
如果包含日志的文件系统上只有少于 2% 的可用空间，则这些值会使记帐停止，如果有 4% 或更多可用空间，则再次启动记帐。每 30 秒做一次检查。
| /proc/sys/kernel/ctrl-alt-del |
该文件有一个二进制值，该值控制系统在接收到 ctrl+alt+delete 按键组合时如何反应。这两个值表示：
● 零(0)值表示捕获 ctrl+alt+delete，并将其送至 init 程序。这将允许系统可以完美地关闭和重启，就好象您输入 shutdown 命令一样。
● 壹(1)值表示不捕获 ctrl+alt+delete，将执行非干净的关闭，就好象直接关闭电源一样。
缺省设置：0
| /proc/sys/kernel/domainname |
该文件允许您配置网络域名。它没有缺省值，也许已经设置了域名，也许没有设置。
| /proc/sys/kernel/hostname |
该文件允许您配置网络主机名。它没有缺省值，也许已经设置了主机名，也许没有设置。
该文件指定了从一个进程发送到另一个进程的消息的最大长度。进程间的消息传递是在内核的内存中进行，不会交换到磁盘上，所以如果增加该值，则将增加操作系统所使用的内存数量。
缺省设置：8192
该文件指定在一个消息队列中最大的字节数。
缺省设置：16384
该文件指定消息队列标识的最大数目。
缺省设置：16
该文件表示如果发生“内核严重错误(kernel panic)”，则内核在重新引导之前等待的时间(以秒为单位)。零(0)秒设置在发生内核严重错误时将禁止重新引导。
缺省设置：0
该文件有四个数字值，它们根据日志记录消息的重要性，定义将其发送到何处。关于不同日志级别的更多信息，请阅读 syslog（2） 联机帮助页。该文件的四个值为：
● 控制台日志级别：优先级高于该值的消息将被打印至控制台
● 缺省的消息日志级别：将用该优先级来打印没有优先级的消息
● 最低的控制台日志级别：控制台日志级别可被设置的最小值（最高优先级）
● 缺省的控制台日志级别：控制台日志级别的缺省值
缺省设置：6 4 1 7
该文件是在任何给定时刻系统上可以使用的共享内存的总量(以字节为单位)。
缺省设置：2097152
该文件指定内核所允许的最大共享内存段的大小(以字节为单位)。
缺省设置：33554432
/proc/sys/kernel/shmmni
该文件表示用于整个系统共享内存段的最大数目。
缺省设置：4096
如果该文件指定的值为非零，则激活 System Request Key。
缺省设置：0
| /proc/sys/kernel/threads-max |
该文件指定内核所能使用的线程的最大数目。
缺省设置：2048
/proc/sys/net
/proc/sys/net/core/message_burst |
写新的警告消息所需的时间(以 1/10 秒为单位)；在这个时间内所接收到的其它警告消息会被丢弃。这用于防止某些企图用消息“淹没”您系统的人所使用的拒绝服务(Denial of Service)攻击。
缺省设置：50(5 秒)
| /proc/sys/net/core/message_cost |
该文件存有与每个警告消息相关的成本值。该值越大，越有可能忽略警告消息。
缺省设置：5
| /proc/sys/net/core/netdev_max_backlog |
该文件指定了，在接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
缺省设置：300
| /proc/sys/net/core/optmem_max |
该文件指定了每个套接字所允许的最大缓冲区的大小。
| /proc/sys/net/core/rmem_default |
该文件指定了接收套接字缓冲区大小的缺省值（以字节为单位）。
| /proc/sys/net/core/rmem_max |
该文件指定了接收套接字缓冲区大小的最大值（以字节为单位）。
| /proc/sys/net/core/wmem_default |
该文件指定了发送套接字缓冲区大小的缺省值（以字节为单位）。
| /proc/sys/net/core/wmem_max |
该文件指定了发送套接字缓冲区大小的最大值（以字节为单位）。
所有 IPv4 和 IPv6 的参数都被记录在内核源代码文档中。请参阅文件 /usr/src/linux/Documentation/networking/ip-sysctl.txt。
同 IPv4。
/proc/sys/vm
/proc/sys/vm/buffermem
该文件控制用于缓冲区内存的整个系统内存的数量（以百分比表示）。它有三个值，通过把用空格相隔的一串数字写入该文件来设置这三个值。
用于缓冲区的内存的最低百分比
如果发生所剩系统内存不多，而且系统内存正在减少这种情况，系统将试图维护缓冲区内存的数量。
用于缓冲区的内存的最高百分比
缺省设置：2 10 60
该文件控制系统如何应对各种级别的可用内存。它有三个值，通过把用空格相隔的一串数字写入该文件来设置这三个值。
● 如果系统中可用页面的数目达到了最低限制，则只允许内核分配一些内存。
● 如果系统中可用页面的数目低于这一限制，则内核将以较积极的方式启动交换，以释放内存，从而维持系统性能。
● 内核将试图保持这个数量的系统内存可用。低于这个值将启动内核交换。
缺省设置：512 768 1024
该文件控制允许内核如何交换内存。它有三个值，通过把用空格相隔的一串数字写入该文件来设置这三个值：
● 内核试图一次释放的最大页面数目。如果想增加内存交换过程中的带宽，则需要增加该值。
● 内核在每次交换中试图释放页面的最少次数。
● 内核在一次交换中所写页面的数目。这对系统性能影响最大。这个值越大，交换的数据越多，花在磁盘寻道上的时间越少。然而，这个值太大会因“淹没”请求队列而反过来影响系统性能。
缺省设置：512 32 8
该文件与 /proc/sys/vm/buffermem 的工作内容一样，但它是针对文件的内存映射和一般高速缓存。
使内核设置具有持久性
这里提供了一个方便的实用程序，用于更改 /proc/sys 目录下的任何内核参数。它使您可以更改运行中的内核(类似于上面用到的 echo 和重定向方法)，但它还有一个在系统引导时执行的配置文件。这使您可以更改运行中的内核，并将这些更改添加到配置文件，以便于在系统重新引导之后，这些更 改仍然生效。
该实用程序称为 sysctl，在 sysctl(8) 的联机帮助页中，对这个实用程序进行了完整的文档说明。sysctl 的配置文件是 /etc/sysctl.conf，可以编辑该文件，并在 sysctl.conf(8) 下记录了该文件。sysctl 将 /proc/sys 下的文件视为可以更改的单个变量。所以，以 /proc/sys 下的文件 /proc/sys/fs/file-max 为例，它表示系统中所允许的文件句柄的最大数目，这个文件被表示成 fs.file-max。
这个示例揭示了 sysctl 表示法中的一些奇妙事情。由于 sysctl 只能更改 /proc/sys 目录下的变量，并且人们始终认为变量是在这个目录下，因此省略了变量名的那一部分(/proc/sys)。另一个要说明的更改是，将目录分隔符(正斜杠 /)换成了英文中的句号(点 .)。
将 /proc/sys 中的文件转换成 sysctl 中的变量有两个简单的规则：
● 去掉前面部分 /proc/sys。
● 将文件名中的正斜杠变为点。
这两条规则使您能将 /proc/sys 中的任一文件名转换成 sysctl 中的任一变量名。一般文件到变量的转换为：
/proc/sys/dir/file --> dir.file
dir1.dir2.file --> /proc/sys/dir1/dir2/file |
可以使用命令 sysctl -a 查看所有可以更改的变量和其当前设置。
用 sysctl 还可以更改变量，它所做的工作与上面所用的 echo 方法完全一样。其表示法为：
| sysctl -w dir.file="value" |
还是用 file-max 作为示例，使用下面两种方法中的一种将该值更改为 16384。
区别和联系
Linux和UNIX的最大的区别是，前者是开发源代码的自由软件，而后者是对源代码实行知识产权保护的传统商业软件。这应该是他们最大的不同，这种不同体现在用户对前者有很高的自主权，而对后者却只能去被动的适应；这种不同还表现在前者的开发是处在一个完全开放的环境之中，而后者的开发完全是处在一个黑箱之中，只有相关的开发人员才能够接触的产品的原型。
Linux 的源头要追溯到最古老的UNIX。1969年，Bell实验室的Ken Thompson开始利用一台闲置的 PDP-7计算机开发了一种多用户，多任务操作系统。很快，Dennis Richie加入了这个项目，在他们共同努力下诞生了最早的UNIX。Richie受一个更早的项目——MULTICS的启发，将此操作系统命名为 Unix。早期UNIX是用汇编语言编写的，但其第三个版本用一种崭新的编程语言C重新设计了。C是Richie设计出来并用于编写操作系统的程序语言。通过这次重新编写，Unix得以移植到更为强大的 DEC PDP-11/45与11/70计算机上运行。后来发生的一切，正如他们所说，已经成为历史。Unix从实验室走出来并成为了操作系统的主流，现在几乎每个主要的计算机厂商都有其自有版本的Unix.
Linux起源于一个学生的简单需求。Linus Torvalds，Linux的作者与主要维护者，在其上大学时所买得起的唯一软件是Minix. Minix是一个类似Unix，被广泛用来辅助教学的简单操作系统。Linus 对Minix不是很满意，于是决定自己编写软件。他以学生时代熟悉的Unix作为原型， 在一台Intel 386 PC上开始了他的工作。他的进展很快，受工作成绩的鼓舞，他将这项成果通过互连网与其他同学共享，主要用于学术领域。有人看到了这个软件并开始分发。每当出现新问题时，有人会立刻找到解决办法并加入其中，很快的， Linux成为了一个操作系统。值得注意的是Linux并没有包括Unix源码。它是按照公开的POSIX标准重新编写的。Linux大量使用了由麻省剑桥自由软件基金的GNU软件，同时Linux自身也是用它们构造而成。
另外两大区别：
1）UNIX系统大多是与硬件配套的，而Linux则可运行在多种硬件平台上。
2）UNIX是商业软件，而Linux是自由软件，免费、公开源代码的。
UNIX（5万美圆）而Linux免费
[历史]
Unix的历史久于linux. Linux的思想源于Unix
[产品]
unix和linux都是操作系统的名称．但unix这四个字母除了是操作系统名称外，还作为商标归SCO所有。
Linux商业化的有RedHat Linux 、SuSe Linux、slakeware Linux、国内的红旗等，还有Turbo Linux。
Unix主要有Sun 的Solaris、IBM的AIX， HP的HP-UX，以及x86平台的的SCO Unix/Unixware
[其他区别]
linux的核心是免费的，自由使用的，核心源代码是开放的．而unix的核心并不公开；
在对硬件的要求上，linux比unix要低，没有unix那么苛刻．在安装上linux比unix容易掌握。
在使用上，linux相对没有unix那么复杂。
Unix多数是硬件厂商针对自己的硬件平台的操作系统，主要与CPU等有关，如Sun 的Solaris作为商用，定位在其使用SPARC/SPARCII的CPU的工作站及服务器上，当然Solaris也有x86的版本，而Linux也有其于RISC的版本。但确切的讲，拿RISC上的Unix与x86上的Linux进行比较不太合适。至于价格，个人使用的Linux基本上算是免费的，不同的Linux发行厂商针对企业级应用在基本的系统上有些优化，如RedHat的Enterprise产品，这些产品包括支持服务是比较贵的。像IBM/HP/SUN的Unix，因为主要是针对其硬件平台，所以操作系统通常在设备价格中。（没有人单独去买一个Unix操作系统的）
在性能上，linux没有unix那么全面，但基本上对个人用户和小型应用来说是绰绰有余。
通常情况下，如果你有机会使用到Unix环境，比如银行、电信部门，那一般都是固定机型的Unix。比如电信里SUN的居多，民航里HP的居多，银行里IBM的居多。学习中，不同的Unix命令集有些不同，要注意。至于学习，我看还是linux比较好学一点，而且现在喜欢和鼓捣linux的人也越来越多，各种有关linux的资料也很多．如果是自己想学习，那Linux或是BSD系统是不错的选择。一台x86的机器就可以。
在应用上，除非是大型网站，一般企业或个人，使用Linux即可。
UNIX是一个功能强大、性能全面的多用户、多任务操作系统，可以应用从巨型计算机到普通PC机等多种不同的平台上，是应用面最广、影响力最大的操作系统。
Linux是一种外观和性能与UNIX相同或更好的操作系统，但，Linux不源于任何版本的UNIX的源代码，并不是UNIX，而是一个类似于UNIX的产品。Linux产品成功的模仿了UNIX系统和功能，具体讲Linux是一套兼容于System V以及BSD UNIX的操作系统，对于System V来说，目前把软件程序源代码拿到Linux底下重新编译之后就可以运行，而对于BSD UNIX来说它的可执行文件可以直接在Linux环境下运行。
一般来说，Linux是一套遵从POSIX（可移植操作系统环境）规范的一个操作系统，它能够在普通PC计算机上实现全部的UNIX特性，具有多任务、多用户的能力。Linux受到广大计算机爱好者的喜爱的另一个主要原因是，它具有UNIX的全部功能，任何使用UNIX操作系统或想要学习UNIX操作系统的人都可以从Linux中获益。
在网络管理能力和安全方面，使用过Linux的人都承认Linux与UNIX很相似。
UNIX系统一直被用做高端应用或服务器系统，因此拥有一套完善的网络管理机制和规则， Linux沿用了这些出色的规则，使网络的可配置能力很强，为系统管理提供了极大的灵活性。
在软件开发过程中，写出影响性能或者有BUG的代码，都是我们无法回避的现实问题。
不过，如果能够在程序发布前（自测或者测试阶段）将这些问题找出来，我想大家都是可接受的。
今天就来介绍一种方法，用来发现在网站开发过程中，容易被我们忽略的一些问题，而这些问题其实是容易被发现的。
将要介绍的方法需要使用Fiddler这样一款工具，我将演示如何使用Fiddler来发现404错误，以及较大的响应输出问题。
我认为这二个问题实在太低级了，所以我设计了这个方法，并写了这篇博客，希望大家能喜欢。
我发现，许多人对于这二类问题（404错误和较大的响应输出）都很不在意，好像它们根本不会对一个网站有任何影响似的。
难道真是这样吗？
我认为：如果你做的网站程序，用户访问量很小，或许的确可以忽略它们。
否则，我还是建议你应该纠正它们，下面我来解释它们的危害。
404错误
我一直认为404不仅仅只是一个数字，过多的404也会影响程序的性能。
通过对404错误的分析，我发现多数的404错误都与一些资源文件的引用有关，比如代码中引用了不存在CSS或者JS文件，这些404错误发生时，可能并不会影响页面的正常显示，因此，这类错误根本就不会引起一些开发人员的注意。
再加上，许多人又喜欢复制粘贴，导致这类错误越来越多。
为什么我会说【过多的404错误也会影响性能】呢？
因为当404错误产生时，IIS其实并不只是返回这样一个数字，而是一个完整的HTTP响应，响应的内容是一个正常的网页。
不同的IIS版本的这个404的错误页面长度并不相同，IIS6默认的404错误页面长度超过2K，而IIS7.5的默认错误页面会超过8K 。
虽然这个响应看起来并不大，但是由于请求不成功，每当打开这些页面时，请求会重新发起，数量会越来越多。
反过来，我们可以想一下：如果要引用的资源文件存在，这些文件仅仅需要请求一次，浏览器就会缓存它们，根本不需要每次都重新发起请求。
这样一来，客户端减少了请求数量，服务器减轻了连接压力，那些无意义的404响应所浪费的网络流量也能消失。
因此，过多的404请求简直是一个恶性循环，它延长了页面的显示时间（前端），给服务端带来了连接压力，也浪费了网络资源。
较大的响应输出
较大的响应输出，应该是容易理解的，那就是：服务端返回的结果太大了。
我们可以想像一下【较大的响应输出】意味着什么。
1、浏览器显示一个【很大的网页】，是不是会比较慢？
2、【很大的网页】是不是会花费较长的网络传输时间？
3、服务端生成【很大的网页】，是不是也要花较长的生成时间？
4、如果这个【很大的网页】的结果来自于数据库的查询结果，会不会给数据库也带来较大的压力？
产生这种情况就典型的场景可能由于一条SQL查询引起的： select * from XXX wherename=@name
或许在早期阶段，XXX表的记录很少，或许当初在设计时根本没想到name会存在一大堆的复制数据时，再或者，当在本地环境测试时，网速根本不是问题，而浏览器的渲染速度的延迟又没有被发觉时。
我们可以想像一下：这样的程序如果部署在互联网上运行，结果会如何？
关于【较大的响应输出】，还有二个可能发生的场景：
1、往ViewState中放入一个很大的对象。
2、展示一个树形结构，或者是一个没有where条件的查询（都属于不分页情况）
当以上这三类情况发生时，你认为性能还能接受吗？用户还会满意吗？
用Fiddler发现这些问题
前面我详细说明了二类低级错误的危害，下面再来说说如何尽早地发现它们。
我想许多人都应该用过Fiddler，它能够方便地让我们知道浏览器发起的每个请求的Request/Response，通常用于调试程序。
在Fiddler中，404错误的请求会用红字醒目地显示，每个请求的响应长度也会单独地显示出来，貌似直接用Fiddler也能容易发现404错误以及较大的响应输出问题。
然而，当访问过多的页面后，Fiddler会显示非常多的请求记录，因此，那些低级问题会被淹没，我们要想发现它们，可能需要花费一点时间。
针对这个问题，我为Fiddler定义了二个规则：
只要打开它们，前面所说的二类低级问题很容易就能发现：
注意：这里只显示符合规则的请求（存在低级问题的请求）。
该怎么合理地使用这个方法呢？
1、如果你是开发人员，请在自测时，打开Fiddler，并选择我定义那二个规则，
2、如果你是测试人员，请在测试时，打开Fiddler，并选择我定义那二个规则，
3、然后，你们平时该做什么就做什么吧，。。。。。。
4、测试结束后，再看一下Fiddler窗口，有没有记录显示出来，如果有，那就是发现低级问题了。
所以，我认为这个方法不会给开发人员以及测试人员带来过多的负担，毕竟，这个方法不会给他（她）们测试时增加任何负担，唯独要求打开一下Fiddler，最后在测试完成后，再来看一眼，仅此而已。
或许有些人认为：分析服务器的IIS日志，也能发现这二类问题。
是的，我知道分析IIS日志也能发现这些问题，但是，分析IIS日志，是不是晚了？
你想过没有：这样的问题是不是已经影响了用户？
反之，不让用户【体验】这些问题，是不是更好？
换句话说：你是否希望发布一个有缺陷的程序？
如何自定义Fiddler过滤规则
如果希望自定义Fiddler规则，建议安装：Syntax-Highlighting 这个Fiddler插件。
然后，打开自定义规则窗口：
此时，会显示Fiddler的规则代码，供你修改：
在这个窗口中，右边显示了能在自定义规则中使用的一些对象类型，以及它们的字段（绿字），属性（蓝字）与方法（黑字）。
我们可以在写规则时参考这些信息。
说明：此规则文件保存在：x:\My Documents\Fiddler2\Scripts\CustomRules.js
还记得我前面的截图中：我在Fiddler的Rules菜单下面增加了二个自定义规则 吗？
定义规则菜单的代码在前面的截图中（找汉字就能发现，最后4行代码）。
菜单定义后，还需要在OnBeforeResponse方法中添加一些处理代码：
最后，我还要再说一句：
如果你不希望发布有缺陷的程序，并且不希望后期返工，那么可以尝试一下本文介绍的方法。
点击此处下载我的CustomRules.js （Fiddler版本 2.4.1.1）（点击右键选择另存为）