在G.J.Myers的经典著作《软件测试之艺术》（The Art of Software Testing）中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。除此之外，G.J.Myers还给出了与测试相关的三个重要观点，那就是：

1.  测试是为了证明程序有错，而不是证明程序无错误； 
2.  一个好的测试用例是在于它能发现至今未发现的错误； 
3.  一个成功的测试是发现了至今未发现的错误的测试。

实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。根据作者多年的经验和理解，软件测试的不同视野，概括为如下5类：

•  软件测试的狭义论和广义论——静态和动态的测试
•  软件测试的辨证论——正向思维和反向思维
•  软件测试的风险论——测试是评估
•  软件测试的经济学观点——为盈利而测试
•  软件测试的标准论——验证和确认

 

1. 软件测试的狭义论和广义论

G.J.Myers所给出了测试定义——“程序测试是为了发现错误而执行程序的过程”，实际是一个狭义的概念，因为他认为测试是执行程序的 过程，也就是传统意义上的测试——在代码完成后，通过运行程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统 需求、发现设计上的问题，把需求、发现设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加软件开发的成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。这种狭义论是受软件开发瀑布模型影响。

正是为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。

延伸后的软件测试，被认为是一种软件测试的广义概念。这就引出软件测试的两个概念“静态测试”和“动态测试”，如 测试方法的辩证统一 （1）所述，这样就由静态测试和动态测试构成一个全过程的、完整的软件测试，而且静态测试显得更为重要。

 

2.软件测试的辨证论 

G.J.Myers的第2个观点“测试是为了证明程序有错，而不是证明程序无错误”， 引出了软件测试的另外一个争论，软件测试究竟是证明所有软件的功能特性是正确的呢？还是其反向思维——对软件系统进行各种试探和攻击，找出软件系统中不正 常或不工作的地方呢？从我个人理解，这两个方面都有一定道理，前者（证明所有软件的功能特性是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们认为，测试不是为了证明所有的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试的一般工作就是发现缺陷 (detect bug)，即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测试是带有“破坏性”的工作。

对于不同的应用领域，两者的比重是不一样的，如国防、航天、银行等软件系统，承受不了任何系统失效，因为一次系统的失效完全有可能导致灾难性的损失，所以强调前者以保证非常高的软件质量。而一般的软件服务应用则不同，强调后者，质量目标设置在“用户可接受水平”，不要国度追求质量，从而可以降低软件开发成本。作者建议，在我们实际操作中，可以分阶段实施不同的测试思想，在早期阶段集中在“证明程序有错”—— 发现Bug，后期集中在验证所有特性是否正常工作——降低风险，见作者的另外一篇讨论：测试执行中非常有效的策略

    下面就是这两种观点的基本描述：

• 验证软件是验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr. Bill Hetzel （代表论著《The Complete Guide to Software Testing》)。

• 证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现Bug Bug的测试，不然就没有价值。

3.软件测试的风险论 

测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身的风险性是大家公认的，测试的覆盖度不能做到100％。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书（Specification/ Spec）”是其中的一个标准，但也不是唯一的，因为Spec中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对Spec 去报Bug。但是，测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢？

有人把开发比作打靶，目标明确，就是按照Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞；如果只捞大鱼（严重缺陷），网眼就可以大些、撒网区域相对比较集中（测试点集中在主要功能-major features）。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域（测试点遍及所有功能——all features）。

在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以完全看作是软件质量控制的过程。

对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大？哪些是用户最常用的20％功能——Pareto原则（也叫80/20原则）？如果某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80％功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。

版权所有，软件测试演义^®

4.软件测试的经济学观点

“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软 件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目标。同样，商业性目标是否正确，直接决定了 企业是否盈利的结果。多数情况下，软件测试是在公司内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅仅 局陷于“和客户需求的一致性、适用性”，而且要增加其它的要求——“预算内、按时发布、易于维护”。

软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是  40～ 1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。

.版权所有，软件测试演义^®

5. 软件测试的标准论

        如果从标准论来看软件测试，可以定义为软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试 = V&V。

 “验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。

需要说明的是，软件测试的对象是产品（包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等），而质量保证和管理的对象集中在软件开发的标准、流程和方法等。

 

究竟什么是软件测试呢？综上所述，软件测试的定义为：

软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

原著 出自： 软件测试演义——中高级系列（序）

软件工程在过去几十年的发展历程中，也形成了一些鲜明的新思想。例如，IBM 提出了软件开发思想的4项要点——迭代开发、以系统架构为中心、持续的质量保证以及管理变更和资产，其中只有“持续的质量保证”和传统工业工程是十分吻合的，而其它3项具有软件特性所拥有的思想。软件的变更比较频繁，自然对其管理的高要求，进一步促进迭代开发的合理性。

客 户和业务用户始终希望软件能够按时交付高质量的产品，又认可软件的灵活性，希望软件能够具有随需应变的能力，及时进行必要的修改来满足业务的新需求。同 时，软件又是一种知识型产品，需要创造性，并依赖每个开发人员的创造力和积极性。所有这些引导人们新的思考，引导人们不断认识软件工程而建立独特的软件工 程思想。

• 迭代开发，以时间换空间，消除市场风险。
• 敏捷开发或轻量级过程，以不变应万变。
• 永远的Beta，不断推陈出新，永无止境。
• 持续集成、持续构建、全程测试。
• 知识管理，将软件工程纳入知识管理的范畴。
• 面向对象是一种方法，也是一种思想。
• 软件即服务（SaaS），面向服务架构（SOA）的开发思想。
• 用例驱动开发，用户为本思想在软件中的体现。

 

同时，软件工程可以向传统工业工程学习，吸收传统工业工程上百年实践积累下来的经验、沉淀下来的思想。

• 以顾客为中心的全面质量管理。
• 过程决定结果。
• 有效的持续改进过程。
• 预防为主，检验为辅。
• 验证和确认缺一不可，质量保证和测试融为一体。
• 以架构设计为中心，体现设计为重的思想。
• 生产标准化、产品标准化和技能标准化。
• 软件工厂思想造就了组件、构件技术，包括自动化测试。
• 围绕项目管理开展工作，包括风险预防、里程碑控制和关键路径法等。

欢迎大家讨论，提出新的思想或补充遗漏之处。

为了感谢大家的厚爱（连续几周在当当 畅销榜上、名列许多在线书店的测试类图书前两名），特提供<全程软件测试>完整一章电子版下载，使大家更加了解本书的特点。

 

微软(Microsoft)欲以62％的溢出价每股31美元、共计446亿美元收购雅虎(Yahoo)，成为目前互联网的最大新闻。微软希望和雅虎联姻，以搜索市场的第2、3名的强强联合来对抗甚至打败搜索市场的老大谷歌（Google）。微软和雅虎联姻会实现微软的如意算盘吗？答案多半是否定的，为什么呢？有3点理由。

1. 微软和雅虎，在许多方面都是很相似的，包括搜索、即时通讯、地图、邮箱等，没有形成很强的互补关系，而是双方重叠的部分很多（见下面的列表），这样兼并后两个公司业务整合的工作量很大，需要很长的时间（一年到两年的时间），这期间业务自然受影响。其结果，反而会让竞争对手Google趁此机会有更快的发展，拉大他们之间的差距。(佐证：微软投资者称收购雅虎无济于事 或削弱实力， 分析：微软收购雅虎对双方都是灾难 )

2. 在互联网，人们的习惯势力是非常大的，不容易改变，大家对Google、Apple情有独钟，对微软的霸气存在一定的心里暗示或抵触情绪 （这里有一个例子： 美国网民恶搞微软收购雅虎(组图) ），这对微软是不利的。IT时代特征“30年河东、30年河西”比较明显，在某个旧领域称雄的公司，很难在新的领域称雄。例如，微软在数据库上一直想打翻身仗，但始终很难超过Oracle.

3. 微软的收购历史说明了这一点，大部分的微软兼并案例都没有获得成功，常常将收购来的公司置于孤独的境界，实例不少。微软和雅虎的文化差异也比较大，对于公司规模相差不大的情况下，两者的冲突会更大些。（佐证：微软并购雅虎面临三道槛：两公司文化能否.. ）

附表：Yahoo, Microsoft和Google的网络业务对比

业务项目	Yahoo	Microsoft	Google
Search 搜索	Yahoo Search	Live Search	Google search
搜索广告业务	Yahoo Search Marketing	Microsoft adCenter	Google AdWords Google AdSense
桌面	Yahoo tool bar	OS, Office	Desktop  Google Toolbar
内容服务	Yahoo.com	Msn.com
行业服务(汽车、财经等)	Yahoo Auto, Yahoo Finances	MSN Autos, Money	Finance
账户管理	Yahoo ID	Passport, Live ID
个性化主页	My Yahoo!	Live.com	iGoogle
电子商务（购物）	alibaba, shopping	Shopping	Shopping
游戏	Yahoo Games	MSN Games
地图	Yahoo Maps	Live Maps	Google Maps
即时通讯	Yahoo Messenger	Live Messenger	Talk
邮件	Yahoo Mail	Live Hotmail	Gmail
社区帮助服务	Yahoo Answers	Live QnA	Orkut  Custom Search
照片共享	Flickr	Live Spaces	Picasa
博客	360°	Live Spaces	Blogger
Widgets	Yahoo Widgets	Windows Sidebar
Video		TV Movies	YouTube
Mobile	Yahoo Mobile	Live Mobile	Google Mobile Maps for mobile SMS Android
Web Development	Yahoo Developer Network	Dev.Live.com	Code
Web Mashup Tools	Yahoo Pipes	Popfly	Google Mashup Editor
Website Services	Yahoo Small Business	Office Live	Google Apps <!--[if !supportLineBreakNewLine]--> <!--[endif]-->
	Geocities
Social Events	Upcoming	Live Events	Groups
Social Bookmarking	del.icio.us	(Advertising deal with Digg)	Google Bookmarks
Music Service	Y! Music/MusicMatch	Zune Marketplace, MSN Music
Music Software	Music Jukebox	Windows Media Player

相关链接

• 鲍尔默笑称唯一不能收购雅虎的是谷歌 
• 分析：微软拟收购雅虎表明无力单独对抗谷歌
• 微软向全球推出Dynamics CRM 4.0 
• 微软洽购推动雅虎股价盘前大涨60% 
• 微软洽购雅虎金额创科技业收购规模之最 
• 高盛称微软收购雅虎对百度不利
• 洪波：微软为什么错过了互联网
  
• 国际先驱论坛报：微软并购案对硅谷小企业..
• 中国政法教授：中国雅虎闪电裁员有违法之嫌
• 传Google CEO致电杨致远愿助雅虎对抗微软
• Google怒斥微软欲垄断互联网 微软回应

《全程软件测试》出版以来很受读者欢迎。

为了让更多的读者了解、让更多的（测试）人员不会错过它，特介绍一些书中的亮点，以供参考。

   本书的亮点：

1. 授之以渔，阐述测试的先进思想、理念和方法，而不是授之以鱼——交待软件测试的知识；
2. 以项目为背景循序渐进，一步一步、手把手教大家进行软件测试；
3. 丰富的经验和世界一流的流程得到全面的分享；
4. 语言流畅，将一些概念单独抽出来，放在内容之后作为知识的补充；
5. 内容丰富，涵盖了测试的全过程，并清晰地给出 “知识点” 、“要点”等；
6. 实例丰富，各种方法和工具的使用都给出示例；
7. 图文并茂，全书插图以百计数，使读者更容易了解所讲解的思路和方法。

下面就从书中抽出一些真实的示例（书中的百分之一、二），从中您或许能体会到上述亮点。

表格丰富

 

参考链接：

•  如何有效又圆满地完成软件测试？

• 推荐《全程软件测试》——软件测试人必读图书

• 如何更好地理解《全程软件测试》 
  

• 技术布道——全程软件测试

来自波音(Boeing)公司的John Vu两个主题演讲（软件过程改进的现状、如何在软件外包市场胜出），切中要害，不仅对国内软件业现状分析透彻，而且提出了很好的对策。给我印象最深的是两句话：

• I never ask the suppliers for CMM maturity level, I only request them to show the data.
• Not look for piece paper, we only look for skills, competencies, expertise

        这两句话的含义只有一点，就是一个软件企业应注重提高实际的技术、竞争能力和专业水平，而不要看重某种认证。通过CMM/CMMI认证，如果没有获得很好的执行结果，是没有意义的。

       在国内，许多软件企业进行过程改进，往往忘记了其根本目的——软件质量和生产力的提高，而把目标放在通过CMM/CMMI的认证，如何通过2级。通过了2级，就想如何通过3级、4级和5级。这实际是抓了芝麻、丢了西瓜。有一组数据可以说明这些问题：

• 在评估认证之后，72%的组织在过程改进上没有获得成功或收效甚微。
• 在前三年，有83%的组织放弃了过程改进
• 未来，有57%的组织放弃了过程改进的努力
• 只有不到1％的组织以改进的数据声明获得过程改进的成功

    为什么有那么多的组织在过程改进上失败了？主要原因有以下几点：

• 过度重视评估，而没有将注意力集中在过程改进的实现上（兑现承诺）
• 只强调成熟度的级别，而没有清晰的方向和可度量的目标
• 缺乏良好的IT基础设施来支持过程改进活动的协调和管理
• 混淆概念和实践，即追求CMM/CMMI的形式，而忽视了真正的执行
• 过程改进实施的管理很差

    
       软件过程改进必须为组织的业务服务，必须受公司发展战略的指导。软件过程改进，实际上就是为了提高公司的利润，只有两个目的——不断提高产品或服务质量、不断提高软件开发的效率（生产力）。所以说，

• 过程改进不是根据一本书写成的一对文档
• 过程改进是业务的竞争力

     过程改进过程中，我们要不断问自己：质量提高了吗？成本降低了？效率提高了吗？开发周期缩短了吗？进度控制更准确了？客户更满意了吗？......而要为 这些问题找到答案，只有靠数据、数据，还是数据。例如，每千行代码的缺陷数、进度误差率、软件复用程度、投入产出比、等等。

    当许多人在质疑CMM/CMMI 含金量的时候，向大家一再强调过程改进的实质目标，是非常具有现实意义的。John Vu的演讲可以看作是对国内软件业的“CMM/CMMI热”敲响的警钟，对纠正政府某些片面政策（如哪个企业通过CMM 3级，将获得奖励基金50万元）也是有帮助的。在一种务实的态度下，紧急围绕着“质量和生产力”这两个核心，以客户需求为导向，以务实的态度，让数据说 话，把过程改进持续进行下去，才是正确的做法。

 下载： John Vu 主题演讲 － 软件过程改进的现状
  

John Vu is a Senior Scientist at Carnegie Mellon University, where he conducts research on software and systems engineering. John is also a Technical Fellow and Chief Engineer of Information Systems at The Boeing Company. He is a member of the IEEE Software Industry Advisory Board and has written many articles on project and program management. John has over 30 years of experience in software and systems development and has managed several large-scale integration programs in which the final products required the integration of in-house components with commercial off-the shelf (COTS) products and out-sourcing suppliers

 

有时，几个人在讨论一个话题时，由于其中一个人猛然想起另外一件事，或者又有一个人加入进来，讨论越来越激烈，大家兴致丝毫未减，但讨论的内容离主题越来越远，到后来都忘记刚开始要讨论的是什么话题。这样的情形，我们可能都遇到过。如果是闲聊，倒也无妨。如果是为了解决问题，就会浪费时间，没有达到目的。

       实际在我们的工作中，也存在这样的现象。例如，软件测试就是为了发现缺陷，无论是Review PRD/Spec, design test plan, 还是test case design, Test automation 等都是为了这个目的。“发现缺陷”就是软件测试之本，我们在做测试工作之中，就不能忘掉这个根本。有时，我们在进行测试自动化的时候，容易出现“忘本”的事。出现这种情况，不外乎以下几种原因：

1.  一开始就不知道测试自动化的目的，而是为自动化而自动化。
2. 在自动化开发过程中，逐渐忘掉了最初的设想和目标，而对技术越来越崇拜，在技术上陷入越来越深，追求框架、追求目前流行的技术等等，结果，并没有解决问题。或者说，本来用一个简单的方法就能解决的问题，却用了几倍的努力来实现。
3. 追求纯数字的东西，例如，一直盯着 how many test cases have been automated, 但究竟其测试结果是否有可靠的保证，却不清楚。有时，知道VP有risk, 但也不去解决，同样是忘本的事。

 所以，在做测试工作时，时刻提醒自己以下几点：

1. 测试就是为了发现缺陷，尽早地、尽可能多的发现缺陷。
2. 做事情不崇拜技术，而是要紧紧抓住目标，力求简洁有效、事半功倍，绝不要使用事倍功半的方法。
3. 在实施测试自动化的过程中，质量还是本，绝不能以质量换取自动化程度。测试自动化的基础还是测试用例，测试工具毕竟是工具、测试工具不会思考，70％缺陷还是需要人的智慧和思考。

 方针：质量为本、工具为辅；工具先行、人力断后

1. 面对任何一个测试任务，首先要想如何用有效的方法来完成测试，即能用测试工具、能自动化的地方，就尽量进行自动化。
2. 实施时，人是决定的因素，始终围绕“质量”这个中心，不断思考，不断改进测试策略和方法，不断提高测试用例的覆盖率。

  [另一个佐证——摩托罗拉的故事。在摩托罗拉的战略中，最彻底失败的案例是所谓的全球铱星计划，就在于技术大大的远超越了市场需求，可以理解为超技术战略失败；现在摩托的手机业务正在进行着另一种失败，就是技术远离了市场需要，可以理解为弃技术战略失败。正应了中国一句俗语“成也萧何，败也萧何”，这句2000多年前的楚汉之争时期的名句，可以用来解释今天全世界成功或失败的案例。摩托罗拉之所以成功，正因为在技术上开创了手机时代，是人类的通讯从有限时代走到无线网络时代，彻底的改变了人类的沟通方式，而成为无线市场的领头羊，成为绝对的领导者。可惜，往往成功者总是太喜欢玩“鸟尽弓藏”的游戏，市场做起来了，就忘了自己最成功的战略和核心的优势。 ]

项目	描述	LoadRunner	OpenSTA
协议	测试工具可以捕捉、处理及回放通信协议	支持多种协议。按照协议数量收费，支持多种协议录制功能。	仅支持HTTP 1.0 / 1.1 / HTTPS (SSL)。
回放功能	回放脚本及脚本调试工具	扩展的记录功能支持参数和服务器信息的浏览，还可浏览及比较已录制网页版本与客户端返回的信息，脚本生成器包括了调试工具、支持断点调试和单步跟踪。	类似的回放功能，但没有综合比较功能。有调试功能，包括控制器、断点设定和单步跟踪。
脚本语言	窗体顶端	称为TSL，使用标准C语言语法而且允许添加C函数库，对工具支持的不同协议有广泛的定制功能。	使用专有的类似“BASIC”语言的自动化脚本语言SCL。在已有的功能上有些限制，例如字符串操作、支持文档对象模型（DOM）直接处理。
	使用中间介质来代表被捕获的协议数据和操作回放数据窗体底端
扩展性	工具功能性扩展	附加的TSL或者C函数库， 受限与工具的功能性。	SCL脚本模块可以定义到Include文件里，开源使得功能可以用C＋＋进行扩展。
脚本界面	编辑脚本的应用程序工具的界面	多种捕捉模式， 支持高级的文本浏览和低级的HTTP浏览，并且支持图形化的树形结构和脚本浏览方式，脚本浏览方式支持功能区分入口。	低级的HTTP浏览并且提供图形树表示的DOM结构。可视化的被捕获的HTML渲染与寻址服务器头表。有语言敏感、语法颜色凸显的编程功能。
相关性	从动态数据中替换数值从而能够成功回放的任务。	自动关联功能，包括在录制中录制后，比较录制与重放效果。但是不支持所有的模式捕获。	手动关联使用互动的DOM架构。自动生成脚本代码的功能用来辅助变量代换。
Cookie 管理	HTTP cookies的检测、录制和回放，并需要额外的代码来管理javascrīpt生成的cookies	HTTP头存根自动管理，如果需要可以手动操纵。	HTTP头存根自动管理，如果需要可以手动操纵。
参数化	自动地调整动态数据参数从而更准确模拟真实用户。往往是对话（session）管理所必须的	可扩充的数据输入接口，包括数据库查询的向导界面。没有标准的函数来锁定数据源保持分布式测试中被并发访问数据的唯一性。	可扩充的数据输入接口，包括自动生成测试数据的向导界面。标准功能包括了对数据文件的顺序、随机、伪随机访问。分布式测试中，有标准的通用函数来维护单个或多个负载注入器（injector）的参数的唯一性。
控制器	管理和实施测试	实时监控功能。情景自动生成。对虚拟用户、脚本、脚本组的单独控制。脚本的运行安排，执行进度显示及循环控制	实时监控功能。简单拖放多情景测试配置，支持模块化脚本，并允许在在运行时加入新的情景/虚拟用户。没有情景自动生成。允许在多用户负载测试过程中对整个测试或者特定用户进行http监测和调试。
监控	在执行期间捕获资源使用信息，包括显示并用于建立性能测试报告。	支持多种模式。 支持在线图形显示、Apache/Netscape/IIS。其他监视器需另外支付费用。新的机制允许远程用户通过浏览器界面实时监控结果。注意：通过防火墙监控需要制定TCP/IP端口。未来版本的LoadRunner应使用HTTP消息避免此类问题。	支持Windows NT/2000中集成的性能图形显示以及SNMP信息收集。各种测试信息包括虚拟用户状特性、自定义状态和活动信息。 基于Web的监视器可以穿过防火墙运行在远程机器上。 执行过程中的联机图形以及监视结果会用于最后的报告。
分布式测试	把压力生成分布到多个产生压力的机器的能力	支持由单一控制器管理多个负载生成器。	支持由单一控制器管理多个负载生成器。同一网络使用TCP/IP或基于Web的HTTP远程控制负载生成器。
虚拟IP地址	模拟不同IP地址访问系统的能力。尤其对负载平衡系统非常有用	支持虚拟IP包括IP转发时的路由自动更新。	没有嵌入虚拟IP功能。
广域网/局域网仿真	在测试中模拟不同网络结构的能力	7.6版本新加入的功能。允许在局域网测试时仿真延时、丢包、连接故障及动态路由效果。需要专门的许可证书。	没有嵌入广域网/局域网仿真功能。
缓存	模拟网络浏览器缓存页面的能力	可以控制浏览器回放时的缓存仿真以及每个虚拟用户的设置。	没有特别的功能，虽然可以效仿简单的脚本代码。
用户网速模拟	模拟真实用户不同网络速度的能力	可以回放时仿真不同的网络速度	没有嵌入模拟真实用户不同网络速度的功能
分布式/远程压力生成	为了产生大量负载需要额外的负载生成器，并需要集中控制	可以控制多个负载生成器及收集结果。使用HTTP端口可穿过防火墙控制远程的负载发生器。	可以控制多个负载生成器及收集结果。使用HTTP端口可穿过防火墙控制远程的负载发生器.
报告&分析	检查和分析测试的结果，包括定时器、监控的资源和以图形方式显示的结果。	大范围的混合式图表功能——在Word中自动生成报告。分析器可以作为单独的应用程序分发给用户	简单的图表，足够能分析、统计与负载有关的关键数据和资源使用情况。资源使用的显示支持覆盖图，可以输出到 Excel。无许可证限制，任何用户都可以浏览数据。 免费的工具和Excel宏都可透过公共用户论坛获取。
可量测性	工具生成多少虚拟用户及相应的资源使用的能力。 实际可利用资源取决于数量、规模和脚本的复杂度。	资源的限制主要是线程数量及内存大小。在NT/2K操作系统上每个虚拟用户会占到1 Mb内存。 Windows 95， 98 & Unix的效率更低些。每台PC的最大虚拟用户数大约为1500。	主要使用的资源是内存。在一个单核P4处理器及Windows 2k上测试一个简单的ASP页面，如果达到3000用户的负载需要1GB内存。 未经证实的报告说明Win2k机器上对于复杂的脚本最多可以支持1664个虚拟用户。可能有线程限制。没有许可证书限制。
初始成本	购买软机及证书的费用，不包括升级或支持。	没有虚拟用户的软件基本价为16，000美元。额外的费用是通过每种协议、监控资源和虚拟用户来收取。	免费并可以通过www.OpenSTA.org下载。可供下载的有: 先前版本; 自动安装包和当前源代码(附有MS C++ Visual Studio 6简单build指令)。
虚拟用户成本	大多数商业工具按照虚拟用户的数量收费。额外的硬件也需要额外费用。	价格范围大：虚拟用户的费用从25个10000美元到1000个66000美元。临时的虚拟用户大约是每天3.50美元(1000分钟)。 这不是正式的报价。	免费，无许可证书限制
技术支持 & 专家咨询	该工具支持的可用服务和费用。	根据M.I.， 此项费用每年大约为初始成本的1/5， 包括升级。 MI和其合伙公司还提供咨询服务(包括etest协会)。	众多的独立资源。 Etest协会对每次远程技术支持收取美元50，也提供收费的专家咨询。网上资源包括网页和电子邮件论坛。升级是免费的(大约每3-6个月)。
培训	工具的培训服务	MI 有大量的培训课程，费用为大约每人每天400美元。许多合作伙伴也提供培训课程	专业公司，提供有针对性的培训，价格也不尽相同。
系统需求	使用工具需要的操作系统。(不是指测试的操作系统)。	MS windows 2000， NT4 (sp6a)，XP-Pro - 在Unix: HP， Solaris， Linux负载发生器仅支持部分功能	MS windows 2000， NT4 (sp5+)， XP-Pro。
硬件需求	使用工具的硬件需求。(不是测试的硬件系统需求)。	最低要求: Pentium 350 & 128M；	最低要求: Pentium 200 & 80MB 内存。 专业版: Pentium 500MHz+ & 128MB+ 内存。
		负载发生器: Pentium 1GHz以及每个虚拟用户1 MB内存
代码开放性	工具本身源代码的可用性	不可用	开放源码GNU的公共许可证- C++语言。
用户评价	网络测试工程师对两种工具的体验	有一个非常友好的用户界面，强大的监测及结果分析。自动关联和改进的脚本记录设施能提高效能。非常灵活的脚本功能及周详的帮助文件，另一个亮点是支持很多协议。缺点是复杂的选项和控制器布局。	易于使用的界面和优秀的延展性。内建的结果分析功能稍许逊色。被捕获的数据是开放的、直接输出到Excel。情景设置和控制的拖放，非常直观和容易互动，模块化脚本简化了情景的制作。手动关联令人头痛，但可以用第三方的‘diff’工具和GUI DOM提供的功能使关联容易。相对不足的是标准脚本语言的功能，但足够完成大多数http负载测试工作。如果没有，就使用"Include"支持功能和提供的源代码，具有很强的可扩展性。

 

您可能阅读了《全程软件测试》的前言、目录和序一，对本书有了基本理解。为了您更好理解本书，将序二的部分内容摘录下来，供大家阅读 :

序二 · 节选

---

 

软件质量管理在软件研发团队中的作用是显而易见的。其中软件测试人员在保障和改进软件质量工作中正发挥着越来越大的作用。但是从整个软件工程周期来看，软件质量其实是在整个开发过程中形成的，或者说软件质量是构造出来的，而不是测出来的。程序代码完成之后，其质量水平就基本确定了，虽然可以通过测试将大部分发现缺陷，但是，程序代码中存在缺陷越多，遗漏的缺陷就会越多，质量很难得到改善。如果缺陷发生在需求阶段或设计阶段，则将带来更大的成本和风险。如果将软件测试贯穿整个软件开发过程，从项目启动的第一天开始就将软件测试引入进来，情况就完全不一样了。贯穿软件开发全过程的测试，不仅可以在第一时间内发现缺陷，而且能有效地预防缺陷的产生。缺陷预防，可以大大减少软件缺陷的数量、提高软件质量，更有价值的是，它可以极大地缩短开发周期、降低软件开发的成本。

全过程的软件测试，赋予软件测试更多的责任和内容，软件测试不再是事后检查，而是缺陷预防和检查的统一。在需求分析时，通过测试团队和开发团队的共同努力，深刻挖掘用户的需求，清除一切模糊的需求描述；在设计阶段，测试人员可以对不合理的设计提出质疑，督促开发人员在设计时充分考虑性能、可靠性和安全性等各个方面的要求，确定每一设计项的可测试性；在编程阶段，测试人员参与代码评审、单元测试等等。所有这些告诉人们，测试过程可以看作质量保证的过程，测试不再是产品质量的一个检验环节。这也就是《全程软件测试》书名的由来，将软件测试扩展到软件质量保证的全过程中，作者赋予了软件测试新的含义和新的生命！

全程软件测试的另一层含义就是手把手地教会读者如何做测试，从头到尾，覆盖每一个环节。从项目启动——如何把握项目的背景和需求、如何选定测试组长等开始，然后逐渐深入测试计划、设计评审、用例设计、测试执行等过程，直至缺陷报告、测试结果分析和测试报告，每一过程都能得到细致的辅导。作者还用了不少笔墨来介绍如何选择测试工具、如何更有效地开展测试自动化的工作。因为测试自动化非常重要，它可以解放测试人员，使测试工作变得非常有趣，又获得很高的技术挑战。测试自动化能够提高测试效率，使测试人员有更多的时间思考，更好地分析测试范围和设计好测试用例，形成一个良性的循环。

本书不仅阐述了先进的、独特而成熟的软件测试思想和方法，而且呈现了丰富多彩而又实实在在的测试技术和实践。测试的知识、概念是比较容易获得的，但要获得经过实践千锤百炼而来的、多年积累下来的体会和经验，却是非常难得的。现在，这些内容就在您的眼前，唾手可得。《全程软件测试》能帮助您获得您所需要的东西、解开您心中的疑惑。本书所给出的最佳实践，不仅代表着国内的最高水平，而且和美国硅谷的软件测试水平也是同步的。它一定会帮助读者高效地、高质量地完成测试和软件质量保证任务。

最后，希望大家喜欢这本书，进而从中受益。

 

 沈剑 - Joss Shen

Founder and CEO

Dreamcast Systems, Inc.

http://YouMonitor.Us/

 

参考链接：

  2000年刚建立测试团队时，测试和开发人员是一种对立的关系，开发人员觉得软件测试是挑他们的毛病、和他们过不去，有一个简单的故事可以说明这一点。当时，条件有限，测试人员和开发人员共享一台小型机服务器，测试人员发现了一个缺陷，告诉某个开发人员，而他趁测试人员不注意回到自己座位，偷偷地修改了代码、处理了那个缺陷，然后跑到测试人员身边，说“你把那个Bug再现给我看？”。结果，可想而知，这个测试人员无论如何也不能复现那个Bug（缺陷）。
    几年以后，这种情况不会再出现了，不是因为条件好了，可以买很多服务器，将测试环境和开发环境分离开来，而是观念改变了。虽然也的确购买了几百台服务器（不用小型机，越来越多采用Linux系统），将测试环境和开发环境分离开来，在客观上避免那类“悲剧”的发生，但是观念远远比机器重要。拥有正确的观念，就比较容易创建良好的质量文化，开发人员的态度也随之发生变化，已经深深认识到：

• 软件测试是帮助自己，测试人员在是找产品定义、设计和实现的缺陷，不是找自己的缺陷，是对事、不是对人。
• 测试人员越快地发现缺陷，项目才能尽早一点结束。
• 测试人员尽可能地发现更多的Bug，遗留在产品中的Bug就会越少，产品的质量就会越高。
• 测试人员和自己（开发人员）的工作都是为了相同的目标——按时、高质量的发布产品。
• 水平越高的开发人员，所写的程序中的Bug越少，而不只是使用别人不知道的技巧。

    现在，有的开发人员向我抱怨，是不是换了一个新人测试他写的模块？因为这个测试人员发现的缺陷比以前那个测试工程师发现的缺陷少多了。开发人员希望更多的缺陷被发现出来，绝不希望缺陷被客户发现。
   
    今天，我们高兴看到开发人员和测试人员心往一处想。从项目启动的第一天起到需求和设计的评审阶段，从后期的缺陷修正到产品维护——在整个软件生命周期中，开发人员和测试人员愉快地合作、共同努力，将软件产品的开发效率和质量推到一个新的高度。一方面，开发人员主动介绍自己对产品特性是如何理解的、又如何实现这些特性，主动邀请测试人员参与代码的走查、对新发现的Bug快速响应。另一方面，测试人员提前将设计好的一些测试用例交给开发人员，让开发人员先根据这些测试用例验证正在开发的功能特性，测试人员还愉快地帮助开发人员再现某个缺陷。
   
    所有这些，显示了软件测试在国内越来越受到重视，软件测试领域正迎来朝气蓬勃的新气象。当更多的人投入到测试行业时，需要一本实践性强、富有启发的专业书，指导大家如何进行测试，出色地完成测试任务。
   
    这本新书《全程软件测试》就承载这样一个任务，从项目启动开始，一步一步地教会大家如何做好测试工作，包括建立测试组、计划测试、设计测试用例、选择测试工具、开发测试脚本、执行测试和编写测试报告等。这也是将多年来所积累的软件测试经验与技术实践，以及不断思考所获得的体会和升华，借此机会与大家分享。
   
    为了写这本书，事先也做了一些尝试，尽量收集大家对软件测试内容需求的反馈，于是在CSDN的个人博客 上演义了30回的软件测试 （ 软件测试演义——中高级系列（序）），受到了大家的好评。也许就因为这个，在CSDN建博客不到8个月，就成为当年（2006年）十大最具价值的博客之一 （迟到的感谢——2006最有价值博客的候选人（& 个人回顾）, 新浪报道 CSDN最有价值博客TOP10 ）。

    此后，也和许多软件测试人员进行面对面的交流，如  技术布道——全程软件测试         

    此前，曾写过一本《软件测试方法和技术》教材，在比较短的时间内印刷了好几次，也颇受欢迎。但那本书，在很大程度上是从理论、概念上讲解软件测试的方法和技术，适合在校学生使用。而这本书重实践、重应用，适合软件公司的测试经理、工程师和想进入这个软件测试行业的人员等学习。

   
      全书共十二章，以两个案例为背景，以项目向前发展的实际过程为路线图，全面展开软件测试的思想、流程、方法、技术和最佳实践。全书力求做到方法有效、技术实用，集中讲解实际测试工作，没有单纯的概念介绍，将概念准确穿插在测试进程活动之中。

• 第1章 介绍测试项目启动后要做好哪些准备、如何掌控项目背景和要素，为测试计划打下坚实的基础，包括了解软件的质量需求、深刻理解究竟什么是软件测试和测试过程和开发过程之间的关系，确定软件测试组长和制定测试规范。
• 第2章 测试计划是焦点，主要讨论了测试人员在需求评审的作用、确定软件功能和非功能性的系统测试测试需求、各个阶段的测试任务、测试范围分析和工作量估计、测试资源需求和团队组建、测试里程碑和进度安排，基于测试风险分析来制定有效的测试策略。
• 第3章 从系统架构的审查，然后深入到系统组件设计、设计规格说明书、界面设计和系统部署设计等一系列的审查。在系统部署设计中，详细讨论了系统部署逻辑设计、物理设计、可用性设计、可伸缩性设计和安全性设计的验证。
• 第4章 围绕测试设计展开讨论，先从测试用例框架的设计入手，然后逐步涉及测试用例的构成、设计方法、评审、功能测试用例和系统测试用例的设计，其中对各种功能设计方法、故障转移和系统安全性的测试用例设计做了更细的介绍。
• 第5章 测试工具的选择和脚本的开发是本章的主题。在这一章，对测试工具的优势、实现原理等进行了分析，介绍了测试工具选择的标准、评估报告和误区，给出了开源的或商业的测试工具的完整解决方案，包括详细介绍了Selenium和Jmeter的使用，最后说明如何进行测试脚本录制、回放、开发和重构。
• 第6章 展示测试和编程的交互过程，主要经历程序代码的审查、程序的动态测试两个环节。对于白盒测试方法及其应用、单元测试工具等，在这一章做了详细介绍。
• 第7章 开始进入功能测试的执行阶段，并着重自动化功能测试的执行、如何优化测试环境的组合、如何有效地创建测试套件和软件缺陷的报告，包括测试执行之前的准备、测试环境的建立和设置、UI测试、回归测试等。
• 第8章 介绍如何进行国际化测试和本地化测试，包括本地化的功能测试、数据格式验证、UI验证、配置和兼容性验证和翻译验证。
• 第9章 内容是围绕系统测试执行来展开，进一步了解系统测试，详细分析了负载测试的加载方式、负载参数、执行布局和结果报告，从而更好地理解如何做好性能测试，并相继介绍了Web安全性测试、容错性测试、兼容性测试、安装测试等。
• 第10章 内容相对简单，包括4个方面：验收测试、文档测试、α测试和β测试、产品后继版本的测试。
• 第11章 内容丰富，涉及测试管理的思想和系统、测试用例的管理、测试自动化的管理、缺陷跟踪和分析、测试进度和风险的控制、测试覆盖度和结果分析等。例如单就缺陷分析，缺陷生命周期、缺陷状态的跟踪、缺陷的分析、累计缺陷趋势分析等。
• 第12章 最后一章是总结和思考，认清现实、制定原则，然后用辨证统一的方法去看各种测试方法的对立统一体，如白盒测试方法和黑盒测试方法、静态测试和动态测试、手工测试和自动化测试、有计划测试和随机测试的等，从而真正悟出软件测试方法的应用之道。这章还分享了测试实践中所积累的、大量的最佳实践，并以实用的测试成熟度模型作为结尾。

 

基于过程的软件测试全景图，是对基于内容的 软件测试内容全貌——全景图(1) 的补充，从而对软件测试有一个较完整的描述。借助这张全景图，更好理解从需求、设计验证开始直至产品发布的整个测试过程，以及慢慢体会如何做好测试工作的每一个环节，不漏过任何一个环节，包括测试项目背景的掌控、沟通等等。




参考：  软件测试内容全貌——全景图(1)

 

在过去的一年里，访问自己博客来自世界各地。

不管是处在互联网非常发达的北美，还是处在相对落后、遥远的非洲，都有自己博客的访客，这是一件非常高兴的事。

来自于ClustrMaps的映射图就真实地展示了自己博客的访问者的分布情况。

在国内的访客，绝大部分来自于发达和较发达区域，如华东、华南、华北和东北等，而西北、西南等区域的互联网相对落后，特别是西藏、甘肃、宁夏、内蒙古等区域的访问者寥寥无几，但新疆例外，乌鲁木齐等城市还是有近千人次。

除 了国内之外，大部分的访客来自于美国、欧洲、日本、印度、印尼、澳大利亚、新西兰、韩国等，非洲和南美洲很少，但还是有一些访客。唯一奇怪的是，在俄罗斯 没有一个访客，不知什么原因？俄罗斯的互联网应用也不错，华人也应该不少，包括中国留学生。因为这张图，在一定程度上也反映了华人在世界上的分布状态，或 者说有知识的华人分布情况，或中国留学生在国外的情况。

这张图是不是告诉我们，在今天，不管你身处何地，哪怕是在世界的某个角落里，你都可以找到你所需要的东西？你是中国人，哪怕在非洲、南美洲，你也能阅读到来自家乡的地地道道的文字信息？这也许就是Thomas L. Friedman所说的，The World is Flat ——世界是平的。

【Thomas写道】当我扬帆启航，我以为世界是圆的，然而到了真印度，却满眼都是Americans，电话中心讲的英语都是美国口音，软件公司更把美国商业技巧学到了家。哥伦布向国王与王后报告说，世界是圆的，并且以这个发现而名垂青史。我回家后只和老婆一人分享我的发现，声音还压很低。“亲爱的，”我附耳说，“我认为世界是平的。”

【客观事实】早在公元前六世纪，希腊数学家毕达哥拉斯最先提出地球是圆的。后来，古希腊学者亚里士多德通过观察月食，根据月球上地影是一个圆形，第一次科学地论证了地球是个球体。1519年8月葡萄牙航海家麦哲伦率领的5艘海船，用3 年时间，完成了第一次环绕地球的航行，从而直接证实了地球是球形的。

Thomas从全球化1.0、2.0和全球化3.0来阐述“世界是平的”，并将过去近20年发生的变化、产生的新技术、新运动和新的生产/开发模式等比喻为抹平世界的十辆推土机：

• 第1辆推土机：1989/11/9 (柏林围墙倒塌)
• 第2辆推土机：1995/8/9网景（Netscape）公司上市
• 第3辆推土机：工作流软体
• 第4辆推土机：开放源代码运动
• 第5辆推土机：外包（Outsouring）
• 第6辆推土机：岸外生产
• 第7辆推土机：供应链
• 第8辆推土机：内包
• 第9辆推土机：资讯搜寻
• 第10辆推土机：轻科技（类固醇）

    概括起来，这10辆推土机只是在3个方面的突破：

1. 思想的进步或思维的突破（开放、互利和包容），启动了（经济、文化、生活等）全球化的进程。
2. 通讯和互联网的发展，大大减少了时空的限制，消除了全球化的阻碍。
3. （空中/海上）运输业、物流的快速发展，促进了全球化的速度。

世界变成了平的，是说世界在技术发展和资本流动的双重推动下，正发生我们尚无法预料结局的转型——一种新型的扁平结构的社会模式，将取代旧有的金字塔结构的社会模式。但实际上，这种金字塔结构的社会模式还存在着，并且永远存在，是不能被铲平的。社会的经济发展依然存在巨大的差距、是不平的，不可能处在一个水平线上，例如：

• 世界上占人口1％的最富有的人拥有世界财富的40%
• 世界上占人口2％的最富有的人拥有世界财富的50%
• 世界上占人口10％的最富有的人拥有世界财富的85%

如果将每个国家的人均收入用立体显示出来， 世界是非常不平的。

富裕	贫穷

       
        姑且不论这10辆推土机的比喻是否恰当（实际已经有人站出来，说“不”，例如阿罗尼卡、罗杜的针锋相对的观点，写成《世界是平的吗？》），就“世界是平的”这种提法是否恰当，也是值得怀疑的。从老百姓的角度看，Thomas用“世界是平的”，更容易让大家理解“全球化”的概念。但从科学的角度看，“世界是平的”提法是一种倒退，倒退了几千年 

随着互联网、通信的发展，不是将“地球是圆的”三维空间推到平面，而是将地球三维空间推到多维空间，至少是四维空间以上。也只有第四维、第五维的存在，才能突破时空的限制、突破三维的物理限制。

• 对于一维空间，人们是没有选择的。小时候在乡下，很少说东南西北，而是按河水的流动方向知“上下”，如上去到某村，下去到某店，只有一条路可走。
• 对于二维空间（世界是平的），人们才开始有选择的。条条道路通罗马就是一个典型的例子，但在二维空间里，只能用马车、汽车、火车等，军队也只有步兵、骑兵等；但不能乘坐飞机，甚至不能使用海底隧道、地铁等方式，也不能有炮兵、空军、导弹部队。
• 对于三维空间（世界是圆的），人们有了更多的选择。可以建立立体交通网，包括海底隧道、地铁、高架桥、飞机等。
• 现 在,我们所处的地球是一个多维的空间。在一定的程度上，我们已经突破了时空的限制。微波、电波、磁场等都可以看作三维空间之外的东西，帮助人们突破时空的 限制来获得新的沟通渠道、传播方式、生产模式等。从物理信号到数字模拟，数字化的过程本身就是在创建新的空间，原来不曾有的空间。发射卫星、宇宙飞船，突 破地球引力，也就是突破地球是圆的概念，向更远的空间发展。要想突破现有思维的空间、要解开宇宙之谜，必须发现、目前还没探测到的新一维空间 …

参考：

 

在定义测试用例的质量标准之前，先要了解设计测试用例的目的。测试用例是测试工作中最重要的元素或测试件（test ware）之一，是测试执行的基础。测试用例不仅能有效地帮助实施后继的回归测试、知识的传递和测试的管理等，而且更重要的是能更快、更有效地发现缺陷，确保测试的系统性和全面性，在测试的深度和广度达到所期望的目标。也就是说，测试用例的质量就是满足测试目标的程度，体现在 “测试覆盖率和测试执行效率”两个方面。所以，测试用例最基本的质量标准就是：

• 达到已定义的或所要求的测试覆盖率，如大于98％。
• 使测试执行的效率达到最好的水平，如最有效的途径并使60％以上的测试用例被测试工具执行。

(1)高层次——满足某一个测试目标或测试任务来整体看测试用例，衡量一组测试用例的结构、设计思路和覆盖率等指标。

    (2)低层次——从单个测试用例看，衡量其描述的规范性、可理解性和可维护性等指标。

朱少民－软件测试和质量专栏 版权所有

1．高层次（high-level）标准

高层次标准是从满足某一个特定的测试目标出发来进行定义，分析一组测试用例的设计思路、设计方法和策略，包括测试用例的层次、结构等。从高层次看，测试用例设计的关键点是：始终从客户需求的角度（出发）想，始终围绕测试的覆盖率和执行效率不断思考，最终通过有效的技术方法完成测试用例的设计。

对于一整套的测试用例组（集合），可定义如下的质量标准：

(1) 测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。

    (2) 设计思路正确、清晰。例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。

    (3) 在组织和分类上，测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致，并具有合理的优先级或执行顺序。

    (4) 测试用例覆盖所有测试点、覆盖所有已知的用户使用场景（User scenario），也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。

    (5) 测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。

    (6) 有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。

    (7) 没有重复、冗余的测试用例，满足相应的行业标准等。

2．低层次(low-level) 标准

低 层次标准是考察单个测试用例是否满足测试的需求，是否能被更有效地执行。测试用例设计的结果就是交付测试用例，使测试用例被执行，所以除了覆盖率，执行的 效率也是测试用例的一个重要属性。测试用例越清楚，越容易被理解和执行。执行效率越高就说明测试用例越好，如果测试用例能被机器（computer）执行，当然执行效率得到体现。

对于具体的某个测试用例，不妨可定义如下的质量标准：

    (1) 测试用例的出发点是发现缺陷，即单个测试用例在“暴露缺陷”上具有较高的可能性。

    (2) 测试用例的单一性。一个测试用例面向一个测试点，不要将许多测试点揉在一起。例如，通过一个测试用例发现1～2个缺陷，而不能发现5～10个缺陷甚至更多的缺陷。

    (3) 符合测试用例设计规范或测试用例模板，见下面附表所示。

    (4) 描述清楚，包括特定的场合、特定的对象和特定的术语，没有含糊的概念和一般性的描述。例如，测试用例名称为“登录功能使用正常”，就是一个描述不清楚的例子，而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户帐号被锁定后再进行登录操作”等就比较好。

    (5) 操作步骤的准确性，按照步骤的操作得到唯一的测试结果。

    (6) 操作步骤的简单性。操作步骤不应该太复杂，过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。

    (7) 所期望的测试结果是可验证的，即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如，在测试用例中描述期望结果为“登录成功”，这实际是不可验证的。要使这个期望结果具有可验证性，我们就应该这样描述所期望的结果——“‘退出（log out）’按钮出现”。

    (8) 测试环境的正确性、测试数据的充分性。

    (9) 前提条件、依赖性被完全识别出来。

    这样，测试用例具有很好的可理解性和可维护性，可以提高测试执行的效率。并能保证不同的人员执行相同的用例能获得统一的结果。步骤的准确性和期望结果的可 验证性，非常有助于测试执行的自动化实现。也只有实现了测试执行的自动化，测试执行的效率才是最高的，而且测试人员才有更多的时间去思考、去设计更优秀的 测试用例，进入良性循环，相互促进，不断地提升测试的质量和效率。

附表 测试用例模板

字段名称	类型	注释
标志符	整型	唯一标识该测试用例的值，自动生成
测试项	字符型	测试的对象，可以从软件配置库中选择
测试目标	字符型	从固定列表中选择一个
测试环境要求	字符型	可从列表中选择，如果没有，则直接输入新增内容
前提	字符型	事先设定、条件限制，如已登录、某个选项已选上
输入数据	字符型	输入要求说明、或数据列举
操作步骤	字符型	按1., 2., … 操作步骤的顺序，准确详细地描述。
期望输出	字符型
所属模块	整型	模块标识符。
优先级	整型	1，2，3 （1－优先级最高）
层次	整型	0，1，2，3  ( 0 – 最高层)
关联的测试用例	整型	上层（父）用例的标识符。
执行时间	实型	分钟
自动化标识	布尔型	T，F
关联的缺陷	枚举型	缺陷标识符列表。

朱少民－软件测试和质量专栏 版权所有

参考： 

第21回   测试用例设计方法的综合运用
第22回   测试用例的复审 
版权所有，软件测试演义

  最近看到越来越多的博客再讨论职业的发展，使我想到一点，做事的态度与工作态度的区别。

        公司里有一个优秀的工程师，当他的主管问他，你工作做得非常出色，动力是什么？他回答到，“我不是把它当作一项工作去做，而是当作一件事去做，全力做好”。 他的回答很简单、朴实，但说到点子上。对于一个员工的工作（job），多数情况下可以看作是一个任务（task）, 员工做工作，就是执行任务。执行任务，就比较被动，就事论事，交给我什么，就做什么，不去多想。而：

• 一般意义上完成任务，是对员工的基本要求。如果某位员工年终没有涨工资，就跑到经理那里去说，交给我的工作都做了（意思是说，自己很不错），为什么不给我涨工资？你可以对他/她说，这是基本要求，你做到了，所以没降你的工资。
• 如果能圆满完成任务，还是一个不错的、称职的员工，表现良好，还不能算优秀的员工。

       作为一个优秀的员工，应该是积极主动地去工作，或者说，不是把工作当任务去做，而是当成自己的事去做，做得完美。他/她会主动地思考，想到事情的前面去，把可能要发生的问题、将来可能要发生的问题都尽量想到。在英文里有两个词 “Active” 和 “Proactive”,  active 是主动、积极的意思，proactive （前摄的，中文字典是这样翻译的）类似预警机，更早、更主动地发现问题和解决问题。我们希望员工主动、积极去做事，而不是被动 （passive）去做事情。但对于一个优秀的员工，不仅 active, 而且要proactive。

        现在流行一句话 “态度决定一切”，也说明了这样一个道理。现实，可能残酷些，大家要为房子、车子等奔波，所以需要工作。如果仅仅为了工作，或者工作就是为了拿一份薪水，当然就很难快乐，至少难以对工作充满激情。如果工作就是为了工作，每天早上起床、匆匆忙忙打理完，坐上班（私、公交）车后，就可能会感觉一天的受罪开始了。如果你不仅仅把自己的工作当成一份工作，而是想和公司一同去做一件事（虽然不一定是去做伟大的事业，如：

• 把产品做出去获得新市场、赢得国际市场
• 做出一个国内一流的团队
• 把公司做大、从20人做到100人、再做到500人

），那你的感觉就不一样。你可能会说，我们也不能不顾 “薪水、待遇、工作环境” 呀？实际上，你有了proactive的态度，又把工作当事做，而不是当“任务”来完成，这些都会很好的，面包会有的。当然，做好事情，还要有一个前提，对所做的事情，你是有兴趣的。大学生或他们的父母经常谈，要专业对口，其实不重要，关键是兴趣。许多计算机做得很好的人，在大学里并不是学计算机的。

        兴趣、享受工作，会对一个人对待工作的态度也是很有帮助的。国内教育还是有问题的 ( 包括我写的 我国教育中令人揪心的若干个"不等式" )，作为父母，常对孩子说，“长大了，要挣钱、做官、出人头地”等等。几千年文化，给人更多的思想是 “升官发财、衣锦还乡”，这本身也没错，但缺乏教育自己孩子，“快乐” 是最重要的。也就是在你挣钱的工作中间，许多 “H” 是重要的，Happy、Health、Home等。 微软、Google、雅虎的创始人，当初都不是为了发财去创业，甚至创业是被 “逼上梁山” 的，如Google的创始人(Larry Page 和 Sergey Brin)当初就想100万卖给一些大的网络公司等，没人买，自己才继续干下去。这和国内目前许多人为了发财、为了创业而创业形成鲜明的对比。

      说远了，回过头来，就是8个字 “兴趣、做事、享受工作”， 然后你就会将工作做得完美。

PS: 完美的工作，也顺便帮了我——质量就有了保证。

这不仅从Glenford J. Myers《测试的艺术》得到验证，还可以从许多方面得到验证，如从下列一系列之间的辨证关系中得到进一步的验证： 白盒测试方法和黑盒测试方法 静态测试 (static test) 和 动态测试( Dynamic test) 手工测试（Manual test）和自动化测试(Automated Test) 有计划测试（Planned Test）和随机测试（Ad-hoc test 或Random test） 新功能测试（new feature test）和回归测试 (Regression testing)   见我的博客（软件测试和质量专栏 －http://blog.csdn.net/KerryZhu/  ）系列文章 测试方法的辩证统一 （之一） 测试方法的辩证统一（之二） 测试方法的辩证统一（之三） 测试方法的辩证统一（之四） 当然，我还得用更多得时间来进一步验证。 这就算是开场白.....