在网上看过好几次关于紧急而不严重、严重而不紧急的缺陷举例，对网上的例子并不满意，就此发表一下自己的看法。
该问题是讨论紧急和严重程度的理解，但在面试的时候我们很容易直观想到紧急程度跟时间有关系，严重程度跟功能重要性有关系。这个不能说错，但这个理解未免太过于表面进而得分不高。
有人说：紧急不严重的会挑一些在临近上线的时候突然冒出一个文字错误、体验不佳的BUG，因为时机不巧所以紧急。
有人说：严重不紧急的会挑一些某功能很少有人使用即出现了BUG，因为其特性所以不紧急了。
对于这类答案，我有一个明显的疑问：难道在测试的初期我们就没有了紧急而不严重的BUG了，难道在常用功能里面我们就没有严重而不紧急的问题了？如果突破了这两个前提条件而符合要求的BUG，我认为才是一个高质量的BUG。这是我发表该问题看法的前置条件。
我更倾向于如下答案（用户登陆为例）：
紧急而不严重：
因为登陆验证码无法显示，导致用户无法登陆进而影响所有人登入系统进行测试。
解析：就该问题而言，解决该问题的迫切程度远高于讨论问题的严重程度且验证码的问题算不上严重。对于开发来说，可能只需要动几处代码就行。对于需求方来说就算阉割该功能也没事。
严重而不紧急：
输入任何密码均能登陆系统
解析：该缺陷属于登陆的核心功能异常，登陆等于被废。毫无疑问为严重，但对测试影响并不大，仍然可以登陆系统进行系统功能测试。
登陆功能毕竟属于最常用来举例的程序同时又是极少出问题的模块，若举非软件测试经典案例效果将会更好。再另举一例（通用型）
紧急而不严重：
某流程因其中一个节点使用无法通过，不能流转至下一个环节。
解析：该缺陷在所有流程类测试中均可认为是紧急缺陷，严重程序视情况而定即首先咱们迫切希望问题解决、其次再去争论缺陷严重等级。
严重而不紧急：
某流程如手机充值交易，充值完成后发现手机到账金额为充值金额的2倍，即充值100元，实际到账200元。
解析：直接提BUG，但不影响后续测试。
有人也许要反对了，以上的严重问题同样也很紧急。那怎么判断是否紧急呢，假设负责处理该BUG的开发因病休假或者结婚休假了，我们对于严重BUG能够忍受几天，说明并不那么紧急。如果半刻也不能忍受，那必是绝对紧急、相对不严重。
再有一条相对要求：所有严重、紧急的BUG均需在上线前修复完成；能够容忍到上线后的BUG全部为不严重同时不紧急的BUG。
和各位亲交流一下我对自动化测试的想法，欢迎各位专家拍砖。我认为，成功的自动化测试工程的成功公式为：
成功（100%）=高效的自动化测试框架平台（30%）+合理科学的自动化测试用例设计策略及实现（35%）+持续运营维护（25%）+其他（10%）
高效的自动化测试框架平台（30%）：
咱们测试部门现在的自动化测试框架的水平，在全国绝对处于非常领先的地位。全国的IT企业里面，拥有和我们类似框架的没有几家。我们现在已经越过了河 流，游到了对岸，而大多数还在摸着石头尝试过河。我们的改变也是最近几个月的事情，之前虽对自动化工具有所研究，但纯粹靠编程来实现自动化测试，不适合我 们公司（测试用例稍有修改，就需要重新编译打包，没人喜欢；我们的业务测试人员的编码水平也不足以完成大量用例的编写）。
虽对取得的成绩自豪，但是咱们的工具还没到冰封代码的时刻，我们还有很多想法需要花时间和精力去实现，也需要更多的人力……新的正能量的加入，是个很好 的开始。我也写好了半年开发计划，期待半年后，一个更完整，遵循简单、高效理念的框架为大家所喜爱。这个30%，测试工具开发部门可以拿到满分的 120%！
合理科学的自动化测试用例设计策略及实现（35%）：
自动化测试用例设计策略是个很大的话题，需要我们在实践中不断总结：
需要自动化的比例？
–》自动化测试属于功能测试的一部分，自动化测试带来效率改变的同时，也需要花费很多精力去创建及维护测试脚本，需在投入和产出之间找到平衡。把Testlink上面所有的功能用例都自动化—即使这是未来的规划方向—这也是不现实的。那些最稳定、功能最重要的功能模块才需要自动化。
自动化什么样的用例？
–》软件测试用 例的设计有横向与纵向之分，工程学上以较长为纵、较短为横，纵向指的完整的业务流程用例设计，横向设计即切面设计，把功能模块从大向小细分。 Testlink上面的用例大都属于后者，事无巨细都考虑的很清楚。对于自动化测试，因投入成本问题，选取纵向设计的用例比较科学合理。建议：重新设计合 理的自动化测试用例，而不是简单盲目选用testlink上面已有用例。你，如何认为呢？
相信自动化测试用例数目吗？
–》打开testlink，咱们的“NGB系统端”和“SmartTV系统”的用例数在8000左右啊！！！8000个用例全都自动化实在没有必要，也没可能。大部分用例也是只有标题，没有内容。还不如80个覆盖重要功能的完整业务流程的纵向测试用例实在啊！
……
持续运营维护（25%）：
自动化测试不是一次性筷子工程，而是需要我们不断的运营维护，我们运营维护的时间越长，从中受益也越大。运行后及时分析结果，反馈bug给开发或者完善测试脚本。产品升级之后，也需要更新测试脚本的。
其他（10%）：
其他影响因素，如果其他90%都做得很好，自动化项目还是失败了，都可以归于此。当项目组想告别刀耕火种的方式时，建议以实施自动化测试作为绩效考核之一。审核机制，建议同时关注自动化测试的产量和质量，不要只相信数字，不要相信国内的免检产品。
其他的其他……
最近一段时间在关注一种新的敏捷模式，当然这里说新，是由于目前很少看到有项目在应用，其实这种模式很早就已经诞生了。一个偶尔的机会，在苦寻敏捷测试的 过程中，无意中看一本书，关于如何提高敏捷过程中需求、开发和验收的测试效率，让我很是感兴趣，这本书名《实例化需求：团队如何交付正确的软件》。可能是 由于翻译的原因，读起来给我的帮助并不是那么大，但至少先让初步了解他的思想，我想这就是最大的帮助了，因为我确实接受了他。
关于如何处理需求说明与测试，不同的组织使用不同的名称，或者说是不同的定义，但他们都有一套共同的核心原则与思想，而且当你接受他了之后，我们便可以认为他们本质上是一致的。通常有如下定义：
● 敏捷验收测试
● 验收测试驱动开发
● 实例驱动开发
● User Story测试
● BDD行为驱动开发
● 实例化需求说明（Specification by Example）
对于以上的概念，我想大家都不陌生，但可能都是一个概念，因为没有实践。当具体去实践，其实就发现跟我们平时的流程相对也很容易理解，只是方式不一样， 或者执行流程不一样，当然这里要说的就是不同，那就是方法。方法都是总结出来，多实践之后，提炼出来的就是适合我们的方法。就如同我们在实施了一段时间之 后，突然有一天有人问我什么是BDD（行为驱动开发），我发现我很疑惑，我不理解。但细想，我现在做的流程不就是BDD吗，而我现在做的流程准确来说被定 义为实例化需求，但这个概念似乎不能把开发和测试给拉进来，而用BDD来定义，似乎就一瞬间把需求、设计、开发和测试拉绑定在了一起。
何为BDD？其实就是通过真实用户的行为来定义我们需要开发出什么样的产品来，个人理解。但再结合实例化需求，就会发现，我们就是把用户的行为通过一个实 例化的过程描述出来，然后整理成设计、开发和测试都能看懂的，当然最重要的是用户也能看懂，而且用户看完之后就认可，这就是我想要的，这就是BDD，也就 是实例化需求过程。
它既不是传统的需求文档，也不是设计文档，更不是测试用例文档，但适用于从需求、设计、开发和测试的每一个阶段，而且都是从用户的角度为出发点的。那我就认为那就是我们想要的过程模式。
以下为实例化需求说明的主要过程模式：
当我们获取一个业务目标时，将按照上述流程图来生产实例化需求过程
● 从目标中获取范围
通过用户提供的需求描述，我们将这些描述转变成另一种用户能够理解且真实用户实际地行为方式，这里就要引入User Story用户故事的概念。然后以客户的业务目标为起始，然后通过协作界定可以实现目标的范围。这里最关键的就是与用户更密切地沟通，通过不断细化，确认 这才是用户想要的功能。
● 从协作中制定需求说明
之所以要提出协作制定需求说明，目的是让需求、设计、开发以及测试都参与进来，发挥整个Team的知识和经验，力求让项目的干系人都更多的参与到交付过程中。
● 举例说明
举例说明其实是项目需求交流过程中不可或缺的，团队中不同职能人都有，而且每个人的业务背景不同，通过举例说明的方式可以让目标更一致。
● 提炼需求说明
协作过程中的开发讨论可以建立大家对相关领域的共识，但最终得到的实例往往包含很多不必要的细节。而关键实例必须是精简的。提炼需求说明的过程，其实就伴随着实例化需求的产生，且这些提炼好的实例就可以当作交付的验收条件。
● 频繁验证
频繁验证的依据就是提炼需求产生的实例化需求，它是所有过程实施中都必须要反复进行的工作。需求通过频繁验证与用户进行频繁确认；设计通过实例 化需求来频繁验证设计是否满足用户的需求；开发通过实例化需求频繁验证代码中业务逻辑；测试通过实例化需求来频繁验证交付的功能，并作为最后验收测试的依 据。
● 演化出一个文档系统
通过以上的这些流程，最后演化出一个文档系统。之所以称为文档系统，主要是体现它的可靠性、权威性。所有设计、开发、变更以及测试过程都以此为出发点来考虑，并及时更新，长久维护。
实例化需求过程的核心就是与用户站在一起，从沟通开始，不断举例、细化、精简到统一确认。
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： 软件测试 测试驱动
在讨论测试驱动开发之前，先澄清一个问题：测试驱动开发是否包括验收测试驱动开发。测试驱动开发（Test Driven Development，简称TDD）存在两种理解：
1、包括验收测试驱动开发（Acceptance Test Driven Develop，简称ATDD）在内，这个是广义的理解；
2、TDD是采用单元测试手段，主要针对非界面代码的，与用户故事或需求一般没有直接关联，这个是狭义的理解，TDD和ATDD是并列的。多数人认为应当采用第2种理解，主要因为：
（1）TDD主要采用单元测试方法，典型工具有xUnit系列，ATDD主要采用界面自动化测试方法，典型工具有Selenium、QTP等；
（2）TDD主要用于设计和编码，ATDD主要用于需求分析和确认。下文TDD即是采用第2种理解的TDD。
在极限编程（Extreme Programming，简称XP）中TDD是与简单设计、重构、持续集成等紧密配合的，这些组成了一套威力强大的组合装备。TDD是其中最突出的外在表 现，XP中TDD遵循“测试驱动开发金规”：先写一个会失败的测试，再写一个新特征，永远如此。对比在武侠世界，XP的TDD（下文称为极限测试驱动开 发，英文为eXtreme Test Driven Development，简称为XTDD）属于神器级别，功力不到者是没法自如使用的，反而可能伤了自己。经典的单元测试方法、架构方法（比如常见的 MVC）和设计方法（包括常用的设计模式）是开展TDD的基础，TDD的学习和 实施是循序渐进的，由简入繁的，由浅入深的。所以把XTDD可以看成是一个极端，把没有任何单元测试视为第二个极端，把经典软件工程中V模型（其在单元测 试方面的特征是针对已经有的功能代码编写单元测试，以保障代码的质量）的完整单元测试看成第三个极端，三者组合为一个三角型，如图一所示。从没有任何单元 测试到XTDD，存在多种多样的中间状态，比如只对模块接口进行TDD，比如进行模块级的架构设计后开始TDD，比如在识别了主要类后再开始TDD，比如 对个别有把握的模块先编码后加抽样的单元测试，等等。在这个三角型中选择一个合适的点，相信能够发挥单元测试和TDD的最佳效果。在没有足够功力之前，先 不必开展XTDD。简单否定TDD是不恰当的。
从CMMI角度看，TDD能够满足CMMI3级中技术方案过程域（TS）、验证过程域（VER）和产品集成过程域（PI）的多个实践，是不错的工程实践。
从传统的瀑布型生命周期方法及其衍生的V模型的角度看，TDD下的基本设计比较简略，甚至没有，难以满足设计里程碑评审的要求，TDD没有详细设计，而单元测试各项指标（比如覆盖率、测试频度、测试用例数量等）却超过V模型，总体上违反了V模型。但是如果不了解源自于V模型下的单元测试技术、面向对象设计技术，TDD也是难以开展。
从XP角度看，TDD应当开展到极限。
从Scrum来看，TDD本身不属于Scrum，应当由团队来决定是否采用TDD，如果是，也由团队来决定采用何种程度的TDD。
从ASD（Adaptive Software development）、FDD（Feature Driven Development）等其他敏捷方法流派来看，并没有明确要求，根据需要来选择开展TDD。
浅谈软件项目管理环境下的质量管理
摘要：软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目的质量管理就是产出的软件，满足客户明确需求、隐含需求的能力的所有特性。在现实生活中，监控所有对质量有影响的关键点，采用有效的测量手段来管理软件的质量，从而实现软件项目的“高”质量。使软件项目管理较之其他项目管理而言有其特殊性。采用CMM标准可以确保软件项目的质量，CMM是美国卡纳基梅隆大学软件工程研究所提出的软件研发项目管理的一系列方法。CMM则提供了一整套较为完善的软件研发项目管理的方法。CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。
关键词：软件项目管理；质量管理
1、概念
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将软件开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。同时，随着软件开发规模及开发队伍的逐渐增大，软件开发不再是向过去那样一二个开发人员即可解决的事情。迫切需要一种开发规范来规范每个开发人员、测试人员与支持人员的工作，每个项目组成员按约定的规则准时完成自己的工作。同时采用规范化管理，专业分工也可以降低对开发人员的要求，从而降低产品研发成本。
怎样才能做好软件项目的质量管理呢？在理解现代软件项目的质量管理的理念的基础上，使项目的质量管理具有可操作性和可衡量性。
现代软件项目的质量管理的理念包括：
1）顾客满意：就是我们的交付件（本文指软件）要满足客户的期望；
2）预防胜于检查：质量管理的重点在事前的预防，而不是事后的检查；
3）管理层责任；
4）持续改进：软件项目的质量管理是一个持续改进的过程。
软件项目的质量管理具有更强的可操作性和可衡量性，软件项目的项目工作要提交出原来所要求的、具有实际用途的软件产品。简单地说，软件项目的质量管理就是产出的软件，满足客户明确需求、隐含需求的能力的所有特性。在现实生活中，监控所有对质量有影响的关键点，采用有效的测量手段来管理软件的质量，从而实现软件项目的“高”质量。
2、如何确保软件项目的质量
软件因其复杂性和难以度量，使软件项目管理较之其他项目管理而言有其特殊性。那么如何确保软件项目的质量？软件研发项目管理应该遵循什么标准呢？软件行业以前倡导的标准是ISO9000系列，而现在更多的场合大力倡导CMM，CMM是美国卡纳基梅隆大学软件工程研究所提出的软件研发项目管理的一系列方法。ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，例如应该做什么、什么算好、什么算不好，却没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套较为完善的软件研发项目管理的方法。CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。
3、企业项目管理
目前软件开发的规模越来越大，软件开发技术都必须有严格的管理过程，要有效的开发出软件产品必须要有符合企业自己的软件管理过程。一般企业项目管理过程如下：
1）项目启动 ：需求分析、项目方案选择和筛选、可行性分析等内容。
2）项目计划：项目计划的作用、内容、步骤，有效计划的建议，项目计划的批准、更改计划。
3）项目实施：项目实施动员大会、发布项目信息、跟踪项目进展、实施阶段性评审。
4）项目控制：整体变更的控制、范围变更控制、进度控制、费用控制、质量控制、合同控制、风险控制。
5）项目收尾：移交评审、项目合同收尾、项目后评价。
一般来说，项目管理的方面主要有：采购管理、成本管理、范围管理、进度管理、风险管理、集成管理、时间管理、质量管理。
4、软件质量管理流程
对软件项目进行质量管理，首先需要知道企业的质量方针；在企业的质量方针下制定详细的质量规划。在制定完质量规划后，要让软件项目的质量管理具有可操作性和可衡量性。同时我们需要牢记，任何类型的质量管理过程，都是一个持续改进的过程，需要不断变更。
一般软件项目可分为启动、规划、执行、监控和收尾五个部分。其中质量管理涉及到规划、执行、监控三个部分。软件的质量管理包括质量规划、实施质量保证、实施质量控制三个部分。
在软件项目的质量管理中，质量规划就是判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准。它是软件的项目管理计划的一部分，一般在项目的规划时处理。
软件项目的质量保证是指质量系统内实施了计划的、系统的活动；同时为项目满足所有项目利益相关方的要求提供信心；相对于内部的质量控制；质量保证可以说是对外的；它包含：
① 涉及整体项目、提高信心；
② 涉及经验教训总结/质量审计；
③ 重新评价质量标准是否合适；
④ 实施阶段。
软件项目的质量控制是在项目生命周期的几个关键点上进行的，它决定了项目进行的方式并进行了必要的纠正。质量控制是质量保证的输出，它考虑了项目的效果和效率。
它通常包含：
① 涉及项目的具体工作成果（软件，开发过程中的文档等）；
② 涉及到具体工作成果是否可以被接受；
③ 检查具体工作成果是否符合相关质量标准；
④ 监控阶段。
5、软件质量管理和软件过程能力成熟度模型
软件质量管理是管理者在对软件质量进行一系列度量之后做出的各种决策，促使软件产品在时间、成本内符合标准。软件质量度量是软件度量的一个子集合，其在于产品、过程和项目的质量。
摘要：软件测试是保证软件质量的重要手段。如何组织软件测试，耗费最少时间与最小工作量完成软件测试，使软件质量满足用户要求，是软件研发单位需要解决的问题。本文结合工程实践，从软件的可测试性及测试组织等方面探讨提高软件测试效率的方法。
关键词：可测试性；软件测试；测试人员；
引言
自从上世纪七八十年代全面爆发软件危机起，软件产业的发展过程中始终伴随着巨大的管理难题。整个软件产业存在着软件代价高、难于控制开发进度、软件工作量估计困难、质量低，以及软件修改、维护困难等问题。而要解决这些问题，在很大程度上取决于提高软件的设计、开发和测试质量。
随着软件开发规模的增大，软件的质量问题越来越突出。软件测试是提高软件质量的有效途径，在软件测试工作中投入的人力、物力、财力逐渐加大，国外有些软件公司的测试人员和开发人员的比例甚至达到1：1或2：1的程度，因此如何提高软件测试效率是每个软件研发单位和研发项目面临的严峻问题。
本文结合工程实践，从软件的可测试性和软件测试组织两个方面进行分析，探讨提高软件测试效率的方法。
1、影响软件测试效率的因素
影响软件测试效率的因素很多，本文只论述被测软件质量和软件测试组织对软件测试效率的影响。通过软件测试可以发现软件中的某些问题，软件中存在的某些潜在问题由于受测试工具、测试方法和测试时间的限制而无法发现，测试中发现的问题最终需要通过软件开发人员进行纠正，从某种角度来看，软件测试并不能从根本上提高软件质量，软件质量的高低直接取决于软件开发人员的设计与编程水平，好的软件开发人员编写完成的软件具有问题少、易维护等特点，但有时会出现修改完成了一个软件缺陷，同时又引人多个软件缺陷的情况，需经过多轮回归测试才能够完成问题归零。所以，虽然软件测试是提高软件质量的有效途径，但提高软件开发人员的水平，提高反映软件设计质量和开发质量的软件的可测试性是提高软件质量的根本途径。
软件测试人员对项目需求的理解程度，对测试理论、测试工具和测试方法的掌握程度，以及对被测软件模块在项目中的重要程度和成熟程度的认识，对软件测试效率同样有很大的影响，所以在工程中需合理组织软件测试，提高软件测试效率。
2、软件的可测试性
2.1 可测试性软件的特征
可测试软件具有以下特征：
（1）可操作性。可操作性是指：被测软件的错误很少，可以避免重复测试的开销；没有阻碍测试连续执行的错误；在软件设计时应允许在开发阶段进行部分测试活动。
（2）可观察性。可观察性包括：每个输入有唯一的输出；系统状态和变量可见，或在运行中可查询；过去的系统状态和变量可见，或在运行中可查询；所有影响输出的因素都可见；容易识别错误输出；自动报告内部错误；可获取源代码。
（3）可控制性。可控制性是指：所有可能的输出都产生于某种输入组合；通过某种输入组合，所有代码都可能被执行；软件测试人员可直接控制软件和硬件的状态及变量；输入和输出格式保持一致且有规范的结构；能够便利地对测试进行说明，以及方便地执行和重构测试。
（4）可分解性。软件系统由众多独立模块构成，每个软件模块均可独立进行测试。
（5）简单性。简单性包括功能简单性、结构简单性、代码简单性。
（6）稳定性。软件的变化是不经常的，变化是可控制的，软件的变化不影响已有的测试，失效后能够得到良好恢复。
（7）易理解性。易理解性包括：设计能够被很好地理解；内部、外部和共享构件之间的依赖性能够被很好地理解；测试人员可方便获取技术文档，并及时掌握设计更改情况；技术文档组织合理、明确详细。
2.2 提高软件可测试性的途径
在实际工作中，可通过以下几个途径提高软件的可测试性：减少并控制需求的变更；加强软件可测试性的设计；重视并规范技术文档的编写。
2.2.1 减少并控制需求的变更
用户需求可分为如下三个层次：基本需求、预期需求和扩展需求三类。其中预期需求是明示的，而基本需求和扩展需求是非明示的。所谓扩展需求是指这些特征在用户的期望范围之外，并且当其存在时将是非常令人满意的。由于种种原因，软件的需求不确定性是客观存在的，是不可避免的，软件规模越大，研制周期越长，需求的不确定性就越大。软件需求不确定性原因主要包括：用户在表述需求时常常带有不确定性与模糊性；随着开发进程的推进，用户对所建应用系统理解的不断深入，对原来模糊的或非明示的需求有了新的认识，随时会提出需求的变更；由于开发人员的领域知识的局限性，导致引发对需求的误解；用户需求的获取过程与描述形式往往采用非形式化的自然语言，以及自然概念中存在的本质矛盾，使需求的规范描述发生困难。
（1）识别项目需求
识别项目需求是项目成功的关键，为了减少需求的不确定性，首先应充分认识确定需求的重要性，通过与用户的沟通，使用户能充分认识到软件需求的变更对软件质量、进度和成本的影响，积极参与到确定软件需求的活动中，达到在进行软件设计前尽量确定软件需求的目的。同时在识别项目需求时，除了用户明示的需求外，还需关注用户基本需求，用户基本需求常常体现在项目的领域知识、项目所在行业的相关标准等方面。实践证明，开发人员对领域知识掌握的程度直接影响到项目需求的确定，开发人员通过对领域知识的积累有助于项目需求的确定。
（2）需求文档化及需求评审
按照软件工程化要求，用户应该向研制方正式提交需求文档，研制方根据用户需求进行需求分析形成产品需求，用户需求及产品需求均需文档化并经过评审，以尽早发现不合理的需求。
（3）需求管理、需求变更的控制
在系统研制过程中应对需求进行管理，首先建立需求库及需求跟踪矩阵，在需求跟踪矩阵中反映研制各阶段工作产品与需求的对应关系，并对需求进行需求的双向跟踪。
（4）采用软件需求管理工具
采用需求管理工具，可以提高需求管理工作流程的自动化程度，使需求管理可以在项目实施过程中得到有效地推行。需求管理工具可以在整个项目生命周期内，帮助团队有效地协作，将需求的变更信息及时传送到团队的每个成员，可以使跨项目团队的所有成员都能掌握必要的需求详细信息，并对软件项目规划、项目跟踪与监督实施管理。
2.2.2 加强软件可测试性设计
在项目设计阶段应注重对软件可测试性的设计。项目负责人可根据项目具体情况对软件可测试性提出具体要求，对软件注释率、软件模块规模、模块圈复杂度、基本圈复杂度、操作数的个数以及过程出口个数等进行规定，在软件设计及编程阶段严格按照规范执行，可有效地提高软件测试效率。实践证明，如果在项目设计阶段不进行软件可测试性的设计，待软件完成后再根据可测试性要求对软件进行修改完善常常需要花费巨大的人力和物力，同时大量修改对软件质量也会带来不利影响。
2.2.3 重视并规范技术文档的编写
技术文档不仅是开发人员进行信息交流的手段，也是测试人员进行测试的依据。所以软件相关文档应描述明确详细，组织合理，并根据需求和设计的变更及时更新。同时为了给独立测试人员提供更多的信息，在技术文档中可增加各软件模块的重要程度、重用性及测试历史等信息，使得独立测试人员可以合理分配精力，对重要软件进行重点测试，减少不必要的重复劳动，提高测试效率。
3、软件测试方法与组织
3.1 软件测试方法
软件模块级测试分为白盒测试和黑盒测试。黑盒测试注重于测试软件的功能性需求，试图发现功能缺陷或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误及初始化和中止等类型的错误。白盒测试依赖对程序细节的严密检验，对软件的逻辑路径进行测试，在不同的程序点检验“程序的状态”以判定预期状态或待验证状态与真实状态是否相符。在软件测试中，常常结合黑盒和白盒两种测试方法，相互补充。
3.2 软件测试人员
软件测试可由软件开发人员、独立测试人员或用户进行。在组织软件测试时，可根据不同人员的特点进行组织，使得各类测试相互补充。
软件开发人员熟悉软件需求及被测软件，清楚各软件模块的重要程度和相互关系，了解各软件模块以前的测试及修改等历史情况，可以有针对性地进行测试；软件开发人员和用户交流较为方便，在测试中能够发现与需求不一致的软件错误。但是开发人员急于证明他们的程序是毫无错误的，是按照用户的需求开发的，而且完全能够按照预定的进度和预算完成，这将影响开发人员完成相关测试任务。
独立测试人员应具备较强的测试理论水平和测试经验，熟练掌握软件测试工具，并知悉被测软件的功能需求才能够对软件进行系统全面的测试。但独立测试人员有时会缺乏相应领域的专业知识，主要测试依据是用户的技术要求及开发人员在软件研制过程中形成的文档，一方面这些文档中缺乏对用户基本需求的描述；另一方面，独立测试人员常常需通过开发人员来进行需求的理解，因此在软件测试中有时无法发现软件不满足需求方面的错误。但这种错误往往从用户角度来看是最严重的。同时，独立测试人员由于对各软件模块的重要性及相互关系了解不深。有时会影响测试效率。
在条件允许的情况下，软件完成后可提交用户试用。用户在试用中根据实际使用需求进行操作，其中包括各种正常操作流程和非正常操作流程。用户试用可有效检验软件是否满足用户需求，同时在用户试用中对软件的可靠性等方面也同步进行了测试。因为用户试用方式同实际使用方式非常接近，所以通过用户试用获得好评的软件基本可以满足今后的实际使用要求。
3.3 提高软件测试效率的方法
为了提高软件测试效率，测试人员需要熟悉掌握软件涉及的领域知识，了解软件各项功能的重要程度和成熟程度，掌握测试理论和工具；用户是验证需求正确性的主导力量，应充分发挥用户的积极作用。
在组织软件测试时，可通过以下几个方面提高软件测试效率：
● 根据不同测试人员的特点进行测试分工，单元测试应以软件开发人员为主进行，以保证每个单元能够完成设计的功能。在很多情况下，集成测试也可以开发人员为主进行。当软件体系结构完成后，独立测试机构介人；
● 软件测试人员应注重与用户的沟通，及早发现需求分析、理解不合理的问题，避免今后花费大量的资源和时间进行改正；
● 对于软件开发人员，需加强测试方法的培训，提高自我测试的效率；
● 在选择独立测试人员时，尽量选择比较熟悉了解被测软件相关领域知识的人员；
● 独立测试人员应该在软件开发的需求阶段就参与项目的研制，以便更好地制定测试计划、确定测试目标及编写测试用例。通过找出项目中关键的模块和出错率高的模块，可使测试首先集中在最重要的部分，避免发生把过多时间花费在非重要模块的测试而没有时间测试重要的模块的情况；
● 被测软件在测试中发现了问题，要进行有组织的分析研究，然后权衡利弊进行规范化修改，避免反复修改，反复测试；
● 规范软件配置管理，通过管理及技术手段，对软件和文档版本进行控制，保障软件测试的有效性。
4、结束语
实践证明，通过提高被测软件的可测试性，以及合理组织软件测试工作，可以有效地提高软件测试效率。随着软件测试的重要性得以承认，软件测试阶段在整个软件开发周期中所占的比重也日益增大。为了将缺陷和错误消灭在萌芽之中，软件测试将逐步发展成为软件开发每一阶段都要进行而且需要反复进行的活动。软件测试中大量的工作是机械的、重复的、枯燥的和非智力的，但逐步加强软件自动化测试的研究和推广将是今后软件产业的发展趋势。
最近看了点敏捷测试的东西，看得比较模糊。一方面是因为没有见真实的环境与流程，也许它跟本就没有固定的模式与流程，它就像告诉人们要“勇敢”“努力”。有的人在勇敢的面对生活，有些人在勇敢的挑战自我，有些人在勇敢的面对失败与挫折。好吧！他们都实现了“勇敢”，勇敢到底是如何去做，也许说不清楚。或者说每个人都有自己的实践方式。但是他们却同样靠着“勇敢”攻克不自己所面临的困难。当然了，敏捷并不是简单一个词语，经过前人的不探索与总结，还积累与总结相当多的经验可供我们借鉴与参考。
按照本文的主题还是来谈谈软件测试人员的分工吧！主要来谈传统软件测试过程中的测试分工，因为敏捷测试中的测试分工我还没弄明白到底是肿么个情况。
集体测试
也许专业测试里讲这种方式，很可能不叫“集体测试”。因为我根据的自己的理解起了大概符合意思的名词叫集体测试“集体测试”。
就是测试模式就是，公司里所有的测试人员抱成一团儿，来一个项目，所有测试人员就集中测试一个项目。
先说这种分工方式的优点：
1、因为测试团队的中每个成员有都有优缺，人员在工作之中相互取长补短。可以很快的找出软件中的缺陷。三个臭皮匠顶一个诸葛亮，一个经验再丰富的测试不一定有三个水平一般的测从员发现的问题多。
2、人多的另一个好处是测试项目能可以在更快的时间内发现更多人缺陷。总结一下就是更短时间内发现更多的问题。
再来说说这种方式的缺点：
1、一个人员一张嘴，人力成本很长（人员工资，人员平均时间投入，测试机等硬件资源投入）。
2、当同时需要测试多个项目中时，不要意思，按顺序来，请在后面排好队。
3、工作重复，同样一个缺陷，很可以同时被所有测试员发现，或者叫重复率很高。
4、人员水平难以区分，在一个项目测试过程中，有的测人员可能一个缺陷也没找到，有的测试人员却发现了几乎所有的问题。也许这个项目一个缺陷也没找到的测试员在下个项目中却发现了很多缺陷。
5、了漏测现象是整个测试团队的责任。（这也不是明确的缺点，要看团队的氛围是积极的还是消极的。）
（也许，你说想照这么个分析法是不是漏了太多东西，也许你有兴趣继续看下去话，我后面会讲解。）
好吧！集体测试缺点太多，就像国家成立初期的“吃大锅饭”，肯定是阻碍发展的。那我们来看看几种分工方式。
按测试内容分工
一个项目的测试包括文档测试，易用性测试，逻辑功能测试，界面测试，配置和兼容等多个方面。我们可以根据人员的特点为每个人员分配不同的测试内容。
内容分工方式的优点：
1、分工明确，每位人员都清楚自己的测试的内容重点。
2、责任到位，通过漏测的缺陷就可明确是谁的责任。
按测试流程划分
我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。
不同的人员负责不同测试阶段的工作。
优点：
1、流程清晰，就像瀑布试项目开发流程，不同阶段的工作由不同的人员担任。
2、划分流程的每个阶段难易程度和所需要的技能。
编写测试计划人员需要对整个项目的工作时间、资源分配，测试内容，实施过程有整体的把控能力。
用例辨析人员，需要对项目需求，测试方法，测试点有深入的了解。
用例执行人员需要细心，使用缺陷系统，沟通，协助研发定位缺陷。
输出测试报告人员需要对项目的测试过程，缺陷数量，类型，分布。用例执行请况等进行统计。也可以由测试执行人员担任。
按项目模块划分
对中大型的项目，这种划分就非常必要了，项目的模块非常多，功能也非常多。不同的测试人员负责不同模块的功能，这样会使用测试工作变得更加清晰。
1、人员利用率高，为什么这么说呢? 不同的人员负责的功能不一样。工作就不会存在交叉与重复。
2、更容易挖掘深度缺陷，假如A人员今天测试这个功能，明天测试那个功能，他就不可以对被测功能内部逻辑与业务有深入有了解。找到的也只是很表面的缺陷。那么如果一个人员长期负责一个模块的功能，那么就会更容易发现更有深度的缺陷。而往往深度的缺陷是致命的。
按照测试类型分工
我们知道软件除了功能需要测试以外，软件在编码阶段需要单元测试，接口测试等，在系统测试阶段，为提高功能测试的效率，可能对某些模块进行功能自动化，我们还要考虑软件的性能、安全性等问题。这些类型也是我项目中最常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然，其专业性对测试人员的要求也比较高。
这种分工方式的特点。
1、专业技能要求较高，在这些分类中除了手工测试要求较低外（表面看是这样的），其它分类都需要较高的专业技能。例如，安全性测试需要掌握网络协议，编程技术，脚本攻击，SQL注入，漏洞分析等方面的技能。
2、不同分类之间交互性低，正国为不同分类需要的技能不同，虽然同为“测试”工作，但一个做单元测试的人就无法让其去做性能测试。
上面分类方式的疑问
看了上面的几种分工方式，你是不是每一种测试人员分工方式都似曾相识，但又没有哪个公司是单一的按照上述某种分工作方式工作。
拿笔者目前所在的公司，是一个长期的互联网产品，产品功能比较多，每位测试人员负责不同的功能模块，测试员人员从测试计划到测试报告都基本由一个人来完成。当然对于比较大和紧急的版本迭代，也会多人协作对版本进行测试（协作的方式一般更将版本功能再次细分到每个人员身上）。安全测试由专业的安全人员指导功能测试人员对自己负责的功能进行安全扫描与分析。有独立的性能测试小组，对需要进行性能的产品版本进行性能测试。在独立的功能自动化人员，对于适合自动化的功能进行自动化工作。
笔者公司的分工作方式几乎包括了上面所有的分工方式。那么，我为什么要进行上面那么单一的分工方式划分呢？这样有助于我们理清对测试工作的各种分工方式。在实际的工作中，有大型项目，有小型项目，有客户端软件，也有互联网产品，有短到几天的项目，也有“永久”性的项目。有一次开发完成交付的，也有不段迭代更新的。根据项目的情况，我们可以可以选择合适的分工方式来应用于项目中。
投入人员与发现缺陷的关系
在人员分工时，这也是一个必须也要考虑问题，对一个项目，投入的人员数量，投入的时间，与发现缺陷的数量有密切的关系。
投入时间与发现缺陷的关系：
在人员一定的情况下，投入的时间越多，发现的缺陷越多。但有一个规律，越到后期发现的新缺陷越少。假设软件总缺陷为100个，第一周发现50个问题，第二新发现20个，第二周可能只发现10个新缺陷。而且一个必然的结果是，测试不可能发现所有的缺陷。
投入人员数量与缺陷的关系：
在时间一定有的情况下，投入的人员越多，发现的问题越多，从图中可以看出，投入的人员越多，人员发现缺陷的重叠度越高。当然，你可以说，把每个人员要测试的内容划分清晰就不会重叠了。做为一个系统的各个功能模块，他们之间肯定存在必然的联系。有可能A人员在测试时会涉及到B人员测试的功能，并且发现了问题，不管是告诉B缺陷还是A人员直接提交缺陷（当然，你也可以装作没看到，等着B去发现），这都算不可避免的重叠。
当然了，划分更清晰的任务有效的降低重叠度。同步也降低了发现缺陷的数量，提高项目风险。除非投入更多的时间测试。这之间的关系，需要测试管理者认真去权衡。
在项目不紧急测试时间充分的情况下，可以投入更少的人员，延长测试时间发现更多的缺陷。 在项目紧急的情况下，需要投入更多的人员测试，以便尽快的发现更多的缺陷。在项目质量要求很高的情况下需要投入更多的人员与时间进行测试。在测试时间少，项目质量要求不高的情况下，可以投入较少的人员与时间进行测试。
本文结束，但还有许多问题我没有讲清楚（或者，我目前还说不清楚）。
1、A人员发现了b功能模块的缺陷（b模块由B人员负责测试）应该如何处理？ 自己提缺陷单 ，告诉B人员，让B人员提单。直接忽视，等着B测试人员去发现。
2、项目紧急情况，人员投入，时间投入，某些情况下，考虑某些模块不进行测试。
3、测试人员的发展职业发展，这与测试人员的分工有着密切的联系。
软件测试作为软件生命周期中不可或缺的重要环节，正在受到越来越多的重视。然而，在实际项目测试工作中却存在一个突出的问题，就是测试工作量的统计问题。如何统计更科学、更准确，本文作者在实际工作中进行了摸索和尝试。
虽然，目前测试工作越来越受到企业的重视，已形成规模，参与测试工作的人越来越多，投入也越来越大。但与之不协调的是没有一个配套的、较为合理的工作量统计方法。原有的测试工作量计算方法，一般是把测试人员进入项目的时间与进入项目的人员数量相乘，得到项目测试的工作量。该计算方法由于计算方便，容易操作，深受众多项目的推崇。
但是，随着测试在项目的重要性的加深，测试工作分工日益细化，测试资源强调有效重用，测试团队协作越来越强，使用这种方法已经不能满足测试工作量计算的需要了：上级领导不了解整个测试团队资源的使用情况；测试团队负责人难于对项目测试任务实际执行过程产生的工作量、成本进行跟踪；项目组在考核绩效时，遗漏了部分测试人员的工作量。
所以，在项目测试领域急需一种新的工作量统计方法。笔者将这方面的一些实践进行了总结，供读者朋友参考。
其基本思路如下：首先就任务类型的设置要达成一致；其次从每日的工作量收集开始，将测试任务按照一定的类别进行分类；然后将工作量数据按照不同的需求进行统计，得出不同的统计表；最后对这些统计表的数据进行分析，得出相应的结论。
设置任务类型
设置任务类型，是每日工作量数据录入的前提。任务类型需要在整个测试团队内达成一致，这样大家有了相同的标准，得出的数据才具有统计的意义。本文以某公司的项目测试为例进行介绍，其任务类型如表1所示。
这里提到的测试任务类型，在实践中会根据项目实际需要进行调整。例如，新增“测试工具学习”任务类型等。
另外，在表1所示的任务类型中，有一项比较灵活的任务类型——沟通。有的团队认为沟通都是有目的、有目标的，是一个为完成具体测试任务所进行的中间活动，所以他们把沟通作为具体测试任务的一部分。也就是说，对于这样的团队，他们没有“沟通”这个任务类型。有的团队则认为将沟通的内容很难划清界限，为避免测试人员填写工作量时发生混淆，所以，将“沟通”作为独立的任务类型。笔者认为这属于任务类型定义问题，测试团队可以根据已经存在的约定俗成进行设置，只要在整个团队内达成一致就可以的。
表1 测试任务类型分类
记录工作量基础数据
这项工作由团队成员根据当天的工作任务完成情况进行记录。它是后续工作量统计的基础，所以要保证这项基础数据收集的准确性，切不可应付了事，最好能在当天下班前填写好当天工作量分配情况。
坚持记录时间需要很强的自我约束能力，所以每天填写工作量记录需要一定的坚持力。在填写工作量记录时，需要为每个任务选择相应的任务类型，填写工作任务持续时间。工作任务持续时间最好不超过4个小时，这是为了避免填写的任务过粗，不利于发现工作过程中的问题。
及时记录、数据准确，是这个环节工作的原则。本例中某公司使用的工作量记录表格如表2所示。
统计人力占用情况
这项工作主要统计测试团队所有成员在各个项目中的投入情况，或者说是项目对测试人员的人力占用情况，每周统计一次。通过对人力占用情况进行统计，测试团队负责人可以得到一份人力占用表。这份人力占用表的主要用途的有三个：
● 供测试团队负责人和上级领导使用，方便他们了解测试团队对项目的支持情况及项目占用测试资源的情况。
● 让上级领导间接了解测试团队的人员饱和度。如果测试团队负责人要申请新增测试资源时，将整个团队的历史人力占用表作为数据证据提供给上级领导，可以增强申请的说服力。
● 提供给项目经理参考。避免项目经理在进行项目人员绩效考核时，遗漏了部分测试人员的工作量。
这项人力占用情况统计工作，笔者建议使用者在每周末进行。统计结束后，测试团队负责人将统计结果作为测试团队工作汇报的一部分提交上级领导。本例中，某公司在某一周测试团队人力占用情况如表2所示。
表2 工作量记录表格
在本文的例子里，测试团队在项目1一共投入了B、C、D三个人，B、C成员是100%资源投入。因为项目后续工作安排未知，而B、C成员又属于项目1核心测试人员，因此这两名成员的退出时间未知。另外一个测试成员D因为不属于项目1的核心测试成员，所以他参与2个项目。同时因为项目2规模较小，所以成员D在项目2中投入20%的资源，在项目1中投入80%的资源。考虑到公司在2005年3月将要启动一个新项目，所以，经过和项目1的项目经理协商后达成一致，计划成员D在2005年2月退出该项目，这样他在2005年3月将投入新启动的项目。
通过及时更新、跟踪这张表的数据，可以对团队内测试人员的工作情况心中有数，并可根据公司业务发展、部门建设、人员发展需要，合理安排团队成员的工作。
表3 测试团队人力占用表
统计项目测试工作量投入情况
这项统计工作是在每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时，会将本周的工作量数据整理后一起提交。测试团队负责人定期（每周或半个月）对团队成员提交的数据进行汇总，并整理到项目工作量投入表中。这就解决了在实际测试执行过程中，测试人员无法对测试工作量进行跟踪的问题。
笔者曾经碰到一个项目，该项目的测试计划只安排了1.5人日的工作量，但是实际上该项目在测试计划上总共投入了9人日的工作量。经过分析，笔者发现是两个原因导致这个问题的发生：一是测试人员在填写每日工作量记录时，部分任务的“任务类型”选错了；二是该项目测试组长在估算测试工作量时，没有考虑到实际测试执行过程中也需要进行测试计划工作，如每次测试执行的计划、实际工作过程中的计划更新工作等。通过这次分析后，该项目的测试工作量没有再发生这么大的偏差了（偏差率＝（计划值－实际值）/计划值×100%）。所以说，测试工作量的统计、分析可以帮助使用者发现一些问题，并改进使用者的工作。某公司某一项目的测试团队工作量投入情况如表4所示。
表4 某项目测试工作量统计表
通过这张统计表格，可以很清楚地了解某个人的工作量投入情况，及具体测试任务使用的工作量情况。
汇总项目测试数据
在项目关闭时，测试团队负责人把整个项目测试过程中产生的数据以及项目基础数据进行汇总。测试过程中产生的数据包括：测试工作量、测试投入成本，它的数据来源于表四；项目基础数据包括：项目规模、项目总成本、项目总工作量，这些数据是向项目经理获取的。这里提到的测试成本，是把每个测试人员的人力成本系数和工作量数据相乘得到的。所有相关人可以通过这张统计表了解项目组中测试占开发总工作量的比例，以及项目组用在测试上的开销情况。这项工作是测试团队资产沉淀的很重要的一项工作。主要用途是：从项目角度对项目测试整体情况进行分析；把测试团队所承接测试的项目进行纵向对比，总结共性，发现问题。
例如，可以对这些项目的测试数据进行分析，得出测试工作量估算公式。再如，笔者曾经通过数据的对比，发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析，发现测试用例的维护占用了测试设计很大一部分的工作量，从而应考虑在团队内改进测试用例管理方法。某公司两个项目的测试数据如表5所示。
表5 某测试团队测试项目资产库——测试数据
参考项目背景，笔者对几个项目的测试数据进行分析后，得到了项目测试总人力成本的估算公式：测试总人力成本＝20%×项目总人力成本。
另外，通过把几个项目的各项测试类型所花费的工作量进行对比分析后，笔者得出各项测试任务的工作量相对于测试总工作量的分配比例。对于后续的项目，项目测试组长可以参考这个分配比例进行测试工作量的估算。
当然，上面介绍的估算公式和工作量比例，只是适用于笔者所在的测试团队。不同测试团队、项目组、公司组织情况都不一样，这里介绍这个例子，目的只是说明测试工作量统计的一个用途。
表6 某测试团队各项测试任务的工作量比例
总结
测试工作量的统计，是整个测试团队管理的基础。测试团队的管理、决策、策划等需要数据的支持，即用数据说话，所以，数据的收集、统计是很重要的。有了这些数据之后，我们就可以将它应用到绩效考核和项目成本核算上。
在本文中，笔者主要介绍的是测试团队的工作量统计，但实际上这些方法不仅适用于测试团队，也适用于个人、项目团队或者整个公司组织。实施时只需要调整“任务类型”等与测试有关的属性，并做一定的扩展即可。
本文使用的表格，都是在Excel中建立和维护的。在团队规模不是很大时，或者处于试用初期时，使用很方便、实施成本也低。但是如果团队规模较大，团队成员比较多，数据量较大的话，这种手工方式就显得有些力不从心了。读者可以自行开发一个工作量管理系统，使用数据库的方式来记录、分析这些数据。在使用初期可先实现每日工作量数据的录入，以及针对个人、项目、任务类型等属性的统计分析功能即可。
测试是为了保证软件的质量，敏捷测试关键是保证可以持续、及时的对软件质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。为此我们期望：
测试范围足够广：
● 测试用例要覆盖所有功能；
● 要在各种可能的环境下作兼容性测试；
● 系统的稳定性、性能都要测试；
测试频率足够高：
● 每日构建产生的版本要保证可用；
● 每个迭代都需要对历史功能做回归测试；
● 释放前或上线后如果打了补丁，就需要回归；
但实际情况往往不遂人愿：
实际测试周期变短：
● 上线时间提前确定，研发进度延期，测试计划被迫延后；
● 最后阶段经常会临时增加测试任务；
● 所有人都知道还需要再经过一轮测试，但时间没有了；
有效测试资源稀缺：
● 临时从其他项目抽调的测试人员不能立刻有效的开展测试工作；
● “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试；
因此由于客观上的资源和时间限制，完整的、及时回归测试在人工测试情况下，往往是不可能完成的任务。团队内部也会产生各种争执：
● 提交给测试的版本为什么研发人员不先做通过性测试？
● 这次代码改动量不大，有必要再花那么多时间回归么？
● 当初不是承诺这次修改肯定不会影响以前的功能么？
● 怎么不早说要支持Chrome浏览器，现在哪还有时间测试啊？
怎么能让现场出现这种低级的Bug，打补丁后为什么不仔细回归一遍？
争执越演越烈，最终有团队成员爆发了：“这简直不是人干的活！”。
您怎么看待这句话呢？
其实话糙理不糙，用更理性的语言翻译一下就是“有些工作不应该以人工的方式来完成”，比如：
● 大量机械的、重复性的回归测试；
● 结果的正确性不依赖主观判断的测试；
● 需要模拟大量数据、大量并发量的测试；
● 需要不间断执行的测试（比如7*24小时持续执行）；
● 需要短时间内完成的大量测试用例执行（比如完整的功能回归测试）；
通过自动化测试可以极大的提升回归测试、稳定性测试以及兼容性测试的工作效率，在保障产品质量和持续构建等方面起到举足轻重的作用。特别是在敏捷开发模式下，自动化测试是必不可少的。
目前业界的商业/开源自动化测试工具有很多，比如，功能测试工具有QTP、Selenium等，性能测试有LoadRunner、JMeter等。其工作原理无非都是通过“测试脚本”和“测试数据”来完成“测试过程”，并比较“测试结果”，进而形成“测试报告”。
本文不对这些测试工具的差异或优劣进行对比，只以作者目前采用的Selenium为例进行分析：敏捷开发模式需要自动化测试，但自动化测试本身的敏捷性又如何呢？
Selenium是针对Web应用的开源自动化测试工具，通过编写模拟用户操作的脚本，它会打开浏览器对Web应用进行黑盒测试。可以方便的用于功能测试、兼容性测试、 稳定性测试及并发测试。目前已被主流浏览器厂商广泛支持，同时也是很多其它自动化测试工具（比如，RobotFramework）的底层核心技术。Selenium由IDE、Remote Control（简称RC）、WebDriver、Grid四个工程组成：
● Selenium IDE
是一个用于录制/回放测试脚本的Firefox附加组件，录制的脚本可以生成基于Selenium RC的测试代码（Java、Ruby、C#等）。适用于快速入门，不太适用于实际较大的测试项目；
● Selenium RC
RC由Server和Client组成两部分组成，Server负责加载/关闭浏览器以及作为HTTP代理来访问Web应用，Clinet支持多种编程语言和测试框架（TestNG、JUnit、NUnit等）。
● Selenium WebDriver
WebDriver作为Selenium2的核心特性提供比RC更简洁易用的API，是官方推荐的RC替代方案。可以更好的支持动态网页，不需要再额外启动一个独立的Server。
● Selenium Grid
是Selenium的一个扩展工具，可以很方便地同时在多台机器上和异构环境中并行运行多个RC或WebDriver用例。
Selenium RC是通过在浏览器加载时“注入”JS函数来操纵后续的浏览器行为，Selenium WebDriver则通过直接调用各个浏览器内置的本地事件来达到这一目的。WebDriver目前已经作为W3C规范草案，提交由Google、Mozilla等浏览器厂商讨论。
WebDriver规范定义一组与平台、语言无关的接口，包括发现和操作页面上的元素以及控制浏览器行为，主要用于支持Web应用的自动化测试。WebDriver的核心是通过findElement方法返回DOM对象（WebElement），通过WebElement可以对DOM对象进行操作（获取属性、触发事件等）。其中findElement方法需要的元素定位器（Locator）支持ID、XPath、CSS、超链接文本等多种方式。
“WebDriver”顾名思义就是“Web浏览器驱动”，它专注于解决如何通过外部命令（通常为测试用例）操作浏览器的问题。至于测试用例按照什么顺序执行、执行过程中如何传递数据、测试结果如何断言、如何报告，则可以通过集成其它优秀的专业测试框架（比如，TestNG）来实现（WebDriver没有必要重复造轮子）。
下面用以“用户管理”为例，来看看用WebDriver实现的“增加”和“删除”测试脚本（只示意部分关键代码）。
1、在用户列表页面点击“新增”按钮，跳转到新增用户页面：
| webDriver.findElement(By.xpath("//a[contains(@id,'addUserBtn')]//button")).click(); |
脚本解读：
● By.xpath()表示通过XPath来定位页面元素；
● click()表示在找到的当前控件上执行点击操作；
2、在新增用户页面，输入“帐号”、“密码”、“姓名”，选择“性别”、“生日”和“国籍”，然后点击“保存”按钮，回到用户列表页面，并判断是否增加成功：
1) String account="autotest2";
2) webDriver.findElement(By.xpath("//div[contains(@id,'account_userForm')]//input")).sendKeys(account);
3) webDriver.findElement(By.xpath("//div[contains(@id,'password_userForm')]//input")).sendKeys("1");
4) webDriver.findElement(By.xpath("//div[contains(@id,'name_userForm')]//input")).sendKeys(account);
5) webDriver.findElement(By.xpath("//div[contains(@id,'sex_userForm')]//input")).click();
6) webDriver.findElement(By.xpath("//span[text()='女']")).click();
7) webDriver.findElement(By.xpath("//div[contains(@id,'birthdate_userForm')]//input")).click();
8) webDriver.findElement(By.xpath("//div[contains(@id,'nationality_userForm')]//input")).click();
9) webDriver.findElement(By.xpath("//span[text()='中国']")).click();
10) webDriver.findElement(By.xpath("//a[contains(@id,'userSaveBtn')]//button")).click();
11) WebElement ele = webDriver.findElement(By.xpath("//div[text()='"+account+"']"));
12) Assert.assertNotNull(ele); |
脚本解读：
● sendKeys ()表示在找到的当前控件上输入字符；
● 2~9行表示通过输入或点击选择的方式为用户相关属性赋值；
● 第10行表示点击“保存”按钮（点击后会自动转向用户列表页面）；
● 11~12行表示查找页面上文本内容为新增帐号的div，并断言该div是存在的（不为空）；
3、删除刚刚增加的人员，然后判断是否删除成功：
1) webDriver.findElement(By.xpath("//a[contains(@id,'deleteUserBtn')]//button")).click();
2) WebElement ele = webDriver.findElement(By.xpath("//div[text()='"+account+"']"));
3) Assert.assertNull(ele); |
脚本解读：
● 第1行表示点击“删除”按钮；
● 2~3行表示查找页面上文本内容为新增帐号的div，并断言该div已经不存在了（为空）；
通过上面的脚本就可以实现“用户增加、删除”的自动化测试，并且可以跨浏览器。看到这里您会不会觉得整体还不错，如果测试脚本再能通过录制的方式自动生成就更好了！
“看”起来确实还不错，但在实际项目中用起来就没那么爽了。这其实是在技术/工具选型时普遍存在的现象：在验证/试用阶段的评价很高，但在投入生产使用时会遇到各种各样的问题，因此大家在选型阶段除了考虑功能，还要考虑技术/工具本身的开放性和可扩展性。
上面的方案单纯从技术的角度来讲是很不错的：开源、社区活跃、标准化程度高、支持跨浏览器、脚本回放稳定、可集成性高，等等。
但是如果就这样应用在实际项目中，会从过程的角度暴露一些棘手的问题：
● 测试脚本是“代码级”的，那么应该由谁来编写呢？
测试人员和开发人员好像都有编写这些测试脚本义务，但似乎又都有不写的理由。
● 测试脚本必须不断的修改才能在最新版本上跑通，谁该为此买单？
在敏捷开发过程中需要快速响应需求的变化（新增、变更），这一点整个团队都好理解。因此如果需求发生变化，开发人员修改代码、测试人员修改测试脚本，一切顺理成章，大家相安无事。但是在用户需求没有变化时，开发人员频繁修改代码的情况也很常见：比如，修改Bug、针对“坏味道”做重构、调整页面布局或样式。于是在“毫无征兆”的情况下，测试脚本又无法执行了！
这时候测试人员可能会质问开发人员：“做之前怎么不想清楚？都已经测试完成的功能，为什么还总是反复修改？什么时候代码才能稳定？”。
而开发人员此时也会非常理直气壮：“有Bug能不改么？页面布局不合理导致用户体验差，能不改么？而且敏捷中的一个重要的实践就是重构啊”。
大家又是似乎都有道理、也都有苦衷。我虽然作为测试人员，但是在这个问题上还是“偏向于”开发人员的： 在软件生命周期的各个阶段（需求、设计、开发、测试）中，后面的阶段对前置阶段是有一定依赖的，所以越往后期响应变化的难度越大。比如，在“开发”环节不仅需要响应“需求”的变化（新增、变更），而且需要响应“设计”的变化。从这个角度来看，“测试”本就应该响应“开发”的变化。
对于在实际项目自动化测试过程中遇到的上述问题，归根到底是因为“自动化测试方案本身的敏捷程度不够”，主要体现在如下三个方面：
1、学习成本高
测试人员除了要掌握WebDriver接口之外，还要掌握XPath、TestNG的用法，甚至还需要对功能的前台实现有一定了解。
2、脚本维护困难
敏锐的开发/测试人员从上面的示例脚本中，可以马上嗅出一些“坏味道（Bad Smell）”： 代码相似度非常高、可能变化的数据被硬编码在测试代码里、代码可读性差、测试代码与页面源码耦合度大，等等。这些坏味道的出现，通常意味着需要进行重构，否则会愈演愈烈，最终变得尾大不掉。
【注】业界常见的测试工具本质上还是针对页面源码来编写（或生成）测试脚本的，即使提供了录制工具，此类脚本的可读性和后期可维护性还是非常差的。
3、断言条件繁琐
业界常见的测试工具即使提供录制脚本的功能，但是对于“断言”还是需要人工插入的（工具做不到智能的判断我们想要在哪里设置断言），于是断言就成了自动化测试人员的“噩梦”。
断言对象可能很“多”，页面的信息量往往很大，需要在测试脚本中为每个断言对象（比如，页面某个文本框的值）补充断言语句。
预期结果是可能“变”化的，甚至是动态的，因此预期结果的值如果与脚本逻辑耦合在一起，将来极难维护。 断言机制比较“呆”板，对于 未设为断言对象的字段，如果发生错误也是无法感知的，并且难以对于UI样式或UI逻辑（比如，翻页图标应该灰显）进行断言。
换个角度可以理解为，如果这样的断言条件“多”的话，整个测试用例集会“变”的非常“呆”板！
想要有效的改善这些问题，就必须让自动化测试变得“敏捷”起来！
在本系列后续的文章中会就“如何让测试脚本易写、易读、易维护”、“如何让断言不再成为测试的负担”、“如何通过持续集成让测试用例发挥更大的价值”进行详细的介绍，敬请关注！
SVN安装与启动服务
一、安装
首先下载一个SubVersion，和TortoiseSVN。前者是svn的服务器端，后者是svn的客户端。注意服务器端得版本和客户端得版本一定要一致才可以，否则会出现错误：
Error * 期望文件系统格式“2”；发现格式“3”
使用subversion过程中出现 Error * 期望文件系统格式“2”；发现格式“3”错误，这是服务器程序subversion和客户端程序TortoiseSVN版本号不一致的。删除subversion和原有的版本库，用相同的版本重新安装subversion和TortoiseSVN，问题即可解决。
下面我以Subversion1.4.5和TortoiseSVN1.4.5为例
二、建库
找一个地方见一个文件夹，这个文件夹是放你的项目的。我们把它称为库。以下以src为例。然后再这个文件夹上右键，选择Create repository here 或者在命令行里执行D:\ApplicationSetUp\Subversion\bin>svnadmin create E:\src
命令行要在安装目录中bin文件夹下执行。
三、设置用户名和密码
设置用户名和密码是成员之间修改项目后伤处使用的。下面我们就来设置一下用户名和密码吧。在刚才建的库文件夹下的conf文件夹里找到一个叫svnserve.conf的文件。用一个文本编辑器将它打开。然后找到## password-db = passwd这行代码。将这行代码签名的#号全部去掉，并且确保顶格不存在空格。#表示注释，去掉#和空格表示启用密保文件。
然后再conf文件夹下找到一个叫password的文件，同样用文本编辑器打开，然后看到如下代码：
[users]
# harry = harryssecret
# sally = sallyssecret
这两行是两个用户名和密码，等号前面是用户名，后面是密码，一行是一个用户。我们可以直接在这下面追加我们自己设置的用户名，也可以把他删除重写。例如：
[users]
jane=123456
spring=789456
写好之后保存就可以了。
四、启动服务
同样是在安装目录下的bin文件下执行D:\ApplicationSetUp\Subversion\bin>svnserve -d -r E:\src，效果如下
这样服务就启动成功了。这个命令窗口不可以关，如果关闭的话服务也就关闭了。这样很不方便，解决的办法就是将服务添加到windows系统服务里面。具体操作如下：
C:\>sc create svn binpath= "D:\ApplicationSetUp\Subversion\bin\svnserve.exe --service -r c:\svnroot" displayname= "Subversion Server" depend= tcpip start= auto
运行这一行命令，两个路径分别是svnserve.exe的地址和库的地址,其中svnservcer.exe就是刚才我们启动服务用的那个，所以写那个路径就好了。start=auto，每次开机自动运行;想手动的话，net start svn或者net stop svn切换开关。
服务添加成功后结果是：
这样我们的服务就启动成功了，现在把命令窗口关闭也没有关系了。
五、导入项目
找到自己的项目，然后在项目上右键。Import……，出现如图窗口：
上面的是我要导入的库德地址：svn://ip/库文件夹名称。建议不要勾选左下角的复选框。ignored 是忽略的意思，比如java的class包他是经常变化的，成员之间没有交换的必要。就可以将它忽略。还有一些私人的配置文件之类的。不然每个人都上传自己的配置文件，导致每个人在每次更新后，系统都跑不动。 直接点击确定就可以上传了。
下面就是每个成员机器上都装上TortoiseSVN,访问服务器上的项目就可以了。自己建一个存放项目的文件夹，然后右键check out ：
上面的地址是服务器地址。下面的地址是下载下来存放到哪里，点击ok就可以从服务器上当下来了。
建议每次编辑项目前都update一次，表示得到最新版本。编辑完之后再commit，这样用svn管理项目就省了非常多的时间。好了，就写到这里。希望对大家有帮助。