C++博客-牵着老婆满街逛-随笔分类-软件工程http://www.cppblog.com/tx7do/category/2131.html危机感是一种强大前进的动力！</br> GMail/GTalk: yanglinbo#google.com;</br> MSN/Email: tx7do#yahoo.com.cn;</br> QQ: 3 0 3 3 9 6 9 2 0 .zh-cnMon, 19 May 2008 14:21:03 GMTMon, 19 May 2008 14:21:03 GMT60用例驱动的需求过程实践http://www.cppblog.com/tx7do/archive/2006/08/23/11619.html杨粼波杨粼波Wed, 23 Aug 2006 11:04:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/23/11619.htmlhttp://www.cppblog.com/tx7do/comments/11619.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/23/11619.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11619.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11619.html　　根据CHAO的权威统计，虽然自"软件危机"提出以来，软件工程方法得到了长足的发展与进步，但在去年的软件项目成功率仍然不足30％，绝大多数的软件项目仍然超进度、超成本。而在这些不成功的项目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。
　　下面的这幅漫画虽然不乏夸张，但却是能够激起我们的深思：

　　根据笔者多年来从事软件需求捕获、分析工作的实践经验，认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍，双方都以自己的角度、自己的专业术语进行沟通，这使得大家并不能够很好地就软件需求达成共识。
　　由于帮助客户更好地利用信息化工具提高工作效率，是我们软件开发团队的责任，因此我们没有权利让用户理解我们所用的语言，而是反过来，我们有义务去理解用户的语言，站在用户的角度看问题。
　　而事实上，许多开发团队经常抱怨"我们的客户连需求都说不清楚"、"我们的客户对计算机了解太少了"。多年以来，大家都习惯从自己的角度来定义、分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业，我们需要改一下习惯了。
二、现代需求实践
　　针对这些现象，许多先贤们开始了实践，并且总结出了一系列优秀的需求实践：
1）Use case：用例分析技术
　　鼎鼎大名的RUP是这样总结自己的：用例驱动，以体系结构为中心，迭代、增量的开发过程。Use case也伴随着RUP、UML一起名扬天下。
　　用例用来描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员（风险承担人，Stakeholder）之间就系统的行为所达成的契约。
2）User Story：用户故事、用户素材
　　用户故事是Kent Beck在极限编程（XP）方法论中推荐的最佳实践之一。它由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语写就，三句话左右。
3）Feature：特征
　　这是特征驱动开发（FDD）方法论的核心实践之一。一个特征就是一个小的，具有客户价值的功能，通常表示为<action><result><object>。
　　从上面的定义来看，这三种现代软件工程需求实践无一例外地遵从两个原则：一是站在用户的角度看待系统、定义系统；二是用用户看得懂的语言表达。而在笔者的实践中，鉴于以下两点考虑还是先在团队中应用了"用例分析技术"：
1）用户故事略显粗糙，掌握起来需要经验，没有详细的规则用于按部就班，一开始采用容易迷失方向；而用例相对来说更加形式化，易于上手；
2）特征看上去很有吸引力，但毕竟相关的理论还未完整，引入团队实践有些困难。
三、用例分析技术简介
　　用例分析技术是Rational三友之一Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后，与三友合作提出了UML、完善了RUP，用例分析技术也因此被人广泛了解和关注。
　　用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。
　　许多人是在学习UML的时候接触到Use case，所以许多人都误解其为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述才是用例分析技术的核心。下面是一个简单的例子：

3.1 参与者，Actor
　　参与者，定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的系统。
3.2 用例，Use case
　　用例实例（场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例（场景）。
　　一个用例应为参与者提供（实现）一个价值。

3.3 事件流
　　就像类对应于对象一样，一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结：
　　1）前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；
　　2）后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；
　　3）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；
　　4）扩展事件流：主要是对一些异常情况、选择分支进行描述。
　　建议大家在编写事件流时，注意以下几点：
　　1）使用简单的语法：主语明确，语义易于理解；
　　2）明确写出"谁控制球"：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
　　3）从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是第三者的角度；
　　4）显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键做为一个事件就是不合适的）；
　　5）显示参与者的意图而非动作（光有动作，让人不容易直接从事件流中理解用例）；
　　6）包括"合理的活动集"（带数据的请求、系统确认、更改内部、返回结果）；
　　7）用"确认"而非"检查是否"：（如系统确认用户密码正确，而非系统检查用户密码是否正确）；
　　8）可选择地提及时间限制；
　　9）采用"用户让系统A与系统B交互"的习惯用语；
　　10）采用"循环执行步骤x到y，直到条件满足"的习惯用语。
四、Alistair Cockburn眼中的用例分析技术
　　在使用用例分析技术时，很多人都觉得如何确定用例的粒度是一个难点，而且感觉到用例没有什么规则遵从，甚至有无所适从的感觉。正如Cockburn先生提出的学习用例分析技术的"守、破、离"的三个阶段：
　　1）守：练习基本功夫，遵循规则，照章行事；
　　2）破：能突破传统，因地制宜地灵活应用； 3）离：超脱任何招式与规则，达到无招胜有招的境界。
　　但用例分析技术却让第一阶段的初学者感到无法很快地掌握。而其所著"编写有效用例"则想为用例分析技术补充规则，让大家能够更好地掌握。
　　Cockburn先生在Ivar Jacobson的基础上，做了一些补充：
　　1）用例是契约，是系统与涉众之间达成的契约。也就是将用例朝着形式化的方向发展；
　　2） 将用例分成三级：
　　◆ 概要级：包括多个用户目标（显示用户目标运行的语境，显示相关目标的生命周期、为低层用例提供一个目录表）；
　　◆ 用户目标级
　　◆ 子功能级
　　不过，对于Cockburn先生的贡献，用例始祖Ivar大师并未做出任何反应。本人在实践中认为，Cockburn先生的思路与理念对于初学用例分析技术的人来说，十分有价值，使得用例分析技术更具操作性，当其同时也有点画地为牢的感觉，也许Cockburn先生也意识到这点，因此第三阶段就是"离"，没有规则，按需灵活使用。
五、如何在开发过程中应用用例分析技术
　　用例分析技术在需求过程中的地位如下图所示：

　　对于用例分析技术理解上的两个最大的误区是：
　　1）用例分析技术包括了整个需求过程：它只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，并无法替代这些技术；
　　2）用例分析技术是分解技术：其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例：

5.1 用例分析前的工作
　　在用例分析之前，应该完成以下工作：
　　1）确定涉众（Stakeholder）和用户类型（命名、简要描述、涉众代表、特征、能力）；
　　2）确定涉众代表（命名、简要描述、责任、参与）；
　　3）在项目中加入涉众代表（访谈、问卷、顾问、评审、角色扮演）；
　　4）创建共同的构想（问题定义、系统范围、用户目标、非功能需求à前景文档）；
　　5）采用传统的需求捕获技术捕获需求；
　　6）组建用例分析队伍（少量、有问题域知识）。
5.2 用例分析过程中的注意事项
　　用例分析的过程如下图所示：

　　在使用中要注意：
　　1）用例源于涉众，请不要自己杜撰出用例；
　　2）用例的事件流的编写过程中，应充分加入团队的参与；
　　3）虽然用例源于涉众，但不要企图向他们直接问"你还有什么用例?这样的问题

杨粼波 2006-08-23 19:04 发表评论
]]>特性、用例、需求－－ Rational软件白皮书http://www.cppblog.com/tx7do/archive/2006/08/23/11618.html杨粼波杨粼波Wed, 23 Aug 2006 11:03:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/23/11618.htmlhttp://www.cppblog.com/tx7do/comments/11618.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/23/11618.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11618.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11618.html作为 BU（UML 出现之前）时代面向对象技术的追随者和支持者，我必须承认当时的业内思想领袖所传播的各种方法和表示法对我具有某种魔力。在 UML 出现之前的两到四年中，您可以走进一个挤满 OO 鼓吹者的房间，并提问以下问题：

我认为这种 OO 技术很有前途，但是告诉我，既然对象共享行为和数据，那么您如何称呼对象为实现它的行为义务而做的事情呢？

您可能得到如下答案：

  • "它是一个职责！"（Wirfs-Brock）
  • "它是一项操作"（Booch）
  • "它是一项服务"（Coad/Yourdon）
  • "它是一个（虚）函数"（Stourstrup）
  • "它是一个方法"（其他很多人）

如果这还不足以让您混淆的话，那么就不要问您如何用图形表示我们称之为对象和类的东西了。（它是一个矩形、一片云，等等。）虽然这看上去很愚蠢，但是实际情况是，我们软件工程领袖的其中一些最显著的共识（继承、关系、封装），由于在术语和表示法上的微小区别而无法得到共享，或者至少变得混乱。换言之，不管是 OO 工程科学还是将要获得的利益都不能继续向前发展，因为还没有发明用来描述该科学的语言。当然，要在这些作者、方法学家 和独立思想者中达成共识不是一件小事情，但是最终UML面世了，软件工程科学又向前迈进了一大步。

虽然需求管理方法学可能不像 UML 出现之前的 OO 方法学所形成的巴比塔那样糟，但是它却经历了同样的一些问题--尤其是对常见词汇的模糊、不一致和过度使用非常盛行。这些词汇（包括诸如"用例"、"特性"和"需求"这样的基本概念）是"每个人都理解"的日常词汇，但是在给定的上下文中每个人又赋予了它们自己的含义。结果就是沟通不畅。这种情况仅在将达成共识作为成功标准的领域中发生。Booch [Booch 1994]引用了 Stepp 的说法：

科学中普遍存在的一个问题是为观察到的对象和情形构造有意义的分类。这样的分类能推动人们对观察以及后续的科学理论开发的理解。

为了推动需求的"科学理论"，我们不得不面对术语的问题。

本文的目的在于，通过定义并描述用于说明系统软件需求的一些最常见术语和概念，来初步探讨一下软件工程的原理。为此，我们希望提供一个能让所有涉众（用户、经理、开发人员等）达成共识的基础。当然如果我们更有效地交流并因此获得一致看法，那么就可能更快地开发并交付更高质量的系统。

本文重点不在于需求管理的原理--关于这方面笔者在建议读物中推荐了很多参考书目。本文的目的仅是帮助该领域中的从业者提高他们对系统正确行为的基本认识。

问题域与解决方案域的对比
在开始描述具体的术语之前，我们首先要意识到需要从两个完全不同的方面定义术语：问题方面和解决方案方面。我们分别称之为问题域和解决方案域。

问题域
如果我们在问题域上做一次"低空滑翔"，就会发现许多实际生活周围的事物。比如"滑翔"过人力资源部门时，会看到雇员、负责发工资的职员以及工资支票。"滑翔"过重型设备工厂时，我们会看到焊工、焊接控制器、焊接机器人和电极。"滑翔"过万维网时，我们会看到路由器和服务器群集，以及具有浏览器、电话机和调制解调器的用户。换句话说，在任何问题域中，我们可以轻易地识别出我们看到和接触到的事物（实体）。有时候，我们甚至可以看到这些事物之间的关系；比如，web 用户和浏览器之间就是一对一的关系。我们可能还会看到从一个事物传递到另一个事物的消息："焊接工似乎正在往焊接机器人的'大脑'中编制工作次序"。

如果我们是敏锐的观察者，可能会发现亟待解决的问题："焊接工对不能安排正确的工作次序感到气馁"或者"注意到雇员输入薪水数据与收到支票之间有令人不愉快的时间延迟！"。有些问题似乎只是在乞求一种解决方案。也许我们可以构建一个系统（更好的可编程控制器、更有效的工资处理）以帮助那些可怜的用户解决这些问题。

 

基于用户和涉众需求

然而在我们构建新系统之前，我们需要确保理解了该问题域内用户的真正需要。如果没有，我们可能会发现焊接工只能愁眉苦脸，因为他就好像脚上得了鸡眼一样痛苦，结果就是他和他的经理都不会对购买我们最新的"SmartBot"自动焊接控制单元感兴趣。我们还注意到当我们试图销售 SmartBot 时，经理是购买决策中的关键涉众。我们不记得在"滑翔"中看见过她。（也许她当时正在吸烟室，而那里正是我们摄像头的盲区）。换言之，不是所有的涉众都是用户，并且如果我们希望有机会卖出SmartBot，则我们必须同时理解两个社区（涉众和用户）的需要。为了简便起见，我们称所有这些需要为涉众需求，但是我们要不断地提醒自己系统的潜在用户有时代表了很重要的一种涉众类型。

我们将涉众需要定义为：

业务、个人或操作问题（或机会）的一种反映，其中这些问题必须得到解决，以使用户相信他们考虑、购买或使用新系统的选择是正确的。

于是涉众需求就成为与问题域关联问题的一种表示。这些涉众需求并未给出解决方案，但是以一个最初的角度，使我们了解需要实现哪些可行的解决方案。比如，如果我们会见重型设备制造厂中管理焊接工的经理，就可能发现焊接大量重复性的焊接件会消耗巨大的制造时间和成本。另外，焊接工似乎不会喜欢这些具体工作，因为他们一直处在被烫伤的危险中。更糟的是，该工作的物理方面（重复、难以琢磨的手工操作位置以及对视力的危害等）带来了个人安全问题以及长远的健康隐患。

充分理解了这些事项，我们就可以开始定义其中一些涉众需求：

  • 我们需要一种自动化的方法来制造大量重复的焊接件，而不用让焊接工手动控制电极。
  • 我们很乐意能有一位焊接工，但是我们需要将其移到焊接件以外的安全区域并且远离那些移动的机器。
  • 我们需要能轻松使用"训练模式"，这样一般的焊接工也能够"训练"机器为他们做大部分工作。
  • 我们需要使训练模式中具有更大的灵活性，并且意识到这可能与用户友好性需要的某些方面产生冲突。

当理解了系统的这些不同方面后，主观上我们会将这些发现"堆放"在一个称之为涉众需求的小堆中。

解决方案域
幸运的是，对问题域的"滑翔"不会花很长时间，并且（通常）我们在问题域中发现的东西也不是很复杂。当我们完成"滑翔"并开始构建我们观察到的问题和需要的解决方案时，就开始理解问题。是的，我们已经开始了最难的一部分：构建问题的解决方案。我们考虑活动集（系统定义、设计等）、为了解决问题而发现和构建的"事物"（计算机、机械臂等），以及在解决方案域的处理部分中创建的工件（比如源代码、用例和测试）。

在解决方案域中，我们必须成功地执行很多步骤和活动，这样才能定义、构建并最终部署问题的成功解决方案。它们包括：

1） 理解用户需求

2） 定义系统

3） 管理范围并管理变更

4） 精化系统定义

5） 构建正确的系统

简言之，上述步骤定义了需求管理的一个简化过程。本文不打算详细介绍这些步骤；关于这些内容我们会为您推荐一些参考读物，包括课本"Managing Software Requirements"，[Leffingwell, 1999]。本文与该参考书保持一致，这里提供的大部分定义都来自该参考书。

比如，在参考书[Leffingwell, 1999]中，我们会发现需求管理是这样定义的：

获取、组织和记录系统需求的系统化方法，在客户与项目团队之间建立并维护对系统需求变更的一致意见的过程。

还是让我们继续寻找并定义用于描述待建系统所需的其他更多的需求管理术语吧。

解决方案域中的常见需求术语
　

产品或系统的特性
当我们开始考虑已识别问题的解决方案时，很自然会匆匆记下系统的特性。特性在系统的开发中占有很有趣的地位。它们看上去介于用户真正需要的表达与系统实现这些需要的详细方式描述之间。这样，它们就为按照抽象的方式描述系统提供了一种方便的构造，或者如果您愿意的话，提供一种"速记方法"。由于需要解决的问题存在很多可能的解决方案，所以在某种意义上特性提供了特定系统解决方案的最初范围；它们描述了系统打算做什么以及不打算做什么。

我们将特性定义为
系统为实现一个或多个涉众需要而提供的服务。

我们可以很容易地使用用户熟悉的术语用自然语言来表示特性。例如：

  • 系统使用的是标准的北美电源。
  • 树浏览器提供了组织缺陷信息的一种手段。
  • 家用照明控制系统具有与标准家用自动化系统的接口。

由于特性是从涉众需求派生而来的，所以我们将它们安排在金字塔的下一层，即需要的下面。与此同时，我们还从问题域（需要）转移到了解决方案域的第一层（特性）。

有一点很重要，需要注意，那就是特性不仅仅是涉众需求的精化（增加了细节）。相反，它们是用户提供的对问题的直接响应，并且它们为我们提供了问题的顶级解决方案。

通常，我们应该能够通过定义 25 到 50 种刻画系统行为的特性来描述系统。如果您发现手头有超过 50 种的特性，那么可能是因为您没能抽象出系统的真正特性或者是系统过于庞大而难于理解，您需要考虑将其分为更小的部分。

特性是用自然语言描述的，所以读到该清单的任何涉众都能立即获得对系统行为的基本理解。特性清单会缺乏细粒度的详细程度。这没关系。我们只是在试着交流目的，并且由于很多涉众都是非技术人员，所以过多的细节可能会让他们混淆甚至干扰理解。通过例子，我们 SmartBot 自动焊接机器人的部分特性清单可能包括：

  • 允许焊接工教导机器人焊接哪些路径的"lead through path"训练模式
  • 支持重复焊接次序的"step-and-repeat"特性。

用例
当我们进一步考虑系统完成用户任务的方法时，我们可能发现使用用例技术来进一步描述系统行为很有利益。该技术在很多书籍[Jacobson 1992]中已经得到了很好的发展，并且也是行业标准统一建模语言[Booch 1999]的一个组成技术。

从技术上说，用例：

描述了系统执行的、为用户带来价值的一系列动作。

换言之，用例描述了有助于用户实现他们期望的一系列用户和系统交互。再换一种说法，用例描述了用户和系统如何共同合作以实现所识别的特性。

用例还引进了参与者这项构造。参与者只是当时使用系统的用户的一个标签。在 UML 中，用一个简单的椭圆来表示用例，而参与者则用一个带有名称的线条画表示。所以可以如下所示用一个简单的图来说明这两者。

用例技术规定了参与者如何实现用例的一个简单的逐步过程。比如，用于 Step and Repeat 的用例可能如下所示：

步骤1：焊接工按下 step and repeat 按钮，启动该序列。

步骤2：焊接系统为驱动电动机供给电源，以便可以人工控制机器臂移动。

步骤3：焊接工握着扳机，将机器臂移动到焊接部位，并按下"weld here"按钮，焊接每一条需要焊接的线路。

用例技术提供了很多其他有用的构造，比如预描述和后描述（pre and post description）、可选流（alternate flow）等。我们将在后面详细讨论用例时再讨论它们。但是现在，我们只需要知道用例提供了一个优秀的方法用来描述如何实现系统特性。

出于计划的目的，可能需要除用例之外的一些方法来描述如何实现特定的特性。对于每个特性可能只需要几个用例即可（也许 3 到 10 个）。在描述用例过程中，我们详细阐述了系统的行为。随着其他特征的获得，用例也变得更加详细。

远景文档
在很多开发尝试中，问题的声明、关键涉众、用户需求、系统特性清单，也许还有示例用例都可以在一个被称为远景文档的文档中找到。它还有其他很多名称，比如项目章程（Project Charter）、产品需求文档（Product Requirements Document）、市场需求文档（Marketing Requirements Document）等。不管名称如何，远景文档强调了正在构建系统的总体意图和目的，因此，是那些被标明日期的特性和说明性用例的自然容器。换言之，远景文档捕获了系统的完全形态，并使用涉众需求、特性和用例来交流意图。

然而，我们不能简单地把这些特性和初始用例转交到开发团队手中，并期望他们很快开发出真正满足涉众需要的系统。我们可能需要在系统功能方面更加明确，并且可能涉及了各种新的涉众，包括开发人员、测试人员等。这是系统定义的下一层（软件需求）要解决的需要。

软件需求
软件需求在软件定义过程中提供了下一层特异性。在这一层上，我们必须指定足够的需求和用例，以便开发人员可以编写代码，并且测试人员可以测试这些代码是否满足需求。从图形上说，软件需求提供了我们金字塔的塔基。

什么是软件需求？尽管在过去的多年中已经有过很多种定义，但是我们发现需求工程创始人 Dorfman 和 Thayer[Dorfmann 1990]提供的定义最合适：

  • 用户解决将实现一个目标的问题所需的软件功能，或者
  • 必须被一个系统或者系统组件满足或拥有，以满足合同、标准、规范或其他正式发布文档的软件功能。

应用该定义，开发团队能够开发出更具体的需求集，以完善或精化前面讨论过的特性清单。每个需求都是某种特性，反之亦然。注意这种方法的简单性。我们有一个特性清单，然后通过编写一个为这些特性服务的需求集来精化它们。我们不编写任何其他需求。这避免了只是坐在椅子上、瞪着天花板，并"为该系统捏造一些需求"的诱惑。

该过程简单明了，但是并不容易。每个特性都需要检查，然后编写需求以支持该特性。不可避免地，为某项特性编写需求会引发您为已经检查过的特性添加新的需求，或者对其进行修订。

当然，您知道编写需求并不容易，并且可能需要指定大量需求。我们发现考虑三种类型或者种类的软件需求（功能性需求、非功能性需求和设计约束）很有帮助。

我们发现这三种需求在我们考虑需求的方式以及我们期望需求实现的任务方面很有帮助。让我们看一下这些不同类型的需求，以及您可以如何使用它们来定义期望系统的各个方面。

功能性需求

功能需求表达了系统行为。更具体地说，功能需求描述了输入和输出分别是什么、以及特定输入如何在不同时刻被转化成特定的输出。能有效工作的大部分软件应用程序都具有丰富的功能性需求。在指定这些需求时，要权衡模糊性（"当您按下 On 钮之后，系统就会打开"）与具体性这二者的关系，这一点很重要。给予设计人员和实现人员以尽可能多的设计和实现选择也很重要。如果我们过于具体，那么就可能过于限制开发团队，如果过于宽松，则开发团队就不知道系统应该实现哪些功能。

指定需求的正确方法不只一种。其中一种技术只简单采用了声明性的方法，并写下系统需要做的每一件详细的事件。

比如：在"weld here"输入被激活时，系统通过每 100 毫秒读取一次光编码器来数字化电极端的位置。

细化用例

在很多系统中，通过精化以前定义的用例并开发其他用例，则易于组织规范活动来全面细化系统。利用这项技术，您可以将用例步骤精化成更详细的系统交互。您还需要定义前置条件和后置条件（在用例之前和之后陈述系统假设），以及由于异常条件而需要的备用动作等。

由于用例在语义上是良好结构的，因此它们提供了一种组织和捕获系统行为的结构。下面是 Smartbot 的代表性用例。

非功能性需求

除了像输入转换为输出这样的功能性需求，大多数系统还需要定义一组着重指定其他系统"属性"的非功能性需求，比如性能需求、吞吐量、可用性、可靠性和可支持性。这些需求和面向输入输出的功能需求同样重要。通常，非功能性需求的表达方式是声明性的，如： "系统的平均故障间隔时间应该为 2000 小时"，"系统的平均修复时间应为 0.5 小时"，以及"Smartbot 最多应该能够存储和检索 100 条焊接路径"。

设计约束

与定义系统行为不同，第三类需求通常对系统设计或者我们用来构建系统的过程施加了限制。我们将设计约束定义为：

系统设计上的限制，或者系统开发步骤上的限制，它不影响系统的外部行为，但是必须被实现，以满足技术、业务或合同要求。

典型的设计约束可能是这样表达的："用 Java 为焊接工控制单元编程"。一般来说，我们将合理的设计约束看作其他需求，尽管符合这些限制的测试可能需要不同的技术。正如功能性和非功能性需求一样，这些约束在系统的设计和测试中扮演了不可或缺的角色。

分层结构需求

很多项目通过利用分层或父子结构表达这些需求而受益。父子结构需求是利用父需求表达的特异性的一种扩大。父子需求为您提供了一种增强和扩大规范的灵活的方法，同时还可以组织提供的详细程度。只看父需求，很容易按照易被用户理解的方法提供顶级规范。同时，实施人员可以快速检查详尽的"子需求"规范，以保证他们能够理解所有的实施细节。

注意，分层结构需求由三种标准类型的需求组成--功能性、非功能性和设计约束。这里只定义了这些需求间的细化关系。

可跟踪性
除了为描述我们用来说明系统需求的事物而定义的术语之外，我们现在将注意力转移到关键关系，即可跟踪性，也就是在这些事项之间可能存在的关系。

开发出高质量软件的一个重要因素就是在规范、构架、设计、实现和测试阶段理解或跟踪需求的能力。历史数据表明变更的影响通常被遗漏，系统的小小变更可能带来显著的可靠性问题。因此，跟踪关系并在发生变更时关联这些关系的能力，形成了很多现代软件质量保证过程的关键线程，尤其是在任务关键活动比如安全关键系统（医疗和运输产品），和故障的经济成本很高的系统（在线交易）中，形成了一个关键线程。

下面看一下我们如何定义需求可跟踪性：

可跟踪性关系是一种依赖关系，其中实体（故障、用例和需求）"traced to"在某种程度上依赖于它"traced from"的实体。

比如，我们已经描述了如何创建一个或更多软件需求，以支持远景文档中给定的特性或用例。因此，我们可以说这些软件需求与一个或更多特性具有可跟踪性关系。

影响分析和怀疑

另外，可跟踪性关系超出了简单依赖关系的范围，因为它提供了利用我们称之为"怀疑"的概念进行影响分析的能力。当变更出现在"traced from"（独立）需求中时，可跟踪性关系就开始"怀疑"，因此必须对"traced to "（依赖需求）进行检查，以保证它与源需求保持一致。

比如，如果我们使用可跟踪性将需求与特定测试关联，并且如果诸如"Smartbot 应该能够存储和检索最多 100 条焊接路径"这样的需求变为"Smartbot 应该能够存储和检索最多 200 条焊接路径"，那么从该需求跟踪而来的测试就值得怀疑，因为为测试第一个需求而设计的测试不太可能适合测试第二个需求。

变更请求和变更管理系统
最后，变更是不可避免的。对于有希望成功的项目，管理变更的过程是必不可少的。不管它们的来源是什么以及来源如何众多，所有变更包括影响特性和需求的请求需要有序地被引进和管理。任何变更管理系统的关键元素都是变更请求本身。

我们将变更请求定义为：

对系统的特性和/或需求作出修订或添加的正式请求。变更请求需要作为提议变更的结构化和形式化的陈述，以及围绕该变更的任何细节进入系统。为了管理这些变更，每个变更都要在系统中有自己的身份，这很重要。变更请求的简化形式可能为：

在大部分项目中，您会发现不缺少变更！实际上，您的问题是按照有序的方式管理、集成和（根据需要）拒绝不必要的变更。换言之，您需要一个管理变更过程。您的变更管理系统应该用于捕获所有输入，并将它们提交给变更控制委员会（CCB）来解决。CCB 由不超过 3 到 5 个代表项目关键涉众（客户、市场和项目管理）的人员组成，它管理和控制系统变更，因而在帮助项目成功方面扮演了关键角色。

结束语
刚一开始，我们就指出本文的目的在于帮助该领域的从业者提高他们回答下列基本问题的能力：
"系统究竟应该实施哪些行为？"

作为实现这一目标的第一步，我们定义和描述了分析人员以及负责描述问题域中问题的其他人员所使用的，用于表达将施加在预期解决方案上的需求的一些常见术语（比如涉众需要、特性、用例、软件需求等）。在这个过程中，我们还阐述了有效需求管理的一些关键概念。通过使用本文提供的术语和方法，您能够更有效地理解用户需要，并与开发人员、测试人员以及负责构建满足客户和用户需要的系统的其他技术团队成员交流提议解决方案的需求。

进一步定义和交流软件解决方案的其他更多关键方面的一项重要技术就是标准建模语言。统一建模语言（UML）是一种用于可视化、指定和文档化软件密集系统的工件的语言，并且提供了按照语义上更精确的方式表达这些技术构造的手段。本文的姊妹篇，Modeling the Requirements Artifacts with UML（利用 UML 建模需求工件），建立了更有效执行需求管理任务所必需的 UML 构造和扩展。

建议读物
[Leffingwell 1999] Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Unified Approach. Reading, MA: Addison Wesley Longman, 1999.

[Weigers 1999] Weigers, Karl. Software Requirements, Redmond Washington: Microsoft Press, 1999.

参考资料

  • [Booch 1994] Booch, Grady. Object-Oriented Analysis and Design with Applications, 2nd ed. Redwood City, CA. Benjamin Cummings, 1994.

    　
  • [Booch 1999] Booch, Grady, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. Reading, MA: Addison Wesley Longman,1999.

    　
  • [Dorfmann 1990] Dorfmann, Merlin, and Richard H. Thayer. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.

    　
  • [Jacobson 1992] Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar ?vergaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Harlow, Essex, England: Addison Wesley Longman, 1992.

    　
  • [Rumbaugh 1999] Rumbaugh, James, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Reading, MA: Addison Wesley Longman, 1999.
    　
  • 请参加Rational 中国论坛关于本文的讨论。
    　

　

关于作者
在 Rational 软件公司里，我很荣幸能够与一些业内资深方法学家（Grady Booch、Ivar Jacobson、Jim Rumbaugh、Philippe Kruchten、Bran Selic 等人）协同工作。尽管这是我的职业生涯中有益的、令我痴迷的一部分，但这不是我可以推荐给每个人的。换言之，请不要在家尝试这样做。


杨粼波 2006-08-23 19:03 发表评论
]]>用例的需求分析-读书笔记http://www.cppblog.com/tx7do/archive/2006/08/23/11617.html杨粼波杨粼波Wed, 23 Aug 2006 11:02:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/23/11617.htmlhttp://www.cppblog.com/tx7do/comments/11617.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/23/11617.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11617.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11617.html一.系统边界和参与者
参与者Actor定义:在系统之外,透过系统边界和系统进行有意义的交互的任何事物
透露出参与者的特征:
1.不属于系统
2.通过系统边界直接和系统交互->参与者的确定决定了系统边界的确定
3.进行有意义的交互
4.任何事物

其中第二点的"直接"要注意:如果一个顾客通过售票员买机票,那么对于售票系统来说,售票员是参与者而顾客不是.
由此又产生了业务建模和系统建模的区别:对于售票系统来说,当业务建模的时候,我们描述的是顾客来订票,可能还有票务中心的主任来询问售票情况等等事件.但是系统建模的时候,他们都不是我们的对象,我们描述为售票员要售票和提供售票情况的事件的描述,因此这两者在建模的不同阶段是不一样的.

在有些自动系统中,时间往往是触发系统工作的外部事物,因此参与者是时间,不可忽略.

识别参与者方法:面对一个系统时,你应该问这些问题:
谁使用系统?
谁改变系统数据?
谁从系统获取信息?
谁需要系统的支持来完成日常工作?
谁负责管理并维护系统正常运行?
系统要应付那些硬设备?
系统要和其他的系统交互吗?
谁对系统产生的结果感兴趣?
时间,气候等外部条件呢?
当你回答完这些问题之后,你的答案基本上就涵盖了参与者的候选人.


识别参与者的重要性:
1.根据参与者识别系统用例:因此为了完整系统的功能,你识别的系统参与者宁多勿少.
2.测试部署阶段你可能会通过识别者的角度去了解系统的完整性.
3.用例文档编写阶段,参与者不是很重要,但是你应该考虑参与者的泛化关系,避免出现用例的重复功能.



二.识别事件
罗列清楚系统事件,是正确建立系统用例的必要条件.

系统事件分为两类:系统外部事件和系统内部事件
外部事件就是外部参与者对系统交互的具体工作,内部事件就是系统内部触发的工作,通常由时间触发.

识别事件的方法:头脑风暴法-主语+谓语+宾语,描述系统可能发生的事情,尽可能全面,同样是宁多勿少的原则,不过你可以根据事件的重要程度进行一个排序,这能加深你对系统的认识.

通常把识别出来的事件列成一个表格:称为3A表
Actor  Action Aim
参与者  作甚么  业务目的
...  ...  ...



三.识别用例
用例定义:用例是一组用例实例
用例实例定义:系统执行的一系列动作,用以产生参与者可观测到的结果值

用例要点:
1.位于系统  --必须由系统运行
2.目标导向  --用例运行必须有所目的
3.止于边界  --可以观测到结果,并且是在边界和外部有所交互的
4.用户观点  --参与者观测
5.粒度   --是一组有共同目标或者可以类聚的目标的实例们组成

识别用例是从业务建模开始的,也就是说我们描述用例是从用户的角度即用户观点出发的识别行为,描述用例是用纯粹的业务语言,而不是技术语言.比如描述为清缴税款,而不是J2ee架构.因此,用户的命名也是从用户的角度出发,描述用户要做的一件通过系统完成有目的,有结果的行为.

用例的粒度不宜过细,过细的分解会导致用例描述的错误:
1.把交互的步骤成为一个用例,而不是把一类一系列步骤作为一个用例.例如,用户登陆是一个用例,错误的做法是把请求输入用户名也作为一个用例.
2.把必要的处理过程中的一些系统内部活动称作用例:验证用户,连接数据库,发送SQL请求等称作一个用例,其实都是用户登陆这一次交互的步骤而已.
3.把识别用例的工作当成是关系数据库分析的工作:称作四轮马车的错误,即CRUD(Create Read Update Delete).例如管理用户是一个用例,但是可能变成了增加用户,查询用户,修改用户,删除用户的"系统就是数据的增删改查"的认识论错误.

识别用例的一个关键性原则就是:站在用户的角度分析用户的目的,而不是站在系统的角度,更不是站在数据的角度.

通过建立的系统事件可以很顺利的画出用例图,但是应该记住"用例的本质是文字",所以我们最终要将用例图转化成用例文档.可以用下面的例子格式书写用例文档:
用例编号:
用例名:
用例描述:
参与者:
前置条件:开始该用例时的所必需的系统和环境状态
后置条件:结束该用例时的所具备的系统和环境状态
基本路径:
1…..××××
2……××××
3…..××××
扩展点:
2a.××××
2a1….×××××
补充说明:

前置条件和后置条件可以反应用例间的相互依赖关系.还可以防止漏掉某些用例


用例之间的关系:扩展extends,包含include,泛化



杨粼波 2006-08-23 19:02 发表评论
]]>Bug databaseshttp://www.cppblog.com/tx7do/archive/2006/08/14/11225.html杨粼波杨粼波Mon, 14 Aug 2006 10:03:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/14/11225.htmlhttp://www.cppblog.com/tx7do/comments/11225.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/14/11225.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11225.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11225.htmlBug databases (34 found)

Abuky

http://abuky.sunsite.dk/index.html

Description:

Abuky stands for the Aoo BUg tracKing sYstem, while AOO stands for Art Of Open Source. Abuky is a system for tracking bugs and aiding the developer to fix them, written in Java with JSP as web interface.

Requirement:

Linux, Windows, Solaris

Download data:

No data feed available


Anthill Bug Manager

http://anthillbm.sourceforge.net/

Description:

Anthill is a tool that aids code development by keeping track of bugs in a multi-project, multi-developer environment. It accomplishes this with a clean, simple, and fast interface that contains all the essential features but avoids the enormous complexity associated with most other projects of this type.

Requirement:

OS Independent

Download data:

Downloadable files: 1617 total downloads to date


BTsys

http://btsys.sourceforge.net/

Description:

BTsys is a lightweight desktop bug tracking system, written using C# and ADO.NET for small developer teams. Easy to install and learn how to use.

Requirement:

All 32-bit MS Windows (95/98/NT/2000/XP)

Download data:

Downloadable files: 0 total downloads to date


BugBye

http://bugbye.sourceforge.net/

Description:

BugBye is a web-based bugtracking system developed using ASP.NET technology and C# as scripting language. It offers all the features needed to manage improvement, bugs, and so on. It also provide statistics help-desk management, and further options which allow the user to simplify all the stage of project development and maintainance.

Requirement:

All 32-bit MS Windows (95/98/NT/2000/XP)

Download data:

Downloadable files: 3077 total downloads to date


Bugfree

http://bugfree.1zsoft.com/English.html

Description:

A lightweight and simple web-based bug tracking system available in Chinese and English.

Requirement:

Windows

Download data:

Downloadable files: 4312 total downloads to date


Buglog

http://buglogv2.sourceforge.net/

Description:

Allows you to easily record bugs into a database along with description and screenshots of the bugs (file upload feature). The BLT allows tracking of all bugs on a project-wise basis thus making it a bug logging and tracking solution. BuglogV2 incorporates a powerful search feature allowing developers to locate bugs effortlessly.

Requirement:

All 32-bit MS Windows (95/98/NT/2000/XP)

Download data:

Downloadable files: 3763 total downloads to date


BugNet

http://www.bugnetproject.com/

Description:

A web based bug / issue tracking application programmed in C# and asp.net. The main goals are to keep the codebase simple, well documented, easy to deploy and scalable. Major features include: Generic DAL / XHTML and CSS layout.

Requirement:

All 32-bit MS Windows (95/98/NT/2000/XP)

Download data:

Downloadable files: 4859 total downloads to date


BugRat

http://www.gjt.org/pkg/bugrat/

Description:

BugRat is free Java software that provides a sophisticated, flexible bug reporting and tracking system.

Requirement:

TBC

Download data:

No data feed available


Bugs Online

http://bugsonline.sourceforge.net/

Description:

Bugs Online was originally developed in 1997 to serve as the primary bug and issue tracking system to be utilized during a large development oriented project. The Bugs Online system is a very flexible and capable system for bug and issue tracking.

Requirement:

Windows NT 4.0 SP3+, MS IIS 3 w/ ASP

Download data:

Downloadable files: 20254 total downloads to date


Bugtrack

http://sourceforge.net/projects/btrack

Description:

Web based bug tracking system written in Perl/DBI. Supports multiple users, projects, components, versions and email notification.

Requirement:

Linux, Solaris, Windows

Download data:

Downloadable files: 3361 total downloads to date


BugTracker.NET

http://btnet.sourceforge.net/bugtrackernet.html

Description:

BugTracker.NET is a free, web-based bug or issue tracker written using ASP.NET, C#, and Microsoft SQL Server/MSDE. It is in daily use by hundreds (maybe thousands) of development and support teams around the world.

Requirement:

All 32-bit MS Windows (95/98/NT/2000/XP)

Download data:

Downloadable files: 71096 total downloads to date


Bugzilla

http://www.mozilla.org/projects/bugzilla/

Description:

Bugzilla has matured immensely, and now boasts many advanced features. These include: integrated, product-based granular security schema, inter-bug dependencies and dependency graphing, advanced reporting capabilities, a robust, stable RDBMS back-end, extensive configurability, a very well-understood and well-thought-out natural bug resolution protocol, email, XML, console, and HTTP APIs, available integration with automated software configuration management systems, including Perforce and CVS (through the Bugzilla email interface and checkin/checkout scripts), too many more features to list

Requirement:

TBC

Download data:

No data feed available


CodeTrack

http://kennwhite.sourceforge.net/codetrack/

Description:

Bug database with a friendly web front end aimed at medium and small development shops. Particularly suited for intranet and extranet environments, CodeTrack includes built-in strong authentication, and allows custom access control to individual projects. No database is required as bug data and developer notes are stored using simple XML text files.

Requirement:

Apache and PHP

Download data:

Downloadable files: 5723 total downloads to date


Debian bug tracking software

http://www.chiark.greenend.org.uk/~ian/debbugs/

Description:

The Debian bug tracking system is a set of scripts which maintain a database of problem reports.

Requirement:

Unix

Download data:

No data feed available


Eventum

http://eventum.mysql.org/wiki/index.php/Main_Page

Description:

Eventum is a user-friendly and flexible issue tracking system that can be used by a support department to track incoming technical support requests, or by a software development team to quickly organize tasks and bugs.

Requirement:

PHP, MySQL

Download data:

No data feed available


Flyspray

http://flyspray.rocks.cc/

Description:

Originally developed for the Psi project, Flyspray is an easy to use bug tracking system for those who do not require all the complexities of something like Bugzilla. It supports multiple users, file attachments, and Jabber notifications.

Requirement:

Web Environment

Download data:

No data feed available


GNATS

http://www.gnu.org/software/gnats/

Description:

GNATS is a portable incident/bug report/help request-tracking system which runs on UNIX-like operating systems. It easily handles thousands of problem reports, has been in wide use since the early 90s, and can do most of its operations over e-mail. Several front end interfaces exist, including command line, emacs, and Tcl/Tk interfaces. There are also a number of Web (CGI) interfaces written in scripting languages like Perl and Python.

Requirement:

OS Independent

Download data:

No data feed available


Helis

http://linux.softpedia.com/get/Programming/Bug-Tracking/Helis-962.shtml

Description:

Helis includes the main features of most bug tracking systems.

Requirement:

Linux web server (php 4/mysql + cgi)

Download data:

No data feed available


Issue Tracker Product

http://www.issuetrackerproduct.com/

Description:

A straight forward and user friendly web application built on top of the Zope application server.

Requirement:

OS Independent, Zope

Download data:

Downloadable files: 797 total downloads to date


JIRA

http://www.atlassian.com/software/jira/

Description:

JIRA is an issue tracking and project management application developed to make this process easier for your team. JIRA has been designed with a focus on task achievement, is instantly usable and is flexible to work with. Free to academic and open source projects, commercial licenses come with the complete source code.

Requirement:

JDK

Download data:

No data feed available


JitterBug

http://samba.anu.edu.au/cgi-bin/jitterbug

Description:

JitterBug is a web based bug tracking system. JitterBug operates by receiving bug reports via email or a web form. Authenticated users can then reply to the message, move it between different categories or add notes to it. In some ways JitterBug is like a communal web based email system. This web page is itself a JitterBug page.

Requirement:

TBC

Download data:

Downloadable files: 0 total downloads to date


JTrac

http://jtrac.info

Description:

Trac is a generic issue-tracking web-application that can be easily customized by adding custom fields and drop-downs. Features include customizable workflow, field level permissions, e-mail integration, file attachments and a detailed history view.

Requirement:

OS Independent

Download data:

Downloadable files: 2323 total downloads to date


Mantis

http://mantisbt.sourceforge.net/

Description:

Mantis is a php/MySQL/web based bugtracking system.

Requirement:

Windows, MacOS, OS/2, and a variety of Unix operating systems. Any web browser should be able to function as a clientWindows, MacOS, OS/2, and a

Download data:

Downloadable files: 276848 total downloads to date


Open Track

http://www.tumblin.com/aws/opentrack.html

Description:

OpenTrack is a problem tracking(PR) system that is table driven and easily configurable/customizable for a variety of PR applications. Project defect tracking, help desk tracking, and requirements gathering can be easily handled by OpenTrack.

Requirement:

TBC

Download data:

No data feed available


PEST

http://sourceforge.net/projects/pest/

Description:

PEST is a bug tracking system written especially for a web enviroment. It supports good testing and bug tracking processes, as well as notification.

Requirement:

TBC

Download data:

Downloadable files: 1881 total downloads to date


phpBugTracker

http://phpbt.sourceforge.net/

Description:

phpBugTracker is an attempt to copy the functionality of Bugzilla while providing a codebase that is independent of the database and presentation layers.

Requirement:

webserver with PHP 4.1.0+

Download data:

Downloadable files: 54426 total downloads to date


Request Tracker

http://www.bestpractical.com/rt/index.html

Description:

RT is an industrial-grade ticketing system. It lets a group of people intelligently and efficiently manage requests submitted by a community of users. RT is used by systems administrators, customer support staffs, NOCs, developers and even marketing departments at over a thousand sites around the world.

Requirement:

Written in object-oriented Perl, RT is a high-level, portable, platform independent system

Download data:

No data feed available


Roundup Issue Tracker

http://roundup.sourceforge.net/

Description:

Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition.

Requirement:

TBC

Download data:

Downloadable files: 33852 total downloads to date


Scarab

http://scarab.tigris.org/

Description:

The goal of the Scarab project is to build an Issue / Defect tracking system that has the following features: A full feature set similar to those found in other Issue / Defect tracking systems: data entry, queries, reports, notifications to interested parties, collaborative accumulation of comments, dependency tracking In addition to the standard features, Scarab has fully customizable and unlimited numbers of Modules (your various projects), Issue types (Defect, Enhancement, etc), Attributes (Operating System, Status, Priority, etc), Attribute options (P1, P2, P3) which can all be defined on a per Module basis so that each of your modules is configured for your specific tracking requirements. Built using Java Servlet technology for speed, scalability, maintainability, and ease of installation. Import/Export ability via XML allowing for easy migration from other systems (like Bugzilla). Modular code design that allows manageable modifications of existing and new features over time. Fully customizable through a set of administrative pages. Easily modified UI look and feel. Can be integrated into larger systems by re-implementing key interfaces.

Requirement:

TBC

Download data:

No data feed available


Stabilizer

http://stabilizer.sf.net

Description:

The Stabilizer bug tracking system aims to quickly stabilize buggy GUI applications so that people can get real work done with them. Users collaboratively and quickly stabilize a buggy GUI application simply by using the application normally and reporting any bugs that they encounter. As soon as a few people report the same bug, warnings will be issued to all users whenever they are about to trigger that bug and they will be given the opportunity to abort the input event -- thus avoiding the bug altogether and keeping the application stable.

Requirement:

All POSIX (Linux/BSD/UNIX-like OSes), Linux

Download data:

No data feed available


Trac

http://projects.edgewall.com/trac/

Description:

Trac is an enhanced wiki and issue tracking system for software development projects. Trac allows wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all project events in order, making getting an overview of the project and tracking progress very easy.

Requirement:

Python, CGI-capable web server

Download data:

No data feed available


Track+

http://www.trackplus.com

Description:

Track+ is a web based issue tracking and project management application targeted at medium to large commercial development projects. Track+ can be used instantly, yet it is flexible and configurable. Track+ is easy to use, provides user centric as well as project centric views, has configurable workflows, supports e-mail submission of issues, and has a comprehensive time and cost tracking module. Track+ is free to academic institutions, open source projects, and charities, and generally free to anybody up to 10 active users in the database. Track+ comes with the complete source code.

Requirement:

OS Independent (Written in an interpreted language)

Download data:

Downloadable files: 79969 total downloads to date


TrackIt

http://trackit.sourceforge.net/

Description:

TrackIt is a Web-based project tracking tool that incorporates defect tracking functionality. It is designed from the ground up to provide maximum flexibility, customization, and most importantly, usefulness to the developer. It has built-in support for various Extreme Programming constructs, as well as full CVS and Subversion integration. It also supports simple listings via HQL and advanced reporting via SQL.

Requirement:

JRE 1.5

Download data:

Downloadable files: 9588 total downloads to date


WREQ

http://www.math.duke.edu/~yu/wreq/

Description:

Wreq is designed to be a distributed request/problem tracking system with builtin knowledge database to help systems personnel to stay on top of requests and to prompt knowledge sharing among all local support groups.

Requirement:

To use wreq, first you must have perl version 5 with GDBM support installed on your web server.

Download data:

No data feed available


For those projects hosted on SourceForge, the project activity data is updated weekly using live newsfeeds powered by CaRP




杨粼波 2006-08-14 18:03 发表评论
]]>Performance test tools http://www.cppblog.com/tx7do/archive/2006/08/14/11224.html杨粼波杨粼波Mon, 14 Aug 2006 10:02:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/14/11224.htmlhttp://www.cppblog.com/tx7do/comments/11224.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/14/11224.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11224.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11224.htmlPerformance test tools (25 found)

Apache JMeter

http://jakarta.apache.org/jmeter/

Description:

Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.

Requirement:

Solaris, Linux, Windows (98, NT, 2000). JDK1.4 (or higher).

Download data:

No data feed available


Database Opensource Test Suite

http://ltp.sourceforge.net/

Description:

The Database Opensource Test Suite (DOTS) is a set of test cases designed for the purpose of stress-testing database server systems in order to measure database server performance and reliability.

Requirement:

Linux, POSIX

Download data:

Downloadable files: 55872 total downloads to date


DBMonster

http://sourceforge.net/projects/dbmonster/

Description:

DBMonster is an application to generate random data for testing SQL database driven applications under heavy load.

Requirement:

OS Independent

Download data:

Downloadable files: 7958 total downloads to date


Deluge

http://deluge.sourceforge.net/

Description:

An open-source web site stress test tool. Simulates multiple user types and counts. Includes proxy server for recording playback scripts, and log evaluator for generating result statistics. Note: this tool is no longer under active development although it is still available on Sourceforge.

Requirement:

OS independent

Download data:

Downloadable files: 7097 total downloads to date


Dieseltest

http://sourceforge.net/projects/dieseltest/

Description:

Contains the high-end features common to packages costing $50,000 or more. Dieseltest is a Windows application that simulates hundreds or thousands of users hitting a website. To run a load test, you first create a test script using our script editor. The script contains all of the requests that a real-world user would make of a website. You then load the script and run the test. The system will show you real-time results while the script is running, and produce a report analyzing the results at the conclusion.

Requirement:

Windows

Download data:

Downloadable files: 6015 total downloads to date


FunkLoad

http://funkload.nuxeo.org/

Description:

FunkLoad is a functional and load web tester, written in Python, whose main use cases are functional and regression testing of web projects, performance testing by loading the web application and monitoring your servers, load testing to expose bugs that do not surface in cursory testing, and stress testing to overwhelm the web application resources and test the application recoverability, and writing web agents by scripting any web repetitive task, like checking if a site is alive.

Requirement:

OS independent - except for the monitoring which is Linux specific.

Download data:

No data feed available


Grinder

http://grinder.sourceforge.net/

Description:

The Grinder is a Java load-testing framework making it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application.

Requirement:

OS Independent

Download data:

Downloadable files: 102533 total downloads to date


Hammerhead 2 - Web Testing Tool

http://hammerhead.sourceforge.net/

Description:

Hammerhead 2 is a stress testing tool designed to test out your web server and web site. It can initiate multiple connections from IP aliases and simulated numerous (256+) users at any given time. The rate at which Hammerhead 2 attempts to pound your site is fully configurable, there are numerous other options for trying to create problems with a web site (so you can fix them).

Requirement:

Hammerhead has been used with Linux, Solaris and FreeBSD.

Download data:

Downloadable files: 19860 total downloads to date


httperf

http://www.hpl.hp.com/research/linux/httperf/

Description:

Httperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro and macro level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility.

Requirement:

linux (Debian package available), HP-UX, perhaps other Unix

Download data:

No data feed available


http_load

http://www.acme.com/software/http_load/

Description:

http_load runs multiple HTTP fetches in parallel, to test the throughput of a Web server. However, unlike most such test clients, it runs in a single process, to avoid bogging the client machine down. It can also be configured to do HTTPS fetches.

Requirement:

tbc

Download data:

No data feed available


JCrawler

http://jcrawler.sourceforge.net/

Description:

Stress-Testing Tool for web-applications. It comes with the crawling/exploratory feature. You can give JCrawler a set of starting URLs and it will begin crawling from that point onwards, going through any URLs it can find on its way and generating load on the web application. The load parameters (hits/sec) are configurable.

Requirement:

OS Independent

Download data:

Downloadable files: 4291 total downloads to date


NTime

http://www.codeproject.com/dotnet/ntime.asp

Description:

The NTime tool is very similar to NUnit tool to perform repeatable tasks that help managers, architects, developers and testers to test an application against its performance.

Requirement:

Windows 98 or above, .Net framework 1.1 or 2.0

Download data:

No data feed available


OpenSTA

http://OpenSTA.org/

Description:

A distributed software testing architecture based on CORBA. Using OpenSTA (Open System Testing Architecture) a user can generate realistic heavy loads simulating the activity of hundreds to thousands of virtual users. OpenSTA graphs both virtual user response times and resource utilization information from all Web Servers, Application Servers, Database Servers and Operating Platforms under test, so that precise performance measurements can be gathered during load tests and analysis on these measurements can be performed.

Requirement:

Windows 2000, NT4 and XP

Download data:

Downloadable files: 164360 total downloads to date


OpenWebLoad

http://openwebload.sourceforge.net/

Description:

OpenLoad is a tool for load testing web applications. It aims to be easy to use and providing near real-time performance measurements of the application under test.

Requirement:

Linux, DOS

Download data:

Downloadable files: 25841 total downloads to date


Seagull

http://gull.sourceforge.net/

Description:

Seagull is a multi-protocol traffic generator test tool. Primary aimed at IMS protocols, Seagull is a powerful traffic generator for functional, load, endurance, stress and performance tests for almost any kind of protocol. Currently supports Diameter, XCAP over HTTP, TCAP (GSM Camel, MAP, Win) protocols.

Requirement:

Linux/Unix/Win32-Cygwin

Download data:

Downloadable files: 712 total downloads to date


Siege

http://www.joedog.org/

Description:

SIEGE is an http regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. It lets the user hit a webserver with a configurable number of concurrent simulated users. Those users place the webserver "under siege." SCOUT surveys a webserver and prepares the urls.txt file for a siege. In order to perform regression testing, siege loads URLs from a file and runs through them sequentially or randomly. Scout makes the process of populating that file easier. You should send out the scout, before you lay siege.

Requirement:

GNU/Linux, AIX, BSD, HP-UX and Solaris.

Download data:

Downloadable files: 554 total downloads to date


Sipp

http://sipp.sourceforge.net/

Description:

SIPp is a performance testing tool for the SIP protocol. Its main features are basic SIPStone scenarios, TCP/UDP transport, customizable (xml based) scenarios, dynamic adjustement of call-rate and a comprehensive set of real-time statistics. It can also generate media (RTP) traffic for audio and video calls.

Requirement:

Linux/Unix/Win32-Cygwin

Download data:

Downloadable files: 41919 total downloads to date


SLAMD

http://www.slamd.com/

Description:

SLAMD Distributed Load Generation Engine is a Java-based application designed for stress testing and performance analysis of network-based applications.

Requirement:

Any system with Java 1.4 or higher

Download data:

No data feed available


Soap-Stone

http://soap-stone.sourceforge.net/

Description:

Network benchmark application which can put your network under load and conduct automatic benchmark and recording activities.

Requirement:

OS Independent

Download data:

Downloadable files: 1482 total downloads to date


stress_driver

http://sourceforge.net/projects/stress-driver/

Description:

General-purpose stress test tool.

Requirement:

Windows NT/2000, Linux

Download data:

Downloadable files: 3034 total downloads to date


TestMaker

http://www.pushtotest.com/ptt/

Description:

TestMaker from PushToTest.com delivers a rich environment for building and running intelligent test agents that test Web-enabled applications for scalability, functionality, and performance. It comes with a friendly graphical user environment, an object-oriented scripting language (Jython) to build intelligent test agents, an extensible library of protocol handlers (HTTP, HTTPS, SOAP, XML-RPC, SMTP, POP3, IMAP), a new agent wizard featuring an Agent Recorder to write scripts for you, a library of fully-functional sample test agents, and shell scripts to run test agents from the command line and from unit test utilities.

Requirement:

Java 1.4 or higher virtual machine on Windows, Linux, Solaris, and Macintosh.

Download data:

No data feed available


TPTEST

http://tptest.sourceforge.net/about.php

Description:

The purpose with TPTEST is to allow users to measure the speed of their Internet connection in a simple way. TPTEST measures the throughput speed to and from various reference servers on the Internet. The use of TPTEST may help increase the consumer/end user knowledge of how Internet services work.

Requirement:

MacOS/Carbon and Win32

Download data:

Downloadable files: 66442 total downloads to date


Tsung

http://tsung.erlang-projects.org/

Description:

Tsung is a distributed load testing tool. It is protocol-independent and can currently be used to stress HTTP, SOAP and Jabber servers (SSL is supported). It simulates complex user's behaviour using an XML description file, reports many measurements in real time (including response times, CPU and memory usage from servers, customized transactions, etc.). HTML reports (with graphics) can be generated during the load. For HTTP, it supports 1.0 and 1.1, has a proxy mode to record sessions, supports GET and POST methods, Cookies, and Basic WWW-authentication. It has already been used to simulate thousands of virtual users.

Requirement:

Tested on Linux, but should work on MacOSX and Windows.

Download data:

No data feed available


Web Application Load Simulator

http://jobmanager.sourceforge.net/openware_pub/

Description:

LoadSim is a web application load simulator. It allows you to create simulations and have those simulations run against your webserver.

Requirement:

JDK 1.3 or above

Download data:

Downloadable files: 7971 total downloads to date


Web Polygraph

http://www.web-polygraph.org/

Description:

Benchmarking tool for caching proxies, origin server accelerators, L4/7 switches, content filters, and other Web intermediaries.

Requirement:

C++ compiler

Download data:

No data feed available


For those projects hosted on SourceForge, the project activity data is updated weekly using live newsfeeds powered by CaRP




杨粼波 2006-08-14 18:02 发表评论
]]>C++单元测试工具列表http://www.cppblog.com/tx7do/archive/2006/08/14/11223.html杨粼波杨粼波Mon, 14 Aug 2006 10:00:00 GMThttp://www.cppblog.com/tx7do/archive/2006/08/14/11223.htmlhttp://www.cppblog.com/tx7do/comments/11223.htmlhttp://www.cppblog.com/tx7do/archive/2006/08/14/11223.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/11223.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/11223.htmlC/C++ unit testing tools (18 found)

Boost

http://www.boost.org/libs/test/doc/index.html

Description:

The Boost Test Library provides a matched set of components for writing test programs, organizing tests in to simple test cases and test suites, and controlling their runtime execution.

Requirement:

Download data:

No data feed available


C Unit Test System

http://sourceforge.net/projects/cut/

Description:

CUT is a simple, to-the-point unit testing system. It's different from other unit test packages in that it follows the KISS principle. It's designed for C testing, not designed to emulate SUnit.

Requirement:

OS Independent

Download data:

Downloadable files: 4744 total downloads to date


Check

http://check.sourceforge.net/

Description:

Check is a unit test framework for C. It features a simple interface for defining unit tests, putting little in the way of the developer. Tests are run in a separate address space, so Check can catch both assertion failures and code errors that cause segmentation faults or other signals. The output from unit tests can be used within source code editors and IDEs.

Requirement:

POSIX

Download data:

Downloadable files: 17934 total downloads to date


CppTest

http://cpptest.sourceforge.net/

Description:

CppTest is a portable and powerful, yet simple, unit testing framework for handling automated tests in C++. The focus lies on usability and extendability. Several output formats are supported and new ones are easily added.

Requirement:

OS Independent

Download data:

Downloadable files: 4445 total downloads to date


CppUnit

http://cppunit.sourceforge.net/

Description:

CppUnit is the C++ port of the famous JUnit framework for unit testing. Test output is in XML or text format for automatic testing and GUI based for supervised tests.

Requirement:

BeOS, MacOS, Windows, OS Independent, Linux

Download data:

Downloadable files: 293875 total downloads to date


cutee

http://codesink.org/cutee_unit_testing.html

Description:

C++ unit testing environment that makes it really easy to create and run tests of a library or application. It will automatically generate Makefiles, runner classes (classes that execute test functions), and main test application code. It will also automatically update Makefiles and support classes whenever you add new test functions or modify old ones.

Requirement:

UNIX

Download data:

Downloadable files: 9 total downloads to date


CUTest

http://cutest.sourceforge.net/

Description:

CuTest is a unit testing library for the C language.

Requirement:

Download data:

Downloadable files: 9356 total downloads to date


CxxTest

http://cxxtest.sourceforge.net/

Description:

CxxTest is a JUnit/CppUnit/xUnit-like framework for C++. Its advantages over existing alternatives are that it doesn't require RTTI, doesn't require member template functions, doesn't require exception handling, doesn't require any external libraries (including memory management, file/console I/O, graphics libraries) and is distributed entirely as a set of header files. This makes it extremely portable and usable.

Requirement:

OS Independent (Written in an interpreted language)

Download data:

Downloadable files: 26641 total downloads to date


Embedded Unit

https://sourceforge.net/projects/embunit/

Description:

Unit testing framework for Embedded C System. Its design was copied from JUnit and CUnit and more, and then adapted somewhat for Embedded C System.

Requirement:

OS Independent

Download data:

Downloadable files: 3933 total downloads to date


GUNit

http://kooditakomo.cs.tut.fi/projects/gunit/

Description:

GUNit is a C unit testing framework in the spirit of JUnit. The framework incorporates an easy to use GUI based on the Gnome libraries.

Requirement:

Linux

Download data:

No data feed available


ObjcUnit

http://oops.se/objcunit/

Description:

ObjcUnit is a unit testing framework for Objective-C on Mac OS X. Its design was copied from JUnit, written by Erich Gamma and Kent Beck, and then adapted somewhat for Objective-C. It also has support for mock objects, adapted from the Java Mock Objects framework.

Requirement:

Mac OS X

Download data:

No data feed available


OCUnit

http://www.sente.ch/software/ocunit/

Description:

OCUnit is a testing framework for Objective C in the Mac OS X, GNUSTEP and other environments. It is based on the original SUnit framework of Kent Beck, but also include a JUnit like API. Test suites are automatically created at runtime. On Mac OS X it provides full integration with the XCode IDE: tests can be run after each compilation and failures and errors are reported in the build panel.

Requirement:

Mac OS X, GNUstep, OPENSTEP or WebObjects 4

Download data:

No data feed available


QtUnit

http://www.uwyn.com/projects/qtunit/

Description:

QtUnit is a unit testing framework for C++ which compiles into a shared library. It uses the Qt library for platform independence. Tests can be compiled into modules which are automatically reloaded after modification. The text and graphical testrunners are fully localized and integrate perfectly into IDEs for the display of the exact source location where failures occurred.

Requirement:

Qt 3.0

Download data:

No data feed available


simplectest

http://simplectest.sourceforge.net/index.php

Description:

Aims to be a simple but effective testing framework for C and C++ projects, without having too much overhead.

Requirement:

Cygwin (MS Windows), OS Portable

Download data:

Downloadable files: 685 total downloads to date


Splint

http://www.splint.org/

Description:

Splint is a tool for statically checking C programs for coding errors and security vulnerabilities. If effort is invested adding annotations to programs, Splint can perform stronger checking than is possible with traditional lints.

Requirement:

Win32, Solaris, Linux, FreeBSD

Download data:

Downloadable files: 0 total downloads to date


TestKit

http://testkit.sourceforge.net

Description:

Testing framework for Mac OS X and the Objective-C language. Includes testing framework, developer tool integration, easy test organization and packaging, GUI Test Runner, and a command-line version for test automation. Modelled after JUnit, but targets the specific needs of the OS X developer in the Cocoa environment.

Requirement:

MacOS X

Download data:

Downloadable files: 1340 total downloads to date


TUT

http://tut-framework.sourceforge.net/

Description:

TUT simplifies tests organization and provides basic framework to run them. All developers have to do is to fill tests bodies with the actual test code.

Requirement:

C++

Download data:

No data feed available


UnitTest++

http://unittest-cpp.sourceforge.net/

Description:

UnitTest++ is a unit testing framework for C++ designed for simplicity and portability. Features include no explicit test registration, good crash handling, fixtures, rich condition-checking functionality, minimal footprint for embedded environments.

Requirement:

Win32, Linux, Mac OS X

Download data:

Downloadable files: 1490 total downloads to date


For those projects hosted on SourceForge, the project activity data is updated weekly using live newsfeeds powered by CaRP



杨粼波 2006-08-14 18:00 发表评论
]]>软件测试相关的６３个国外站点 http://www.cppblog.com/tx7do/archive/2006/07/27/10612.html杨粼波杨粼波Thu, 27 Jul 2006 14:21:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/27/10612.htmlhttp://www.cppblog.com/tx7do/comments/10612.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/27/10612.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10612.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10612.html软件测试相关的63个国外站点
网址          简介
http://bdonline.sqe.com/         一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
http://citeseer.nj.nec.com/        
一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考
网站
http://groups.yahoo.com/group/LoadRunner         性能测试工具LoadRunner的一个论坛
http://groups.yahoo.com/grorp/testing-paperannou-nce/messages        
提供网站上当前发布的软件测试资料列表
http://satc.gsfc.nasa.gov/homepage.html        
软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心，
研究包括了度量、工具、风险等各个方面
http://seg.iit.nrc.ca/English/index.html         加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载
http://sepo.nosc.mil         内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process
Office)主页，包括软件工程知识
方面的资料
http://www.asq.org/         是世界上最大的一个质量团体组织之一，有着比较丰富的论文资源，不过是收费的
http://www.automated-testing.com/         一个自动化软件测试和自然语言处理研究页面，属于个人网页，上面有些资源可供下载
http://www.benchmarkresources.com/         提供有关标杆方面的资料，也有一些其它软件测试方面的资料
http://www.betasoft.com/         包含一些流行测试工具的介绍、下载和讨论，还提供测试方面的资料
http://www.brunel.ac.uk/~csstmmh2/vast/home.html        
VASTT研究组织，主要从事通过切片技术、测试技术和转换技术来验证和分析
系统，对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
http://www.cc.gatech.edu/aristotle/        
Aristole研究组织，研究软件系统分析、测试和维护等方面的技术，在测试方面的研究包括
了回归测试、测试套最小化、面向对象软件测试等内容，该网站有丰富的论文资源可供下载
http://www.computer.org/        
IEEE是世界上最悠久，也是在最大的计算机社会团体，它的电子图书馆拥有众多计算机方面的论文资料，
是研究计算机方面的一个重要资源参考来源
http://www.cs.colostate.edu/testing/         可靠性研究网站，有一些可靠性方面的论文资料
http://www.cs.york.ac.uk/testsig/        
约克大学的测试专业兴趣研究组网页，有比较丰富的资料下载，内容涵盖了测试的多个方面，
包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
http://www.csr.ncl.ac.uk/index.html        
学校里面的一个软件可靠性研究中心，提供有关软件可靠性研究方面的一些信息和资料，对
这方面感兴趣的人可以参考
http://www.dcs.shef.ac.uk/research/groups/vt/        
学校里的一个验证和测试研究机构，有一些相关项目和论文可供参考
http://www.esi.es/en/main/         ESI（欧洲软件组织），提供包括CMM评估方面的各种服务
http://www.europeindia.org/cd02/index.htm         一个可靠性研究网站，有可靠性方面的一些资料提供参考
http://www.fortest.org.uk/         一个测试研究网站，研究包括了静态测试技术（如模型检查、理论证明）和动态测试（如测试自动化、
特定缺陷的检查、测试有效性分析等）
http://www.grove.co.uk/         一个有关软件测试和咨询机构的网站，有一些测试方面的课程和资料供下载
http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm         NASA可靠性设计实践资料
http://www.io.com/~wazmo/         Bret
Pettichord的主页，他的一个热点测试页面连接非常有价值，从中可以获得相当大的测试资料，很
有价值
http://www.iso.ch/iso/en/ISOOnline.frontpage        
国际标准化组织，提供包括ISO标准系统方面的各类参考资料
http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html        
提供面向对象和基于构架的测试方面著作下载，对这方
面感兴趣的读者可以参考该网站，肯定有价值
http://www.ivv.nasa.gov/        
NASA设立的独立验证和确认机构，该机构提出了软件开发的全面验证和确认，在此可以获得这方面的研究
资料
http://www.kaner.com/         著名的测试专家Cem Kanner的主页，里面有许多关于测试的专题文章，相信对大家都有用。Cem
Kanner关于
测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 
       卡耐基梅陇大学网上图书馆，在这里你可
以获得有关计算机方面各类论文资料，内容极其庞大，是研究软件测试不可获取的资料来源之一
http://www.loadtester.com/         一个性能测试方面的网站，提供有关性能测试、性能监控等方面的资源，包括论文、论坛以及一些相关
链接
http://www.mareinig.ch/mt/index.html        
关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载，包括了测
试方面的内容
http://www.mtsu.ceu/-storm/         软件测试在线资源，包括提供目前有哪些人在研究测试，测试工具列表连接，测试会议，测试新闻和
讨论，软件测试文学（包括各种测试杂志，测试报告），各种测试研究组织等内容
http://www.psqtcomference.com/         实用软件质量技术和实用软件测试技术国际学术会议宣传网站，每年都会举行两次
http://www.qacity.com/front.htm         测试工程师资源网站，包含各种测试技术及相关资料下载
http://www.qaforums.com/         关于软件质量保证方面的一个论坛，需要注册
http://www.qaiusa.com/         QAI是一个提供质量保证方面咨询的国际著名机构，提供各种质量和测试方面证书认证
http://www.qualitytree.com/         一个测试咨询提供商，有一些测试可供下载，有几篇关于缺陷管理方面的文章值得参考
http://www.rational.com/         IBM Rational的官方网站，可以在这里寻找测试方面的工具信息。IBM
Rational提供测试方面一系列的工
具，比较全面
http://rexblackconsulting.com/Pages/publicat-ions.htm
        Rex Black的个人主页，有一些测试和测试管理方面的资料可供下载
http://www.riceconsulting.com/         一个测试咨询提供商，有一些测试资料可供下载，但不多
http://www.satisfice.com/         包含James Bach关于软件测试和过程方面的很多论文，尤其在启发式测试策略方面值得参考
http://www.satisfice.com/seminars.shtml         一个黑盒软件测试方面的研讨会，主要由测试专家Cem
Kanar和James Bach组织，有一些
值得下载的资料
http://www.sdmagazine.com/         软件开发杂志，经常会有一些关于测试方面好的论文资料，同时还包括了项目和过程改进方面的课题，
并且定期会有一些关于质量和测试方面的问题讨论
http://www.sei.cmu.edu/         著名的软件工程组织，承担美国国防部众多软件工程研究项目，在这里你可以获俄各类关于工程质量和测
试方面的资料。该网站提供强有力的搜索功能，可以快速检索到你想要的论文资料，并且可以免费下载
http://www.soft.com/Institute/HotList/        
提供了网上软件质量热点连接，包括：专业团体组织连接、教育机构连接、商业咨询公司
连接、质量相关技术会议连接、各类测试技术专题连接等
http://www.soft.com/News/QTN-Online/        
质量技术时事，提供有关测试质量方面的一些时事介绍信息，对于关心测试和质量发展的人
士来说是很有价值的
http://www.softwaredioxide.com/         包括软件工程（CMM,CMMI,项目管理）软件测试等方面的资源
http://www.softwareqatest.com/        
软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料，各质量/测试网站介绍，
各质量/测试工具介绍，各质量/策划书籍介绍以及与测试相关的工作网站介绍
http://www.softwaretestinginstitute.com        
一个软件测试机构，提供软件质量/测试方面的调查分析，测试计划模板，测试WWW的技
术，如何获得测试证书的指导，测试方面书籍介绍，并且提供了一个测试论坛
http://www.sqatester.com/index.htm        
一个包含各种测试和质量保证方面的技术网站，提供咨询和培训服务，并有一些测试人员社团
组织，特色内容是缺陷处理方面的技术
http://www.sqe.com/        
一个软件质量工程服务性网站，组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议，并提供一
些相关信息资料和课程服务
http://www.stickyminds.com/         提供关于软件测试和质量保证方面的当前发展信息资料，论文等资源
http://www.stqemagazine.com/        
软件策划和质量工程杂志，经常有一些好的论文供下载，不过数量较少，更多地需要通过订购获得，
内容还是很有价值的
http://www.tantara.ab.ca/         软件质量方面的一个咨询网站，有过程改进方面的一些资料提供
http://www.tcse.org/         IEEE的一个软件工程技术委员会，提供技术论文下载，并有一个功能强大的分类下载搜索功能，可以搜索到测
试类型、测试管理、 测试分析等各方面资料
http://www.testing.com/         测试技术专家Brain Marick的主页，包含了Marick
研究的一些资料和论文，该网页提供了测试模式方面的
资料，值得研究。总之，如果对测试实践感兴趣，该网站一定不能错过
http://www.testingcenter.com/         有一些测试方面的课程体系，有一些价值
http://www.testingconferences.com/asiastar/home        
著名的AsiaStar测试国际学术会议官方网站，感兴趣的人一定不能错



杨粼波 2006-07-27 22:21 发表评论
]]>微软的软件测试方法（二）http://www.cppblog.com/tx7do/archive/2006/07/27/10611.html杨粼波杨粼波Thu, 27 Jul 2006 13:33:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/27/10611.htmlhttp://www.cppblog.com/tx7do/comments/10611.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/27/10611.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10611.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10611.html微软的软件测试方法（二）
我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法，其基本思想大家应该是比较熟悉的，因为它们还只是传统的软件测试方法的综合。所以单从形式上，它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时，你会对一些基本的事实感到惊讶。比如，“微软的测试人员和开发人员数量大致相等或略多”，“微软的产品成本中测试大约占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年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。





开发对测试的依赖





现代软件开发，特别是大型软件开发通常会遇到以下两个问题：



（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的搜寻；在具体方法上，自动测试和测试工具的使用已成为基本的要求。在微软，测试不仅使用一些通用的工具，每一个产品还有专门开发的专用工具库，测试的代码量常常超过项目本身的代码量。



一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。

杨粼波 2006-07-27 21:33 发表评论
]]>微软的软件测试方法http://www.cppblog.com/tx7do/archive/2006/07/27/10610.html杨粼波杨粼波Thu, 27 Jul 2006 13:32:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/27/10610.htmlhttp://www.cppblog.com/tx7do/comments/10610.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/27/10610.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10610.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10610.html微软的软件测试方法
国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。

作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考，更有利于发现问题的根源。即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。

微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。



两类经典的软件测试方法



在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。

传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。

提出第一类方法的代表人物是软件测试领域的先驱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客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（在微软这是常事），所涉及的测试用例当然也要相应地修改。



微软的第二类测试



微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“Bug Bash（Bug大扫除）”。

Bug Bash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。一般会邀请公司内部，或业界的专家来搜寻产品的安全漏洞。



以上我从传统软件测试概念的角度，介绍了微软的策略和两类传统测试方法的具体做法，及其侧重点。这其实仅仅是一个基础，一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的，也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法，和概念上的突破，比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍。

杨粼波 2006-07-27 21:32 发表评论
]]>常见测试术语http://www.cppblog.com/tx7do/archive/2006/07/27/10609.html杨粼波杨粼波Thu, 27 Jul 2006 13:26:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/27/10609.htmlhttp://www.cppblog.com/tx7do/comments/10609.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/27/10609.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10609.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10609.htmlSLA －－服务级别协议（ service level agreement ）
服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

Smoke Testing －－冒烟测试         
对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

software development process －－软件开发过程         
一个把用户需求转换为软件产品的开发过程。

software diversity －－软件多样性         
一种软件开发技术，其中，由不同的程序员或开发组开发的相同规格的不同程序，目的是为了检测错误、增加可靠性。

software element －－软件元素         
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

software engineering －－软件工程         
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

software engineering environment －－软件工程环境         
执行一个软件工程工作的硬件、软件和固件。

software life cycle －－软件生命周期         
开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

SOP －－标准操作过程（ standard operating procedures ）
书面的步骤，这对保证生产和处理的控制是必须的。

source code －－源代码         
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

source statement －－源语句         
参考语句（ statement ）

第 132 贴【 2004 － 11 － 2 】：常见测试术语十四

specification －－规格         
组件功能的一个描述，格式是：对指定的输入在指定的条件下的输出。

specified input －－指定的输入         
一个输入，根据规格能预知其输出。

spiral model        －－螺旋模型         
软件开发过程的一个模型，其中的组成活动，典型的包括需求分析，概要设计，详细设计，编码，集成和测试等活动被迭代的执行直到软件被完成。

SQL －－结构化查询语句（ structured query language ）
在一个关系数据库中查询和处理数据的一种语言。

state －－状态         
一个系统、组件或模拟可能存在其中的一个条件或模式。

state diagram －－状态图         
一个图形，描绘一个系统或组件可能假设的状态，并且显示引起或导致一个状态切换到另一个状态的事件或环境。

state transition －－状态转换         
一个系统或组件的两个允许状态之间的切换。

state transition testing        －－状态转换测试         
根据状态转换来设计测试用例的一种方法。

statement －－语句         
程序语言的一个实体，是典型的最小可执行单元。

statement coverage －－语句覆盖         
在一个组件中，通过执行一定的测试用例所能达到的语句覆盖百分比。

statement testing －－语句测试         
根据语句覆盖来设计测试用例的一种方法。

Static Analysis －－静态分析         
分析一个程序的执行，但是并不实际执行这个程序。

第 133 贴【 2004 － 11 － 3 】：常见测试术语十五

Static Analyzer －－静态分析器         
进行静态分析的工具。

Static Testing －－静态测试         
不通过执行来测试一个系统。

statistical testing －－统计测试         
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

stepwise refinement －－逐步优化         
一个结构化软件设计技术，数据和处理步骤首先被广泛的定义，然后被逐步的进行了细化。

storage testing －－存储测试         
验证系统是否满足指定存储目标的测试。

Stress Testing －－压力测试         
在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。类似负载测试，通常是性能测试的一部分。

structural coverage －－结构化覆盖         
根据组件内部的结构度量覆盖率。

structural test case design －－结构化测试用例设计         
根据组件内部结构的分析来设计测试用例的一种方法。

structural testing －－结构化测试         
参考结构化测试用例设计（ structural test case design ）

structured basis testing －－结构化的基础测试         
根据代码逻辑设计测试用例来获得 100 ％分支覆盖的一种测试用例设计技术。

structured design －－结构化设计         
软件设计的任何遵循一定纪律的方法，它按照特定的规则，例如：模块化，有顶向下设计，数据逐步优化，系统结构和处理步骤。

structured programming －－结构化编程         
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

structured walkthrough －－结构化走读         
参考走读（ walkthrough ）

第 134 贴【 2004 － 11 － 4 】：常见测试术语十六

stub －－桩         
一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

symbolic evaluation －－符号评价         
参考符号执行（ symbolic execution ）

symbolic execution －－符号执行         
通过符号表达式来执行程序路径的一种静态分析设计技术。其中，程序的执行被用符号来模拟，例如，使用变量名而不是实际值，程序的输出被表示成包含这些符号的逻辑或数学表达式。

symbolic trace －－符号轨迹         
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

syntax testing －－语法分析         
根据输入语法来验证一个系统或组件的测试用例设计技术。

system analysis －－系统分析         
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

system design －－系统设计         
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

system integration －－系统集成         
一个系统组件的渐增的连接和测试，直到一个完整的系统。

System Testing －－系统测试         
从一个系统的整体而不是个体上来测试一个系统，并且该测试关注的是规格，而不是系统内部的逻辑。

第 135 贴【 2004 － 11 － 7 】：常见测试术语十七

technical requirements testing －－技术需求测试         
参考非功能需求测试（ non-functional requirements testing ）

test automation －－测试自动化         
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

test case －－测试用例         
用于特定目标而开发的一组输入、预置条件和预期结果。

test case design technique －－测试用例设计技术         
选择和导出测试用例的技术。

test case suite －－测试用例套         
对被测软件的一个或多个测试用例的集合。

test comparator －－测试比较器         
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

test completion criterion －－测试完成标准         
一个标准用于确定被计划的测试何时完成。

test coverage －－测试覆盖         
参考覆盖率（ Coverage ）

test driver －－测试驱动         
一个程序或测试工具用于根据测试套执行软件。

test environment －－测试环境         
测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

第 136 贴【 2004 － 11 － 8 】：常见测试术语十八

test execution －－测试执行         
一个测试用例被被测软件执行，并得到一个结果。

test execution technique －－测试执行技术         
执行测试用例的技术，包括手工、自动化等。

test generator －－测试生成器         
根据特定的测试用例产生测试用例的工具。

test harness －－测试用具         
包含测试驱动和测试比较器的测试工具。

test log －－测试日志         
一个关于测试执行所有相关细节的时间记录。

test measurement technique －－测试度量技术         
度量测试覆盖率的技术。

Test Plan －－测试计划         
一个文档，描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务，并且任何风险都要冲突计划。

test procedure －－测试规程         
一个文档，提供详细的测试用例执行指令。

test records －－测试记录         
对每个测试，明确的记录被测组件的标识、版本，测试规格，和实际结果

test report －－测试报告         
一个描述系统或组件执行的测试和结果的文档。

Test Script －－测试脚本         
一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

Test Specification －－测试规格         
一个文档，用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

第 137 贴【 2004 － 11 － 9 】：常见测试术语十九

test strategy －－测试策略         
一个简单的高层文档，用于描述测试的大致方法，目标和方向。

test suite －－测试套         
测试用例和 / 或测试脚本的一个集合，与一个应用的特定功能或特性相关。

test target －－测试目标         
一组测试完成标准。

testability －－可测试性         
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

Testing －－测试         
IEEE 给出的定义是： 1 ）一个执行软件的过程，以验证其满足指定的需求并检测错误。 2 ）一个软件项的分析过程以检测已有条件之间的不同，并评价软件项的特性。

thread testing －－线程测试         
自顶向下测试的一个变化版本，其中，递增的组件集成遵循需求子集的实现。

time sharing －－时间共享         
一种操作方式，允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。

top-down design －－由顶向下设计         
一种设计策略，首先设计最高层的抽象和处理，然后逐步向更低级别进行设计。

top-down testing －－自顶向下测试         
集成测试的一种策略，首先测试最顶层的组件，其它组件使用桩，然后逐步加入较低层的组件进行测试，直到所有组件被集成到系统中。

traceability －－可跟踪性         
开发过程的两个或多个产品之间关系可以被建立起来的程度，尤其是产品彼此之间有一个前后处理关系。

traceability analysis －－跟踪性分析         
（ 1 ）跟踪概念文档中的软件需求到系统需求；（ 2 ）跟踪软件设计描述到软件需求规格，以及软件需求规格到软件设计描述；（ 3 ）跟踪源代码对应到设计规格，以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

traceability matrix －－跟踪矩阵         
一个用于记录两个或多个产品之间关系的矩阵。例如，需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

第 138 贴【 2004 － 11 － 10 】：常见测试术语二十

transaction －－事务 / 处理         
（ 1 ）一个命令、消息或输入记录，它明确或隐含的调用了一个处理活动，例如更新一个文件。（ 2 ）用户和系统之间的一次交互。（ 3 ）在一个数据库管理系统中，完成一个特定目的的处理单元，如恢复、更新、修改或删除一个或多个数据元素。

transform analysis －－事务分析         
系统的结构是根据分析系统需要处理的事务获得的一种分析技术。
trojan horse －－特洛伊木马         
一种攻击计算机系统的方法，典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户，在用户执行该程序的时候，其隐含的代码对系统进行非法访问，并可能产生破坏。

truth table －－真值表         
用于逻辑操作的一个操作表格。

Unit Testing －－单元测试         
测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。

Usability Testing －－可用性测试         
测试用户使用和学习产品的容易程度。

validation －－确认         
根据用户需要确认软件开发的产品的正确性。

verification －－验证         
评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

version －－版本         
一个软件项或软件元素的一个初始发布或一个完整的再发布。

volume testing －－容量测试         
使用大容量数据测试系统的一种策略。

Walkthrough －－走读         
一个针对需求、设计或代码的非正式的同行评审，一般由作者发起，由作者的同行参与进行的评审过程。

waterfall model －－瀑布模型         
软件开发过程模型的一种，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段，这些阶段按次序进行，可能有部分重叠，但很少会迭代。

White Box Testing －－白盒测试         
根据软件内部的工作原理分析来进行测试。

第 139 贴【 2004 － 11 － 11 】：测试是一个持续进行的过程，而不是一个阶段

在传统的瀑布式开发模型中定义了专门的测试阶段，如单元测试阶段，集成测试阶段或系统测试阶段。然而，这并不意味着测试只有在这个时候才进行。我遇到过很多项目，在这些项目中，对测试的理解都基于了阶段这个概念，在他们的思维中，测试只有在适当的时候才开始，并且在某个点就可以结束了。这是一个错误的理解，并且对产品的质量来说是很危险的。现代的测试已经发展成为一个全过程的验证和确认活动，它贯穿于整个开发生命周期的始末。为了获得最大的受益，测试的开发和准备必须在编码之前就应当开始，同时为了保证最终的质量，我们必须在开发过程的每个阶段保证其过程的质量。

第 140 贴【 2004 － 11 － 12 】：测试必须被计划、被控制，并且被提供时间和资源

测试并不是一个随机的活动，测试必须被计划，并且被安排足够的时间和资源。测试活动应当受到控制，测试的中间产物应当被评审并纳入配置管理。
      测试计划是一个关键的管理功能，它定义了各个级别的测试所使用的策略、方法、测试环境、测试通过或失败准则等内容。测试计划的目的是要为有组织的完成测试提供一个基础。从管理的角度来看，测试计划是最重要的文档，这是由于它帮助管理测试项目。如果一个测试计划是完整并且经过深思熟虑的，那么测试的执行和分析将平滑的进行。
      测试计划可以分级，也可以是一个总的计划，并且测试计划是一个不断演进的文档。如果不考虑应用软件的最初来源（复用的组件或已实现的组件），软件需求是测试活动的驱动。因此，测试计划应当关注于文档化的需求。此外，支持测试的过程应当被文档化下来以创建一个可重复的过程，该过程将保证开发工作产品的质量。
      一个好的测试计划应当：
1 、在检测主要缺陷方面有一个好的选择
2 、提供绝大部分代码的覆盖率
3 、是灵活的
4 、易于执行、回归和自动化
5 、定义要执行测试的种类
6 、清晰的文档化了期望的结果
7 、当缺陷被发现的时候，提供缺陷核对
8 、清晰的定义测试的目标
9 、明确测试的策略
10 、清晰定义测试的出口标准
11 、没有冗余
12 、确认风险
13 、文档化测试的需求
14 、定义可交付的测试件

第 141 贴【 2004 － 11 － 15 】：测试应该有重点

尽管我们的测试是需要按照一定的级别进行，但资源和时间是有限的，实际上我们不可能无休止的进行测试，因此在有限的时间和资源下如何有重点的进行测试是测试管理者需要充分考虑的事情。例如，在单元测试的时候，对于哪些函数我们需要重点测试，哪些函数可以粗略测试，哪些函数可以不测试；而对于系统测试，则要考虑首先应当保证哪些功能的测试，其次应当保证哪些功能的测试等等。测试的重点选择需要根据多个方面考虑，包括测试对象的关键程度，可能的风险，质量要求等等。这些考虑与经验有关，随着实践经验的增长，你的判断也会更有效。

第 142 贴【 2004 － 11 － 16 】：测试不是为了证明程序的正确性

正如 Mayer 所说的，测试的目的是证伪而不是证真。事实上，证明程序的正确性是不可能的，一个大型的集成化的软件系统不能被穷尽测试以遍历其每条路径。即使遍历了所有的路径，错误仍有可能隐藏。我们做测试是为了尽可能的去发现错误。因此，测试必须包含一系列测试级别。这些测试级别能最大化对被测对象的覆盖。
    必须有一些标准可以用于平均所有的测试活动。所有可以跟踪到需求的测试可以通过三个方式进行执行：
在正常的数据流量下的有效信息；
在一个控制环境中使用超量的数据输入速率；
使用一个预先计划的正常数据和异常数据的组合；
    理想的测试环境要能够使得一个系统在可控的方式下被破坏。例如，数据及数据组合必须不断变化直到系统不能够以正常的方式接受。系统支持变得不可接受的点必须被确认并文档化下来。
    必须在所有的测试级别上运行测试，且同时使用正常条件和异常条件。这是很严格的，即使在测试环境难以建立的情况下。

第 143 贴【 2004 － 11 － 17 】：测试是不可能穷尽的，当测试出口条件满足时就可以停止测试

有测试大师说测试是为了发现错误，一个好的测试是发现以前没有发现的错误。但是这个要求可能会使人走入极端。其实，不同的系统有着不同的质量要求，对于质量要求严格的系统，可能需要进行长时间的，全面的测试，尽可能的去挖掘系统中的缺陷。然而对于质量要求不是很严格的系统，系统是允许可以出现错误的，因此我们通过测试是要使得系统的缺陷数量能够降到可接受的范围内。
    测试是不可能穷尽的，资源和时间是有限的。因此我们在做测试的时候需要分析哪些功能是对用户很关键的，在这些功能中出现某类型错误对用户是不可接受的，而相对其它一些功能，出现的错误是可以容忍的，这样，我们在测试的时候，重点就应当去寻找那些用户不可接受的错误，而不是漫无目的的去搜索错误。同时我们应当对测试定义合理的出口标准，这是因为测试是没有穷尽的，系统中的问题你总是可以一直发现下去，然而我们不能无休止的去寻找这些问题。当条件满足的时候，我们就应当停止测试。而测试出口条件的设置需要考虑系统的质量要求及系统的资源要求。曾经有人说过：当时间和资源用尽的时候，测试也就停止了。这是没有办法的最好办法。

第 144 贴【 2004 － 11 － 18 】：测试是开发的朋友，不是开发的敌人

测试人员和开发人员经常无法有效的一起工作。这一方面是因为双方工作的性质不同（开发的工作是构建系统，而测试的工作是去破坏系统），另一方面也可能是因为管理的原因造成了测试和开发之间的矛盾。不管是什么原因，这个矛盾，对于产品来说不是一件好事。
    如何处理好测试与开发之间的关系是现代软件管理研究中的一个课题。开发和测试作为一个整体都是服务于产品，都要为产品的质量负责。从这一点上来讲，开发和测试的利益是一致的。要知道，如果在产品交付使用之前，测试人员遗漏了一个问题，而这个问题最终在用户手上被发现，并产生比较严重的后果的时候，那么，我想无论是开发还是测试，最终都逃避不了责任。我们要为质量服务，测试的目的是要去寻找错误，最终提高产品的质量，而不是去找开发的茬，只有当双方都认识到这一点的时候，开发和测试就有共同交流的基础了。测试应当是开发的朋友，他帮助开发寻找遗留在产品中的缺陷，使得开发人员能够产生的更好的产品。测试和开发不应当是敌人。

第 145 贴【 2004 － 11 － 19 】：测试人员应当站在公正的立场上进行测试

我们说测试是开发的朋友，这并不等于测试就应当处处维护开发人员，替开发人员隐瞒缺陷或纵容缺陷的存在。这是对朋友的误解。我们要知道缺陷的存在最终只会影响到整个产品。在开发过程中，测试人员一直承担着质量把关人员的角色，尤其是测试将会是产品最终交付给用户之前的最后一道关卡。如果测试人员不能站在公正的立场上去执行测试，并如实的记录和报告缺陷，那么最后受伤的不仅仅是开发人员，还会包括测试人员自己。对质量负责，不仅仅是对自己负责，也是对开发负责和对产品负责。

第 146 贴【 2004 － 11 － 22 】：测试自动化能解决一部分问题，但不是全部

工具所能发挥的作用依赖于使用工具的人。因此，对工具的过分依赖将降低人的能动性，并最终使测试本身受到损害。适当的使用测试工具能够减轻测试人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。

第 147 贴【 2004 － 11 － 23 】：测试不能仅仅包括功能性的验证，还需要包括非功能性的验证

目前很多公司进行的测试，其范围仅局限在功能领域内进行测试。这一方面可能有产品进度的压力影响，另一方面则是测试人员对测试的理解还比较局限。从用户角度来讲，其需求除了功能性需求外，还包括了非功能性需求，有些非功能需求可能是显性的，而有些非功能需求则是隐性的。我们在测试的时候，应当关注所有的需求，在验证功能的同时，还需要验证产品的性能、可靠性、稳定性、可维护性、安全性、可操作性、可安装性等等。一个产品的缺陷往往会在其性能的边界上产生，如果我们忽视了这部分的测试，很多缺陷将漏过测试进入到用户手上。

第 48 贴【 2004 － 11 － 24 】：尽早的、频繁的进行测试

现代测试的一个重要哲学要求尽可能早的，尽可能频繁的进行测试，尽可能多的从开发那边获得反馈信息。这包含着要求测试尽可能早的进行准备，并且和开发人员一起进行评审、走读、单元测试、原型评价、早期模拟等等。早期测试的目的是尽可能早的发现任何意想不到的坏的消息，并且帮助开发人员产生高质量的单元。
    该方法希望在缺陷产生的时候发现并纠正缺陷，它假设了在早期测试中发现的问题能够被描述并及时修正。许多项目管理人员延迟了缺陷修正的时间直到开发人员已经完成了所有特性的设计和编码。这大大提高了系统出错的可能，也增加了修改的成本。一般来说，一次完成一个特性的设计和编码，并保证其正确性将更加有效一些。
    为什么我们要尽早的发现缺陷和修正缺陷呢？这主要有以下原因：
1 、缺陷的修改成本随着阶段的推移将急剧上升，在产品发布之后修正一个缺陷的成本将是需求阶段的 100 倍，甚至更高；
2 、缺陷具有放大的特点，缺陷修改延迟几个星期甚至几个月将使得系统更容易出错；
3 、设计判定和一些小的代码限制及条件很容易被忘掉；
4 、尽早修正缺陷可以节省重新分析设计的时间；
5 、早期的问题反馈有助于防止类似错误的产生；
6 、大量的缺陷和问题跟踪工作将被减轻；
7 、如果必要的话，可以重新设计和编码，而这个工作越往后期越不可能

第 149 贴【 2004 － 11 － 25 】：尽早的产生一个综合的主测试计划

提供和维护一个主测试计划（ Master Testing Plan ），包含所有预期的测试活动和测试交付物。综合的测试计划应当结合总的项目和程序开发计划，并保证资源和责任在项目中尽可能早的被了解和分配。
      大部分项目没有尽早的描述测试的问题。主测试计划解决了这个问题并且使得测试的工作和策略可以被项目中的每个人看到和理解。主测试计划至少应当包括测试的总工作量，分配所有主要工作的责任以及在所有测试级别上应交付的物件。其目的是要提供一个大的活动图并且协调所有的测试工作。
      主测试计划涉及到项目组所有成员，包括用户、客户和管理人员。在测试评价中所包含的每个人的活动应当被描述，包括那些分配给开发人员的活动，例如：单元评审和测试。产品经理以及那些在项目之外的人员将发现主测试计划有助于把测试过程融合到整个项目开发过程中去。随着项目的进行，主测试计划也将被修正和更新。
      创建主测试计划不需要花费许多工作量，并且它不需要是一个特别冗长的或者严肃的文档。许多内容可以通过类似于 RAD ，头脑风暴等方法在项目早期被完成。

第 150 贴【 2004 － 11 － 26 】：对质量要求较高的产品或大型复杂的产品成立独立的测试组

测试是一个需要专业技能的工作，它需要专门的培训和实践，你不应当把它看作是一个开发之外附带的工作。大部分人认为（尤其是项目管理人员）测试是项目工作中的一部分，因此他们认为只要能够小心的彻底的测试自己的工作，就能够提交高质量的工作结果。我们完全可以理解好的测试是每个人的任务。我们也知道测试是过程的一部分，并且在大部分情况下，我们知道需要做什么，需要得到什么。然而，事实上在进度和竞争的压力下，测试任务经常被第一个延迟、裁减或完全绕开。为什么会这样呢？我们应当做些什么才能使得组内每个人更好的履行他的责任呢？
      大部分问题是心里上的问题：
   当我们知道会有更多的问题被发现的时候，测试会让人沮丧；
   当我们认为每一样东西都已经被完成的时候，测试让人厌烦；
   弱的测试让我们感觉获得比实际上更多的进展；
   对开发人员来说，测试暴露的问题越多，意味着有更多的返工需要进行；
   对管理人员来说，测试看起来像是虚的工作，在项目陷入问题的时候是可以被砍调的；
   开发人员相信用户和客户愿意购买低质量的，但功能更多的产品；

    由一个独立于开发的专业测试组来从事项目的测试是一个比较好的实践，并且能有效解决上面的问题。

第 151 贴【 2004 － 11 － 29 】：在每个开发阶段，使用质量评价标准

许多项目看上去都进行的非常不错，但到它们进入集成测试和系统测试后，这时，甚至一个简单的测试都无法运行起来。如何避免这种现象的产生呢？一个好的方法是尽早测试，并且在每个阶段上通过测试数据来评价其是否能通过阶段的质量标准。当你坚持使用测试来分阶段证明每一个特性或对象被完成，那么你就能保证各阶段的设计和代码被真正的按照质量要求完成。

第 152 贴【 2004 － 11 － 30 】：开发和维护一个测试需求和目标的风险优先级列表

现代测试的一个重要实践是在测试被设计和创建之前建立一个需要覆盖的目标清单。这个清单细化了需要测试的内容，并且被用于指导和驱动测试设计和开发工作。根据风险的优先级（一般分为高、中、低）有助于使测试关注于高风险区域。
    下面是一个如何获取测试清单的指导：
尽可能早的开始并且覆盖所有需求或功能设计规格；
使用头脑风暴和非正式会议来创建一些大家担心的事项列表；
在评审期间，评价清单中的每一项，并设定优先级；
把清单中的内容分成三个主要的增量组：需求、设计和代码；
把每个增量组分解成一个小部分的逻辑组；

    由于清单列表可能会变得非常长，因此把它们分类是很有帮助的。遗漏的目标可以很容易从这些组中被确认。
    随着每个测试被开发，相关的清单目标和组被进行了记录，作为测试描述的一部分。通过一些简单的测试管理工具，你可以报告需求和目标的测试覆盖情况，尤其是哪些还没有被任何测试覆盖到的目标。

杨粼波 2006-07-27 21:26 发表评论
]]>转载]Mantis安装配置说明http://www.cppblog.com/tx7do/archive/2006/07/25/10507.html杨粼波杨粼波Tue, 25 Jul 2006 13:04:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/25/10507.htmlhttp://www.cppblog.com/tx7do/comments/10507.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/25/10507.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10507.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10507.html

杨粼波 2006-07-25 21:04 发表评论
]]>Mantis学习笔记http://www.cppblog.com/tx7do/archive/2006/07/25/10502.html杨粼波杨粼波Tue, 25 Jul 2006 12:45:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/25/10502.htmlhttp://www.cppblog.com/tx7do/comments/10502.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/25/10502.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10502.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10502.htmlMantis学习笔记

mantislogo.gif　　在错误追踪系统中，Mantis绝对是个轻量级的工具，无论安装还是配置或使用，正如它自己的目标中所宣称的。但是，对一个中小型的项目来言，功能够用。
　　非常感谢车东的推荐，也使我进一步关注学习成本和够用就好的观点。

0、介绍


　　Mantis是一个基于php/MySQL/web的开源的错误追踪系统。
　　Mantis中的bug追踪及处理和管理流程参考下图。
mantis_usage.gif
　　默认的mantis用户类型及其权限叁看下表，具体使用时可据需要修改名称及增删用户类型），
 View BugReport BugUpdate BugAssign BugResolve BugClose BugReopen BugDelete Bug
ViewerYNNNNNNN
ReporterYYNNNNNN
UpdaterYYYYYYYN
DeveloperYYYYYYYY
ManagerYYYYYYYY
AdministratorYYYYYYYY


1、下载


　　现在最高版本是0.18.0rc1，安装要求PHP版本为4.0.3 或以上，MySQL版本为3.23.2或以上（它计划在其2.0版本中支持其它关系数据库）。

2、安装


1）解压缩
$tar zxvf mantis-0.18.0rc1.gz
$mv mantis-0.18.0rc1 mantis

2)建立数据库mantis及用户mantis

$mysqladmin -u root -p密码 create mantis
$mysql -u root -p密码
mysql>GRANT SELECT,INSERT,UPDATE,DELETE,INDEX, ALTER,CREATE,DROP,REFERENCES ON mantis.* TO mantis@localhost IDENTIFIED BY '你指定的密码';
mysql>FLUSH PRIVILEGES;
mysql>\q

3)修改配置文件

$cd mantis
$cp config_inc.php.sample config_inc.php
$vi config_inc.php
修改以下几行为
$g_db_username = "mantis";
$g_db_password = "你在建立用户时指定的密码";
$g_database_name = "mantis";
增加以下几行
$g_path = "http://www.yourdomain.com/bugtrack/";
$g_icon_path = $g_path."images/";
$g_absolute_path = "/解压缩的目录/mantis/";#此处的mantis要和第1）步中mv的目标一致
$g_use_iis = OFF;#我用的是linux
$g_show_version = ON;
然后根据具体情况设置那一堆email.

4)做汉化
　　有几个人已经做了汉化，此处只需要配置

$vi config_inc.php
修改下一行为
$g_default_language = 'chinese_simplified';
$vi sql/db_generate.sql
language varchar(32) NOT NULL default 'chinese_simplified',

5)创建数据库的表

$mysql -u mantis -p你指定的密码 mantis < sql/db_generate.sql

6)修改apache的配置文件并重新启动

$vi /etc/httpd/conf/httpd.conf
增加以下几行（供参考）：
Alias /bugtrack/ "/解压缩目录/mantis/"

Options Indexes MultiViews Includes FollowSymLinks +ExecCGI
AllowOverride None
Order allow,deny
Allow from all

注:此处的bugtrack要与第三步中的$g_path中的bugtrack保持一致
$su -
#service httpd restart

7)通过浏览器访问http://www.yourdomain.com/bugtrack/。
如果出现登录页面，则一切OK！

3、应用


　　以administrator用户登录，密码为root，新建一个用户，权限为administrate。以新用户登录，删除administor.
　　同时，将安装目录/mantis下admin目录删除。

杨粼波 2006-07-25 20:45 发表评论
]]>BugZilla之外的选择——另一个 Bug 跟踪管理系统 Mantis 在 IIS5 下安装指南 http://www.cppblog.com/tx7do/archive/2006/07/25/10501.html杨粼波杨粼波Tue, 25 Jul 2006 12:39:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/25/10501.htmlhttp://www.cppblog.com/tx7do/comments/10501.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/25/10501.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10501.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10501.html最开始想找一个 Bug 跟踪管理系统时，是想用 BugZilla 的，但是在实际安装使用时发现在 Windows 下安装非常费劲，需要自己改动 n 多的地方才能获得一个可以在Windows下使用的 Hack 版本，而且邮件设置怎么都没有成功，最后只好放弃。

在网上查找BugZilla相关资料的时候发现了 Mantis，这也是一个开源的 Bug 跟踪管理系统，基于 PHP+MySQL，支持 Windows；相对于BugZilla，比较轻量级，不过对于我们的开发团队来说是完全够用了，所以我在放弃了BugZilla以后就转向了 Mantis 。

下面是我写的一个安装指南。

Bug 跟踪管理系统 Mantis 在 IIS5 下安装指南 v1.1

v1.1：修改部分错误；
修改JPGraph和PHPMailer设置部分路径误为C:\PHP\C:\PHP\...的错误；
JPGraph设置部分增加对PHP.INI中extension_dir的修改；
v1.0：完成于2004-03-18；

这是我写的一篇 Mantis 在 Windows IIS 下的安装指南，如果对你有帮助我会很高兴。
转载请注明出处。

和BugZilla一样，Mantis也是一个开源的Bug管理系统；基于PHP+MySQL，可以运行在Windows/xnix平台上；它的主页是http://www.mantisbt.org/，目前最新版本是0.18.2。
和BugZilla不一样的是，Mantis是轻量级的，在功能上相对比较少一些（特别是报表模块），不过对于小型的开发团队是完全够用了。
对于我来说，Mantis是完全够用了，而且最重要的一点是：Mantis直接提供对Windows平台的支持，不需要自己做n多的修改做出一个Hack版本才能运行在Windows平台上。在多次尝试使用BugZilla失败后，我转向了Mantis。
可能已经有人注意到了，Mantis是螳螂的意思，我想给Mantis起这个名字的人一定是希望这只螳螂能够把我们系统中的Bug统统吃掉吧:-D？

说明：
1.由于我使用的是IIS，没有使用apache，因此我下面的安装说明全部都是在IIS上进行的；
2.下面所说的操作都是我的事后回忆，有些细节可能不是很正确，如果有问题，请大家自己尝试解决，或与我联系：TurboNetCobra@hotmail.com（不可能每信必复，如果发送邮件后没有回音，敬请谅解）；
3.文中所说的软件的最高版本号均为截止到2004-03-17的最高版本号；

好了，下面我们开始安装Mantis。

需要作的准备工作：
1.从http://www.mysql.com/downloads/index.html下载MySQL安装文件，请下载Windows安装文件，当前有多个版本可供下载，出于稳定起见，建议下载推荐的Production release (recommended)，目前最高版本是4.0.18；同时可以下载MySQL Control Center，一个免费的MySQL图形管理界面程序；
2.从http://www.php.net/downloads.php下载PHP安装文件，目前最高版本4.3.4，请下载Windows安装文件；其中“PHP 4.3.4 installer”EXE包可以自动进行设置，但是比ZIP包缺少一些模块，如果需要使用图形报表功能，建议下载“PHP 4.3.4 zip package”ZIP包，因为图形报表需要使用到包括在ZIP报中的PHP扩展模块，不过ZIP需要自己手工设置；
提示：对于象我这样的懒人，你可以这样做：两个都下载，先安装EXE包自动完成设置工作，然后将ZIP包解压缩到PHP安装目录，覆盖原文件，然后手工修改PHP.ini配置文件，让PHP载入扩展模块，就可以得到一个完整的PHP安装包了*^_^*；
3.从http://www.mantisbt.org/download.php下载Mantis安装文件，目前最高版本是0.18.2；
4.（可选项）如果希望使用Mantis的PHPMailer发信功能和图形报表功能，则还需要PHP的PHPMailer模块和JPGraph模块，请分别到http://phpmailer.sourceforge.net 和http://www.aditus.nu/jpgraph/index.php下载，最新版本分别是1.71和1.14；

准备就绪，下面就可以开始安装了；

1.安装MySQL，建立数据库；
MySQL的安装很简单，解压缩下载得到的ZIP包，运行其中的setup.exe文件，然后就可以用“Next”大法轻松安装；这里假设你的MySQL安装在C:\MySQL下；
安装后运行C:\mysql\bin\下的winmysqladmin.exe文件，如果在系统任务栏显示绿灯，表示你的MySQL服务已经启动了；
1)修改MySQL默认的root用户密码：
在命令行下进入c:\mysql\bin，运行如下命令： 

    C:\>cd mysql  
    C:\mysql>cd bin  
    C:\mysql\bin>mysql -u root mysql  
       mysql>UPDATE user SET Password=PASSWORD( ’<new_root_password’> ) WHERE user=’root’;  
       mysql>FLUSH PRIVILEGES;

说明：请将< new_ root_password>改为你设定的root用户的新密码。更改密码后，要用root用户访问mysql，必须使用mysql -u root -p，按提示输入入正确的root新密码。
2)创建mantis数据库：
注意：进行这一步以前，需要先把你的Mantis安装包解压缩，因为创建数据库需要用到其中的建表SQL文件。 

       mysql>create database mantis;  
       mysql>connect mantis;  
       mysql>source <mantis_path>\sql\db_generate.sql

说明：请将<mantis_path>改为你解压缩Mantis安装包的路径；
3)创建mantis用户，并赋给对Mantis数据库的相应权限： 

       mysql>GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, DROP, REFERENCES, LOCK TABLES,  
                  CREATE TEMPORARY TABLES ON mantis.* TO mantis@localhost IDENTIFIED BY ’<mantis_password>’;  
       mysql>FLUSH PRIVILEGES;

说明：请将<mantis_password>改为你设定的mantis用户的密码；这个密码在下面的操作中要写到Mantis的配置文件中；
4)完成MySQL初始化工作，退出 

       mysql>exit

上面的数据库操作也可以直接在mysqlcc图形界面中完成。

2.安装PHP
我的安装方法就是上面说的懒人安装方法*^_^*，好像就没有什么特别操作了；在使用图表和PHPMail时需要修改PHP.ini，这些修改我会在后面讲到。

3.设置Mantis
1)打开IIS管理器，在默认网站中增加一个虚拟目录Mantis，指向你的Mantis解压缩目录（这里使用D:\WebSite\Mantis），在“属性”窗口的“文档”页面增加默认文档“index.php”；
2)将D:\WebSite\Mantis中的config_inc.php.sample复制一份，改名为config_inc.php，修改其中的设置；
Mantis的设置是这样保存的：在config_defaults_inc.php中保存这Mantis的默认设置，用户自己的设置信息保存在config_inc.php中，如果某个选项在config_inc.php中有设置，则系统使用config_inc.php中的设置，否则使用config_defaults_inc.php的系统默认设置；config_inc.php.sample则是Mantis给出的一个用户设置文件例子。
所以我们需要修改config_inc.php文件中的设置，设置很简单，各个参数的意义可以参见config_defaults_inc.php，这里对每个参数都有详细的解释，虽然是E文，不过应该都能看懂；Sample中给出的一些设置是一定需要修改的，比如MySQL数据库的连接参数，管理员的邮箱的；其他的要根据你的实际情况进行修改。
下面是我的一些自定义参数，其中一些参数（$g_use_jpgraph 和$g_use_phpMailer的设置请参照下面的内容）： 

 $g_use_iis                             = ON;                                 # 使用IIS 
 $g_show_version                        = OFF;                                # 不在页面下部显示 Mantis的版本号 
 $g_default_language                    = ’chinese_simplified’;              # 默认语言为简体中文 
 $g_show_project_menu_bar               = ON;                                 # 显示项目选择栏 
 $g_show_queries_count                  = OFF;                                # 在页脚不显示执行的查询次数 
 $g_default_new_account_access_level    = DEVELOPER;                          # 默认用户级别 
 $g_use_jpgraph                         = ON;                                 # 使用图形报表 
 $g_jpgraph_path                        = ’C:/PHP/includes/JPGraph/src/’;    # JPGraph路径 
 $g_window_title                        = ’Mantis Bug 跟踪管理系统’;          # 浏览器标题 
 $g_page_title                          = ’Mantis Bug 跟踪管理系统’;          # 页面标题栏 
 $g_enable_email_notification           = ON;                                 # 开通邮件通知 
 $g_smtp_host                           = ’smtp.mail.net’;                   # SMTP 服务器 
 $g_smtp_username                       = ’mailuser’;                        # 邮箱登录用户名 
 $g_smtp_password                       = ’mailpwd’;                         # 邮箱登录密码 
 $g_use_phpMailer                       = ON;                                 # 使用 PHPMailer 发送邮件 
 $g_phpMailer_path                      = ’C:/PHP/includes/PHPMailer/’;      # PHPMailer 的存放路径 
 $g_phpMailer_method                    = 2;                                  # PHPMailer 以 SMTP 方式发送 Email 
 $g_file_upload_ftp_server              = ’ftp.yourftp.com’;                 # 上传文件 FTP 
 $g_file_upload_ftp_user                = ’ftpuser’;                         # FTP 登录用户名 
 $g_file_upload_ftp_pass                = ’ftppwd’;                          # FTP 登录密码 
 $g_short_date_format                   = ’Y-m-d’;                           # 短日期格式，Y 大写表示 4 位年 
 $g_normal_date_format                  = ’Y-m-d H:i’;                       # 普通日期格式 
 $g_complete_date_format                = ’Y-m-d H:i:s’;                     # 完整日期格式

完成以上设置以后，你就可以使用Mantis了，打开IE，输入http://localhost/mantis，应该就可以看到Mantis的登录页面了，你可以用默认用户名administrator和密码root登录进去，进行管理设置。

4.Mantis的初步安全设置
1)在Mantis目录下有一个admin目录，如果你在IE中打开这个目录下的index.php查看，你就会知道这个目录是进行Mantis Administration的，使用这个模块可以检查你的Mantis是否安装完全，对旧版本的Mantis进行升级，对Mantis的页面CSS文件进行修改；使用这个管理模块是不需要用户名和密码的，因此任何人都可以通过这个管理模块查看你的Mantis系统信息，而且由于有升级模块，在这里还可以直接对数据库进行修改；因此如果被未授权的人打开，结果会是什么样不用我多说；最好因此按照系统的建议，在配置完成后将这个admin目录删除；注意一定是删除而不是改名！改名后仍然是可以访问的！
2)在添加一个管理员用户后，删除系统默认的administrator用户。

5.PHPMail的设置
默认情况下，Mantis使用内置的Mailto()函数进行邮件的发送，包括新用户注册发送密码、Bug改变提醒、重设密码等邮件的发送都使用MailTo()来完成，不过实际使用中发现，MailTo函数好像不支持需要校验的邮件服务器，比如我的263邮箱每次都提示需要校验，所以我给PHP安装了PHPMail模块，设置Mantis使用PHPMailer发送邮件。
1)下载PHPMailer：从http://phpmailer.sourceforge.net下载，最新版本是1.71;
2)安装PHPMailer：将下载下来的phpmailer-1.71.zip解压缩到C:\PHP\includes \PHPMailer目录下；
3)修改Windows目录下的PHP.ini，找到include_path，增加C:\PHP\includes \PHPMailer目录；
4)如上表所示，设置$g_use_phpMailer、$g_phpMailer_path和$g_phpMailer_method三个参数；
5)现在应该就可以使用PHPMailer进行邮件发送了；

6.图形报表的设置
默认情况下，Mantis的图形报表是关闭的，需要安装JPGraph模块并设置$g_use_jpgraph为ON才能打开图形报表；
1)下载JPGraph：从http://www.aditus.nu/jpgraph/index.php下载JPGraph的安装文件，目前最高版本是1.14；
2)将下载下来的jpgraph-1.14.tar.gz解压缩到C:\PHP\includes目录下；
3)打开config_inc.php文件，修改$g_jpgraph_path为JPGraph的src目录，$g_use_jpgraph为ON；
4)修改Windows目录下的PHP.ini文件，将“;extension=php_gd2.dll”和“;extension=php_iconv.dll”两行前面的分号删除；另外如果extension_dir项不正确，请把extension_dir改为正确的值（应该是extension_dir = "./extensions/"，我这里不知道为什么是extension_dir = "./"，大概就是因为使用懒人安装方法的缘故吧tongue）；
5)将C:\PHP\dlls下面的iconv.dll复制到Windows\System32目录下，以上两个步骤使PHP自动载入php_gd2和php_iconv.dll模块，这两个模块是JPGraph在显示图表和进行汉字编码转换是所必须的；
6)修改JPGraph的src目录下的jpgraph.php；将CACHE_DIR和TTF_DIR分别定义为Windows下的Temp目录和Fonts目录，如下所示 

 DEFINE("CACHE_DIR","E:/WinTemp/Temp/jpgraph_cache"); 
 DEFINE("TTF_DIR","C:/WinNT/Fonts/");

7)现在再打开Mantis的统计页面，可以看到多了分别按状态等进行统计的图形报表，包括柱图、饼图和线图；
8)不过如果你的界面语言是用简体中文或者繁体中文，那么你会看到图形中的汉字都是乱码，这是因为Mantis对于JPGraph的编码设置不正确造成的，JPGraph会自动将汉字转换为UTF-8编码，但是需要在调用JPGraph的时候对标题等SetFont，Mantis没有做这个操作，因此汉字显示出来都是乱码，解决方法是在Mantis\core\graph_api.php中增加对图形标题等设置字体的代码；
对于柱图和线图，要设置图形标题和x、y轴标题、节点标题： 

   //Set the title and axis font if the default_language is set to chinese  
   if (config_get(’default_language’) == ’chinese_simplified’){  
     $graph->title->SetFont(FF_SIMSUN,FS_NORMAL);  
     $graph->xaxis->title->SetFont(FF_SIMSUN,FS_NORMAL);  
     $graph->yaxis->title->SetFont(FF_SIMSUN,FS_NORMAL);  
     $graph->xaxis->SetFont(FF_SIMSUN,FS_NORMAL);  
     $graph->yaxis->SetFont(FF_SIMSUN,FS_NORMAL);  
   }  
   else if (config_get(’default_language’) == ’chinese_traditional’){  
     $graph->title->SetFont(FF_CHINESE,FS_NORMAL);  
     $graph->yaxis->title->SetFont(FF_CHINESE,FS_NORMAL);  
     $graph->xaxis->title->SetFont(FF_CHINESE,FS_NORMAL);  
     $graph->xaxis->SetFont(FF_CHINESE,FS_NORMAL);  
     $graph->yaxis->SetFont(FF_CHINESE,FS_NORMAL);  
     };  
     

对于饼图，要设置图形标题和图例名称： 

   //Set the title and legend font if the default_language is set to chinese  
   if (config_get(’default_language’) == ’chinese_simplified’){  
     $graph->title->SetFont(FF_SIMSUN,FS_NORMAL);  
     $graph->legend->SetFont(FF_SIMSUN,FS_NORMAL);  
   }  
   else if (config_get(’default_language’) == ’chinese_traditional’){  
     $graph->title->SetFont(FF_CHINESE,FS_NORMAL);  
     $graph->legend->SetFont(FF_CHINESE,FS_NORMAL);  
   }; 
   

大家可以找到位置自己修改，简单的说就是在graph_api.php中每个“$graph->title->Set(…”后面根据当前的图表是柱图、线图还是饼图分别加上上面两段；
9)现在你的图形报表应该就可以显示中文了。

好了，Mantis的配置工作到此就结束了，现在你的Mantis功能应该是完全而且是安全的了，相对于BugZilla，Mantis的确很“轻量”，不过我的想法是够用就好，对于小团队，Mantis足够应付80％的日常Bug管理工作了。

杨粼波 2006-07-25 20:39 发表评论
]]>Windows下开源缺陷跟踪系统mantis安装指南http://www.cppblog.com/tx7do/archive/2006/07/25/10498.html杨粼波杨粼波Tue, 25 Jul 2006 12:26:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/25/10498.htmlhttp://www.cppblog.com/tx7do/comments/10498.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/25/10498.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10498.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10498.html1. 简介
mantis(螳螂)是一个基于php/MySQL/web的缺陷跟踪系统，最新版本是0.19.2。
要了解更多信息请到http://www.mantisbt.org/。
2. 下载
mantis0.19.2   http://www.mantisbt.org/download.php
mysql5.0.2       http://dev.mysql.com/downloads/mysql/5.0.html
PHP5.0.3     http://www.php.net/downloads.php
apache2.0.52   http://httpd.apache.org/download.cgi
3. 安装步骤
   1）安装刚才下载的软件
   下面假设各软件的安装目录为
   c:\mantis-0.19.2
   c:\mysql-5.0.2
   c:\php-5.0.3
   c:\apache-2.0.52 
   我习惯下载zip版的程序，直接解压到一个目录就可以了。没有的话，只好下载windows_installer版本：）。
   a.安装apache2.0.52
   我下载的是http://apache.freelamp.com/httpd/binaries/win32/apache_2.0.52-win32-x86-no_ssl.msi
   运行安装程序，安装时选择安装给当前用户，采用8080端口，不要安装成服务，对我来说没必要。安装后同样可以再安装成service  
   详细请参考：
   apahce在windows下的安装指南 http://httpd.apache.org/docs-2.0/platform/windows.html
   运行c:\apache-2.0.52\bin\apache.exe，在IE地址栏输入http://localhost:8080/，可以看到安装成功。如果前面是安装成80端口的服务，则输入http://localhost/
   b.其它的软件直接解压到自己想要的目录。当然如果你下载的是installer也是一样的，直接运行安装程序，无非是安装
   后多了几个启动的快捷菜单外加一些默认设置罢了。
   2）为apache配置php
   打开c:\apache-2.0.52 \conf\httpd.conf文件，添加如下内容到文件尾
  #PHP 5
  LoadFile "c:/php-5.0.3/php5ts.dll"
  LoadModule php5_module "c:/php-5.0.3/php5apache2.dll"
  AddType application/x-httpd-php .php
 ＃PHP.ini path
  PHPIniDir "c:/php-5.0.3"
   3）php配置
   将c:\php-5.0.3下的php.ini-dist复制一份，并改名为php.ini
   查找include_path,改为include_path=".;c:\php-5.0.3\pear"
   查找extension_dir,改为extension_dir="c:\php-5.0.3\ext"
   查找php_mysql.dll,将这一行前面的“;”号去掉
   保存文件
   4）为apache安装mantis系统
   打开c:\apache-2.0.52 \conf\httpd.conf文件，添加如下内容到文件尾
   Alias /mantis "c:/mantis-0.19.2/"
   <Directory "c:/mantis-0.19.2/">
    Options Indexes
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>
  查找DirectoryIndex，添加index.php到后面。像这样DirectoryIndex index.html index.html.var index.php
   5)创建数据库
   运行c:\mysql-5.0.2\bin\mysqld-nt，启动数据库
   mysql -uroot -p
   create database bugtracker;
   use bugtracker;
   source c:\mantis-0.19.2\sql\db_generate.sql;
  当然你也可以用其它GUI工具创建数据库。
   6)mantis配置
   将c:\mantis-0.19.2下的config_inc.php.sample复制一份，并改名为config_inc.php
  如果你改了root的密码，打开这个文件，设置$g_db_password='yourpassword'
   7)windows环境
   将c:\php-5.0.3添加到path中
   8)启动bug tracking system
   首先启动apache和mysql,
   在址栏输入http://localhost:8080/mantis/index.php或者http://localhost/mantis/index.php
   应该可以看到初始页面了。用amdinistrator/root登录，mantis 开始为你工作。
   9)邮件服务器配置
   在c:\php-5.0.3\php.ini文件中查找smtp,将localhost改为你的发件服务器,如SMTP = smtp.163.com
   在php.ini文件中查找sendmail_from,将前面的分号去掉,并在后面填上邮件地址
   在c:\mantis-0.19.2\config_inc.php文件中添加
   $g_smtp_host='smtp.163.com';
   $g_smtp_username='yourusername';
   $g_smtp_password='yourpassword';
   $g_phpMailer_method =2;
 
   查找$g_return_path_email,将后面的邮件地址改为有效的地址,这一点非常重要,不然将无法正常发送激活注册的邮件.
   config_inc.php其它邮件地址最好也改为有效的地址.
   $g_smtp_username,$g_smtp_password在服务器需要验证时用,不需验证时不用加,或设为
   $g_smtp_username=''
   $g_smtp_password=''
   现在你可以注册新用户,并使用发送邮件功能了。  
4.后记
  昨天想装一个bug tracking system，上网转了一下，最后选定了mantis，理由只有一个：感觉这是一个功能能满足我的需要，更重要的是我能掌控的系统，以前除了在mysql上create过一个db外，没有用过上面的任何一种软件。安装这个东西完全是为了我自己用，我是一个很懒的人，觉得把一些问题记在txt里会有一些麻烦，其他人如果愿意用，我当然不反对：）。
  从下载安装到写完这个所谓的指南，用了几乎一天，有一些小问题浪费了很多时间，网上的一些安装手册，并没有想象的好用，
  按照我这个指南，一个小时应该可以搞定。
 
集成apache+php+mysql+...的安装工具，http://www.apachefriends.org/en/xampp.html用它来安装very easy，即使你什么都不懂，也只要几分钟。
下载windows下的安装包,setup,找到apache\conf\httpd.conf，在文件最后添加
Alias /mantis "c:/mantis-0.19.2/"
   <Directory "c:/mantis-0.19.2/">
    Options Indexes
 AllowOverride None
 Order allow,deny
 Allow from all
  </Directory>
启动apache和mysql就行了。发邮件的功能设置见上面的3.9)
唯一不好的是，他安装了一整套软件，如果你的机器上已经安装了mysql等，就会浪费一些硬盘空间。
 
续：今天试了一下，发现发邮件的功能不能用，昨天试的时候说发送成功实际上并没有。上面的文档 邮件服务器配置 部分已经经过修改，可以收到注册激活邮件了。调试的时假注意把垃圾瑞星监视等关掉，打开以后php可能不会返回合适的出错提示，浪费大量时间。


杨粼波 2006-07-25 20:26 发表评论
]]>Windows下开源缺陷跟踪系统mantis安装指南(续)- http://www.cppblog.com/tx7do/archive/2006/07/25/10499.html杨粼波杨粼波Tue, 25 Jul 2006 12:26:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/25/10499.htmlhttp://www.cppblog.com/tx7do/comments/10499.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/25/10499.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10499.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10499.html1)中文显示
在APACHE的httpd.conf配置文件中将AddDefaultCharset ISO-8859-1 改为 AddDefaultCharset OFF
2)数据库
对mysql5.0.2支持不好,有严重bug
用4.1.8没有问题
3)上传文件
在config_inc.php中添加
$g_allow_file_upload=ON;
$g_file_upload_method=DISK;
并且在c:\mantis-0.19.2下面新建一个upload目录
当你以管理员身份登录,新建项目时,在上传文件路径那一项填上upload即可,如果要为每一个项目指定不同的目录,可能先在upload下建一个projectname,在上传文件路径那一项填上upload\projectname
注意最好不要用中文目录名,目录名中间也不要带空格.


杨粼波 2006-07-25 20:26 发表评论
]]>TEST TOOLShttp://www.cppblog.com/tx7do/archive/2006/07/24/10404.html杨粼波杨粼波Mon, 24 Jul 2006 07:05:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/24/10404.htmlhttp://www.cppblog.com/tx7do/comments/10404.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/24/10404.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10404.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10404.html
 

            TEST MANAGEMENT & PLANNING

          COMMERCIAL

 Mercury TestDirector Mercury TestDirector allows to plan and schedule tests, analyze results, and manage defects and issues. TestDirector is a single, Web-based application for all essential aspects of quality management — Requirements Management, Test Plan, Test Lab, and Defects Management. These core modules are available either as a standalone solution or integrated within a global Quality Center of Excellence environment.
    
 IBM Rational TestManager IBM Rational TestManager is a console for test activity management, execution and reporting. Built for extensibility, it supports everything from pure manual test approaches to various automated paradigms including unit testing, functional regression testing, and performance testing.  Rational TestManager is freely available to all users of IBM Rational Functional Tester and IBM Rational Robot.
    

         OPEN SOURCE

 Testmaster A testcase management, logging, reporting and test automation tool, similar to the commercial product Test Director. Features: Progress stats, reports, test case import from CSV,doc,web or SQL, STAF plugin. SQL database.
    
 TestLink TestLink is a web based test management and test execution system. Enables quality assurance teams create and manage their test cases as well as organize them into test plans. These test plans allow team members to execute test cases and track test results dynamically.
    
 QAtraq QAtraq allows you to consolidate the whole test process with one test management tool. From communicating your test plans, to managing results and producing reports.
    
 Bugzilla Test Runner Bugzilla Test Runner is a test case management system that works as an add-on over Bugzilla, the leading open-source bug-tracking system.
With this tool you can define test plans and test cases, group your test cases into functional groups, support test runs (statistics, reportin) and link test case runs with bugs.
Test plan and test cases can be imported/exported to HTML.
    
 GanttProject GanttProject is a tool for project (and test) planning, developed in Java (SDK>=1.4).
    
 Test Case Manager (TCM) Test Case Manager (TCM) is a tool designed for software test engineers to organize test cases for storage and execution logging. Test cases are written up in a standard format and saved into the system. Test cases can be organized by level (Smoke, Critical Path, Acceptance Criteria, Suggested), by area (GUI breakdown, installation, data, etc.), by status (pass, fail, untested, etc.), or other breakdown criteria.
    
 TETware Provided as both a freely available Open Source product and a fully supported product, known as TETware (which also includes additional platform support), the Test Environment Toolkit provides an easy to use framework which can be built to support local testing, remote testing, distributed testing, testing on real-time and embedded systems.
Example application areas include Operating system tests, Network API tests, Protocol tests, Object Oriented tests and Data management tests.
Key attributes of where TETware can be used, is for automated, repetitive testing, usually close to a system level or library level where well defined interfaces exist.
    
 QMTest QMTest's extensible architecture allows it to handle a wide range of application domains: everything from compilers to graphical user interfaces to web-based applications. QMTest can easily compare test results to known-good baselines, making analyzing test results far simpler. This tool runs on virtuall all operating systems and is developed by CodeSourcery.
    

           

          UNIT TESTING

          COMMERCIAL

 CTA++
CTC++
CMT++
CMTJava 		 In its category Testwell is one of the leading vendors of testing tools for C, C++ and Java languages. The tools are applicable in code-level unit testing (test harnessing, test coverage), systems testing (test coverage) and static analysis (code metrics) sub-phases of testing.
Verifysoft is the market responsible for Switzerland.
    

            OPEN SOURCE

 JUnit JUnit is a simple framework for writing and running automated tests. As a political gesture, it celebrates programmers testing their own software.
    
 Jetif Jetif is a regression test framework in pure Java. It provides a simple and flexible architecture for Java unit testing and functional testing, and used for testing in both individual and enterprise software development.
    

           

          AUTOMATED FUNCTIONAL AND REGRESSION TESTING

          COMMERCIAL

 Mercury QuickTest Professional

Mercury
WinRunner		 

Mercury QuickTest Professional is a solution for functional test and regression test automation - addressing every major software application and environment.
Mercury WinRunner is a similar tool, the difference lies primarily in the supported environments.
Mercury provides a comparison between QuickTest Professional and WinRunner as well as a short guide for choosing the best product option.
Both products are combined in the Mercury Functional Testing suite.

    
 IBM Rational Functional Tester IBM Rational Functional Tester is an evolution of the Rational RobotJ and IBM Rational XDE Tester tools. It is an automated functional and regression testing tool for testers and GUI developers for testing Java, Microsoft Visual Studio .NET and Web-based applications.The tool can also be extended to support the testing of terminal-based applications (mainframe environment).
    
 Empirix e-Tester Empirix e-Tester enables Automated Functional Testing of Enterprise Applications.
    
 Compuware Testpartner Compuware TestPartner is an automated functional and regression testing tool that has been specially designed for testing complex applications based on Microsoft, Java and web based technologies. Unique features of TestPartner allow both testers and developers to create repeatable tests through visual scripting and automatic wizards. Users also have access to the full capabilities of Microsoft's Visual Basic for Applications (VBA), allowing tests to be as high level or detailed as needed.
Testpartner is an evolution based on Microsoft VBA of QARun.
    
 Radview WebFT Radview WebFT is a robust, Web-centric testing solution that efficiently verifies the functional accuracy of Web applications and ensures applications perform as expected. Built specifically for functional testing of Web applications, WebFT supports both established and emerging Web technologies.
    
 Seapine QA
Wizard		 

Seapine QA Wizard completely automates
the functional and regression testing of Web-based, Windows,
and Java applications.
A comparison between Seapine QA Wizard and Mercury Interactive WinRunner is presented here. Seapine also proposes an evaluation guide.

    
 Segue SilkTest 

Segue SilkTest supports Web, Java, client/server and enterprise applications. Comes with many adds-on (for instance for writing automation scripts in C/C++ or for testing .NET Windows Forms applications). It exists also in the version SilkTest International for testing localized applications.

    
 Telelogic TAU/Tester 

TelelogicTAU/Tester is a stand-alone, standards-based dedicated test language tool designed for systems and software applications across multiple industries providing integrated test development and test execution environment based on the internationally standardized language TTCN - 3.
It can be used in different areas/industries as Communications, Military/Aerospace, Transportation.

    
 Parasoft Webking

Parasoft SOAPtest

 Parasoft Webking is a tool for automated testing for Web applications. Performs coding standards, load testing, critical path testing, functional testing & more.
Parasoft SOAPtest is suited for Web services verification. Automates client/server functional testing, regression testing, load/performance testing & more.
    
 Solstice
Integra
Enterprise		 Solstice Integra Enterprise is an Enterprise Integration Testing tool including simulation of unfinished modules or unavailable vendor systems.
    
 Worksoft Certify Worksoft Certify highlights that there is no need to have programmer or technical knowhow: non-technical people can with this tool point and click to document and automate their test cases.
    
 Argogroup Monitor
Master		 Argogroup's Monitor Master is an end-to-end test environment supporting WAP, WML, MMS, SMS, EMS, J2ME and others.
It simulates real users testing mobile services like Text, WAP, Photo-Messages, e-Mail, Ring-Tones, Games, Video, Location, VoIP, Web, Payments, IVR, i-Mode and WiFi
The tool covers not only functional tests, but also load tests, regression tests and real-time monitoring.
    

          OPEN SOURCE

 STAF STAF is an open source software testing automation framework.
    
 Abbot Abbot is framework for automated testing of Java GUI components and programs (including unit test).
    
 Jameleon Jamaleon is an acceptance-level automated testing tool that separates applications into features and allows those features to be tied together independently, creating test-cases. These test-cases can then be data-driven and executed against different environments.
    
 Webinject WebInject is a free tool for automated testing of web applications and services. It can be used to test individual system components that have HTTP interfaces (JSP, ASP, CGI, PHP, Servlets, HTML Forms, etc), and can be used as a test harness to create a suite of [HTTP level] automated functional, acceptance, and regression tests.
    
 Marathon Marathon is a testing framework for GUI applications developed using Java/Swing. It composes of recorder, runner and editor. The testscripts are composed of python code.Marathon focuses on end-user testing.
    
 Jacareto Jacareto is a capture & replay framework for Java applications and applets. It allows you to easily create your own capture & replay tools. With Jacareto you can write your own capture modules, replay modules, classes which handle special components, editors, record types, record elements and tests. You can also group record elements together to build high-level structures (qualitative analysis). By extracting data sets from records, quantitative analyses can be performed.
There are two applications included in the Jacareto software package: CleverPHL and Picorder. CleverPHL is a graphical front-end for Jacareto. Picorder is a small application for the "fast Capture & Replay process".
    
 PGUIRobot Java Test & Replay PGUIRobot is an automated tool for functional and GUI testing Java programs, which can also be used for making canned demonstrations by event and screen capture.
    
 JSystem JSystem is a framework for writing and running automated tests, based on JUnit. Its main goal is to support automation of functional / system testing.
    
 TRecorder TRecorder is a simple free Windows application from Cyamon Software that allows to record and playback keyboard and mouse events.
Events can be saved in events-files. Events-files can be loaded and their events played. Several events-files can be put in batch-files so that they can be played in sequence.
    
 JSpider JSpider is a highly configurable and customizable Web Spider engine developed under the LGPL Open Source license in 100% pure Java. It can be used to:
Check a web site for errors (internal server errors, ...);
Outgoing and/or internal link checking;
Analyze a web site structure (creating a sitemap, ...);
Download complete web sites;
Other tasks, with a plugin.
    
 LinkChecker LinkChecker checks websites and HTML documents for broken links.
    

 

          LOAD TESTING

          COMMERCIAL

 Mercury LoadRunner Mercury LoadRunner is a performance testing product for predicting system behavior and performance. It can emulate hundreds or thousands of concurrent users to put the application through user loads. Simultaneously, LoadRunner collects system and component-level performance information through a comprehensive array of system monitors and diagnostics modules. These metrics are combined into an analysis module that allows to isolate bottlenecks within the architecture.
LoadRunner supports the widest range of enterprise environments and is the only performance testing product to be customized and certified to work with ERP/CRM applications from PeopleSoft, Oracle, SAP, and Siebel.
    
 IBM Rational Performance Tester IBM Rational is an automated load and performance testing tool validating the scalability and reliability of complex e-business applications before deployment.
It Consists of IBM Rational Robot, IBM Rational TestManager and separately purchased packs of virtual testers.
    

          OPEN SOURCE

 OpenSTA OpenSTA is a distributed software testing architecture designed around CORBA, it was originally developed to be commercial software by CYRANO. The current toolset has the capability of performing Web Load Testing (HTTP/HTTPS stress and performance tests) with performance measurements from Win32 platforms. Data Collection includes scripted timers, SNMP data, Windows Performance Monitor stats and HTTP results and timings.
    
 OpenLoad OpenLoad is a tool for load testing web applications. It aims to be easy to use and providing near real-time performance measurements of the application under test.
    
 The Grinder The Grinder is a Java load-testing framework. It is a programmer's load tester, designed for people who understand the code that they're hitting - it's not just a "black box" with a set of associated response time. It comes with a mature plug-in for testing HTTP services, as well as a tool which allows HTTP scripts to be automatically recorded.
    
 TestMaker TestMaker is a utility and framework to build test automation solutions. It solves functionality, scalability, performance, and regression problems in Web-enabled applications, especially Web Services and Service Oriented Architecture (SOA).
It has an integrated test environment and a test agent recorder.
    
 dbMonster DBMonster is a tool which generates random test data and puts it into SQL database. It helps to test how an application can deal with large database.
    
 Network Traffic Generator This tool generates TCP/UDP traffic from client(s) to server(s) to stress test routers/firewalls under heavy network load.


杨粼波 2006-07-24 15:05 发表评论
]]>软件测试自动化的一些具体做法http://www.cppblog.com/tx7do/archive/2006/07/20/10272.html杨粼波杨粼波Thu, 20 Jul 2006 13:59:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10272.htmlhttp://www.cppblog.com/tx7do/comments/10272.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10272.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10272.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10272.html因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。

　　 首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。

　　 下面举出一些测试自动化的例子：

1.测试个案（test case ，或称为测试用例）的生成

　　 用编程语言或更方便的剧本语言（script language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。

　　 这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。

2.测试的执行写控制

　　 单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。

　　 对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。

　　 对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。

　　 如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。

　　 在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。

　　 同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。

3.测试结果与标准输出的对比

　　 在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。

　　 许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。

4.不吻合的测试结果的分析、分类、记录和通报

　　 上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。

　　 “分析”是找出不吻合的地方并指出错误的可能起因。“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。“记录”，是按分类存档。“通报”，是主动地对测试的运行者及测试用例的“负责人”通报出错的信息。

　　 这里提到测试用例的“负责人”的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。

　　 最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。

5.总测试状况的统计，报表的产生

　　 这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。

　　 产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。

6.自动测试与开发中产品每日构建（build ）的配合

　　 自动测试应该是整个开发过程中的一个有机部分。自动测试要依靠配置管理来提供良好的运行的环境，同时它必须要与开发中的软件的构建紧密配合。

　　 在开发中的产品达到一定程度的时候，就应该开始进行每日构建和测试。这种做法能使软件的开发状态得到频繁的更新，以及及早发现设计和集成的缺陷。

　　 为了充分利用时间与设备资源，下班之后进行自动的软件构建，紧接着进行自动测试（这里多数指的是系统测试或回归测试），是一个非常行之有效的方法。如果安排得好，到第二天上班时，测试结果就已经在各人的电子邮箱里面面了，等待着新的一天的开发工作。



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=131405



杨粼波 2006-07-20 21:59 发表评论
]]>测试工具的选择和使用http://www.cppblog.com/tx7do/archive/2006/07/20/10270.html杨粼波杨粼波Thu, 20 Jul 2006 13:58:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10270.htmlhttp://www.cppblog.com/tx7do/comments/10270.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10270.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10270.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10270.html2003年第9期《程序员》上啄木鸟部落发文“测试工具的选择和使用”，现将其中的工具列表摘录，以备忘

Parasoft白盒测试工具集

工具名支持语言环境简介
JtestJava代码分析和动态类、组件测试
JcontractJava实时性能监控以及分析优化
C++ TestC,C++代码分析和动态测试
CodeWizardC,C++代码静态分析
Insure++C,C++实时性能监控以及分析优化
.test.Net代码分析和动态测试

Compuware白盒测试工具集

工具名支持语言环境简介
BoundsCheckerC++,DelphiAPI和OLE错误检查、指针和泄露错误检查、内存错误检查
TrueTimeC++,Java,Visual Basic代码运行效率检查、组件性能的分析
FailSafeVisual Basic自动错误处理和恢复系统
JcheckM$ Visual J++图形化的纯种和事件分析工具
TrueCoverageC++,Java,Visual Basic函数调用次数、所占比率统计以及稳定性跟踪
SmartCheckVisual Basic函数调用次数、所占比率统计以及稳定性跟踪
CodeReviewVisual Basic自动源代码分析工具

Xunit白盒测试工具集

工具名支持语言环境官方站点
AunitAdahttp://www.libre.act-europe.fr
CppUnitC++http://cppunit.sourceforge.net
ComUnitVB,COMhttp://comunit.sourceforge.net
DunitDelphihttp://dunit.sourceforge.net
DotUnit.Nethttp://dotunit.sourceforge.net
HttpUnitWebhttp://c2.com/cgi/wiki?HttpUnit
HtmlUnitWebhttp://htmlunit.sourceforge.net
JtestJavahttp://www.junit.org
JsUnit(Hieatt)Javascript 1.4以上http://www.jsunit.net
PhpUnitPhphttp://phpunit.sourceforge.net
PerlUnitPerlhttp://perlunit.sourceforge.net
XmlUnitXmlhttp://xmlunit.sourceforge.net

主流黑盒功能测试工具集

工具名公司名官方站点
WinRunnerMercuryhttp://www.mercuryinteractive.com
Astra QuicktestMercuryhttp://www.mercuryinteractive.com
RobotIBM Rationalhttp://www.rational.com
QARunCompuwarehttp://www.compuware.com
SilkTestSeguehttp://www.segue.com
e-TestEmpirixhttp://www.empirix.com

主流黑盒性能测试工具集

工具名公司名官方站点
WASM$http://www.micro$oft.com
LoadRunnerMercuryhttp://www.mercuryinteractive.com
Astra QuicktestMercuryhttp://www.mercuryinteractive.com
QaloadCompuwarehttp://www.empirix.com
TeamTest:SiteLoadIBM Rationalhttp://www.rational.com
WebloadRadviewhttp://www.radview.com
SilkperformerSeguehttp://www.segue.com
e-LoadEmpirixhttp://www.empirix.com
OpenSTAOpenSTAhttp://www.opensta.com

测试管理工具典型产品的比较

工具名称TestdirectorClearQuestBMSBugzilla
流程定制YYNY
查询功能定制YYYY
功能域定制YYYY
用户权限分级管理YYYY
Email通知YYYY
构架模式B/SC/S,B/SB/SB/S
报表定制功能Y强,集成Crystal Report有标准报表和高级报表,定制功能不够Y
支持平台WindowsWindows, UnixWindowsLinux, FreeBSD
支持数据库Oracle, M$ Access, SQL Server等Oracle, M$ Access, SQL ServerSQL Server等MSDEMySQL
安装配置的复杂度简单有些复杂容易不复杂
许可证费用昂贵昂贵适中免费
售后服务国内有多家代理公司提供相关服务在国内有分公司提供技术支持技术支持和服务体系完备可自行修改源代码
与其他工具集成本身又是测试需求、测试案例管理工具, 与winRunner, LoadRunner集成，并且具有多种主流Case工具接口Add-In与rational公司的其它产品无缝集成，特别与Clear Case配合以可实现UCM的配置管理体系M$ VSS, Project开源配置管理工具CVS
公司背景世界主流测试软件提供商已被IBM合并,世界著名软件公司微软与上海市政府新成立的软件企业　世界著名开源项目
商业化自动功能测试工具特性比较
特性WinRunnerSilkTestEtester
易于安装是是是，不支持设置代理服务等设置
GUI对象和脚本分离是对象声明在单独的include文件中，但是case脚本中还有包含两者都在VB脚本的case中
toolbar/field定制可以无法定制toolbar,可以定制GUI的fields内容无法定制
操作系统WindowsUnix,WindowsUnix, Windows
浏览器NetScape,IENetScape,IENetScape,IE
支持测试对象HTML,DHTML,java script,VBScript,XML,JAVA applets, ActiveX,VB, PowerBuilder,Delphi,Terminal Emulator,,Oracle,SAP,PeopleSoft, SiebelHTML, DHTML, java script, XML, Java apps and applets, MFC, VB, Oracle, PowerBuilder, Delphi, SAPJava apps and applets in M$JVM/SunJVM, HTML, DHTML, java script, XML, MFC, VB, Oracle, SAP, Delphi, Terminal Emulator, PowerBuilder, Oracle, Peoplesoft
脚本语言TSL第四代面向对象的脚本语言4Test,类似C++提供可编程接口，用户可使用标准语言扩展可视脚本，如VB,C++,Java
脚本调试功能强大类似C＋＋DebuggerVBA Debugger结合Visual Script Debugger
允许数据驱动的测试是是是
自动数据生成支持支持不支持
允许通过数据库验证数据通过ODBC及本地数据库连接自带Database Tester通过ODBC
应用程序改变后的脚本维护直接修改GUImap更新include 文件。自动更新无需录制
数据库支持市场流行的数据库市场流行的数据库市场流行的数据库
无人看管下的自动执行测试通过Testdirector允许允许，通???>??????师?过eTestSuite
分布式测试控制/同步/执行Testdirector支持支持支持
自动创建测试结果日志是是是
非预期错误的恢复允许允许允许
与测试管理工具接口Testdirector自带Case管理功能。e-test suite
图形化设计脚本执行集合通过Testdirector设计不支持通过e-test suite设计
培训有，Onsite及public training有，提供kickoff training有，onsite及public training
技术支持曾获SSPA STAR荣誉很好客户对其评价
License灵活的记费方式，既可以按使用次数计费也可以按协议算永久使用费提供floating以及node-locked两种方式提供Floating以及Node-locked两种方式
价格昂贵较贵一般
Add-in收费部分收费不收费不收费
总论在全球的市场占有率较高，功能全面，价格昂贵在国内的推广还处于起步阶段价格较低，只支持web的测试，在金融、证券、电子商务等领域有广泛应用。


杨粼波 2006-07-20 21:58 发表评论
]]>测试工具WEB大全http://www.cppblog.com/tx7do/archive/2006/07/20/10271.html杨粼波杨粼波Thu, 20 Jul 2006 13:58:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10271.htmlhttp://www.cppblog.com/tx7do/comments/10271.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10271.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10271.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10271.html This tools listing has been loosely organized into the following categories:
Load and Performance Test Tools
Java Test Tools
Link Checkers
HTML Validators
Free On-the-Web HTML Validators and Link Checkers
PERL and C Programs for Validating and Checking
Web Functional/Regression Test Tools
Web Site Security Test Tools
External Site Monitoring Services
Web Site Management Tools
Log Analysis Tools
Other Web Test Tools

(Categories are not well-defined and some tools could have been listed in several categories. Note that the 'Web Site Management Tools' category includes products that contain: site version control tools, combined utilities/tools, server management and optimization tools, and authoring/publishing/deployment tools that include significant site management or testing capabilities. Suggestions for category improvement are welcome; see bottom of this page to send suggestions.)



杨粼波 2006-07-20 21:58 发表评论
]]>软件测试工具集锦http://www.cppblog.com/tx7do/archive/2006/07/20/10268.html杨粼波杨粼波Thu, 20 Jul 2006 13:57:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10268.htmlhttp://www.cppblog.com/tx7do/comments/10268.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10268.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10268.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10268.html阅读全文

杨粼波 2006-07-20 21:57 发表评论
]]>[转帖]TestLink1.6 配置说明 http://www.cppblog.com/tx7do/archive/2006/07/20/10267.html杨粼波杨粼波Thu, 20 Jul 2006 13:54:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10267.htmlhttp://www.cppblog.com/tx7do/comments/10267.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10267.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10267.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10267.html
$g_tpl [ ' tcView ' ] 

 $g_tpl [ ' tcSearchView ' ] 

 $g_tpl [ ' tcEdit ' ] 

 $g_tpl [ ' tcNew ' ] 

 $g_tpl [ ' execSetResults ' ] 
最近抽空学习了一下TestLink1.6，看到Judy写了TestLink1.6的安装文档，我就不重复了，跟一篇配置文档吧，原文在我的blog上，是翻译TestLink1.6的安装配置手册的，（http://blog.csdn.net/yolanda_chung/archive/2006/02/12/597053.aspx），以下我截取了原文的配置章节，要是翻译的不好，请笑我哦！


配置

配置文件
<testlink installation directory>/config.inc.php － 主要的配置文件，后面会做详细介绍

<testlink installation directory>/config_db.inc.php － 包含访问数据库的所有配置参数。这个文件在安装或升级过程中产生。通常不必做手工修改

<testlink installation directory>/cfg/<bug_tracking_system>.cfg.php 

/cfg/bugzilla.cfg.php
/cfg/mantis.cfg.php
/cfg/jira.cfg.php
包含访问bugzilla、mantis或者jira等缺陷跟踪系统的配置参数。如果想从TestLink直接访问这些系统，需要手工修改这些文件，另外这个功能需要在config.inc.php文件中修改一个配置参数。


必须修改的参数
DB_SUPPORTS_UTF8
MySQL4.1以前的版本不支持utf8，因此所有的页面使用ISO-8859-1字符集而数据则以latin1字符集存入数据库，令DB_SUPPORTS_UTF8 = FALSE；
MySQL4.1及以后的版本，令DB_SUPPORTS_UTF8 = TRUE，使全部页面支持UTF-8而数据以utf8字符集存入数据库。


可能需要修改的参数
TL_LOG_LEVEL_DEFAULT
日志记录的缺省级别，日志级别有（NONE、ERROR、INFO、DEBUG）。DEBUG级别只在开发或者与bug系统集成时使用

TL_LOG_PATH
日志文件的文件名和路径

MAIN_PAGE_METRICS_ENABLED
这个参数控制矩阵表格是否显示在主页上，允许“TURE”和“FALSE”两个值

TL_INTERFACE_BUGS
设置testlink和缺陷跟踪系统的接口。允许的值为：“NO”、“BUGZILLA”、“MANTIS”
与BUGZILLA的接口配置参见cfg/bugzilla.cfg.php，支持0.19.1
与MANTIS的接口配置参见cfg/mantis.cfg.php，支持1.0.0.a3

TL_TREE_KIND
这个参数用于配置testlink所使用的树形菜单，允许的值为“LAYERSMENU”、“JTREE”、“DTREE”
LAYERSMENU 是缺省值；在这里，JTREE的性能最好；其他的两种树形菜单，可以记住上一次的位置。

TL_IMPORT_LIMIT
最大可以上传的文件的大小，单位是bytes。缺省值是200000。如果需要上传一个更大的文件，你可以加大这个值。另外还有一个参数：TL_IMPORT_ROW_MAX，用户规定导出文件一行最长可以有多长字符，10000字符已经足够了。

$g_fckeditor_toolbar
定义fckeditor工具条，你可以修改其内容。这个部件的更详细的信息参见fckeditor的主页（http://www.fckeditor.net/）

TL_TPL_CHARSET
中文用户只需要设置：define('TL_TPL_CHARSET','gb2312')；这样就定义了正确的html字符集。其他的语言可以不必修改这个参数

TL_DEFAULT_LOCALE
置缺省语言，必须是$g_locales的一个值。缺省值是en_GB。

TL_COMPANY,TL_DOC_COPYRIGHT，TL_DOC_CONFIDENT
用于文档抬头，如果不用写抬头，就置这些参数为空。

自定义参数

级联样式表
可以编写你自己的级联样式表改变TestLink的外观。
你必须修改以下定义：

define('TL_LOGIN_CSS','gui/css/tl_login.css'); - 登录、登出的CSS文件

define('TL_TESTLINK_CSS','gui/css/testlink.css'); - 主页的CSS文件

define('TL_DOC_BASIC_CSS','gui/css/tl_doc_basic.css'); - 用于测试报告


重要：CSS文件的路径是相对于<TestLink的安装目录>的路径，是相对路径

如果要使用自己的CSS文件，建议进行如下操作：

1. 在gui目录下创建一个新的目录，例如 “gui/css/my_css/”
2. 复制testlink原文件到新的目录
3. 按你的想法修改它们
4. 编辑config.inc.php文件：
  // Original configuration 
  //define('TL_LOGIN_CSS','gui/css/tl_login.css'); 
  //define('TL_TESTLINK_CSS','gui/css/testlink.css'); 
  //define('TL_DOC_BASIC_CSS','gui/css/tl_doc_basic.css'); 
  define('TL_LOGIN_CSS','gui/css/my_css/tl_login_acqua.css'); 
  define('TL_TESTLINK_CSS','gui/css/my_css/testlink_acqua.css'); 
  define('TL_DOC_BASIC_CSS','gui/css/my_css/tl_doc_basic.css');




当产品、部件、分类、测试用例重名时的处理


当从一个已经复制一个产品、部件、分类、测试用例时，经常会发生重名的情况。
你可以配置如何处理复制：
如果你设置$g_check_names_for_duplicates=TRUE，那么系统就会进行以下的检查

1. 产品名是否唯一
2. 产品下的部件名是否唯一
3. 部件下的分类名是否唯一
4. 分类下的测试用例名是否唯一

一旦置$g_check_names_for_duplicates=TRUE，你可以配置如果进行操作，如果发现重名的情况，就使用$g_action_on_duplicate_name，选项如下：

'allow_repeat'：允许重名（可以和1.0.4、1.5.x兼容）
'generate_new'：生成新名称，将"$g_prefix_name_for_copy"的值和原名合并，成为一个新名字
'block'：返回一个错误

例如：

$g_action_on_duplicate_name='allow_repeat';
$g_prefix_name_for_copy= strftime("%Y%m%d-%H:%M:%S", time());

允许重复，并将当前时间以（年月日－时分秒）的格式做为原来的名字的前缀。

测试计划和产品的关联
从1.6版开始，当创建一个测试计划（Test Plan）时，缺省情况下测试计划会和当前所选择的产品相关联。这意味着你可以以产品为关键字过滤测试计划（Test Plan）。在1.6版本之前，Test Plan没有和指定的产品相关联，当从1.5.x升级到1.6时，安装程序不能将测试计划和产品相关联从而将测试计划的product ID项置为0。这样做将导致老的测试计划将不能被看到。要解决这个问题，必须添加以下参数：

$g_show_tp_without_prodid=TRUE;

你也可以通过在数据库中手工关联，以便使用以前的数据。

通过产品过滤测试计划
使用以下参数：

$g_ui_show_check_filter_tp_by_product

你可以：

允许用户通过界面来使能测试计划过滤功能。$g_ui_show_check_filter_tp_by_product = TRUE时，在测试计划之前显示了一个复选框。
$g_ui_show_check_filter_tp_by_product = FALSE时。强制测试计划的过滤，并且用户不能修改

关键字管理
如果不想为同一个产品创建相同的关键字：

$g_allow_duplicate_keywords=FALSE;

日期和时间本地化
设置日期和时间的显示方式。使用两个关联的数组进行配置：$g_locales_date_format 和
$g_locales_timestamp_format.

$g_locales_date_format = array(
'en_GB' => "%d/%m/%Y", 'it_IT' => "%d/%m/%Y", 
'es_AR' => "%d/%m/%Y", 'es_ES' => "%d/%m/%Y",
'de_DE' => "%d.%m.%Y", 'fr_FR' => "%d/%m/%Y",
'pt_BR' => "%d/%m/%Y" ); 

$g_locales_timestamp_format = array(
'en_GB' => "%d/%m/%Y %H:%M:%S", 
'it_IT' => "%d/%m/%Y %H:%M:%S",
'es_AR' => "%d/%m/%Y %H:%M:%S",
'es_ES' => "%d/%m/%Y %H:%M:%S",
'de_DE' => "%d.%m.%Y %H:%M:%S",
'fr_FR' => "%d/%m/%Y %H:%M:%S",
'pt_BR' => "%d/%m/%Y %H:%M:%S", );
　

如果在上述数组中没有找到匹配的本地化格式，以下配置参数将被使用：$g_date_format 和 $g_timestamp_format

例如：

$g_date_format ="%d/%m/%Y";
$g_timestamp_format = "%d/%m/%Y %H:%M:%S";

从需求生成测试用例
在创建需求SRS之后，可以选择为每个测试需求创建测试用例（部件和分类也同时被创建）

使用配置参数：$g_reg_cfg,你可以配置：

创建的部件的名字：$g_req_cfg->default_component_name="Component Created by Requirement - Auto";
部件的范围：$g_req_cfg->scope_for_component="Component/Category/Test Cases generated from Requirements";
创建的分类的名字：$g_req_cfg->default_category_name="TODO";
分类的目标描述：$g_req_cfg->objective_for_category="Category/Test Cases generated from Requirements";
分类的名字可以作如下配置：

$g_req_cfg->use_req_spec_as_category_name=TRUE;
将需求名称做为分类名称
$g_req_cfg->use_req_spec_as_category_name=FALSE;
那么$g_req_cfg->default_category_name将做为分类的名称
使用自己的Smarty模板（GUI定义）
使用自定义模板，要用到以下参数：$g_tpl



允许创建新的模板，而且新的模板采用不同于原始TestLink模板的名字，以避免在下次升级过程中被覆盖

注意：不是所有的TestLink页面都可以进行这样的配置

标准配置如下：

$g_tpl [ ' tcView ' ]  =   " tcView.tpl " ; 
 $g_tpl [ ' tcSearchView ' ]  =   " tcSearchView.tpl " ; 
 $g_tpl [ ' tcEdit ' ]  =   " tcEdit.tpl " ;
 $g_tpl [ ' tcNew ' ]  =   " tcNew.tpl " ;
 $g_tpl [ ' execSetResults ' ]  =   " execSetResults.tpl " ;



杨粼波 2006-07-20 21:54 发表评论
]]>CSV文件及其使用http://www.cppblog.com/tx7do/archive/2006/07/20/10266.html杨粼波杨粼波Thu, 20 Jul 2006 13:48:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10266.htmlhttp://www.cppblog.com/tx7do/comments/10266.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10266.html#Feedback1http://www.cppblog.com/tx7do/comments/commentRss/10266.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10266.html    在集图的过程中，你肯定会常常听到CSV文件这个词。那么所谓CSV文件到底是个什么东西呢？ 它有什么用处呢？又要如何使用呢？认真读完下面的文字，相信你对CSV会有一个初步的了解。
    所谓“CSV”，是Comma Separated Value（逗号分隔值）的英文缩写，通常都是纯文本文件。 下面是一个实际CSV文件中的部分内容，让大家对他有一个感性的认识。我们选的是Sjojo_Rescan 的CSV文件(Sjojo是ASW-亚洲扫图风的成员之一)。
sj_mino1001.jpg,715282,4FB55FE8,
sj_mino1002.jpg,471289,93203C5C,
sj_mino1003.jpg,451929,C4E80467,   
通常CSV文件开头是不留空的，以行为单位，每行中记录一张图片的了多项数据，每项数据用逗号 来分隔（标准英文逗号）。一般说来集图用的.CSV文件的格式是这样的：
文件名,文件大小(以字节为单位),CRC校验值,注释(可省略)
sj_mino1001.jpg,715282,4FB55FE8,
     |             |       |        |
   文件名      文件大小  CRC值   注释(已省略)     
如果你的机器上装了Microsoft Excel的话，.csv文件默认是被Excel打开的。需要注意的是，当你 双击一个.CSV文件，Excel打开它以后即使不做任何的修改，在关闭的时候Excel往往会提示是否要 改成正确的文件格式，这个时候千万记得要选择“否”。因为Excel认为.CSV 文件中的数字是要用 科学记数法来表示的，而我们要的.CSV文件中的数字是普通的。如果你选择了“是”的话，Excel
会把CSV文件中所有的数字用科学计数来表示（2.54932E+5这种形式），这个文件就没法用了。 所 以如果你的CSV文件绝大部分都是用在集图上的话，建议把.CSV的默认打开方式改成任意一个文本 编辑器，系统自带的记事本就是个不错的选择。
    好，让我们回到CSV文件的格式中来。见上面，从左到右 sj_mino1001.jpg是文件名，715282 是以字节表示的文件大小。当文件名中包含逗号的时候，由于逗号在CSV文件中特殊的作用，为了 不至于产生歧义，需要用引号把文件名括起来。比如 "The Art, Fantasy.jpg",384211,...,.... 接着是一个8位的16进制数字 4FB55FE8，这是文件的CRC32校验值。整个CSV文件的精髓都在这里。
让我们举个小例子来说明它的意义：Sjojo发布了一张图sj_mino1001.jpg，假设你是从朋友手中拿 到这张图的，那么你肯定常常会有这样的疑问，这张图在传播的过程中是否被改动过呢？是否无意 中遭到了损坏呢？CRC就是为解决这个问题而存在的。一般情况下，扫图家每发布了一套图，就同 时放出一个CSV文件（这种CSV通常叫做Official CSV，也就是官方发布的CSV的意思），这个CSV中 的CRC值是用专门的软件通过CRC32算法（常用的CRC算法还有CRC16）对文件运算后生成的一个值， 这个值可用作文件真身的标志。在绝大多数情况下，如果这个文件在传播过程中无论是大小还是内 容被改动过。那么，用同样的CRC32算法再对文件进行运算后产生的CRC校验值就完全不一样了。如 果得出的CRC值是一样的，则完全有理由认为这个文件是真身，没有被改动过。还有些时候，收来 的图片文件名被改动过了，那么你怎么知道谁是谁呢？这个时候CRC值又起作用了：用专用的软件对图片处理后，可以得到文件的大小和CRC值，然后根据大小和CRC值在CSV中寻找是否有适合的图片。如果有，就会把图片的名字改成CSV里的。举个例子，你收到了一张图片，名字是pic0001.jpg，同时你知道这张图片是Sjojo_Rescan这个集子里面的，但是不知道具体是哪一张。用软件得到它的大小和CRC分别是715282和4FB55FE8，那么软件在CSV文件里找到一行sj_mino1001.jpg,715282,4FB55FE8,大小和CRC都符合，软件就认为这张图片的原名是sj_mino1001.jpg，接着自动把文件的名字改成sj_mino1001.jpg。改动的不是CSV文件而是图片的文件名。接下来的是注释和说明，可以省略掉。需要注意的是注释的后面是没有逗号的，如果要省略注释的话，一定要在CRC值的后面保留一个逗号，否则软件会把CRC值认为是注释的。
    相信看完上面的一大堆东西后，你不但对CSV文件有了个大概地了解，对它的用途应该也有些模糊的概念了吧。我们收集图片往往是通过各种各样不同的渠道，比如从网站上，IRC上，抑或干脆是朋友送的光盘。在整个的传播过程中，图片有可能遭受到各种各样的非人待遇。尤其是从网站上收来的图片。有些时候仅仅是简单的改了一下名字，更多的时候由于很多PLMM站空间有限，常把图片的尺寸缩小，或者把图片文件缩小。一张1356x588的图被改成了678x294，或者一个四五百K的文件被缩成了几十K都是常有的事。比较可恶的是，许多网站把原来扫图家的Logo去掉，打上自己网站的Logo。还有些许搞笑派的玩家，把各种各样的图片移花接木，改头换面。这些对于一般的看
图娱乐无伤大雅，但是对于集图来说，收到这样的图片是无法容忍的。如何验明图片的正身，这是扫图家和集图者共同面对的问题。CSV文件就是为了解决这样的问题而出现的。CSV文件最早用在简单的数据库里，由于其格式简单，并具备很强的开放性，所以起初被扫图家用作自己图集的标记。 如上面所说的，CSV文件是个纯文本文件，每一行表示一张图片的许多属性。你在收一套图集时，只要能找到它的CSV文件，用专用的软件校验后，你对该图集的状况就可以了如指掌。比如这套图一共有多少张，你收到了多少张，哪些是原图，那些是可能被改动过或者损坏了的图片......我们可以把.CSV文件看作一份索引，你不但可以“按图索骥”，还可以检查自己收来的“马子”血统是 否纯正。
    CSV文件的来源通常有两种：一种是扫图家自己发布的CSV，一般称作Official CSV。也就是官方发布的CSV，通常说来是有相当的权威性的。比较特殊的是亚洲的许多扫图家，除了公开发布的图以外，还有一些私下发布的Special图，或者一些专门送给朋友的图。加上扫图家不愿意或者不会做CSV，所以他们图集的CSV往往由集图界中一些资深前辈出头来做。在这种情况下，往往会出现一个图集有好几个版本的CSV文件，并且每个版本之间都有不小的差别。此时的CSV不仅是验明真身的依据，同时也给了集图者一个希望：即使缺的再多，即使用这个版本csv收全的人再少，一定会有一个人是全的，就是此CSV的作者！集图界前辈LiQing有一句名言：“有CSV就表示一定有图！” 自然而然的，民间现了一些权威的做CSV的玩家。比如早期的EDZONE，现在依然活跃的OSun,shum,vsam,TE,Paul... 还有偶们COC图盟的WQC  
    好了，说了那么多，大家可能会问，CSV文件那么好用，到底要怎么用呢？不会要自己手工来检测吧？呵呵，还记得上文中一再出现的“软件”这个字眼吗？有专用的软件可以帮助我们完成这项工作。常用的软件有The!Checker和The Hunter。目前这两个软件都有汉化的简体中文版，汉化人是来自北方的snowtank（感谢snowtank  ）



杨粼波 2006-07-20 21:48 发表评论
]]>[转帖]TestLink1.6.0安装说明 http://www.cppblog.com/tx7do/archive/2006/07/20/10265.html杨粼波杨粼波Thu, 20 Jul 2006 13:47:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/20/10265.htmlhttp://www.cppblog.com/tx7do/comments/10265.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/20/10265.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/10265.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/10265.html本文引自Judy Shen的专栏，原文地址：http://blog.csdn.net/judyxm/archive/2006/01/12/577148.aspx

TestLink1.6.0安装说明

Judy Shen

TestLink是基于Web的，开源的测试管理和执行系统。它可以让测试团队在创建和管理测试用例的同时，在测试计划中对测试用例进行组织。TestLink可以和Bugzilla、Mantis、Jira等缺陷管理工具进行集成。因为网上TestLink的资料很少，考虑到测试用例的管理对于测试过程的有效开展很重要，所以，笔者把在安装TestLink1.6.0中碰到的问题及安装过程的注意事项进行了总结，供同行参考。
本文不包括对TestLink的优化及使用说明的介绍，这部分内容将在《TestLink1.6.0使用说明》中进行描述。
本文适用于对PHP、Apache、MySQL不熟的读者。本文的描述适用于在windows上的安装。
1介绍
TestLink目前最新的版本是1.6.0，它的运行需要一些应用程序的支持。TestLink开发团队推荐的环境配置为：MySQL4.1.x＋php4.3.x和更高的版本（php5不支持但估计也可以运行）＋Webserver（Apache1.3.x或2.0.x，IIS3等）。这里要强调php和MySQL的版本问题，在TestLink1.6.0的环境搭建上，高版本不兼容低版本的php和MySQL。笔者刚开始时使用的环境配置为：PHP5.1.1＋MySQL5.0.18＋Apache2.0.55，但是经过努力，笔者发现对于1.6.0版本的TestLink，在WinXP下无法是使用这个环境配置将TestLink安装并正确运行。所以，笔者推荐的环境配置为：PHP4.4.1＋MySQL4.1.16＋Apache2.0.55。
下面我对这些应用程序的安装与配置步骤分别进行描述。

2安装Apache2.0.55
Apache2.0.55安装程序可在Apache网站http://httpd.apache.org/下载。2.0.55版本的下载地址为：
http://dla.pchome.net/internet/server/web/apache_2.0.55-win32.msi

Apache的安装只需要按照安装界面的步骤进行即可。这里需要说明的是，如果你的机器上安装了其它web服务器，或者说你机器上的80端口已经被占用的话，那么安装时Apache服务不会成功创建。对于这个问题，有两个解决办法：
1．将机器上的其它web服务器占用80端口的服务暂停
2．虽然服务创建不成功，但是其它组件均已经安装了。可以修改Apache配置文件，<ApacheDir> \Apache2\conf\httpd.conf，将80端口改为其它端口，如8080。然后重新运行安装程序即可。
安装Apache后，在任务栏的托盘上会显示Apache的图标。如果安装成功的话，在浏览器输入htpp://yoursite（如http://172.16.111.39:8080），会进入Apache测试界面。

3安装PHP4.4.1
PHP有两种形式的安装包，一种是压缩包的方式，需要手工配置；另一种是安装包的方式，安装时自动配置IIS，PWS和Xitami，但是可扩展性较差。所以一般是建议下载压缩包，手工配置PHP。下面的安装步骤针对压缩包方式。
PHP4.4.1压缩包可在php网站http://www.php.net/上下载。4.4.1版本的下载地址为：
http://cn2.php.net/get/php-4.4.1-Win32.zip/from/cn.php.net/mirror

以下安装步骤都是针对PHP4，PHP5的安装步骤和它有些不同。PHP4安装步骤如下：
1.将压缩包解压缩到C:\PHP，可以选择其它的路径但最好不要用中间有空格的路径（例如：C:\Program Files\PHP就不太好），如果这样做有些 web 服务器会崩溃。
2.将位于dlls和sapi文件夹中的文件移动到主文件夹中（例如 C:\PHP）
下面两个服务器模块是后面的步骤中要用到的：
     。sapi/php4activescript.dll - ActiveScript 引擎，允许将 PHP 嵌入 Windows 应用程序中。
     。sapi/php4apache2.dll - Apache 2.0.x 模块。
3.将 PHP 目录添加到PATH环境变量中，目的是为了让CGI和web服务器模块需要使用的php4ts.dll文件能正确被搜索到，同时便于将来升级 PHP。
4.（可选）如果在 Windows NT、2000、XP 或 2003 中使用 NTFS 分区，确认运行 web 服务器的用户有权限读取 php.ini（例如将其设置为Everyone 可读）
5.将php.ini-recommended拷贝到c:\php目录下，重命名为php.ini
6.（可选）编辑新的 php.ini 文件。如果计划使用 OmniHTTPd，不要执行下一步。设置 doc_root 并指向 web 服务器的 doc_root。例如：
doc_root = c:\inetpub\wwwroot // for IIS/PWS
doc_root = c:\apache\htdocs // for Apache
7.注册动态链接库。准备好全部所需文件后，必须在系统中注册 DLL。做法是打开命令提示行窗口（位于开始菜单），然后输入类似cd C:\php的命令进入 PHP 目录，最后输入regsvr32 php4activescript.dll注册该 DLL。
要测试ActiveScript是否正确工作，请创建一个新文件，命名为 test.wsf（这个扩展名很重要）然后输入：
<job id="test">
<script language="ActivePHP">
$WScript->Echo("Hello World!");
</script>
</job>
保存并双击这个文件。如果您看到一个小窗口，内容为“Hello World!"，说明安装成功。
8.将PHP集成到Apache 2.0。以Apache模块方式安装，将以下两行加入到 Apache 的 httpd.conf 配置文件中，用来设定Apache 2.0的 PHP 模块：
# 对 PHP 4 用这两行：
LoadModule php4_module "c:/php/php4apache2.dll"
# 别忘了从 sapi 目录中把 php4apache2.dll 拷贝出来！
AddType application/x-httpd-php .php

# 配置 php.ini 的路径
PHPIniDir "C:/php"
注：记得用自己 PHP 实际所在的路径替换掉上例中的 c:/php/。要留意在 LoadModule 指令中用的是 php4apache2.dll，而不是 php4apache.dll，后者是设计用于 Apache 1.3.x 的。
注：记住在 Windows 下给 Apache 的配置文件中加入路径值的时候，所有的反斜线例如 c:\directory\file.ext 必须转换成正斜线，如 c:/directory/file.ext。
9.验证PHP是否正确安装。现在已经完成了 PHP 的配置，我们在命令行提示窗口执行一个简单的脚本，以测试安装。下面的代码是一个简单的 PHP 脚本，用于测试您的PHP环境。
<!-- begin of test.php-->
<?php phpinfo(); ?>
<!--end of script-->
将上述代码复制到一个名为test.php的文件中，并将它保存在 PHP 主目录中。在命令行提示窗口下，输入php c:\php\test.php >1.txt（因为输出内容较多，所以将输出结果保存到文本文件）。界面上会显示PHP的环境信息。
你也可以将上面刚刚创建的 test.php 文件复制到 Web 服务器的 htdocs 目录下。然后打开浏览器，输入 http://yoursite/test.php，例如： http://172.16.111.39:8080/test.php，界面上将显示PHP的版本信息。
10.设置Session存储路径。修改php.ini文件，设置session.save_path = C:\windows\temp 。默认路径是UNIX上的写法，在Windows上不能正常工作。

4安装MySQL4.1.16
MySQL4.1.16安装程序可在MySQL网站http://dev.mysql.com下载。4.1.16版本的下载地址为：
http://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-4.1.16-win32.zip/from/http://mirror.vmmatrix.net/mysql/

MySQL的安装步骤比较简单，按照安装界面的默认设置逐步执行即可。注意以下几点：
1.数据库编码选择utf-8编码，避免中文发生乱码现象。
2.root帐号是否选择修改密码。Root初始密码为空，在安装界面中默认是要修改密码的。
3.是否允许root远程访问数据库。安装界面默认不允许root帐号远程访问数据库。
4.如果服务器上启用了防火墙，那么需要在防火墙设置中添加一个例外端口，如端口号为3306。

5安装TestLink1.6.0
TestLink1.6.0的安装包可在TestLink网站http://testlink.sourceforge.net/docs/testLink.php 下载。1.6.0版本的下载地址为：
http://nchc.dl.sourceforge.net/sourceforge/testlink/testlink_1_6_0.zip

在安装TestLink1.6.0前，需要完成以下步骤：
1.安装运行所需要的环境：Webserver、php4和MySQL。可以参照前面的介绍进行安装。
2.将TestLink安装包保存到服务器
3.将TestLink安装包解压缩到Apache2的htdocs目录下，并重命名为testlink

TestLink的安装有两种方式，一是自动安装，二是手工安装的方式。
5.1自动安装
1.在浏览器输入访问地址http://yoursite/testlink/install/index.php，如：http://172.16.111.39:8080/testlink/install/index.php
2.选择new install，在进入的页面中，输入登录MySQL的用户名和密码，如root，如果没有为TestLink新建一个专用的用户，也可以输入初始用户root。但是因为root权限过多，所以，建议为TestLink新建专用的用户，并为该用户赋予ALTER、SELECT、INSERT、UPDATE、INDEX、CREATE、DELETE和DROP权限。操作的sql语句见手工安装的步骤4
3.提示安装成功。系统为testlink创建一个默认管理员账号，用户名和密码为：admin/admin。你可以使用这个账号访问TestLink

在自动安装过程中，安装程序主要做了以下事情：
1.检查web server的参数、php配置、数据库版本
2.创建数据库和表，并导入初始数据
3.在完成安装后，系统会为testlink创建一个数据库配置文件config_db.inc.php。

5.2手工安装
你也可以通过手工的方式来完成TestLink的安装。安装步骤如下：
1.打开命令行窗口，输入：mysql –uroot –proot（注：假设安装MySQL时将root帐户的密码修改为root），进入MySQL
2.创建数据库。mysql> create database testlink;
3.使用新创建的testlink数据库。mysql> use testlink;
4.创建用户，并赋予适当的权利。
mysql> grant select,insert,update,alter,index,create,delete,drop on testlink.* to tl@"%" identified by "123456";
mysql> grant select,insert,update,delete,index,drop,create,alter on testlink.* to tl@"localhost" identified by "123456";
如果不加上后面这句话，新建的用户只能用IP地址访问本机，而不用用localhost的方式来访问本机。
5.修改root和新创建的tl帐号的密码。这个步骤主要是因为4.1版本后的MySQL使用了基于不同的密码算法的认证协议。如果服务器更新了版本，但是客户端API没有相应更新，就会出现认证失败的情况。这个情况可以通过执行以下sql语句来解决。
mysql> update mysql.user set password = OLD_PASSWORD('root') where host = 'localhost' and user = 'root';
mysql> update mysql.user set password = OLD_PASSWORD('123456') where host = '%' and user = 'tl';
mysql> flush privileges;
记得用实际的用户的信息替换上述的“user”、“host”信息。“OLD_PASSWORD”后面的括号内输入新的密码。
最后一句命令flush privileges的意思是强制刷新内存授权表，否则用的还是缓冲中的口令，这时非法用户还可以用root用户及空口令登陆，直到重启MySQL服务器。
6.切换用户，使用tl用户。使用quit命令退出mysql，然后再次执行步骤2和步骤4，只是此时的root用户信息改为tl用户
7.执行数据库初始化语句。依次将<Apache Install Dir>\ Apache2\htdocs\testlink\install\sql\文件夹下的testlink_create_tables.sql和testlink_create_default_data.sql的内容在MySQL内执行。
8.创建TestLink数据库配置文件。参照下面的代码创建<testlinkdir>/config_db.inc.php文件
<?php // Automatically Generated by TestLink Installer
define('DB_TYPE', 'mysql');
define('DB_USER', 'tl_16');
define('DB_PASS', 'tl_16');
define('DB_HOST', 'localhost'); //建议使用IP地址来代替localhost
define('DB_NAME', 'tl_16');
?>
9.打开浏览器，输入：http://172.16.111.39:8080/testlink/index.php，可以打开TestLink登陆界面。建议使用IP地址，而避免使用localhost。如果使用IP地址，在步骤9定义的配置文件中，DB_HOST也要用IP地址替换。

无论是自动安装还是手工安装，安装成功后，要将安装目录下的install目录移走，并在系统中修改admin的初始密码。

6小结
TestLink1.6.0的安装过程如上面介绍的步骤进行。更多的信息可以访问testlink网站（http://testlink.sourceforge.net/docs/testlink.php），也可以在TestLink网站的论坛（http://www.testlink.org/tiki/tiki-forums.php）中获取更多的信息。另外，如果不想安装，只想使用TestLink，那么也可以访问TestLink网站上的Demo（http://testlink.org/demo/index.php）。

7参考资料
《TestLink 1.6 Installation & Configuration Manual》 TestLink Development Team
《MySQL 5.0 Reference Manual》
（http://dev.mysql.com/doc/refman/5.0/en/old-client.html） MySQL AB.
《PHP手册》（http://php.benscom.com/manual/zh/install.windows.php）The PHP Group

杨粼波 2006-07-20 21:47 发表评论
]]>界面设计与测试规则http://www.cppblog.com/tx7do/archive/2006/07/05/9466.html杨粼波杨粼波Wed, 05 Jul 2006 14:41:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9466.htmlhttp://www.cppblog.com/tx7do/comments/9466.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9466.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9466.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9466.html
    目前流行的界面风格有三种基本方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
    1：易用性：
    按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

    易用性细则：
    1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
    2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
    3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
    4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
    5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
    7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
    8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
    9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
    10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
    11):复选框和选项框按选择几率的高底而先后排列。
    12):复选框和选项框要有默认选项，并支持Tab选择。
    13):选项数相同时多用选项框而不用下拉列表框。
    14):界面空间较小时使用下拉框而不用选项框。
    15):选项数叫少时使用选项框，相反使用下拉列表框。
    16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

    2： 规范性：
    通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。

    规范性细则：
    1):常用菜单要有命令快捷方式。
    2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    3):菜单前的图标能直观的代表要完成的操作。
    4):菜单深度一般要求最多控制在三层以内。
    5):工具栏要求可以根据用户的要求自己选择定制。
    6):相同或相近功能的工具栏放在一起。
    7):工具栏中的每一个按钮要有及时提示信息。
    8):一条工具栏的长度最长不能超出屏幕宽度。
    9): 工具栏的图标能直观的代表要完成的操作。
    10):系统常用的工具栏设置默认放置位置。
    11):工具栏太多时可以考虑使用工具箱。
    12):工具箱要具有可增减性，由用户自己根据需求定制。
    13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
    14):状态条要能显示用户切实需要的信息，常用的有：
        目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，
        如果某一操作需要的时间较长，还应该显示进度条和进程提示。
    15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
    16):状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
    17):菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
    18):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
    19):右键快捷菜单采用与菜单相同的准则。

    3：帮助设施：
    系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

    帮助设施细则：
    1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
    2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
    3):操作时要提供及时调用系统帮助的功能。常用F1。
    4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    5):最好提供目前流行的联机帮助格式或HTML帮助格式。
    6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
    7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
    8):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

    4：合理性：
    屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

    合理性细则：
    1):父窗体或主窗体的中心位置应该在对角线焦点附近。
    2):子窗体位置应该在主窗体的左上角或正中。
    3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
    4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
    5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
    6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
    7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    8):非法的输入或操作应有足够的提示说明。
    9):对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
    10):提示、警告、或错误说明应该清楚、明了、恰当。

    5：美观与协调性：
    界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
    美观与协调性细则：
    1):长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
    2):布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
    3):按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
    4):按钮的大小要与界面的大小和空间要协调。
    5):避免空旷的界面上放置很大的按钮。
    6):放置完控件后界面不应有很大的空缺位置。
    7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
    8):前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
    9):如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
    10):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    11):界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
    12):如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
    13):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
    14):通常父窗体支持缩放时，子窗体没有必要缩放。
    15):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

    6：菜单位置：
    菜单是界面上最重要的元素，菜单位置按照按功能来组织。

    菜单位置细则：
    1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
    2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
    3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
    4):一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
    5):没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
    6):如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
    7):菜单深度一般要求最多控制在三层以内。
    8):对常用的菜单要有快捷命令方式，组合原则见8。
    9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
    10):菜单前的图标不宜太大，与字高保持一直最好。
    11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
    12):主菜单数目不应太多，最好为单排布置。

    7：独特性：
    如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    独特性细则：
    1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
    2):主界面，最好是大多数界面上要有公司图标。
    3):登录界面上要有本产品的标志，同时包含公司图标。
    4):帮助菜单的“关于”中应有版权和产品信息。
    5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

    8：快捷方式的组合
    在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。

    菜单中：
    1):面向事务的组合有:
        Ctrl-D 删除
        Ctrl-F 寻找
        Ctrl-H 替换
        Ctrl-I 插入
        Ctrl-N 新记录
        Ctrl-S 保存
        Ctrl-O 打开

    2):列表:
        Ctrl-R   刷新
        Ctrl-G   定位
        Ctrl-Tab 下一分页窗口或反序浏览同一页面控件

    3):编辑:
        Ctrl-A 全选
        Ctrl-C 拷贝
        Ctrl-V 粘贴
        Ctrl-X 剪切
        Ctrl-Z 撤消操作
        Ctrl-Y 恢复操作

    4):文件操作:
        Ctrl-P 打印
        Ctrl-W 关闭

    5):系统菜单
        Alt-A 文件
        Alt-E 编辑
        Alt-T 工具
        Alt-W 窗口
        Alt-H 帮助

    6):MS Windows保留键:
        Ctrl-Esc 任务列表
        Ctrl-F4 关闭窗口
        Alt-F4 结束应用
        Alt-Tab 下一应用
        Enter 缺省按钮/确认操作
        Esc 取消按钮/取消操作
        Shift-F1 上下文相关帮助
    按钮中：
    可以根据系统需要而调节，以下只是常用的组合。
        Alt-Y 确定(是)
        Alt-C 取消
        Alt-N 否
        Alt-D 删除
        Alt-Q 退出
        Alt-A 添加
        Alt-E 编辑
        Alt-B 浏览
        Alt-R 读
        Alt-W 写
    这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母（不推荐）。

    9:安全性考虑：
    在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
    如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

    安全性细则：
    1):最重要的是排除可能会使应用非正常中止的错误。
    2):应当注意尽可能避免用户无意录入无效的数据。
    3):采用相关控件限制用户输入值的种类。
    4):当用户作出选择的可能性只有两个时,可以采用单选框。
    5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    6):当选项特别多时，可以采用列表框，下拉式列表框。
    7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    11):对错误操作最好支持可逆性处理，如取消系列操作。
    12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    13):对可能造成等待时间较长的操作应该提供取消功能。
    14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。（此外，还要注意全角和半角符号的区别）
    15):与系统采用的保留字符冲突的要加以限制。
    16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
    17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

    10:多窗口的应用与系统资源：
    设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
    应用细则：
    1): 在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
    2):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
    3):关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
    4):尽量防止对系统的独占使用。

杨粼波 2006-07-05 22:41 发表评论
]]>测试Linux的可靠性http://www.cppblog.com/tx7do/archive/2006/07/05/9467.html杨粼波杨粼波Wed, 05 Jul 2006 14:41:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9467.htmlhttp://www.cppblog.com/tx7do/comments/9467.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9467.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9467.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9467.html来自DevelopWorks

本文记录了 Linux 内核和其他核心 OS 组件的测试结果与分析，从库和设备驱动程序到文件系统和网络，测试范围无所不含，所有的测试都是在相当不利的条件下进行，并且经历了很长的时间。IBM Linux Technology Center 刚刚结束了这次长达三个多月的全面测试，并将他们的 LTP (Linux Test Project) 测试结果与 developerWorks 的读者共享。
IBM Linux Technology Center (LTC) 成立于 1999 年 8 月，想让 Linux 成功的共同梦想使其与 Linux 开发团体直接合作。它的 200 多名员工使之成为开放源代码开发者的较大团队组织之一。他们提供的代码范围包括，从补丁到结构化的内核改变，从文件系统和国际化工作到 GPL'd 驱动程序。他们还致力于追踪 IBM 内部进行的 Linux 相关开发。
LTC 尤其感兴趣的领域是 Linux 可扩展性、适用性、可靠性和系统管理 —— 所有的目的都是为了使 Linux 更适用于企业。他们为 Linux 团体所做出了诸多贡献，包括使 Linux 可以工作于 S/390 主机，将 JFS 日志文件系统移植到 Linux，等等。
LTC 的另一项核心任务是，以测试商业项目的方式在实验室条件下对 Linux 进行专业的测试。LTC 与 SGI、OSDL、Bull 和 Wipro Technologies 一道促成了 LTP Linux 测试项目（LTP）。下面是经过 LTP 套件在 Linux 内核上超长时间全面测试得到的结果。如您所猜，Linux 极好地承受了持续的压力的考验。
测试结果一瞥
下面的总结基于运行期间的测试和观察结果：
Linux 内核和其他核心 OS 组件 —— 包括库、设备驱动程序、文件系统、网络、IPC 和内存管理 —— 运转稳定并完成了所有期望的运行期间，没有任何严重的系统故障。
每次运行的成功率都很高（超过 95%），只有极少数的期望中的间歇故障，而这些故障是设计用来使资源过载的测试同时执行的结果。
Linux 系统性能在长时间的运行中没有下降。
在 SMP 系统上，Linux 内核正确地扩展以使用硬件资源（CPU、内存、硬盘）。
Linux 系统可以很好地承受 CPU 持续满负荷运转（超过 99%）和极重内存压力。
Linux 系统正确地处理了过载的情况。
测试证明了 Linux 内核和其他核心组件在 30 天、60 天、90 天内是可靠的稳定的，可以为用户提供一个长时间运行的健壮的、企业级的环境。

Linux 可靠性度量
目标
对 IBM Linux Technology Center 来说，Linux 可靠性工作的目标是，使用 LTP 测试套件对 Linux 操作系统进行超长时间的测试，重点在于 Linux 用户环境相关的工作负荷（参阅 参考资料 以深入了解 LTP）。而并不是致力于证明缺陷。
测试环境概述
本文描述的是使用 LTP 测试套件进行的 30 天与 60 天的 Linux 可靠性度量测试的测试结果和分析。测试以 SuSE Linux Enterprise Server v8 (SLES 8) 作为测试内核，以 IBM pSeries 服务器作为测试硬件。使用的是一个特别设计的 LTP 压力测试场景，在使用网络与内存管理的同时并行地运行大范围的内核组件，并在测试系统上生成高工作负荷压力。Linux 内核、TCP、NFS 和 I/O 测试组件以重工作负荷压力为目标。
测试
30 天
pSeries 30 天 LTP 压力执行结果
机器：p650 LPAR
CPU：(2) Power4- 1.2 GHz
内核：Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
LTP 版本：20030514
99.00% 平均 CPU 利用率（用户：48.65%，系统：50.35%）
80.09% 平均内存利用率（8GB）
观测结果：
在 p650 LPAR 上 SLES 8 PPC64 30 天压力运转成功完成。
测试工具是 LTPstress。测试用例以并行和串行方式执行。
内核、TCP、NFS 和 I/O 测试组件都以重工作负荷压力为目标。
成功率：97.88%。
没有严重的系统故障。
图 1. 30 天 LTP 压力执行结果

60 天
60 天 LTP 压力执行结果：pSeries
机器：B80
CPU：(2) Power3- 375 MHz
内核：Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
LTP 版本：20030514
99.96% 平均 CPU 利用率（用户：75.02%，系统：24.94%）
61.69% 平均内存利用率（8GB）
3.86% 平均交换分区利用率（1GB）
观测结果：
在 pSeries B80 上 SLES 8 PPC64 60 天压力运转成功完成。
测试工具是 LTPstress。测试用例以并行和串行方式执行。
内核、TCP、NFS 和 I/O 测试组件以重工作负荷压力为目标。
成功率：95.12%。
没有严重的系统故障。
图 2. 60 天 LTP 压力执行结果

测试基础设施
硬件与软件环境
表 1 列出了硬件环境。
表 1. 硬件环境 系统 处理器 内存 硬盘  交换分区  网络
pSeries 650 (LPAR) Model 7038-6M2  2 - POWER4+(TM) 1.2GHz  8GB (8196MB)  36GB U320 IBM Ultrastar（有其他硬盘，但没有使用）  1GB  以太网控制器：AMD PCnet32  
pSeries 630 Model 7026-B80  2 - POWER3(TM)+ 375 MHz  8GB (7906MB)  16GB  1GB  以太网控制器：AMD PCnet32  

pSeries 630 Model 7026-B80 和 pSeries 650 (LPAR) Model 7038-6M2 上的软件环境是相同的。表 2 列出了软件环境。
表 2. 软件环境
组件 版本
Linux  SuSE SLES 8 with Service Pack 1  
内核 2.4.19-ul1-ppc64-SMP  
LTP  20030514  

方法学
系统的稳定性和可靠性通常以连续运转时间和系统的可靠运行时间来度量。
最初运行的是一组为期 30 天的基线运转，然后增加到 60 天和 90 天的 xSeries 和 pSeries 服务器上的 Linux 测试运转。初始重点在于内核、网络和 I/O 测试。
测试工具
Linux Test Project（即 LTP；参考资料 中有链接和更多信息）是 SGI、IBM、OSDL、Bull 和 Wipro Technologies 合作的项目，目的是为开放源代码团体提供测试套件，以测试 Linux 的可靠性、健壮性和稳定性。Linux Test Project 是测试 Linux 内核和相关部件的工具的集合。目的是通过使内核测试工作自动化来帮助改进 Linux 内核。
当前，在 LTP 套件中有超过 2000 个测试用例，涵盖了内核的大多数接口，比如系统调用、内存、IPC、I/O、文件系统和网络。测试套件每月都会更新发布，可以运行于多种体系结构上。已知的 LTP 测试套件测试过的体系结构有 11 种，包括 i386、ia64、PowerPC、PowerPC 64、S/390、S/390x (64bit)、MIPS、mipsel、cris、AMD Opteron 和嵌入式体系结构。我们的可靠性测试中使用的 LTP 版本是 20030524，这是当时可以获得的最新版本。
测试策略
在基线运转中有两个特别的阶段：一个 24 小时的“初始测试”，接下来是压力可靠性运转阶段，或者说是“压力测试”。
通过初始测试是开始测试的必要条件。初始测试包括 LTP 测试套件在硬件和操作系统上 24 小时的成功运转，这些硬件和操作系统将用于可靠性运转。LTP 测试套件包附带的驱动程序脚本 runalltest.sh 用于验证内核。这个脚本串行地运行一组成包的测试，并报告全部结果。也可以选择同时并行地运行几个实例。默认地，这个脚本执行：
文件系统压力测试。
硬盘 I/O 测试。
内存管理压力测试。
IPC 压力测试。
调试器测试。
命令功能的验证测试。
系统调用功能的验证测试。
压力测试可以验证产品在系统高使用率时的健壮性。作为 runalltest.sh 的补充，特别设计了一个名为 ltpstress.sh 的测试场景，在使用网络与内存管理的同时并行地运行大范围的内核组件，并在测试系统上生成高压力负荷。ltpstress.sh 也是 LTP 测试套件的一部分。这个脚本并行地运行相似的测试用例，串行地运行不同的测试用例，这样做是为了避免由于同时访问同一资源或者互相干扰而引起的间歇性故障。默认地，这个脚本执行：
NFS 压力测试。
内存管理压力测试。
文件系统压力测试。
数学 (浮点) 测试。
多线程压力测试。
硬盘 I/O 测试。
IPC (pipeio, semaphore) 测试。
系统调用功能的验证测试。
网络压力测试。
系统监控
LTP 测试套件附带的修改过的 top 工具用作系统监控工具。使用 top 可以实时地观察处理器的行为。改进的 top 工具具有附加的功能，可以将 top 结果的快照保存到文件中，并给出结果文件的平均总结，包括 CPU、内存和交换空间利用率等信息。
在我们的测试中，每 10 秒钟截取一次系统利用率（或者 top 输出文件）的快照，并保存到结果文件。另外，每天或每周要处理系统利用率的快照和 LTP 测试输出文件并得到数据分数，以确定系统在长时间运转中性能是否下降。此功能由 cron 作业和脚本控制。
测试之前
所有选定的测试系统的硬件配置尽可能相同。去掉了额外的硬件以减少潜在的硬件故障。在映像安装过程中选择最低的安全选项。预留至少 2 GB 的硬盘空间以保存 top 数据文件和 LTP 日志文件。
注意，这是一个测试场景；现实生活中，最好建议用户保持安全设置远高于最低设置。
测试期间
在测试期间系统不要受到干扰。偶尔访问一下系统以确认测试仍在进行是可以接受的。确认的手段包括使用 ps 命令、检查 top 数据和检查 LTP 日志数据。
测试之后
当测试结束后，系统监控工具 top 立刻停止。所有的 top 数据文件，包括每天或每周的快照和 LTP 日志文件，都被保存并处理，以便为分析提供数据。
结束语
本文论述的结果基于一个在实验室环境下创建并测试的解决方案。这些结果可能并不是在所有的环境中都可以得到，而且在这种环境中实现可能还需要另外的步骤、配置和性能分析。
然而，由于大部分的 Linux 内核测试工作历时都比较短，因此本系列测试为我们提供了长时间运转的第一手数据和结果。本系列测试还提供了高工作负荷压力下 Linux 内核组件以及 TCP、NFS 和其他测试组件的数据。测试证明，Linux 系统在长时间内是可靠的和稳定的，可以提供一个健壮的、企业级的环境。
参考资料
在 SourceForge 的 LTP Linux Test Project 主页 和 LTP 项目主页 可以找到有用的信息和链接。

项目的文档包括 LTP HowTo 和 LTP man pages（还有其他文档）。

LTP 网页还提供了关于其他 Linux 测试工具 的摘要和链接。

访问 IBM Linux Technology Center 主页 以阅读他们最新的新闻和声明。

IBM Linux Technology Center 项目主页 列出了工作组当前正在进行的项目。

“Inside IBM's Linux Technology Center”（ITworld.com）和“Inside IBM: Dan Frye and the Linux Technology Center”（Consulting Times） 两篇文章更深入地介绍了 IBM LTC 的背景。

IBM developerWorks 文章“Behind the scenes at the IBM Linux Technology Center” 也对 IBM Linux Technology Center 进行了描述。

在 IBM developerWorks Linux 专区 可以找到更多的关于 Linux 的开发资料。

杨粼波 2006-07-05 22:41 发表评论
]]>游戏测试方法http://www.cppblog.com/tx7do/archive/2006/07/05/9465.html杨粼波杨粼波Wed, 05 Jul 2006 14:40:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9465.htmlhttp://www.cppblog.com/tx7do/comments/9465.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9465.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9465.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9465.html如果给个定义，我觉得：测试工作是，解决玩家所遇非正常问题的预测工作，同时也是不断调试平衡的一个长期观察任务。无论在什么时间段，功能实现、内测、公测等。测试都应该是分硬件与软件两部分测试。
硬性问题
硬件的BUG部分是指会引起不能让游戏流程进行的BUG。死机、画面出错等硬性问题。这种问题只要按照一定流程进行游戏，就会发生。但对一些会不断增加服务器负担的高级BUG，应该不会短期测试出来。而对这种在有计算机就出现的问题，现在的游戏在制作过程中都有可自动记录问题的LOG功能，所出现的BUG大多会被程序部门解决掉。部分的LOG功能可保留到正式客户端，以收集因为升级客户端，而不断产生的新问题。这里应该不会在讨论范围内吧。
软性问题
而软件的逻辑部分大多会在后期进行，比如公测。是各种功能的数值调整。主要为游戏的世界定义一个平衡。除了初级的数值设定外，内部测试人员很少有能把一个功能测试千万遍的。于是有可能产生出猫耍的老虎团团转，这种经典的寓言故事。策划及相关测试人员注重的应该是这部分的测试原理及方法。
而这部分问题的测试，同硬性问题一样，需要一定流程及要求。而具体流程只有根据具体游戏来决定，大多是将问题分裂存放，并将理由归纳。但有几点是不变的。
平衡的目标
而如何让各种设定不偏离主题，明确世界背景及制定等级概念应该是首要的。尤其在一些角色等系统十分复杂的情况下。那种变态ADD的规则，可由主角的5~6种基础属性影响到数十种战斗、非战斗技能。还可根据各种物品来休整这些数值。而无论如何。他们都有个明确的等级观念。从弱到普通，再到强，甚至到最强的龙。这是因为他们知道一个人，最强也不能强过龙。这样就给自己定下上限目标。
所以，测试时首先不要去看玩家可选择的职业技能等等是否足够多。都会获得什么强大的技能、体力等等。先了解到这个世界里，各个种族之间的关系、职业的互补、各个角色的互相的关系，在整个世界中是什么位置，是否够合理、让常人可以现实中的逻辑去衡量，这个角色在游戏是否合理。之后才需要针对每个种族、每类职业、每个角色的平衡。最后到一个一个角色的测试。有人会说这是前期策划制定讨论的部分，没错，因为测试从这里就已经在策划的头脑中开始了。
在这里定义的过程，正好与现实世界中相反。现实世界是总结出整体的平衡，而游戏世界则要定义平衡，再将世界整理成平衡的状态。
划分等级
测试时同样要明确问题的严重等级，一个数值影响的事物越多，那他的严重等级越高。现在的MMRPG整个属性结构，基本都类似树形结构，之间也有着一些交错的枝叶。力量等最基本的角色属性，为根。这类属性会影响到的其他属性，最终到达游戏的胜负，任务的完成等等。而这些属性的等级自然也就十分明确。根为最高，枝叶最低。而修整树木永远不会从根开始。
力量，最基础的属性，结合自己的命中率，对方的敏捷等，会影响物理攻击。同样也影响着可拿的武器。但如果这个人攻击力过高。那是谁的原因？是武器，还是角色的力量。需要修改那一个？那些角色的基础属性是最不能随便修改的。因此，还是武器吧。实在不行在从由属性引发的其他部分着手，如技能的熟练度等。越基础的部分，影响力越大，也最容易出错。角色的基础属性是一切测试的根源，同样也是最不能随便更改的一类。更不应该因为某个问题而被指明要求更改。而添加删除任何一个属性，更会让之前的测试工作有2/3付之一炬，也许更多。而对于各种武器，基本可以与角色测试分开。在角色属性有数十条的游戏中，武器更不会容易出现大的问题。
严重等级之间从高到底可分为，角色，物品，技能。要修正这三大类属性，尽量在自己的范围内修正。不要妄想在其他级别动手，更别想在比自己之前高的级别里动手脚。而在这些属性里面同样还各种属性，就需要根据具体游戏进行划分测试。虽然这里以属性距离，但任务也同样如此，相互关连的任务网同样十分重要。只不过之前变化较属性掠少。
玩家是否付出与获得成正比
现实世界中，没有可能可用捷径获得某一种事物、，只有拼搏。游戏世界里是否也是？获得一个强大技能之前，给角色的锻炼是否足够。让他足够珍惜这一种技能或物品。这是游戏中较为关键的一部分，多体现在任务上。时间、精力的消耗，是否足够让玩家获得物品时有足够的满足感。以及对得起测试人员的劳动。
记录、调整，总结
 软性问题应该同硬性问题一样拥有足够多的文档资料来记录，同时也方便对以往数值的效果再思考。这也应该是所有文档资料应该具备的，记录每次关键更新的工作。
 调整方面Sid Meier说过，每一次调整都要多一些。这样可以看到数值中的巨大差别，从中找到合适的数值。这几乎是知道Sid Meier的人都知道的一句话。（大意相似，具体内容没办法记起来，惭愧）
 很多时候，测试时会直接将测试的内容按自己的想法修改。即便记录下来也是只要改好就好。其实很多时候这些修改都有一定规律，一些修正往往是没改变任何事情。多一些时间去探讨大家是否按照原来制定的目标去修正，会更合理的利用剩下的时间测试。同样，全部结束后的总结也会让下次制作时避免出现需要大量修正的设计。

杨粼波 2006-07-05 22:40 发表评论
]]>游戏项目中的自动化测试和持续集成http://www.cppblog.com/tx7do/archive/2006/07/05/9464.html杨粼波杨粼波Wed, 05 Jul 2006 14:39:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9464.htmlhttp://www.cppblog.com/tx7do/comments/9464.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9464.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9464.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9464.html
转载GameRes
--------------------------------------------------------------------------------


  
现在，许多游戏项目要么跳票严重，要不就是发布时Bug多多。当然，这样的现象并不仅存于游戏工业。例如，根据2001Standish集团发表的那份 声名狼藉的报告“极度混乱”所表述的，70%以上的软件项目要么被取消，要么严重的超时和超支。然而，游戏是软件开发复杂性的最佳代表，不同技能的人需要 协同工作，这也就是某些人所说的游戏项目中高风险因素所在。
　　软件项目延期、Bug满天飞和失败的原因是多种多样的，但看起来除了随产品特性不断变化之外，测试和品质管理是永恒的问题。以我们的经验来看，相当多数的游戏开发工作室完全依靠人工的方式来测试游戏引擎、开发工具和游戏代码，几乎没有采用自动化过程测试。很巧，在2002GDC的圆桌会议：游戏中的纯软件工 程，只有18%的与会者表示他们参与的项目采用了自动化测试。
　　在2000年，我们的客户，当时新成立的中间件公司对我们的3D引擎的稳定性和大量的BUG抱怨频频，我们第一次想到了自动化测试。直到那时，每当完成一 个新特征，我们还是依靠人工测试，并且使用这些特征开发出技术演示供市场部使用。我们在彻底分析了情况后得出以下结论，我们的软件质量问题主要和我们测试 方法有关：
*人工测试不够全面和彻底，因为它仅仅花费了很多时间。 代码在修改或添加之后，它本应运行预定义的人工测试集来保证修改不会产生新的问题。人工测试花费的时间越来越多，并给开发者带来挫折感，打击他们执行测试 的积极性。而且，测试的工作量使得开发者不愿意改进或优化现有的代码。
*当开发者测试他们自己的代码时，他们总是不愿意（潜意识？）执行最苛刻的测试用例，因此就导致了最有可能出错之处也是最不可能被全面测试到这样的情形。
　　因此，我们决定采用自动化测试，从开发一个新SDK部件开始。结果是鼓舞人心的，最终我们把它推广到所有的SDK部件开发中去。测试框架极限编程，由Kent Beck和Martin Fowler总结的一系列方法和经验，带来了自动化测试的流行。一般来说，自动化测试指无需用户干预，用来验证软件产品中的功能子集的代码和数据。它可以是用来测试某个特定类方法（通常称为单元测试），也可以是用来测试程序功能性的集成测试（功能测试）。
　 　为了促进自动化测试进程，有许多开源代码的单元测试框架，比如CPPunit（C++专用）或Nunit（.Net专用）。这些测试框架提供了GUI来 运行测试集并提供测试结果反馈。根据你的项目，也许需要根据你的游戏进行一些额外的功能扩展和自定义，例如支持跨平台。这些测试框架的内容，一个单元测试 对应一个函数，测试类由多个单元测试组成，并且包含一个开始和结束测试的方法（例如载入和卸载一幅地图）。这些测试类可以放在分离的执行文件中，例如 DLL文件，也可以与主项目在一起。除此之外，测试类应该存放在产品代码之外的文件中，这样的话，他们就可以很方便的从版本发布中移除。
　　物理引擎的简单测试代码，如果任何一个VTEST条件没有满足，那么测试就失败。该测什么？当要决定测试的范围时，实用第一。一般来说，为简单的功能编写单元测试是没有意义的，比如常见的getter和setter方法。为了让自动化测试物有 所值，被测试的代码至少应该是可能会产生错误的，比如，发射一束穿透游戏场景的光线并且返回它穿过的任何几何物体的方法（光线测试），然后将返回的结果与 编写测试用例的作者提供的预期结果作比较。
　　到底是只为类的公用 接口编写测试用例（黑盒测试）还是要兼顾类的私有成员（白盒测试），是一个有争议的问题。通常来说，黑盒测试比白盒测试粗糙，它们只能检查一个操作的最终 结果，不能检查内部中间状态，它们对于被修改的测试代码比较迟钝。刚才提到的光线测试功能可能被全部重写（比如原先的版本运行效率不够），但是它返回的结果没有变化。这时，白盒测试用例就需要跟着重写，然而黑盒测试可以继续用来检测代码修改后，所产生的结果是否与原先一致。
　　因此，我们认为自动化测试中，测试范围只要包括类的公有成员就够了，毕竟，类的内部修改比它接口修改要频繁得多。
回归测试
　 　特别是在游戏开发领域，大多数情况下，把测试结果和用例编写者提供的数据手工作比较是不太现实的。例如，检测与复杂的几何体碰撞的交点，人工提供相关测 试数据几乎不可能。相反，将测试结果与早期代码产生的结果数据相比较，被称为“回归测试”。用例编写者可以评审参考数据，例如，使用简化图形的碰撞物体，如果被证实是正确的，它就可以一直用于测试。这样，自动化测试可以帮助你确认新代码产生的结果与原先的一致。
　 　代码功能测试会生成非常复杂的输出数据，比如游戏的图形渲染引擎，回归测试是唯一可行的自动化测试。以图形渲染引擎为例，所有图形测试以输出最终平台相关的图形文件为结果。一旦自动化测试开始运行，渲染出来的图形文件与样本图形文件逐一像素的进行比较，如果有差异，那么测试失败。为了减少样本图形文件的存占用，你可以使用图形快照来进行测试。
　　图形回归测试的优势在于即使是肉眼难以发现的微小差异也不会被漏掉。除非人们对这个场景非常熟悉，否则很难会有人注意到场景中缺失的一个阴影或一个物体或者某个光源的R值与B值被错换了。而回归测试就不会放过任何一个这样的错误。
　 　必须注意到，任何情况下，回归测试的样本数据都是自动生成的。样本数据也许是平台相关，特别涉及到渲染输出的时候，因此，它也许要被生成多次，即使是这样，当渲染通道发生变化导致生成的图形文件有所改变，样本数据也要重新生成。为了不打击开发者编写回归测试的积极性，要做到只需点击框架用户界面上一个按钮就可以重新生成新的参考数据。
如何把所有的整合在一起
　 　包括游戏在内的所有应用，完整的测试集合包括单元测试和回归测试。单元测试适合于测试底层功能性、基础库文件和平台类库。上层的各种功能特征集成测试可以使用回归测试。根据结果，你可以有选择的重构或优化你的逻辑或引擎代码，回归测试一旦失败，你会马上发现出问题的地方，单元测试失败可以让你精确的定位出错之处。
　　知道代码被你编写的自动化测试覆盖得范围是非常有好 处的，你可以使用代码覆盖率调查工具（BullseyeCoverage/AQtime）。代码覆盖率分析会告诉你，你的代码哪些被调用，也可以提示你测 试集合中的疏漏之处。测试覆盖率应该是多少，无法精确定量，尽管它取决于被测试的代码。细小的方法无需测试，调试用的函数也不必测试。并且，几乎所有的项 目都会包括一些“死”代码，也就是不会被调用到的代码，那么，这些代码自然也不用测试。总而言之，现实中，我们见过的使用自动化测试的游戏和中间件项目中 测试覆盖率大致是55%到70%。
编写友好的测试代码
　 　必须承认，并不是所有的代码都能使用自动化测试。以单元测试为例，严格的面向对象，良好的类和函数模块化封装设计可以大大提高它的测试效率。类的接口越多，为它编写的单元测试就越多。同样，过多的使用C++的友元也会增加编写的难度，甚至无法为该类编写（黑盒）单元测试用例。
　　在写代码的时候，要时刻牢记保持良好的测试性。在开发过程中，就会变成可行但是单调乏味的工作，有时候它需要很好的结构性。要在游戏开发中使用，以下几点必须牢记：
*所有的回归测试都取决于明确的行为。比如，使用随计算法的寻径系统可以提供一个初始化随机种子的公共方法使得角色的行动决策更复杂多变。这个方法在随后的测试中可以被用来确保角色始终选取同样的路径。
*同样，回归测试中要避免与帧数相关的情况；否则，有真实物理特性的物体或渲染输出也许会和以前的数据不同，特别是当结果来自不同的机器或者不同的编译条件（debug 和release）。在测试时，使用恒定的虚拟帧数就可以避免这样的问题。
* 严重依赖于用户输入的软件很难测试，比如游戏内置的编辑系统或者游戏工具。这样的话，把UI 和逻辑代码严格的区分开会有所帮助。在我们的游戏工具里， UI界面里每个用户动作会执行一条或多条简单的脚本指令。每条脚本指令可以很明确的重现用户的原意。这样，测试用例可以简单的执行这些指令并且与样本数据 作比较就可以（比如导出地形文件）。
　　也可以使用GUI捕捉工具来测试UI，但我们发现这并不是个好办法。UI会经常改变，哪怕一个按钮仅仅移动几个像素也会使捕捉软件失效，GUI捕捉工具也许会帮倒忙。
关于测试的疑问：我们真的可以节省时间么？
　 多数情况下，一个开发团队想要在开发过程中使用自动化测试，大多数成员都会对它抱以质疑的态度。毕竟，与其花这点时间写测试用例，还不如去写逻辑和引擎 的代码。根据我们在游戏和其他领域的工作中使用自动化测试的经验来看，编写测试代码会额外增加30%工作量。初看，在时间和资金上这也许是很大的开销，然而，你要意识到这样做，省去了人工测试所花费的时间。
　　自动化测 试可以看作在开发前期投入，在开发过程中赢利。大多数的代码修改，包括Bug修改，都可能会引入更多问题导致程序宕机。所以，理论上说，一旦代码有所改变，就必须测试所有可能被影响的代码。自动化测试无需人工干预就可以完成，它们缩短了开发过程。而且由于自动化测试可以简单快速的发现修改的代码是否能有效地运行，因此也就鼓励开发者优化和改进现有的代码。
　　对我们来说，自动化测试帮助开发者编写更稳定和可靠的代码。哪怕是一开始对它抱有怀疑态度的开发成员也欣赏它所提供早期反馈的特性，在开发过程中，它也可以更早的 发现Bug。开发者的工作压力和负荷随着项目的开展日益加大，尽早的发现和解决Bug也可以避免给开发关键时期带来额外的压力。
　 　在开发Vision引擎的时候，我们收集了一些数据来研究为提高代码稳定性而实施自动化测试的有效性。2001年早期，全部依靠人工测试的引擎第一个 release版本开发完成，尽管我们已经进行了很全面的测试，但是每个月，我们的在线技术支持数据库依然会收到上百个来自客户的Bug报告。2001年 9月，我们对已有的引擎功能和新增的特征实施自动化测试。这样，即使我们现在的工作量很大，开发进展也很正常，每月Bug报告的数量锐减（现在大概是5到10个）。
　 必须强调，这些图表只是反映了单元测试用例数量和每月Bug数量两者之间的相互关系，不能将它理解为必然的因果关系。当然，从2001年到2004年，我们在如何编写健壮的代码上学到了很多，在这段时间内，开发团队的人数变动频频，但是，这些明显的差异足以说明稳定性的提升部分归功于使用了自动化测试。
游戏中自动化测试的局限性
　　尽管使用自动化测试对于游戏开发来说获益匪浅，但是也有其局限之处。显然，很难用它来测试游戏的平衡性，也不太可能用它来测试游戏性和画面的美观性。在这几年里，我们总结了一些编写自动化测试的要点，重点如下：
*测试最重要的模块（比如，最复杂和最常用的）。对那些最有可能出问题或者不会破坏原先设计的重构任务进行自动化测试，性价比最高。
*当上层功能性测试难以进行的时候，把精力集中在不同的子系统上。例如，你也许不能通过自动化测试来验证AI系统是否正常工作，但你可以测试当一个怪兽的体力低于一定数值的时候，它是否会“投降”。
*用压力测试来验证你的代码的强壮性。如果你的游戏在极端条件下运行的很好，比如，每秒有2000个怪兽出生和死亡，一个场景中同时放入500个有真实物理特性的物体，一幅地图轮流载入200次，那么玩家作一些异常操作时，宕机的可能性就会小很多。
*在修改Bug前，也为它编写测试用例。这样的话，可以确保这些Bug在今后的版本中不会重现。
*回归测试。例如，图像或状态比较的话，使用指定的测试场景要比使用产品地图更容易维护。如果你认为测试用产品数据可能会经常变动，那么你最好使用小的测试场景。否则，不断的生成新的参考数据会使得开发团队产生疲倦和厌烦的情绪。
* 测试用例越简单越好，不要奢望有非常大的覆盖面。搭建一个易维护和可扩展的自动化测试是一个长期的任务。一般来说，“底层”代码，例如算术、碰撞检测和渲染，更容易进行自动化测试，对于游戏性和完整的游戏测试来说，还是需要经过QA人员亲自测试。当然，QA部门的注意力也要从技术转移到与游戏性相关的问题上去。“到A房间后，因为通风口前面的箱子太高了，所以出不去”这样的报告就会取代“当我的角色转动的时候，屏幕上出现了很多扭曲的三角面”。
持续集成
　 　在一个复杂的软件项目中引入自动化测试，你会发觉运行它也需要一定的时间，我们看到的一些项目甚至需要几个小时。如果让开发者在他们的开发用机上运行的话，测试会完全占用他们的机器，影响工作，那么结果就是他们不去运行测试用例，很显然，没有被运行的用例是没有任何价值的。
　 　解决方法就是搭建一台或多台专用的自动化测试机。它同时还运行版本管理软件（Subversion/CVS/Perforce），一旦发现提交了新代 码，那么代码就会被Check out并编译，测试用例也会自动运行。最后，系统会将测试结果报告以email的形式自动发送给最近提交代码的开发者。
　 　完全自动化、重复的 build和测试过程，这种过程每天运行多次，在极限编程中，我们把它称为：持续集成。为了更好的实行持续集成，像 Cruise Control或者Anthill这样的开源代码工具可以将版本管理软件和自动build工具，例如ANT，整合起来。使用这样的工具， 可以很轻松的搭建适合自己的持续集成系统。
　　我们发现搭建专用持续集成服务器使得开发过程变得更顺畅，开发者可以更专注于自己的工作。与此同时，测试可以被很好的运行，一旦提交了错误的代码，持续集成系统会自动通知开发者和项目经理，因此开发者也可不必为此分心。自动化，自动化！
　 　自动化测试和持续集成的使用为我们在游戏和工具的开发上带来了极大的收益。例如，持续集成服务器根据Wiki中的变化，每天自动生成CHF （windows帮助文件）文件。而且，使用ANT和CruiseControl来制作软件自动分发包会非常容易。这样一来，用最新的代码（或最新的 tag）创建一个完整的分发包就是举手之劳。
　　自动化过程中的自 动化测试执行，例如测试框架中的常规单元和回归测试，他们不是用来检查错误，而是用在相同环境下得到测试结果来衡量和比较引擎的性能（系统配置的结果以 XML文件格式存放在版本管理软件系统上）。如果当前的结果比参考结果差很多，那么测试失败，反之，它就成为了新的参考结果。
　　性能测试是一种特殊的回归测试。当引擎代码被重构，我们通过它来确保修改不会降低引擎原有的性能。这样，就迫使我们时刻关注代码的运行效率和对代码的优化工作，可以避免遇到在实际运行中，速度突然变慢的现象发生。
结论
　　根据我们的经验，使用自动化测试和持续集成可以使开发团队工作更有效而开发出更好、稳定、简单的软件。而且，减少人工测试也可以减少开发团队的压力和工作负荷，可以在开发过程中尽早的发现Bug。
　　当然，自动化测试不会使你的游戏想当然成为畅销品。但毋庸置疑，它会使各类开发人员甚至玩家活得更自在。
参考
* Unit Tests: http://c2.com/cgi/wiki?UnitTest
* The Standish Group, Inc. (2001), Extreme Chaos
* By the Books: Solid Software Engineering for Games (GDC 2002 roundtable):
* http://www.convexhull.com/sweng/GDC2002.html
* Continuous Integration: http://cruisecontrol.sourceforge.net/
* http://c2.com/cgi/wiki?ContinuousIntegration
* ANT: http://ant.apache.org
* BullseyeCoverage: http://www.bullseye.com
* AQtime: http://www.automatedqa.com

杨粼波 2006-07-05 22:39 发表评论
]]>网络游戏测试过程http://www.cppblog.com/tx7do/archive/2006/07/05/9463.html杨粼波杨粼波Wed, 05 Jul 2006 14:36:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9463.htmlhttp://www.cppblog.com/tx7do/comments/9463.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9463.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9463.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9463.html――落叶夏日（陈卫俊）

游戏测试起因
近几年来，网络游戏成了网络最新的弄潮儿，从盛大之传奇般的掘起，吸引了无数公司的眼球。但由于随着玩家的品位的升高，代理费用的上升，单一的代理国外游戏的模式已经很难在国内立足，而有中国传统文化特色的网络游戏则在国内大受欢迎，比如剑侠情缘，大话西游等一些国内的精典之作已经进入了一流网游的阵营。与此同时随着大家对网游稳定性，可玩性要求的升高，网络游戏测试开始成为大家关注的话题。
游戏测试与软件测试的区别
游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：
测试的目的是发现软件中存在的缺陷。
测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。
每一种测试都需要产品运行于真实的或是模拟环境之下。
每一种测试都要求以系统方法展示产品功能，以证明测试结果是否有效，以及发现其中出错的原因，从而让程序人员进行改进。
总而言之，测试就是发现问题并进行改进，从而提升软件产品的质量。游戏测试也具备了以上的所有特性，不过由于游戏的特殊性，所以游戏测试则主要分为两部分组成，一是传统的软件测试，二游戏本身的测试，由于游戏特别是网络游戏，它相当于网上的虚拟世界，是人类社会的另一种方式的体现，所以也包含了人类社会的一部分特性，同时它又是游戏所以还涉及到娱乐性，可玩性等独有特性，所以测试的面相当的广。 我们称之为游戏世界测试，主要有以下几个特性：
游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动，我喜欢称为游戏情感世界的测试。
游戏世界的平衡测试，主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。
游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言J。
游戏测试概述
很多人有这样一个观点：“就是在软件开发完毕后，再进行测试。”殊不知，这种关点是有悖于软件开发的生命周期的，软件缺陷的发现必须是越早越好，这样才可以有效的规避风险，而在“最后进行测试”的测试观念的指导下测试工作必将会产生很多问题，这种观念的错误在于：生命周期中的“测试阶段”表明在该阶段测试工作是主要的工作，而不是说，测试工作只发生在“测试阶段”。通常，到了测试阶段，测试的主要任务是运行测试，形成测试报告。而想要提高游戏的质量，则必需要做到测试的早期介入，诸如测试计划，测试用例的确定以及测试代码的编写等等都是要在更早的阶段进行。如果你把测试完全放在最后阶段，就错过了发现构架设计和游戏逻辑设计中存在严重问题的最好时机，到那时，要修复这些缺陷将很不方便，因为缺陷已经扩散到系统中去了，所以这样的错误将很难寻找与修复，代价更高。
要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。游戏要成功，其基本的必要条件有三。分别为Vision(设计)、technology(技术)和Process(过程)。三个条件，缺一不可如图所示：
    
图：游戏开发三大基石
Vision则是对游戏还没有实现的总体上的把握，前瞻性的理解与策略的考量。
Technology：有了vision，如果没有技术的话，则各种美妙的想法只能停留在虚无缥缈的阶段，通过技术来实现Vision。
Process：有了Vision作为指导，有了技术作为保证，也不一定能够把好的想法转换成高质量的游戏。要创造高品质的游戏，尚缺重要的一环，即过程，制造游戏是一个非常是一个长时间的动态过程。游戏产品的质量则是要靠动态过程的动态质量来进行保证。过程由很多复杂的相互牵制的环节与部件组成，如果任意的环节或者是部件出了问题都会对最终的产品形成质量上的影响。因此对这个动态的过程，一定要有规划与控制，以保证按步就班，按质按时完成工作。
游戏测试与开发过程的关系
CMM（Software Capability Maturity Model）软件成熟模型，大家都比较熟悉了，但在实施的过程中却存在这样那样的问题，对于游戏开发就更没有一个固定的路可以讲了，我们的团队是一个长期的游戏开发团队，对游戏开发有着很深的认识，我们认为游戏的Process(过程)实际上也是软件过程，不过是特殊的游戏软件开发过程，各个生命周期还是相通的。所以我们总结一套以测试作为质量驱动的、属于自己的开发过程。下图是游戏的迭代式开发过：
    
图：游戏迭代式开发与测试
由于网络游戏的生命周期也是3、4年，所以采用迭代式的开发过程，既可以适应网络游戏本身这种长周期的开发，又可以利用RUP的迭代式开发的优点与CMM的里程碑控制，从而达到对游戏产品的全生命周期的保证。
在游戏开发过程中，通用软件的需求分析阶段被策划所代替，但起的作用是一样的，明确游戏的设计目标（包括风格，游戏玩家群），游戏世界的组成，为后期的程序设计，美工设计，测试提出的明确的要求。由于开发是一个阶段的过程，所以测试与开发的结合就比较容易，从图上我们可以看到测试的工作与游戏的开发是同步进行的，每一个开发阶段中测试都进行了参与，能够深入的了解到系统的整体与大部分的技术细节，从而从很大程度上提高了测试人员对错误问题判断的准确性,并且可以有效的保证重要游戏系统的稳定。
游戏策划与测试计划
测试过程不可能在真空中进行。如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排，通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。策划书包含了游戏定位，风格，故事情节，要求的配制等等。在策划评审中我们的高级测试人员可以参与进来，得到详细的游戏策划书，从里面了解到游戏的组成，可玩性，平衡（经济与能力），与形式（单机版还是网络游戏），而我们测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对服务器的性能要求。同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的测试打下良好的基础。同时由于测试人员参与到策划评审，资深的游戏测试人员与产品经理由于对游戏也有很深入的了解，会对策划提出自己的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起到控制的作用。
游戏设计与测试
设计阶段是做测试案例设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。而我们的测试则会很明确，因为我们的测试计划已经写的很明确，需要测试那些游戏系统，但是我们还需要了解系统的组成，而设计阶段则是设计系统的过程，所有的重要系统均是用UML状态图进行了详细的描述，比如用户登陆情况。如图2：
    
图2用户登陆情况
在我们的团队中资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图，时序图，状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到充分的保证。比如上图中就是一个用户登陆游戏系统的时序图。从这里我们可以很明确的了解玩家是如何验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库，从而对登陆系统的系统化测试做了充分的准备。同时通过这张图，性能分析人员还可以分析出可能存的性能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试的需求，比如模拟玩家登陆的压力工具等等。
同时在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。上面所说的是对游戏程序本身的测试设计，对于游戏情节的测试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明书，称为任务说明书，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成，我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任务，还可以提出自动化需求，采用机器人自动完成。
游戏测试与开发
开发与测试一直有人认为是不可以平行进行的，必需要先开发后测试，但是软件的开发过程又要求测试必须早期介入，但在这里这种矛盾得到了很好的解决。我们采用了每日编译，将测试执行和开发结合在一起，并在开发阶段以编码--测试--编码--测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。普通情况下，先进行的测试是单元测试，但是一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。特别是关于接口测试，像游戏程序与任务角本、图片的结合，大家都认为需要提前测试，通过每日编你可以把已经写好的程序片段接合起来，形成部分的集成测试，从而有效的体现的接口优先测试的原则。同时由于软件测试与开发是并行进行的，并且实行的是软件缺陷优先修改的策略，所以很少会出现缺陷后期无法修改的情况，并且由于前期的测试案例的设计与自动化工具的准备，我们不需要投入太多的人力就可以极高的保证游戏软件的产品质量，特别是重要系统的质量。由于我们的游戏程序是每日不断的完善，所以集成测试也在同步的进行之中，当开发进入最后阶段时，集成测试也同步的完成了。这里有一个原则，也就是我前面所说的，测试的主体方法和结构应在游戏设计阶段完成，并在开发阶段进行补充(比如在游戏开发中会有相应的变动，或是某个转移变地址的变化，这就需要实时的更新)。这种方法会对基于代码的测试（开发阶段与集成阶段）产生很重要的影响，但是不管在那个阶段，如果在执行前多做一点计划和设计,都会大幅度的提高测试效率，改善测试结果，同时还有利于测试案例的重用与测试数据的分析，所以我们的测试计划是在策划时就形成了，为后继的测试形成了良好的基础。
集成测试阶段
集成测试是对整个系统的测试。由于前期测试与开发的并行，集成测试已经基本完成，这时只需要对前期在设计阶段中设计的系统测试案例运行一下就OK了。我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式，内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。
游戏可玩性测试
游戏可玩性测试也是非常重要的一块，主要包含四个方面：
游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。
游戏世界事件的驱动，主要指任务。
游戏世界的竞争与平衡。
游戏世界文化蕴涵，游戏的风格与体现。
这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需要职业玩家对它进行分析，这里我们主要通过三种方式来进行：
内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。
利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。
利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。
游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试,测试大量玩家下的运行情况。
可玩性测试是游戏重要的一块，只有玩家的认同，我们才可能成功。
性能测试与优化
最后要单独提一下的是性能优化，在单机版的时代，性能的要求并不是很高，但是在网络版的时代，则是两个完全不同的概念，主要包含了以下几个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。不过在测试过程中有这样一个原则，就是由于测试是在集成测试完成或接近完成时进行，要求测试的功能点能够走通，这时你首先要进行优化的是数据库或是网络本身的配制，只有这样才可以规避改动程序的风险。同时性能的测试与优化是一个逐步完善的过程，需要前期的很多的工作，比如性能需求，测试工具等等，不过由于前期工作的完善，这些都在前期完成了。这里我只做原则性的描述。
数据库的优化的原则主要是这样的，首先是索引进行优化，由于索引的优化不需要对表结构进行任何改动，是最简单的一种，又不需要改动程序就可能提升性能若干倍，不过要注意的是索引不是万能的，若是无限的增加会对增删改造成很大的影响。其次是对表，视图，存储过程的优化。不过在分析之前需要知道优化的目标，客户行为中那些SQL是执行的最多的，所以我们必需借助些SQL的跟踪分析工具，例如SQLProfile,SQLExpert,等工具，这样会迅速的定位问题。
关于网络的优化，这里我所说的并不是针对网络本身的优化，而是对游戏本身的网络通信的优化，所以它是与程序的优化是结合在一起的，首先也是发现问题，通过Monitor与Sniff先定位是什么应用占用了较多的网络流量，由于网络游戏的用户巨大，所以这也是一个重在的问题。对于程序的性能优化，最主要的是找到运行时间最长的函数，只有优化它，性能才有大幅度的提升，具体的方法我就不做详细的描述了。
总述
游戏测试是一个新的领域,它既有通用测试的特点,又有自己的特点,有许多未知的路要走,每天都在总结,希望给大家带来一些帮助,同时在这里也谢谢所有支持我的同事。

杨粼波 2006-07-05 22:36 发表评论
]]>游戏测试过程http://www.cppblog.com/tx7do/archive/2006/07/05/9462.html杨粼波杨粼波Wed, 05 Jul 2006 14:35:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9462.htmlhttp://www.cppblog.com/tx7do/comments/9462.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9462.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9462.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9462.html标题   游戏测试过程     cwj007 [原作] 
关键字   游戏测试过程
出处   

游戏测试过程
游戏测试起因
 近两年，IT业一直经历着“寒冬”，但是游戏软件业却呈现出了勃勃生机。网络游戏仅在中国游戏市场出现不过两年，到今年1月，正式投入商业运营的游戏数目已超过100款，但众所周知，都是国外的（主要是韩国的游戏）统治着国内大部分的市场，国内游戏软件想要突围而出，主要从二个方面，一是可玩性，由于中国有上下五千年的传统文化，博大精深，是我们得天独厚的优势，二是游戏的质量，游戏测试作为游戏开发中质量保证的最重要的环节，在游戏设计与开发的过程中发挥着越来越重要的作用。
游戏测试与软件测试的差异
 游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：
 测试的目的是发现软件中存在的缺陷。
 测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。
 每一种测试都需要产品运行于真实的或是模拟环境之下。
 每一种测试都要求以系统方法展示产品功能，以证明测试结果是否有效，以及发现其中出错的原因，从而让程序人员进行改进。
总而言之，测试就是发现问题并进行改进，从而提升软件产品的质量。游戏测试也具备了以上的所有特性，不过由于游戏的特殊性，所以游戏测试则主要分为两部分组成，一是传统的软件测试，二游戏本身的测试，由于游戏特别是网络游戏，它相当于网上的虚拟世界，是人类社会的另一种方式的体现，所以也包含了人类社会的一部分特性，同时它又是游戏所以还涉及到娱乐性，可玩性等独有特性，所以测试的面相当的广。 我们称之为游戏世界测试，主要有以下几个特性：
 游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动，我喜欢称为游戏情感世界的测试。
 游戏世界的平衡测试，主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。
 游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言J。
游戏测试概述
 很多人有这样一个关点：“就是在软件开发完毕后，再进行测试。”殊不知，这种关点是有悖于软件开发的生命周期的，软件缺陷的发现必须是越早越好，这样才可以有效的规避风险，而在“最后进行测试”的测试观念的指导下测试工作必将会产生很多问题，这种观念的错误在于：生命周期中的“测试阶段”表明在该阶段测试工作是主要的工作，而不是说，测试工作只发生在“测试阶段”。通常，到了测试阶段，测试的主要任务是运行测试，形成测试报告。而想要提高游戏的质量，则必需要做到测试的早期介入，诸如测试计划，测试用例的确定以及测试代码的编写等等都是要在更早的阶段进行。如果你把测试完全放在最后阶段，就错过了发现构架设计和游戏逻辑设计中存在严重问题的最好时机，到那时，要修复这些缺陷将很不方便，因为缺陷已经扩散到系统中去了，所以这样的错误将很难寻找与修复，代价更高。
 要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。游戏要成功，其基本的必要条件有三。分别为Vision(设计)、technoogy(技术)和Process(过程)。三个条件，缺一不可如图所示：
Vision

Technoogy

Process

 

 


图：游戏开发三大基石
 Vision则是对游戏还没有实现的总体上的把握，前瞻性的理解与策略的考量。
 Technoogy：有了vision，如果没有技术的话，则各种美妙的想法只能停留在虚无缥缈的阶段，通过技术来实现Vision。
 Process：有了Vision作为指导，有了技术作为保证，也不一定能够把好的想法转换成高质量的游戏。要创造高品质的游戏，尚缺重要的一环，即过程，制造游戏是一个非常是一个长时间的动态过程。游戏产品的质量则是要靠动态过程的动态质量来进行保证。过程由很多复杂的相互牵制的环节与部件组成，如果任意的环节或者是部件出了问题都会对最终的产品形成质量上的影响。因此对这个动态的过程，一定要有规划与控制，以保证按部就班，按质按时完成工作。
游戏测试与开发过程的关系
CMM（Software Capabiity Maturity Mode）软件成熟模型，大家都比较熟悉了，但在实施的过程中却存在这样那样的问题，对于游戏开发就更没有一个固定的路可以讲了，我们的团队是一个长期的游戏开发团队，对游戏开发有着很深的认识，我们认为游戏的Process(过程)实际上也是软件过程，不过是特殊的游戏软件开发过程，各个生命周期还是相通的。所以我们总结一套以测试作为质量驱动的、属于自己的开发过程。下图是游戏的迭代式开发过：

 

 

图：游戏迭代式开发与测试
由于网络游戏的生命周期也是3、4年，所以采用迭代式的开发过程，既可以适应网络游戏本身这种长周期的开发，又可以利用RUP的迭代式开发的优点与CMM的里程碑控制，从而达到对游戏产品的全生命周期的保证。
在游戏开发过程中，通用软件的需求分析阶段被策划所代替，但起的作用是一样的，明确游戏的设计目标（包括风格，游戏玩家群），游戏世界的组成，为后期的程序设计，美工设计，测试提出的明确的要求。由于开发是一个阶段的过程，所以测试与开发的结合就比较容易，从图上我们可以看到测试的工作与游戏的开发是同步进行的，每一个开发阶段中测试都进行了参与，能够深入的了解到系统的整体与大部分的技术细节，从而从很大程度上提高了测试人员对错误问题判断的准确性,并且可以有效的保证重要游戏系统的稳定。
游戏策划与测试计划
 测试过程不可能在真空中进行。如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排，通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。策划书包含了游戏定位，风格，故事情节，要求的配制等等。在策划评审中我们的高级测试人员可以参与进来，得到详细的游戏策划书，从里面了解到游戏的组成，可玩性，平衡（经济与能力），与形式（单机版还是网络游戏），而我们测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对服务器的性能要求。同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的测试打下良好的基础。同时由于测试人员参与到策划评审，资深的游戏测试人员与产品经理由于对游戏也有很深入的了解，会对策划提出自己的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起到控制的作用。

游戏设计与测试
 设计阶段是做测试案例设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。而我们的测试则会很明确，因为我们的测试计划已经写的很明确，需要测试那些游戏系统，但是我们还需要了解系统的组成，而设计阶段则是设计系统的过程，所有的重要系统均是用UM状态图进行了详细的描述，比如用户登陆情况。

 


图2用户登陆情况

在我们的团队中资深的测试人员要具备的一项基本的素质就是可以针对UM的用例图，时序图，状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到充分的保证。比如上图中就是一个用户登陆游戏系统的时序图。从这里我们可以很明确的了解玩家是如何验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库，从而对登陆系统的系统化测试做了充分的准备。同时通过这张图，性能分析人员还可以分析出可能存的性能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试的需求，比如模拟玩家登陆的压力工具等等。
同时在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。上面所说的是对游戏程序本身的测试设计，对于游戏情节的测试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明书，称为任务说明书，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成，我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任务，还可以提出自动化需求，采用机器人自动完成。
游戏测试与开发
 开发与测试一直有人认为是不可以平行进行的，必需要先开发后测试，但是软件的开发过程又要求测试必须早期介入，但在这里这种矛盾得到了很好的解决。我们采用了每日编译，将测试执行和开发结合在一起，并在开发阶段以编码--测试--编码--测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。普通情况下，先进行的测试是单元测试，但是一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。特别是关于接口测试，像游戏程序与任务角本、图片的结合，大家都认为需要提前测试，通过每日编你可以把已经写好的程序片段接合起来，形成部分的集成测试，从而有效的体现的接口优先测试的原则。同时由于软件测试与开发是并行进行的，并且实行的是软件缺陷优先修改的策略，所以很少会出现缺陷后期无法修改的情况，并且由于前期的测试案例的设计与自动化工具的准备，我们不需要投入太多的人力就可以极高的保证游戏软件的产品质量，特别是重要系统的质量。由于我们的游戏程序是每日不断的完善，所以集成测试也在同步的进行之中，当开发进入最后阶段时，集成测试也同步的完成了。这里有一个原则，也就是我前面所说的，测试的主体方法和结构应在游戏设计阶段完成，并在开发阶段进行补充(比如在游戏开发中会有相应的变动，或是某个转移变地址的变化，这就需要实时的更新)。这种方法会对基于代码的测试（开发阶段与集成阶段）产生很重要的影响，但是不管在那个阶段，如果在执行前多做一点计划和设计,都会大幅度的提高测试效率，改善测试结果，同时还有利于测试案例的重用与测试数据的分析，所以我们的测试计划是在策划时就形成了，为后继的测试形成了良好的基础。
集成测试阶段
集成测试是对整个系统的测试。由于前期测试与开发的并行，集成测试已经基本完成，这时只需要对前期在设计阶段中设计的系统测试案例运行一下就OK了。我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式，内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。
游戏可玩性测试
游戏可玩性测试也是非常重要的一块，主要包含四个方面：
1. 游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。
2. 游戏世界事件的驱动，主要指任务。
3. 游戏世界的竞争与平衡。
4. 游戏世界文化蕴涵，游戏的风格与体现。
这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需要职业玩家对它进行分析，这里我们主要通过三种方式来进行：
1. 内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。
2. 利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。
3. 利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。
4. 游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试,测试大量玩家下的运行情况。
可玩性测试是游戏最重要的一块，只有玩家的认同，我们才可能成功。
性能测试与优化
 最后要单独提一下的是性能优化，在单机版的时代，性能的要求并不是很高，但是在网络版的时代，则是两个完全不同的概念，主要包含了以下几个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。不过在测试过程中有这样一个原则，就是由于测试是在集成测试完成或接近完成时进行，要求测试的功能点能够走通，这时你首先要进行优化的是数据库或是网络本身的配制，只有这样才可以规避改动程序的风险。同时性能的测试与优化是一个逐步完善的过程，需要前期的很多的工作，比如性能需求，测试工具等等，不过由于前期工作的完善，这些都在前期完成了。这里我只做原则性的描述。
 数据库的优化的原则主要是这样的，首先是索引进行优化，由于索引的优化不需要对表结构进行任何改动，是最简单的一种，又不需要改动程序就可能提升性能若干倍，不过要注意的是索引不是万能的，若是无限的增加会对增删改造成很大的影响。其次是对表，视图，存储过程的优化。不过在分析之前需要知道优化的目标，客户行为中那些SQ是执行的最多的，所以我们必需借助些SQ的跟踪分析工具，例如SQProfie,SQExpert,等工具，这样会迅速的定位问题。
 关于网络的优化，这里我所说的并不是针对网络本身的优化，而是对游戏本身的网络通信的优化，所以它是与程序的优化是结合在一起的，首先也是发现问题，通过Monitor与Sniff先定位是什么应用占用了较多的网络流量，由于网络游戏的用户巨大，所以这也是一个重在的问题。对于程序的性能优化，最主要的是找到运行时间最长的函数，只有优化它，性能才有大幅度的提升，具体的方法我就不做详细的描述了。
总述
 游戏测试是一个新的领域,它既有通用测试的特点,又有自己的特点,有许多未知的路要走,每天都在总结,希望给大家带来一些帮助,同时在这里也谢谢所有支持我的同事。



杨粼波 2006-07-05 22:35 发表评论
]]>防御性编码和单元测试规则http://www.cppblog.com/tx7do/archive/2006/07/05/9461.html杨粼波杨粼波Wed, 05 Jul 2006 14:24:00 GMThttp://www.cppblog.com/tx7do/archive/2006/07/05/9461.htmlhttp://www.cppblog.com/tx7do/comments/9461.htmlhttp://www.cppblog.com/tx7do/archive/2006/07/05/9461.html#Feedback0http://www.cppblog.com/tx7do/comments/commentRss/9461.htmlhttp://www.cppblog.com/tx7do/services/trackbacks/9461.html关键字   防御性编码和单元测试规则(一)  
出处    

开发人员编写代码。不幸的是，开发人员也编写缺陷，其中大多数缺陷是在最初的编码阶段加入的。修复这些缺陷成本最低的地方同样也是在开发的初始阶段。如果等到功能测试或者系统测试来捕获并修复缺陷，那么您的软件开发成本就会高得多。在本文中，作者 Scott Will、Ted Rivera 和 Adam Tate 讨论了一些基本的“防御性”编码和单元测试实践，让开发人员更容易找到缺陷 —— 更重要的是，从一开始预防缺陷产生。
防御性驾驶和防御性开发
大多数司机接受过防御性驾驶技术的教育 —— 这有很好的理由 —— 但是并不是所有开发人员都接受过防御性开发的教育，特别是那些没有用汇编语言进行过多少开发（如果不是完全没用过的话）、也没有因内存约束和处理器限制而关心过编写极其紧凑的代码的年轻开发人员。本文讨论防御性编码和单元测试概念，它们可以帮助开发人员更快生成更好的代码并且缺陷更少。
为什么防御性开发是重要的？
捕捉错误、问题和缺陷的最佳位置是在开发周期的早期。图 1 展示了最容易出现缺陷的地方，以及最容易发现它们的地方，并包括了修复这些缺陷的成本（这些成本是针对 1996 年的 —— 今天的成本显然更高）。



图 1. 缺陷：引入阶段及发现阶段（包括成本）


当然，比在编码阶段找到缺陷更好的是在一开始就防止它们。防止缺陷应该是开发人员最优先考虑的。我们将分析几个让开发人员可以在编码和单元测试时防止并检测缺陷的简单的、经过证明的方法。
在编译前（防御性设计考虑）
防止缺陷（特别是系统性缺陷）的最有效方式是仔细检查编码所依据的设计。由设计缺陷导致的缺陷 —— 虽然一般不是很多 —— 通常修补成本是最高的。事前花很少的时间针对以下几点对设计进行检查可以得到显著的长期回报。
设计考虑
设计是否有任何不清楚或者混乱的部分？如果是的话，在编写任何代码 之前 澄清这些问题。否则，您可能以一种方式解释一个设计需求，而同事则以另一种方式解释它，从而得到不兼容的实现。
如果您的代码要访问同时被其他组件访问的数据，那么保证您的设计可以处理这种情况。同时，检查设计的安全问题。
如果您的代码严重依赖于其他应用程序的代码，那么您对那个应用程序是否熟悉到可以对设计进行检查？考虑在您的设计检查小组中加入熟悉该产品的一个开发人员。在 设计阶段 发现的集成问题可以得到最有效的处理。
安装和使用考虑
如果您的代码是以前版本的一个升级，那么是否有会使升级失败的参数或者其他选项改变？有哪些其他产品与新代码交互或者集成 —— 如果这些产品本身也改变了呢？还有，您的代码是否容易安装？
操作系统和数据库考虑
您的代码是否会在新版本的操作系统或者数据库上运行？您是否知道这些新版本中加入了哪些改变以及它们是否（及如何）影响您的代码？
这只是测试
设计是否结合了可测试性？虽然您可能认为可测试性问题不是您需要关心的，但是事实上单元测试 是 开发人员的责任之一 —— 几乎所有使执行功能测试和/或系统测试更容易的任何事情也会使单元测试更容易执行。
下面是 可测试性 领域内容的几个例子。

设计是否允许运行时外部工具访问“状态”变量（例如，当前状态），特别是那些测试程序需要用来验证代码是否正确工作以帮助确定问题的变量？

是否对跟踪和日志给予了足够的重视？您让其他人分析缺陷越容易，您在发现缺陷后修正它们就越容易（而且在单元测试中发现自己的问题也会更容易）。

您是否考虑了所有可能调用您的代码的上下文？如果您可以将错误消息与调用它的用户函数上下文相关联，那么用户就更有可能理解这个错误。

设计是否结合了您的测试自动化工具所需要的特定的“钩子（hook）”？
再多想一想您肯定可以在这个清单中加入更多的内容，特别是那些对您的产品或者组织特定的内容。
防御性编码技术：编译器是您的朋友
当您完成对设计的检查后，就轮到编码了。就让我们面对它，除了设计错误外，编码是惟一引入缺陷的地方。无论如何，您的测试程序和客户是不会加入缺陷的 —— 只有 您 会。我们都知道时间很紧张，但是如果您没有时间在第一次就把它编写正确，那么您怎么能找到时间去修正它呢？花上一些时间，这会使您在以后的编码工作中更轻松。
防止缺陷的最好方法之一是使用编译器。令人恐惧的是，开发人员在编译时通常选择使用最低程度的警告输出，所以请启用编译的全部警告 —— 把即使将编译器配置为检查 所有方面 编译时也不产生一个警告当成编写代码的一个挑战。此外，对代码使用多种编译器使很多程序员获益 —— 这种方法有时会捕获不同的语法错误。
编码习惯
下面我们将抛砖引玉介绍几个好的编码习惯。我们不是要为您定义“最佳编码习惯” —— 我们只是要您形成自己遵守的代码编写习惯。下面是几个供参考的最佳习惯的例子。
在使用前初始化所有变量
您是否有一组可接受的默认值，特别是对于可能被用户、其他组件或者其他程序有选择地修改的数据？同时，我们强烈要求您列出在最外围例程中要使用的所有本地变量，然后再专门初始化它们。这样不会对您编写代码时的想法留下任何疑问。虽然这可能要多花一些时间并且像是没有理由地增加了几行代码，但是与只是在“运行中（on the fly）”声明本地变量相比，大多数优化编译器不会对此生成任何额外的运行时代码。清单 1 显示了在一个例程中最初几行代码的一个例子：
清单 1. 初始化本地变量
public unsigned short TransMogrify( UFEventLink IncomingLink )
  {
    //
    // local variables
    //
    unsigned short usRc;
    String sOurEventType;
    String sTheirEventType;
    //
    // beginning of code
    //
    usRc = 0;
    sOurEventType = null;
    sTheirEventType = null;
    //
    // a miracle occurs...
    //
    return( usRc );
  } // end "TransMogrify"


使用一个“编码标准”文档
如果您有一个编码标准文档，就使用它。您可以在 Internet 上找到许多种编码标准。找到一种简单的、切中要害、并为您留下一定的活动空间的标准。Sun 的网站有一个关于 Java 编程的编码规范的文章（请参阅 参考资料），它给出了拥有标准的下列几点理由：
一个软件生存期百分之八十的成本都用在维护上。
几乎没有软件在整个使用期间都是由原作者维护的。
编码规范改进了软件的可读性，使工程师可以更快和更充分地理解新代码。
如果您将源代码作为产品交付，那么需要保证它有像您创建的所有其他产品一样的包装和整洁性。
即使不赞成“标准”的想法，至少采用这个简单的建议：对变量名使用“匈牙利命名法”，这会使您的代码更容易阅读和维护（。
保证返回代码的一致性
在调试时有一种会制造麻烦的情况是：调用程序屏蔽（或者覆盖）一个表示错误的返回代码。一定要想好您要向调用您的代码的例程返回什么值，并保证从您所调用的例程返回的所有错误代码都得到恰当处理。如果返回代码 n 在一个地方意味着一件事，就不要在其他的地方用返回代码 n 表示另一件事。
对每个例程使用“单点退出”
这一点怎么强调也不过分：对每个例程使用单点退出 —— 就是说，没有多重返回！这是最容易忽视的、也是您可以采用的最好的习惯。如果例程只从一个地方返回，那么就可以用一种非常容易的方法保证在返回前完成所有必要的清理工作，这也使调试更容易。清单 2 显示了一个包含多重返回的代码示例。注意重复代码、甚至忘记“清理”项目是多么容易。
清单 2. 单点退出示例
1   public String getName( )
2     {
3       //
4       // local variables
5       //
6       String returnString;
7
8
9       //
10      // beginning of code
11      //
12      returnString = textField.getText( );
13      if ( null == returnstring )
14        {
15          badCount++;
16          totalCount++;
17          return( null )
18        }
19
20      returnString = returnString.trim( );
21      if ( returnString.equals( "" ) )
22        {
23          badCount++;
24          totalCount++;
25          return( null );
26        }
27
28      totalCount++;
29      return( returnString );
30
31    } // end getName


在第 15 行，badCount 增加了，因为 getText( ) 返回 null。在第 23 行，badCount 代码又重复了。现在想像一下如果这个例子需要完成更复杂的“清理”时会有多混乱。
清单 3 显示了一种更好的方法：
清单 3. 单点退出示例 —— 修正后
1   public String getName( )
2     {
3       //
4       // local variables
5       //
6       String returnString;
7
8
9       //
10      // beginning of code
11      //
12      returnString = textField.getText( );
13      if ( null != returnstring )
14        {
15          returnString = returnString.trim( );
16          if ( returnString.equals( "" ) )
17            returnString = null;
18        }
19
20      //
21      // "cleanup"
22      //
23      if ( null == returnString )
24        badCount++;
25      totalCount++;
26
27      return( returnString );
28
29    } // end getName



标题   防御性编码和单元测试规则(二)      chensheng913 [原作]  
关键字   防御性编码和单元测试规则(二)   出处     加强警戒（En garde）! 要记住，您的客户对您的产品有与您不一样的想法。他们会在一个您的小组很可能从来也没想到的 —— 或者至少是没有可能测试的 —— 环境中安装它。他们会以您从来没有想到过的方法使用它，并以您意想不到的方法配置它。下面的列表有助于帮助您保证他们不会发怒： 验证所有收到的参数的完整性（考虑如果您期待一个数组而传递来的是一个 null，但是您在索引数组之前没有检查这种可能性时会发生什么情况）。 考虑所有可能的错误情况并增加处理每种情况的代码（您希望代码得体地处理错误条件而不是堵塞它）。 对于那些未预料到的错误条件，加入一个一般性的“捕获所有”错误处理程序。 在适当的时候和地点使用常量。 在代码各处加入跟踪和日志。 如果您的产品将翻译为另一种语言，那么保证您的代码可以“支持”它。即使出现这种情况的机会很小，但是提前计划总是好一些。修改代码以使它提供支持是最容易产生缺陷的。下面是几个您要考虑的与支持相关的问题： 您是否有任何硬编码的字符串？ 您是否正确地处理不同的日期/时间？ 不同的货币表示呢？ 还有，在代码中使用大量断言。 给您的代码加上充分的 注释。总之，您还记得在六个月前编写那个方法时的想法吗？一年后要修改您的代码的某个人又会怎么想呢？在我们提出的所有建议中，这一条可能是最重要的。 单元测试（防御性测试技术） 在本文中，我们所说的 单元测试 是开发人员在自己的代码正确编译后、在交给功能测试小组之前进行的所有测试和分析。正如我们在 这只是一个测试 中提到的，主动进行单元测试并 在测试时像一位测试者那样思考（即，必须往坏处想、热衷于破坏并喜欢恶作剧）是很重要的。下面是在单元测试时要记住的几件事。 静态代码分析工具 第一种，也是最容易的分析代码的方法是让别人替您做 —— 或者像在这里一样，让其他 工具 替您做。有一些不同的静态代码分析工具可用，从综合性的工具 —— 一些开发机构实际上在他们的“编译”环境（这可是需要购买的）中加入了这样的工具 —— 到其他可以免费从 Internet 上下载的工具。 发现缺陷 当您准备运行代码并检查缺陷时，要记住往坏处想。这些缺陷是您所创建的或者由您忽略的代码产生。下面是一些帮助您找到代码中缺陷的提示： 试着强行制造您所想到的所有错误条件并检查可以出现的所有错误消息。 试着使用与其他组件或者程序交互的代码路径。如果其他程序或者组件还不存在，那么就自己编写一些脚手架代码以使您可以试用 API 或者填充共享内存、共享队列，等等。并让您的功能测试小组可以使用这个脚手架代码，这样他们就可以把它加入到他们的武器库中。 对于 GUI 中的每一个输入字段，试验下面多种不同的组合（考虑 自动化）： 不可接受的字符（控制字符、非打印字符等）。 过多的字符。 过少的字符。 负数（特别是当您只期待正数时）。 过大和/或者过小的数。 剪切和粘贴数据和文本到输入字段，特别是当您编写的代码限制用户可以键入该字段的内容时。 文本和数字的组合。 全大写字母和全小写字母。 为代码创建“压力条件”，如大量活动、慢连接的网络和所有您想到的可以将代码推到极限条件的东西。 反复进行同样的步骤，然后： 检查未预计到的内存损失条件。 检查当内存用光时发生什么。 试图创建缓存溢出、满队列、不可用的缓存以及其他“不能正确工作”的情况。 对于数组和缓存，试着向数组（或者缓存）增加 n 个数据项，然后试图删除 n+1 个项。 关于时间的考虑？ 如果操作“b”在操作“a”之前发生会怎么样？就算您 认为 它不会发生 —— 您能 使 它发生吗？如果是的话，可以打赌您的客户会使它发生的。最好现在找出来，而不是在修复成本更高、并听到客户报怨您的软件质量糟糕之后再去做。 脚手架代码 我们在前面 发现缺陷 中讨论了脚手架代码。如果是为自己的使用需要而创建的，一定要将它交给验证工程师。可能您提供的脚手架代码使他们可以很快地开始测试您的代码，或者至少使他们更好地理解当其他组件存在时可以预期什么。 如果您的产品有保护性的安全功能，那么您必须测试它们。提供可以创建您想要防止的情况的脚手架代码是很重要的：您必须能够创建系统试图防止的那种情况。 脚手架代码的另一个简单例子是提供操纵队列的代码。如果您的产品使用队列，那么想像如果有一个可以在运行时从队列中增加或者删除项、破坏队列中的数据（以保证适当的错误处理）等等的工具会有多方便。 源代码级调试程序 使用源代码级的调试程序是进行彻底和成功的单元测试的关键方法。开发人员应该与他们的调试程序共生死。不幸的是，对源代码级的调试程序的充分了解和使用是一种正在消亡的做法，尽管这些调试程序的好处远远超过任何学习曲线。简而言之，我们强烈鼓励您全面学习一种调试程序。下面是用源代码级调试程序对代码进行单元测试的几种方法。您可以： 在运行中操纵数据 —— 例如，在输入代码时设置中断点，然后重新设置传递的参数值以检查代码是否能正确处理（现在为）无效的参数。以这种方式使用调试程序就不需要让错误条件真正发生。 设置断点，然后“单步”通过代码，这样您就可以看到每一行代码所做的事情。 设置对变量的“监视（watch）”。 强制使用错误代码路径。 观察调用堆栈以检查哪一个例程调用了您的代码。 在错误发生时“捕获”它们。 执行边界检查。 认识您的验证工程师 验证工程师是测试知识的很好来源。他们可以给您指出要测试什么并帮助您了解可以在代码中加入什么以帮助他们测试（如代码钩子）。此外，您可以向他们展示如何使用您的脚手架代码。他们还会很有兴趣了解您认为在测试中哪些应该是自动化的 —— 如果您某些事情做了不止一遍，那么他们也会。 开始测验! 现在是进行小测试的时候了。让我们看看您是否用心了。 问题 您希望检查一个整数的值是否为 5。通常，要这样编写代码： if ( i == 5 ) then   {     //     // do something...     //   } 不过，如果您对代码进行“手指检查”，并且把代码写成了下面这样会出现什么情况呢？ if ( i = 5 ) then   {     //     // do something...     //   } 这个失误是一个缺陷，但是只有在运行时才能捕获它 —— 可能需要相当的调试努力才能找到它。编译器会轻易放过您的代码，那么如何防止这种错误发生？ 答案 实际上有两个答案：您可以使用一种上面描述的静态代码分析工具，并希望它有足够的健壮性可以捕获这种错误，也可以交换操作数以使常量位于左边： if ( 5 == i ) then   {     //     // do something...     //   } 因为这种方法保证您可以在编译代码时立即捕捉到问题，所以它是首选的技术。虽然它看上去有些笨，但是代码可以编译并运行得很好。然而，当您“手指检查”代码时就可以立即看到好处了： if ( 5 = i ) then   {     //     // do something...     //   } 可是编译器不喜欢这样，因为 5 不能被赋值为另一个值。这就是我们在 前面 说您应当将编译器看成是您的朋友时所表达的意思。 您还可以在检查 null 指针时使用这个技巧。看下面的代码： if ( returnString == null )   {     //     // do something...     //   } 如果您偶然将它“误写”成下面这样会发生什么呢？ if ( returnString = null )   {     //     // do something...     //   } 您可能不会得到想要的结果。而改用下面的方法您会得到与我们刚描述过的同样的“编译器保护”： if ( null == returnString )   {     //     // do something...     //   } 结束语 为保持简明扼要我们做了一个相当简洁的归纳：要么现在去做，要么以后花 多得多 的代价去做。换句话说，您在开发周期的早期在测试和预防代码缺陷上花的时间越多，您在以后节省的时间和金钱就越多。这就是防御性编码的意义。它就是这么简单。

杨粼波 2006-07-05 22:24 发表评论
]]>