基本进度计划要说明哪些工作必须于何时完成和完成每一任务所需要的时间，但最好同时也能表示出每项活动所需要的人数。常用的制定进度计划的方法有以下几种：

①关键日期表

这是最简单的一种进度计划表，它只列出一些关键活动和进行的日期。

②甘特图

也叫做线条图或横道图。它是以横线来表示每项活动的起止时间。甘特图的优点是简单、明了、直观，易于编制，因此到目前为止仍然是小型项目中常用的工具。即使在大型工程项目中，它也是高级管理层了解全局、基层安排进度时有用的工具。

在甘特图上，可以看出各项活动的开始和终了时间。在绘制各项活动的起止时间时，也考虑它们的先后顺序。但各项活动上间的关系却没有表示出来，同时也没有指出影响项目寿命周期的关键所在。因此，对于复杂的项目来说，甘特图就显得不足以适应。

③关键路线法（Critical Path Method，简称CPM）。

④计划评审技术（Program Evaluation and Review Technique，简称PERT）。

CPM 和PERT是50年代后期几乎同时出现的两种计划方法。随着科学技术和生产的迅速发展，出现了许多庞大而复杂的科研和工程项日，它们工序繁多，协作面广，常常需要动用大量人力、物力、财力。因此，如何合理而有效地把它们组织起来，使之相互协调，在有限资源下，以最短的时间和最低费用，最好地完成整个项目就成为一个突出的重要问题。CPM和PERT就是在这种背景下出现的。这两种计划方法是分别独立发展起来的，但其基本原理是一致的，即用网络图来表达项目中各项活动的进度和它们之间的相互关系，并在此基础上，进行网络分析，计算网络中各项时间多数，确定关键活动与关键路线，利用时差不断地调整与优化网络，以求得最短周期。然后，还可将成本与资源问题考虑进去，以求得综合优化的项目计划方案。因这两种方法都是通过网络图和相应的计算来反映整个项目的全貌，所以又叫做网络计划技术。

此外，后来还陆续提出了一些新的网络技术，如GERT（Graphical Evaluation and Review Technique，图示评审技术），VERT（Venture Evaluation and Review Technique，风险评审技术）等。

很显然，采用以上几种不同的进度计划方法本身所需的时间和费用是不同的。关键日期表编制时间最短，费用最低。甘特图所需时间要长一些，费用也高一些。CPM要把每个活动都加以分析，如活动数目较多，还需用计算机求出总工期和关键路线，因此花费的时间和费用将更多。PERT法可以说是制订项目进度计划方法中最复杂的一种，所以花费时间和费用也最多。

应该采用哪一种进度计划方法，主要应考虑下列因素：

①项目的规模大小。很显然，小项目应采用简单的进度计划方法，大项目为了保证按期按质达到项目目标，就需考虑用较复杂的进度计划方法。

②项目的复杂程度。这里应该注意到，项目的规模并不一定总是与项目的复杂程度成正比。例如修一条公路，规模虽然不小，但并不太复杂，可以用较简单的进度计划方法。而研制一个小型的电子仪器，要很复杂的步骤和很多专业知识，可能就需要较复杂的进度计划方法。

③项目的紧急性。在项目急需进行，特别是在开始阶段，需要对各项工作发布指示，以便尽早开始工作，此时，如果用很长时间去编制进度计划，就会延误时间。

④对项目细节掌握的程度。如果在开始阶段项目的细节无法解明，CPM和PERT法就无法应用。

⑤总进度是否由一、两项关键事项所决定。如果项目进行过程中有一、两项活动需要花费很长时间，而这期间可把其他准备工作都安排好，那么对其他工作就不必编制详细复杂的进度计划了。

⑥有无相应的技术力量和设备。例如，没有计算机，CPM和PERT进度计划方法有时就难以应用。而如果没有受过良好训练的合格的技术人员，也无法胜任用复杂的方法编制进度计划。

此外，根据情况不同，还需考虑客户的要求，能够用在进度计划上的预算等因素。到底采用哪一种方法来编制进度计划，要全面考虑以上各个因素。

软件开发项目过程中的风险管理研究[1]

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。

　　在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。

　　项目风险管理

　　项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图1所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生?

（1）需求风险

　　①需求已经成为项目基准，但需求还在继续变化；

　　②需求定义欠佳，而进一步的定义会扩展项目范畴；

　　③添加额外的需求；

　　④产品定义含混的部分比预期需要更多的时间；

　　⑤在做需求中客户参与不够；

　　⑥缺少有效的需求变化管理过程。

　　（2）计划编制风险

　　①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；

　　②计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；

　　③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；

　　④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；

　　⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；

　　⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

　　（3）组织和管理风险

　　①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；

　　②低效的项目组结构降低生产率；

　　③管理层审查决策的周期比预期的时间长；

　　④预算削减，打乱项目计划；

　　⑤管理层作出了打击项目组织积极性的决定；

　　⑥缺乏必要的规范，导致工作失误与重复工作；

　　⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

　　（4）人员风险

　　①作为先决条件的任务(如培训及其他项目)不能按时完成；

　　②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；

　　③缺乏激励措施，士气低下，降低了生产能力；

　　④某些人员需要更多的时间适应还不熟悉的软件工具和环境；

　　⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；

　　⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；

　　⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；

　　⑧没有找到项目急需的具有特定技能的人。

（5）开发环境风险

　　①设施未及时到位；

　　②设施虽到位，但不配套，如没有电话、网线、办公用品等；

　　③设施拥挤、杂乱或者破损；

　　④开发工具未及时到位；

　　⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；

　　⑥新的开发工具的学习期比预期的长，内容繁多。

　　（6）客户风险

　　①客户对于最后交付的产品不满意，要求重新设计和重做；

　　②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；

　　③客户对规划、原型和规格的审核决策周期比预期的要长；

　　④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；

　　⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；

　　⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

　　（7）产品风险

　　①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；

　　②开发额外的不需要的功能(镀金)，延长了计划进度；

　　③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

　　④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；

　　⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；

　　⑥开发一种全新的模块将比预期花费更长的时间；

　　⑦依赖正在开发中的技术将延长计划进度。

　　（8）设计和实现风险

　　①设计质量低下，导致重复设计；

    一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
    二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
    三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
    四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
    五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
    六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
    七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
    八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

    前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
    针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

    ·测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查； 
    ·有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险； 
    ·有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

    为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

    ·在做资源、时间、成本等估算时，要留有余地，不要用到100%； 
    ·在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中； 
    ·对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，    项目不会受到严重影响，仍能可以继续下去； 
    ·制定文档标准，并建立一种机制，保证文档及时产生； 
    ·对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换； 
    ·对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

    要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。

　　需求定义（Specify Requirements）：分析应用程序并确定测试需求。

　　测试计划（Plan Tests）：基于测试需求，建立测试计划。

　　测试执行（Execute Tests）：创建测试集（Test Set）并执行测试。

　　缺陷跟踪（Track Defects）：报告程序中产生的缺陷并跟踪缺陷修复的全过程。

　　贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。

1.2需求定义（Specify Requirements）
　　分析应用程序并确定测试需求。

　　定义测试范围（Define Testing Scope）：检查应用程序文档，并确定测试范围——测试目的、目标和策略。

　　创建需求（Create Requirements）：创建需求树（Requirements Tree），并确定它涵盖所有的测试需求。

　　描述需求（Detail Requirements）：为“需求树”中的每一个需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。

　　分析需求（Analyze Requirements）：产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。

1.3测试计划（Planning Tests）
　　基于已定义的测试需求，创建相应的测试计划。

　　定义测试策略（Define Testing Strategy）：检查应用程序、系统环境和测试资源，并确认测试目标。

　　定义测试主题（Define Test Subject）：将应用程序基于模块和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（Test Plan Tree）。

　　定义测试（Define Tests）：定义每个模块的测试类型，并为每一个测试添加基本的说明。

　　创建需求覆盖（Create Requirements Coverage）：将每一个测试与测试需求进行连接。

　　设计测试步骤（Design Test Steps）：对于每一个测试，先决定其要进行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（Test Steps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。

　　自动测试（Automate Tests）：对于要进行自动测试的部分，应该利用MI、自己或第三方的测试工具来创建测试脚本。

　　分析测试计划（Analyze Test Plan）：产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。

1.4测试执行（Running Tests）
　　创建测试集（Test Set）并执行测试。

　　创建测试集（Create Test Sets）：在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。

　　确定进度表（Schedule Runs）：为测试执行制定时间表，并为测试员分配任务。

　　运行测试（Run Tests）：自动或手动执行每一个测试集。

　　分析测试结果（Analyze Test Results）：查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。

1.5缺陷跟踪（Tracking Defects）
　　报告程序中产生的缺陷并跟踪缺陷修复的全过程。

        添加缺陷（Add Defects）：报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加缺陷。

　　检查新缺陷（Review New Defects）：检查新的缺陷，并确定哪些缺陷应该被修复。

　　修复打开的缺陷（Repair Open Defects）：修复那些你决定要修复的缺陷。

　　测试新构建（Test New Build）：测试应用程序的新构建，重复上面的过程，直到缺陷被修复。

　　分析缺陷数据（Analyze Defect Data）：产生报告和图表来帮助你分析缺陷修复过程，并帮助你决定什么时候发布该产品。

Mercury Quality Center™ 提供了基于 Web 的系统，可在广泛的应用环境下自动执行软件质量测试和管理。仪表盘技术使您可以了解验证功能和将业务流程自动化，并确定生产中阻碍业务成果的瓶颈。Mercury Quality Center 使 IT 团队能够在开发流程完成前就参与应用程序测试。这样将缩短发布时间表，同时确保最高水平的质量。

利用 Mercury Quality Center，您可以：

Mercury Quality Center 产品

Mercury Quality Center 包括自动化软件测试产品，例如 Mercury TestDirector®、Mercury QuickTest Professional™、Mercury WinRunner™、Mercury Business Process Testing™ 和 Mercury Service Test™。Mercury Quality Center 还提供了基于最佳实践的服务，用于内部部署或通过我们的 Mercury Managed Services 进行部署。

===========================================================

Software Trial	Download	||
Mercury QuickTest Professional Web Services Add-in
Mercury Diagnostics Profiler for .NET
Mercury TestDirector for Quality Center Starter Edition
Mercury QuickTest Professional for VisualAge Evaluation
Mercury QuickTest Professional for Stingray Evaluation
Mercury QuickTest Professional for Peoplesoft Evaluation
Mercury QuickTest Professional for Java Evaluation
Mercury QuickTest Professional for Oracle Evaluation
Mercury QuickTest Professional for .Net Evaluation
Mercury QuickTest Professional for SAP Evaluation
Mercury QuickTest Professional Terminal Emulator Add-in Evaluation
Mercury QuickTest Professional for Siebel Evaluation
Introduction to Quality Center 8.0 - Using TestDirector: Computer-Based Training (CBT) Course
Introduction to QuickTest Professional 8.0 Computer-Based Training (CBT) Course
Mercury QuickTest Professional Free 14-Day Trial

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

•  软件未达到客户需求的功能和性能；

•  软件超出客户需求的范围；

•  软件出现客户需求不能容忍的错误；

•  软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

•  测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

•  测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

•  测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

•  80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

•  为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

•  缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

•  软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

•  软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。

4、掌握测试理论
   开发工具在变，测试工具在变，被测试的系统在变，一切的东西都在边，那么作为一个测试人员最重要的是学习什么，个人认为是测试理论的学习，拿我自己的例子来说，我原来
是做纯软件的，可是现在接触到了很多和硬件相关的测试，比如手机测试，但不管你测试的是什么系统基本理论是不变的，首先都需要开发人员提供比较好的需求文档。概要设计文档，
详细设计文档，需求文档是我们制定测试需求的标准，也是我们判断系统是否存在问题的标准，而概要设计文档，详细设计文档是我们制作测试用例的依据。我们的划分等价类，边界值
测试等基本测试的方法都需要这些文档的支持，当然每一种不同类型的测试，都有其特殊的地方，比如手机的测试就需要你对通讯理论有一定的了解（也就是系统环境），所以说好的测试
人员必须数量掌握测试理论。如果你认为你的测试理论已经不错了，那就回答一下性能测试，负载测试，压力测试有什么区别这个问题吧。

4、不清谈，而是冲锋在前

   我的一些测试人员，总是喜欢给我出注意，但却从来不考虑如何实施，他们喜欢的一句话就是，看我多聪明，一眼就可以问题的实质，头我这个参谋不错吧（我原来也是这样）。我要告诉
大家这样的人实际已经落入了一个技术生涯的误区，看到问题可以说明你有一定的水平，但如何解决问题，如何实施才是真正体现一个人水平，中国文人当初因为怕杀头，产生了一个极为可怕的
现象就是什么光清议，而从不肯去实践。这个不好的习惯我们现在叫做眼高手低。只有在解决实际问题的时候我们才能发现我们的解决方法有那些不足，会产生什么新的问题，从而不断改进我们
的工作，一个简单的例子，我用TD已经很长时间了，可今天我还是能发现TD一些新的特点，并把这些特点用到我的工作中去，改进我的测试管理，所以个人认为好的测试人员总是那些冲锋在前的
测试人员，在实际工作中才是提高功能能力的最好方法

5、人际关系的处理
   测试工作是一个问题的爆发点，特别是对于那些开发流程不规范的单位，如何处理好人际关系，是一个好的测试人员需要掌握的技巧，作为一个测试负责人要和开发人员、测试人员、公司领导
经常面临短暂的测试时间，不断的回归测试，测试的异常终止，领导的批评，开发人员的职责，测试人员关于工期，测试环境的抱怨。如何化解矛盾，处理好这些问题是一个衡量测试人员好坏的标准
人际关系处理不好，其实一个主要的问题就是误解，开发人员，公司领导对于测试工作的工作量的误解是产生这些矛盾的一个主要原因，所以作为好的测试人员，除了具备一些常用的人际关系处理
技巧以外，还要是一个好的宣传员，不断将测试的方法、理论、工作量对开发人员、上级领导进行宣讲，让他们对测试工作有一个正确的认识，只有这样才能真正处理好测试部门和其他工作人员的
人际关系，是单位的测试向一个好的方向发展。

6、熟悉开发工具和平台
今天累了，不多说了，不了解开发平台是无法做单元测试的，而且也无法做好的性能测试

7、掌握测试工具

  中国软件评测中心的测试原则，就是从用户和开发者的角度出发进行软件产品测试的。

  为了达到上述的原则，需要注意以下几点：

  1.应当把“尽早和不断地测试”作为开发者的座右铭。

  2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

  3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

  4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

  5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

  6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

  7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

  8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档

尽早、尽可能多地发现 Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。

零缺陷(Zero-Bug) 是一种理念，足够好（ Good-Enough ）是测试的基本原则。

在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项：

1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。错误集中发生的现象，可能和程序员的编程水平和习惯有很大的关系。

　　一个基本的也是最有分歧的问题就是：测试文化应是服务型还是控制型？我认为较好的测试文化应是服务型的。有的企业将测试文化定位为控制型，即测试员对最终产品的质量负责，对质量过程负责，甚至批准或拒绝产品的发布。事实上，测试员不应有也不应期望拥有这些控制权利，应将不合理地赋予的这些权利分离出去：1）质量的过程控制应由QA负责，因为，最终产品的质量是设计与开发出来的，而不是测试出来的；2）批准或拒绝产品的发布更有应是企业高层的职责，不应是测试部门更不是测试员的职责。测试部门或测试员应明确自已的角色定位，努力培养服务型测试文化，在服务意识的指导下，努力做了自已的本职工作。

　　既然测试文化定位为服务型，那么，对测试员的职责就可以从如下方面来描述：

　　为高层提供服务：即测试部门将产品的测试报告提供给高层，由高层作出有关决策。测试报告应包含高层希望了解的产品情况：错误发现率、错误改正率、问题收敛趋势，等等。

　　为项目经理提供服务：向项目经理提供的测试报告应满足项目经理关注的需求，这些需求包括：产品的功能有哪些未满足、性能方面有哪些问题、哪些问题已与程序员沟通，但未达成一致意见，需要提交高层仲裁，等等。

　　为QA提供服务：测试人员参与质量管理活动应该是服务性质的，即他不是去主导质量管理活动，而是为质量管理活动提供服务支持。测试人员通过测试报告，利用事实和数据来反映产品目前的质量情况，为QA的工作提供依据。

　　为程序员提供服务：测试员要同程序员交朋友，向程序员及时反馈具体的程序问题，并与程序员共同探讨。一方面，测试员通常比程序员更了解业务领域，因此，他能从业务员的视角来检测产品的功能；另一方面，测试员通过测试用例能发现程序员不易想到的问题；再一方面，测试员从用户（操作员）的角度所进行的随机测试，也是检查产品的可用性。这些方面的测试情况，应及时反馈给程序员，以便进行及时修改。同时，测试员也要从程序员角度考虑问题，并获取相关程序的文档资料，使得测试员编制的测试用例更切合测试的重点、难点以及关注点。必要时，测试员也应了解程序员所使用的开发语言，这对于进行程序的白盒测试尤为重要。

　　为市场推广人员提供服务：产品最终是要投放市场的，在产品的投产前，市场推广人员必须了解产品的优缺点和与同类产品对比的特色，从而有利于组织产品的广告宣传，以及应对媒体的挑剔与非难。总之，在市场推介活动中，市场推广人员应充分了解产品的相关信息，这些信息的主要来源就是测试报告。

　　综上所述，测试人员的职责就是通过测试报告向项目的主要涉众传达产品的信息，即他是作为一个重要的信息源，为质量体系的运作提供到位的服务。

　　从形式来看，测试报告是测试人员的工作成果，因此，测试人员的职责可以围绕着“测试报告”来描述——这里的“测试报告”是广义的，包括测试员的所有的报告（含非正式的口头报告）。例如：

　　描述“测试报告”的前期工作：包括测试计划、测试案例、测试过程、信息收集。
描述“测试报告”的信息管理：通常使用测试管理工具，它对测试中的问题进行收集、流转和跟进或督办，并提供分析与统计功能。

　　描述“测试报告”的撰写：要注意不同的涉众需要不同的信息，即需要不同的测试报告。如，高层可能只需要一些统计信息或问题的收敛情况，而程序员可能需要一些非正式的、直接的、及时的反馈意见。因此，对不同类型的“测试报告”可能有不同的模板或样例，测试报告的编写能力应是测试员的基本功之一。

　　描述“测试报告”的报告流程，测试报告（正式的或非正式的）的报告流程应清楚明白，特别是问题报告应形成闭环。

　　描述“测试报告”的管理：测试报告应作为企业的重要信息加以保存、管理，并作为历史数据供以后参考和比较。

　　测试员的职责的描述形式可以是多种多样，如何描述并不重要，重要的是应通过职责的描述，体现企业的测试文化，努力营造一个好的测试文化是我们所关心的。

关键词

测试过程模型 测试管理理念 可持续改进
  
引言

    1963年，在美国发生了这样一件事：编程人员把一个FORTRAN程序的循环语句DO 5 I=1，3误写为DO 5 I=1.3。一点之差导致飞往火星的火箭爆炸，造成1000多万美元的损失。这种情况的发生，迫使人们考虑在软件投入使用之前必须进行彻底的测试。今天，在软件比较发达的国家，软件测试已经成为一个独立的产业，软件公司纷纷建立独立的测试队伍研究测试技术并开展测试工作。中国的软件测试起步较晚，但随着我国软件产业的蓬勃发展以及人们对软件质量的重视，软件测试正在成为一个新兴的产业。近两年来，国内新成立专业性测试机构10余家，一批批专业的软件测试人员正涌现出来。每年国内都有大量的测试技术交流会议举办，有大量的测试研究论文在专业刊物上发表。在测试技术发展的同时，测试过程的管理显得犹为重要。一个成功的测试项目，离不开对测试过程科学的组织和监控，过程管理已成为测试成功的重要保证。

1 测试过程概述

1．1 软件测试过程概述

    软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。众所周知，开发过程的质量决定了软件的质量，同样的，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。
    随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。

1．2 软件测试过程模型介绍

Ｖ模型

    V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。

                                 


图1-1　软件测试V模型

    V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

Ｗ模型

    W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
    W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
    但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

  

图1-2　软件测试W模型

Ｈ模型

    V模型和W模型均存在一些不妥之处。如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内是可以交叉进行的，所以，相应的测试之间也不存在严格的次序关系。同时，各层次的测试（单元测试、集成测试、系统测试等）也存在反复触发、迭代的关系。
为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图1-3所示。

  
图1-3　软件测试H模型

    这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。
 
    H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

其他模型

    除上述几种常见模型外，业界还流传着其他几种模型，例如X模型、前置测试模型等。X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试。这些模型都针对其他模型的缺点提出了一些修正意见，但本身也可能存在一些不周到的地方。所以在测试过程管理中，正确选取过程模型是一个关键问题。

1．3 软件测试过程模型选取策略

    前面介绍的测试过程模型中，V模型强调了在整个项目开发中需要经历的不同的测试级别，但忽视了测试的对象不应该仅仅是程序。而W模型在这一点上进行了补充，明确指出应该对需求、设计进行测试。但是V模型和W模型都没有将一个完整的测试过程抽象出来，成为一个独立的流程，这并不适合当前软件开发中广泛应用的迭代模型。H模型则明确指出测试的独立性，也就是说只要测试条件成熟了，就可以开展测试。

    在实际测试工作中我们应该尽可能地去应用各模型中对项目有实用价值的方面，不能强行的为使用模型而使用模型。在测试实践中，我们采用的方法是：以W模型作为框架，及早的、全面的开展测试。同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。

2 测试过程管理理念

    生命周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。但实际的测试工作是复杂而烦琐的，可能不会有哪种模型完全适用于某项测试工作。所以，我们应该从不同的模型中抽象出符合实际现状的测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。当然测试管理牵涉的范围非常的广泛，包括过程定义、人力资源管理、风险管理等等，本节仅介绍几条从过程模型中提炼出来的，对实际测试有指导意义的管理理念。

2．1 尽早测试

    “尽早测试”是从W模型中抽象出来的理念。我们说测试并不是在代码编写完成之后才开展的工作，测试与开发是两个相互依存的并行的过程，测试活动在开发活动的前期已经开展。
    “尽早测试”包含两方面的含义：第一，测试人员早期参与软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例；第二，尽早的开展测试执行工作，一旦代码模块完成就应该及时开展单元测试，一旦代码模块被集成成为相对独立的子系统，便可以开展集成测试，一旦有BUILD提交，便可以开展系统测试工作。
    由于及早的开展了测试准备工作，测试人员能够于早期了解测试的难度、预测测试的风险，从而有效提高了测试效率，规避测试风险。由于及早的开展测试执行工作，测试人员尽早的发现软件缺陷，大大降低了BUG修复成本。但是需要注意，“尽早测试”并非盲目的提前测试活动，测试活动开展的前提是达到必须的测试就绪点。

2．2 全面测试

    软件是程序、数据和文档的集合，那么对软件进行测试，就不仅仅是对程序的测试，还应包括软件“副产品”的“全面测试”，这是W模型中一个重要的思想。需求文档、设计文档作为软件的阶段性产品，直接影响到软件的质量。阶段产品质量是软件质量的量的积累，不能把握这些阶段产品的质量将导致最终软件质量的不可控。
    “全面测试”包含两层含义：第一，对软件的所有产品进行全面的测试，包括需求、设计文档，代码，用户文档等等。第二，软件开发及测试人员（有时包括用户）全面的参与到测试工作中，例如对需求的验证和确认活动，就需要开发、测试及用户的全面参与，毕竟测试活动并不仅仅是保证软件运行正确，同时还要保证软件满足了用户的需求。
    “全面测试”有助于全方位把握软件质量，尽最大可能的排除造成软件质量问题的因素，从而保证软件满足质量需求。

2．3 全过程测试

    在W模型中充分体现的另一个理念就是“全过程测试”。双V字过程图形象的表明了软件开发与软件测试的紧密结合，这就说明软件开发和测试过程会彼此影响，这就要求测试人员对开发和测试的全过程进行充分的关注。
    “全过程测试”包含两层含义：第一，测试人员要充分关注开发过程，对开发过程的各种变化及时做出响应。例如开发进度的调整可能会引起测试进度及测试策略的调整，需求的变更会影响到测试的执行等等。第二，测试人员要对测试的全过程进行全程的跟踪，例如建立完善的度量与分析机制，通过对自身过程的度量，及时了解过程信息，调整测试策略。
    “全过程测试”有助于及时应对项目变化，降低测试风险。同时对测试过程的度量与分析也有助于把握测试过程，调整测试策略，便于测试过程的改进。

2．4 独立的、迭代的测试

    我们知道，软件开发瀑布模型只是一种理想状况。为适应不同的需要，人们在软件开发过程中摸索出了如螺旋、迭代等诸多模型，这些中需求、设计、编码工作可能重叠并反复进行的，这时的测试工作将也是迭代和反复的。如果不能将测试从开发中抽象出来进行管理，势必使测试管理陷入困境。
    软件测试与软件开发是紧密结合的，但并不代表测试是依附于开发的一个过程，测试活动是独立的。这正是H模型所主导的思想。“独立的、迭代的测试”着重强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开展。

    所以，我们在遵循尽早测试、全面测试、全过程测试理念的同时，应当将测试过程从开发过程中适当的抽象出来，作为一个独立的过程进行管理。时刻把握独立的、迭代测试的理念，减小因开发模型的繁杂给测试管理工作带来的不便。对于软件过程中不同阶段的产品和不同的测试类型，只要测试准备工作就绪，就可以及时开展测试工作，把握产品质量。

3 测试过程管理实践

    本节以一个实际项目系统测试过程（不对单元测试和集成测试过程进行分析）的几个关键过程管理行为为例，来阐述上节中提出的测试理念。在一个构件化ERP项目中，由于前期需求不明确，开发周期相对较长，为了对项目进行更好的跟踪和管理，项目采用增量和迭代模型进行开发。整个项目开发共分三个阶段完成：第一阶段实现进销存的简单的功能和工作流；第二阶段：实现固定资产管理、财务管理，并完善第一阶段的进销存功能；第三阶段：增加办公自动化的管理（OA）。该项目每一阶段工作是对上一阶段成果的一次迭代完善，同时将新功能进行了一次叠加。

3．1 策划测试过程

    依据传统的方法，将系统测试作为软件开发的一个阶段，系统测试执行工作将在三个阶段完成后开展，很明显，这样做不利于BUG的及时暴露。有些缺陷可能会埋藏至后期发现，这时的修复成本将大大提高。我们依据“独立和迭代”的测试理念，在本系统中，对测试过程进行独立的策划，找出测试准备就绪点，在就绪点及时开展测试。该系统的三个阶段具有相对的独立性，在每一阶段完成所提交的阶段产品具有相对的独立性，可以作为系统测试准备的就绪点。故而，在该系统开发过程中，系统测试组计划开展三阶段的系统测试，每个阶段系统测试具有不同的侧重点，目的在于更好的配合开发工作尽早发现软件BUG，降低软件成本。软件开发与系统测试过程的关系如图3-1所示。
    实践证明，这种做法起到了预期的效果，与开发过程紧密结合而又相对独立的测试过程，有效的于早期发现了许多系统缺陷，降低了开发成本，同时也使基于复杂开发模型的测试管理工作更加清晰明了。
  
3．2 把握需求

    在本系统开发过程中，需求的获取和完善贯穿每个阶段。对需求的把握很大程度上决定了软件测试是否能够成功。系统测试不仅仅确认软件是否正确实现功能，同时还要确认软件是否满足用户的需要。依据“尽早测试”和“全面测试”原则，在需求的获取阶段，测试人员参与到了对需求的讨论之中。测试人员与开发人员及用户一起讨论需求的完善性与正确性，同时从可测试性角度为需求文档提出建议。这些建议对开发人员来说，是从一个全新的思维角度提出的约束。同时，测试组结合前期对项目的把握，很容易制定出了完善的测试计划和方案，将各阶段产品的测试方法及进度、人员安排进行了策划，使整个项目的进展有条不紊。
实践证明，测试人员早期参与需求的获取和分析中，有助于加深测试人员对需求的把握和理解，同时也大大促进需求文档的质量。在需求人员把握需求的同时，于早期制定项目计划和方案，及早准备测试活动，大大提高了测试效率。

3．3 变更控制

    变更控制体现的是“全过程测试”理念。在软件开发过程中，变更往往是不可避免的，变更也是造成软件风险的重要因素。在本系统测试中，仅第一阶段就发生了7次需求变更，调整了两次进度计划。依据“全过程测试”理念，测试组密切关注开发过程，跟随进度计划的变更调整测试策略，依据需求的变更及时补充和完善测试用例。由于充分的测试准备工作，在测试执行过程中，没有废弃一个测试用例，测试的进度并没有因为变更而受到过多影响。

3．4 度量与分析

    对测试过程的度量与分析同样体现的“全过程测试”理念。对测试过程的度量有利于及时把握项目情况，对过程数据进行分析，很容易发现优势劣势，找出需要改进的地方，及时调整测试策略。
    在ERP项目中，我们在测试过程中对不同阶段的BUG数量进行了度量，并分析测试执行是否充分。如图3-2所示，通过分析我们得出：相同时间间隔内发现的BUG数量呈收敛状态，测试是充分的。在BUG数量收敛的状态下结束细测是恰当的。
 
图3-2　软件开发与系统测试关系图

    测试中，我们对不同功能点的测试数据覆盖率和发现问题数进行度量，以便分析测试用例的充分度与BUG发现率之间的关系。如表3-1所示，对类似模块进行对比发现：某一功能点上所覆盖的测试数据组越多，BUG的用例发现率越高。如果再结合工作量、用例执行时间等因素进行统计分析，便可以找到适合实际情况的测试用例书写粒度，从而帮助测试人员判断测试成本和收益间的最佳平衡点。

表3-1 测试数据覆盖率与BUG发现率对应表

注：通过统计可以得出测试数据与BUG发现率之间的关系，便于及时调整测试用例编写策略。

笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
 
　　1.软件企业的组织结构

　　(1)A公司结构

　　图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。

图1

　　* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
　　* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
　　* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。

　　(2)项目组结构

　　1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
 
　　2) 汇报关系为:
　　Team Member->Team Leader->PC->EM->研发总负责人。

　　3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
　　1级:Software Engineer，刚毕业的本科生和研究生。
　　2级:Senior Software Engineer。
　　3级:Project Leader。
　　4级:Project Manager。
　　5级:Senior Project Manager。
　　3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。

　　A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。

　　A公司通常的项目组为4到5人，最多不超过10人。

　　以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。

　2.项目计划

　　凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。

　　项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。

　　如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。

　　因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。

　　3.项目管理

　　当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：

　　(1)开发阶段和项目周期
　　开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
 
　　(2)流程

　　* A公司对流程比对项目更重视。
　　* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
　　* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。

　　(3)计划

　　1) 计划详细、周到。

　　2) 流程中明确定义开发阶段。
 
　　3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
　　* 进入条件，输入;
　　* 验证方法;
　　* 结束条件，输出。

　　4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。

　　5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。

　　(4)Review

　　按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。

　　在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。

　　(5)QA

　　QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。

　　(6)度量数据

　　CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。

　　(7)团队精神

　　印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。

　　(8)培训

　　印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。

　　(9)配置管理
　　在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
　　(10)记录

　　记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
 
　　1)与客户和其他项目组的所有往来必须邮件记录。

　　2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。

　　3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。

　　4)记录比较准确、比较客观。

　　5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。

　　以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:

　　1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。

　　2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。

　　3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。

　　4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。

　　5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
 
　　这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：

　　1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。

　　2）合理的时间表――为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

　　3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。

　　4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

　　5)沟通――在适当时机进行预排和检查;充分利用团组通信工具―电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。

　　4.PC（项目经理）

　　项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。

　　（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：

　　* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。

　　* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。

　　*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。

　　（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。

　　（3)总的说来，PC安排工作有这么几个特点:

　　a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。

　　b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
 
　　c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:

　　* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。

　　* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。

　　* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。

　　* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。

　　d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。

　　e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。

　　f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
 
　　g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
 
　　从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者，笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。

　　从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的流程表示。

　　为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

1．测试的过程及组织

　　当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。

　　在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：

　　(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

　　(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。

　　(3)代码会审：
　　代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。

　　(4)单元测试：
　　单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。

　　(5)集成测试：
　　集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

　　(6)验收测试：
　　验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

　　经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。

2．测试方法的应用

　　集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括?/p>

　　(1)用边值分析法和（或）等价分类法提出基本的测试用例；
　　(2)用猜测法补充新的测试用例；
　　(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。

　　单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：

　　a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。

　　b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。

3．测试的人员组织

　　为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。

(1)软件的设计和实现都是基于需求分析规格说明进行的。

　　需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
　　组长：1人
　　成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户

(2)设计评审：

　　软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：
　　组长：1人
　　成员：包括系统分析员、软件设计人员、测试负责人员各一人。

(3)程序的测试：

　　软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。测试工作由专门的测试组完成，测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。

4．软件测试文件

　　软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。

　　测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。

(1)测试文件的类型

　　根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，自然要在测试阶段内编写。

(2)测试文件的使用

　　测试文件的重要性表现在以下几个方面：

　　a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的，

　　b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。

　　c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。

　　d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。

　　e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

　　f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。
　　g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。

(3)测试文件的编制

　　在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。

1）测试度量的作用（－）
　　 A:为制定测试计划时提供依据
　　　 需要多长时间?　需要什么物质条件？　 需要多少人，什么素质的人？ 在规定的时间内能完成到什么程度？
　　　　哪些模块及功能需要重点关注？ 测试工作量占整个项目的比例？ 测试结束后我们能达到什么样的目标 ？等等
( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目 类似的情况，以能更为准确的完成计划。 )
　　B： 提高测试流程可控性
　　　　提高测试效率和质量
　　　　提高测试人员的成就感

2)在测试哪个过程做度量
（产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段）
我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步，通过 FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

3）测试度量的内容
两种度量类型：
　　　 A： 项目度量：规模、测试工作量、测试进度、测试生产率
　　　 B： 质量度量：缺陷率（阶段）、缺陷排除率、可靠性等
四个基本度量项：规模、工作量、进度、缺陷

4) 测试用例设计阶段的度量
　　　A：规模 ：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
　　　 B： 工作量 ：文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
　　　C： 进度 ：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
　　　 D： 缺陷 ：评审过程中出现的错误数量、缺陷数量，级别

5）测试执行阶段的度量：
? 测试用例执行率　　　　　　　? 测试用例通过率
? 测试用例问题发现率　　　　　? BUG数量
? BUG级别统计　　　　　　　　　? BUG分布统计（模块）
? BUG分布统计（阶段）　　　　　? BUG密度
? BUG关闭率　　　　　 　　　　? 人均BUG发现效率
? 测试用例执行工作量项目　　　? 回归测试执行工作量
? 发布文档数量　　　　　　　　? 发布文档缺陷数量、级别
? 现场发现的BUG数量　　　　　　? 回归测试现场BUG的工作量
? 版本发布过程中的验证周期　　? 版本发布过程中的验证工作量
? 测试用例覆盖率　　　　　　　? 功能的用户关注度
? 需求变化程度 　

6）测试的度量为项目实施做的贡献

7)由谁来做度量

8)怎样做度量?
PDCA方法：
　　　　　第一步：Plan 　　（ 计划、设置标竿） ( 计划－－制定我们想要达到的目标)
　　　　　第二步：do　　　　（执行）(日报－－记录数据)( 周报－－汇总数据，给出度量结果)
　　　　　第三步：check　　（ 检查和标竿有什么差距） (周例会－－针对度量结果，作出下一步工作建议)
　　　　　第四步：action　　（改进过程)( 阶段总结－－子系统、集成、系统测试等各测试阶段结束后做度量评估，为后续工
　　　　　　　　　　　　　　　　　　　　 作做出指导)
　　　　　第五步:return to plan