软件测试项目管理.doc

作者：白红勃 测试计划 测试项目管理 若你想成为优秀的测试项目管理者，你就反思如下内容是否做到： 1) 在一个项目中多与开发和产品负责人讨论并了解变化，因为我们的规范永远不能保证测试的输入没有遗漏； 2) 在一个项目中多参与测试方案、测试用例、测试方法、测试工具、测试过程、测试结果的评审与讨论，弥补下属或者自己考虑不周全的问题；最好可以请开发负责人参加； 3) 在一个项目中多考虑测试效率和测试效果的问题，这样可以不断启用新的测试方法和测试流程来提高效率、保证测试效果； 4) 在一个项目中多多进行阶段小结，这样可以弥补一些测试不足的地方，并很好地规划下一个阶段的计划；测试计划不是一成不变的，必须定期调整； 5) 在一个项目中涉及到变更时，要再次评审测试方案、测试用例、测试方法、测试工具；若频繁变更，则更要把握好节奏； 6) 在一个项目中要非常重视组件/模块的接口测试、集成测试，不仅表现在方案、用例上，同时也表现在测试时间的安排和人的协调管理上； 7) 在一个项目中要非常重视下属直接参与技术讨论会议的重要性，既树立他与开发人员沟通的信心，又加深了下属对项目的了解情况，对未来的工作开展非常有利； 8) 在一个项目中对于还没有掌握沟通技巧或者对自己没有信心的下属，请带着他一起和开发或者产品进行沟通，或者鼓励他去沟通，并了解他沟通的效果并指出下次沟通的注意事项； 9) 在一个项目中你要了解自己的知识面是否与该项目匹配，不匹配提前做好准备； 10) 在一个项目中你也要了解你的下属能力与该项目的要求是否匹配，若不匹配，要不换人，要不请开发来培训； 11) 在一个项目中你不要和下属争功，上级对你的考察永远是团队和项目，帮助下属成长和保证项目质量是你永远的责任； 12) 在一个项目中你的懒惰将会对下属和项目造成极坏的影响，因为你是核心。 若你还想往上发展，就不断地在项目中锻炼自己的同时，让自让自己多关注技术、管理和行业，缺哪个补哪个。概述TechExcel DevTest 是一套功能完善的、适用于软件测试生命周期的测试管理解决方案。从制定测试计划到分析测试结果，DevTest 帮助您全方位地管理测试流程。在DevTest中，您可以根据不同的产品版本，分别创建测试周期和管理测试流程，包括制定测试计划、分配测试任务、执行测试覆盖以及提交产品缺陷。以知识为核心的测试管理解决方案DevTest，为您的测试团队提供完整的项目视图，从测试计划、测试执行、到结果分析，每一个测试任务都与相应的知识文档关联，有效地提高团队工作效率和管理水平。 最值得一提的是，在您测试的过程中，DevTest为您的团队同步提供内置的动态测试分析。DevTest是您最明智、最理想的选择。 从 DevTest 中受益 全面控制和管理测试项目，通过跟踪测试任务、查看测试报告、分析测试结果，实时掌握详细的测试进度。 通过使用完整集中的测试知识库，提高产品的测试质量和管理标准。 简化的数据输入形式，可定义的测试界面，以及自动化管理流程，帮助您的团队有效提高工作效率。 包括测试案例、测试数据和测试结果在内的详细的历史记录，保证了测试工作的可追溯性和可核查性。 屏幕快照运行环境系统要求 客户端 Windows2000、Windows XP、Windows NT4.0或以上 Pentium PC机，256MB内存，100 MB硬盘空间 Microsoft .NET framework 1.1 服务器 Windows2000、Windows NT4.0或以上 Pentium PC机，1GB内存，500MB硬盘空间 Microsoft Internet Information Server (IIS) 5.0 或以上、ASP .NET 1.1 Microsoft .NET Framework 1.1 数据库 Microsoft SQL Server Oracle MySQL Microsoft Access 功能特性 全面的测试覆盖管理: 通过DevTes，t您不仅可以创建、管理、分析测试范围，还可以从中心知识库中调用原有的测试范围，以此提高您的工作效率、使您的管理流程更加标准化。 高度可视化的测试计划向导: DevTest 为您提供高度可视化的测试计划向导，您只需点击设置，就可以轻松地安排测试时间、分配测试任务、调整测试流程。 拥有 Windows 客户端和 Web 客户端两种架构: DevTest 提供具有相同功能特性的两种安装类型：Windows客户端和 Web客户端。无论您的测试工程师在办公室还是在地球的另一端，他们都能连接到DevTest系统中。 完全自定义用户界面: DevTest为您提供强大的用户自定义功能，您可以自定义字段标签、字段类型、下拉菜单选项、主从关系和用户报表。DevTest 能够完全满足您的测试需要、优化您的测试流程，是一款不可多得的测试管理工具。 成熟的工作流程设定: 在 DevTest中，您不仅可以为测试范围的生成、测试任务的执行而设定流程规则，也可以设置触发事件功能。当 DevTest中出现逾期未完成的任务时，系统会立即触发自动通知功能，并将测试任务重新分配。 自动提交缺陷: DevTest自动向开发人员提交产品缺陷，并与对应的测试任务建立关联。 内置报表分析: 内置的质量报表帮助您轻松分析测试趋势、掌握工作进展、总结测试缺陷。 什么是软件配置管理？1作者：不详来源：测试时代2008年6月10日发表评论进入社区 作为软件配置管理工作者，差不多都有这样的经验：在认识新朋友时，当别人问起自己所从事的职业，自然回答到，“我从事软件配置管理工作”。接着，十有八九，会被问到下一个问题“什么是软件配置管理?”。总被问到相同的问题，倒还称不上是苦恼，真正的苦恼在于回答这个问题，因为软件配置管理真是不太容易说得清解释了半天，结果往往是，“你这份工作好玄妙啊。隔行如隔山啊，我是搞不懂了。”是的，软件配置管理，确实不太好解释。软件开发过程中的其它工作，似乎都比它容易理解。开发工程师在编写源代码;测试工程师在测试，挑毛病;需求分析师跟用户确定需求，并且用精确严谨的语言表达出来虽说这样说未必严谨，但是至少能够得到一个大致的印象。但是，软件配置管理呢?软件配置管理是什么?下面是软件配置管理的一个权威定义：一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征;控制这些特征的变更;记录和报告变更的处理和执行的状态;以及验证其符合特定的需求。”如果你看得一头雾水，别担心，这不是你能力上的问题。大部分人和你的感受相同。这个定义，以及类似的权威定义，都高度抽象。用一两句话，确实很难把握好软件配置管理这个概念。需要更多的描述，才能把它说清楚。事实上，这一整本书，就是在认识和理解软件配置管理。而在这一章中，我们将用一些我们相对熟悉的概念来打比方，做对比，来讲解软件配置管理这个概念。通过这样一种方式，让大家对软件配置管理有一个初步的，但比较正确的认识。与图书管理作对比软件配置管理，是关于软件资产的管理。什么是软件资产呢?源代码，设计文档，可以运行的程序，这些在软件研发过程中产生的有价值的东西，都是软件资产。软件配置管理就是关于这些内容的管理。那么，具体有什么要管理的呢?让我们把它和图书馆的图书管理做个对比。它们有一些相似点。首先，图书管理管的是图书资产；软件配置管理管的是软件资产。这两种管理，管的都是信息资产。其次，图书管理，需要把图书进行分类，以便检索，需要将图书存放在合适的地方，以便存取，还要防止虫吃鼠咬；而软件配置管理也类似，需要把软件资产主要是源代码，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。再次，在图书馆，要记录谁借出了哪本书，还没还。这是为了保证，图书馆的书不会而软件配置管理中也类似，需要记录谁“借”出了什么文件，什么时候“还”的。在这一“借”一“还”的过程中，程序员修改了它，而软件配置管理记录下了这些修改。那么，为什么要记录呢？因为软件资产与图书资产不同，软件资产在不断变化，不断演进。项目初始的时候，可能只有一份简单的项目计划，而项目结束时，已是可以交付给用户的产品。如果缩小视野，单就某个源代码文件来看，也会看到，通常它会在项目的某个时刻，被某个程序员创建第一个版本，然后，可能有不同的程序员，不断修改它，产生新的版本。软件配置管理关心：是不是这个文件的各个历史版本应该被记录，以便今后翻阅?是不是各次修改的修改者、修改的原因应该被记录，以便将来可以理解当时的情形，理解为什么做出这样的改动?更扣人心弦的是，当两个人同时想要修改一个文件的时候，可能会导致其中一个人的改动丢失，也就是常说的版本覆盖。那么，是让他们一个改完了另一个再改呢，还是让他们同时改，在将来合并?等等。所以说，软件配置管理是关于不断演进的软件资产的管理。为什么称作配置管理？丢失。机器由正确型号的零部件配置而成。每个零件都有型号、编号。零件组成的部件也有。一直到整个机器，一辆汽车。要保证制造出来的机器是正确的，就要保证选取了所有正确型号的零部件。那么，容易想到，应该有某种列表或文档，标明各零部件型号和组成关系，也就是说，标明配置信息。而当配置有变动的时候，要更新这样的列表或文档。并且，这种变动不能随随便便，是否应该先让总工程师批准?是否应该做相应的测试?这些都属于对配置的管理。从软件配置管理的视角看，软件也是这么配置起来的。往小了说，各个源代码文件的正确版本配置在一起，编译产生了正确的可运行程序。往大了说，若干软件组件的特定版本，配置构成了特定的软件产品。而有些软件组件，可能参与了不止一个软件产品的配置构成。而当某个软件组件参与不止一个软件产品的配置构成的时候，可能是这个软件组件的同一个版本，也可能是不同版本。看，问题有多复杂!不管理怎么行!软件配置管理，与对机械系统的配置的管理相比，是有一些自己的特点的。主要有两点：第一，软件更容易发生变化，向前演进。一个程序员，修改一个Bug，可能5分钟就搞定了，于是，5分钟前与5分钟后，已经是不同的版本了。更何况，不止一个程序员在工作。如此快速的、众多的变化，如果靠一个书记员手工记录相关信息，那恐怕比较累。所以需要某种自动化的工具，提供这方面的支持。第二，软件的耦合性更高。当程序员为某个任务改动源代码的时候，经常要改动不止一个文件。在目录结构上，这些文件可能相距遥远。组件/模块间的接口，往往并不像把鼠标线插到USB口上那么简单。某个模块的变化，常会影响到相关模块。这个特点，使得在软件领域，需要格外关心整体性。要尽可能早的、尽可能频繁的集成，保证产品作为整体，是可运行的。另一方面，一个模块、一个源文件，可能被几个程序员改动：出于不同的目的，改动不同的位置，甚至相同的位置。因此，版本更容易混乱，或相互覆盖。需要软件配置管理工具提供相应支持，提供便利，同时避免出现问题。软件配置管理为软件开发提供了一个保险柜。保险柜里，存的都是值钱的东西。存进保险柜，是因为怕自己不小心弄丢，或者被偷走。软件资产也一样，甚至比金戒指之类的更值钱。软件资产也会丢失，特别是源代码。比如，一个软件项目完成后，如果没有进行存储/归档等工作，等再过几个月，想基于版本1.0开发版本2.0的时候，可能会发现1.0的源代码找不着了无奈，只好从头写。这是自己不小心弄丢的情况。软件资产还有可能被窃取或泄漏。虎视眈眈的竞争对手，无孔不入的商业间谍所以，一定要把软件资产放进类似保险柜的地方。这是来自攀岩者的经验。系上保险绳，每向上攀一小段，就在岩壁上打个岩钉。这样，即使偶尔失手，也不会从半山坠到谷底，只是向下滑一小段。软件开发也是一样，适当的保存历史版本，可以在失手的时候回退到上一个安全的地方。这里的版本，不仅仅指具体某个文件的版本，也指整个产品的版本。不仅指源文件，也包括需求、设计、测试用例当我们关心软件产品的部署和运行情况时，版本还意味着，某个软件，上次安装的版本是多少?这次升级到哪个版本?如果升级失败，应该回退到上一个版本。一步一个脚印。这有两个含义。首先，先走好这一步，踩实了，踩稳了，再走下一步。软件研发也是这样，需要里程碑;需要基线;需要每个迭代结束时，内部或外部的发布。这些是项目的脚印。在每个脚印处，我们要认真检查，是不是踩实踩稳了。这可能是通过相关人员的评审，领导的审批，可能是通过软件测试，也可能是通过某些检查。其次，一个个的脚印，就构成了足迹。它告诉我们，我们是如何一路走来的，走的是哪条路。必要的时候，我们可能会回顾。还有可能，我们会回到半路，以便从那里再闯一条新路出去。对应到软件开发，我们就是要保存历史上的版本，已备将来的不时之需。好了好了，据说所有的类比和比喻都是蹩脚的。软件配置管理是什么?软件配置管理就是软件配置管理。如果再多说几句，那就是：它是关于不断演进的软件资产的管理。这涉及到存储和安全；涉及到记录它演进的历史;涉及到让修改和变更井然有序，避免出现版本丢失、版本覆盖等混乱情况;涉及到保证软件代码集成在一起的质量让我们在随后的章节里，更细致地学习和研究吧!测试环境管理规范1作者：李丽君来源：李丽君的博客2008年4月21日发表评论进入社区 测试环境重要性及意义1、稳定、可控的测试环境，可使测试人员花费较少时间完成测试用例的执行;2、 可保证每一个被提交的缺陷被准确的重现;3、经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。 测试环境搭建原则测试环境搭建之前，需要明确以下问题：1、所需计算机数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度等;2、部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;3、用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;4、是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份;5、测试中所需要使用的网络环境;6、执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议;7、测试数据的备份与恢复是否需要;8、模拟实际生产环境或用户环境搭建。测试环境管理一、 设置专门的测试环境管理员测试环境管理规范2作者：李丽君来源：李丽君的博客2008年4月21日发表评论进入社区 每条业务线或测试小组应配备一名专门的测试环境管理员，其职责包括： 测试环境搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册编写; 记录组成测试环境的各台机器硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况; 完成被测应用的部署，并做好发布文档的编写; 测试环境各项变更的执行及记录; 测试环境的备份及恢复; 操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理; 当测试组内多名成员需要占用服务器并且相互之间存在冲突时(例如在执行性能测试时，在同一时刻应当只有一个场景在运行)，负责对服务器时间进行分配和管理。二、测试环境文档管理需要维护如下文档是最新版本： 组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况; 组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置(CPU/内存/硬盘/网卡)、IP地址、具体用途以及历次的变更情况; 被测软件或产品的发布手册，记录被测软件或产品的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测软件或产品的发布情况，对版本差异进行描述; 测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因(与上次备份相比发生的变化)以及所形成的备份文件的文件名和获取方式; 用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。三、测试环境访问权限管理按照如下要求维护测试环境权限： 访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品等所需的各种用户名、密码、权限，由测试环境管理员统一管理; 测试环境管理员拥有全部的权限; 除对被测软件或产品的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要(例如查看系统日志)，则只授予只读权限(user权限); 除测试环境管理员外，其他测试组成员不授予删除权限; 用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。四、测试环境变更管理确保每次变更是可追溯和可控： 测试环境的变更申请由测试人员提出邮件申请，由测试环境管理员负责执行。测试环境管理员不接受非正式的变更申请(例如口头申请); 对测试环境的任何变更，测试负责人均应记入相应的文档; 每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理; 对于被测软件或产品的发布，开发人员负责打包、测试人员核对发布包。五、测试环境备份与恢复1、确保测试环境程序版本、数据是可恢复;2、对于功能或性能测试，测试数据需定期进行备份或从生产环境导入测试数据;3、通过备份软件工具备份数据，同时保障备份数据可快速恢复。测试环境维护执行流程附件1、测试机器申请流程2、测试机器维护列表格式3、测试环境部署文档维护列表格式4、发布手册维护列表格测试环境管理规范1作者：李丽君来源：李丽君的博客2008年4月21日发表评论进入社区 测试环境重要性及意义1、稳定、可控的测试环境，可使测试人员花费较少时间完成测试用例的执行;2、 可保证每一个被提交的缺陷被准确的重现;3、经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。 测试环境搭建原则测试环境搭建之前，需要明确以下问题：1、所需计算机数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度等;2、部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;3、用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;4、是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份;5、测试中所需要使用的网络环境;6、执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议;7、测试数据的备份与恢复是否需要;8、模拟实际生产环境或用户环境搭建。测试环境管理一、设置专门的测试环境管理员每条业务线或测试小组应配备一名专门的测试环境管理员，其职责包括： 测试环境搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册编写; 记录组成测试环境的各台机器硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况; 完成被测应用的部署，并做好发布文档的编写; 测试环境各项变更的执行及记录; 测试环境的备份及恢复; 操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理; 当测试组内多名成员需要占用服务器并且相互之间存在冲突时(例如在执行性能测试时，在同一时刻应当只有一个场景在运行)，负责对服务器时间进行分配和管理。二、测试环境文档管理需要维护如下文档是最新版本： 组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况; 组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置(CPU/内存/硬盘/网卡)、IP地址、具体用途以及历次的变更情况; 被测软件或产品的发布手册，记录被测软件或产品的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测软件或产品的发布情况，对版本差异进行描述; 测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因(与上次备份相比发生的变化)以及所形成的备份文件的文件名和获取方式; 用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。三、测试环境访问权限管理按照如下要求维护测试环境权限： 访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品等所需的各种用户名、密码、权限，由测试环境管理员统一管理; 测试环境管理员拥有全部的权限; 除对被测软件或产品的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要(例如查看系统日志)，则只授予只读权限(user权限); 除测试环境管理员外，其他测试组成员不授予删除权限; 用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。四、测试环境变更管理确保每次变更是可追溯和可控： 测试环境的变更申请由测试人员提出邮件申请，由测试环境管理员负责执行。测试环境管理员不接受非正式的变更申请(例如口头申请); 对测试环境的任何变更，测试负责人均应记入相应的文档; 每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理; 对于被测软件或产品的发布，开发人员负责打包、测试人员核对发布包。五、测试环境备份与恢复1、确保测试环境程序版本、数据是可恢复;2、对于功能或性能测试，测试数据需定期进行备份或从生产环境导入测试数据;3、通过备份软件工具备份数据，同时保障备份数据可快速恢复。测试环境维护执行流程附件1、测试机器申请流程2、测试机器维护列表格式3、测试环境部署文档维护列表格式4、发布手册维护列表格软件测试的复杂性与经济性作者：不详来源：不详2008年2月17日发表评论进入社区 人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。E.W.Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误不存在”。在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例时应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级;第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：、系统的目的系统的目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。一台在Boeing 757上的系统应该比一个用于公共图书馆中检索资料的系统需要更多的测试。一个用来控制密封燃气管道的系统应该比一个与有毒爆炸物品无关的系统有更高的可信度。一个安全关键软件的开发组比一个游戏软件开发组要有苛刻得多的查找错误方面的要求。、潜在的用户数量一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。一个在全世界范围内有几千个用户的系统肯定比一个只在办公室中运行的有两三个用户的系统需要更多的测试。如果不能使用的话，前一个系统的经济影响肯定比后一个系统大。除此而外，在分配处理错误的时候，所花的代价的差别也很大。如果在内部系统中发现了一个严重的错误，在处理错误的时候的费用就相对少一些，如果要处理一个遍布全世界的错误就需要花费相当大的财力和精力。、信息的价值在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。、开发机构一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也就截然的不同。 然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。、测试的时机测试量会随时间的推移发生改变。在一个竟争很激烈的市场里，争取时间可能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那测试项目的启动、规划以及测试项目需求分析往往是很多软件服务型企业的薄弱环节所在。本文围绕该难点问题，重点讨论了这两个阶段所应进行的项目活动以及相关工作流程。一、测试项目启动与规划一般地，项目启动过程组包括两个过程参见PMBOK2004版：即制定项目章程和制定项目初步范围说明书；而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。对任一项目而言，有三个文件是非常重要的。即：项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。一个项目，不论大小，都应该有项目章程。一个典型的项目章程包括如下内容：1）项目名称及背景描述；2）项目经理任命及职责范围界定；3）项目业务需求描述；4）项目发起的原因；5）主要项目干系人及其初步需求；6）产品及预期交付成果描述；7）项目假设和约束条件。项目章程由项目发起人（Sponsor）签发，自签发之日起，项目经理即获得法定权力。项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。比较典型的有项目范围基线、项目成本基线、项目进度计划、项目质量计划、项目风险分析及应对计划、人力资源计划、项目沟通计划以及项目采购计划。这些计划、规划经过权衡、调整，最终将集成为一个完整的项目管理计划。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。此后，项目经理将召开项目开工会议（Kickoff meeting），宣布项目正式开始进入执行阶段。项目启动阶段的项目章程和项目初步范围说明书（或SOW），也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。通常，伴随合同到达项目经理手中的还有项目建议书（Project Proposal），项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理根据合同、SOW以及Project Proposal进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组有重叠。比如，规划过程组有可能在整个项目生命期内都有更新和完善（典型的有滚动波浪式规划）。对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。比如：项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理适用于项目型或强矩阵组织或高层经理适用于弱矩阵或职能型组织指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计（即会先粗略地进行软件测试需求分析和软件测试设计，以后再进一步细化），并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。二、软件测试需求分析理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求（当发生这种情况时，普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。是的，事实上，资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。）由于后者涉及需求工程的专门知识，本文略过不做细述；这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW、项目建议书等文档中）细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。（注意：为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文试论软件测试学科架构建设）然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）；又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。测试需求的开发总是有赖于相应层次的软件规格说明书（只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明-概要设计规格说明-软件需求规格说明-用户需求规格说明-项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯）。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。哪些测试需求项应该先测，哪些可以延后，那些是可以并行等等，都需要在测试需求开发阶段一并分析清楚。么产品的质量就变得更重要了，测试量就要加大。测试量应该针对合适的目标进行调整。人世间最痛苦的事莫过于我所在项目开发正陷于混乱不堪的缺陷之中。因为缺乏一套缺陷管理的有效解决方案，使程序的缺陷无法回溯，无法跟踪，解决没解决不清楚，整一个就是一片模糊。由于没有得到足够的重视，软件缺陷管理处于失控状态。软件测试人员报告的缺陷常常被遗忘掉；或没有人知道在新的软件版本里究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。更重要的是纠正过程是否引入了新的缺陷也没有人知道，再或者就是缺陷报告书写不规范，使得开发人员不得不一次次找到测试人员来面谈，还有许多无效的文档使缺陷状态混乱，相关人员无法及时获得有关的变更信息。 什么是开发的缺陷管理？软件中的缺陷（Defect或BUG）是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。（1）缺陷管理的目标一般而言，缺陷的跟踪和管理需要达到以下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。（2）缺陷管理重在预防缺陷正如我们所知，BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此，越晚修正BUG，需要重做的事情就越多。对很多人来说，零缺陷的软件产品似乎是不切实际的。因此，我们总是听到许多软件开发人员说：“软件永远有BUG”。软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值提深思的事情了。事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。为了能够预防BUG，我们首先需要了解BUG的来源。软件BUG可以分为几个类别：第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难预防。但是，适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。因此，BUG的预防尤为重要。缺陷管理的核心：缺陷分析缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费，但是却可带来极大的额外价值。（1）BUG记录BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。（2）利用BUG分析了解开发质量趋势对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。在这个时候，BUG分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。实际上，BUG分析图表会告诉我们很多有价值的信息。比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的