需求分析的20条法则!
对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。


　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

风险躲在需求的迷雾之后

　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

客户的需求观

　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达

　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s

3、 分析人员必须编写软件需求报告

　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明

　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见

　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案

　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

1. 概述 

随着 web 应用的增多，新的模式解决方案中以 web 为核心的应用也越来越多， 很多公司各种应用的架构都以 B/S 及 web 应用为主，但是有关 WEB 测试方面的内容并没有相应的总结，所以我在这里对 web 的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖 web 程序的各个方面，测试技术方面在继承传统测试技术的技术上结合 web 应用的特点。 
l 相关的测试和实现技术也有着很大的关系，由于本公司使用 J2EE 体系，也许例子中只有 JAVA 平台可以使用， .NET 平台测试技术暂时不涉及，如果你有请与我联系。 

2. 测试方法 

说明：测试方法的选择取决你的测试策略。 

一般的 web 测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 

当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 

有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 

2.1 界面测试 

现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 

方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的 HTML ， CSS 等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面 / 框架。注意不要靠程序员的美术素养形成你的 web 风格，那样可能会很糟糕。 

主要包括以下几个方面的内容： 

1 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确； 

2 背景 / 色调 是否正确、美观，是否符合用户需求； 

3 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等； 

4 连接 连接的形式，位置，是否易于理解等。 

web 测试的主要页面元素 

5 页面元素的容错性列表（如输入框、时间列表或日历）； 

6 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）； 

7 页面元素的容错性是否存在； 

8 页面元素的容错性是否正确； 

9 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）； 

10 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）； 

11 页面元素是否显示正确（主要针对文字、图形、签章）； 

12 元素是否显示（元素是否存在）； 

13 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）。 

测试技术 

14 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案； 

15 可以结合数据定义文档查看表单项的内容，长度等信息； 

16 对于动态生成的页面最好也能进行浏览查看。如 Servelet 部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用 XML 封装要做的工作会多一点等等。 

2.1.l 界面测试要素 : 

符合标准和规范 , 灵活性 , 正确性 , 直观性 , 舒适性 , 实用性 , 一致性 

2.1.l.1 直观性 : 

a 用户界面是否洁净 , 不唐突 , 不拥挤 . 界面不应该为用户制造障碍 . 所需功能或者期待的响应应该明显 , 并在预期出现的地方； 

b 界面组织和布局合理吗 ? 是否允许用户轻松地从一个功能转到另一个功能 ? 下一步做什么明显吗 ? 任何时刻都可以决定放弃或者退回 , 退出吗 ? 输入得到承认了吗 ? 菜单或者窗口是否深藏不露 ? 

c 有多余功能吗 ? 软件整体抑或局部是否做得太多 ? 是否有太多特性把工作复杂化了 ? 是否感到信息太庞杂 ? 

d 如果其他所有努力失败 , 帮助系统真能帮忙吗 ? 

2.1.l.2 一致性 

a 快速键和菜单选项 . 在 Windows 中按 F1 键总是得到帮助信息； 

b 术语和命令 . 整个软件使用同样的术语吗 ? 特性命名一致吗 ? 例如 ,Find 是否一直叫 Find, 而不是有时叫 Search? 

c 软件是否一直面向同一级别用户 ? 带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息； 

d 按钮位置和等价的按键 . 大家是否注意到对话框有 OK 按钮和 Cancle 按钮时 ,OK 按钮总是在上方或者左方 , 而 Cancle 按钮总是在下方或右方 ? 同样原因 ,Cancle 按钮的等价按键通常是 Esc, 而选中按钮的等价按钮通常是 Enter. 保持一致。 

2.1.l.3 灵活性 

a 状态跳转：灵活的软件实现同一任务有多种选择方式； 

b 状态终止和跳过：具有容错处理能力； 

c 数据输入和输出：用户希望有多种方法输入数据和查看结果 . 例如 , 在写字板插入文字可用键盘输入 , 粘贴 , 从 6 种文件格式读入 , 作为对象插入 , 或者用鼠标从其他程序拖动。 

2.1.l.4 舒适性 

a 恰当：软件外观和感觉应该与所做的工作和使用者相符； 

b 错误处理：程序应该在用户执行严重错误的操作之前提出警告 , 并允许用户恢复由于错误操作导致丢失的数据，如大家认为 undo /redo 是当然的； 

c 性能：快不见得是好事，要让用户看得清程序在做什么，它是有反应的。 

2.2 功能测试 

功能测试是测试中的重点，主要包括一下几个方面的内容： 

a 连接：这个连接和界面测试中的连接不同。那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式；这里的连接注重功能，如是否有连接，连接的是否是说明的位置等； 

b 表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。 B/S 结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量； 

c Cookies 验证：如果系统使用了 cookie ，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie 能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于 cookie 的使用可以参考浏览器的帮助信息。如果使用 B/S 结构 cookies 中存放的信息更多； 

d 功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。 

2. 2.1 测试技术 

功能测试的测试技术可是很多的，我们可以结合实际环境选择使用。 

a白盒测试技术 (White Box Testing) ： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。 

b黑盒测试技术（ Black Box Testing ）：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 

c正确性 (Correctness) ：计算结果，命名等方面。 

d可用性 (Usability) ：是否可以满足软件的需求说明。 

e边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 

f性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题 

g压力测试 (Stress) ： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。 

h错误恢复 (Error Recovery) ：错误处理，页面数据验证，包括突然间断电，输入脏数据等。 

i安全性测试 (Security) ：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 \ 内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。 

j 兼容性 (Compatibility) ：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。 

兼容性测试内容详述： 

a 硬件平台 

b 浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深，文字大小，调制解调器速率 . 

c 软件配置 (Configuration) ：如 IE 浏览器的不用选项 - 安全设定最高，禁用脚本程序等等，你们的程序在各种不用的设置下表现如何。 

2. 2.2 单元测试技术 (Unit Test): 

2. 2.2 .1 下面是对白盒测试和单元测试的区别的论述 : 

单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。 

另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。 

不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。 

2. 2.2 .2 功能测试边界测试 \ 越界测试技术详述 

a 边界条件 

边界条件是指软件计划的操作界限所在的边缘条件，如果软件测试问题包含确定的边界，那么数据类型可能是：数值、速度、字符、地址、位置、尺寸、数量。同时，考虑这些类型的下述特征：第一个 / 最后一个、最小值 / 最大值、开始 / 完成、超过 / 在内、空 / 满、最短 / 最长、最慢 / 最快、最早 / 最迟、最大 / 最小、最高 / 最低、相邻 / 最远。 

b 越界测试 

通常是简单加 1 或者很小的数 ( 对于最大值 ) 和减少 1 或者很小的数 ( 对于最小值 ) ，例如：第一个减 1/ 最后一个加 1 、开始减 1/ 完成加 1 、空了再减 / 满了再加、慢上加慢 / 快上加快、最大数加 1/ 最小数减 1 、最小值减 1/ 最大值加 1 、刚好超过 / 刚好在内、短了再短 / 长了再长、早了更早 / 晚了更晚、最高加 1/ 最低减 1 。 

另一些该注意的输入：默认，空白，空值，零值和无；非法，错误，不正确和垃圾数据。 

2. 2.2 .3 状态测试技术 

a 软件可能进入的每一种独立状态； 

b从一种状态转入另一种状态所需的输入和条件； 

c 进入或退出某种状态时的设置条件及输入结果。 

具体测试方法可以参考如下： 

d 每种状态至少访问一次； 

e 测试看起来最常见最普遍的状态转换； 

f 测试状态之间最不常用的分支； 

g 测试所有错误状态及其返回值； 

h 测试随机状态转换。 

2. 2.2 .4 竞争条件测试技术 

竞争条件典型情形参考如下 : 

a 两个不同的程序同时保存或打开同一个文档； 

b 共享同一台打印机 , 通信端口或者其他外围设备； 

c 当软件处于读取或者修改状态时按键或者单击鼠标； 

d 同时关闭或者启动软件的多个实例； 

e 同时使用不同的程序访问一个共同数据库。 

2. 2.3 负载 \ 压力测试 (StressTest) 

在这里的负载 \ 压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。 

使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。 

负载测试一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。 

负载测试技术在各种极限情况下对产品进行测试 ( 如很多人同时使用该软件，或者反复运行该软件 ) ，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题。 

a 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。 

b 对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 100 的 Load Size 连续使用 24 小时，微软定义的通过准则是通过 72 小时测试的程序一般不会出现稳定性的问题。 

2. 2.4 回归测试 (Regression Test) 

过一段时间以后，再回过头来对以前修复过的 Bug 重新进行测试，看该 Bug 是否会重新出现。 

a 回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。 

b 回归测试的目的就是保证以前已经修复的 Bug 不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。 

2. 2.5 A lpha 和 Beta 测试 (Alpha and Beta Test): 

在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。 

特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。 

不同的测试技术区分 

2.3 覆盖测试技术 

说明 : 测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。 

覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。 

该技术可以用在任何测试阶段，包括单元测试、集成测试、系统测试。 

使用该技术时可以使用以上的任何测试方法和测试技术。 

2.4 白盒测试和黑盒测试技术 

白盒测试技术 (White Box Testing) ：该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行测试。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用 Xunit 系列工具进行测试，可以包括很多方面如功能性能等。 

黑盒测试 (Black Box Testing) ：测试的主体部分，黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。 

2.5 手工测试和自动化测试 

手工测试 （ Manual Testing ）：即依靠人力来查找 Bug 。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。 

自动测试 （ Automation Testing ）：使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考 MI,Rational 或者其他类测试工具说明。 

根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程 80 ％还是手工完成。 

自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。 

2.6 根据 RUP 标准按阶段区分测试 

单元测试：在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。 

集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。 

系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。 

验收测试：可以包括 Alpha 和 Beta 测试，在这里就不再详述。 

3. 存在风险及解决方法 

说明：测试不能找出所有的问题，只是尽量在开发阶段解决大多数的问题而已。 

测试风险如下： 

软硬件的测试环境提供上也对测试结果有很大的影响； 

测试团队的水平，经验，合作效果等； 

整个开发流程对测试的重视程度，测试的进入时间等； 

由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。 

4. 软件缺陷的原则 

软件缺陷区别于软件 bug, 它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的 bug 测试和开发人员有不同意见等。 

a 软件未达到产品说明书标明的功能； 

b 软件出现了产品说明书指明不会出现的错误； 

c 软件功能超出产品说明书指明范围； 

d 软件未达到产品说明书虽未指出但应达到的目标； 

e 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 

5. 文档测试 

产品说明书属性检查清单 

a 完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？ 

b 准确：既定解决方案正确吗？目标明确吗？有没有错误？ 

c 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？ 

d 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ? 

e 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ? 

f 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ? 

g 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ? 

h 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ? 

产品说明书用语检查清单 

说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷

i 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例

j 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。 

k 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。 

l 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。 

m 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。 

n 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。 

o 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。 

　　我2001年大学毕业，大学期间对计算机有兴趣、有热情，就利用业余时间买了大学计算机专业的教材自学了一遍，毕业前考了一个计算机三级B 的证书。毕业后混进了一家软件公司做HIS系统，做了几个大项目后转到测试——当时的优势是有资深的行业背景，又有开发经验，了解系统的实现——之后就在 测试行业一直混迹到现在。

　　几年来换过几家公司，所做的系统主要都是HIS系统，电信BOSS 系统以及其它运营商级系统。自己所从事的工作包括开发工程师，测试工程师，Team leader，在前两家公司也零零碎碎的做过一些售前和需求工作。目前又转回技术职位，在一家外企做 Senior Test Engineer，所关注的方向是软件测试过程改进，性能测试和软件测试自动化。

　　对于转行来说，如果能够充分利用之前专业所积累下的知识和经验，将会对转行有很大的帮助。我的第一份工作并不是因为我的开发能力强，而是因为当时公司所有人对医院内部的各种业务的熟悉程度都不如我。很多软件企业都是作企业应用的，为某一个行业提供服务，那么相对来说，行业知识比计算机专业知识更重要，也更难学的精通，因为作为技术人员很难有机会沉浸到那个环境中去。

　　对于测试工程师来说，有开发经验和没有开发经验的确是有差别。但是这并不是关键，关键在于如何认清自己的优势并加以利用，找到合适的定位而不是去和别人的长处一争高低。

　　另外，无论做哪个行业，作什么工作，兴趣都是最重要的。有了兴趣，你就不会怕吃苦，不会怕跨行业时的阵痛，可以从不断超越自己的过程中收获很多乐趣和经验。

　　其实你问到这个问题让我突然想起了一件事情。在之前几年的工作中，虽然我从来没有刻意要安排自己的发展之路，但是也倒是一路走的很顺利，我一直都认为是幸运女神的眷顾，不过今天想一想，其实在几年的工作生涯中有些东西是不知不觉帮助了我的发展的，这个过程中有些东西是可以总结出来作为经验的，只是一直都被我忽视了。举个例子，在跨行业和换工作是，要尽可能避免太大的变动，要保证新工作的压力不会大到超过自己所能承受的最大限度。在我自己的工作经历中：

　　1. 第一个行业，优势是对于医院内部各部门以及跨部门业务的精通。所以别人看来头痛无比的东西对我来说轻车熟路，并且乐于同我交流，我用行业知识交换来了很多计算机知识和开发经验。另外，HIS系统其实是一个很庞大繁杂的系统，除了业务类型众多，流程复杂外，还有各种复杂的业务逻辑和算法，甚至包括了完整的财务系统和进销存系统。这使我对“大系统”有了一种宏观上的感受，也见识到了大系统的开发和部署过程中的各种问题;

　　2.第二个行业是电信行业，优势是对软件测试技术以及开发过程、开发技术的熟悉，所以可以很快的上手本职工作，有足够多的时间学习了各种通信领域的知识，熟悉了各种电信行业的系统和业务;

　　3. 第三个行业是IPTV和DVB行业，优势是对软件测试技术/过程以及开发过程的精通，和对电信系统行业系统和业务的熟悉——在我学习和测试IPTV以及 DVB行业系统时，可以借鉴到很多电信行业系统的经验——包括技术方面和业务方面。而新近获得提升的是外企工作经验和行业经验，以及英文水平。

　　我的看法是现在的软件行业分工越来越细，越来越明确，但是工作领域的交叉也越来越多，例如我们公司有些开发人员对于测试的理解恐怕比很多专职测试工程师还要 深入，而在我们实际的测试工作中，也要求测试工程师在计算机网络、数据库、操作系统以及程序设计语言方面有较多的经验。一个测试工程师所要面对的就是面前全是路，自己该选哪一条的问题。不过我的感受是，并不需要刻意成为全能选手，但是要积极的对待自己手边的每一份工作，从工作本身出发，培养自己快速反应的能力和快速学习的能力，不断想着如何更好、更快的完成自己的工作，并以此为出发点去带着问题学习，多多跟同事、同行交流。这样要好过去学习一些开起来漂亮、热门，但是总是用不到的技术好的多。

　　另外，如果你有了足够多的工作经验，就会发现每件工作都有很多种做法，自己拥有超强的技术并不是最重要的，也未必是最有效的。这也是为什么外企更加看重 soft skill 的缘故。

转自http://www.51testing.com/?2730

在我们日常的测试活动中，单纯的功能界面测试（黑盒测试）发现的缺陷质量不高，即使发现了，也很少能从根本上去定位，这样的bug提交上去，给我们的研发同事修复带来了困难，同时也不利于提高我们自身的能力。这里我介绍一下个人的经验。

1、按照需求说明编写用例，然后严格执行，这个方法最常见。

2、在发现问题后，不要立刻就想着提交bug，应该做下记录，然后自己尝试着去分析这个问题产生的原因，比如看一下源代码，有些问题测试人员是可以自己定位的，只要自己确认了，提交上去的bug质量会更高。比如，执行搜索的时候，输入某个字段值，没有搜出来，查看代码后，发现sql语句并未执行，这时，我们再提交bug，描述里可以具体到那个页面文件，那个源代码，研发同事定位也方便，同事也对我们的技术能力认识上有改变。

3、如果测试环境带有控制平台，比如tomcat，jboss，weblogic等等，都有控制平台，那么我们测试的时候，不仅仅需要关注前台的页面表现，还要看监控平台上的信息日志。有些系统对错误页面做了处理，我们在发现这类问题的时候，顶多将处理过的错误页面写到bug中，根本的原因可能无法得知，其实我们可以利用控制平台获取真正的错误原因，写到bug中。

4、结合数据库进行测试，一般流程性的测试，最重要的就是数据在数据库中的状态变化。比如移动的项目，很多是异步的，光从页面是看不到效果的，所以我们可以结合数据库进行测试，弄清楚数据在数据库中的流转流程，这样才能发现更深层的bug，当然需要我们掌握数据库的使用，尤为重要要的是sql语句。举个例子，进行添加操作的时候，添加完成后没有反应，可能有两种情况，第一，添加根本未成功，第二，添加成功了，没回显出来，那么我们可以通过sql查一下添加的数据，如果数据库中有了，就说明回显出了问题，如果没有，就说明insert 出了问题。

5、可以查看系统的日志检查测试过程中的问题。一切异常都需要关注

不错，尤其是第四个总结自己以前也发现过这样的问题，只是自己却不知道总结

        假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

        根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

       在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

        （1）  计算平均的并发用户数： C = nL/T      

        （2）  并发用户数峰值： C’ ≈ C+3根号C

         公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

        公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：

        假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

Java Learning Path （一）、工具篇 
一、 JDK (Java Development Kit) 

JDK是整个Java的核心，包括了Java运行环境（Java Runtime Envirnment），一堆Java工具和Java基础的类库(rt.jar)。不论什么Java应用服务器实质都是内置了某个版本的JDK。因此掌握JDK是学好Java的第一步。最主流的JDK是Sun公司发布的JDK，除了Sun之外，还有很多公司和组织都开发了自己的JDK，例如IBM公司开发的JDK，BEA公司的Jrocket，还有GNU组织开发的 JDK等等。其中IBM的JDK包含的JVM（Java Virtual Machine）运行效率要比Sun JDK包含的JVM高出许多。而专门运行在x86平台的Jrocket在服务端运行效率也要比Sun JDK好很多。但不管怎么说，我们还是需要先把Sun JDK掌握好。 

1、 JDK的下载和安装 
JDK又叫做J2SE（Java2 SDK Standard Edition），可以从Sun的Java网站上下载到，http: //java.sun.com/j2se/downloads.html ，JDK当前最新的版本是J2SDK1.4.2，建议下载该版本的JDK，下载页面在这里：http://java.sun.com/j2se/1.4.2/download.html。 

下载好的JDK是一个可执行安装程序，默认安装完毕后会在C:\Program Files\Java\目录下安装一套JRE（供浏览器来使用），在C:\j2sdk1.4.2下安装一套JDK（也包括一套JRE）。然后我们需要在环境变量PATH的最前面增加java的路径C:\ j2sdk1.4.2\bin。这样JDK就安装好了。 

2、 JDK的命令工具 
JDK的最重要命令行工具： 
java： 启动JVM执行class 
javac： Java编译器 
jar： Java打包工具 
javadoc： Java文档生成器 
这些命令行必须要非常非常熟悉，对于每个参数都要很精通才行。对于这些命令的学习，JDK Documentation上有详细的文档。 


二、 JDK Documentation 

Documentation在JDK的下载页面也有下载连接，建议同时下载Documentation。Documentation是最最重要的编程手册，涵盖了整个Java所有方面的内容的描述。可以这样说，学习Java编程，大部分时间都是花在看这个Documentation上面的。我是随身携带的，写Java代码的时候，随时查看，须臾不离手。 


三、 应用服务器(App Server) 

App Server是运行Java企业组件的平台，构成了应用软件的主要运行环境。当前主流的App Server是BEA公司的 Weblogic Server和IBM公司的Websphere以及免费的Jboss，选择其中一个进行学习就可以了，个人推荐Weblogic，因为它的体系结构更加干净，开发和部署更加方便，是Java企业软件开发人员首选的开发平台。下面简要介绍几种常用的App Server： 

1、 Tomcat 
Tomcat严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，数据库连接池，用户事务处理等等。Tomcat被非常广泛的应用在中小规模的Java Web应用中，因此本文做一点下载、安装和配置Tomcat的介绍： 

Tomcat是Apache组织下Jakarta项目下的一个子项目，它的主网站是：http: //jakarta.apache.org/tomcat/ ，Tomcat最新版本是Tomcat4.1.27，软件下载的连接是：http: //www.apache.org/dist/jakarta/tomcat-4/binaries/ 。 

下载Tomcat既可以直接下载zip包，也可以下载exe安装包（个人建议zip更干净些），不管哪种情况，下载完毕安装好以后（zip直接解压缩就可以了）。需要设置两个环境变量： 

JAVA_HOME=C:\j2sdk1.4.2 
CATALINA_HOME=D:\tomcat4 (你的Tomcat安装目录) 

这样就安装好了，启动Tomcat运行CATALINA_HOME\bin\startup.bat，关闭Tomcat运行 shutdown.bat脚本。Tomcat启动以后，默认使用8080端口，因此可以用浏览器访问http://localhost:8080来测试 Tomcat是否正常启动。 

Tomcat提供了两个Web界面的管理工具，URL分别是： 
http://localhost:8080/admin/index.jsp 
http://localhost:8080/manager/html 
在启用这两个管理工具之前，先需要手工配置一下管理员用户和口令。用一个文本工具打开CATALINA_HOME\conf\tomcat-users.xml这个文件，加入如下几行： 

<role rolename="manager"/> 
<role rolename="admin"/> 
<user username="robbin" password="12345678" roles="admin,manager,tomcat"/> 

这样用户“robbin”就具备了超级管理员权限。重新启动Tomcat以后，你就可以使用该用户来登陆如上的两个管理工具，通过Web方式进行Tomcat的配置和管理了。 

2、 BEA Weblogic 
Weblogic可以到BEA的网站上免费注册之后下载到最新的Weblogic8.1企业版，License可以免费使用1年时间，其实这已经完全足够了。Weblogic的下载连接：http://commerce.bea.com/index.jsp，Weblogic的在线文档： http://edocs.bea.com/ 。 

3、 IBM Webshpere 
Websphere同样可以下载到免费的试用版本，到IBM的developerWorks网站可以看到Websphere试用产品的下载和相关的Websphere的资料，developerWorks中文网站的连接是：http://www- 900.ibm.com/developerWorks/cn/wsdd/ ，Websphere的下载连接：http: //www7b.software.ibm.com/wsdd/downloads/WASsupport.html 。 

4、 Jboss 
Jboss是免费开源的App Server，可以免费的从Jboss网站下载：http: //www.jboss.org/index.html，然而Jboss的文档是不免费，需要花钱购买，所以为我们学习Jboss设置了一定的障碍。在 Jdon上有几篇不错的Jboss配置文档，可以用来参考：http://www.jdon.com/idea.html 


四、 Java应用的运行环境 

Java的应用可以简单分为以下几个方面： 

1、 Java的桌面应用 
桌面应用一般仅仅需要JRE的支持就足够了。 

2、 Java Web应用 
Java的Web应用至少需要安装JDK和一个web容器（例如Tomcat），以及一个多用户数据库，Web应用至少分为三层： 
Browser层：浏览器显示用户页面 
Web层：运行Servlet/JSP 
DB层：后端数据库，向Java程序提供数据访问服务 

3、 Java企业级应用 
企业级应用比较复杂，可以扩展到n层，最简单情况会分为4层： 
Browser层：浏览器显示用户页面 
Client层：Java客户端图形程序（或者嵌入式设备的程序）直接和Web层或者EJB层交互 
Web层：运行Servlet/JSP 
EJB层：运行EJB，完成业务逻辑运算 
DB层：后端数据库，向Java程序提供数据访问服务 

4、 Java嵌入式应用 
Java嵌入式应用是一个方兴未艾的领域，从事嵌入式开发，需要从Sun下载J2ME开发包，J2ME包含了嵌入式设备专用虚拟机KVM，和普通的JDK中包含的JVM有所不同。另外还需要到特定的嵌入式厂商那里下载模拟器。 


Java Learning Path（二）、书籍篇 

学习一门新的知识，不可能指望只看一本，或者两本书就能够完全掌握。需要有一个循序渐进的阅读过程。我推荐Oreilly出版的Java系列书籍。 

在这里我只想补充一点看法，很多人学习Java是从《Thinking in Java》这本书入手的，但是我认为这本书是不适合初学者的。我认为正确的使用这本书的方法应该是作为辅助的读物。《Thinking in Java》并不是在完整的介绍Java的整个体系，而是一种跳跃式的写作方法，是一种类似tips的方法来对Java很多知识点进行了深入的分析和解释。 

对于初学者来说，最好是找一本Java入门的书籍，但是比较完整的循序的介绍Java的语法，面向对象的特性，核心类库等等，在看这本书的同时，可以同步来看《Thinking in Java》，来加深对Java的理解和原理的运用，同时又可以完整的了解Java的整个体系。 

对于Java的入门书籍，蔡学镛推荐的是Oreilly的《Exploring Java, 2nd Edition》 或者《Java in a Nutshell,2nd Edition（针对C++背景）》，我并没有看过这两本书。其实我觉得电子工业出版社的《Java 2编程详解》或者《Java 2从入门到精通》就很不错。 

在所有的Java书籍当中，其实最最有用的，并不是O'reilly的 Java Serials，真正最最有用处是JDK的 Documentation！几乎你想获得的所有的知识在Documentation里面全部都有，其中最主要的部分当然是Java基础类库的API文档，是按照package来组织的，对于每一个class都有详细的解释，它的继承关系，是否实现了某个接口，通常用在哪些场合，还可以查到它所有的 public的属性和方法，每个属性的解释，意义，每个方法的用途，调用的参数，参数的意义，返回值的类型，以及方法可能抛出的异常等等。可以这样来说，所有关于Java编程方面的书籍其实都不过是在用比较通俗易懂的语言，和良好的组织方式来介绍Documentation里面的某个package里面包含的一些类的用法而已。所以万变不离其宗，如果你有足够的能力来直接通过Documentation来学习Java的类库，那么基本上就不需要看其他的书籍了。除此之外，Documentation也是编程必备的手册，我的桌面上有三个Documentation的快捷方式，分别是J2SDK1.4.1的 Documentation，Servlet2.3的Documentation和J2SDKEE1.3.1的Documentation。有了这个三个 Documentation，什么其他的书籍都不需要了。 

对于Java Web 编程来说，最核心的是要熟悉和掌握HTTP协议，这个就和Java无关了，在熟悉HTTP协议之后，就需要熟悉Java的实现HTTP协议的类库，也就是Servlet API，所以最重要的东西就是Servlet API。当然对于初学者而言，直接通过 Servlet API来学习Web编程有很大的难度，我推荐O'reilly的《Java Server Pages 》这本书来学习Web 编程。 

EJB的书籍当中，《Enterprise JavaBeans, 2nd Edition》是一本很不错的书， EJB的学习门槛是比较高，入门很难，但是这本书完全降低了学习的难度，特别重要的一点是，EJB的学习需要结合一种App Server的具体实现，所以在学习EJB的同时，必须同步的学习某种App Server，而这本书相关的出了三本书，分别是Weblogic6.1，Websphere4.0和JBoss3.0上面部署书中例子的实做。真是既有理论，又有实践。在学习EJB的同时，可以边看边做，EJB的学习会变得很轻松。 

但是这本书也有一个问题，就是版本比较旧，主要讲EJB1.1规范和部分EJB2.0的规范。而Ed Roman写的《Mastering EJB 2.0》这本书完全是根据EJB2.0规范写的，深入浅出，覆盖了EJB编程的各个方面，并且还有很多编程经验tips，也是学习EJB非常推荐的书籍之一。 

如果是结合Weblogic来学习J2EE的话，《J2EE应用与BEA Weblogic Server》绝对是首选读物，虽然是讲述的 Weblogic6.0，仍然值得购买，这本书是BEA官方推荐的教材，作者也是BEA公司的工程师。现在中文版已经随处可见了。这本书结合 Weblogic介绍了J2EE各个方面的技术在Weblogic平台上的开发和部署，实践指导意义非常强。 

在掌握了Java平台基础知识和J2EE方面的知识以后，更进一步的是学习如何运用OO的方法进行软件的设计，那么就一定要学习“设计模式”。 Sun公司出版了一本《J2EE核心模式》，是每个开发Java企业平台软件的架构师必备的书籍。这本书全面的介绍了J2EE体系架构的各种设计模式，是设计师的必读书籍。 

Java Learning Path（三）过程篇 

每个人的学习方法是不同的，一个人的方法不见得适合另一个人，我只能是谈自己的学习方法。因为我学习Java是完全自学的，从来没有问过别人，所以学习的过程基本上完全是自己摸索出来的。我也不知道这种方法是否是比较好的方法，只能给大家提供一点参考了。 

 其实JDK的学习没有那么简单，关于JDK有两个问题是很容易一直困扰J学习Java的第一步是安装好JDK，写一个Hello World， Java程序员的地方：一个是CLASSPATH的问题，其实从原理上来说，是要搞清楚JRE的ClassLoader是如何加载Class的；另一个问题是package和import问题，如何来寻找类的路径问题。把这两个问题摸索清楚了，就扫除了学习Java和使用JDK的最大障碍。推荐看一下王森的《Java深度历险》，对这两个问题进行了深入的探讨。 

第二步是学习Java的语法。Java的语法是类C++的，基本上主流的编程语言不是类C，就是类C++的，没有什么新东西，所以语法的学习，大概就是半天的时间足够了。唯一需要注意的是有几个不容易搞清楚的关键字的用法，public，protected，private，static，什么时候用，为什么要用，怎么用，这可能需要有人来指点一下，我当初是完全自己琢磨出来的，花了很久的时间。不过后来我看到《Thinking in Java》这本书上面是讲了这些概念的。 

第三步是学习Java的面向对象的编程语言的特性的地方。比如继承，构造器，抽象类，接口，方法的多态，重载，覆盖，Java的异常处理机制。对于一个没有面向对象语言背景的人来说，我觉得这个过程需要花很长很长时间，因为学习Java之前没有C++的经验，只有C的经验，我是大概花了一个月左右吧，才彻底把这些概念都搞清楚，把书上面的例子反复的揣摩，修改，尝试，把那几章内容反复的看过来，看过去，看了不下5遍，才彻底领悟了。不过我想如果有 C++经验的话，应该一两天时间足够了。那么在这个过程中，可以多看看《Thinking in Java》这本书，对面向对象的讲解非常透彻。可惜的是我学习的时候，并没有看到这本书，所以自己花了大量的时间，通过自己的尝试和揣摩来学会的。 

第四步就是开始熟悉Java的类库。Java的基础类库其实就是JDK安装目录下面jre\lib\rt.jar这个包。学习基础类库就是学习rt.jar。基础类库里面的类非常非常多。据说有3000多个，我没有统计过。但是真正对于我们来说最核心的只有4个，分别是 
java.lang.*; 
java.io.*; 
java.util.*; 
java.sql.*; 

这四个包的学习，每个包的学习都可以写成一本厚厚的教材，而O'reilly也确实是这样做的。我觉得如果时间比较紧，是不可能通过读四本书来学习。我觉得比较好的学习方法是这样的： 
首先要通读整个package的框架，了解整个package的class，interface，exception的构成，最好是能够找到介绍整个包框架的文章。这些专门介绍包的书籍的前几章应该就是这些总体的框架内容介绍。 

对包整体框架的把握并不是要熟悉每个类的用法，记住它有哪些属性，方法。想记也记不住的。而是要知道包有哪些方面的类构成的，这些类的用途是什么，最核心的几个类分别是完成什么功能的。我在给人培训的时候一般是一次课讲一个包，所以不可能详细的介绍每个类的用法，但是我反复强调，我给你们讲这些包的不是要告诉你们类的方法是怎么调用的，也不要求你们记住类的方法调用，而是要你们了解，Java给我们提供了哪些类，每个类是用在什么场合，当我遇到问题的时候，我知道哪个类，或者哪几个类的组合可以解决我的问题，That'all！，当我们具体写程序的时候，只要你知道该用哪个类来完成你的工作就足够了。编码的时候，具体的方法调用，是边写代码，边查Documentation，所有的东西都在Documentation里面，不要求你一定记住，实际你也记不住3000多个类的总共将近10万个方法调用。所以对每个包的总体框架的把握就变得极为重要。 

第五步，通过上面的学习，如果学的比较扎实的话，就打好了Java的基础了，剩下要做的工作是扫清Documentation里面除了上面4个包之外的其他一些比较有用处的类。相信进展到这一步，Java的自学能力已经被培养出来了，可以到了直接学习Documentation的水平了。除了要做 GUI编程之外，JDK里面其他会有用处的包是这些： 
java.text.*; 
java.net.*; 
javax.naming.*; 
这些包里面真正用的比较多的类其实很少，只有几个，所以不需要花很多时间。 

第六步，Java Web 编程 
Web编程的核心是HTTP协议，HTTP协议和Java无关，如果不熟悉HTTP协议的话，虽然也可以学好Servlet/JSP编程，但是达不到举一反三，一通百通的境界。所以HTTP协议的学习是必备的。如果熟悉了HTTP协议的话，又有了Java编程的良好的基础，学习 Servlet/JSP简直易如反掌，我学习Servlet/JSP就用了不到一周的时间，然后就开始用JSP来做项目了。 

在Servlet/JSP的学习中，重头仍然是Servlet Documentation。Servlet API最常用的类很少，花比较少的时间就可以掌握了。把这些类都看一遍，多写几个例子试试。Servlet/JSP编程本质就是在反复调用这些类来通过HTTP协议在Web Server 和Brower之间交谈。另外对JSP，还需要熟悉几个常用JSP的标记，具体的写法记不住的话，临时查就是了。 

此外Java Web编程学习的重点要放在Web Application的设计模式上，如何进行业务逻辑的分析，并且进行合理的设计，按照 MVC设计模式的要求，运用Servlet和JSP分别完成不同的逻辑层，掌握如何在Servlet和JSP之间进行流程的控制和数据的共享，以及 Web Application应该如何配置和部署。 

第七步，J2EE编程 
以上的学习过程如果是比较顺利的话，进行到这一步，难度又陡然提高。因为上面的知识内容都是只涉及一个方面，而像EJB，JMS，JTA等核心的J2EE规范往往是几种Java技术的综合运用的结晶，所以掌握起来难度比较大。 

首先一定要学习好JNDI，JNDI是App Server定位服务器资源（EJB组件，Datasouce，JMS）查找方法，如果对JNDI 不熟悉的话，EJB，JMS这些东西几乎学不下去。JNDI其实就是javax.naming.*这个包，运用起来很简单。难点在于服务器资源文件的配置。对于服务器资源文件的配置，就需要看看专门的文档规范了，比如web.xml的写法，ejb-jar.xml的写法等等。针对每种不同的 App Server，还有自己的服务资源配置文件，也是需要熟悉的。 

然后可以学习JTA，主要是要理解JTA对于事务的控制的方法，以及该在什么场合使用JTA。这里可以简单的举个例子，我们知道一般情况可以对于一个数据库连接进行事务控制(conn.setAutoCommit(false),....,conn.commit())，做为一个原子操作，但是假设我的业务需求是要把对两个不同数据库的操作做为一个原子操作，你能做的到吗？这时候只能用JTA了。假设操作过程是先往A数据库插一条记录，然后删除B 数据库另一个记录，我们自己写代码是控制不了把整个操作做为一个原子操作的。用JTA的话，由App Server来完成控制。 

在学习EJB之前要学习对象序列化和RMI，RMI是EJB的基础。接着学习JMS和EJB，对于EJB来说，最关键是要理解EJB是如何通过RMI来实现对远端对象的调用的，以及在什么情况下要用到EJB。 

在学习完EJB，JMS这些东西之后，你可能会意识到要急不可待学习两个领域的知识，一个是UML，另一个是Design Pattern。 Java企业软件的设计非常重视框架(Framework)的设计，一个好的软件框架是软件开发成功的必要条件。在这个时候，应该开始把学习的重点放在设计模式和框架的学习上，通过学习和实际的编程经验来掌握EJB的设计模式和J2EE的核心模式。 

J2EE规范里面，除了EJB，JMS，JTA，Servlet/JSP，JDBC之外还有很多很多的企业技术，这里不一一进行介绍了。 

另外还有一个最新领域Web Services。Web Services也完全没有任何新东西，它像是一种黏合剂，可以把不同的服务统一起来提供一个统一的调用接口，作为使用者来说，我只要获得服务提供者给我的WSDL（对服务的描述），就够了，我完全不知道服务器提供者提供的服务究竟是EJB 组件，还是.Net组件，还是什么CORBA组件，还是其他的什么实现，我也不需要知道。Web Services最伟大的地方就在于通过统一的服务提供方式和调用方式，实现了整个Internet服务的共享，是一个非常令人激动的技术领域。Web Services好像目前还没有什么很好的书籍，但是可以通过在网络上面查资料的方式来学习。 

Java Learning Path（四） 方法篇 

Java作为一门编程语言，最好的学习方法就是写代码。当你学习一个类以后，你就可以自己写个简单的例子程序来运行一下，看看有什么结果，然后再多调用几个类的方法，看看运行结果，这样非常直观的把类给学会了，而且记忆非常深刻。然后不应该满足把代码调通，你应该想想看如果我不这样写，换个方式，再试试行不行。记得哪个高人说过学习编程就是个破坏的过程，把书上的例子，自己学习Documentation编写的例子在运行通过以后，不断的尝试着用不同的方法实现，不断的尝试破坏代码的结构，看看它会有什么结果。通过这样的方式，你会很彻底的很精通的掌握Java。 

举个例子，我们都编过Hello World 

public class HelloWorld { 
public static void main(String[] args) { 
System.out.println("Hello World"); 
} 
} 

很多初学者不是很理解为什么main方法一定要这样来定义public static void main(String[] args)，能不能不这样写？包括我刚学习Java的时候也有这样的疑问。想知道答案吗？很简单，你把main改个名字运行一下，看看报什么错误，然后根据出错信息进行分析；把main的public取掉，在试试看，报什么错误；static去掉还能不能运行；不知道main方法是否一定要传一个String[]数组的，把String[]改掉，改成int[]，或者String试试看；不知道是否必须写args参数名称的，也可以把args改成别的名字，看看运行结果如何。 

我当初学习Java的时候就是这样做的，把Hello World程序反复改了七八次，不断运行，分析运行结果，最后就彻底明白为什么了main方法是这样定义的了。 

此外，我对于staic，public，private，Exception，try{ }catch {}finally{}等等等等一开始都不是很懂，都是把参考书上面的例子运行成功，然后就开始破坏它，不断的根据自己心里面的疑问来重新改写程序，看看能不能运行，运行出来是个什么样子，是否可以得到预期的结果。这样虽然比较费时间，不过一个例子程序这样反复破坏几次之后。我就对这个相关的知识彻底学通了。有时候甚至故意写一些错误的代码来运行，看看能否得到预期的运行错误。这样对于编程的掌握是及其深刻的。 

其中特别值得一提的是JDK有一个非常棒的调试功能，-verbose 
java –verbose 
javac –verbose 以及其它很多JDK工具都有这个选项 
-verbose 可以显示在命令执行的过程中，JVM都依次加载哪里Class，通过这些宝贵的调试信息，可以帮助我们分析出JVM在执行的过程中都干了些什么。 

另外，自己在学习过程中，写的很多的这种破坏例程，应该有意识的分门别类的保存下来，在工作中积累的典型例程也应该定期整理，日积月累，自己就有了一个代码库了。遇到类似的问题，到代码库里面 Copy & Paste ，Search & Replace，就好了，极大提高了开发速度。最理想的情况是把一些通用的例程自己再抽象一层，形成一个通用的类库，封装好。那么可复用性就更强了。 

所以我觉得其实不是特别需要例程的，自己写的破坏例程就是最好的例子，如果你实在对自己写的代码不放心的话，我强烈推荐你看看JDK基础类库的 Java源代码。在JDK安装目录下面会有一个src.zip，解开来就可以完整的看到整个JDK基础类库，也就是rt.jar的Java源代码，你可以参考一下Sun是怎么写Java程序的，规范是什么样子的。我自己在学习Java的类库的时候，当有些地方理解的不是很清楚的时候，或者想更加清晰的理解运作的细节的时候，往往会打开相应的类的源代码，通过看源代码，所有的问题都会一扫而空。 

Java Learning Path（五）资源篇 

1、 http://java.sun.com/ (英文) 
Sun的Java网站，是一个应该经常去看的地方。不用多说。 

2、http://www-900.ibm.com/developerWorks/cn/ 
IBM的developerWorks网站，英语好的直接去英文主站点看。这里不但是一个极好的面向对象的分析设计网站，也是Web Services，Java，Linux极好的网站。强烈推荐！！！ 

3、http://www.javaworld.com/ (英文) 
关于Java很多新技术的讨论和新闻。想多了解Java的方方面面的应用，这里比较好。 

4、http://dev2dev.bea.com.cn/index.jsp 
BEA的开发者园地，BEA作为最重要的App Server厂商，有很多独到的技术，在Weblogic上做开发的朋友不容错过。 

5、http://www.huihoo.com/ 
灰狐动力网站，一个专业的中间件网站，虽然不是专业的Java网站，但是在J2EE企业应用技术方面有深厚的造诣。 

6、http://www.theserverside.com/home/ (英文) 
TheServerSide是一个著名的专门面向Java Server端应用的网站。 

7、http://www.javaresearch.org/ 
Java研究组织，有很多优秀的Java方面的文章和教程，特别是在JDO方面的文章比较丰富。 

8、http://www.cnjsp.org/ 
JSP技术网站，有相当多的Java方面的文章和资源。 

9、http://www.jdon.com/ 
Jdon论坛，是一个个人性质的中文J2EE专业技术论坛，在众多的Java的中文论坛中，Jdon一个是技术含量非常高，帖子质量非常好的论坛。 

10、http://sourceforge.net/ 
SourgeForge是一个开放源代码软件的大本营，其中也有非常非常丰富的Java的开放源代码的著名的软件。

----注：本文内容转自“chinabear2008的个人空间”

微软的软件测试方法
 国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。
    作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考，更有利于发现问题的根源。即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。
    微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。
    两类经典的软件测试方法
    在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。
    传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。
    提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel（代表论著《The Complete Guide to Software Testing》），他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。他首先在1973年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do.”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。

续：

第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。
    在软件行业中一般把第一类方法奉为主流和行业标准。1990年的IEEE/ANSI标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。The
process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std
610.12-1990]”这里所谓“既定的状况”也可理解为需求或设计。
    尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。他还从人的心理学的角度论证，将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“就是以发现错误为目的而运行程序的过程。The process of executing a program or system with the intent of finding errors.”
    这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。他甚至极端地认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。我并不完全同意这一看法。
    第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。大家熟悉的Ron Patton在《软件测试》（中文版由机械工业出版社出版，具说此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”有些软件企业以Bug数量来作为考核测试人员业绩的一项指标，其实就是接受了这样的方法。
    两类方法的优劣对比
    虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。
    第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。
    第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高（关于测试的层次问题，我会在今后的讨论中专门介绍）。第二类测试方法不具备这种过程的渐进性。
    第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，正像Myers先生所说，不容易找到软件的错误（Bug）。而这方面正是第二类测试方法的长处。
    微软的策略
    正是因为认识到两类测试方法各有利弊，微软在软件测试活动中将两类方法结合起来，以第一类测试方法为基础和主要线索，阶段性地运用第二类测试方法。
    微软的第一类测试
    微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。
    前文已述，第一类测试是以需求和设计为本来验证软件的正确性。大家很自然的想到，需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。有必要指出的是，这里所说的需求和设计具体说来它一般包括：（1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement   Specification）；（2）由项目经理根据需求文本而编写的功能设计文本（Functional Design     Specification）；（3）由开发人员根据功能文本而编写的实施设计文本（Implementation Design       Specification）。微软的测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。
    第二步，测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。原因很简单，这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。从这里大家可以看出这是典型的“黑盒测试”。确实微软的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划”
    文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。
    第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行，在前面我已提到，这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。可见Myers的理论在这里是不适用的。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（在微软这是常事），所涉及的测试用例当然也要相应地修改。
    微软的第二类测试
    微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“BugBash（Bug大扫除）”。BugBash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
    微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。一般会邀请公司内部，或业界的专家来搜寻产品的安全漏洞。
    以上我从传统软件测试概念的角度，介绍了微软的策略和两类传统测试方法的具体做法，及其侧重点。这其实仅仅是一个基础，一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的，也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法，和概念上的突破，比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍。   
    ２００４年１１月１８日
    我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法，其基本思想大家应该是比较熟悉的，因为它们还只是传统的软件测试方法的综合。所以单从形式上，它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时，你会对一些基本的事实感到惊讶。比如，“微软的测试人员和开发人员数量大致相等或略多”，“微软的产品成本中测试大约占40%以上”等等。人们会有疑问，仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗？有必要付出如此大的代价吗？应该有理由相信，微软作为一个软件企业，其每一份投入都是有意义的，因此也可断定微软在软件测试方面的努力一定超出传统测试方法的范畴。
    历史回顾
    为了更好的理解微软件测试在方法和理念上的突破，我想首先回顾一下软件开发和软件测试的发展历史，并从中揭示其必然性。Edward Kit 在他的畅销书“Software Testing In The Real World : Improving The Process（1995，ISBN: 0201877562）”中将整个软件开发历史分为三个阶段 ： 第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。
    第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。      
    第三个阶段是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。与之相应，人们为软件开发设计了各种复杂而精密的流程和管理方法（比如CMM和MSF），并将“质量”的概念融入其中。软件测试已有了行业标准（IEEE/ANSI），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。
    测试与开发的融合
    在这一历史发展过程中，最值得注意的是测试与开发流程融合的趋势。人们对这种融合也许并不陌生。比如测试活动的早期展开，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。再比如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。
    开发对测试的依赖

续2

现代软件开发，特别是大型软件开发通常会遇到以下两个问题：      
      （1）在开发初期，如何能够展开大规模团队，群体齐头并进，而同时保持开发的有序性。从而有效利用资源，缩短开发周期。
      （2）在开发后期，如何解决深层次的Bug，如何面对设计更改，而能够保证产品的质量不出现或少出现回落。对于小型简单的软件，这两个问题也存在，但不突出，而且容易解决。但对于复杂的大型软件的开发，这两个问题常常会成为难以逾越的障碍。      
    通常大型项目的功能丰富，但架构、层次也会相当复杂。稳妥的开发方式是，一次投入少量的人员，逐层开发，逐层稳定。但这种方式显然资源利用率低，开发周期长，不能满足现代软件和IT行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软，产品开发团队（主要包括开发、测试和项目管理）一般都有百人以上规模，有些产品甚至上几千人（Windows2000的开发部门曾有3000多人）。这样大规模的人力资源作用在一个动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样的关系，而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时，他（或她）常常无法确定，或无法完全确定究竟有哪些相关的模块会受到影响，以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。
    在微软，这种协调是通过测试来实现的。具体来说就是：每日建造+自动化测试。关于每日编译和自动化测试，我将来会作专门介绍，这里简单的说就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。这里所说的质量当然有一般意义上质量的概念，但同时它也反映项目在开发过程中的整体协调性。
    自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量（事后检查），也可以在当天存入代码前，先运行自动测试以进一步确保存入代码的质量（事前检查）。
    在微软，每日建造都是在午夜开始，完成后紧接着就是全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。
    当开发进入后期阶段，尽管项目已总体成型，开发人员也会不时遇到一些技术上的挑战。比如一些Bug的解决涉及对项目深层次结构的调整；再比如由于客户反馈的意见造成设计的修改。每一次这样的修改和调整事实上都是对一个稳定系统的破坏，如果处理不当往往一个Bug的修改会生成很多新的Bug，就像一系列联锁的恶性循环。很多项目工期的延误都是这样造成的。要避免或至少将这种破坏减少到最低限度，开发人员首先需要知道这种破坏的影响面。在这里单靠开发人员自身的逻辑思维、技能和经验是远远不够的，自动测试再一次成为一种有效的工具。往往开发人员会制定不止一个方案，对每个方案上都运行一遍同样一套自动测试用例，然后比较结果，选出最佳方案。自动测试在这方面所起的作用不仅在产品的开发过程中，它还延续到产品发布后。产品支持部门在为客户提供应急解决方案时也要依赖自动测试。
    管理对测试的依赖
    在微软，软件项目管理的主要线索就是Bug的管理，其中最直接具体的管理活动就是“Bug三方讨论会（Bug
Triage）”。会议一般由项目管理Program Manager（简称PM）来主持，有开发人员和测试人员参加（所以叫三方会议）。会上对每个新生成的Bug进行讨论，并决定（1）是否接受这个Bug；（2）Bug的严重级别和优先级别；（3）Bug由谁来负责，是由测试提供进一步详细信息，还是交由开发人员解决，以及大致的解决方案等等。会议还要对老的Bug检查解决进度。这种讨论会常常会发生争论，要求测试人员具有足够的技术基础和用户经验，来捍卫产品的质量。可以说项目开发到了某一阶段后就是由这种Bug的管理所驱动的。这其中的原动力来自测试。
      
   项目管理中一项非常重要但也十分困难的工作是衡量项目的进度，包括判断项目的状态，确定项目是否能预期完成。这方面，测试提供了两个非常重要的参数，一个是Bug数量的趋势，另一个是测试结果的趋势。
   Bug趋势就是将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的Bug所造成的项目质量的波动。
    每天的自动测试结果同样可以形成类似的图表。它同样非常有助于了解当前项目的质量状况，开发测试进度。由测试产生的这些数据不仅在项目开发过程中为项目管理提供有效的依据，而且也是产品通过发布的必要条件。在微软，每个产品都要经过评审才能通过发布。前面介绍的几个图表是发布评审的重要内容，如果从图表中发现临评审前还出现过较大的质量波动，评审人员一定会对此提出质疑。因此软件项目管理依赖软件测试提供其基本的管理素材。
    可以说，现代大型软件开发过程中开发和管理对测试的依赖性是测试与开发流程融合的一个根本因素。从另一个角度看，测试与开发流程融合决不仅仅是简单的时间上的同步，更不是双方空间上的接近，而是这种内在的依存关系的外在表现。开发对测试的这种依赖性对测试和测是人员提出了更高的要求。在理念上，软件测试已远不仅仅只是软件功能的验证和Bug的搜寻；在具体方法上，自动测试和测试工具的使用已成为基本的要求。在微软，测试不仅使用一些通用的工具，每一个产品还有专门开发的专用工具库，测试的代码量常常超过项目本身的代码量。
    一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。

    五级的具体定义如下:

    初级(initial)：软件开发过程中偶尔会出现混乱的现象,只有很少的工作过程是经 过严格定义的,开发成功往往依靠的是某个人的智慧和努力。 

    可重复的(repeatable)：建立了基本的项目管理过程。按部就班地设计功能、跟踪 费用 ,根据项目进度表进行开发。对于相似的项目,可以重用以前已经开发成功的部分。

    被定义的(defined.)：软件开发的工程活动和管理活动都是文档化、标准化的,它 被集成为一个组织的标准的开发过程。所有项目的开发和维护都在这个标准基础上进行定 制。

    被管理的(managed.)：对于软件开发过程和产品质量的测试细节都有很好的归纳, 产品和开发过程都可以定量地分解和控制。

    优化的(optimizing)：通过建立开发过程的定量反馈机制,不断产生新的思想,采用 新的技术来优化开发过程。
/Q l._4a0O3I-w7F0 
r^@a L~0    模型的等级从低到高，可以预计企业的开发风险越来越低，开发能力越来越高。除模型的第1级外，其他每个等级都由不同的过程区域构成，而每个过程区域又由各种目标构成，每个目标由各种实践支持（实践分为该目标特有的特殊实践和各种目标均适用的通用实践两种形式）。51Testing软件测试网(c8Z3I9i6i&E~~
 51Testing软件测试网+BJ7I9O-P2?m
     一个组织只要开始从事软件开发，即自动处于第1级，要通过其他等级，就需要达到统一的标准，即相对应等级中的各个区域过程。
Y?e^Tgh_0 51Testing软件测试网9Z?S$u6x_
     CMM2级过程区域有7个：需求管理、项目策划、项目监督和控制、供方协定管理、测量和分析、过程和产品质量保证、配置管理。
L*O$bKBR c0 
SL(O.iQ-mo E@ f J"{0     CMM3级过程区域有11个：需求开发、技术解决、产品集成、验证、确认、组织过程聚焦、组织过程定义、组织培训、集成项目管理、风险管理以及决策分析和决定。 51Testing软件测试网HV R,Ym-?S{
     CMM4级过程区域有2个：组织过程性能和定量项目管理。
MeOc2C0     CMM5级过程区域有2个：组织革新和部署、原因分析和决定。51Testing软件测试网 Z:U8k/Pn`2Ta/g9i
     当一个软件组织按照CMM的要求贯彻活动，并达到预期的效果，该组织就可以被认为是达到CMM的要求。

    cmm和iso9001的出发点都是通过对生产过程进行管理,来确保产品的质量。虽然它们 之间有很多区别,但也有相似之处。比如,通过iso9001认证的组织,可以基本满足cmm二级 的标准和很多cmm三级的要求。因为cmm中的很多要求并没有列入iso9000标准之中,所 以,cmm一级的组织也可能获得iso9001的登记,defined.同样,有些iso9001规定的内容并没 有列入cmm标准。一个cmm三级组织获得iso9001认证几乎没有困难,cmm二级组织申请 iso9001认证也有明显优势。51Testing软件测试网*xN9PTy
t.? zYv ]
    引进CMM的意义有两个方面
:P;NX5X#XG0 
k f&Cb*MK0１．对软件企业： 提高软件开发的管理能力：CMM提供了软件企业自我评估的方法和自我提高的手段；提高软件生产率；加强软件生产的国际竞争力。
~Ao9r$d2Kf0 
:u1z;s;w)}Y$|0２．对软件项目发包单位和软件用户： 提供了对软件开发商开发管理水平的评估手段，有助于软件开发项目的风险识别。
+dOYLb0 51Testing软件测试网#NY/i8R_ a/V
    何谓CMMI？
0l S"i{;h1c!f,cY+hE W0     CMMI全称是Capbility Maturity Model Integration，即集成的能力成熟度模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制，与2002年4月推出了系统工程和软件工程的集成成熟度模型。CMMI是一套融合多学科的、可扩充的产品集合，同时也是工程实践与管理方法。 51Testing软件测试网P@2U7NK3f6h
　　CMMI能够解决现有的不同CMM模型的重复性、复杂性，并减少由此引起的成本、缩短改进过程，她将软件CMM2.0版草案(SW-CWW)、EIA过渡标准731(系统工程CMM)及IPD-CMM集成为一体，同事还与ISO15504相兼容。与原有的能力成熟度模型CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。

　　CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴——工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。

　　那么CMMI究竟是什么呢？它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。

　　CMMI与CMM的区别呢？CMMI即CMM集成，是系统工程和软件工程的集成成熟度模型，CMMI更适合于信息系统集成企业。CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。

    1.在任何情况下都必须使用边界值分析方法，经验表明，用这种方法设计的测试用例发现错误的能力最强。

    2.用等价类方法补充一些测试用例。

    3.用错误猜测方法再追加一些测试用例。

    4.如果程序的功能说明书中含有输入条件的组合情况，应在一开始就使用因果图法。

    5.如果程序的某功能适合自动测试，则可采用自动测试方法和随机测试方法进行测试。

    6。获得需求说明书的软件可以采用测试大纲的方法。

    7.对于流程类软件可以采用状态图的方法。   

做测试已经近六年了。在测试技术方面的技能长进了不少，又能享受写代码的乐趣，同事们经常交流对软件测试技术的见解，也在项目中实现一些创新的测试技术和基于自己的想法设计好的测试框架，每天过的很开心。随着对测试这个职业的了解越来越深，对微软测试技术的掌握越来越多，慢慢地，人就开始对那些测试“大牛”在做什么感兴趣了。他们就是那些在公司内部挂着“测试架构师”头衔的一小撮人。They are Test Architects。

什么？你的公司还有测试架构师这么一说？呵呵，好像很多人都会这么问吧。大家听架构师听多了。比如我们头比尔的头衔就是“微软首席软件架构师”。一般来说，说到架构师，人们想到的都是“软件设计架构师”，那些设计整个产品架构，决定各模块如何协调工作，决定采用何开发平台的大师（对不起，可能每个人对大师的定义不同，如果你心目里只有Lippman, Stroustrup, Anders这样的人才能称为大师，那么原谅我的定义，我的大师就是那些杰迪武士里的Master，他们中有些人是Yoda/Anakin这样实力超人的，但也有一些普通的我们每天都可以从他们身上学到不少东西的人，我愿意把后者也叫大师。）。那么“测试架构师”，他们是些什么人?他们凭什么拿着和设计架构师一样的薪水?我们怎样成长为测试架构师呢？我也是带着这样的一个个问题，在雷德蒙总部有幸遇到一个测试架构师艾德的。那天，大晴，有利西方。

测试架构师，这里我更多的是讨论这个角色的职责，而不是这个头衔本身。所以也许你已经扮演了这个角色，但没有这个头衔。但这不妨碍我们讨论测试架构师在做什么。

如果你是一名测试架构师，那意味着你有很多事情可以做，虽然你不一定都做：开发和设计测试框架测试库；纵横全局的考虑产品的功能，设计复杂的测试系统；负责研发某一项特定的测试技术；为你的公司考虑如何提高测试效率；但总的来说，我们可以这样描述：测试架构师领导公司测试技术的发展和测试策略上的方向。区别一个测试架构师和普通测试工程师的特质是：他关注的是一个功能模块，一条产品线，还是整个公司的测试部门的问题。甚至对于一些更加资深的测试架构师，他们已经不再局限于产品当前版本的测试，他们可以前瞻性的考虑未来的版本的测试策略和技术。

测试架构师的角色可以和设计架构师的角色互相比较着看，设计架构师，计划/设计一个产品，关注着产品的研发过程。同样的，测试架构师他们计划/设计测试平台，关注着产品的测试过程。（废话而且拗口是吗？：））但他们倒是有一个让我们IT民工羡慕的共同特点，他们更多的是提供咨询服务，并不亲身去帮你写完每一行代码。他们的工资不由他们敲多少字决定。呵呵。测试架构师具备测试技术测试方法学上雄厚的知识，不仅仅是公司内部的知识，也包括公司外部的知识。所以他们具备实力给那些测试经理们提供“咨询”服务，告诉他们，什么样的测试技术什么样的测试平台会符合公司要测得产品，什么样的软件流程可以更好的保证软件质量。那有人会自然想到，这不是测试经理的事情吗？不然，测试经理，我们都是知道，人一到了“经理”这个位置，杂事就多了，员工加薪，员工福利，办公室装修，测试实验室购买新机器。什么事情都可能找到测试经理头上。测试经理的主要责任，应该是领导和培养一个优秀的测试团队。所以领导和培养是他的重点。对于剩下得测试技术测试策略上的任务，这时候他身边的测试架构师就起到了辅佐的作用。我觉得，这样的一个解释可以让很多测试经理如释重负，把技术和管理的重担全部依赖在测试经理的身上，有点不近人情了。呵呵。

测试架构师不仅仅是需要影响到公司内的测试机构测试社区，还需要影响开发机构甚至市场部门，好的测试架构师，可以从保证质量的角度，对产品的研发销售各个方面施加深远而正确的影响，也吸收来自各个部门的建议，最终提高整体软件质量。所以说一个优秀的测试架构师，也可以是一个不错的设计架构师，不错的用户需求分析师。因为软件质量保证是一个贯穿需求分析、设计、测试整个软件项目的过程。做好测试架构师，就要求你能够驾驭软件项目各个阶段。所以对开发和其他部门的熟悉是必不可少的

前面说了这么多软件测试架构师“做”什么，最后我们谈谈哪些是他们“不做”的：

1，他们不是项目经理，虽然前面说了很多软件测试架构师对项目的各个方面施加影响，但是他们不是项目经理。一个纯粹的项目经理要考虑的事情还有很多很多，如果一个测试架构师最后扮演了项目经理的角色，那么对项目还是对测试架构师，都是不益的。

2，测试架构师不是一个水到渠成的头衔，不是你做了很多年测试，对产品很了解，就自然成为了测试架构师。你需要有足够的技术前瞻能力和对公司内的影响力以达到对产品测试策略和技术方向提供咨询。

3，不只是一个纯粹的软件测试技术编程高手，一个测试架构师的存在是为了解决实际项目产品中的测试问题，并不是一个纯粹的测试技术编程爱好者。一个热衷于单元测试开发框架的人，可以是一个编程好手，但未必是公司需要的测试架构师。一个架构师，对技术和测试策略测试方法学都能在解决实际问题上运用娴熟

LoadRunner设置相关

1>     Run time setting设置中的Browser：‘Simulate a new user on each iteration’选项
例如：录制了一个脚本，设置了100个VU，每个VU的迭代次数为10次，正确运行时应该在系统中生成100×10条记录，但是，运行后发现这100个VU都只运行了一次，最终生成了100条记录。
原因是：
选中了Simulate a new user on each iteration，如果选中这一项，在两次迭代之间LR清除了cookie。
也可以把‘Clear cache on each iteration’取消选中
2>     录制脚本时在Recording option中的设置Recording项目
¨   HTML-base方式：
HTML-based 方式对每个页面录制形成一条语句，对LoadRunner来说，在该模式下，访问一个页面，首先会与服务器之间建立一个连接获取页面的内容，然后从页面中分解得到其他的元素（component），然后建立几个连接分别获取相应的元素
¨   URL-base方式
URL-based 方式将每条客户端发出的请求录制成一条语句，对LoadRunner来说，在该模式下，一条语句只建立一个到服务器的连接，LoadRunner提供了web_concurrent_start和web_concurrent_end函数模拟HTML-based的工作方式
在录制脚本时选择那种方式呢：
¨       如果应用是WEB应用，首选是HTML-based方式
¨       如果应用是使用HTTP协议的非WEB应用，首选是URL-based方式
¨       如果WEB应用中使用了java applet程序，且applet程序与服务器之间存在通讯，选用URL-based方式
¨       如果WEB应用中使用的javascrīpt、vbscrīpt脚本与服务器之间存在通讯（调用了服务端组件），选用URL-based方式

在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。
前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：
通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：
“要求系统支持 100 个并发用户”
看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。
事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。
因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。
对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：
“要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )
面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。
因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。
最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。

原文:

各位高手，我是刚开始参加测试工作不久的新人，主要是负责集成测试，我以前有一些系统测试的经验。但是，做集成测试时就很迷茫。
      不论国内外，讲集成测试的文章都太少了，而且大都都只是讲了概念性的东西，不太实用。
      写测试用例时，我总会有意无意的把集成测试和系统测试混淆起来，（我主要是做黑盒测试，）我觉得两者的用例都是基于功能测试，虽然说集成测试会侧重于接口方面，但是在我看来，它只会比系统测试多了一检测接口的内容，而其他的，例如模块功能之类方面的测试都是不能少的。因为集成测试在描述中也说到，需要检测各个功能模块在集成后是否正常。。。就是说，我还是需要，每个小角落的去看啊。。。。
      所以，我写用例的时候就会很迷茫，我到底在写的是集成测试，还是系统测试的用例呢？
      有人告诉我说，他们的用例可以相同，只是在施行时有所区别。系统测试采用的是可以通过可视界面检测的黑盒测试，而集成测试要采用深入代码的白盒测试，所以集成测试有时被称作灰盒测试。这种说法，让我再次迷惘。。。难道，集成测试就不能通过黑盒测试进行吗？但是，我在网上看到说：集成测试正逐渐从白盒测试向黑盒测试转变。
      说了那么多混乱的东西，其实我是有几个困惑了我几个月的问题，希望各位高手可以帮忙解答一下：
          1、我对集成测试的认识是否有偏差了？
          2、就用例书写方面，集成测试和系统测试到底有什么明显区别？
          3、集成测试的用例应该从哪里着手写？从什么点切入？是不是一定要把代码研究透了，才能写？那，还叫黑盒测试吗？         

Re:

我以为简单可以这样分：
系统全部组装完毕后的测试是系统测试。
之前的都可以叫做集成测试。

集成测试可分为两种：手工黑盒和代码灰盒。
手工黑盒测试就这样了，与后续的系统测试用例存在重用。
代码灰盒是指针对组件的接口采用代码调用的方式来测试，一般不会走到白盒，即不关心组件内部是如何实现，只关心组件的接口。

集成测试的组成以及流程

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

      集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

      集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

      集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。

      所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。

      集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

      集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

一、集成测试过程

二、单元测试工作内容及其流程

三、集成测试需求获取

      集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。集成测试需求主要来源于设计模型（DESign Model）和集成构件计划（Integration Build Plan）。集成测试着重于集成版本的外部接口的行为。因此，测试需求须具有可观测、可测评性。

      1． 集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。

      2． 由集成工作版本的外部接口确定集成测试用例。

3． 测试用例应覆盖工作版本每一外部接口的所有消息流序列。

     注意：一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。

四、集成测试工作机制

      软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示：

      软件评测部：

      软件项目组：

      集成测试工作内容及其流程工作流程：

五、集成测试产生的工件清单

      1、 软件集成测试计划
      2、 集成测试用例
      3、 测试过程
      4、 测试脚本
      5、 测试日志
      6、 测试评估摘要

六、集成测试常用方案选型

      集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、BIg-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。在此，笔者将重点讨论其中一些经实践检验和一些证实有效的集成测试方案。

      ·自底向上集成测试

      自底向上的集成（BOttom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。自底向上集成测试的步骤大致如下:

      步骤一: 按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。图2给出了自底向上的集成测试过程中各测试活动的拓扑关系。利用图论的相关知识，可以排出各活动之间的时间序列关系，处于同一层次的测试活动可以同时进行，而不会相互影响。

      步骤二: 在步骤一的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。

      步骤三: 将各软件模块集成为子系统（或分系统）。检测各自子系统是否能正常工作。同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。

      步骤四: 将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。

      方案点评: 自底向上的集成测试方案是工程实践中最常用的测试方法。相关技术也较为成熟。它的优点很明显: 管理方便、测试人员能较好地锁定软件故障所在位置。但它对于某些开发模式不适用，如使用XP开发方法，它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。尽管如此，自底向上的集成测试方法仍不失为一个可供参考的集成测试方案

核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。其步骤如下:

      步骤一: 对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块;

      步骤二: 对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。

      步骤三: 按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件部件的集成。

      步骤四: 在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。

      步骤五: 按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。

      方案点评: 该集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。

      ·高频集成测试

      高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件: 可以持续获得一个稳定的增量，并且该增量内部已被验证没有问题; 大部分有意义的功能增加可以在一个相对稳定的时间间隔（如每个工作日）内获得; 测试包和代码的开发工作必须是并行进行的，并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本; 必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁，显然，人工的方法是不胜任的。

      高频集成测试一般采用如下步骤来完成:

      步骤一: 选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。

      步骤二: 设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。如使用CVS进行版本控制。

      步骤三: 测试人员和开发人员负责编写对应程序代码的测试脚本。

      步骤四: 设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。

      步骤五: 测试人员监督代码开发人员及时关闭不合格项。

      按照步骤三至步骤五不断循环，直至形成最终软件产品。

      方案点评: 该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。

以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。

附：集成测试计划书 模版

原创作者：jerry
转载请注明：来自SAwin系统分析之窗
最后修改时间：2005-4-27

1引言
1.1编写目的
本文是描述****集成测试的大纲文章，主要描述如何进行集成测试活动？如何控制集成测试活动？集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人，集成部门经理，集成测试设计师。
1.2背景
项目名称：***集成测试
项目相关对象：******************
1.3定义
**********：********************
1.4参考资料
《*********》
2测试项目
本测试主要为***系统的集成测试，目前***的版本为2.0,测试是***的最终集成测试，是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上
3 被测特性
3.1操作性测试
主要测试操作是否正确，有无误差？分为两部分：
3.1.1返回测试
由主界面逐级进入最终界面，按EXIT键逐级返回，检查返回时候屏幕聚焦是否正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按EXIT键返回，检查当前聚焦是否为“频道搜索”
5. 按EXIT键返回，检查当前聚焦是否为“系统设置”
3.1.2进入测试
由主界面逐级进入最终界面，按MENU键返回主界面，再次进入，检查是否聚焦正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按MENU键返回主界面
5. 当前聚焦是否为“系统设置”
6. 进入“系统设置”，当前聚焦是否为“频道搜索”
3.2功能测试
测试机顶盒中每个应用的功能是否正确
3.3性能测试
3.3.1疲劳性测试
测试连续开机1个月不关机器，每3天去运行一次应用。看系统的稳定性
3.3.2大容量数据测试
前段***数据库表中含有大量数据，测试***功能
4 不被测特性
5 测试方法
1. 书写测试计划
2. 审核测试计划，未通过返回第一步
3. 书写测试用例；
4. 审核测试用例，未通过返回第三步
5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）
6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW）
7. 集成部经理接到bugzilla发过来的bug
7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）;
7.2 对于不是bug

已经很久没有写过case了,结合以前编写用例的一些经验，其实觉得编写用例也还是有流程可走的（当然不是按照教科书上说的那样进行用例设计，姑且不说有多少企业会有那么详细的需求书，会有多少时间让你去写完善，非常详细的测试用例，反正我是感觉项目中写用例的时间非常短），总结自己的一些经验，不单单是用例设计，还涉及到一些其他方面。

简单7个步骤：

1、理清模块需求：

   ----由于项目需求说明书不详细，而且没有进行需求评审的情况下，在拿到上级lead给的测试任务后，一拿到先别着急去写测试用例，首先你应该做的是，根据有限的模块需求说明进行深入理解模块的功能，流程，以及涉及到的其他功能，记录下来。发送给该模块的开发人员，询问他你理解的是否和他设计的有差错，虽然说开发人员可能对整个需求不情况，但是对自己要开发的模块肯定还是能说出个大概来。

2、测试需求提起

-----在经过和相对应的开发人员简单交流后，就可以根据得到文档进行测试需求提起了，原则是从大到小，大模块一直分解到最小部分模块。整理一份模块测试需求书

3、设计测试思路

-----测试需求书完成后，就可以设计测试思路，这里的设计思路并不是说写测试用例，而是一个总的思路说明；

举个例子：

如大家都熟悉的软件升级功能，可以向下面一样简单列出测试思路

正常情况：

1、软件在网络链接好的情况下升级正常

2、最新版本的软件不能进行升级，升级会有提示

3、试用期的软件不能升级

4、升级过程中能正常取消，而且不会影响到软件

异常情况：

1、在网络速度非常缓慢情况下的升级

2、在网络时断时续情况下进行升级

3、系统电脑系统资源消耗严重情况下升级

4、升级过程中进行断电，断网，关机等操作

5、下载过程中强制推出软件

6、多个客户同时进行升级，查看升级服务器的性能

上面只是简单列出一些思路，还有很多。在列出测试思路后，如果时间的话可以组织测试人员和开发人员进行头脑风暴，因为一个人的思路是有限的，开发人员可以从开发的角度考虑有那些地方需要重点考虑的，其他人员也会有自己的想法。

在上面的例子中，我们还可以想到，网络是代理的情况，下载的文件大小情况，服务器支持的最大用户同时升级，软件下载是否支持断点续传等，，

4、测试用例编写

----头脑风暴完成后，就可以整理出一份测试思路，最好在设计测试用例模板时考虑到这点，只有把思路记录下来，在后面的详细用例编写中才不会忘记，在后期的维护用例中也可以快速掌握用例情况。后面会有一份测试用例模板

对于测试用例编写，本人用的是自己归纳的一个通用模式

解释上面的图：

由于本人测试的程序是C/S结构的，大部分都是在这三个操作系统下进行。如果产品是B/S结构的话，可能在winxp,win2000与win2003后面还要增加一列，就是各种不同的浏览器，

这样编写用例的好处就是层次分明，比如后面产品需要修改界面而不涉及到功能时，就可以快速找到进行用例修改。模块功能的用例大部分就是来自第三点的测试思路，只是进行扩充编写吧了。

其他的详细编写用例技巧就不说了，网络上很多资料，肯定比我写的好。我的宗旨就是用例编写前先要做到层次分明，心中有数写那些方面。其他就是慢慢扩充。

5、测试用例评审

---------这一步就不说了，如果有时间的话最好做详细的用例评审，没有时间的话也要进行测试内部人员相互查看各自的用例，提出各自的意见。

6、执行用例

--------这一步是最好检验测试用例编写的水平了，交叉进行用例执行。

7、用例效率计算

-------这一步对有很好测试管理工具的公司来说，可能没有用处。这里是根据公司进行设计的，由于公司不是很大，也没有用大型商业测试管理工具，所以一下用例效率都可能必须手动，公司用JIRA管理BUG，用例和需求都是通过EXECL进行管理。在需求与用例之间暂时没有想到好的方法，用例与BUG对应已经想出方法了，在下面的的用例模板中有。

虽然说对应比较简单，但是比较实用，能够快速反应出用例设计的质量，以及用例是否遗漏了。

这份文档写完了，既不能算是测试用例的管理，也不能算是用例设计技巧，管他呢？当作自己的总结。

测试用例模板

今天有同行在blog上留言，问“想从功能测试转向性能测试，但不知道需要哪些了解哪些知识，及怎样进行一个系统的学习”。这类问题之前也被问到很多次了，所以这次干脆整理一下，发个主题供同行们参考。如果需要补充，也欢迎大家留言一起讨论。

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

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. 积极的参与到各类圈子、社团的讨论和交流、分享中。

另外，我之前也整理发布过不少性能测试方面的资料，从入门级的文章到 升级的必读都有一些，有兴趣可以参考。

资料收集：高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 http://www.cnblogs.com/jackei/archive/2007/10/07/915931.html

最全,最强的软件测试资料汇总 (性能测试,性能调优,功能测试,自动化测试,测试管理,测试工具,测试用例设计,缺陷分析预防,前沿测试技术...)
http://www.cnblogs.com/jackei/archive/2007/02/06/641647.html

好东西大家共分享！