未来很长。
全部博文（148）
分类： WINDOWS
2017-08-08 10:28:10
确切地讲，所谓的需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。
2. 为什么要做测试需求分析
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
3. 测试需求的依据与收集
测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软件的主要内容。
测试需求主要通过以下途径来收集：
1） 与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、技术文档等。
2） 与客户或系统分析员的沟通。
3） 业务背景资料。如待测软件业务领域的知识等。
4） 正式与非正式的培训。
5） 其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。
4. 测试需求的分析
目前不少的书籍与网站资料开始重视测试需求的分析，同时也提出了一些测试需求分析的方法。这里也提出一些自己的看法。
测试需求需要考虑几个层面的因素：
第一层：测试阶段。阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试，不过也是见仁见智的做法，要看测试管理者对测试策略与风险的平衡能力了。
目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。此种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。
第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。
第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出 的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，那些已经是很好的测试需求参考了，在此仅列出业务流的测试分析方法。
任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：
1） 常用的或规定的业务流程
2） 各业务流程分支的遍历
3） 明确规定不可使用的业务流程
4） 没有明确规定但是应该不可以执行的业务流程
5） 其他异常或不符合规定的操作
然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该导致的结果，便形成了软件业务流的基本测试需求。
在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。
5. 测试需求的优先级
优先级别的确定，利于测试工作有的放矢的展开，使测试人员清晰了解核心的功能、特性与流程有哪些，客户最为关注的是什么，由此可确定测试的工作重点在何处，更方便处理测试进度发生问题时，实现不同优先级别的功能、模块、系统等迭代递交或取舍，从而缓和测试风险。
通常，规范的客户，会规定用户需求/软件需求的优先级别，测试需求的优先级可根据其直接定义。如果没有规定项目需求的优先级，则可与客户沟通，确定哪些功能或特性是需要尤其关注的，从而确定测试需求的优先级。
6. 测试需求的覆盖率与覆盖程度
测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经跟测试需求存在了一对一或一对多的对应关系，可以说测试需求已经覆盖了该功能点，以此类推，如果确定了所有的软件需求都建立了对应的测试需求，那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%，但并不意味着测试需求的覆盖程度高。因为测试需求的覆盖率只计算了显性的（即被明确规定的功能与特性）因素，而隐性的（即没有被明确规定但是有可能或不应该拥有的功能与特性）因素并未计算在内。因此根据不断的完善或实际测试中发生的缺陷，可以对测试需求进行补充或优化，并更新进测试用例中，以此来提高测试需求的覆盖程度。
在确定了测试需求、明确了测试范围之后，就需要明确测试任务，估算测试工作量。基于质量需求和测试的工作量、测试环境、产品发布的设想时间等要求，就可以确定测试进度和所需的测试资源，或者基于现有的测试资源来决定测试的日程表。
在传统开发模式中，测试工作量估算是测试计划的基础工作之一，但在开发中，虽然也强烈建议有一个测试计划，但其测试计划简明扼要，主要是列出测试目标、测试边界、测试点、主要的测试风险和注意事项等。其测试任务在迭代计划（如Scrum的SprintPlanning）会议中和开发任务一并考虑，可以采用Scrum估算扑克牌的方式来完成估算，这样测试工作量估算主要依赖个人经验、团队沟通等完成。即使是采用这种方式，对下面内容了解之后，有一个科学估算的基础，在敏捷开发中依旧会发挥作用。
测试的工作量是根据测试范围、测试任务和开发阶段来确定的。测试范围和测试任务是测试工作量估算的主要依据。如何确定测试范围已在上一节做了充分的讨论，可以根据产品需求规格说明来决定。测试任务是由质量需求、测试目标来决定的，质量要求越高，越要进行更深、更充分的测试，回归测试的次数和频率也要加大，自然，测试的工作量要增大。处在不同的开发阶段，测试工作量的差异也挺大。新产品第一个版本的开发过程，相对于以后的版本来说，测试的工作量要大一些。但也不是绝对的，例如，第一个版本的功能较少，在第2、3个版本中，增加了较多的新功能，虽然新加的功能没有第一个版本的功能多，但是在第2、3个版本的测试中，不仅要完成新功能的测试，还要完成第一个版本的功能回归测试，以确保原有的功能正常。
在一般情况下，一个项目要进行2～3次回归测试。所以，假定一轮（Round）功能测试需要100个人日（man-day），则完成一个项目所有的功能测试肯定就不止100个人日，往往需要200～300多个人日。可以采用以下公式计算：
W ＝ Wo+ Wo? R1 + Wo ? R2 + Wo? R3
? W为总工作量，Wo为一轮测试的工作量。
? R1，R2，R3为每轮的递减系数。受不同的代码质量、开发流程和测试周期等影响，R1、R2、R3的值是不同的。对于每一个公司来说，可以通过历史积累的数据获得经验值。
测试的工作量，还受自动化测试程度、编程质量、开发模式等多种因素影响。在这些影响的因素中，编程质量是主要的。编程质量越低，测试的重复次数（回归测试）就越多。回归测试的范围，在这3次中可能各不相同，这取决于测试结果，即测试缺陷的分布情况。缺陷多且分布很广的话，所有的测试用例都要被再执行一遍。缺陷少且分布比较集中，可以选择部分或少数的测试用例作为回归测试所要执行的范围。
在代码质量相对较低的情况下，假定R1、R2、R3的值分别为80%、60%、40%，若一轮功能测试的工作量是100个人日，则总的测试工作量为280个人日。如果代码质量高，一般只需要进行两轮的回归测试，R1、R2值也降为60%、30%，则总的测试工作量为190个人日，工作量减少了32%以上。
自动化程度越高，测试工作量就越低。由计算机运行的自动化脚本效率很高，能使执行实际测试的工作量大大降低。但是在很多情况下，测试自动化并不能大幅度降低工作量，因为测试脚本开发的工作量很大。也就是说，将总体的测试工作量前移了，从测试执行阶段移到测试脚本设计和开发的阶段，总体工作量没有明显降低。同时，由于自动化脚本可以重复使用，而且机器可以没日没夜地运行，回归测试就可以频繁进行，如每天可以执行一次，这样任何回归缺陷都可以即时发现，提高软件产品的质量。
工作量的估计是比较复杂的，针对不同的应用领域、程序设计技术、编程语言等，其估算方法是不同的。其估算可能要基于一些假定或定义。
（1）效率假设，即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度、窗口的个数、每个窗口中的动作数目。对于容量测试，主要依赖于建立测试所需数据的工作量大小。
（2）测试假设，目的是验证一个测试需求所需测试的动作数目，包括估计的每个测试用例所用的时间。
（3）阶段假定，指所处测试周期不同阶段（测试设计、脚本开发、测试执行等）的划分，包括时间的长短。
（4）复杂度假定，应用的复杂度指标和需求变化的影响程度决定了测试需求的维数。测试需求的维数越多，工作量就越大。
（5）风险假定。一般考虑各种因素影响下所存在的风险，将这些风险带来的工作量设定为估算工作量之外的10%～20%。
要做好测试工作量的估算，需要对测试任务进行细化，对每项测试任务进行分解，然后根据分解后的子任务进行估算。通常来说，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮动幅度，来确定实际所需的测试工作量。比较专业的方法是工作分解结构表（WBS），它按以下3个步骤来完成。
（1）列出本项目需要完成的各项任务，如测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。
（2）对每个任务进一步细分，可进行多层次的细分，直到不能细分为止。如针对测试计划，首先可细分为：
? 确定测试目标；
? 确定测试范围；
? 确定测试资源和进度；
? 测试计划写作；
? 测试计划评审。
“确定测试范围”还可再细分为功能性测试范围和非功能性测试范围的分析。“测试计划评审”可以再分为测试组内评审、项目组评审、公司质量保证小组评审和最终批准。
（3）列出需要完成的所有任务之后，根据任务的层次给任务进行编号，就形成了完整的工作分解结构表（如表2-5所示）。
WBS除了用表格的方式表达之外，还可以采用结构图的方式，那样会更直观、方便，如图2-5所示。
当WBS完成之后，就拥有了制定日程安排、资源分配和预算编制的基础信息，这样不仅可获得总体的测试工作量，还包括各个阶段或各个任务的工作量，有利于资源分配和日程安排。所以，WBS方法不仅适合工作量的估算，还适合日程安排、资源分配等计划工作。
结合Google日历的功能点可以看出，测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各阶段的时间安排。根据Google日历的功能计算，测试用例数为6×60 =360例（以平均每个大模块60个用例来算）。除了测试用例数，还要考虑以下因素。
? 根据测试团队和项目的具体情况来算，如2.3.3节中的几个假定：效率假设、测试假设和应用的维数等。
? 测试平台、环境的不同组合，包括、浏览器、通信协议、防火墙、代理服务器等的组合。
? 回归测试频率和重复次数。
? 自动化测试的水平。
? 其他特定的因素，增加10%～20%的余量。
在Google日历的测试中，做如下假定和分析。
? 所有人员为中级工程师的水平。
? 每个测试用例设计时间为20分钟，包括评审、输入到用例管理中等所用的时间。所以测试用例设计的时间为120小时，即15个人日。
? 70%的测试用例可以进行自动化测试，30%为手工测试。即自动化测试用例数为252例，手工测试用例数为108例。
? 每位工程师每天可开发10个测试用例的测试脚本，包括调试。所以测试脚本开发的工作量为26个人日。
? 要进行两次的回归测试，R1、R2值为70%、40%，则单平台下手工运行的测试用例数为108×(1＋70%＋40%)＝ 227例。
? 对操作系统没有影响，而且不考虑SSL的支持，只考虑浏览器IE6.0、IE7.0、Firefox1.5、Firefox2.0和代理服务器的影响。作为交叉组合，共设为4种。
? 也没有必要在4种组合上运行所有的测试用例，两种主要组合运行100%的手工测试用例，另外两种组合运行50%的手工测试用例，即测试用例数为原来的3倍，所以手工运行的测试用例数为227× 3 ＝ 681例。
? 假定每个测试工程师每天可以运行60个测试用例，即每个测试用例的执行要用5分钟，运行测试用例要用5个小时，另外3个小时用于处理缺陷报告和邮件、与开发人员沟通等。所以手工测试用例执行的时间为12个人日。
? 自动化测试的运行都在晚上进行，工程师需要时间分析测试结果、修改脚本适应新的变化、做缺陷报告等，估计要5个人日。
这样就估算出了功能测试的基本工作量，即15＋26+12+5=58个人日。
对系统测试的工作量，可以按照同样的方法进行，所不同的是系统测试几乎是由测试工具完成的，工作量主要集中在环境构建、测试数据准备和结果分析等上面。表2-6给出了Google日历所要的测试工作量。
分析测试范围之后，所需要的测试资源就比较清楚了。测试的资源需求，包括人力资源和软、硬件资源。人力资源，侧重如何组建测试团队——项目测试组，而软、硬件资源，对于不同的项目差异很大。这里只讨论一般的操作方法，设计测试环境的建立，将在第7、第9章进行详细介绍。
如果将测试资源进行较为详细的分类，可以归纳为如图2-6所示。
1．人力资源需求
在完成了测试工作量的估算之后，软件测试项目所需的人员数目就能够基本确定了。软件测试项目所需的人员和要求在各个阶段是不同的。
（1）在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。
（2）在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。
（3）在测试中期，主要是测试的执行，测试需求的数量取决于测试自动化实现的程度。如果测试自动化程度高，人力的投入则不需要明显的增加；如果测试自动化程度低，对执行测试的人员要求就比较多了。
（4）在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。
2．测试环境资源
把建立所有必要的测试环境所需的计算机软件资源和硬件资源合称为测试环境资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源包括操作系统、第三方软件产品、测试工具软件等，具体如下。
? 硬件：交换机、路由器、负载均衡器（Load balance）、服务器、客户端PC、摄像头、特殊的显示卡和声卡、耳机、麦克风等。
? 支撑的系统软件：操作系统、Web服务器（如Apache）、中间件（如Tomcat、WebLogic）、数据库系统软件/等。
? 测试工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。
软件测试贯穿软件产品开发的整个生命周期，从产品的需求分析审查到最后的验收测试，直至软件发布。从测试实际的前后过程来看，软件测试的过程是由一系列不同的测试阶段组成的，这些阶段主要有：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。在软件测试项目的计划书中，需要给各个阶段制定一个明确的开始和结束时间，这就是通常所说的日程进度表（schedule）。项目进度安排，实际上取决于测试工作量和现有的人力资源。当人力资源充足时，测试周期短；当人力资源较少时，测试周期就会长。
里程碑一般是项目中完成阶段性工作的标志，即用一个结论性的标志来描述一个过程性任务明确的起止点，进度安排就是确定里程碑的起止点。一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。里程碑具有很强的时序性，还具有下列特征。
? 里程碑也是有层次的，在一个父里程碑的下一个层次中定义子里程碑。
? 不同类型的项目，里程碑可能不同。
? 不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
在软件测试周期中，建议定义下列6个父里程碑。
（1）M1：需求分析和设计的审查。
（2）M2：测试计划和设计。
（3）M3：代码（包括单元测试）完成。
（4）M4：测试执行。
（5）M5：代码冻结。
（6）M6：测试结束。
每个里程碑再划分为子里程碑，如果项目周期很长，还可以对每个子里程碑进一步划分为更小的里程碑，以利于更有效的控制，如表2-7所示。
在本书一开始的引言中，以Scrum为例，简要阐述了敏捷测试流程。而在敏捷测试项目中，如何明确测试的里程碑呢？万变不离其宗，敏捷测试也需要从测试计划到测试设计、再到执行，只是测试设计和执行的界限不那么分明，测试设计和执行往往交替或并列地开展。在敏捷测试中，甚至可以不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发相对稳定功能的自动化测试脚本，为后期的回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合上述考虑，敏捷测试的实际操作流程如图2-7所示，简单有效。
在这样的流程中，大框架也没有什么不同，而且各项测试件（测试计划、需求、自动化脚本等）的评审还是需要的，只是没有明确的评审阶段，测试是一个持续的质量反馈过程，阶段性不那么突出，但还是可以设定一些控制点，即里程碑：
（1）测试任务定义；
（2）测试计划制定和评审通过；
（3）测试需求或测试点（或测试场景）列表明确和评审通过；
（4）验收测试结束。
