如果想真的做好性能测试，需要学习的东西还是比较多的。简单列一下吧。

1. 精通性能测试的基本概念，过程，方法论，了解性能工程；
2. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；
3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；
4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；
5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；
6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；
7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；
8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；
9. 了解一般的大型企业应用的部署架构和应用架构；
10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；
11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；
12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；
13. 大量的实际性能测试及优化经验；
14. 积极的参与到各类圈子、社团的讨论和交流、分享中。

【转载】软件缺陷管理基本概念

认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。
1、首先介绍软件缺陷的概念
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
2、软件缺陷的详细特征
a、单一准确
b、可以再现（要求软件缺陷具有精确的步骤）
c、完整统一
d、短小简练
e、特定条件
f、补充完整
g、不做评价
3、软件缺陷的属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
下面详细介绍一下以上这些属性：
a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；
b、缺陷类型：功能、用户界面、文档、软件包、性能、系统"模块接口
     功能：影响了各种系统功能、逻辑的缺陷；
     用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；
     文档：影响发布和维护，包括注释、用户手册、设计文档；
     软件包：由于软件配置库、变更管理或版本控制引起的错误；
     性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；
     系统"模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）
    致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；
    严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；
    一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；
    较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
d、缺陷产生可能性：总是、通常、有时、很少
     总是：总是产生这个软件缺陷，其产生的频率是100；
     通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80—90；
     有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30—50；
     很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1—5.
e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级
     立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；
     高优先级：缺陷严重，影响测试，需要优先考虑；
     正常排队：缺陷需要正常排队等待修复；
     低优先级：缺陷可以再开发人员有时间的时候被纠正。
f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息
    激活或打开：问题还没有解决，存在源代码中，确认”提交的缺陷”，等待处理，如新报的缺陷；
    已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；
    关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态；
    重新打开：测试人员验证后，确认缺陷不存在之后的状态；
    推迟：这个软件缺陷可以在下一个版本中解决；
    保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷；
    不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；
     需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。
g、软件缺陷的起源：需求、构架、设计、编码、测试、用户
     在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54、设计阶段占25、编码阶段占15、其他占6.
h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码
    需求说明书：需求说明书的错误或不清楚引起的问题；
    设计文档：设计文档描述不准确。和需求说明书不一致的问题；
    系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；
    数据流（库）：由于数据字典、数据库中的错误引起的缺陷；
    程序代码：纯粹在编码中的问题所引起的缺陷。
i、缺陷根源：测试策略，过程、工具和方法，团队"人，缺乏组织和通讯，硬件，软件，工作环境
   测试策略：错误的测试范围，误解测试目标，超越测试能力等；
   过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；
   团队"人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；
   缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；
   硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；
   软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等；
   工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。
4、学会利用管理缺陷的工具
例如TD、bugfree、bugzille等

[转载]程序员应具备的素质

中国有很多精于编码的人，但是中国软件行业，尤其是网络应用开发方面误区很大，很难形成有规模的软件开发力量和产品能力，不但比美国差距甚远，和印度相比也是颇有不如。这些问题不是在于中国程序员的智商和工作努力状况，也不是在于国家和民间对开发的投入程度，而是很大程度上，有一些对技术，对程序开发，对项目设计方面的思想误区，这些误区，导致了软件行业的产品化能力不足，缺乏规模化和大型复用系统研发能力，可以说，改变认识误区，是解决软件行业小作坊模式和个体英雄模式所带来的局限性的重要工作。

程序员是一种技术工作，在IT的发展中有相当重要的地位，从底层硬件通讯协议的建立，到数据传输层的处理，到操作系统的建设，到数据库平台的建设，一直到应用层上各种数据营销平台的搭建，程序员在里面都扮演着举足轻重的角色并为IT事业的发展做出了巨大的贡献。

中国有很多小朋友，他们18,9岁或21,2岁，通过自学也写了不少代码，他们有的代码写的很漂亮，一些技术细节相当出众，也很有钻研精神，但是他们被一些错误的认识和观点左右，缺乏对系统，对程序的整体理解能力，这些人，一个网上的朋友说得很好，他们实际上只是一些Coding fans，压根没有资格称为程序员，但是据我所知，不少小网络公司的CTO就是这样的coding fans,拿着吓人的工资，做着吓人的项目，项目的结局通常也很吓人。

程序员基本素质：

作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具有的素质。

1：团队精神和协作能力
把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。

2：文档习惯
说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3：规范化，标准化的代码编写习惯
作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。 有些coding fans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。 再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。

4：需求理解能力
程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能力。性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。

5：复用性，模块化思维能力
经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。

复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。

一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力。

6：测试习惯
作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。

测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试，并尽早发现和解决问题，当然这需要上面提到的需求理解能力。

7：学习和总结的能力
程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。

善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。但是学习也要找对目标，一些小coding fans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp，他们把这个作为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，做网络程序不懂通讯传输协议，做应用程序不懂中断向量处理，这样的技术人员，不管掌握了多少所谓的新语言，永远不会有质的提高。

善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。

一个不具备成长性的程序员，即便眼前看是个高手，建议也不要选用，因为他落伍的时候马上就到了。

具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是一种意识上的问题。

LoadRunner测试Web的常见问题

性能测试是一件非常严谨的事情，就像我以前写过的一样，很多用户的性能测试的问题在于测试本身。以下列举几条LoadRunner测试Web的常见问题。

• 网络带宽问题。

对Web进行压力测试时，通常百兆网络是不够的，当网络带宽不够的时候server端没有足够压力。用LoadRunner所在的Windows的性能管理器看一下网络利用率就知道了。

• Vuser脚本的检查。

虽然Loadrunner提供了方便的脚本录制功能，但由于录制时可能出现的操作偏差，也应手工检查生成的Vuser脚本。去除某些与压力测试无关的东西。否则可能会出现Loadrunner测试结果有误或压力上不去的情况（比如vuser访问一些不存在的资源）。

• Runtime setting。

在创建Loadrunner scenario时，每台机器的vuser的runtime setting都应该分别设置并检查，不能只对第一个vuser的runtime setting进行设置。通常你会关掉think time，以便能用较少的机器达到较大的压力。另外，如果返回页面里包含了一些访问其它资源的链接比如图片服务器，这时应关掉 download non-html resources。

• 没有检查返回页面。

当server端出错时应用程序有可能返回错误信息，但对HTTP来讲仍是成功的响应，返回码为200 O.K. 这样在Loadrunner就被记为成功的transaction。于是，server端出错越多，Loadrunner测出的性能越好。解决办法：开启并检查应用的错误日志；或者启用Loadrunner的返回内容检查功能。

• 当心Loadrunner所在机器的磁盘空间。

缺省情况下Loadrunner会把运行结果的详细信息放在C盘的Documment and Settings的用户目录下，当大压力长时间运行或有大量出错时，Loadrunner会生成大量的数据到该目录下。当磁盘空间满了后，机器的响应将变得很慢。

• 结语。

还是那句话，性能测试是一件非常严谨的事情。本身在实验室里的性能测试就很难模拟真实情况，另外世界上没有两个一模一样的系统，要做到apple-apple的比较很难。 所以做性能测试一定要仔细，测试条件一定要定义清楚。否则，最后的结果是：上了生产系统后被最终客户折磨地吃不下饭睡不着觉。这不是开玩笑，我在别人那里见过了太多的这种情况。

浅析软件项目管理中十个误区[转]
随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致， 以后对需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间 进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面 要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽 早地对需求变动问题进行沟通。

误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的 改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少， 容易被实现。

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是 着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。

误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般 的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。

误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。

误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体 参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好 心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培 训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系 。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不 一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。

误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味 工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对“成就感”的追求，应该向每一个人详细描述最终“ 作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作 效率。

误区10：为了保证项目继续，为了留住核心程序员，加薪吧。分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了——加薪的 人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。 既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形 成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水 ，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其 感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

 
（转）悲哀，你选择开发工程师做为自已的职业

　　本文所指的开发工程师，仅指程序开发人员和以数字电路开发为主的电子工程师。
　　当你选择计算机或者电子、自控等专业进入大学时，你本来还是有机会从事其它行业的，可你毕业时执迷不悟，仍然选择了开发做为你的职业，真是自做孽不可活。不过，欢迎你和我一样加入这个被其它人认为是风光无限的“白领”吧。
　　如果你不是特别的与人世隔绝，我想你一定看过金老先生的名著《笑傲江湖》吧，里面有一门十分奇特的武功叫做"辟邪剑法"，你看这个小说第一次看到这种功夫的练法时，我想你当时一定笑歪了牙“呵呵，真好玩！”，可是现在我很痛心的告诉你：你选择的开发工作就是你人生路上的"辟邪剑法"，而你现在已经练了，并且无法再回头。
相对同时刚出校门同学从事其它行业而言优厚的薪水，以及不断学习更新的专业知识不仅仅让你感到生活的充实，更满足了你那不让外人知的虚荣心。在刚出校门的几年中，你经常回头看看被你落在后面的同学们，在内心怜悯他们的同时，你也会对自已天天加班的努力工作感到

心里平衡：“有付出才会有回报”这句话在那几年中你说的最多，不管是对自已的朋友们还是自已的爱人。第二句最常说的话是对公司的领导：“不行我就走人！”，实际上你也真的走过几回。对了，在这几年中，因为你的经济条件不错，你开始买房、开始谈恋爱、结婚、开始有了自已的小孩。有时候你会对自已说再过两年就去买车。当然其中可能有许多大件是需要分期付款的，但你对前途充满了信心，你确信认为这种日子会永远的持续下去，即使不是变得更好的话。
　　日子总是在这种平淡中一天天的过去，就在那么不经意间，你突然发现自已已经快30岁了，或者已经30了，莫名的，你心里会漫延着一种说不清楚的不安情绪，你好像觉得前途并非像前几年那样变得越来越好，你也忽然发现你以前所瞧不起的同学里好像已经有不少开着车的了，也有几个人住着比你还大的房子，好像房款还是一次付清的，你突然明白你现在的生活比起你的同学来最多是中游偏上了。工作中最让你感到心里不舒服的是，你越来越不敢对你的领导说不了，即使比你来的晚的同事升职或提薪，你也只是在私下与朋友们一起喝酒时才敢发发牢骚，在头的面前你的声间越来越小、笑脸是越来越温柔。
　　你终于开始迷茫“再过几年我会是在干什么呢？”，这句话常常出现在你的心里。
　　计算机开发工作，是一种以年轻为资本的工作，说句通俗点的话是“吃青春饭的”，嗯，这句话好像在一种特别的行业也听到过。

其标志就是一：工作的时间性非常强，一个开发项目被定的时限通常是很紧张的，更有甚者，有些号称开发管理的书里面还非常卑鄙的号召将一个项目切成多个小片，每个小片都定一个叫“里程碑”的东东来严格跟踪开发进度，加班加点在其它行业是需要加班工资的，而在开发行业，加班工资好像还没见到几个公司发过，是啊，反正有时间限制着，你干不完我再找你算账.所以开发工作通常有着其它工作所没有的精神上的压力。

一旦一个人步入而立之年，因为家庭和孩子的负担，加上精力上面的衰退，加班工作时间变得越来越少，这点让很多老板们感到：这些人已经老了，不好用了。指示人事部门：“以后招开发人员限制在30岁以下！”，相对而言硬件开发会年龄方面限制会稍好一点点，但也是五十步笑百步。还有一个很重要的一点就是：计算机这个烂东东实在是进步的太快了，前两年买的顶级配置电脑，现在怎么看怎么像废品，这还是小事，更可气的是好像每天都需要学习新的知识，刚毕业时只会书本上的PASCAL，学会了用腐蚀的办法来做电路板，一上班就开始学习TURBOC和TANGER2.0，刚刚学会，还没来得及高兴，马上开始学Borland C＋＋和Protel3.0，好不容易学会了，却发现需要学习VC和Protel98了。单片机也是啊：Z80的指令背的很熟，工作中没来得及用就要学8031，好好学吧，本来想着这辈子就吃它了，又发现又出来什么PIC、DSP、CPLD、FPGA、ARM等等....这还不包括中间要学一大堆74系列、4000系列、XX系列...IC卡居然里面还有CPU卡..如果学习的知识里每个字都能变成一分钱，我想所有的开发工程师都是腰缠万贯的富翁。
　　一眼看去，这种日子好像见不到头，年轻时乐此不彼，但现在你一定对自已能坚持到什么时候感到怀疑了。我们都玩过像仙剑奇侠传这样的RPG游戏，刚开始时你只是一个一名不文的少年，随着你去打怪物、捡宝贝、学秘芨，最后终于有一天你会变成一个大英雄！那么你在实际生活中过得比那些小侠们还辛苦，为什么成不了一个生活中的大侠呢？呵呵，原因在这里：因为开发工作是邪门功夫，它虽然可以让你速成的变成小资，但它最大的特点是经验不积累！日新月异的知识更新，让你总是感到自已在退步，你就像在RPG中的主人公，开始时就给了你一把好剑和好盔甲，而且让你的级别很高，但让你的经验不累积，虽然刚开始打小怪物时你觉得自已很爽，但越到后来，你会发现你会死的很惨！比较一下你与其它非开发行业的同学你就可以知道了，例如和你学医的同学比起来。套用岳不群他老人家说华山剑宗和气宗的区别那段话：前十年你比你那些学医的同学收入和地位要好的多，但十年以后你和他基本上各方面都会持平，而二十年以后你的各方面远远不能与你学医的同学相提并论！嗯，你已经开始不笑辟邪剑法了吧。
　　“敢问路在何方？路在脚下...”，不过猴兄和八戒兄这么认为是可以的，你呢？
总结了许多开发朋友在30岁以后的生活之路，让我们一起看看开发人员“路在何方？”那么开发人员在30岁以后都干些什么呢？
其路一：继续做你这个很有“前途”的职业吧！
　　偶掰着脚指头仔细数了数，发现还真的有很多朋友在30岁以后还在从事开发工作，我这里说的从事，是指你还需要天天在电脑边上编程序和画电路板，与你手下是否有几个小兵无关，也与你是否头上顶着什么项目经理、主任工程师的帽子无关，只要你还需要亲自开发，你就属于这一类。其中有个年龄最大的朋友是63年的，从事医疗仪器的开发工作，35岁左右还在从事软硬件开发工作的仍有一大堆，分析这些仍然从事开发的朋友，基本上都有以下特点：
1　痴迷工作或者痴迷电脑，晚上八点到十二点的这段时间，基本上是在电脑桌或工作台前渡过的。
2　不喜欢与人交住，朋友很少，常联系的人不超过五个。
3　与朋友交往时谈工作多，但一般不主动谈钱。
4　体型偏胖或偏廋，不在正常区间。
5　无未来计划，对五年后自已生活怎么样、从事什么工作说不清楚。
6　俭省，从不乱花钱。
即使你是还不到30岁的开发人员，你也可以看看自己对以上几条是否符合，是否会在30岁后还从事开发职业，四条疑似，五条以上基本确诊你也是这类型的人。
　 这些朋友们通常报着过一天是一天的态度生活，到了这个年龄，也不敢再轻易的换工作了，年轻时的锐气慢慢的也消退了。唯一不变的希望是有一天从天上掉下来一大堆钱把自己砸伤。说实在话因为他们的性格所限，基本上可以确定他们以后不可能在职场上获得更好的发展，当个小头头，带几个人开发已经是他们发展的顶点。至于以后的人生之路，不仅他们自己迷茫，可能上帝也正在头痛。
不过像这类朋友，偶很奇怪的发现：他们的小孩都是儿子！不知是偶然还是有什么其它说法。
简单建议：要改变命运，先改变性格：坚持半年晚上不从事工作、游戏及电视，用此时间与人交往，你的人生会有改变。

其路二：转行从事技术支持、行政或生产等工作还有一些朋友，从事了几年的开发工作，因为自已并非特别的爱好，或者领导上面的强制工作安排，他们转到了技术支持、服务或行政等工作，至少当时从表面上看起来，他们的薪水较开发要少一些，但真正的统计这些人，发现他们之中有半数的人获得了更好的发展，升职为服务部经理或行政经理等职，最历害的一个朋友已升职为总经理助理，进入高层。
　　这类朋友当时转行通常并非自已志愿，属被逼无奈或者其它原因，但显然，拥有专业知识技术的他们显然在非技术部门中鹤立鸡群，遇到什么事情他们均可从专业的角度提出建言，久而久之，他们获得更多的升职和加薪机会也就不足为奇。
　　因为不从事开发，所以经验开始积累，这类的职业通常会给你一个很安定的感觉，你到30多岁后会发现这类职业反而比开发工作更容易获得新的工作机会。

　　简单建议：你如果确定在开发部无法获得很好的发展机会，不妨转到其它几个部门试试，换个活法，钱少点就少点吧，机会多。
其路三：开发管理
　　如果你现在已经是总工或开发部经理，或者你眼看就有机会被提升为这类职务，那么恭喜你，你走的是从“弼马温”到“斗战胜佛”这条金光大路，你不仅拥有很高的专业技能，而且很显然，你也有着很强的人际交往能力，你这类人根本不需要对未来有着任何的担心，你在即使一无所有的时候也很容易白手起家。
　　你这种人算是练辟邪剑法练成了仙，嗯，我无话可说。
　　你是不是这类人也很容易区别，就像围棋二十岁不称国手终身无望一样，你应该在工作三、四年以后，也就是说二十七岁左右就会发现自已工作中指手划脚的时间比亲自开发的时间要多了，而且大多数这类人在这个年龄手下应该有“兵”了，相反的，如果你快30岁了还天天埋头于电脑前编程序和画板子，或者30多岁了你还没升到部门经理（虽然你总是觉得自已很有希望），基本上可以确定你不是这类人。好了，如果你确定你是这类人，那么你唯一的想法就是尽快爬上中层和高层，因为有时候人生偶然性太大，不占住坑的萝卜很有可能被人拔出来！

　　简单建议：天天去你的老板家里面拖地和擦桌子！

其路四：出国或考研
　　有两个搞开发后出国的朋友，其中一个甚至打工打到了一个小公司总工的位置，数据库和软件方面水平巨牛，但仍感觉心里不踏实，于是将自己工作多年的钱忍痛掏出来，出国费加上机票大概将自已辛苦所攒的银子花完，然后又借了一些钱，在02年身上揣着一万美元跑去了加拿大，在加拿大不停的重复找工作，换工作，然后再找工作的循环，找的工作基本上与计算机无关，不过工资总是在1500加元左右，呵呵，折成人民币与他在国内打工拿的基本上差不多，不过租个地下室就花了300加元，然后吃吃喝喝，再买个电脑上上网这类的，基本每月平均还要倒贴一点。前段时间给我的邮件里说，现在身上花的差不多只有5、6000美元了，准备开个小公司，看看能不能往国内倒腾点东东，做最后一搏。另外一个朋友去澳州，时间稍早一些，先是大概摘了一年多的葡萄，后来总算找了个技术工作，每天的工作是画机械图纸，收入还算不错

将近3000澳元，买了个旧车，也算是过上了资本主义生活。不过前年回来一趟，唯一的感叹就是：在国外拿2000美元的生活，绝对不如在国内拿5000人民币的生活舒服。
　　也有两个考研的朋友，不过其中一个严格的说不是做开发的出身，偏重于市场方面的工作性质，不过我的朋友里面考研的不多，只好凑两个人说说，一个考研后在北京找了个工作，每个月5、6000元钱，但还是做开发，生活仍然与没考研之前没有任何的改变，前途仍然没见到什么大亮的光，还是搞不清楚以后再干些什么，标准的过一天算一天了。另外一个考研后在大学里面找了个工作，工资虽然比他原来打工少了不少，但毕竟终身有靠，稳定了下来，也算修成了正果，这位哥们心情一放松下来，也开始有时间琢磨着业余时间自已做点什么，好像现在慢慢的也开始有了点眉目。
　　简单建议：这两条路，对开发人员来说都不算是很好，出国十年前是好事，现在难说，考研能成功转行的概率恐怕也不是很大，多半仍然去搞开发，只不过研究生可以多干几年罢了。

其路五：转行到市场
　　绞尽脑汁的想想，我所知道的人之中只有两个开发人员去了市场，这两个人都不能说是朋友，认识而已。他们都是主动要求去了市场，结果是这两个人均在市场都是干到一年左右，然后都自已开公司了。呵呵，很奇怪，极高的转行成功率！不过仔细想想，我对这两个人的思路佩服的五体投地。能下决心仍掉每月5、6000元的开发职位，从事一个自已并不熟悉的岗位，每月拿个2000多元＋提成，但提成那是说不清楚的事情，这个决定，只能让人感觉到他们对自已前途清晰的把握和老谋深算的心机。而且他们不去服务不去生产，挖空心思说服领导去市场（市场部门与开发部门通常是一个公司的核心部门，进入其实并不容易），可以说是有着长远的考虑的。有技术了，再与客户交成朋友，马上就会产生很大的机遇应该是正常的事情。
　　有实力，有心机，也有着很强的决心力，这种人恐怕早在大学毕业时或更早的时候就已经决定了自已的人生之路，他们的每一步路在若干年前早就计划周全，现在看起来：学会技术－＞进入市场－＞寻找商机－＞开公司，一条多么清楚的人生之路。但就像我们上小学中学时，所有人都知道上大学是我们最清楚的人生路一样，最后只有少数人才能真正达到目标（当然，现在扩招的历害是另外一回事，我是说我们那个时候，也就是：“很久很久以前，当我像你那么大的时候”）。

　　简单建议：你若是这类人，我的建议是：...嗯?....那个你.你，你别走啊，我还有个事想请你赞助一下啊.....

其路六：开公司自已干

　　呵呵，看到这一条，发现你的眼睛已经圆了，你肯定千百次的想过这个事情吧，咳咳，其实我从事开发的时候也是天天梦想着这种事情。总想着过两年找个机会就自已干，这个梦想一年又一年的折磨着你也给着你希望。看看吧，开发后来开公司的还真的不少，里面有成功的也有很多失败的，通常开公司都是几个人合伙开始的，有做技术的，有做市场的，几个人一拍即合、狼狈为奸，共同策划了这一个大活动。一般说来能让这几个人下决心走出这一步，产品肯定是先进的，甚至是国内独一无二的，市场也是很大的，负责市场的那个哥们通常会拍着胸保证可以卖出去，并悄悄地告诉你他在某主管领导是他小舅子的同学的二叔，肯定没问题。于是你们几个人找地点、注册执照、买了几个破桌子，再攒了两台电脑，每个人又凑了几万银子，公司开张了！
　　产品很快出来了，市场的哥们也不负重望，有几个客户表示要试用了，一切看起来都是如此的正常，“.......你坐在老板桌前，不停的有人来汇报工作或者找你签字...人进人出中...你又想起公司再穷也不能只有一把椅子的故事.....”你在梦中笑出声来。
是如此的顺利，你们很快就有单子了，很快的单子让你们凑的那点钱不够了，你们很高兴的每个人又增加了投入，拿出钱时你眼泪汪汪的数着钱说：“这就是我那生蛋的母鸡啊”。你们的产品确实不错，市场也经营的很好，客户慢慢的多了起来，单子来的时候一笔接着一笔，你每天都处于兴奋之中，唯一美中不足的是好像客户回款总是会拖一些日子，不过客户给你保证说：过几天，过几天就付给你们，因为回款总是在计划外，所以你们为了资金的流畅运行又凑了一些钱，这个时候你有一些心事了，因为你的存款折上面的数字已经快趋向于零了。“没事，过两个月等回款了一切都OK了，谁干事业不吃点苦呢？”你这么安慰着自已又投入到工作中去，资金总是在回款和生产经营费用之间走着一个窄窄的小木桥，你的账上总是没有太多的钱，扩大了的公司规模和许多意外情况，使你又一次、二次、三次的与合作者们再次投入了自已的资金，当然，后来的钱你可能已经是借的了.....
　　终于有一天，你的会计再一次告诉你，老板啊，账上又没现金了，吃过多次苦头的你终于下决心开始重视资金的运行了，你裁掉了一些不必要的人手，减少了开发的投入，要求市场人员签单的时候必须予付XX%的款，回扣也必须等收过款后再付，同时也开始对产品的生产成本开始进行控制。
　　时间一天一天的过去，因为竟争对手的产品也对你的产品进行了仿造，你的产品慢慢变得不再先进，市场人员开始埋怨公司的合同资金方面规定太严格，不好签单，生产成本的下降通常也导至产品毛病的增多，客户也开始埋怨你的服务人员不能及时进行服务。
　　终于有一天，你重新走进了人才交流中心，以前你是来招人的，现在你拿着自已的简历开始寻找一个工作
......
公司的成功与否，与产品有关，与市场有关，但更重要的是与资金有关，产品与市场都可以通过资金来弥补，而却没有任何东西可以代替

资金，凡是倒下的公司，99%与资金链的断裂有关。在你决定要开公司以前，先估计一下你公司支持一年所需要的资金数额，包括人工费，生产，场地，广告宣传、市场费用、甚至电、水费等等等等，把你所想到的一切加在一起，得出的值就是..慢..如果你没有实际的开过公司的经验，你需要将此数字乘3，然后就是你开公司一年最少需要的费用，呵呵，公司的实际运营所需要的钱是你想像的3倍以上，你要是不信我也没办法。

简单建议：开公司前最重要的是先确立你后续的资金来源！也就是说钱不够了怎么办？－－－因为你投入的钱肯定会不够的。

其路七:第二职业
这类的朋友有不少,他们没有脱离开发工作,但是在业余时间又不停的接项目或者在卖产品,在单位里面他们显得并不出众,比起其它人来说他们属于最不愿意加班的一类.为此他们白天通常工作很勤奋.这类人也许不一定可以挣很多钱,但平均下来他们一年之中通常都可以比同事们多挣个几万元.有时候比上班拿得还多.但令人疑惑的是,这类人在生活中更加注重稳定,基本上没见到他们跳过蹧,即使私下里面已经开了个小公司,他们通常也不会辞职.
你的旁边有没有这类人呢?分辨他们很容易:
--电话很多,而且更愿意来电话时离开办公室找个没人的旮旯通话.神秘兮兮给人一种"这家伙是不是有二奶啊?"的感觉的人，通常是这类人。这类人是女性最佳的选择对象：很顾家，不象那些富人容易花心，而比起一般人来说，他们收入相对要高得多。但总结了一下几位这类的开发朋友：也得出了一个令人沮丧的结论：这种人通常个子不高，体形类似桶状.....

简单建议：这好像是开发人员最佳的出路了，但比较丰厚的收入通常让这类人不愿意去冒风险....到现在为止我所认识的这类人还没有一个真正算是成功的。
好了，虽然偶的经历远远说不上丰富，也没有什么成功之处可以自满的，但或许因为比其它朋友痴长了几岁，见过的人可能会稍多一些，所

以斗胆写出了以上的一些文字，让您掉牙了。
下面是偶走过开发这条路上总结出来的一点心得，你可以不看，但看了就千万别把嘴咧的太大：
一、不管是给别人打工还是自已干，都要全心全意的工作，因为你所做的任何一点工作都会让自已的人生多一点筹码，这一点最最重要!这样的例子我至少可以举出两起，优秀的开发人员被其它新公司挖走，并给一定的股份，成为新公司的股东的例子。当时与这样的开发人员一个部门同时工作或更早工作的有许多人，他们平时经常偷点懒，能少干点工作就少干点，有时候还笑话那个平时努力工作的人傻，几年过去了，究竟谁比谁傻？
二、多与市场人员交朋友，你接触他们时可能总会觉得他们知识比你少，甚至素质比你低，可能比你还有点黄。但实际上他们比你更懂这个社会！参加到他们这个圈子中去，和他们一起赌赌钱、一起聊聊天、一起洗洗桑拿、一起.....你会通过他们接触到另外一个世界。
三、机会远比钱重要，挣不挣钱在年轻时并不是特别重要！不论是在实际生活中还是在网上或其它地方，如果有机会参与到除本职工作外的一些项目或产品的开发中（包括你的朋友拉你去做点小生意之类的非开发性质的工作），那怕是帮忙的性质，也要积极介入，至少你会交到很多的朋友，这样你的人生会多出很多的机会。

　　由于没有得到足够的重视，软件缺陷管理处于失控状态。软件测试人员报告的缺陷常常被遗忘掉;或没有人知道在新的软件版本里究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。更重要的是纠正过程是否引入了新的缺陷也没有人知道，再或者就是缺陷报告书写不规范，使得开发人员不得不一次次找到测试人员来面谈，还有许多无效的文档使缺陷状态混乱，相关人员无法及时获得有关的变更信息。

　　什么是开发的缺陷管理?

　　软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。

　　软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。

　　(1)缺陷管理的目标

　　一般而言，缺陷的跟踪和管理需要达到以下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。

　　在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　(2)缺陷管理重在预防缺陷

　　正如我们所知，BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此，越晚修正BUG，需要重做的事情就越多。

　　对很多人来说，零缺陷的软件产品似乎是不切实际的。因此，我们总是听到许多软件开发人员说：“软件永远有BUG”。软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值提深思的事情了。

　　事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。为了能够预防BUG，我们首先需要了解BUG的来源。软件BUG可以分为几个类别：第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难预防。但是，适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。

　　但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。因此，BUG的预防尤为重要。

　　缺陷管理的核心：缺陷分析

　　缺陷预防的着眼点在于缺陷的共性原因(Common Cause)。通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。

　　BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费，但是却可带来极大的额外价值。

　　(1)BUG记录

　　BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。

　　(2)利用BUG分析了解开发质量趋势

　　对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。

　　BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。在这个时候，BUG分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。

一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。

　　实际上，BUG分析图表会告诉我们很多有价值的信息。比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点发现的故障数反而呈上升趋势，那么意味着往往有一些特殊事件的发生。通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。

　　(3)发布BUG分析经验,提高团队成员能力

　　分析得出来的BUG实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库，这将使得新的知识在项目内流动并被相关的开发人员所学习。

　　BUG分析带来了很多的好处。第一个好处就是帮助产生BUG的开发人员总结经验，并使他在将来避免类似的BUG。有时只修正一个具体的BUG而不去分析它产生的原因并不会帮助开发人员在日后得到提高，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。

　　从这个角度来看，BUG分析的价值不仅仅是缺陷的预防，更大的好处是通过记录和分析BUG，项目内的其他开发人员知道如何发现类似的错误。所以，我们可以通过某个开发人员产生的一个BUG提高整个项目团队的实践经验，而不仅仅是尽快修正它。这样，因为一个缺陷所浪费的时间也可以转化为收益：确保类似的错误不会再发生。除了分享项目内的测试知识和经验，BUG分析过程还可以促进开发更好的测试技术和工具，从而帮助发现类似的BUG。

　　如何高效地进行缺陷管理

　　(1)清晰缺陷分类，明确处理责任

　　首先要改变以前那种凡是BUG就是由开发人员负责的观念。跟据缺陷内容可分为需求BUG与程序BUG。对于程序BUG是由相关开发人员进行处理，需求BUG则要交由需求人员进行处理，对于这种分法的好处就是明确了BUG处理的责任人。

　　测试人员从本质上来说与程序员还是对立的，如果为了一个不是软件程序本身的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况。测试人员协调好与开发人员的关系，可让他们更高效的关注软件本身的缺陷。

　　(2)建立缺陷处理流程，减少无效运作

　　建立缺陷处理流程，这对测试人员和开发人员来说都是很有帮助的。BUG处理流程其实就是定义BUG处理过程的职责和权限，用明确的流程去指导如何对BUG进行日常管理，提高运作效率。

　　(3)使用缺陷管理工具:BUG管理库

　　为了跟踪和控制测试质量，便于管理测试发现的BUG，我们需要为项目配置一个专用的缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证缺陷。因此，开发过程中使用一套BUG管理工具是非常必要。

　　缺陷管理工具应便于项目组和管理人员获取正确、足够的信息，以简化信息共享流程，最大限度减少重复工作。BUG管理库就是记录、评估缺陷，并执行及维护系统配置，创造一个高效管理环境的最好工具。例如使用缺陷管理库可以很方便制作各种缺陷分析图表，从而预测项目风险或解释测试结果。整个开发过程是BUG数从少到多，再到少的过程。从BUG数量的变化，也可以推断软件产品的成熟性，推断产品的发布期。

　　(4)把管理制度和配置策略相结合

　　有了先进的缺陷管理工具，还需要有相应的管理制度与之相配套，否则BUG管理就只是一个摆设。目前BUG管理制度方面主要的问题是不重视测试，认为测试人员无关大局，随便测测就行了，再或者就是虽然认识到测试的重要性，但却走向了极端，制定了极其严格的规章制度。

　　例如无数琐碎、难用的测试工单，非常严密的层级权力控制等。把一个需要灵活变化的工作变成了工业制造车间流水线的一个工种，让测试人员陷入制度的泥潭，不能把主要精力投入测试工作本身。再或者就是项目负责人也没有制订明确的BUG处理流程及相关指导原则，让测试人员在黑暗中摸索，走到哪儿算哪儿，不能给他们以切实有效的指导和帮助，把软件的质量保证责任一股脑推到测试人员身上，任何问题都去指责测试人员。

　　最后，BUG管理制度还有一种常见的错误考核制度，就是项目主管用BUG个数去衡量测试人员的工作成绩，谁发现的BUG多谁的工作就做的好。这是一个十分危险的倾向，将直接导致测试人员去重视BUG个数这个数字本身、而不是产品的真正质量。最后重申强调一点：BUG不仅仅是被修正，更重要的是根据BUG管理来提高软件产品质量。

从事了几年测试工作，也着实见证了测试的发展，如今测试行业对从业者的要求是越来越高，不再仅仅局限于要求会写测试用例、会细致的执行测试、能有效的发现系统缺陷等；越来越多的企业对应聘者本身的技能要求也越来越高，招聘信息中诸如“精通VBscrīpt、Perl/Rbuy等至少一门脚本语言”、“至少熟悉一门开发语言”、“精通QTP、LR等自动化测试工具”、“有大型项目自动化实施成功经验”此类的字眼也逐渐增多。目前看来，除白盒测试内容和测试管理外，主流的方向有两个：功能自动化测试和性能测试。这就要求从业人员能够在短时间内快速的掌握这些知识，才能获取到更好的工作机会。本人是名功能自动化测试的工程师，以自己学习、工作的过程结合QTP讲讲该如何学习自动化测试

首先，想从事自动化测试，必须先了解What/Why/How，也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试，这类的资料在网上有很多，这里就不做重复了

其次，需要根据项目的特点，选择合适的自动化测试工具，并了解工具的特性。以QTP为例，该如何去掌握它呢？对于初学者，大多数都是通过录制的方式来生成脚本，这个阶段应该掌握的基础知识有

1)      QTP是如何去识别对象的，对于新手经常会出现录制的脚本回放的时候报错的现象，这个时候就应该考虑为什么呢？如果很了解QTP识别对象的原理啊，我想就能很快定位到原因了

2)      去掌握一些QTP对象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等，对于相似的方法应该去搞清楚到底区别在哪？像GetROPreperty、GetTOPreperty有什么区别等

3)      什么是Action参数、什么又是Test参数？两者有什么区别，又有什么联系，在同一Test和不同Test间这些参数如何工作

4)     什么是环境变量？环境变量是如何建立和使用的，环境变量在参数传递中和action参数、test参数有什么不同

5)     了解检查点的知识，明白什么是内置检查点，什么又是自定义检查点。并搞清楚在什么时候该如何使用检查点

6)     掌握对象库的操作，了解对象库对于测试的意义，象是否启用智能识别对测试脚本有何影响、为什么同一对象识别起来会有_1、_2之类的后缀等都是需要去研究清楚的问题

这几个问题都搞清楚的话，那基本就能够利用QTP生成正确的脚本了，当然以上只是部分必须掌握的内容，其实还是很多细节的设置，就需要在实际运用中去掌握了

接下来，就可以进一步提升自己的QTP运用水平了，这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了，同时在这个过程中还需要去学习html知识、DOM、XML、以及像excel、word等的API知识了，总的来说，这个阶段应该掌握的内容大体上包括

1)     VBscrīpt的基础知识，熟悉常用的方法和函数，掌握文件对象的操作等

2)     熟练掌握XML技术；excel、word等API对象，可以根据需要创建日志等

3)     熟练掌握DOM和HTML知识，能够结合这些技术对Web页面进行解析

4)     掌握数据库的基本操作语句，能够利用ADO对象进行数据操纵

5)     熟练掌握正则表达式，很多时候处理对象问题相当方便

6)     掌握如何调用dll进行工作

7)     能够利用QTP的自动化对象模型创建出需要的运行模式

8)     掌握WMI知识

以上只是我考虑到的部分，并不全面，呵呵，供大家参考，当然这些技术主要是针对Web系统运行，因为我们的系统就是B/S的，呵呵。如果这些知识都能够扎实的掌握的话，个人认为，基本上能够处理自动化过程中的绝大多数问题了，这个时候你对自动化测试的技术应该是有一定积累了

接下来就需要考虑自动化测试框架问题了。当脚本规模到了一定的程度，就会面临一些问题，如：

1)       如何有效的管理并调度脚本

2)     如何实现脚本运行的无人值守，测试过程中能够自动进行错误处理并进行日志记录

3)     如何生成简介明确的测试报告

4)     如何能够更加高效的维护测试脚本

5)     实现框架代码和业务代码的分层、业务脚本和业务数据的分离

这个阶段主要体现的是测试人员的测试思想，是可以脱离工具独立存在的过程。当然各个公司项目的实际情况不同，导致设计出来的思想不同，但总体上来说一般包括数据驱动和关键字驱动两种模式。后者实现的技术难度大于前者，大多数公司目前都采用的数据驱动模式。这个阶段不应局限于技术运用上，而需要从测试全局考虑，进行分层设计、模块化实现，减少代码之间的耦合

如果以上三个方面都能够做的很好的话，那么恭喜你，你已经可以独立负责项目的自动化测试建立工作了，呵呵！

总之，学习自动化测试需要在实际项目中进行，这样提高的会比较快，项目中运用了很多种技术，自动化实施过程会碰见各种各样的问题，是很好的学习机会，关键要善于总结、积累经验，只要能够把各个细节做好，那么你一定能够成为一名优秀的自动化测试工程师

转]数据库设计中的14个技巧
下面十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。

      1. 原始单据与实体之间的关系
　　
      可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。

      〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。

      2. 主键与外键
　　
      一般而言，一个实体不能既无主键又无外键。在E?R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
　　
      主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

      3. 基本表的性质
　　
      基本表与中间表、临时表不同，因为它具有如下四个特性：
　　 
        (1) 原子性。基本表中的字段是不可再分解的。
　　    (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
　　    (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
　　    (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

      理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

      4. 范式标准
　
      基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。

      〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
　　
      在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
　　
      表1 商品表的表结构
　　  商品名称 商品型号 单价 数量 金额
　　  电视机 29? 2,500 40 100,000
　　 
      5. 通俗地理解三个范式
　　
      通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
　　
      第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
　　  第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
　　  第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.
　　
      没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

      6. 要善于识别与正确处理多对多的关系
      
      若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。

      〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。

      7. 主键PK的取值方法
　　 
      PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。

      8. 正确认识数据冗余
　　
      主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。

      〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。

      9. E--R图没有标准答案
　　
      信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E?R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

      10. 视图技术在数据库设计中很有用
　　
      与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

      对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？

      11. 中间表、报表和临时表
　　
      中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

      12. 完整性约束表现在三个方面
　　
      域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。

      13. 防止数据库设计打补丁的方法是“三少原则”
　　 
       (1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
　　  
       (2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
　　  
       (3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
　　
      数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。
　　
      提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E?R图中实体的个数、主键的个数、属性的个数就会越少。
　　
      提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
　　 
      “三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

      14. 提高数据库运行效率的办法
　　
      在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
       (1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
      
       (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
　　
       (3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
　　
       (4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
　　
       (5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
　
      总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。

磁盘已满　

导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。

日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与操作系统不同的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。

C指针错误

用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引用指针（即，访问指向的内存）中出现一个错误，就会导致操作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。

内存泄漏

C/C++程序还可能产生另一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操作系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。

解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法无法找到由其他原因引起的库中的泄漏，因为库的源代码是不可用的。另一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个原因创建和清除子进程。

虽然Java本身并无指针，但总的说来，与C程序相比， Java程序使用内存的情况更加糟糕。在Java中，对象被频繁创建，而直到所有到对象的引用都消失时，垃圾回收程序才会释放内存。即使运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操作系统。结果是：Java程序会用光给它们的所有堆，从不释放。由于要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。

还有一个问题，情况与此类似。从连接池分配一个数据库连接，而无法将已分配的连接还回给连接池。一些连接池有活动计时器，在维持一段时间的静止状态之后，计时器会释放掉数据库连接，但这不足以缓解糟糕的代码快速泄漏数据库连接所造成的资源浪费。

进程缺乏文件描述符

如果已为一台Web服务器或其他关键进程分配了文件描述符，但它却需要更多的文件描述符，则服务器或进程会被挂起或报错，直至得到了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络连接。默认时，大多数shell有64个文件描述符，这意味着每个从shell启动的进程可以同时打开64个文件和网络连接。大多数shell都有一个内嵌的 ulimit命令可以增加文件描述符的数目。

线程死锁

由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形：在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。

解决死锁没有简单的方法，这是因为使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。

如果程序使用了永久锁，比如锁文件，而且程序结束时没有解除锁状态，则其他进程可能无法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。

服务器超载

Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。操作系统级别可能还在不断地接收新的连接，而应用程序（Web服务器）却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected（已连接）的提示消息，但这以后什么也不会发生。

解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值，这样如果越过 RqThrottle的值，就不会接收新的连接。那些不能连接的服务器将会停止工作，而连接上的服务器的响应速度则会变慢，但至少已连接的服务器不会被挂起。这时，文件描述符至少应当被设置为与线程的数目相同的数值，否则，文件描述符将成为一个瓶颈。

数据库中的临时表不够用

许多数据库的临时表（cursor）数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。

这是一个不容易被程序员发觉的问题，但会在负载测试时显露出来。但可能对于数据库管理员（DataBase Administrator，DBA）来说，这个问题十分明显。

此外，还存在一些其他问题：设置的表空间不够用、序号限制太低，这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。

另外，还有许多因素也极有可能导致Web站点无法工作。如：相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无意间锁住了关键的表。

1、Web性能测试

Web性能测试涉及的范围太广，但一般web开发者在程序上线以后很多都曾遇到过性能的问题。普遍表现为页面速度开始急剧变慢，正常访问时间变的很长，或则干脆给你抛出异常错误页面。这里会涉及到很多可能发生的情况，举例几个最主要发生的情况：

• 数据库连接超过最大限制，目前一般表现为程序的连接池满，拒绝了与数据库的连接。
• 数据库死锁
• Web Server 超过最大连接数（一般在虚拟主机上才会限制）
• 内存泄漏
• Http连接数太多，即访问量超过了机器和软件设计正常所能提供的服务

2、CC攻击

CC主要是用来攻击页面的.大家都有这样的经历,就是在访问论坛时,如果这个论坛比较大,访问的人比较多,打开页面的速度会比较慢,访问的人越多,论坛的页面越多,数据库就越大,被访问的频率也越高,占用的系统资源也就相当可观。

一个静态页面不需要服务器多少资源,甚至可以说直接从内存中读出来发给你就可以了,但是论坛就不一样了,我看一个帖子,系统需要到数据库中判断我是否有读读帖子的权限,如果有,就读出帖子里面的内容,显示出来——这里至少访问了2次数据库,如果数据库的体积有200MB大小,系统很可能就要在这200MB大小的数据空间搜索一遍,这需要多少的CPU资源和时间?如果我是查找一个关键字,那么时间更加可观,因为前面的搜索可以限定在一个很小的范围内,比如用户权限只查用户表,帖子内容只查帖子表,而且查到就可以马上停止查询,而搜索肯定会对所有的数据进行一次判断,消耗的时间是相当的大.

CC就是充分利用了这个特点,模拟多个用户(多少线程就是多少用户)不停的进行访问(访问那些需要大量数据操作,就是需要大量CPU时间的页面).这一点用一个一般的性能测试软件就可以做到大量模拟用户并发。

假设服务器A对Search.asp的处理时间需要0.01S(多线程只是时间分割,对结论没有影响),也就是说他一秒可以保证100个用户的Search请求,服务器允许的最大连接时间为60s,那么我们使用CC模拟120个用户并发连接,那么经过1分钟,服务器的被请求了7200次,处理了6000次,于是剩下了1200个并发连接没有被处理.有的朋友会说:丢连接!丢连接!问题是服务器是按先来后到的顺序丢的,这1200个是在最后10秒的时候发起的,想丢?!还早,经过计算,服务器满负开始丢连接的时候,应该是有7200个并发连接存在队列,然后服务器开始120个/秒的丢连接,我们发动的连接也是120个/秒,服务器永远有处理不完的连接,服务器的CPU 100%并长时间保持,然后丢连接的60秒服务器也判断处理不过来了,新的连接也处理不了,这样服务器达到了超级繁忙状态.

我们假设服务器处理Search只用了0.01S,也就是10毫秒(这个速度你可以去各个有开放时间显示的论坛看看),我们使用的线程也只有120,很多服务器的丢连接时间远比60S长,我们的使用线程远比120多,可以想象可怕了吧,而且客户机只要发送了断开,连接的保持是代理做的,而且当服务器收到SQL请求,肯定会进入队列,不论连接是否已经断开,而且服务器是并发的,不是顺序执行,这样使得更多的请求进入内存请求,对服务器负担更大.

防范方法

说了攻击原理,大家肯定会问,那么怎么防御?使用硬件防火墙我不知道如何防范,除非你完全屏蔽页面访问,我的方法是通过页面的编写实现防御.

1. 使用Cookie认证.这时候朋友说CC里面也允许Cookie,但是这里的Cookie是所有连接都使用的,所以启用IP+Cookie认证就可以了.

2. 利用Session.这个判断比Cookie更加方便,不光可以IP认证,还可以防刷新模式,在页面里判断刷新,是刷新就不让它访问,没有刷新符号给它刷新符号.给些示范代码吧,Session:

程序代码:

〈% 

if session(“refresh”)〈〉 1 then  

Session(“refresh”)=session(“refresh”)+1 

Response.redirect “index.asp” 

End if 

%〉

数据库测试
随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。

　　数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试。

　　从测试过程的角度来说我们也可以把数据库测试分为：

　　系统测试

　　传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。

　　这个阶段我们的测试主要通过数据库设计评审来实现。

　　集成测试

　　集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是：

　　数据项的修改操作；
　　数据项的增加操作；
　　数据项的删除操作；
　　数据表增加满；
　　数据表删除空；
　　删除空表中的记录；
　　数据表的并发操作；
　　针对存储过程的接口测试；
　　结合业务逻辑做关联表的接口测试；
　　同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。

　　单元测试

　　单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。

　　而我们也可以从测试关注点的角度对数据库进行分类：

　　功能测试
　　对数据库功能的测试我们可以依赖与工具进行。

　　DBunit
　　一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。

　　QTP
　　大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。

　　DataFactory
　　一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。

　　数据库性能

　　虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能。

　　性能优化分4部分：

　　1.物理存储方面
　　2.逻辑设计方面
　　3.数据库的参数调整
　　4.SQL语句优化

　　我们如何对性能方面进行测试呢，业界也提供了很多工具。

　　通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。

　　Loadrunner
　　这个不用多说，我们可以通过对协议的编程来对数据库做压力测试。

　　Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）

　　数据库厂商也意识到这点，例如：

　　oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。

　　还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。

　　安全测试

　　软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端。自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。

　　对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点，我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求

 
关于软件测试及测试工具比较

来源：heiyou 作者：香山叶

1、测试自动化实现到何种程度为好

（1）、测试自动化的程度再高都不可能取代手工测试，即测试工具不可能取代测试人员；

（2）、一般来讲，测试自动化在整个测试过程中只能占到30%左右；

（3）、实现、运用自动化的程度还取决于各方面的资源，特别是软件的行业规范性和软件开发的稳定性；

（4）、对于部分白盒测试可以使用测试工具，如对代码性能分析等；

2、如何实现测试自动化的计划

（1）、首先将测试的基本管理形成自动化，如BUG管理等；

（2）、然后利用测试自动化工具来实现一些手工无法进行的测试活动，如：压力，并发，强度测试等；

（3）、接着利用测试自动化工具来完成回归测试中的缺陷跟踪测试；

（4）、再往后就可以利用测试自动化工具来记录两个版本的异同，以找出缺陷；

（5）、最后将整个回归测试都用自动化脚本保存，以完成每次的回归测试；

（6）、而对于白盒测试则可以引入测试工具进行代码分析；

3、对测试工具的使用现状及分析

（1）、目前，软件测试方面的工具很多，主要有MercuryInteractive（MI）、Segue、Rational、 Compuware和Empirix等公司的产品，而MI公司的产品占了主流。以下就各种常用测试工具进行简要对比：

主要厂商及其测试工具如下表：

Mercury Interactive Winrunner、loadrunner、TestDirector、Astra QuickTest

Rational Rational Purify （测试时用，检查运行时内存错误）

Rational Quantify （性能检测工具，查出系统瓶颈以便改进运行速度）

Rational TestManager （测试管理）

Robot （软件测试用，通过scrīpt自动模拟输入输出）

LoadTest

TestFactory （软件测试用）

Compuware QACenter、Perfromance Edition、EcoScope、TrackRecord

Segue SilkTest

Empirix eTest Suite

以下从常见测试工具功能、使用范围、目前市场情况、应用前景等方面做简要比较：

工具名称 功能范围

WinRunner-----功能：

1.插入检查点；

2.检验数据；

3.增强测试；

4.分析结果；

5.维护测试；、

６.为无线应用作准备。

范围：功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。

LoadRunner-----功能：

1.松创建虚拟用户；

2.创建真实的负载；

3.定位性能问题；

4.分析结果以精确定位问题所在；

5.重复测试保证系统发布的高性能；

6.Enterprise Java Beans的测试；

7.支持无线应用协议；

8.支持Media Stream应用；

9.完整的企业应用环境的支持。

范围：性能测试、压力测试、模拟多用户、定位性能瓶颈。

TestDirector------功能：

1．需求管理;

2. 计划测试;

3. 安排和执行测试;

4. 缺陷管理;

5. 图形化和报表输出;

范围：测试管理工具

Rational系列-------Rational Purify （测试时用，检查运行时内存错误）;

Rational Quantify（性能检测工具，查出系统瓶颈以便改进运行速度）;

Rational TestManager （测试管理）;

Robot （软件测试用，通过scrīpt自动模拟输入输出）;

LoadTest （负载测试）;

TestFactory （软件测试用）;

QACenter-----QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。

这些测试工具自动帮助管理测试过程，快速分析和调试程序，

包括针对回归，强度，单元，并发，集成，移植，容量和负载.

建立测试用例，自动执行测试和产生文档结果。

QACenter主要包括以下几个模块：

- QARun：应用的功能测试工具。

- QALoad：强负载下应用的性能测试工具。

- QADirector：测试的组织设计和创建以及管理工具。

- TrackRecord：集成的缺陷跟踪管理工具。

- EcoTools：高层次的性能监测工具。

QARun----

1.强大的测试脚本建立功能。

2.可反复运行，进行回归测试。

3．支持更多的应用访问

QALoad------

1.自动捕获实际执行过程，自动生成测试脚本。

2.通过控制台（安装在Windows NT）控制各个Agent（安装在Windows和Unix），进行脚本分配。

3.模拟实际操作，压力测试。

WebLoad-----Web压力测试工具

（2）、对于测试工具目前的使用状况，总结就是，大家都处于学习阶段，部分虽有一些应用到工作中，但也是比较有限的，最主要是应用在性能测试方面；

随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。
　　B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。

　　首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？

　　如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：

　　1、通用指标（指Web应用服务器、数据库服务器必需测试项）:

　　* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；

　　* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；

　　* Physicsdisk Time : 物理磁盘读写时间情况；

　　2、Web服务器指标：
　　
　　 * Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

　　* Attempted Connections ：尝试链接数；

　　3、数据库服务器指标：

　　* User 0 Connections ：用户连接数，也就是数据库的连接数量；

　　* Number of deadlocks：数据库死锁；

　　* Butter Cache hit ：数据库Cache的命中情况；

　　上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持） 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧。

　　在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。

　　这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。

　　对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。

　　上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：

　　一、性能达不到目标；

　　二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；

　　三、服务器稳定性的问题，比如内存泄漏……。

　　要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

　　我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库。

　　数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。

　　同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情。

　　内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:

　　1、 Array Bounds Read (ABR) ：数组越界读

　　2、 Array Bounds Write (ABW)：数组越界写

　　3、 Beyond stack Read (BSR)：堆栈越界读

　　4、 Free Memory Read(FMR)：空闲内存读

　　5、 Invalid pointer Read(IPR)：非法指针阅读

　　6、 Null Pointer Read(NPR)： 空指针阅读

　　7、 Uninitialized Memory Read(UMR)：未初始化内存读写

　　8、 Memory Leak：内存泄漏

　　注：如果需要更多的信息，可以参见Purify的帮助信息。

　　顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了。

　　注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。

补充一些知识:

spring架构的单元测试现状
    一般网站分三层，业务层、逻辑层、持久层。spring架构下这三层通过配置文件来装载起来，持久层依赖于自己的配置文件、逻辑层依赖于自己的和持久层的、业务层依赖于三种配置文件。如果有发送邮件，调用外部接口等，还需要相应的配置文件和接口服务器。这种情况下，要做一个单元测试，需要配置很多东西，任何一个配置有误都无法启动spring容器，而且这些配置都在xml文件里面，内容是否正确无法自动检测。要做业务层的测试，不是一个容易的事情。其中持久层的东西相对固定，需要配置的文件也较少，相比较而言，这一层测试很容易完成，逻辑层和业务层的测试难度成指数级增长。

    对于数据的校验，这又是web软件测试的一个难点。软件的功能依赖于数据，数据之间的关联在Java程序中控制，但这些数据却可以通过sql生成、修改，数据库里面存在的数据可能是单元测试产生的，可能是整个业务过程中产生的，也可能是完全无意义的冗余数据，这些数据在一起会产生的效果无法预测。这样一来，单元测试的代码中取到的数据跟现实情况相差很远，无法通过已存在的数据看出预期的结果，单元测试可以检查获取数据的条件是否正确，却很难检查取到的数据是否符合预期。

    对于一个高速发展的网站来说，业务层和逻辑层的代码随时会有改动，会增加输入或输出的参数，会有新的返回值和新的异常抛出，在快速的修改过程中，有些东西不需要单元测试来验证，只需要业务测试即可。这种情况下，单元测试的代码很容易遭到破坏，几周之后就好发现测试代码跑不起来了，要让他跑得起来就要了解这些业务做了那些修改，而这些修改未必是一个人做完的，每人告诉你一点情况，最后会把人搞糊涂，单元测试跟在开发的屁股后面，越跑越累。

    单元测试由开发人员做，会加入很多假设条件，例如某个字段不可能为空，某个方法返回值只有几种；单元测试由测试人员来做，看不懂代码的逻辑的话，很难有高覆盖率，看明白别人的代码，要很牛的水平才够。

热评：IT人转行其实是个人能力的心虚 
 
 
【作者：李颜芯】 
　　中学政治学科的课堂上，辩证唯物主义告诉我们，任何事物都包含着既对立又统一的两个方面。要如实的反映事物的本来面目，就必须坚持一分为二的矛盾分析法，对矛盾作全面的分析要运用两分法、两点论去认识事务的本质。
 
 
 
简单的意思就是，万事万物都要看到它好的一面和不好的一面。

　　IT也是如此，程序员的职业也是如此。“程序员的最后归宿是什么！”、“程序员为什么到了30或35就会想要转行”、“边缘化的IT人”等等诸如此类的话题漫天遍野，“程序员吃的就是口青春饭”如一根刺隐隐的扎在了程序员心头肉上。这已成为程序员们深思的职业规划问题。

　　搜了搜论坛里相关的帖子，仔细看看热心的网友们的讨论，不难发现大家各自的论证都集中“转行”与“不转行”这两个对立的观点上，大家谈到了很多，有关于软件行业这个大背景的讨论，也有关于职业规划与个人现实状况相结合的讨论、更有转了行的程序员道出了转行后的心境，等等。

　　一定坚持奋斗在这一行的IT人说，他们认为问题的根本还是在个人的心态上。他们表示，实际上程序员是完全可以干一辈子的。国外胡子一大把还干着开发的老外多了去，他们的思维同样活跃，精力充沛，并且还有大量的经验和积累。一行行看似简单的代码之中却蕴含了无数思想，足以体现出其功力，而这也并非一日之力所能。有位网友说，他所在单位隔壁研究所的一位年纪60的工作人员，他的程序思维还是很不错。

　　IT人确实很累又辛苦，但是真正熬过几年coding日子的程序员，到哪里又不受欢迎呢？可以选择去外资、大型企业作高级工程师，待遇又好，工作也不会像最初做底层开发时那么得忙。也可以选择取中小型企业，做技术经理、研发主管。敢闯一点的，在技术、管理、人脉积累到一定的程度的时候，更可以出来创业。又或者在家作soho一族，承接外包项目也未尝不可。实际上这个行业正在不断地创新中，因此机会也还是很多。

　　有网友毫不客气的指出，矛盾在转与不转行中的人，其实就是个人能力的心虚。

　　城外的人想进城，城内的人想出城，很多其他行业的人还很羡慕IT这个行业，IT之外其他行业的苦楚也并非我们能够想象。

　　生活中的压力，买房子买车，偿还贷款，赡养老人，结婚生子等等，这对任何一个行业的现代人来说都是一个要处理的问题。并非只存在于IT这个行业的从业人员中。计算机行业并非那么的苦不堪言，IT一族虽然挣钱不会太多，相对来说算是比较稳定的，不会太穷。

　　任何一个行业，想要有更长远的发展，前进的动力就在于由被动到主动，主动去工作，主动去学习，主动去寻找这个行业中的其他道路，认认真真将这个行业捉摸透，只要做到积极与主动，推动职业发展的强而又力的动力就有了，那么职业生涯的道路必然就掌握在自己的手中。

　　少一些浮躁，沉下心来体会技术的真正精髓，踏踏实实的做，最终会有一个好的归宿。

　　要在程序中用代码作诗，要做个IT李白。一部分IT人表示一定要做个纯粹的IT人。始终坚持自己的兴趣和理想。继续向软件狂人、顶尖科学家进军！。

　　另一部分IT人，他们毫无遮掩的指出了一个同样令人发省的问题：现实呢，这个行业确实发展太快，技术的不断更新，随着年龄的上升，体力脑力精力不可能随之快速的适应，不能适应，也就意味着被淘汰，那么那时该怎么办呢？与其这样，不如提早为自己找寻另外一条路，提早认识这一点，算是对自己的负责。

　　关于转行的观点中也有两个集中点：行业自身与年龄问题。

　　30或者35岁的IT人为什么要转行，因为生活的关注不同了，有了家庭，不再是单打独斗，有的是更多一份责任的承担。年龄的增长带来了生理上的改变。这是讨论的主要观点之一。

　　技术的日新月异，各个公司的血液不断换新，企业想要发展依赖于产品，而产品的开发归于技术的支持。新老开发人员的不同在于，老一辈的开发人员在年轻时学的技术在现在应用的很少了，生活上上有老下有小，体力和精力投入的要少，学习新技术的能力比不上年轻人，思路也不灵敏了，逻辑分析能力，理解能力逐步减退，唯剩经验，但是IT届的经验不如创新值钱。

　　相比较，新一代开发人员对新技术的学习及应用所花的时间要多一些，他们的生理机能也正在上风，他们更多的技术起点也是基于此，他们有的是时间和精力投入其中。大部分企业也认为，招聘年轻的开发人员，他们没有太多生活负担，他们能将更多的时间投入工作中。公司总是希望自己的员工将精力投入到公司的工作中越多越好，至于员工的其他生活呢，公司又会管你多少？

　　还有IT人表示现在做开发远没有之前那么热情了，随着工作时间的变长，发现当初怀着对技术的崇敬，加入其中，原本以为这是个崇尚技术本身的队伍，但慢慢发现很多技术管理，技术经理他们的技术并非想象中的那么好，依靠着资历换得职位，技术为上的梦想也逐步幻灭。Coding如同打字，代码贴过来，转过去，全成了一种体力上的劳动。积极与热情大大打消了。这也是主动性减少的原因之一。

　　另外一点就是，国内的软件业形势不好，需求乏力，盗版猖獗，成本提高，规模小，导致了软件业的不景气。在这样的大环境下，前景并非乐观，因此程序员的职业发展也受到了相当大的阻碍。
 
 

实现B/S架构系统性能大提升的有力武器

阅读提示：摩卡响应时间管理通过对B/S架构系统页面或业务环节进行脚本录制，实现对网站响应效率的有效监控，是B/S架构系统系能提升的利器。

摩卡响应时间管理（RTM）是针对大中型企业或政府的IT支持和管理部门设计，为监控其对外提供的电子商务或电子政务网站及内部BS架构应用系统核心业务流程的响应时间，提早预防，快速定位和解决系统问题，提高IT服务水平和效率所提供的监控管理软件。RTM通过对B/S架构系统页面或业务环节进行脚本录制，实现对网站响应效率的有效监控，从Web页面的响应时间和返回内容分析帮助提高业务服务水平，克服发展瓶颈，是B/S架构系统系能提升的利器。

Mocha RTM从以下三个角度实现B/S架构系统性能的提升：

采集业务流程响应时间，提高用户的访问体验，最大可能的避免客户的流失

通过提前录制的业务流程，按照业务流程中的业务环节，实时或者定时模拟登录Web页面，并采集业务流程中各页面的响应时间，帮助互联网企业了解用户在网站的体验，在有需要时，及时进行系统优化，减少客户的流失。

监控各业务环节响应时间，分析业务服务瓶颈

IT部门通过业务流程录制工具，根据业务特点，将业务流程细分为各个业务环节，例如搜索-购买-结算等，系统分别监控各个环节的响应时间，帮助IT管理者快速分析出业务流程中，响应速度慢的瓶颈，并优化此瓶颈。

分析Web页面关键字，帮助互联网企业第一时间发现Web页面的不完整性。管理员输入页面上必须监控的关键字，如果关键字不出现，则该页面将定位为不可用

通过KPI图表，协助互联网企业，了解用户的访问体验

体验时间管理提供业务流程响应时间KPI分析报表，IT部门可以根据KPI报表分析出用户体验最差的业务流程或者业务环节，将协助IT部门有目的的进行系统优化，保障用户处于最佳体验。

Mocha RTM关键功能及亮点：

根据业务流程特点，灵活定制相关的业务监控流程

IT部门可以根据互联网站的业务特点，灵活录制不同的业务流程，并将业务流程分为不同的业务环节，根据录制的不同业务流程和业务环节进行响应时间的采集。

实时监控Web页面响应时间，分析用户访问体验

通过模拟登陆Web页面访问方式，将Web页面的返回时间进行统计和分析，即可以清楚地知道用户在登陆企业Web页面的具体响应和用户体验，将业务流程分为多个业务环节来分段监控，细化问题，分析业务服务瓶颈。

可以根据关键字对Web响应页面进行分析

用户体验时间管理不仅仅可以判断页面的响应时间，还可以根据监控的需求，分析Web页面的返回内容是否正确，如果返回页面有错误，通过告警，可以在第一时间通知管理员，并快速恢复故障。

URL过滤分析，帮助运维人员去除干扰，聚焦关键内容响应时间分析

用户体验时间管理将分析所有元素的返回时间，提供URL过滤分析功能，在过滤分析栏目中输入需要看到的关键元素响应时间，这样有利于管理人员清晰地得到自己关注的关键元素响应时间。

定制监控时段和监控频率

由于监控的不同需求，系统管理需要在登录繁忙的时候，减少监控采集次数和频率，以及响应时间的告警阈值都可以通过策略灵活的定义。

提供实时监控界面

系统管理人员不仅可以通过用户体验时间管理定时对响应时间进行采集，也可以尽可能快地点击采集按钮，对业务流程响应时间进行实时采集，达到更便捷的响应时间管理。

响应时间超时告警

一旦响应时间超过了预先定义的阈值，管理人员能第一时间被通知，并快速恢复或优化系统。

提供多样化和可定制的交易响应时间分析报表

提供多样化的报表和TOP10排名，帮助管理者分析Web页面的整体水平和具体的交易流程，尽最大可能的发现业务服务瓶颈，帮助互联网企业提高Web 页面服务水平，并最终提高互联网企业竞争力。