1.2 开发团队做的远不仅是开发
加入团队已经有一段时间，小艾逐渐发现，在工作中，似乎每个人都在做不一样的事情，而每个人在团队中的位置都显得不可或缺。一个疑问从小艾的心中冒出来：为什么团队中大家似乎都在做不同的事情？开发团队有多少种角色？测试团队又有多少种角色？测试专家的核心价值究竟在哪里？
凯文的解答从讲述团队分工开始。
细致的分工能提高效率的道理已经在许多需要专门技能的领域得到充分证明。在软件开发领域，分工的作用同样突出。分工的结果是，团队的成员根据分工的结果担当不同的角色，在其位，谋其职。
在一个软件开发团队中，狭义上从事开发任务的成员其实只占其中一部分；开发以外的其他任务，如项目管理、设计、测试等在软件开发过程中同样非常重要。作为测试团队中的一员，小艾有必要了解更多关于测试团队中角色分工的内容。测试在软件开发过程中的重要性，在许多人心目中并不那么突出，但实际上，软件的好坏，在很大程度上是由测试决定的。
1.2.1 术业有专攻
在知识密集型的社会，人是最关键的资源。软件开发的产出和从业人员的技能密不可分。然而，随着软件系统的复杂度越来越高，驾驭软件开发所需的人力资源远远超出单一个体的可承受限度。从这个角度而言，分工是解决个人控制力有限的唯一方法。从经验和效率的角度看，一个团队中的个体在技术和经验上各有千秋，分工能更有效地发挥人的长处。
在一个成熟的开发团队中，细致严密的分工使团队能以更高的效率运作。分工有助于提高效能的奥秘在于，绝大多数情况下，专注的人在效率上要高于注意力分散的人。细致的分工有利于凝聚人的注意力，提高熟练程度的同时减少切换带来的开销。在软件开发团队中，特别是使用了敏捷开发以后，团队的角色分工是非常明确的，每个成员根据各自的角色，专注于开发过程中的相应任务。
电子商务平台是一个涉及多种业务场景的复杂软件系统。软件开发任务的顺利完成，必须依赖于一个角色完善的团队的紧密合作。那么团队中究竟都需要哪些角色分工呢？
小艾所在的开发团队使用Scrum模式敏捷开发，是已经被证实可以提高开发效率的开发方式。按照敏捷开发的团队角色划分方式，Scrum团队的核心角色主要包括产品负责人（Product Owner）、Scrum Master及团队成员（Team）。在Scrum团队的外围还包括客户（Stakeholder）、经理（Manager）等角色 。
团队成员主要负责产品的具体开发。每个团队成员有具体的分工，如架构师、开发人员、测试人员、文档设计人员等。团队成员组成执行团队，这是个自组织、自定向和跨功能的执行团队。执行团队通过直接的行动推进项目的进度，以达到计划的目标。执行团队一般由5～9个各方面的专家组成，团队的组织结构文档贯穿整个开发周期。团队成员都是开发周期里各个领域的专家，他们使用专业的技能完成开发任务。对每种角色，通常都有一套技能集（Skill Set），通过技能集，可以定义一个角色应该具备的能力，反过来也能够判定一个员工是否具备担当某个角色的专业素质。
架构师是对软件开发过程的各个领域都具备一定专业技能的人员，主要任务是把软件开发的需求转化为可以实现的抽象设计和具体设计，并完成相应的设计文档。同时，架构师还需要把业务化的需求转化为技术化的功能性需求及非功能性需求。架构师需要参与软件开发各个阶段，也作为审核人员对详细设计和开发计划进行审查。架构师的技能特点是，具有更高视角，对技术的发展方向能够有全局的把握，对业务也有深刻的认识。可以说，架构师的知识体系兼顾了深度和广度。
开发人员的职责是根据抽象设计和高层次的具体设计进行更细化的具体设计，并按照设计完成编码实现及单元测试任务。在测试阶段，开发人员还有完成问题分析和解决缺陷的任务。由于软件的代码实现都是由开发人员完成的，因此开发人员的开发技能与软件是否以高质量完成有重要的关系。开发人员具有把宏观任务抽象化和把抽象概念具体化的能力，能够以微观的视角完成功能细节的开发。作为开发人员，卓越的理解能力和编码能力是必需的。
测试人员的任务是根据软件设计文档编写测试计划，并按照测试计划对软件进行测试。要完成的测试种类是根据需求定义的，在复杂软件系统的开发团队中，通常包括多种类型的测试人员，分别对各自的领域进行有针对性的测试。测试人员从另一个角度促进软件的开发过程，其工作的重点是发现问题和解决问题，因此，这对测试人员的洞察能力和分析能力提出非常高的要求。测试人员除了掌握测试方法学以外，还需要具有良好的抽象思维能力和逻辑分析能力。
文档设计人员的任务是根据需求文档和设计文档，设计编写交付给用户的说明文档和使用手册。文档对于软件产品的重要作用是不言而喻的，完备的文档是成熟软件产品必须具备的交付成果。一套好的文档在很大程度上决定了软件产品能否顺利被最终用户接受。文档对于开发团队也有重要的意义。清晰细致的技术文档对于产品维护的帮助也是不言而喻的。为了完成文档的设计，对文档设计人员的技能要求丝毫不能马虎。文档设计人员需要具有突出的表达能力和叙述能力，善于把抽象的问题具体化，另外，还需要有一定的艺术才能。
在团队的外围，相关的角色还有客户和经理。
客户是软件产品的直接利益相关者，他们从业务的角度提出对软件产品的需求。从本质上而言，客户是开发软件的根本动力，为软件开发支付相应的费用。在开发过程中，他们需要对软件的进度、是否满足需求进行相应的把关，并参与阶段性的回顾。客户的特点是对业务有深入的理解，能够清晰地理解业务流程。
经理在团队中的任务是控制开发进度、解决团队的资源问题、对团队的运行进行技术性的指导等。根据这三种不同的任务，可以有三个人分别担当不同的经理角色，分别是项目经理（Project Manager）、人事经理（People Manager）及指导经理（Coaching Manager）。通常情况下，也可能是一个成员同时兼顾多个经理角色。经理不直接参与项目，但在项目的外围提供关键的支持，为软件开发营造良好的环境，因而需要有更高的视觉和领导力以完成相应的任务
作为测试团队的一员，小艾最关心的是测试团队中都有哪些角色分工。可以认为，测试团队的成员都是敏捷开发项目组的测试人员，都具备测试人员的一般技能。
由于软件测试本身就可以作为一个项目来看待，因此测试团队中需要相应的项目组角色。测试负责人（Test Lead）是测试的主要统筹者，需要担当测试项目经理的角色，其任务包括定义测试计划、统筹人员调配、监督测试项目进度等。测试负责人定期向项目团队发布有关测试项目的进度和更新，对测试项目进度负责。作为测试的统筹者，为了顺利完成测试任务，测试负责人需要利用相关的规则结合经验安排测试的执行顺序，降低测试进度受阻或测试检测出严重问题但难以解决的风险。测试负责人的技能要求是综合的，既需要掌握测试的专业技能，又要具备良好的组织能力和协调能力。
测试架构师的职责是定义测试策略，从宏观上定义测试的方向和方法。测试架构师对测试目标的技术特性和业务需求有准确的把握，能为测试团队提供方法论方面的全面建议。在测试计划完成后，测试架构师需要审核计划是否全面覆盖应该包含的验证点，根据经验给出相关的执行建议。作为测试团队的“智囊”，测试架构师应该具有较高的技能水平，包括深入和全面的测试经验，对软件开发和测试的模型有全面的认识，对商业模式及客户的业务需求也有比较深刻的理解。
相对于具有宏观视角的测试架构师，测试工程师以“微观”的视觉专注于具体的测试任务。根据特定的测试场景，测试工程师重点关注其测试的目标业务部分，根据特定业务场景制订该部分的测试计划。由于不同的测试类型之间存在依赖关系，测试工程师得进行团队的直接沟通，使测试计划可以满足这种依赖。测试计划制订完成以后，测试工程师就根据计划执行测试；同时，在测试过程中发现缺陷时，测试工程师还有义务和开发人员一起分析问题的原因并提出解决方案。测试工程师的技能集主要包括设计和执行测试用例的专业技能，良好的业务理解能力和问题分析能力。
测试经理（Testing Manager）从资源调配的角度给不同的测试项目分配资源。通常来说，测试和开发的执行步调是不一致的，因此同一个测试人员有可能同时承担多个子项目的测试任务。在一个敏捷软件开发团队中，对测试人员的多任务处理能力有较高的要求。
在软件开发团队和测试团队中，有些角色对承担者的资历有明确要求，如架构师角色要求对业务和技术有一定的经验。然而，角色的不同仅仅体现分工的不一样，并没有级别的区分。因此，角色并没有贵贱之分。每个角色的技能集都非常明确，相同角色的承担者在技能的层次上也可能存在很大的差异。随着技术和经验的积累，每种角色都可以成长出资历深厚的专家。专家和菜鸟，在某种程度上，仅仅是一种“闻道有先后”的差异。
了解到团队中原来有这么多不同的角色，而不是仅有“程序员”，小艾觉得非常兴奋。在一个完备的团队中，体验不同角色的奥妙，该是一件多么有趣的事情！
1.2.2 好软件由测试决定
进入电子商务平台开发一段时间以来，小艾不时听身边的前辈提及IBM的软件质量不错。似乎每个人都认为自己有清晰的标准衡量软件的好坏，但对于什么样的软件才是好软件，小艾心中并没有明确的界定标准。用"好"来形容软件，显然是一个相当笼统的描述。
软件质量 包括两个相关但截然不同的概念--功能性质量（Functional Quality）和结构性质量（Structural Quality）。功能性质量反映的是软件是否按照设计实现并满足相应功能性需求（Functional Requirements）；结构性质量反映的是软件是否满足相关的非功能性需求（Non-Functional Requirements，NFR）。
要评价软件的功能性质量和结构性质量，有一系列衡量指标。有了衡量指标以后，另一个重要的问题就是如何获得这些指标的量化数值。软件测试是验证这些指标的有效方法。通过测试可以在一定程度上模拟真实的使用场景，并得到质量指标的具体水平。如果测试发现某些指标无法达到要求，则需要对系统进行改进，以求通过测试。测试的通过指标是根据质量的需求来定义的，系统通过了测试，可以从量化的角度说明它符合需求。
正确性（Correctness）反映了实现的功能达到设计规范并满足用户需求的程度。这是功能性质量的基本指标。正确性可以通过功能测试来验证。
可靠性（Reliability）衡量在规定的时间和条件下，系统维持其性能水准的程度。这是结构性需求的重要指标。对于企业级的应用系统，对可靠性通常都有很高的要求。可靠性指标可以通过系统可靠性测试获取。
易用性（Usability）反映用户掌握软件操作及理解软件事务所需付出的时间及努力程度。具体的指标诸如界面是否友好，是否有在线帮助，是否提供容易理解的异常信息等。易用性指标通常由功能测试获得。
可移植性（Portability）衡量系统从一个平台转移到另一个平台的容易程度，包括把程序从一种软/硬件环境转移到另一种软/硬件环境的容易程度等。大型软件的安装和部署可能也是一个复杂的过程，高可移植性的系统应该是容易安装和更新的。此外，企业级系统对多国语言的支持程度也是可移植性的一个衡量指标。可移植性在多平台的功能、系统测试、安装测试、多国语言测试中得到验证。
可迁移性（Migratability）衡量系统版本升级的容易程度。大型系统的迁移通常是一件非常复杂的事情，可迁移性需要通过迁移测试来验证。
效率（Efficiency）衡量系统执行某功能所需的计算机资源和时间有效程度，包括功能和性能是否经过优化，是否检验内存泄漏或溢出问题等。效率是系统测试的一个重要检测点。
作为测试团队的一员，小艾最关心的是测试团队中都有哪些角色分工。可以认为，测试团队的成员都是敏捷开发项目组的测试人员，都具备测试人员的一般技能。
由于软件测试本身就可以作为一个项目来看待，因此测试团队中需要相应的项目组角色。测试负责人（Test Lead）是测试的主要统筹者，需要担当测试项目经理的角色，其任务包括定义测试计划、统筹人员调配、监督测试项目进度等。测试负责人定期向项目团队发布有关测试项目的进度和更新，对测试项目进度负责。作为测试的统筹者，为了顺利完成测试任务，测试负责人需要利用相关的规则结合经验安排测试的执行顺序，降低测试进度受阻或测试检测出严重问题但难以解决的风险。测试负责人的技能要求是综合的，既需要掌握测试的专业技能，又要具备良好的组织能力和协调能力。
测试架构师的职责是定义测试策略，从宏观上定义测试的方向和方法。测试架构师对测试目标的技术特性和业务需求有准确的把握，能为测试团队提供方法论方面的全面建议。在测试计划完成后，测试架构师需要审核计划是否全面覆盖应该包含的验证点，根据经验给出相关的执行建议。作为测试团队的“智囊”，测试架构师应该具有较高的技能水平，包括深入和全面的测试经验，对软件开发和测试的模型有全面的认识，对商业模式及客户的业务需求也有比较深刻的理解。
相对于具有宏观视角的测试架构师，测试工程师以“微观”的视觉专注于具体的测试任务。根据特定的测试场景，测试工程师重点关注其测试的目标业务部分，根据特定业务场景制订该部分的测试计划。由于不同的测试类型之间存在依赖关系，测试工程师得进行团队的直接沟通，使测试计划可以满足这种依赖。测试计划制订完成以后，测试工程师就根据计划执行测试；同时，在测试过程中发现缺陷时，测试工程师还有义务和开发人员一起分析问题的原因并提出解决方案。测试工程师的技能集主要包括设计和执行测试用例的专业技能，良好的业务理解能力和问题分析能力。
测试经理（Testing Manager）从资源调配的角度给不同的测试项目分配资源。通常来说，测试和开发的执行步调是不一致的，因此同一个测试人员有可能同时承担多个子项目的测试任务。在一个敏捷软件开发团队中，对测试人员的多任务处理能力有较高的要求。
在软件开发团队和测试团队中，有些角色对承担者的资历有明确要求，如架构师角色要求对业务和技术有一定的经验。然而，角色的不同仅仅体现分工的不一样，并没有级别的区分。因此，角色并没有贵贱之分。每个角色的技能集都非常明确，相同角色的承担者在技能的层次上也可能存在很大的差异。随着技术和经验的积累，每种角色都可以成长出资历深厚的专家。专家和菜鸟，在某种程度上，仅仅是一种“闻道有先后”的差异。
了解到团队中原来有这么多不同的角色，而不是仅有“程序员”，小艾觉得非常兴奋。在一个完备的团队中，体验不同角色的奥妙，该是一件多么有趣的事情！
1.2.2 好软件由测试决定
进入电子商务平台开发一段时间以来，小艾不时听身边的前辈提及IBM的软件质量不错。似乎每个人都认为自己有清晰的标准衡量软件的好坏，但对于什么样的软件才是好软件，小艾心中并没有明确的界定标准。用"好"来形容软件，显然是一个相当笼统的描述。
软件质量 包括两个相关但截然不同的概念--功能性质量（Functional Quality）和结构性质量（Structural Quality）。功能性质量反映的是软件是否按照设计实现并满足相应功能性需求（Functional Requirements）；结构性质量反映的是软件是否满足相关的非功能性需求（Non-Functional Requirements，NFR）。
要评价软件的功能性质量和结构性质量，有一系列衡量指标。有了衡量指标以后，另一个重要的问题就是如何获得这些指标的量化数值。软件测试是验证这些指标的有效方法。通过测试可以在一定程度上模拟真实的使用场景，并得到质量指标的具体水平。如果测试发现某些指标无法达到要求，则需要对系统进行改进，以求通过测试。测试的通过指标是根据质量的需求来定义的，系统通过了测试，可以从量化的角度说明它符合需求。
正确性（Correctness）反映了实现的功能达到设计规范并满足用户需求的程度。这是功能性质量的基本指标。正确性可以通过功能测试来验证。
可靠性（Reliability）衡量在规定的时间和条件下，系统维持其性能水准的程度。这是结构性需求的重要指标。对于企业级的应用系统，对可靠性通常都有很高的要求。可靠性指标可以通过系统可靠性测试获取。
易用性（Usability）反映用户掌握软件操作及理解软件事务所需付出的时间及努力程度。具体的指标诸如界面是否友好，是否有在线帮助，是否提供容易理解的异常信息等。易用性指标通常由功能测试获得。
可移植性（Portability）衡量系统从一个平台转移到另一个平台的容易程度，包括把程序从一种软/硬件环境转移到另一种软/硬件环境的容易程度等。大型软件的安装和部署可能也是一个复杂的过程，高可移植性的系统应该是容易安装和更新的。此外，企业级系统对多国语言的支持程度也是可移植性的一个衡量指标。可移植性在多平台的功能、系统测试、安装测试、多国语言测试中得到验证。
可迁移性（Migratability）衡量系统版本升级的容易程度。大型系统的迁移通常是一件非常复杂的事情，可迁移性需要通过迁移测试来验证。
效率（Efficiency）衡量系统执行某功能所需的计算机资源和时间有效程度，包括功能和性能是否经过优化，是否检验内存泄漏或溢出问题等。效率是系统测试的一个重要检测点。
作为测试团队的一员，小艾最关心的是测试团队中都有哪些角色分工。可以认为，测试团队的成员都是敏捷开发项目组的测试人员，都具备测试人员的一般技能。
由于软件测试本身就可以作为一个项目来看待，因此测试团队中需要相应的项目组角色。测试负责人（Test Lead）是测试的主要统筹者，需要担当测试项目经理的角色，其任务包括定义测试计划、统筹人员调配、监督测试项目进度等。测试负责人定期向项目团队发布有关测试项目的进度和更新，对测试项目进度负责。作为测试的统筹者，为了顺利完成测试任务，测试负责人需要利用相关的规则结合经验安排测试的执行顺序，降低测试进度受阻或测试检测出严重问题但难以解决的风险。测试负责人的技能要求是综合的，既需要掌握测试的专业技能，又要具备良好的组织能力和协调能力。
测试架构师的职责是定义测试策略，从宏观上定义测试的方向和方法。测试架构师对测试目标的技术特性和业务需求有准确的把握，能为测试团队提供方法论方面的全面建议。在测试计划完成后，测试架构师需要审核计划是否全面覆盖应该包含的验证点，根据经验给出相关的执行建议。作为测试团队的“智囊”，测试架构师应该具有较高的技能水平，包括深入和全面的测试经验，对软件开发和测试的模型有全面的认识，对商业模式及客户的业务需求也有比较深刻的理解。
相对于具有宏观视角的测试架构师，测试工程师以“微观”的视觉专注于具体的测试任务。根据特定的测试场景，测试工程师重点关注其测试的目标业务部分，根据特定业务场景制订该部分的测试计划。由于不同的测试类型之间存在依赖关系，测试工程师得进行团队的直接沟通，使测试计划可以满足这种依赖。测试计划制订完成以后，测试工程师就根据计划执行测试；同时，在测试过程中发现缺陷时，测试工程师还有义务和开发人员一起分析问题的原因并提出解决方案。测试工程师的技能集主要包括设计和执行测试用例的专业技能，良好的业务理解能力和问题分析能力。
测试经理（Testing Manager）从资源调配的角度给不同的测试项目分配资源。通常来说，测试和开发的执行步调是不一致的，因此同一个测试人员有可能同时承担多个子项目的测试任务。在一个敏捷软件开发团队中，对测试人员的多任务处理能力有较高的要求。
在软件开发团队和测试团队中，有些角色对承担者的资历有明确要求，如架构师角色要求对业务和技术有一定的经验。然而，角色的不同仅仅体现分工的不一样，并没有级别的区分。因此，角色并没有贵贱之分。每个角色的技能集都非常明确，相同角色的承担者在技能的层次上也可能存在很大的差异。随着技术和经验的积累，每种角色都可以成长出资历深厚的专家。专家和菜鸟，在某种程度上，仅仅是一种“闻道有先后”的差异。
了解到团队中原来有这么多不同的角色，而不是仅有“程序员”，小艾觉得非常兴奋。在一个完备的团队中，体验不同角色的奥妙，该是一件多么有趣的事情！
1.2.2 好软件由测试决定
进入电子商务平台开发一段时间以来，小艾不时听身边的前辈提及IBM的软件质量不错。似乎每个人都认为自己有清晰的标准衡量软件的好坏，但对于什么样的软件才是好软件，小艾心中并没有明确的界定标准。用"好"来形容软件，显然是一个相当笼统的描述。
软件质量 包括两个相关但截然不同的概念--功能性质量（Functional Quality）和结构性质量（Structural Quality）。功能性质量反映的是软件是否按照设计实现并满足相应功能性需求（Functional Requirements）；结构性质量反映的是软件是否满足相关的非功能性需求（Non-Functional Requirements，NFR）。
要评价软件的功能性质量和结构性质量，有一系列衡量指标。有了衡量指标以后，另一个重要的问题就是如何获得这些指标的量化数值。软件测试是验证这些指标的有效方法。通过测试可以在一定程度上模拟真实的使用场景，并得到质量指标的具体水平。如果测试发现某些指标无法达到要求，则需要对系统进行改进，以求通过测试。测试的通过指标是根据质量的需求来定义的，系统通过了测试，可以从量化的角度说明它符合需求。
正确性（Correctness）反映了实现的功能达到设计规范并满足用户需求的程度。这是功能性质量的基本指标。正确性可以通过功能测试来验证。
可靠性（Reliability）衡量在规定的时间和条件下，系统维持其性能水准的程度。这是结构性需求的重要指标。对于企业级的应用系统，对可靠性通常都有很高的要求。可靠性指标可以通过系统可靠性测试获取。
易用性（Usability）反映用户掌握软件操作及理解软件事务所需付出的时间及努力程度。具体的指标诸如界面是否友好，是否有在线帮助，是否提供容易理解的异常信息等。易用性指标通常由功能测试获得。
可移植性（Portability）衡量系统从一个平台转移到另一个平台的容易程度，包括把程序从一种软/硬件环境转移到另一种软/硬件环境的容易程度等。大型软件的安装和部署可能也是一个复杂的过程，高可移植性的系统应该是容易安装和更新的。此外，企业级系统对多国语言的支持程度也是可移植性的一个衡量指标。可移植性在多平台的功能、系统测试、安装测试、多国语言测试中得到验证。
可迁移性（Migratability）衡量系统版本升级的容易程度。大型系统的迁移通常是一件非常复杂的事情，可迁移性需要通过迁移测试来验证。
效率（Efficiency）衡量系统执行某功能所需的计算机资源和时间有效程度，包括功能和性能是否经过优化，是否检验内存泄漏或溢出问题等。效率是系统测试的一个重要检测点。
可维护性、可扩展性（Maintainability、Scalability）反映当环境改变或出现错误时，执行修改或修复的难易程度。系统的设计是否很好地考虑日后扩展的需求，架构是否灵活等因素决定可维护性和可扩展性。系统测试可以获得系统的可扩展性指标。
健壮性（Robustness）衡量系统在接受异常或错误输入后能否返回正确的提示信息且不影响正确运作的指标。详细的功能测试是检验健壮性的主要方法。
安全性（Security）衡量系统对攻击性或不当的访问的抵御能力，检测的方向包括在受到没有授权的访问时系统对自身及数据的保护程度，系统的安全机制是否正确地实现，系统在受到攻击时是否能保持正常的业务运作等。系统测试有专门的测试涵盖安全性的审核。
有了诸多衡量质量的指标，软件的好坏就可以量化了，可见有效的测试是软件质量的重要保证。测试除了提供量化指标以外，还可以作为动力来驱动开发的进度，这就是极限编程倡导的测试驱动开发（Test-Driven Development，TDD）。
测试驱动开发的要点是先写测试程序，然后再编码实现使其通过测试。测试可以有效推动需求的实现，但是测试场景的覆盖度不足以涵盖所有的分支，因此，开发前的完整设计及第一轮开发过后的详细功能测试能够避免测试场景的覆盖问题。这样，测试场景相当于提供给开发人员的指导性主线，加快主要功能点的开发速度。
测试驱动开发的方法为开发提供一种新的方式，测试处于主导的位置。但测试的更重要作用还是在于提供衡量软件质量的量化指标。因此，我们认为，软件的好坏是由测试决定的。
1.2.3 测试也有大学问
既然软件测试对于软件质量有非常重要的影响，那么，如何有效地进行软件测试，则是非常值得关注的问题。
测试的目标是发现软件系统中存在的缺陷，这其中有一个关键的原则--尽可能早地发现问题。
在软件开发的前期甚至是设计阶段，某些缺陷可能已经存在，然而在这个时期要发现问题并不是件容易的事情。原因是多方面的。首先，在系统的很多功能模块尚未开发完善时，由于相互依赖关系而引起的缺陷一般难以被发现，因为缺陷只有在系统进行了集成以后才会真正暴露出来。例如，有些模式在简单的系统架构下可以带来不错的开发效率和运行效率，但是随着新模块的加入，这种架构的集成复杂度会急剧提高，系统原有的"精简"优势在这种条件下不复存在，新模块的运行效率会受到明显影响。这是个很明显的缺陷，但是这种设计的缺陷在新模块加入以前不可能很容易地暴露。其次，有些缺陷在开发前期看起来也许算不上是个缺陷，测试人员很容易忽略或仅仅把它当做一个"事件"。这种问题的严重性随着开发的深入才会逐渐显现。一个典型的例子是数据库查询的效率问题。使用全表扫描（Table Scan）可以获取完整的数据集合，全表扫描的效率缺陷在开发初期常常不容易被察觉，随着越来越多的数据和查询的加入，全表扫描的问题才会变得越加明显。另外，在开发周期的前期，项目人员通常会把注意力放在开发新功能上，在测试方面投入的资源相对较少，因此发现问题的可能性也降低了。
从图1-2中可以看到，一个相同的问题如果在不同的开发阶段解决，所需的开销是不一样的。越到开发后期，解决问题所需的开销越大。
有人对“尽可能早地发现问题”这个观点持怀疑态度。既然问题在开发的前期隐藏得非常好，而在后期更容易暴露，那为什么不干脆等到后期才专注于缺陷的发现和解决？这样不是更能降低测试的成本吗？
就测试本身而言，这种想法有道理，减小测试的开销同时让更多的问题暴露，似乎是个很理想的策略。然而，从软件项目的整体上考虑，这就是个非常糟糕的选择了。同一个缺陷，在不同的时间段发现，对其进行修复所需的努力很可能极不相同。一个典型的例子是使用了不恰当的消息模式而导致系统与外围通信效率低下的问题。如果问题在需求分析阶段即被发现，那么只要考虑更换一种消息模式。因为这个过程中任何实质性的劳动都不存在，所以并不需要额外的劳动开销。如果问题是在设计阶段出现的，那么更换消息模式还是必需的，同时，还需要考虑更换模式对外围接口的设计是否有影响。当然，这种考虑主要是评估性质的。假如是在功能实现的前期发现问题，那么除了评估对外围的影响以外，重写一部分代码是必不可少的。随着开发的进一步推进，可能有很多模块对消息模块存在依赖，如果针对依赖的开发已经完成以后才发现问题，不可避免地，相应的依赖模块的设计和实现就得重做，所需的代价变得更加高昂。
软件开发是一个迭代和累积的过程，越是底层的缺陷，发现的时间越晚，修复缺陷的代价越高。软件开发项目一般是以工程的方式运作的，作为工程会有明确的目标，因此，风险的控制非常重要。如果已知缺陷存在而无法修复，软件产品是无法发布的。如果在后期发现严重问题，修复难度很大或者需要大面积的改动，项目的风险会陡然增加。项目组面临的选择只有延期完成或宣布项目失败。很多失败的项目都是因为多次的延期而宣告失败的。可见，从项目整体的角度而言，“尽可能早地发现问题”才能降低风险，而问题越迟发现，项目的风险越高，对整体进度的影响越大。
作为测试专家，应该考虑的问题是如何更早地发现缺陷，以及有效地解决缺陷。
正如之前曾经提及的，开发的前期，缺陷可能已经存在但不容易暴露。那么，有没有办法让问题“提前”暴露呢？
发现问题的可行方法有两类，分别是分析方法 和测试方法。分析主要使用逻辑分析推理的方法发现缺陷和评估问题的严重性，并根据所处的阶段得到解决的方法。例如，有一个报表系统，起初是使用直接SQL查询的方式实现报表功能的。对实现的方法进行分析，可以发现，要生成条件复杂的报表，需要完成执行效率较低的查询语句，执行查询的时候是需要给相应的表格加锁的，因此有可能影响对相同的表有业务操作的模块。单从报表模块的设计和功能实现而言，使用直接的SQL查询已经可以满足功能上的需求，但综合考虑运行效率和跨模块的相互影响，通过分析可以得到结论--报表系统使用直接SQL查询的方法，在系统完成实现后会带来性能和系统级别的缺陷。
测试和分析人员可以针对这个问题直接创建一个缺陷，虽然这并不是通过测试发现的。针对这个问题，项目组有机会在设计阶段修复这个潜在的缺陷。这里使用“潜在的”作为定语，是因为这个缺陷没有经过测试证实，而是通过分析的方法推导认定的。但由于理据充分，本质上这个缺陷和测试发现的缺陷是一样的。为了提高查询效率，考虑使用物化表存储报表的内容，再通过筛选物化表的记录生成报表。因为有了物化表，可以把生产数据和报表数据最大限度地隔离，避免了数据锁定而引起的冲突；物化表从性质上也保证了查询的效率。重新设计和实现以后，可以认为对这个缺陷有了一个解决方法。最后要做的是通过严谨的测试证实问题已经解决或者潜在的问题得到避免。测试的方式是对设计分析时认为有问题的场景进行模拟，如果在这种场景下没有出现此前认为会出现的问题，那么这个缺陷解决方案就被认为是可以接受的。
分析方法不需要等待缺陷目标的开发完成并使用测试进行验证，然而，这种方法对分析人员技能要求较高。分析人员在需求分析和设计方面的经验必须比较丰富，才能准确定位问题所在。实施难度相对较低的是测试方法。测试方法设计出有针对性的场景，并在测试环境上模拟该场景。如果测试的输出和预期的输出存在差异，则能证实问题的存在。然而，要使用测试的方法发现问题，对测试环境是有要求的。要运行测试场景验证用例是否成功，前提是测试的场景能够在测试环境中正常运作。黑盒测试方式的测试用例一般是端对端（End-To-End）的，也就是测试用例是个完整的业务场景，而不仅仅是一个单元。在开发的早期，要走通一个端对端的用例大多情况下只是个奢望。可用的方式是使用“假对象”（Mock Object）或模拟器把端对端场景中没有完成实现的部分补充完整。
例如，在一个面向服务的体系结构（SOA）开发模式下的系统，如果某些流程中服务并没有开发完成，但目标测试用例必须用到这个没完成的服务，为了让用例完整地走通，可以设计一个简单的假对象。假对象不实现任何逻辑，对于任何输入，仅返回符合格式要求的特点数据。有了假对象返回的内容，业务流程就能以这种临时的方式完成。因为测试的重点在于已经完成的部分，因此假对象没有任何业务逻辑，也不会影响测试的有效性。如果测试验证失败，则证明测试目标存在缺陷。这时候可以对缺陷进行跟踪和解决。为了在早期发现问题，使用假对象或"假业务数据"来完成测试，都是常用的"主动测试"策略。
无论是使用分析方法还是测试方法发现的问题，都通过创建缺陷来跟踪。高效的项目组一般都有完善的缺陷跟踪机制和系统，使应有的资源流向相应缺陷并尽早解决问题。缺陷跟踪系统定义了缺陷的生命周期和相关信息 ，如图1-3所示。
缺陷（Bug），一般是指系统存在的问题或者需要加强的细节。从广义的角度而言，系统中任何需要修改或强化的任务都可以归类为缺陷。发现缺陷的人员在系统中创建一个新的缺陷，对于这个缺陷而言，创建的人是缺陷的创始人（Originator）。创始人会明确说明缺陷的内容，包括测试的时间、环境、测步和问题的描述、建议等。缺陷创建后，它处于开启（Open）状态，在任何时候它都会有一个直接的负责人（Owner），负责人是必须对缺陷采取行动的那个人。负责人的义务是推动缺陷的解决。初始化的时候，系统会根据一定的规则指定缺陷的负责人，创始人或者被指定的负责人可以重新指定（Assign）更适合解决该缺陷的人员为新的负责人。
针对一个开启状态的缺陷，首要的任务是验证其有效性，因为在不少情况下，缺陷对应的问题是由于不符合规定的操作导致的。遇到这种缺陷时，负责人仅需要把缺陷退回（Return）给创始人。如果缺陷被返回，创始人可以再次确认缺陷是否合法，假如缺陷确实合法，则可以重新开启（Reopen）缺陷，使缺陷回到开启状态；如果证实缺陷仅是不符合规定的操作引起的问题，则可以把它取消（Cancel）。取消状态是缺陷生命周期的其中一种终结状态。如果负责人经过验证后证实了缺陷的有效性，那么下一步的工作就是谋求解决方法。开始考虑解决方案前，需要接受（Accept）这个缺陷，使缺陷的状态从开启转成工作中（Working）。
在工作中状态下，缺陷的负责人可以与测试人员（缺陷创始人）及相关人员一同讨论问题的原因和解决办法，并根据方案对文档或系统进行修改。修改完成以后，负责人需要把缺陷的状态改为验证（Verify）状态，并创建一个验证记录（Verification Record）供缺陷创始人验证。这时缺陷的创始人同时也是负责人。如果验证通过，问题已经解决，则缺陷创始人可以认可（Accept）这个解决方案，这时缺陷的状态会变成认可（Accept）。系统可以关闭（Close）处于认可状态的缺陷。
从开启到关闭状态的流程，是缺陷生命周期的主要流程。在任何时候，基于新线索的发现，缺陷创始人都可以取消缺陷。有一些问题可能在不同的测试用例中以不同的方式暴露出来，或者分别被不同的测试人员发现，这种问题所被报出的缺陷最终都会被归结为同一个缺陷。缺陷负责人仅需要跟踪第一个被创建的缺陷（主缺陷），而其他缺陷会被标上重复（Duplicate）的记号。然后，验证缺陷的步骤无论是对主缺陷还是重复缺陷的创建人都是必需的。
这种基于状态的缺陷生命周期管理模型有利于跟踪缺陷的状况并推动缺陷的及早解决。缺陷的属性中会包括重要性、严重性、发现时间等信息，根据这些信息，项目组可以把更多资源分配给更重要的、严重的和紧急的缺陷。
测试专家在大多数情况下会作为问题的发现者出现，因而也顺理成章地成为缺陷处理的推动者。如何更早地、有效地发现问题，是测试专家的一项非常有技术含量的工作。而测试专家的另一项有技术含量的工作，就是发现问题后的问题分析（Problem Determination，PD）。
开发人员要做的，远不仅限于开发；而测试专家要做的，也远不仅限于测试。系统出现缺陷好比一个人生病了，而问题分析的过程则好比医生对病情的诊断，问题分析的主要任务是找到问题的原因。只有发现了问题的原因，才有对症下药解决问题的可能。
问题分析常用的系统方法有两种--自顶向下（Top-Down）和自底向上（Bottom-Up）方法。在分析错综复杂的问题，如系统级别的结构问题或性能问题时，这两种方法能够有效地定位问题。
自顶向下方法，其着眼处在于整体。使用自顶向下方法，首先应该认同的一个观点是，系统整体的问题可能是系统某个部分的原因引起的，而这个局部的问题放大后会在系统的宏观级别上表现出来。通过观察和分析存在缺陷的系统整体情况，把系统分成若干部分，并逐个部分判断可能存在的问题。判断确定“嫌疑”所在后，使用调整--测试的方法证实判断的正确性。如果判断正确，宏观的问题确实存在于系统中，那么可以对这个细节进行修改，解决问题；如果判断不正确，则需要重现判断。从宏观到微观的过程也可能不是一步到位的，在复杂的系统中，这个过程可能会分为多个级别的细化来完成。有时候，整体的问题可能是由多个划分同时存在的问题引起的。通过逐个验证测试系统划分的“地毯式排查”方式，可以扫清所有“患处”。
一个系统的局部分解方式通常是稳定的，使用自顶向下方法的理念在于通过这种稳定的分解，使用穷举方式最终可以确切地找到发生问题的局部。其好处是对于经验不多的人员，使用自顶向下法也能最终找到问题所在。当然，缺乏经验也可能带来苦头--对某些局部的验证也许是不需要的。
相对而言，自底向上方法对分析者的能力要求较高。使用自底向上方法的前提是，承认缺陷的全部或部分是由于系统局部细节的问题引起的。分析时，根据系统表面看到的蛛丝马迹，直接判断出现问题的根源，并验证这个判断是否正确。实践上，可以从最底一层起，对系统在逻辑上或功能上进行划分，然后设计特定的测试场景，有针对性地验证这些划分是否正常。因为对系统进行过划分，所以一旦验证性的测试重现了问题，则能够比较清晰地定位究竟是哪个部分存在问题。
这个从下往上的判断过程当然是很有讲究的，遭遇问题的经验、对问题的“嗅觉”，都有助于提高判断的准确性。复杂的系统中可能有问题的细节成千上万，作为分析人员，首先应该对系统的这些细节及其在整体中的作用比较熟悉，其次要拥有直达问题根源的“直觉”。如果缺少这种一击即中要害的技能，自底向上的问题分析方法可能并不奏效。
值得注意的是，无论是自顶向下还是自底向上的问题分析方法，其本质其实都是准确地重现和定位问题。只要问题得以有效重现和定位，离找到解决的办法就不遥远了。
自顶向下和自底向上方法可通用于一般各种测试类型，针对不同测试类型，这两种方法的具体使用方式可能存在不同之处。
发现、定位和解决问题的方法，是测试人员的核心技能。由于测试的门类众多，针对系统的测试也有多种角度，这些方法在不同的测试中会有不同的具体表现。
经过与凯文的谈话，小艾觉得自己对测试本身及其重要性、测试的技巧和窍门等方面的理解都加深不少。许多要点其实小艾在日常工作中已经有所接触，只是缺少系统的总结和提炼，而其他一些能力，则需要通过更多积累才能达到。凯文提醒道：“作为测试专家，核心的能力其实还是思考的能力。五花八门的测试方法和技术，得通过自己的实践、总结和思考，转化成系统的测试方法论。当一套属于你自己的测试方法论已经形成的时候，意味着你已经从专家成长为高手了。测试，在这种角度看，就是一个完备的哲学体系。”
（未完待续）
相关链接：
一个软件测试工程师的成长日记（连载一）
测试流程图如下：
一、测试准入条件
1、不接受无详细需求文档的项目；
2、需要测试的项目至少提前5个工作日提交测试组进行需求分析；
3、一般DEMO不予与支持；
4、开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用；
二、测试准备
1、需求分析
拿到项目需求后仔细阅读，分析整个程序的功能分布及逻辑关系，细分程序功能点，理清各功能点之间的关系。
2、用例设计
根据各个功能点设计详细的功能测试用例，要求设计的测试用例必须覆盖需求。
3、测试计划
根据项目的实际进展及测试资源制定测试计划，合理有效的分配测试任务及时间。若在后期项目变动较大或其他情况需对计划进行维护更新
三、系统测试
1、功能测试
① 开发输入的程序包要求：必须开发人员自测后程序能正常运行，各功能都正常；
② 功能模块测试：需照详细的功能测试用例测试一轮，若测试用例未完全覆盖功能或有错误，则记录下有问题的用例，待测试完成后进入测试用例文档修订。
③ bug的提交需遵守bug提交规范。
④ 返测：输入新版本的程序后对于开发人员修改后的bug进行返测，待返测完成后再按照修订后的详细功能测试用例测试一轮，总体测试循环次数要控制在3轮以内，已保证开发及测试的效率。
⑤ 测试报告：每轮测试完成后测试人员需输出一份功能测试报告，报告中详细记录本次测试发现的各类型bug情况，清楚描述测试环境及测试数据等。
2、健壮性、性能及UI界面测试
① 健壮性测试：
测试程序的稳定性、容错机制、异常处理等。注意：Symbian平台的软件需通过所有Symbian签名的测试用例。
安装/卸载、网络接入点更改测试。
② 性能测试：测试程序对系统资源的占用，联网成功响应速度，按键响应速度，并发测试等。
③ UI界面测试：查看程序各UI界面与需求规定的UI效果的差异，提交bug时需在附件中提交需求效果图与实际程序截图的对比。
3、适配性测试
① 根据UI测试用例测试在不同机型及分辨率的真机环境下UI界面是否正常显示，横竖屏切换是否显示正常。
② 根据验收测试用例测试软件功能是否正常。
③ 根据手机功能兼容测试用例测试软件的运行是否影响手机系统常用功能的使用。
4、系统测试报告
针对整个系统测试过程中的测试情况作出总结，具体内容参考《系统测试报告书写规范》
四、验收测试
对已通过系统测试的程序进行验收测试，测试其主要功能及业务逻辑是否完全符合需求。在完成测试用例后可进行随机测试，模拟用户体验，检验是否有其他未发现的问题。
测试输出文档：
① 验收测试用例：不同于系统测试中的详细功能测试用例，验收测试用例只需覆盖程序的功能及业务逻辑即可。
② 验收测试报告：对于验收测试出现的问题详细描述。
③ 验收测试通过的程序包：正式发布的程序包必须通过验收测试由测试人员发布，其他人员发布的程序均属于测试版本。
五、测试总结
测试负责人对项目的测试过程及结果进行总结，输出测试总结文档。
第1章 上班第一天，新人培训
1.1 测试专家的第一步
小艾是某名牌大学计算机科学专业硕士毕业生，这天是他离开校园走上工作岗位的第一天。他将成为大型外资IT公司IBM的软件测试工程师（Software Test Engineer），开始一段新的旅程。
1.1.1 我是菜鸟
在离开校园以前，小艾对将要从事的工作几乎一无所知。记得面试时被问及对测试的想法时，他的理解是，测试就是给产品挑错吧，目标应当是保证产品以高质量交付给用户。面试经理告诉他，其实测试是软件开发过程中必不可少的重要流程。在追求质量和效率的软件工程里，如何有效地对复杂的软件半成品进行测试，其实有许多问题值得工程师们去思考和探索。软件测试工程师的工作将很有趣、充满挑战。于是，对新事物充满好奇心的小艾欣然接受了软件测试工程师这个职位邀请，充满期待地走进这个他完全不了解的神秘领域。
产品开发组的同事，包括组长和老员工，对小艾这只菜鸟照顾周到，一会儿工夫他就把入职的流程办妥，工作的机器也准备就绪。坐在新的座位，小艾开始憧憬自己的新工作。可是测试却是一张陌生的面孔，让他有点无所适从。于是，小艾找到公司给他安排的“导师”凯文，希望凯文能帮他排解困惑。凯文是测试组组长，一位具有丰富工作经验的老员工。未来，就从这一刻开始向小艾展露出微笑。
“凯文，我对将要从事的工作一无所知。你能告诉我测试工作都包含些什么内容吗？我们应该如何做测试？什么时候可以真正开始工作？”
凯文对小艾的问题一点儿也不陌生，这些问题不正是几年前他入职时的困惑吗？“小艾，别着急，请慢慢听我说。我也像你一样，是从菜鸟一步一步成长起来的……”
经过与凯文的谈话，小艾心中的一团迷雾逐渐消除了。
原来，在大型软件开发团队中，测试被分成很多种类和步骤，每种测试有针对性地模拟使用测试对象的场景，并试图找出测试对象的潜在问题和缺陷（Bug）。在确定原因后，制定严谨完善的解决方案并根据方案修复缺陷。测试其实是发现并解决问题的过程，而其目标则是让软件产品以尽可能高的质量交付给客户，使软件产品中存在的问题尽可能少，这样，软件的用户可以得到最完美的使用体验。
除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。可行的方法是运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。软件开发本身是追求产出和投入比的工程性过程。因此，考虑测试的内容和方式时，都应当以高产出投入比为最终目标，最大化地利用现有资源排除潜在的问题。
小艾听说过风险控制，在软件测试过程中，风险控制是通过专业有效的方法实现的。测试团队由许多个测试分队组成，每个分队的测试任务和方法都具有高度的针对性。
小艾回想，在学校的时候，他曾经参加过软件工程课程的项目实训。在项目中，测试很简单，其目的仅仅是验证开发的功能点是否正确并与设计一致。测试是在所有功能开发完毕后才开始的。当时项目规模很小，从计划的时候开始，大家就没有仔细地考虑过怎样做测试。由于项目组人数很少，在功能开发阶段大家也无暇顾及测试，而是到了功能开发已经完成后，大家才匆忙地花些时间测试。当然，这种测试非常简陋，没有计划细节，方向也不清晰，测试过程中的所有流程都手工操作一遍。发现问题则随时修改代码，如果修改后流程能走通，就认为测试已经通过了。
通过凯文对测试的类型和当今流行的开发模式的介绍，小艾发现测试远不是从前软件工程项目实训测试那般随便和简单。软件测试是一个严谨、全面且有条理的过程。这个过程中包含了多种测试类型，每种测试类型都有针对性地验证软件，发现相应的问题。测试就像河流中一张精心编织的网，软件的功能和流程就像河流中的鱼，要通过这张网的鱼必须足够优秀才能最终存活。正是这种“优胜劣汰”的思想，保证软件只有通过了测试这张网才得以与用户见面。
凯文娓娓道来，小艾对IBM的测试方法有了初步的了解：原来测试的种类可以如此多种多样。
单元测试是和开发最接近的一种测试。开发人员编写单元测试用例并执行，验证单元模块是否得出预期的结果。在敏捷开发模式中，有一种流行的开发模式叫做测试驱动开发（Test Driven Development，TDD）。测试驱动开发的核心就是把单元测试用例先做好，功能开发以通过相应的单元测试用例为目标。单元测试是粒度最小的软件测试，小粒度能保证复杂系统中的每个“螺丝钉”都质量合格。通过了单元测试的代码才可以继承到系统中，进行进一步测试。
功能测试是通过黑盒子模式发现代码集成后存在的功能问题的测试。顾名思义，功能测试关注的重点是系统的功能。通过执行自动或手动的测试用例，可以验证相应的功能点是否正确。只要测试用例设计完整，功能测试的网能把最终用户可能遇见的功能问题都“提前”发现并解决。可以说，功能测试保证了提供给用户的是产品而不是一堆垃圾。单元测试和功能测试的区别主要是粒度的不同。单元测试关注的是一个最小的代码片段，如一个类或接口，而功能测试关注的是一个完整的业务功能。
功能测试通过后，性能测试就随之开始了。性能测试是重点验证软件的非功能性需求的测试。企业级软件通常用于应对复杂苛刻的用户场景。在软件设计和安装的过程中，有许多细节能提供软件的性能，包括吞吐率、稳定性、可靠性等。性能测试通过自动化的方法模拟真实用户并发访问的场景，以验证系统的性能指标或发现其性能瓶颈。性能缺陷常常不是显而易见的，有时候得通过复杂的场景模拟方可重现问题。由于性能问题的复杂性，要定位问题的原因也是一个艺术的过程。通过了性能测试的软件系统从根本上保证了用户体验和长远利益。
正式版本发布前，测试组还要组织成品测试（GMV），测试软件的安装、部署、发布等情况，确保软件能最终顺利地安装到用户的环境中。通过集成测试后，软件的质量有了进一步的保障。
软件正式版本发布以后，根据用户的反馈，产品组需要发布多个小版本。发布以前，当然也要有针对性地测试小版本的功能、性能，以及和正式版本的兼容性。小版本的开发和测试周期比正式版本短得多，因此对测试团队的项目管理要求更高。
“在IBM，为了保证软件质量而进行的测试是全面而苛刻的。”凯文说，“等你完成了新员工培训并开始接触项目时，你将有更多机会从方法到实践了解我们的软件测试。”
1.1.2 苦练基本功（1）
小艾所在开发团队所负责的产品是电子商务平台。电子商务平台是一个功能强大的企业级应用，它支持多种计算机平台。要成为一名合格的测试工程师，首要的就是熟练掌握基本功。所谓基本功，指的是作为任何开发团队的一员，都应该掌握的基本知识和技能。
小艾发现上大学时学习的专业课还是非常有用的，诸如数据结构与程序设计、计算机组成原理、操作系统原理等。但这些课程大多只注重理论，缺少在真实环境中实践的经验。公司的软件开发通常都有比较成熟的基础设施，对于新人来说，了解开发平台和方式也是锻炼基本功的一部分。
操作系统是平台的基础。IBM的产品通常都支持多种流行的操作系统，如Windows，UNIX，Linux等；为了满足更大规模的应用，产品还能提供对大型机的支持。小艾最熟悉的操作系统是Windows，在学校和日常生活中基本都用这个系统，而对UNIX和Linux却是一知半解。在开发组的数据库里，小艾学习了大量关于UNIX/Linux基础的材料。在学习的过程中，他有机会操作各种平台的机器，这样在实践中学习效果是最好的。几周下来，小艾已经掌握了UNIX/Linux的系统管理知识和编程基础。他发现，在简洁的黑色文本界面背后，隐藏着超乎想象的强大计算能力。
学习了操作系统基本知识后，小艾满怀兴奋地找凯文：“我是不是可以开始测试产品了？”凯文摇头说：“离测试还远着呢！不过你可以接着实践测试环境搭建了。”所谓测试环境搭建，是指在操作系统基础上，安装测试需要的应用程序，并部署测试的功能代码，准备测试数据，建立起一个可供测试的环境。电子商务系统是基于中间件的网络应用程序，因此，必须从安装服务器程序开始。一个完整的企业级网络应用程序，通常需要集成多个服务器，包括网络服务器、应用服务器、数据库服务器等。坐在机器前，小艾发现搭建测试环境是一个艰巨的过程。
测试环境的搭建从安装网络服务器开始，接着是数据库服务器和应用服务器的安装。网络应用程序作为企业级应用，部署在应用服务器上。面对一系列的设置步骤，小艾感到头晕目眩。一连几天，小艾都在直接和服务器打交道。在UNIX/Linux上搭建测试环境，用户的权限管理是关键的部分。因为涉及许多手动操作的部分，一时疏忽引起的用户权限错误会导致搭建失败。小艾自问还是很有耐心的，这次也被测试环境安装折腾得“体无完肤”。经过凯文的多次“指点迷津”，在安装配置好服务器以后，电子商务应用程序也安装好了。
小技巧：正确的流程和步骤一定要及时记录。有了流程和步骤的指引，可以避免大量不必要的重复劳动。
这也仅仅相当于一个新建的购物商城做好了“硬装修”，商城还是空空的，还不足以接受业务流程。根据测试用例的要求，需要安装并激活业务模块。网上商城的经营模式、页面的样式、能够提供的功能等特性，都是通过激活业务模块并配置数据等步骤决定的。
激活了业务模块以后，工程师的测试才可以开始。
领教了测试环境安装的烦琐步骤，小艾想，要是测试工程师不得不耗费大量资源兼顾测试环境的安装和配置，那么将难以保障软件测试的质量。从资源利用优化的角度而言，这似乎也不是很好的方式。
带着疑惑，小艾找到了凯文，“环境安装耗时费劲，测试人员必须每次都从头到尾安装测试环境吗？”
凯文说：“看来你对环境安装的难度有了很深的体会啊。你的顾虑项目组很早以前已经考虑到了。我们发现，更细的分工是提高效率的源泉。你应当看看我们用什么样的方式实现了测试平台的高效搭建。”
凯文说，其实许多新同事也有着和小艾一样的疑惑，解决环境安装问题的方式是执行构建测试（Build Verification Testing，BVT）。
的确，构建测试是个烦琐、重复性的过程。为了有效搭建环境，避免人为原因的错误，采取的策略是最大程度上地使构建过程自动化。因为环境的原型和步骤基本上是类同的，这种条件很适合自动化。于是工程师们使用构建了参数化的脚本、响应文件等构建测试的元素，有了这些元素，构建过程不再每一步都需要人工干预，出现错误的可能性有效降低。当然，由于平台本身的复杂性，自动化元素的构建由构建组专门维护。构建组把这个过程称为构建测试。通过测试验证环境安装的正确性。
软件的构建（Build）本身是依赖于Java的，因此没有平台依赖性。但是，Java虚拟机是安装在不同的操作系统中的，于是测试环境的安装就有了平台依赖性。构建完整的测试应该包括对多种平台的支持。不同操作系统平台结构通常很不一样，需要提供有针对性的自动化构建程序。构建完成后，构建组还必须完成对所有支持的平台的构建测试。
有了自动化的构建程序和构建测试的步骤，可以保证测试环境正确和顺利地安装。但是，每次安装还是得花时间的。熟练的工程师使用构建程序在某个平台构建一个测试环境得花大半天时间。小艾从兴奋转为沮丧：每次安装半天时间的成本并不小啊，大家测试环境的资源耗费问题还没有解决。
幸运的是，开发实验室利用虚拟技术构建了基于不同平台的测试镜像。有了虚拟技术，时间和步骤也是“可复制”的。由于测试环境必须支持多平台，使用自动化方式搭建第一个测试平台的时间是不可节省的；但是，第二个、第三个测试环境的搭建时间确实可以节省。奥秘就在于虚拟技术。成功搭建一套测试环境后，就可以把这个环境保存成镜像（Image）。以后任何时间需要再使用这套环境，不必重新安装，仅需要把镜像恢复，并替换必要的机器信息即可。虚拟技术被多个平台支持，包括AIX、Windows、UNIX/Linux。用于恢复镜像的硬件环境既可以是实际存在的，也可以是虚拟的。
虽然没有仔细了解过虚拟技术，但小艾在学校的时候使用过Ghost克隆软件。凯文说：“虚拟技术的原理和Ghost有相似的地方，随着使用的深入，你会对虚拟技术有更多的认识。”
对测试环境安装有了初步的了解，作为菜鸟，小艾接着需要知道的是中间件技术。要知道，功能强大的电子商务平台是建立在IBM的WebSphere中间件基础上的。凯文开始给小艾介绍一些基于中间件的应用服务的基础内容。
中间件（Middleware）是提供系统软件和应用软件之间连接的软件，以便于各种部件之间的沟通，特别是应用软件对于系统软件的集中的逻辑。中间件技术在现代信息技术应用框架，如Web服务（Web Service）、面向服务的体系结构（Service Oriented Architecture，SOA）等应用中应用得比较广泛。中间件不提供具体的功能，但它却是系统中各个部件有机连接的桥梁。中间件可以提供对外围服务器，包括数据库服务器、应用服务器、Web服务器等的支持和管理。中间件技术建立在对应用软件部分常用功能的抽象上，将常用且重要的过程调用、分布式组件、消息队列、事务、安全、连接器、商业流程、网络并发、HTTP服务器、Web服务等功能集于一身或者分别在不同品牌的不同产品中分别完成。
接下来的日子里，小艾开始研究WebSphere中间件提供的功能。经过一段时间的学习，他掌握了通过应用服务器对应用程序进行管理和监控的方法。这部分知识对于测试中发现和解决问题起着关键的作用。
经过基本能力的训练，小艾基本上已经达到了进入项目组的要求。然而，对于项目如何运作，如何确保项目顺利达到预期结果，小艾却还是一知半解。接着，小艾在凯文的指导下，认识了敏捷项目管理的基本知识。
对于敏捷开发（Agile Development）的定义，工业界其实还没有标准的定义，而相关的描述倒是五花八门，各种定义也出现在出版物或网络博客中。缺乏标准定义，其实是因为敏捷开发的实现方式非常多样化。我们可以容易地找到关于敏捷的方式、方法、实践及技术等的描述。在IBM的软件开发和测试中，团队使用了多种流行的敏捷开发方式进行项目管理。使用敏捷项目管理的目的并不复杂，是为了提高开发效率，激发团队的积极性并尽可能降低项目失败的风险。
提到敏捷开发，会把某种开发方式作为“非敏捷”方式来对比，而这种开发方式通常会是传统的瀑布开发模型。在瀑布开发模型中，整个系统的开发被划分成需求分析、设计、实现、测试、集成和维护等阶段。这种划分本质上是把不同性质的项目内容分隔到不同的阶段，而某个阶段则专注地进行某种任务。专注在许多情况下带来了高质量，单一流程的划分却很容易带来资源浪费和失败风险的增加。如果在一个阶段，项目组只完成一组相同性质的任务，那么，团队中其他无关的人员在这段时间里就无事可做了。项目的成果必须到最后阶段才完成，中间任何步骤出现差错都有可能导致项目全盘失败，这样的项目风险是很高的。
敏捷开发从根本上避免了瀑布模型的弱点，它有两个核心点--迭代开发（Iterative Development）和增量开发（Incremental Development）。
迭代开发是一种“重复时序安排”的开发方式。迭代开发把一个完整的瀑布模型开发流程分成多个迭代，每个迭代可以看做独立的开发过程，其中包含了项目的主要步骤，如设计、开发和测试等。把完整过程分成多个持续时间较短的迭代，其好处是生产的周期变短了，每个完整的周期都会产出相应的产品，这种方式有利于在完整项目开发的过程中跟踪和控制开发进度及产品质量。
1.1.2 苦练基本功（2）
增量开发用的则是一种"分段完成"的策略。在增量开发模式中，系统中不同的部分被安排在多个阶段完成，各个部分完成后再集成到系统中。
在敏捷开发模式中，迭代开发和增量开发的策略通常会被同时使用，并统称为迭代开发，迭代开发框架如图1-1所示。
增量地实现系统的思想是迭代开发的基础。项目成员通过不断学习和总结，使开发效率不断提高，同时避免在后期的迭代中重犯某些错误。因此增量开发对于团队的进步也很有好处。
因为时间周期缩短，和传统瀑布模式相比，迭代开发的进度会紧凑很多。项目组必须定期开会确保项目如期进行。项目的周期称为冲刺（Sprint），每个Sprint通常持续2～6周时间。在Sprint开始之前，项目组会进行Sprint计划会议，安排当前开发周期的任务；而在Sprint结束时，项目组举行Sprint评审会议，对这个周期的交付件进行评审核实；评审会议结束后，项目组还需要进行简明扼要的Sprint回顾会议，回顾这个开发周期中做得好的或需要提高的方面，以便在下一周期提高开发效率。
在每个Sprint中，为了确保开发进度，项目组还需要举行周期的会议（通常是每天），确定各个小组成员更新已经完成的任务、即将开始的任务及使进度受阻的问题，并通过讨论得出解决问题的方案。这种周期的会议叫做每日站立会议（Daily Scrum Meeting），由Scrum Master主持。
小艾最讨厌开会了，他认为开会浪费时间却常常没什么有效的结果。但凯文告诉他，每日站立会议有个重要原则，为了避免浪费时间，每个成员的汇报时间必须严格限制，会议的持续时间只能在15到20分钟。更细节的问题都放在会后讨论。这样的安排优势是明显的，既能让所有成员了解项目进度，又不耽误所有人的时间。
听完凯文的介绍，小艾对敏捷开发条件下的项目运作有了最基本的了解。对于敏捷开发范畴而言，这仅仅是冰山的一角。凯文还列举了许多开发的方法，包括测试驱动开发（Test Driven Development）、极限编程（Extreme Programming）、开发统一过程（Open Unified Process）、结对开发（Pair Development）等。不同的项目根据实际情况会使用不同的具体开发方式。然而，有两样东西是所有这些方法的基础--计划和流程。
计划定义的是做什么（What）和什么时候做（When）。在项目或迭代的初期，项目负责人要根据需求定义项目的计划，计划的内容包括要执行的任务、任务依赖条件、负责人选、执行任务的时间等。对于测试而言，测试计划的制订非常重要。测试计划详细描述了测试的环境、场景、执行要点、依赖等内容。项目执行完全根据计划实施，因此，好的计划是项目成功的基础。
流程是项目成功的保障，它定义了怎么做（How）。无论是开发还是测试，每个步骤都有标准的流程。在软件测试中，测试环境的准备有标准流程，没有按标准流程安装的环境就可能有潜在的错误；执行测试的步骤有标准控制流程，没有按流程执行的测试结果是无效的。完全按照标准流程完成的测试，如果存在失败的测试用例，我们就可以很直接地从产品本身找原因，而不用怀疑是错误的执行导致了失败。流程控制每个步骤的正确完成，有了流程控制，软件的质量才得以保证。
作为菜鸟的小艾对测试工程师的基本功掌握得差不多了，他明白，这些基本功需要在实践锻炼中不断加深理解，才能得心应手，融会贯通。
1.1.3 培养专业技能
这天中午，小艾经过凯文的座位，发现他正在专心致志地阅读一本技术书籍。小艾好奇地问凯文，究竟是什么书那么有趣。面对小艾的一脸好奇，凯文细致地解释自己学习的内容：“我在学习脚本语言编程技术。作为测试工程师，开发技术对我们而言也同样重要。为了更好地进行测试，得学点脚本编程知识。”
“测试工程师也必须掌握开发技术吗？还有哪些技能是测试工程师应该掌握的呢？”小艾有些疑惑。
“的确，我们的工作应该专注在测试上，但这并不代表我们不需要掌握开发技术。恰恰相反，开发技术是测试工程师应该掌握的基本专业技能之一。先给你解释什么是专业技能，再介绍我们应该掌握哪些专业技能吧。”
在软件开发团队中，作为软件测试工程师，为了完成测试任务，有一些技能是必须掌握的，我们把这部分技能定位为专业技能。在开发团队里的“专业”，与高等院校中的“专业”不同。开发团队的专业，强调的是长时期从事的行为作业规范，规范保证了产品的质量。
一名专业的测试工程师，应该把开发技能作为其技能体系的基础。测试人员虽然不需要编写功能代码，但是测试人员在测试过程中需要完成测试代码的编写。掌握开发技能，有利于理解功能实现的方法和逻辑。我们知道，测试就像一把手术刀，务求一击即中要害，不让存在问题的地方漏网。测试工程师掌握了开发方法，基于对开发的了解，更容易设计出有效的测试场景和用例。例如，使用Java EE开发的应用程序，程序的实现逻辑很有可能影响垃圾回收的效率，那么设计测试用例时，应当重点测试功能模块对垃圾回收的影响。又如，使用JavaScript实现的前端页面，在不同的浏览器中的显示状况可能有明显差异，有些脚本是针对特定的浏览器开发的。了解JavaScript的这种特性及开发的逻辑后，设计测试用例时就应当在不同浏览器中针对可能有问题的脚本进行测试。测试工程师应该掌握数据结构和算法设计、设计模式和体系结构，了解不同的开发语言和平台的差异。
开发技能不仅包括设计和实现功能的技术，还包括发布和部署代码、配置环境的技术。软件产品的测试通常具有严格的版本限制，小版本的差异也完全有可能得出不一样的测试结果。测试人员了解代码的发布和部署，能够评估新代码的影响范围，并根据评估适当地调整测试的内容。当然，掌握代码发布和部署以后，至少不会糊里糊涂地就开始测试，而能够在确认代码的发布和版本都没有问题之后再行动。
开发团队使用了版本控制工具来管理程序的版本，了解新代码如何进入到软件版本中，对测试人员而言也很有用。在对原始代码进行修改前，程序员或测试人员需要创建一个“缺陷”，“缺陷”意味着系统有需要更新的地方。缺陷创建后，系统会生成唯一的缺陷号码，用于跟踪代码的更新状态。无论是因为加入新功能还是测试失败而创建的缺陷，都通过统一的平台进行管理。有了这种版本控制方法，对代码的任何改动都记录在案，任何引起新问题的线索都得以保留，系统也可以在需要时回滚到任何较早的状态。了解“缺陷”模式的运作，有助于测试人员执行测试或回归，验证缺陷是否修复。
鉴于测试工程师的专职工作是完成软件测试，因此测试专业技能是测试工程师技能体系的核心。
小知识：软件测试，从宏观角度而言，是指针对被测试的产品或服务进行的一系列关于软件质量的调查，软件测试结果对软件的拥有者（Product Owner）负责。软件测试还从一种独立的视角为业务运作提供客观评估，这种评估包括软件的质量达标程度及因为某种相应的实现方式而存在的风险等。
测试得到的是一种相对客观的结果，通过事实和数据对软件的质量进行定义，为软件的拥有者提供决策的参考。测试通过执行程序或应用的方式，达到发现存在的错误或缺陷的目标。至于测试，使用的方法则是多种多样的。理论上，任何方法，只要发现的错误或缺陷是确实存在的，都是可行的测试方法。但是在项目实践中，我们不可能把所有可能的方式都用上，而只能采取最有效和可控的方法。有效，是指这种方法有效模拟真实的应用，并有效地暴露潜在的问题；可控，指的是使用方法有明确的步骤，通过相应的步骤可以使暴露的问题重现。
真正的测试中，有效可控的测试方法通常有两类，分别是白盒测试（White-box Testing）和黑盒测试（Black-box Testing）。
白盒测试指测试人员可以直接访问内部数据结果、算法及其代码实现的测试，常见的方法包括编程应用接口测试、代码覆盖率测试、缺陷注入方法等。通过调用应用程序的公有或私有接口，验证返回内容的正确性的方式，是很常用的白盒测试方法。通常一个测试用例可以用于验证一个被测的接口。如果需要验证一个代码分支，还可以把分支需要使用的多个接口调用放在一个用例中。
代码覆盖率测试是检验代码是否满足指定覆盖率的测试。例如，可以设计一个测试，通过改变输入条件，使程序中所有代码行都被执行至少一次，并检验输出是否符合预期。覆盖率测试在一般条件下，最大限度地覆盖代码，评估代码的整体质量。缺陷注入关注代码在错误和临界条件的表现。错误和临界条件在所有输入条件中只占小部分，但这部分输入却非常关键，而且存在问题的可能性较大。测试涵盖了错误和临界条件，就能保证代码的健壮性。健壮的程序不仅能处理期望的输入，对于“不速之客”，同样能够从容应对。
白盒测试用最直接的方式，从根源上发现程序中的缺陷。然而，底层代码的逻辑往往错综复杂，分支繁多，白盒测试的方法需要测试人员对实现的细节比较了解，方可设计出有效的测试用例。而且，因为时间等条件的限制，要覆盖所有分支的所有条件，简直是个“不可能的任务”。于是便有了黑盒测试，通过触发业务相关的功能点，检验集成条件下系统的正确性。虽然不能期待黑盒测试方法能覆盖更多的代码分支，但这些方法针对的都是和实际系统应用相关的分支，因此黑盒测试对于评估系统是否达到需求是至关重要的。理论上，只要黑盒测试的用例设计得足够细致，测试能发现所有应用中可能存在的问题。当然，因为进行黑盒测试的时候系统是集成的，所以发现问题后，需要“打开黑盒子”，用额外的工作定位问题的确切原因。相对而言，白盒测试发现问题后，定位原因的过程会简单得多。
综合应用白盒测试和黑盒测试，可以达到有效测试系统的目的。
定义了测试方法，测试工程师应该明确的下一个内容是测试的执行。大型电子商务系统的业务逻辑非常复杂，集成测试往往需要涉及多个功能模块。如何执行测试用例问题，实际上是如何提高工作效率的问题。
对于界面操作、简单的功能验证用例，通常可以使用直接手工操作的测试方式；但是对于大多数逻辑复杂或者有特殊要求的测试用例来说，自动化测试是主要的测试执行方法。
手工操作的优势是方便灵活，只需有明确的测试用例作为指导便能执行，不需要花额外的时间准备完备的自动化测试材料。我们甚至可以通过手工操作的方式执行随机测试（Adhoc Testing）。探索式测试不使用可识别的测试用例，而采用相对“随机”的方式验证某些功能点的正确性。但是手工操作的重复开销是测试策略的设计人员必须重视的。由于测试步骤必须通过手工的方式执行，重复执行测试用例的时间与资源开销和第一次执行基本上没有任何区别。对于一线测试工程师而言，不停地重复手工测试用例是个无法摆脱的梦魇，至少热衷于接受新挑战的小艾这么认定。
自动化测试则能弥补手工测试在重复开销方面的不足。自动化测试，顾名思义，就是测试过程并不需要人工干预的测试方式。其优点是一旦测试的材料（包括自动化工具、自动化测试环境和测试脚本）准备好，测试可以在无须人工干预或在有限度的人工干预的条件下重复执行。对于流程复杂的测试场景，自动化测试在节省重复执行的资源的同时还能很好地控制测试质量和效率。当然，自动化测试对测试团队的组织和技术要求更高。要进行自动化测试，首先，测试团队必须有一套完备的测试工具集；其次，测试人员需要掌握测试工具的使用方法，包括如何编写自动化测试代码，如何执行并收集结果等；最后，对测试资源的维护也有更高的要求。自动化测试脚本和对应的测试环境应当严格归档保存，以备日后查询和重复使用。
作为一个成熟高效的测试团队，手工测试和自动化测试都是不可或缺的测试执行方法。两者优势互补，可以有效保障软件产品的质量。
在产品开发过程中，特别在使用敏捷开发模式的项目中，新功能的完成大多是分阶段的。功能点在不同的迭代中陆续发布，同时，在新的发布中还会包含对老版本的问题修复。作为测试，除了需要测试新发布的内容，还必须验证已经存在的功能是否正确，存在的问题是否已经修复。这是测试执行中很重要的一环--回归测试。就理论而言，只要有新的软件版本发布，对执行所有测试用例的回归测试是必需的，因为只有这样，才能从事实上保证所有功能在最新版本中的正确性。随着开发完成的功能越来越多，回归测试中要执行的测试用例也随之增加。自动化测试在重复执行方面的优势正好能满足回归测试的这种要求。
作为测试工程师，掌握了测试执行方法，可以认为已经掌握基本的专业技能了。然而测试工程师专业技能的涵盖范围其实非常广，因为高质量的测试要求工程师掌握更多的技术，包括架构设计、软件开发技术等。更好地掌握这些专业技术，目的是更好地服务于测试，测试的目的则是发现和排除软件中存在的问题。
“发现、解决问题其实是一种艺术。”凯文语重心长地指导小艾，“等你熟练掌握基本的测试专业技能的时候，我们还会从更深入的层次探讨测试的核心价值和技术。”
（未完待续）
第一种方法：在tomcat中的conf目录中，在server.xml中的，<host/>节点中添加：
<Context path="/hello" docBase="D:\eclipse3.2.2forwebtools\workspace\hello\WebRoot" debug="0" privileged="true">
</Context>
至于Context 节点属性，可详细见相关文档。
第二种方法：将web项目文件件拷贝到webapps 目录中。
第三种方法：很灵活，在conf目录中，新建 Catalina（注意大小写）＼localhost目录，在该目录中新建一个xml文件，名字可以随意取，只要和当前文件中的文件名不重复就行了，该xml文件的内容为：
<Context path="/hello" docBase="D:\eclipse3.2.2forwebtools\workspace\hello\WebRoot" debug="0" privileged="true">
</Context>
第3个方法有个优点，可以定义别名。服务器端运行的项目名称为path，外部访问的URL则使用XML的文件名。这个方法很方便的隐藏了项目的名称，对一些项目名称被固定不能更换，但外部访问时又想换个路径，非常有效。
第2、3还有优点，可以定义一些个性配置，如数据源的配置等。
还有一篇详细的
1、直接放到Webapps目录下
Tomcat的Webapps目录是Tomcat默认的应用目录，当服务器启动时，会加载所有这个目录下的应用。也可以将JSP程序打包成一个war包放在目录下，服务器会自动解开这个war包，并在这个目录下生成一个同名的文件夹。一个war包就是有特性格式的jar包，它是将一个Web程序的所有内容进行压缩得到。具体如何打包，可以使用许多开发工具的IDE环境，如Eclipse、NetBeans、ant、JBuilder等。也可以用cmd 命令：jar -cvf applicationname.war package.*；
甚至可以在程序执行中打包：
try{
string strjavahome = system.getproperty("java.home");
strjavahome = strjavahome.substring(0,strjavahome.lastindexof(\\))+"\\bin\\";
runtime.getruntime().exec("cmd /c start "+strjavahome+"jar cvf hello.war c:\\tomcat5.0\\webapps\\root\\*");
} catch(exception e){system.out.println(e);} |
webapps这个默认的应用目录也是可以改变。打开Tomcat的conf目录下的server.xml文件，找到下面内容：
<Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeloy="true" xmlValidation="falase" xmlNamespaceAware="false">
2、在server.xml中指定
在Tomcat的配置文件中，一个Web应用就是一个特定的Context，可以通过在server.xml中新建Context里部署一个JSP应用程序。打开server.xml文件，在Host标签内建一个Context，内容如下。
<Context path="/myapp" reloadable="true" docBase="D:\myapp" workDir="D:\myapp\work"/>
其中path是虚拟路径，docBase是JSP应用程序的物理路径，workDir是这个应用的工作目录，存放运行是生成的于这个应用相关的文件。
3、创建一个Context文件
以上两种方法，Web应用被服务器加载后都会在Tomcat的conf\catalina\localhost目录下生成一个XML文件，其内容如下：
<Context path="/admin" docBase="${catalina.home}/server/webapps/admin" debug="0" privileged="true"></Context>
可以看出，文件中描述一个应用程序的Context信息，其内容和server.xml中的Context信息格式是一致的，文件名便是虚拟目录名。您可以直接建立这样的一个xml文件，放在Tomcat的conf\catalina\localhost目录下。例子如下：
注意：删除一个Web应用同时也要删除webapps下相应的文件夹祸server.xml中相应的Context，还要将Tomcat的conf
\catalina\localhost目录下相应的xml文件删除。否则Tomcat仍会岸配置去加载。。。
tomcat部署web应用主要有以下几种方式：
1）拷贝你的WAR文件或者你的web应用文件夹（包括该web的所有内容）到$CATALINA_BASE/webapps目录下。
2）为你的web服务建立一个只包括context内容的XML片断文件，并把该文件放到$CATALINA_BASE/webapps目录下。这个web应用本身可以存储在硬盘上的任何地方。这种context片断提供了一种便利的方法来部署web应用，你不需要编辑server.xml，除非你想改变缺省的部署特性，安装一个新的web应用时不需要重启动Tomcat。
3）同方法2,只是将context片断放在CATALINA_BASE\conf\Catalina\localhost目录下.这种方法比方法2>要有效,笔者经过多次实验发现方法2不如后面这种方法好用.前者多次出现系统打不开的情况.
4）直接在server.xml中</Host>前加上Context片断，使用这种方法时，tomcat会自动在CATALINA_BASE\conf\Catalina\localhost目录下生成一个文件片断.方法同方法3具有同样效果.这种方式需要将ROOT目录删除才行。
另外，为了让tomcat只运行conf/server.xml中指定的web应用，可以有以下几种办法：
实现一：
1）将要部署的WEB应用放在webapps以外的路径，并在server.xml相应的context中的docBase指定。
2）删除webapps中的所有文件夹，以及conf/catalina/localhost下所有xml文件。
注：webapps是server.xml中的Host元素的appBase属性的值。
实现二：
1）修改server.xml中Host元素的属性，添加或修改：deployXML="false" deployOnStartup="false" autoDeploy="false"
2）含义：
deployXML="false": 不部署conf/catalina/localhost下的xml相应的WEB应用deployOnStartup="false" : tomcat启动时，不部署webapps下的所有web应用autoDeploy="false"：避免tomcat在扫描改动时，再次把webapps下的web应用给部署进来。
摘要：如同代码是程序员的成果之，软件测试报告是测试人员的丰要成果之一。一个好的软件测试报告建立在测试结果的基础之上，不仅要提供必要测试结果的实际数据，同时要对结果进行分析，发现产品中问题的本质，对产品质量进行准确的评估。本文详细说明一个软件测试报告究竟需要什么样的测试结果，需要对哪些结果进行归纳分析。
1、软件测试结果的内容
软件测试评估的目的是统计和分析测试结果，确定是否达到软件要求的指标。一般来说，首先需要分析实际测试执行的有效性和充分性，分析测试执行是否完全，软件问题的产生是否因为不符合测试的前提和约束；其次，统计测试过程中的所有软件缺陷，并将缺陷的各种属性进行归纳分析；最后，根据用例的执行情况对软件进行宏观的横向分析，确定软件缺陷的错误来源。
2、测试的有效性和充分性
评价软件测试有效性的主要目的是评价测试人员的工作和使用评价后的结果改进测试过程。在软件测试中，往往会存在一些无效的方面，评价的目标就是识别这些无效和问题以便可以采取修复措施。
在测试的有效性评价工作中，存在两个关键的因素：一是评估的目标，目标是对度量过程的恰当指导。无效的目标会使整个评价过程无效；二是实现度量目标所需的信息类别，信息的收集需要建立专门的小组，整个评价过程也应指派专门的人员负责，因为如果没有专人负责评价过程。那么就无法确保进行正确的数据收集和评估过程。
当所有的软件测试过程结束后，软件测试有效性评价工作就可以开始了，测试阶段的最终执行结果是它的入口条件，表1 列出了输入所需的一部分信息类型，根据具体项目的不同，也会产生其它的输入。
表1 测试有效性评价的输入信息
我们可以通过一个实际的例子来看看有效性是如何实现的，表2列出了软件需求规格说明中常见的几个章节。针对每个需求首先验证是否包含了相应的测试类型，比如在容量和时间要求章节中，是否包含性能测试、强度测试和余量测试等。接下来，列出每个测试类型有多少个测试项进行支撑，通过这一点可以看出各个测试类型在本次测试中的优先级状态。最后，列出每个测试类型包含的测试用例数量，可以反映出需求的覆盖情况。
……………………
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
2）软件测试缺陷按所属测试类型和级别统计
根据缺陷所属的测试类型和级别进行分析，可以精确的将缺陷定位到每个测试类型中，从而反应出软件在哪些方面存在的较大质量问题。
表4 软件测试缺陷按所属测试类型和级别统计
图2 软件测试缺陷按所属测试类型和级别统计
3）软件测试缺陷按缺陷类型和轮次统计
根据缺陷类型和轮次进行分析，可以将软件缺陷定位到代码层面，通过多轮的对比，从而可以看出软件修改过程中的修改趋势，可以有效避免错误的发生。
表5 软件测试缺陷按缺陷类型和轮次统计
图3 软件测试缺陷按缺陷类型和轮次统计
4、测试用例执行情况
测试用例的执行情况能够反应测试人员在执行测试的过程中，软件质量对软件在实际应用中产生的效果。与软件缺陷不同的是，缺陷反应的是一种现象和问题，而用例的执行情况则反应的是软件实际操作的使用难度。一个缺陷影响一个用例和一个缺陷影响多个用例，是两个完全不同的概念，所以用例的通过率是用户真正关心的数据。
在用例执行情况中，根据每轮测试的结果，可以分别对用例总数、执行用例总数、未执行用例数、通过数、未通过数和通过率等指标进行考核。用例总数代表了本次测试设计的用例总数，执行用例总数代表了本轮测试需要执行的用例总数，未执行用例数则是前两者的差数。而通过数、未通过数和通过率则反应了本轮测试用例的通过情况。
……
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
本文收录于《51测试天地》电子杂志第二十九期。
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第二十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
摘要：网站可用性测试并不像看起来那么简单。虽然它不像航天科学那么复杂，但仍是错综复杂的。本文将分享几条经验，帮你快速提高可用性测试技巧，避免纰漏。
Damian Rees为用户体验设计机构Experience Solutions的主管，作为UI设计专家，有着13年的设计经验，曾工作于BBC、国家航空交通服务局。他在Smashing Magazine发表文章了《Improving Your Website Usability Tests》，分享了提高可用性测试的几点经验。我们对该文进行了编译，内容如下：
在我首次进行可用性测试时，我遇到一位可爱的老妇人。她不会使用鼠标，而是将它拿在手中，指向屏幕，并对光标说着鼓励的话。测试结束后，我毫无收获。但这位妇人却认为我很“可爱”，建议我去见见她的孙女。从这件事上，我懂得了在招募测试参与者时应设定好明确的标准。
可用性测试并不像看起来那么简单。虽然它不像航天科学那么复杂，但仍是错综复杂的。本文将分享我从工作中总结出的几条经验，帮你快速提高可用性测试技巧，避免纰漏，使你和测试参与者更好地工作。
编写可用性测试脚本，回答特定的调查问题
在开始新的可用性测试时，不要认为需要做的仅仅是找到网站的重点区域，并请用户完成该区域中的任务。该方法可能会使你收到一些不错的建议，但你也会遭到项目干系人大量问题的狂轰乱炸，被弄得哑口无言。
关键点
找到你需要给以反馈的人，与其进行交谈，询问他们希望研究报告回答哪些关键问题。如果有很多问题，那就对它们进行优先级排序，想办法尽自己最大的努力来回答这些问题。如果某个问题十分模糊，抑或你不了解他们为什么会这样问，那就要想办法去弄明白。对问题背后的原因了解的越多，就越能更好地回答它们。
给测试参与者信心，让他们更自然地工作
当参与者投入到某一测试中时，他们往往不确定期望他们做什么。当前面有相机，后面有人盯着时，他们就会紧张。在一开始，如果有人请求你的指导，不要惊讶。如果一开始你就严格限制，他们就会认为做任何事之前，都要得到你的许可。
给测试参与者信心，让他们更自然地工作
关键点
鼓励用户自然地工作。给用户更宽泛的任务，允许他们按自己的喜好进行其他方向的探索。使用预先测试好的问题，帮助他们发现测试环境中的实际问题，然后让他们根据自己的想法自然地回答这些问题。例如，我想测试一个财产法网站，首要任务是请人们在喜欢的区域内寻找房子（特定的区域），这样我们可以真实地看到他们是如何使用网站的，同时可为下一个测试任务设定好环境。
为用户留出自由空间，使他们按自己的方式完成任务
早些时候，我通常在测试脚本中设置好任务，用户一离开我布置的任务，我就会要求他们再次回来。我对用户控制得十分严格，有时与他们无法和谐相处，同时我也失去了学习到期望之外东西的机会。
关键点
为用户留出足够空间以便他们在网站上自由畅游。把用户拉回测试任务之前不要追踪得太紧。你可能会担心对他们失去控制，或者担心他们不理解此任务，但仍要试着再多忍耐一段时间，这样你可以观察他们去了哪里，以及为什么到那里去，这也是一件很精彩的事。这种情况中往往会发现一些真正有价值的东西，所以尽自己最大的努力去这样做。只在你确定他们无法返回时，再进行追踪引导他们回来。
放松、沉默，观察所显露的一切
严格控制用户，只专注于你希望用户完成的事上，是很容易做到的。当他们做某件感兴趣或意料之外的事时，很有必要问一下他们在想什么。但此事不易过早，不易过于频繁，否则你可能无法观察到用户的自然行为。
让用户自由思索
关键点
尽量不要打断参与者的思路。你打断的次数越多，他们就越没有信心完成这些任务。如果你每30秒打断他们一次，他们就会失去思路，你将无法看到他们的自然行为。任务完成之后，你可以返回来再询问他们之前所发生的事。我曾遇到很多新手曾犯过这样的错误，在此提醒他们，同一时间一边问问题一边观察用户在做什么，是不可能的。
为参与者订制适合的任务
当你开始做一件新事情时，你可能会去控制存在的可变因素，并对未知因素进行锁定。根据经验，当你有足够信心相信你能解决发生的任何事时，你便会学会放松控制。
早些时候，我喜欢为用户写好某一任务的精确场景。但不久我了解到，如果我设置的任务与用户的自然行为无法匹配时，他们将不会遵从。记得有一次，我请一个19岁的男孩把自己想象成有三个孩子的妈妈，以完成某一任务。毫无疑问，他奇怪地看着我，没有这样做，而是放弃了。
关键点
为用户布置好整体任务，并为用户定制合适的场景。在测试开始前，花一点时间了解测试参与者是谁，他们当前使用哪些相似的产品、服务，是十分有用的。如果你利用这些信息构建出了符合实际问题、用户乐于参与的场景，用户不再简单地“假装”参与其中，你将会有更多的收获。
设定一些针对竞争对手网站的测试任务
在某一网站上花费整整一小时，对于你和测试参与者来说，是十分无聊的事。但无聊不是唯一的问题，你所有的发现及观察都是孤立。你并不明白，参与者平时就经常使用搜索引擎呢，还是因弄不明白网站导航，而只在使用你网站时使用呢。只观察一个网站，你无法了解用户使用Web的真实情况。
关键点
把竞争对手网站加入到测试计划中，作为测试工作的一部分。最好的方法是，在测试开始前询问参与者现在所使用的网站，并让他们展示给你看。然后再介绍一个他们不曾使用过的竞争对手网站。这样你就可以更好地掌握他们的行为模型，了解他们为什么选择这个网站而非其它，更重要的是还可以学习到其他网站的优秀之处。这将为你以后解决网站中棘手的可用性问题提供灵感。
不要让他们知道你所要测试的网站
过去，我曾犯过同样的错误。我太过明显的表现出所要测试的网站。当然，有些时候这是难以避免的，但如果可以，我建议尽量避免。主要原因是，当你为某一公司工作时（无论是员工还是代理人），任何人都很难完全忠诚于他们对该公司网站的真实体验。
关键点
在测试之前，如果我没有参与到网站的设计中，我就会强调自己的独立性。另外，在访问你真正想测试的网站之前，首先让测试者查看竞争对手的网站，并给出真实的反馈。如果这一切是在他们对所真正要测试的网站毫不知情的情况进行的，你就有更大的机会获得他们最真实的想法。
总结
如果你想提高可用性测试技术，除了多做测试外没有别的办法。不过，正如我在本文所强调的几点，你要知道，测试任务的设计及与参与者的交互方式将影响着你的研究结果。针对关键问题设计测试过程，在测试中不要过于严格是一个好的开始。另外，将竞争对手加入到测试中，鼓励用户自然地工作，以产生更好的结果。
本文出自：http://www.csdn.net/article/2013-04-23/2815003
一、执行测试用例
作为一个测试新手来说，最主要的工作应该就是执行测试用例，最基本的要求当然就是不能够出现执行漏测了。是的，达到这个要求毕竟简单，只要严格按照用例来执行就可以了，这里主要考验的就是一个测试人员的执行力和细心的能力。另外，这个阶段测试人员能够学习到自己测试模块的一些基本业务知识，以及如何去执行用例，提交和跟踪bug等等，这个阶段也很容易达到，甚至可能会跟第2个阶段一起进行，但是该阶段虽然简单却很重要
二、发现bug
经历第一个阶段后，这个时候测试人员可以开始在执行用例的基础上开始一些自己的发散测试（更好的叫法是探索性测试），来更好的发现一些通过执行用例无法测试到的bug。这个阶段就比较考察一个测试人员的发散思维了（个人觉得测试人员的发散思维恩能力是测试人员非常重要的一个能力，这也是软件测试的魅力所在），有的测试人员就是能够通过自己的一些想法来发现一些bug（甚至是隐藏很深的bug），并且很享受在其中。个人觉得这些能力（也可以叫对bug的敏感程度）是天生的，当然，并不是说这块能力不强的人在测试里面发展不好，因为测试也有技术（确定的因素）的成分，比如：自动化等。但是，这样的测试人员不太容易享受到发现bug给自己带来的成就感（即软件测试的艺术性）。当然，要达到这样的程度对于模块本身的业务逻辑也需要非常熟悉
三、保证质量
质量是一个测试人员的生命，当我们将一个功能模块交给一个测试人员负责的时候，我们肯定是希望对方能够给保证质量的。但是实际上要达到这个要求是很难的。首先，我们对于保证质量是如何定义的，是保证该模块到客户那里不会影响客户的业务还是在客户那里不出现问题？实际上2者是很难区分的，目前我们对于测试人员的要求大概都是能够发现所有的bug吧，虽然实际上不可能。其次，作为一个测试人员，我们自己对于该模块的测试策略该如何把握呢（因为测试时间是一定的）？根据个人经验，要达到这个目标，至少需要做到以下几点吧！
1、需求覆盖：对于的整个需求的理解程度：对于客户来说，为什么需要这个功能？主要是用使用习惯是怎样的？客户哪里可能会出现的一些异常情况等等
2、业务逻辑覆盖：对于整个业务逻辑的理解程度：通过看研发的设计文档和具体的实现逻辑图，来分析如何覆盖到所有的逻辑以及异常逻辑（这个时候还需要提前发现一些研发没有考虑到的地方），并且设计对应的逻辑测试用例，保证我们的测试业务逻辑的覆盖率（代码覆盖率非逻辑覆盖率）。当然，这个阶段是能够通过一些技术手段做的更好的，比如：接口测试、单元测试、代码的静态走读等等，后面再讨论...
3、性能压力覆盖（为什么就不说了）：主要是在前面对业务逻辑非常熟悉的基础上，对于每个业务逻辑的性能测试点进行分析，看下这些逻辑是否可能有压力点，比如：当资源不足的时候是否有影响？当并发数或者流量很大的情况下是否会有影响？是否会涉及到多线程通信或者进程之间抢占资源等等，分析完成后还需要考虑如何去覆盖到这些地方（包括压力是否足够等等）
4、关联覆盖：大部分情况下一个模块总是会和整个系统的其他模块存在关联的地方，那么我们除了要分析出和哪些模块有关联，还需要分析具体的关联点是什么？这其实就要求我们对于与之关联的模块也足够的熟悉，这样才能够更好的分析到对应点上
5、当然，还会需要涉及到其他的，比如：模块的可靠性，安全性等等
6、发散测试：一般情况下，前面的几点很难分析到非常的全面和充分，这个时候就需要依赖自己的分析能力和发散思维能力了，如果这方面比较好的话应该是有意外惊喜的，而且前面的一些测试也需要依赖自己的发散思维能力
如果能够达到这个阶段，相信你已经是一个比较让人放心的测试人员了，这些阶段一个非常重要的就是对被测模块的业务熟悉程度。
四、提高测试效率
测试是有成本的，而且测试的周期越长，成本越大，甚至可能影响整个产品在市场的占有情况或客户的满意程度。所以，对于测试人员一个很重要的要求当然是如何在更短的时间内保证质量。要做到这个程度，主要依靠两个手段吧！
1、前期缺陷预防：测试人员通过前期和开发人员配合，共同的将很多bug直接扼杀在摇篮，避免bug在后面被发现。下面可以从每个阶段来分析测试测试人员需要做好哪些事情。
（1）需求阶段：测试和研发一起将该功能的所有需求点全部列出来，并且分析所有的需求点是否明确和合理。另外，是否还有没有考虑到的客户的隐藏需求等等，通过不断的检视来完善。需要的能力：测试经验、对于需求的理解能力和思考问题的全面性
（2）设计阶段：加深对于设计的理解，多跟开发进行交流，能够根据自己的测试经验以及对于该模块的理解程度对研发的设计进行评审，并能够发现设计存在的一些问题（比如：一些场景可能没有考虑到，一些异常情况可能没有考虑到等等）。并且将自己后面可能会怎么测试提前告诉开发（这个时候心里应该大概知道该如何去测试该模块，可能的风险是什么灯）。需要的能力：对于模块的理解程度，对于用户场景的理解程度，对于整个业务的理解程度（参考测试人员的第3个阶段）。
（3）编码阶段：这个时候可以通过一些改进，比如：对研发的代码进行静态走读，通过工具覆盖，思考单元测试或者借口测试，对用例实现自动化等，目的就是在黑盒测试前就能够提前发现该模块存在的代码逻辑问题，减少后面的手工测试时间。需要的能力：代码理解能力、代码测试工具的使用能力，一定的编码能力，自动化开发能力等
2、测试分析能力
进入测试后，需要对我们前期的缺陷预防进行分析和总结，并且分析下该模块的质量：看下哪些地方是存在风险的，哪些地方是前面做的比较充分的，从而来制定我们的测试策略，减少一些没有必要的测试点或增加一些有效的测试点，让我们的整个测试更加的有效，并且通过不断的测试和分析，来及时调整测试策略，来减少我们的测试时间（比如：以前需要测试500个测试用例，后面通过分析后能够减少到300个，并且证明测试结果是一样的），当然我们需要对我们的测试结果负责，要达到这个程度应该是比较难的！
以上纯属个人观点，欢迎大家讨论。
版权声明：本文出自 pengyongbo 的51Testing软件测试博客：http://www.51testing.com/?181625
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
3.5 Exchange TiP v2——将TiP迁移到Windows Azure云端
虽然第一个版本的服务毫无疑问地已经为公司带来了收益，并且是度量和改进在线服务的主要工具，但是我们有一个大胆的计划，那就是处理当前服务存在的问题，并使它具有更大的价值。第一个版本中最需要处理的3个问题是：
将执行移到公司网络之外，来处理雷德蒙德地区的代理防火墙问题。
将测试执行的频率增加到5分钟一次或者更少时间。
将覆盖扩展到所有的数据库可用性组（Database Availability Group, DAG）和邮箱数据库。
我们考虑了几种方法来解决上述这些问题，如表3-4所示。
虽然我们还想维持现有测试执行用具的简单易操作性，但很显然的是，没有任何潜在可用的环境能够支持它。同时，与用具相关的所有报告、失效调查和工作流对于复合结果并不是非常有效，这使我们得出了一个结论：必须为测试更换执行夹具（harness）。最后我们决定将TiP基础设施移到具有平台优势的Windows Azure上面的运行。最值得骄傲的是，因为我们设计测试架构的方式，所以移动到另一个平台的时候不需要修改（事实上，我们只需要简单地将测试移到新的夹具，而不需要重新编译）。
表3-4 TiP框架潜在执行环境中的决策矩阵
将TiP框架从测试实验室移到产品中，正是采用了TiP中将测试基础设施从实验室移到数据中心的思想。在这种情况下，我们进驻云端并构建了一个可扩展的、灵活的TiP服务。
图3-5中的框架以插图的形式说明了现在是如何执行产品测试的。通过使用Windows Azure，我们不仅具有了覆盖现有标度单位的能力，还具有了对之前无法预期的新场景进行模拟的功能（比如，在提交给客户之前，即便没有成千上万的用户，仍然可以对数百个用户并发地使用产品进行模拟）。随着时间的推移，这个框架当然会不断演进来满足日益增长的需求。
图3-5 Exchange TiP第二个版本的系统拓扑结构
3.6 我们的心得
TiP测试使我们可以找出数据中心上线过程中引入的问题和有时在产品中客户还没发现的问题。随着时间的推移，还可以让我们找出潜在问题、性能和总体功能表现的非常有趣的发展趋势。
3.6.1 合作方服务相关的问题
对TiP测试至关重要的一个组成部分就是：找出我们所依赖的并在其上进行构建的与合作方服务相关的问题。我们的服务，与几乎所有其他云端服务一样，依赖于许多特定领域相关的不同服务。例如，我们依赖Windows Live ID来提供专门的身份验证层。又如，命名空间管理和提供是依赖于在线域名服务的。在找出上面这些通过别的方面无法捕获的依赖问题方面，我们的测试是非常有帮助的。
3.6.2 云端监视的挑战性
Exchange作为服务很独特的一个方面是它的目标客户是IT专业人员，他们在升级到新的服务时总是非常谨慎，而且很多大客户都定制了一些写在Exchange顶层的产品。此外，有一些客户在混合模式下运行，而另一个客户仅仅只在公司的Exchange Servers中运行，也有一些是在云端运行的。在处理单个云端中版本的一些值得注意的、更持久的变化方面，标准监控解决方案设计得并不是很好。TiP测试在流经系统时，其版本和配置变化使我们能更好地在异构的云端测量和保证质量。这些挑战对于很多云端服务来说是非典型的，如Bing、Facebook、Twitter, 更多的是使用同构的和松耦合的服务架构来获取连续的部署模型。
尽管如此，我们的服务是分层的，且依赖于比Exchange团队更快速的发布周期。网络本身就是随着新的Firmware版本和访问控制列表（Access Control List, ACL）的改变而不断更新的一个层。当那些层发生灾难性的改变时，由监控服务（如Gomez 和Keynote）提供的黑盒方法会向运营中心发出警报，但是对于间歇型或边缘情况却不会发出警报。TiP使我们可以在这些依赖问题变成灾难性问题之前深入分析并捕获它们。在某些情况下，我们甚至可以在合作方服务升级过程中捕获问题，这样就可以提醒他们将这些变更进行回滚。
3.6.3 在线TiP测试所发现的一些问题
以下是通过TiP测试在产品中找到问题的一些样例：
都柏林（爱尔兰共和国的首都）的服务提供的一个队列挂起了，但是监控器并没有检测到。
检测到服务提供的延迟。
TiP检测到了Hotmail运行中断，Exchange团队可以暂停并等待Hotmail的修复。
Live ID运行中断影响了Exchange Cloud的客户；Live ID的运营需要进一步加强。
TellMe, 一个可以将电话在我们的系统和手机交换器（Quest/Verizon负责的地上通信线和T-Mobile的移动电话）之间转换的VoIP网关系统，需要对最终用户连接场景的运行中断进行监控。TiP是找出集成试点测试中所使用的电话号码故障的唯一方法。
也常用TiP测试来鉴定发生随时间不断流逝的间歇失效的根本原因（随着时间流逝出现故障的百分比，而不仅仅只是在单个事故中出现故障）。
3.6.4 聚集处理结果中的“噪声”
我们学到了很多关于对一个实时服务如何执行测试的知识。学到的第一点就是，这种自动化的运行并不简单。例如，因为是在公司防火墙后面运行的，所以只好按照雷德蒙德的代理服务器的路线来发送请求。这些代理服务器并非旨在拥有这种用途，所以导致了有时会出现请求丢失、主机查找失败和其他奇怪的网络故障等。这很快导致了第二种实现方法的出现，即在产品系统中运行自动化测试时，重要的不是个体的通过或者失败的结果，而是随着时间推移，这些结果的聚集体。聚集可以帮助识别一个问题是持久中断问题还是仅仅只是一次网络故障，因此可以将噪声级减少到足够低，这能对服务安全性进行更精确的提高。同时还可以帮助预测未来的发展趋势，而只通过简单地适时看一看统计结果是无法做到这些的。
【小窍门】
对细节过程进行监控是非常重要的，但留意总体趋势也同样重要。
当你注意到测试一个小时运行一次的时候，上述最后一点（关于噪声消减）就变得十分重要。这一频率受到测试执行框架上的内置假设的影响，即关于测试通过之后怎么配置（比如，假设每一个测试运行执行都必须出现在一个新部署的机器上）和关于测试本身是如何执行的。我们发现那些假设因为很多原因存在一些漏洞。
它们一个小时运行一次的另外一个原因是担心消耗太多的生产力。我们发现一个服务必须要留出一些额外的设备来支持实时网站监控、使用过程中的高峰和低谷、拒绝服务攻击和成长。如果以一个增长的频率，比如每5分钟一次，在每个产品簇中运行一个自动化功能测试集合来对服务的边缘进行检测，那么运行的这项服务的时间就太密集了，需要增加设备。但事实上，对许多IT组织来说，采购和安置专用硬件的成本太高，以至于他们觉得准备额外设备留作备用是很不可思议的。然而，随着转移到进行云计算并具有了对电脑和存储资源的动态增长能力，很多组织都能负担得起通过一些合理的额外设备构建一个服务以用于在线测试。
3.6.5 易犯的错误
我们得到的一个教训就是，测试自动化比由外到内的基本监控更完整，并且由于这些测试的质量不错，团队很快就想将TiP系统作为一个加强的监控解决方案。但问题是，我们不可能对频率为1小时的测试进行适时的反应，因为收集足够的样本来分析一个问题是否真的需要花费的太长时间。另一种办法是在测试中实施重试逻辑（retry logic），这样有可能进一步降低通过率并有可能因为瞬态问题而给你提供假阳性的结果（例如，因节流机制而引起发送信息失败）。
我们得到的第二个教训是，当处理横向扩展的产品系统时，如果没有一个类似的自动化测试横向验证策略，就有可能导致一种虚假的安全感。在最初的实施过程中，我们为每一个规模化单元的每个人创建了单个邮箱账户集合，问题是，规模化单元还有进一步的粒度分割，因为它们是由多服务器、可用组织和其他最初未说明的资源组成的。事实上，这意味着每个站点只能覆盖一个可用的组织或者邮箱数据库。这会导致事故不被基础设施所捕获的情形，因为规模化单元受到影响的那部分并不是我们所覆盖的那部分。
除了作为回归测试的金丝雀之外，TiP测试像我们的系统一样，应该将其当作更健壮的持续改进项目（continuous improvement project，CIP）中的一员来对待。与大多数CIP一样，高层管理人员的参与和带动是成功的关键。管理人员与团队的同心协力将保证工程团队获得支持以改善产品服务、弥补TiP和整个监控解决方案中其他元素（单服务器并且由外到内）的空缺。
3.7 总结
在线测试在这个快节奏的在线服务领域中是很有必要的，测试实验室中的自动化测试应该扩展到产品中去，因为没有哪一个服务是封闭的孤岛，持续执行那些贯穿和验证主要端到端（end-to-end）场景的测试用例，这将会增强简单的单服务器（SCOM）或由外而内（Gomez or Keynote）可用性监控。持续回归测试具有类似监视器的作用，可以针对服务运行中断向产品服务团队发出警报，而且该方法对于早期鉴定非用户影响的间歇性bug特别有用。
虽然本案例研究是基于Exchange的，但测试自动化的趋势，尤其是丰富自动化场景，在微软服务团队中发展非常迅速。同时，在产品云端运行这些解决方案的趋势也越来越受到关注。我们期待通过自动化测试来加强监视作用的这类活动会，在整个微软延续下去。
【小窍门】
在云端进行测试可能是你将来工作的一部分，从本章作者的这些经历中学习知识吧！
3.8 致谢
感谢Keith Stobie 和Andy Tischaefer的同行审校，并感谢Karen Johnston对本章进行审稿。
（连载完）
相关链接：
自动化测试最佳实践 连载一
自动化测试最佳实践 连载二
自动化测试最佳实践 连载三
自动化测试最佳实践 连载四
自动化测试最佳实践 连载五
自动化测试最佳实践 连载六
自动化测试最佳实践 连载七
近来，CMM获得了各界越来越多的关注，motorala（中国）过了五级，鼎新过了二级，其他不少企业如华为、浪潮国强、联想、东大阿尔派、天大天财、创智、亚信等一批企业都在进行研究 、试验或者实施预评估。国家发布的关于促进IT业发展的18号文件，以及软件企业资格认证等有关文件中，都鼓励企业实施CMM，珠海开发区规定了通过二级一次性奖励50万元的政策。预计未来2、3年内，国内将出现软件业实施CMM的高潮。但是，根据笔者对于ISO9000标准的实践和对于CMM体系的比较研究，认为，未来在中国企业实施CMM的过程中，存在着如下的障碍：
一、制度化理念与既有企业文化的冲突
体系实施是遇到的诸多问题，包括领导重视程度不够，开发人员、项目经理抵触情绪，质保人员和软件工程人员得不到应有的尊重和权威等等，归根结底是文化冲突。ISO9000和CMM体系都是基于法治的体系，而国人普遍习惯于人治的氛围，大到整个国家小到一个企业莫不如此，这种冲突正是很多问题的根源。
以CMM的组织结构为例，它推荐在最高领导之下设立SEPG（软件工程过程组）、SQA（质量保证组）、SEG（软件工程组），这三个组构成是立法、监督和执法的制衡体系，体现的是西方文化的法治观念。而我们在整体企业管理上推行制度化都困难重重，何况是质量管理。这种冲突体现在两个层面上，一是社会的文化环境与少数企业制度化要求的冲突，二是企业基础管理的不完全制度化和质量管理的制度化特质的冲突。
最近，由于媒体的不断炒作， CMM概念大行其道，软件业似乎找到了新的救命稻草。殊不知，CMM和ISO9000并无本质区别，实施ISO9000遇到的困惑，在CMM中也一定会遇到，他们的基本要求不外乎：
－形成文档化的制度、规范和模板
－严格按照制度办事
－按照要求形成必要的记录
－检查和监督和持续改善
而以上这些正是我们不喜欢的东西，但是抛弃这些，制度化管理还能剩下什么呢？看来，想要花点钱，造个省心的简便的办法是不可能行的通的，不管什么样的体系，都得踏踏实实去做，该面对的困难迟早还是要面对的。
二、ISO9000咨询中的问题对市场的抑制作用
以往企业做ISO9000过程中发生的种种问题，造成了社会上对类似质量管理体系的怀疑态度，也会成为企业实施CMM的障碍。特别是，CMM的实施不是在短时间内可以看到显着成效的，它强调"逐步改进"，而非突变。每升一个级别可能会花费1－2年。这样的情况下，如果企业管理者没有一个坚定的支持态度，很难保证实施不被半途而废。而这样的失败又成了新的打击人们信心的案例，造成恶性循环。
我们常说，"企业实施ISO9000，最高领导的支持是关键"，其实这句话还应改为"企业实施ISO9000，最高领导的亲身参与是关键"更好。因为，每个企业实施ISO9000，肯定都获得了领导的支持，但是当实施过程中碰到一次又一次的抵触和碰撞时，试问，又有多少领导还能保持十足信心？再加上市场上的一些负面言论，体系实施往往从这时候开始被一步步遗忘掉。。。所以，领导不仅是支持，应该有高层领导亲身参与，不是表面上的，而是抱着一个坚定的信心，执着的投入到里面去。对于为此会付出多少辛苦、时间精力、资源都应该有充分的心里准备。把推行质量管理当作企业推行全面制度化的一个手段和阶梯。
高层领导亲身参与的头一个好处是，由于不断地研究，他会成为此中专家，所以能够保持其自信，而不被市场和现实的噪音所影响；第二个好处是可以有效的触动原体制下的深层次缺陷，有些潜在问题是质量管理经理推不动或或没有能力看到的。
从整个企业的层面来看，通过实施质量体系，事实上改造了原有企业文化，使制度化的观念深入人心，为企业引入西方先进的管理思想、推行全面的制度化管理奠定了思想和文化基础。
三、企业人员的质量和质量管理意识有待提高
任何体系的实施都离不开其主体－人。企业实施质量体系过程中各层次人员进行不同的定向培训。对于开发人员来说加强软件工程的培训和实践应从学校教育就开始，进入企业后再进行有针对性的再教育。有些规模比较大的国外企业入职再教育的时间可能长达1－2个月。国内企业却常常抱怨没有时间和不愿意为此投入资金，造成体系的贯彻没有基础。
不仅是对于开发人员，对于项目管理人员的管理培训，对体系的实施起着至关重要的作用。因为项目管理人员处在承上启下的关键位置，体系的落实、组内配置管理、组内质量数据的收集等都离不开这一层管理人员的配合。而实际情况是，项目管理人员往往都是从技术出身，管理意识不足是普遍存在地问题。这层管理人员进行强化的质量意识培训和项目管理培训是非常迫切的。如果通过培训能使大家明白怎样做一个合？quot；科研管理人员"，真正增强其管理的意识，会发现项目经理会主动配合质量管理工作，因为他们认识到，质量管理其实是项目管理职能中非常重要的部分。
四、顾问公司水平和服务亟待改善
ISO9000和CMM都只提要求，没有告诉怎么做，具体的实施和应用需要由顾问公司协同企业来做。当前，顾问公司所提供的服务是浅层次咨询，只是把标准的知识引进来，怎么使用基本是企业来琢磨，最后顾问公司再验证要素的覆盖程度。顾问公司不对体系的效率负责，只管要素覆盖，是因为要素覆盖是与拿证书相关的。强调在原模式的基础上建立ISO9000体系，而不能进行流程重组。这其实反映了顾问公司的非专业化，只对质量管理熟悉，对其它管理不了解，对细分的行业特征不了解。这个观念我觉得要转变，一个好的顾问公司应该协同顾客研究其流程，提出重组的建议，流程的建立不仅要考虑要素覆盖还要兼顾流程效率。实施参与深度不够是一方面，参与时间也偏短，我们一般一个咨询周期6－8月，而国外1－2年的周期是很多的。6个月的时间往往只是体系的初步建立，还很粗糙，要运行和完善为一个比较可行的的体系，还需要大量的时间，这个过程仍然不能没有咨询公司的参与和指导。
以上所列问题，是企业实施CMM时应该有心里准备并准备付出努力的方面，也是各企业管理人员、顾问公司应该着力研究的方面，我相信，只有这些问题能够很好的解决，CMM的实施才会真正获得成功，企业告别作坊式管理的愿望才能真正实现。