工作上的与人沟通更是每天都要面临的沟通关系。现代社会不允许单枪匹马的个人英雄主义，团队思想与沟通技巧贯穿着所有的行业和工作。

    在这里，我只简单的剖析一下软件行业领域里，作为测试和开发人员的沟通问题。只是工作期间的一些愚见，随便写来，供大家褒贬。

    单讲沟通工具：本人建议即时通讯工具和面对面沟通相结合的方式。QQ、MSN、飞鸽、其它一些公司的内部局域网沟通工具等等，不胜枚举，对于传文件或是简单的需要沟通的事宜通过工具可以省时间，提高效率，但是对于一些技术上或是其它方面的问题，我建议还是需要面对面沟通。

    程序员整天对着代码，与人沟通的机会相对比较少，喜欢闷头研究，出了问题就在msn等工具上提出来，有时候表达不完全时候，两个人针对一个很简单的问题会一直争执不下，或是因为一两句不带任何语气的话而影响情绪，这都无形给工作带来了弊端，影响了效率和感情。有时候当面一句话能解决的问题，在网上要说上好几句也未必能真的解决。

    一个优秀的测试人员，应该知道哪些问题是应该给开发人员提出来的（毕竟，它也是从开发走过来的），对于一些不是很重要的bug，测试人员应该予以补充或作为备注，并提出个人的一些想法，尤其是这个bug有可能发生的潜在隐患。开发人员呢，对于举手之劳能改的地方尽量满足测试人员提出的需要修改的地方。毕竟，作为一个团队，每个人都是为了更好的完成项目或是工作。开发人员要不断的从测试人员那里吸取经验，测试人员也要考虑开发人员的工作量和难度，这样的话，沟通工作就相对容易些。

    其实，每一个开发人员都是对自己所做的软件认真负责，这个不容置疑，但对于测试人员提出的问题，本能上一般的人都会有抵触心理，测试人员说白了就是挑刺的，把找出多少个系统bug为己任，这两者表面上看充满了对立与矛盾，有矛盾就会有统一，当开发人员和测试人员都把自己看成这个软件或系统的创造者之一的时候，它们在共同完成一件作品，只是分工不同罢了。有矛盾才会有进步，在测试与开发之间，同样适用。

    工作易做，沟通难做。当我们尝试着用换位思考的角度面对任何问题时，一切就不会总那么针尖对麦芒了。工作是一门技术，沟通是一门技巧，以扎实的技术作为根基，灵活友善的运用沟通的技巧，也许所有的工作看起来就不那么难进展，人与人之间就不那么难沟通了。

有网友来信中提到的问题如下，都是和测试用例相关：

[2]可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！

[3]不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。

很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角落看示波器！技术以外的技能才是更重要的本事！！从古到今，美国日本，一律如此！

[4]多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌撞撞，遇到重重困难，交不少学费，成功的概率大大降低！

[5]知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务， 法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！

[6]抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！
[7]逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱），犹豫不决，胆怯，多虑，脸皮太薄，心不够黑，教条式思维。。。这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个月地摊，包准有效果 ，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好--尽管你可能技术不错！
[8]工作的同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！

[9]要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会...

[10]该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功。

Windows的特别多服务都是双刃剑，用不好就会带来诸多安全隐患。本文介绍了十项服务，建议大家一定要禁用，此外还有十余个建议禁止的，供用户参考。
　　WindowsXP必须禁止的服务

　　1、NetMeetingRemoteDesktopSharing

　　允许受权的用户通过NetMeeting在网络上互相访问对方。这项服务对大多数个人用户并没有多大用处，况且服务的开启还会带来安全问题，因为上网时该服务会把用户名以明文形式发送到连接它的客户端，黑客的嗅探程序很容易就能探测到这些账户信息。

　　2、UniversalPlugandPlayDeviceHost

　　此服务是为通用的即插即用设备提供支持。这项服务存在一个安全漏洞，运行此服务的计算机很容易受到攻击。攻击者只要向某个拥有多台WindowsXP系统的网络发送一个虚假的UDP包，就可能会造成这些WindowsXP主机对指定的主机进行攻击。

　　另外如果向该系统1900端口发送一个UDP包，令"Location"域的地址指向另一系统的chargen端口，就有可能使系统陷入一个死循环，消耗掉系统的所有资源。

　　3、Messenger

　　俗称信使服务，电脑用户在局域网内可以利用它进行资料交换。

　　这是一个危险而讨厌的服务，Messenger服务基本上是用在企业的网络管理上，但是垃圾邮件和垃圾广告厂商，也经常利用该服务发布弹出式广告，标题为"信使服务"。而且这项服务有漏洞，MSBlast和Slammer病毒就是用它来进行快速传播的。

　　4、TerminalServices

　　允许多位用户连接并控制一台机器，并且在远程计算机上显示桌面和应用程序。如果你不使用WindowsXP的远程控制功能，可以禁止它。

　　5、RemoteRegistry

　　使远程用户能修改此计算机上的注册表设置。注册表可以说是系统的核心内容，一般用户都不建议自行更改，更何况要让别人远程修改，所以这项服务是极其危险的。

　　6、FastUserSwitchingCompatibility

　　在多用户下为需要协助的应用程序提供管理。WindowsXP允许在一台电脑上进行多用户之间的快速切换，但是这项功能有个漏洞，当你点击"开始→注销→快速切换"，在传统登录方式下重复输入一个用户名进行登录时，系统会认为是暴力破解，而锁定所有非管理员账户。

　　如果不经常使用，可以禁止该服务。或者在"控制面板→用户账户→更改用户登录或注销方式"中取消"使用快速用户切换"。

　　7、Telnet

　　允许远程用户登录到此计算机并运行程序，并支持多种TCP/IPTelnet客户，包括基于UNIX和Windows的计算机。又一个危险的服务，如果启动，远程用户就可以登录、访问本地的程序，甚至可以用它来修改你的ADSLModem等的网络设置。除非你是网络专业人员或电脑不作为服务器使用，否则一定要禁止它。

　　8、PerformanceLogsAndAlerts

　　收集本地或远程计算机基于预先配置的日程参数的性能数据，然后将此数据写入日志或触发警报。为了防止被远程计算机搜索数据，坚决禁止它。

　　9、RemoteDesktopHelpSessionManager

　　如果此服务被终止，远程协助将不可用。

　　10、TCP/IPNetBIOSHelper

　　NetBIOS在Win9X下就经常有人用它来进行攻击，对于不需要文件和打印共享的用户，此项也可以禁用。

需求分析的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

微软的软件测试方法
 国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。
    作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考，更有利于发现问题的根源。即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。
    微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。
    两类经典的软件测试方法
    在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。
    传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。
    提出第一类方法的代表人物是软件测试领域的先驱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，不只是一个纯粹的软件测试技术编程高手，一个测试架构师的存在是为了解决实际项目产品中的测试问题，并不是一个纯粹的测试技术编程爱好者。一个热衷于单元测试开发框架的人，可以是一个编程好手，但未必是公司需要的测试架构师。一个架构师，对技术和测试策略测试方法学都能在解决实际问题上运用娴熟

原文:

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

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

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

测试用例模板