要想解决这个问题，最终取决于这整个团队的管理者及整个团队工作的氛围。

　　曾记得在某一本书上看到这么一个观点：要想看一个公司管理者的能力、整个团队的管理水平及氛围；可以从问题角度去观察。

　　当出现问题时，整个团队是互相推卸，还是积极反馈、查找原因和解决办法；整个团队是否愿意去发现和寻找工作中的问题，能否有正确的方法去面对问题；这就要求管理者在组建和管理一个团队时，对团队成员的要求；工作流程很重要，执行工作流程的人更重要。

　　没有做过测试工作的人，会不知道测试工作过程中的困难和难度；没有做过开发工作的人，会不知道开发工作过程中的困难和难度；没有做过管理工作的人，会不知道管理工作过程中的困难和难度；前不久有位同事说过：有些东西你没有做过就你没有发言权。

　　当某些工作需要大家配合去完成时，只有足够的尊重（学会换位思考、学会沟通）、责任心才会让事情做起来比较顺利。

　　上面这些牵扯出另一个问题：工作技能，应该说是综合技能。

　　做技术的，大家都知道，牛人通常不会推卸责任；牛人知道自己会哪些，不会哪些，不会瞎指挥；牛人会根据实际情况结合自身的经验给予对方建议和帮助，而不是刁难和嘲笑；牛人会用你能接受的方式让你知道自己在哪个地方出问题了。

　　关于现象3中的自动化测试工具的局限性，如何让开发明白，我给的建议如下：

　　1）让一部分开发人员来干干测试的工作，让他做过后，就会明白了；这个方法耗费的成本代价较大，属于内耗。

　　2）如果公司还有其它团队，让其它团队测试工作有影响力的人给开发团队管理者进行引导。

　　3）收集数据，准备材料，用足够的数据（自动化测试提升了XXXX测试执行工作效率；自动化发现的bug数据；手工测试发现的bug数据XXXX等等）来说服对方，当然在说服的过程中，要得到更上一层管理者的支持和理解。

　　上面3点是治标不治本，最终还是要把工作流程整理顺畅，要有个合适的人在合适的位置上选择一堆合适的人，然后带这堆合适的人一起做事。

　　在我测试工作的7个年头里，经过在不同公司和不同团队配合做事后，让我感触最深的是：测试工作要做好很不容易。

　　同行在来信中提到的问题现象是：

　　问题现象1：测试完成后，出现需求变更（如：增加、修改、删除），此时的测试该如何做（如：测试执行该如何做、测试文档该如何写）？

　　问题现象2：开发人员和用户直接交互，出现需求变更，开发修改后没有经过QA测试，直接提交用户，导致用户发现很多bug，因此开发人员说测试组发现不了bug，要求引入自动化测试工具。

　　问题现象3：开发人员理解的自动化测试工具，就是能够自动发现Bug，并且能发现所有Bug的工具，让测试人员引入这类的自动化测试工具；如何让他们开发人员明白自动化测试工具的局限性，似乎不是一个简单的问题。

　　站在测试管理角度看上面的问题现象，我总结为三点问题：测试工作流程、测试工作技能、团队协作沟通，现在一一对这些现象进行分析和探讨。

　　现象1和现象2都遇到了需求变更。

　　由于缺少需求变更处理流程，问题1的测试人员不知道该怎么办；问题2的测试人员很冤枉的背负漏出去的bug，被开发强求引入自动化测试工具。

　　老中医的一个观点我很认同：最终目标是要治本而不是治标；公司一位大牛的一句话我很认同：要用科学的态度看问题。

　　当需求发生变更后，测试该怎么办？我给的建议是：

　　1）需求变更，不光牵扯到的是测试、里面还有开发和后期负责维护的相关部门；需求变更时，需求负责部门（或产品部门）、开发部门、测试部门、技术支持维护部门之间要对这个情况进行沟通协调，通过一个合适的工作流程让团队之间的工作效率和质量能有效的得到保障和提升。

　　2）需求变更出现时，我认为测试能做的、应该做好的是：

　　a）测试管理者对待需求变更等同于测试一个版本的流程一样，需要进行版本控制和资源协调；也要相应的对变更需求做分析（如：需求变更的影响范围、紧急程度、资源能否相应、工期的影响和风险），制定相应计划、评审相应测试用例；

　　b）测试人员需要根据变更的需求以及开发设计文档，编写用例、执行测试、测试日报……等等执行相应的测试工作流程。

　　有的人会说，但现实情况是，有的团队就没有这么个变更处理流程、有的团队有了这个流程会要求特殊情况给予特殊处理，测试能怎么办？

　　1）没有变更处理流程的，需要各个相关部门的管理者给予重视并商讨建立一个合适的，大家好才能是真的好！

　　2）有了流程，需要考虑特殊情况特殊处理：

　　a）例如：时间紧任务重，可否跳过QA？可以跳过QA，但QA不承担这种情况出现的质量问题，由决策者来承担。

　　b）例如：时间紧任务重，QA资源紧，但必须要QA测试，测试管理者要让相关兄弟部门老大知道，在这样的情况下，QA能保障的也是必须要保障的是主要业务和功能的测试，其它的无法保障，同时要让相关兄弟部门做好这个任务的风险评估及应对配合工作。

　　c）在特殊情况下的测试任务，测试有权力说出自己当前的版本质量情况及是否上线的建议。

　　现象2和现象3都遇到了团队协作沟通的问题。

　　这是测试工作中最难、也是最累的；有过测试工作经验的人都有体会，测试和开发配合的好坏直接影响工作的进度、质量和团队发展。

　　要想解决这个问题，最终取决于这整个团队的管理者及整个团队工作的氛围。

　　回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁。

　　回归测试包的选择：软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，不得不选择一个缩减的回归测试包来完成回归测试。

　　选择回归测试策略应该兼顾效率和有效性两个方面。

　　(1)、基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。

　　(2)、基于操作剖面选择测试 。如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。

　　(3)、再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

　　任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：

　　1）  常用的或规定的业务流程

　　2）  各业务流程分支的遍历

　　3）  明确规定不可使用的业务流程

　　4）  没有明确规定但是应该不可以执行的业务流程

　　5）  其他异常或不符合规定的操作

　　然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该导致的结果，便形成了软件业务流的基本测试需求。

　　在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流

　　程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。

　　5. 测试需求的优先级

　　优先级别的确定，利于测试工作有的放矢的展开，使测试人员清晰了解核心的功能、特性与流程有哪些，客户最为关注的是什么，由此可确定测试的工作重点在何处，更方便处理测试进度发生问题时，实现不同优先级别的功能、模块、系统等迭代递交或取舍，从而缓和测试风险。

　　通常，需求管理规范的客户，会规定用户需求/软件需求的优先级别，测试需求的优先级可根据其直接定义。如果没有规定项目需求的优先级，则可与客户沟通，确定哪些功能或特性是需要尤其关注的，从而确定测试需求的优先级。

　　6. 测试需求的覆盖率与覆盖程度

　　测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经跟测试需求存在了一对一或一对多的对应关系，可以说测试需求已经覆盖了该功能点，以此类推，如果确定了所有的软件需求都建立了对应的测试需求，那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%，但并不意味着测试需求的覆盖程度高。因为测试需求的覆盖率只计算了显性的（即被明确规定的功能与特性）因素，而隐性的（即没有被明确规定但是有可能或不应该拥有的功能与特性）因素并未计算在内。因此根据不断的完善或实际测试中发生的缺陷，可以对测试需求进行补充或优化，并更新进测试用例中，以此来提高测试需求的覆盖程度。

　　1. 什么是测试需求？

　　确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。

　　就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。

　　2. 为什么要做测试需求分析

　　如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。

　　测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

　　如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。

　　3. 测试需求的依据与收集

　　测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软件的主要工作内容。

　　测试需求主要通过以下途径来收集：

　　1）  与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。

　　2）  与客户或系统分析员的沟通。

　　3）  业务背景资料。如待测软件业务领域的知识等。

　　4）  正式与非正式的培训。

　　5）  其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

　　在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。

　　4. 测试需求的分析

　　目前不少的书籍与网站资料开始重视测试需求的分析，同时也提出了一些测试需求分析的方法。这里也提出一些自己的看法。

　　测试需求需要考虑几个层面的因素：

　　第一层：测试阶段。系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试，不过也是见仁见智的做法，要看测试管理者对测试策略与风险的平衡能力了。

　　目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。此种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。

　　第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。

　　第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出 的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，那些已经是很好的测试需求参考了，在此仅列出业务流的测试分析方法。