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）方法。在分析错综复杂的问题，如系统级别的结构问题或性能问题时，这两种方法能够有效地定位问题。
自顶向下方法，其着眼处在于整体。使用自顶向下方法，首先应该认同的一个观点是，系统整体的问题可能是系统某个部分的原因引起的，而这个局部的问题放大后会在系统的宏观级别上表现出来。通过观察和分析存在缺陷的系统整体情况，把系统分成若干部分，并逐个部分判断可能存在的问题。判断确定“嫌疑”所在后，使用调整--测试的方法证实判断的正确性。如果判断正确，宏观的问题确实存在于系统中，那么可以对这个细节进行修改，解决问题；如果判断不正确，则需要重现判断。从宏观到微观的过程也可能不是一步到位的，在复杂的系统中，这个过程可能会分为多个级别的细化来完成。有时候，整体的问题可能是由多个划分同时存在的问题引起的。通过逐个验证测试系统划分的“地毯式排查”方式，可以扫清所有“患处”。
一个系统的局部分解方式通常是稳定的，使用自顶向下方法的理念在于通过这种稳定的分解，使用穷举方式最终可以确切地找到发生问题的局部。其好处是对于经验不多的人员，使用自顶向下法也能最终找到问题所在。当然，缺乏经验也可能带来苦头--对某些局部的验证也许是不需要的。
相对而言，自底向上方法对分析者的能力要求较高。使用自底向上方法的前提是，承认缺陷的全部或部分是由于系统局部细节的问题引起的。分析时，根据系统表面看到的蛛丝马迹，直接判断出现问题的根源，并验证这个判断是否正确。实践上，可以从最底一层起，对系统在逻辑上或功能上进行划分，然后设计特定的测试场景，有针对性地验证这些划分是否正常。因为对系统进行过划分，所以一旦验证性的测试重现了问题，则能够比较清晰地定位究竟是哪个部分存在问题。
这个从下往上的判断过程当然是很有讲究的，遭遇问题的经验、对问题的“嗅觉”，都有助于提高判断的准确性。复杂的系统中可能有问题的细节成千上万，作为分析人员，首先应该对系统的这些细节及其在整体中的作用比较熟悉，其次要拥有直达问题根源的“直觉”。如果缺少这种一击即中要害的技能，自底向上的问题分析方法可能并不奏效。
值得注意的是，无论是自顶向下还是自底向上的问题分析方法，其本质其实都是准确地重现和定位问题。只要问题得以有效重现和定位，离找到解决的办法就不遥远了。
自顶向下和自底向上方法可通用于一般各种测试类型，针对不同测试类型，这两种方法的具体使用方式可能存在不同之处。
发现、定位和解决问题的方法，是测试人员的核心技能。由于测试的门类众多，针对系统的测试也有多种角度，这些方法在不同的测试中会有不同的具体表现。
经过与凯文的谈话，小艾觉得自己对测试本身及其重要性、测试的技巧和窍门等方面的理解都加深不少。许多要点其实小艾在日常工作中已经有所接触，只是缺少系统的总结和提炼，而其他一些能力，则需要通过更多积累才能达到。凯文提醒道：“作为测试专家，核心的能力其实还是思考的能力。五花八门的测试方法和技术，得通过自己的实践、总结和思考，转化成系统的测试方法论。当一套属于你自己的测试方法论已经形成的时候，意味着你已经从专家成长为高手了。测试，在这种角度看，就是一个完备的哲学体系。”
（未完待续）
相关链接：
一个软件测试工程师的成长日记（连载一）