管理员辛苦了！
谢谢！ 多谢，全部下下来慢慢看～ 后面的我简单做了一下合集，希望对象我一样刚来的有帮助（12月后期）
第167贴【2004－12－24】：选择合适的覆盖率指标
覆盖率的种类有很多，有简单的也有复杂的，如果我们针对每种覆盖率都要进行测试的话，那么我们的测试成本将变得非常昂贵，测试本身也将变得无法实现。现在的软件开发讲究的是一个市场的快速适应，这要求我们能够使用尽可能短的实际让产品能够稳定下来，所以对测试就提出了更高的要求，一般产品都希望能够化最小的代价得到最大的测试效果。同样，如果只考虑一种覆盖率指标，会使得我们遗漏一些重要的方面，不同的覆盖率所考虑的重点是不同的，尤其当我们只考虑比较弱的覆盖率的时候，如语句覆盖，我们会丢失很多在路径，判定，条件上的错误信息。
各种不同的覆盖率度量有其不同的优点和不足，实际测试时可以结合实际情况进行选择。可以对各覆盖率度量用下面几个方面来进行衡量：可获得性、可理解性、完整性，每个方面的评价又分5种不同级别：好、较好、一般、较差、差。如：
语句覆盖：可获得性（好） 可理解性（好） 完整性（差）
判定覆盖：可获得性（好） 可理解性（好） 完整性（较差）
条件覆盖：可获得性（好） 可理解性（好） 完整性（一般）
路径覆盖：可获得性（较差） 可理解性（一般） 完整性（好）
。。。
第168贴【2004－12－27】：不要绝对的去追求100％的覆盖
不要绝对的去追求100％的覆盖，当然，如果有足够的资源和时间，达到100％的覆盖是现实的。但事实上，为了要达到100％的覆盖将付出极大的成本。并且也不是必须的，对于一般性的软件（对于涉及到生命安全方面的系统要求有100％的覆盖）应当设置一个合理的覆盖率标准。研究表明80％的错误隐藏在20％的代码中，从成本效率考虑，你应当把覆盖率结合代码静态分析工具一起使用，去覆盖那些最容易出错的代码，而忽略那些简单的和不易出错的代码。
另一个方面，在用例设计的时候，你可以尽可能的设计高覆盖率的用例，但这些用例是否一定要通过代码执行来验证却是可以变通的。
第169贴【2004－12－28】：软件风险分析
IEEE软件测试文档编制标准对于测试计划模板中有一部分称为“风险与应急措施”的内容。其中可以分为两部分：软件风险分析、计划风险与应急措施分析。
在软件开发项目中，软件风险分析是非常重要的活动之一。如果进度安排十分紧张、资源匮乏，那么就更应该进行这项工作。
软件风险分析的目标是：确定测试对象、测试的优先级、以及测试的深度。有时候，可能还包括确定不予测试的对象。风险分析能够帮助测试员识别出高风险的应用程序（需要进行更加彻底的测试）和特定应用中具有潜在错误倾向的构件（需要进行比其他构件更加严格的测试）。在测试计划阶段中，可以将风险分析的结果用来确定待测软件的测试优先级。
我觉得还可以细分
1）测试活动本身的风险分析：进度安排十分紧张、资源匮乏，测试活动不能保证
2）对待测对象的风险分析：确定测试对象、测试的优先级、以及测试的深度
第170贴【2004－12－31】：何时进行风险分析
风险分析工作应该在软件生命周期内尽早进行。通常，最早的风险分析应该在确定了高级的需求之后就马上进行。对于每个发布版本而言，并不需要重新进行完整的风险分析，但是，却需要根据正在实施的变动对风险分析进行再次审视。同时要记住，因为需求、资源和其他因素可能会发生变动，所以，必须在项目进行的过程中时时对分析结果进行分析。 （2005年1月上）
第171贴【2005－01－04】：测试计划－－测试计划等级
测试计划应该发生在不同的阶段中。我们考虑的第一个计划是总体测试计划，它可能是一份独立的文档，也可能被包含到项目计划中，作为其中的一部分内容。总体测试计划的目标是协调各个等级的测试。IEEE标准829－1998软件
测试文档编制标准中确定了下述的测试等级：单元级、集成级、系统级和验收级。其他组织采用的等级可能不完全是四个等级，并且可能会采用不同的名称。我们常常会见到的其他一些等级（或者其他一些叫法）包括：Alpha级、Beta级、客户验收级、开发级等。
测试计划是最终形成一份文档的一个过程，在测试计划中，尽管文档十分重要，但是做计划的过程也许最终比文档还要重要。如果在项目生命周期的早期对有关测试什么和如何进行测试的问题进行讨论，不但可以节省大量的时间和金钱，还可以避免以后的分歧。
第172贴【2005－01－05】：测试计划－－读者分析
在制订某个测试计划时，你首先应该向自己问这样一个问题：“谁将是我的读者？”单元测试计划的读者与验收测试计划或总体测试计划的读者是不同的，所以，应该对措词、首字母缩略词的使用、技术术语和行话进行相应的调整。同时，还要注意，不同读者对于他们喜欢或者憎恶阅读的内容的容忍程度是不一样的。
第173贴【2005－01－06】：测试计划－－测试计划的时间安排
通常测试计划开始得越早越好。比较合适的时机是：差不多在制订需求规格说明书和项目计划的同时就开始制订总体测试计划。
如果测试计划开始得足够早，就可能而且肯定会对项目计划的内容产生重要的影响。验收测试计划可以在需求定义过程启动之后就马上开始。比如，我们的一个客户就将验收测试计划和高级测试场景作为需求规格说明的一个组成部分。同样，系统测试计划、集成测试计划、单元测试计划也应该尽早启动。
当早早地开始计划过程时，测试计划制订者常常会变得十分沮丧，因为他们会发现：所有需要的信息要么是不能获得，要么是处于一种起伏不定的状态。有经验的测试计划制订者需要在遇到计划中的某个还不太明朗的部分时，运用TBD（待定）战术。这种做法本身就十分重要，因为测试计划制订者可以看清自己的工作重点，突出了还未完成的工作。
第174贴【2005－01－07】：测试计划－－计划模板
软件组织有必要制订自己的测试计划模板，建议在参考IEEE标准829－1998软件测试文档编制标准的基础上结合自身的实际情况制作，它能为建立自己的自定义模板提供一个良好的基础。在许多情况下，IEEE模板可能已经符合软件组织的需求而无需变动，这时可以直接拿来应用。
如果模板不能符合企业的具体要求，可以随心所欲的按照需要对其进行自定义。随着应用时间的增加，你可能会发现在模板中某些项总是留下空白，如果你能确信这些项与你们组织没有太大关系，那么可以调整模板，把这些项目去掉。如果某些措词在各个计划中都是相同的，那么必须确定是否说清楚了这个问题。如果确信已经说清楚了这个问题，那么建议将这部分内容转变成为标准方法的一个组成部分，并将这部分内容从测试计划中删除。
有时候一个测试计划需要考虑某个特定项目或发布版本的特殊情况，并且可能需要根据某些项目进行自定义，所以模板中的模型部分可能需要列为可选项。
第175贴【2005－01－10】：测试计划－－测试计划文档的各个组成部分
IEEE标准829－1998软件测试文档编制标准
测试计划模板
目录
1。测试计划标识符
2。目录表
3。参考文献
4。词汇表
5。介绍
6。测试项
7。待测特征
8。不予测试的特征
9。方法
10。测试项通过/失败准则
11。挂起准则和恢复需求
12。测试交付物
13。测试任务
14。环境需求
15。职责
16。人员安排与培训需求
17。进度表
18。计划风险与应急措施
19。审批
第176贴【2005－01－11】：测试计划－－测试计划标识符
为了跟踪测试计划的最新版本，需要为其指定一个标识数。如果软件组织有自己的标准文档控制系统，那么会自动赋值，用于标识测试计划的版本、等级以及与该计划相关的软件版本。
测试计划和其他软件文档一样，本质上是动态的，需要及时更新。在对软件组织的测试计划进行审核时，需要对测试计划标识符进行审核。如果没有标识符，那么这意味着建立了测试计划后从未进行过变动，甚至可能从未使用过。更有甚者，测试计划仅仅是为了完成一项任务而进行的写作活动，没有任何指导意义。
第177贴【2005－01－13】：测试计划－－参考文献
IEEE推荐的参考文献包括：
。项目授权
。项目计划
。QA计划
。配置管理计划
。相关政策
。相关标准
IEEE标准还规定，在多等级的测试计划中，每个较低等级的计划必须要以相邻的较高等级的计划作参考。另外还有一些需要考虑的参考文献，包括需求规格说明、设计文档和其他能够提供额外相关信息的文档。列在这一部分的每一项都应该包括文档名、日期和版本，以及联系位置或联系点。参考文献增加了你们的测试计划的可信度，同时便于读者确定哪些主题值得进行进一步研究。
第178贴【2005－01－14】：测试计划－－测试项
测试计划的这部分主要是纲领性地描述在测试计划范围内需要对哪些内容进行测试，以及应该与配置或程序库管理者和开发员协作完成哪些工作。这部分内容可以面向测试计划的等级来完成。对于较高的等级，这部分内容可以参照应用程序或版本来组织。对于较低的等级，这部分内容可以参照程序、单元、模块或者构建来组织。例如，如果这是一个财会软件总体测试计划，这部分内容可能包括与财会软件的2.2版、用户手册的1.2版和需求规格说明的4.5版相关的信息。如果这是一个集成或者单元测试计划，这部分内容实际上可能会列出待测程序（如果这些程序可知的话）。IEEE标准中指出，可以参考下面的文档（如果有的话）来完成测试项：
。需求规格说明
。用户指南
。操作指南
。安装指南
。与测试项相关的意外事件报告
注意，应该将那些将会被明确排除于测试之外的项标识出来。 （2005年1月下）
第179贴【2005－01－17】：测试计划－－待测特征和不予测试特征
测试计划中待测特征这一部分列出了待测的内容（从用户的角度出发），这与测试项相反，测试项是从开发者的角度对待测内容的度量。例如，如果要测试某台自动取款机（ATM），其中的待测特征可能包括：取款、存款、查询帐户余额、转帐、偿还贷款等。对于较低等级的测试而言，待测特征可能还要详细得多。
测试计划中不予测试特征这部分用来记录不予测试的特征及其理由。对于某个特征不予测试的理由很多：可能该特征前后版本没有发生变化、可能因为该特征还不能投入使用。。。但是，一个特征之所以被列在这个部分，是因为它被归结为具有较低的风险，所以确定哪些特征不予测试之前，需要进行一定的风险分析。
第180贴【2005－01－18】：测试计划－－方法
测试方法是测试的核心所在，所以有些组织更愿意将其标记为“策略”而不是方法。这部分内容包括：描述如何进行测试、解释对测试（并不是对被测项目）的成功与否起决定作用的所有问题。
对总体测试计划而言，应该对各个测试阶段所采用的方法（包括从一个阶段到另一个阶段的入口和出口准则）进行解释。
标准的测试阶段有单元测试、集成测试、系统测试和验收测试，有些组织会根据实际情况对这些阶段进行合并、删除或增加，或者对这些阶段取不同的名字。每个阶段是在特定的环境下定义的，环境中可能包括硬件配置、软件配置、接口等等，随着测试阶段不断进行较高的阶段，环境将逐步向真实情况靠拢。最高的测试阶段（如验收测试）应该尽可能真实的反映产品环境。
第181贴【2005－01－19】：测试计划－－测试项通过/失败准则
测试计划的这个部分描述每个测试项的通过/失败准则。正如每个测试用例都需要一个预期的结果那样，每个测试项同样需要一个预期的结果。一般来说，通过/失败准则由通过和失败的用例、bug的数量、类型、严重性和位置、可使用性、可靠性和/或稳定性来表述的。随着等级的不同和组织的不同，所采用的确切标准也会有所不同。
每个用例的重要程度等级是不一样的。尽管执行测试用例的百分比是一个常见的度量，但它经常会提供误导信息。比如，核控制设备的测试中，即使95％的测试用例获得通过，但是“核切断开关“的测试失败，那么其他的用例通过并没有什么意义。
通过/失败标准包括以下一些例子：
。通过的测试用例所占的百分比
。缺陷的数量、严重程度和分布情况
。测试用例覆盖情况
。。。。。。
第182贴【2005－01－20】：测试计划－－挂起准则和恢复需求
测试计划这部分内容的目的是：找出所有对测试进行暂时挂起的条件和恢复测试的标准。测试人员在执行测试的过程中往往都备受折磨，经常会遇到一些导致测试执行困难的事情。在遇到这些困难的时候，虽然也欣赏测试人员排除万难继续前进的精神，但有时候继续执行测试是毫无意义的事情。以路由器测试为例，在路由转发基本功能测试中出现重大缺陷的情况，继续测试路由转发性能是毫无意义的，测试出的性能指标也无任何指导作用。甚至有些时候，某个特性的测试不通过，会导致其他特性无法执行测试，大量用例被堵塞。这时候可以用甘特图来显示测试活动之间的依赖关系，一旦关键路径上的测试执行失败，就需要挂起后续的测试活动。
常见的挂起准则有：
。在关键路径上未完成任务；
。出现大量的BUG，测试执行下去无意义；
。资源短缺；
。不完整的测试环境
。。。。。。
第183贴【2005－01－23】：测试计划－－测试交付物
这部分包含了为了支持测试工作需要开发和维护的所有文档、工具和其他构件的列表。测试交付物包括这样一些例子：测试计划、测试方案、测试用例、测试规程、开发的测试工具、缺陷报告、测试报告、仿真器、测试数据等等。待测软件不属于测试交付物。
在总体项目计划中需要确定为测试工作提供支持的制品，以作为交付物，并且需要在项目跟踪系统中为其分配合理的资源。这保证了测试过程在总体项目跟踪过程中的可见性，也保证了以建立这些交付物为目的的测试任务能够在合理的时间被启动。
第184贴【2005－01－24】：测试计划－－环境需求
环境需求包括：硬件、软件、数据、接口、设备、出版物、安全访问以及其他一些与测试工作相关的需求。应该尽量将测试环境配置成与真实系统相似的环境。如果确定该系统将会运行于多种配置（硬件、操作系统，等等），那么就需要决定：是复制所有这些配置，还是只复制风险最高的配置；是复制最常见的配置，还是采取其他的组合方法。在决定硬件配置时，不要忘记还要将系统软件需求列入其中。
除了指定硬件和软件需求外，还需要确定数据的出处，以便能填充测试数据库。数据项可能包含以下方面：产品数据、购买的数据、用户提供的数据、生成的数据和仿真器。到此为止，你还应该确定如何确定数据，并评估其脆弱性，以便对数据的更新频度有一个清楚的了解。
在对测试环境进行规划时，需要确定各接口的风险，明确用接口连接的系统已经存在，如果这些系统还未准备好，我们需要做的全部工作就是对设计规格说明或者某种类型的协议进行处理。如果该接口还未成型，则需要构造仿真器来代替。
第185贴【2005－01－25】：测试计划－－任务职责
在这部分内容里，我们需要描述每个任务的责任人，以及每个责任人在完成该任务中的职责。这里可以用一个矩阵显示各任务和各责任人之间的对应关系，主要的任务有测试方案、测试用例设计、测试执行等。有的人喜欢在职责矩阵中列出职务，如测试经理，因为他们认为负责各种工作的小组成员会发生频繁的变动，列出职务会避免因此所造成的测试计划文档的频繁修改。而我比较倾向于列出责任方的姓名，因为把某人的姓名和某项任务联系在一起比列出部门或职务更能引起他们的关注。
第186贴【2005－01－26】：测试计划－－进度表
测试进度应该围绕着包含在项目计划中的里程碑（比如各种文档和模块的交付日期、资源、接口的可用性等）来构造。然后，需要添加测试中的所有里程碑。测试中的这些里程碑的详略程度各不相同，它取决于正在构造的测试计划的等级。在总体测试计划中，里程碑将围绕着主要的事件，比如需求与设计评审、代码交付、用户手册的完成，以及接口的可用性来构造。在单元测试计划中，绝大多数的里程碑是建立在各种软件模块完成的基础之上的。
在项目的初期，通常是采取构造一个没有规定日期的普通进度表的形式；也就是说，确定各种任务所需要的时间、各种任务的依赖关系，但是并不指定任务具体的开始和结束日期。通常，该进度表是用甘特图来表示的，以便显示各种任务的依赖关系。为制订进度表，我们必须对时间和资源进行非常精确的估计，如果时间进度的安排十分紧张，那么估计工作就显得尤为关键，以便能够为测试确定计划风险和应急措施，以及优先级。以估计值为基础记录的进度表，还为测试经理提供了一个审核线索：估计数据为何获得了或者没有获得通过，并且为在未来进行更好的估计工作奠定了基础。 （2005年2月）
第187贴【2005－02－01】：测试计划－－审批
审批人应该是有权宣布软件已经为转入下一个阶段做好了准备的某个人或某几个人。比如，单元测试计划的审批人可能就是开发经理。系统测试计划的审批人可能就是负责系统测试的人员和任何准备在下一个步骤接手产品的个人（如果他们准备进行验收测试，那么这个人很可能是客户）。因为这是一个总体测试计划，所以其中可能会存在大量的审批人，包括：开发员、测试员、客户、QA、配置管理部门以及其他人员。
如果在计划写成之前和审批者没有沟通，到写成之后再拿着文档四处请求批准，那么所能得到的仅仅是一个签名而已。为了获得我们所期待的承诺，我们应该尽量使审批人，或者审批人的代表在测试计划的开发过程中参与测试计划的制定或评审工作。作为一个测试计划的制订者，要想让所有的审批人参与到计划的制订中来，确实是一项挑战。
测试计划牵涉到许多方面的工作，可能需要耗费大量的时间。但我们无法在没有一份良好的测试计划的前提下就开始测试工作。
第188贴【2005－02－02】：单元测试中的度量
单元测试的一个优点在于：能够对单元级的度量进行收集，这有利于在开发过程的早期识别出那些存在问题的区域，虽然这并不一定是一个直观的概念。在这里识别出有大量缺陷的程序或模块，一般都还会残留很多未被检测到的缺陷。发生这种现象的一个原因是因为程序很复杂，已发生缺陷掩盖了其他缺陷的发现，另外的一个原因可能是因为bug修复的过程中又引入一些bug到系统中。一些组织可能会将在单元测试中识别出的那些容易存在缺陷的模块标记为高风险模块，并确保这些模块在进行集成和系统测试之前能够受到充分的重视。在单元测试过程中的高缺陷密度可能还表明，需要为后期的测试阶段分配更多的时间。
在单元测试期间收集度量还会有助于估计未来发布版本的测试时间和资源，并有助于识别出需要过程改进的区域。
第189贴【2005－02－03】：伙伴测试
在单元测试的操作过程中，建议采用一种小组方法（暂且称之为伙伴测试）来进行编码和单元测试。即在整个编码和单元测试阶段，建立一些“两人小组”，并且分别安排各种编程任务。开发人员A在开发人员B开始编码之前为B的设计编写测试用例，开发人员B同样需要在A开发编码之前为A的设计编写测试用例。这样有以下好处：
1、在单元测试中提高测试的客观性；
2、在编码之前完成测试用例能保证设计的质量，同时也能改变开发人员编码的方式，这是预防性测试的一种；
3、伙伴测试提供了人力资源的技术备份，提高了人力资源风险的规避能力。
第190贴【2005－02－21】：测试分析与设计
测试分析与设计就是确定测试目标的过程，以及确定如何以一种支持高效执行的方式组织测试目标的过程。测试工程师可使用各种技术进行测试分析和设计，清单技术是其中的一种。
测试目标包含了一个给定的应用程序中需要进行测试的事项的所有范畴。比如，一个汽车保险程序的测试人员可能会确定如下目标：汽车类型、地理位置、驾驶员年龄、汽车使用年限、汽车的安全特征、汽车的主要用途，等等。
清单是根据每个测试目标确定的需要测试事项的实际列表。比如，“汽车类型”的清单可能会包括：SUV、跑车、老式汽车、越野车、轿车，等等。
许多目标都是各个被测应用程序所特有的，例如本例中“汽车类型”这个目标就不适用于ATM应用程序。但是某些目标是完全能够普遍适用的，所以可以将这些目标称作公共目标。比如，接口就是一个公共目标。
很可能绝大多数的应用程序都需要将自己与其他系统相连的所有接口进行测试。所以，每个应用程序的测试都需要建立一个应用程序所特有的接口清单。
第191贴【2005－02－22】：清单技术进行测试分析设计的过程
建立清单的过程是一个由多个步骤构成的过程，一般来讲有如下的步骤：
步骤1：收集参考材料，包括需求、设计文档、用户手册等等；
步骤2：组成头脑风暴小组，小组包括三到四位专家，如开发人员、测试人员和业务分析师；
步骤3：确定测试目标。头脑风暴小组将编制一个测试目标列表（如测试需求或种类）；
步骤4：确定目标的优先级，这需要根据覆盖率和风险来确定；
步骤5：识别每个目标必须进行测试的条件，分析目标，建立列表；
步骤6：建立清单跟踪矩阵，将现有的测试用例映射到清单中；
步骤7：为未涵盖的条件确定测试，每个条件至少建立一个测试用例或者修改现有的测试用例；
步骤8：为每个清单项评价测试用例的充分性，必要时进行增删；
步骤9：维护测试矩阵，每个新的软件发布版本的测试用例需要进行增加、修改和删除。
第192贴【2005－02－23】：测试分析和设计－－确定测试目标
在清单技术中需要建立待测事项的各种列表。但是，不要预先就对各个列表进行彻底的核查，同样也不要把列表做得太细。常见需求目标的例子包括如下一些内容：
。函数或方法
。约束或限制
。系统配置
。与其他系统的接口
。输入和输出属性的条件
。系统/对象存储的条件（即影响处理的各种状态）
。将输入和存储条件（即对象状态）与结果函数相链接的行为规则
。关键的使用与操作场景
。根据对系统的外部分析得出的需要考虑的其他问题
当然，还会存在许许多多的其他测试目标，而且总会存在某个系统特有的一些测试目标，但是上面的列表能让你了解正在探询的各种事项。不必担心会存在目标或者清单的重叠，我们是从不同的角度对系统进行审视，以确定可能会被测试的内容，至于内容的冗余，可以考虑在后续步骤中消除。
第193贴【2005－02－24】：工具的陷阱－－没有清晰的策略
关于工具使用，最容易犯的一个错误是，对测试工具如何推动测试工作全面成功还没有一个清晰的概念，就早早的推行了一个工具。
工具的选择和使用要根据它们是否能推动所制定的整体测试策略。选择一个工具，然后调整自己的规程以匹配这个工具并不是一个好的做法，尽管有的时候不得已要这样做。关键是要找到一个有助于实现你们策略的工具，而不是工具供应商的测试策略。
当然可能存在这样的情况：你们根本没有实现某一过程或功能，需要依据工具来建立。例如，还没有自己的缺陷跟踪系统，那么会选择一个流行的工具并围绕这个工具构造自己的缺陷跟踪过程。但是，大多数情况下，需要首先定义过程，然后选择一个有助于推动该过程的一个工具。
第194贴【2005－02－25】：工具的陷阱－－过高的预期
管理人员（尤其是上层管理人员）都希望在购买一个工具之后，测试工作将会有立竿见影的效果，变得更好、更快、更便宜，能发现更多的缺陷。虽然某些项目可能会取得这三方面的成功，但是大多数的项目却只能考虑一个或两个方面的成功。引入测试工具只能提高测试效率，并不一定能发现更多缺陷。工具引入后达到的实际改进水平需要进行量化，否则将无法确定工具的推行是否取得了真正的成功。 （2005年3月）
第195贴【2005－03－01】：工具的陷阱－－缺乏支持
工具能给我们的测试工作带来帮助，但工具的使用也存在一定的风险。缺乏支持就是很大的一个风险。如果测试计划中没有考虑这部分风险，那么当工具使用过程中出现问题，而本公司人员无法解决时，会导致测试计划延期，甚至测试根本无法完成。
这样的风险在采购测试工具的时候就要考虑到。即选购测试工具的时候，能不能提供技术支持，能多大程度上提供支持，是做最终选择的很重要一个因素。通常要考虑以下方面：
。有没有技术支持文档、文档详尽程度如何、有没有中文的支持；
。有没有技术支持中心，最近的支持中心有多远；
。对于今后出现问题，能承诺多快的时间内做出反应；
。能不能提供在线帮助
。。。。。。
特别是国内存在着一些盗版工具使用情况，那么更加要考虑缺乏支持的风险。使用盗版虽然能省投资，但由此引起的计划延期等造成的损失也许会更大。
第196贴【2005－03－02】：工具的陷阱－－缺乏有效的培训
大多数的测试经理都知道，必须对测试工程师进行如何使用新工具的培训，但不幸的是，时间和培训量常常被低估。同样，有时候培训工作开展得太早，在培训和工具的首次使用之间存在一个巨大的时间间隔。进行了培训而没有及时使用，这样的培训通常都没有多大价值。实际上，作为一条粗略的经验法则，如果在培训之后的的6个月内没有使用这个工具，这些经过培训的工程师基本上就与没有进行过任何培训的差不多。
与培训相关的另外一个问题是：如何使用工具对软件进行实际的测试。工具培训不应该只包含如何安装工具、如何敲键盘。我们应该将培训和实际的测试工作对象结合起来，帮助工程师了解如何利用工具实现我们的测试。
第197贴【2005－03－04】：工具的陷阱－－错误对象的自动化
我们应该尽量避免一个经常容易犯的错误，即对不应该实行自动化的对象进行了自动化。通常来讲，各种人力密集型和重复的任务是自动化的首选对象。但是，在有些情况下，自动化却是得不偿失。例如，预计运行次数仅为一次的测试用例就不是自动化的一个好的选择；当一个系统正在经历快速的变更时，通常也不要耗费更多的资源来实现测试自动化，因为系统尚未处于稳定状态；另外，对人和系统的接口进行检验的测试也不能实现自动化。
第198贴【2005－03－08】：工具的陷阱－－选择错误的工具
为了选择正确的工具，很重要的一点是，要明确提出工具的选择和应用方面的需求。例如：需要有录制回放功能、需要能编辑脚本、需要能提供测试日志、能提供性能分析工具、需要能识别所采用的第三方控件。。。特别要注意的是，和所有的软件需求一样，这些需求也应该排定优先级顺序。如果对于将要采用的工具没有一个清楚的要求的话，将会导致选择错误的工具。
第199贴【2005－03－09】：工具的陷阱－－选择错误的供应商
这是一个十分敏感的话题，但是在实际的工具采购中，并不是所有的供应商都能满足同样的标准。在选择供应商时，特别要注意选择一个能与团队融洽相处的供应商。工具供应商对于公司一些需求的响应是一个工具取得长期成功的一个关键因素。选择供应商的另外一个重要因素是他们提供的培训和服务。下面列举一些在选择供应商时应该考虑的方面：
。他们是只向测试人员展示预装样例的情况下如何使用这个工具，还是确实提供了与你们的应用程序相关的培训？
。在购买工具后，获得现场帮助的方便程度如何？
。在演示工具的时候，供应商只是派来了销售人员，还是同时派来了能深入回答问题的技术人员？
。供应商是否会组织用户年会或区域性用户团体？有这种机制的供应商通常比没有这种机制的供应商更注重客户的想法。
。工具能否进行调整以满足你们的需要？
第200贴【2005－03－10】：工具的陷阱－－不稳定的软件
在确定是否实现测试用例的自动化时需要考虑的另外一个重要因素是：待测软件的稳定性。如果放入测试环境的软件质量很低劣，或者因为某种原因正处于不断变更中，那么某些测试用例将可能不得不在每次修改待测软件时进行相应的修改。如果编写自动化脚本比手工脚本花费的时间更长，那么待测软件就不是自动化的好选择。
如果被测应用程序正处于不稳定或快速变更的状态，自动化测试脚本的工作可能会显得十分困难。
第201贴【2005－03－12】：工具的陷阱－－做得太多、太快
和任何流程改进一样，引入工具需要从细处着手，并对引起的变更进行限制。通常，我们试验新工具时更愿意在一个试点项目上进行，而不会一下子进行全面推行。一次只引入一个，或者至少是有限数量的工具。如果同时推行多个工具，很可能会使资源变得十分紧张，而且也难于判断每一个工具对测试工作的成功产生的影响。
第202贴【2005－03－14】：工具的陷阱－－低估时间、资源
糟糕的进度安排、低估工具推行所需要的时间和资源，这些可能都会对一个测试工具的成败产生重大的影响。推行工具可能会花费很长的时间，即使是在一个小型的组织中推行一个工具也可能会花费几周甚至几个月的时间。引入工具前必须确认在增加这些工作量后，是否还能真正受益。
第203贴【2005－03－15】：工具的陷阱－－不充分或独特的测试环境
某些组织购买的工具，会出现由于自身测试环境不充分而无法有效地利用这些工具。这里所指的环境包括数据库、文件、文件结构、源代码控制、配置管理，等等。如果想成功地推行测试工具，就有必要将自己的开发环境和测试环境准备妥当。
另外一种常见的问题是，组织应该自己购买还是开发工具。通常情况下，购买工具都胜过自己构造工具。因为自己开发工具必须要做很多事情，如编制文档、测试和维护，并且这是偏离组织核心业务的。购买工具实际上是让各个用户分摊了工具的开发、测试、维护费用。但一些特殊的情况下自己是不得不构造自己的工具的，例如：嵌入式系统，没有通用的工具适合你的嵌入式平台。
第204贴【2005－03－16】：变体分析
变体分析有时被用做核查单元测试质量的一种方法。进行变体分析的基本方法是：先往一段代码（比如一个单元）中插入一个变体语句（比如BUG），然后再运行单元测试用例，以确定能否检查到这个变体。
如果单元测试集是全面的，变体就应该能被发现。如果不能发现变体，就说明单元测试集不够全面。但是这不能反推：因为发现了变体，并不能说明测试集就是全面的。
变体分析只对那些已经获得高水平的代码覆盖的组织有效，因为变体分析是建立在这样一个前提之上的：所有的代码行都已经被覆盖，现在只是在查找一个异常的地方。除非测试组有大量的时间，否则应该把注意力转移到更为有用的事情上，比如达到一定的逻辑覆盖指标。
第205贴【2005－03－18】：测试执行－－由谁来执行测试
在不同的测试阶段，可能参与测试执行的人不一样。在单元测试阶段，由于受到测试人力资源（数量和技术）的限制，目前由开发人员来执行测试是很常见的。通常每个开发人员只负责对自己所开发的部分执行测试，但是最好是由程序员执行不同模块的单元测试（即前面介绍过的伙伴测试方式）。集成测试常常由开发人员或测试人员来执行。系统测试可由开发人员、测试人员、最终用户或者以上人员的组合来执行。而虽然开发人员、测试人员都可以参加验收测试，但是验收测试还是应该以用户为主导来执行。
从测试活动的技术层次上来划分，测试执行是技术层次最低的一种活动。在企业测试组技术层次划分合理的情况下，测试执行通常由测试员（或者称为初级测试工程师）来承担。当然这需要高层次的测试分析和设计质量有保证、测试用例设计、描述得足够清楚、易于理解。
第206贴【2005－03－21】：测试执行－－确定首先执行什么
选择首先测试哪些用例是一个具有策略性的决定，它取决于软件的质量、可用的资源、已有的测试文档和风险性分析的综合结果。如果是回归测试，那么需要根据这些分析来考虑是完全重复执行用例还是选择性重复执行用例，如果考虑选择性重复执行，那么又可以从不同的角度来选择应该执行的用例。如果是初次测试一个特性，那么应该对测试用例完全执行，在人力资源有限的情况下，可以考虑选择等级高、风险大的用例进行测试。
第207贴【2005－03－23】：外场测试
外场测试（Site Testing）主要用于验证系统在实际使用环境中能够正常工作。这类测试一般在一些大型的系统中经常会用到，比如电信系统，航天产品等。
外场测试是一个比较昂贵的测试，需要投入大量的人力和物力。而且场点的选择要具有一定的代表性。这类测试一般需要有专门的外场测试小组负责，并经过精心的策划。使用到的技术已经不仅仅局限在测试技术领域，包括了制造、维护、系统集成等领域。
有很多测试在实验室里是很难模拟的，并且许多问题只有在实际使用环境中才可能被暴露出来，外场测试是一个非常好的方法，有利于提高系统的可靠性。尤其对于可靠性要求很高的系统。
在英文中Site Testing还有一个意思是网站测试，主要用于验证一个网站是否符合设计规格（信息、接口和可视化设计）和可用性标准。
第208贴【2005－03－25】：测试过程中的用例更新
无论测试工程师如何擅长设计测试用例，用例设计得多么充分，在开始执行测试后，肯定会遇到用例需要更新（补充、修改、删除）。在执行测试的过程中，肯定会学习到关于系统的更多的知识，对系统有了更新更深的认识，使你能设计更多的新的用例。但在测试执行时，工作的重点更多的是放在用例的执行、测试点的观察、故障的排除上，很多关于用例更新的想法可能不会记录下来，但这些想法可能就是瞬间的事情，如果过了一段时间可能就会遗忘，这是很遗憾的事情，因为这些“探查性”测试用例常常是测试过程中产生的最有用的东西，我们完全应该把他们加入到测试用例库中去，因为提高测试集覆盖率是我们长期目标之一。有的测试工程师将一些附注加入到测试日志中，作为描述这些探查性测试用例的一种便捷方式。这样在测试执行阶段结束后，可以安排专门的时间来进行用例的更新，这时可以使用测试日志来进行回顾，记录下这些用例，然后把它们放入到测试用例库中。
thank
谢谢管理员您辛苦了 受益非浅 好好看下才行 好好看下才行 感谢感激。。。。
无限感激！ xiexie斑竹辛苦了 xiexie
斑竹辛苦了 顶，谢谢管理员的整理
