|
在项目启动之后，就要着手软件项目的计划，包括软件测试计划。软件测试计划是整个开发计划的组成部分，同时，它又依赖于软件组织过程、项目的总体计划、质量文化和方针。在测试计划活动中，首先要确认测试目标、范围和需求，其中“测试需求分析”是关键任务，然后在测试需求基础上制定测试策略，并对测试任务、时间、资源、成本和风险等进行估算或评估。
无论何时进行估算，我们都是在预测未来，并会接受某种程度的不确定性。软件项目计划的目标是提供一个框架，不断收集信息，对不确定性进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得项目测试负责人能够对资源、成本及进度进行越来越合理、准确的估算。这些估算是软件项目开始时在一个限定的时间框架内做出的，并且随着项目的进展而不断更新。所以，测试计划强调的是一个过程，计划（Planning）的过程，而不仅仅是为了一个文档——“测试计划书”（Test
Plan）。
测试计划活动过程伴随着需求文档的审查，而需求文档的评审反过来也有利于测试计划的制定。而且，测试计划必须建立在软件需求定义之上，为软件的质量需求验证和确认活动的开展进行规划和指导。
2.1 软件测试的目标和基本需求
在分析测试需求之前，先要确定测试目标，而测试目标的确定，取决于质量要求。虽然在理论上，对软件质量的要求是比较明确的，但对不同的软件开发项目，其质量要求是不一样的。根据特定的质量要求，确定测试目标。然后再根据测试目标，来分析测试需求。
2.1.1 质量要求
关于什么是软件质量，本书在第1.1.1节进行了详细讨论，包括软件产品的质量属性，如功能性、易用性、性能、安全性、兼容性、可用性、可维护性、扩展性等。但是，仅仅根据这些质量属性不够，还要参考业务领域专业知识、行业标准、地方标准或其他规范等，才能明确特定产品的质量要求。只有明确质量要求，才能明确测试目标。让我们先讨论特定软件产品的质量要求。
对质量的具体要求，可以参考国际标准ISO/IEC 25030的相关描述，质量不仅局限于最终用户的需求（通常指外部质量要求、软件使用质量），还要考虑产品或项目的干系人（Stakeholders）的质量要求，包括组织的管理层、系统运维等，对软件内部质量也有具体要求，包括软件的可维护性、可扩充性等。从质量来看，用户的需求会显得更重要，我们会在使用质量（Quality
in Use）上有更多的关注，使用质量的具体要求见图2-1。
手机也是大家熟悉的产品，不同的用户群对一部智能手机的要求也是不同的，如低档手机和高档手机有着不同的质量要求、老年人和年轻人对手机也有不同的期望，商务人士对手机也有一些特定的需求（如Blackberry的实实在在的全键盘）。低档手机的质量要求如下。
通话正常、稳定。
通话质量要有一定保障。
待机时间长。
安全，电池不能发生爆炸。
外观大气美观，不要太重。
通讯录、短信、闹钟等功能使用方便。
支持手写输入功能。
但对智能手机，对手感、用户体验、性能、外观质感等有更高的要求。虽然不同的产品类型、不同的应用领域，功能的质量要求是有差异的，但一般来说，通用的功能质量要求如下。
程序安装、启动正常，有相应的提示框、错误提示等。
每项功能符合实际要求。
每一项功能能正常运行、输出结果正确。
能处理各种不正常的操作，对异常数据的输入可以进行提示、容错处理等。
系统的界面清晰、美观。
菜单、按钮操作正常、灵活，能处理一些异常操作。
能接受正确的数据输入，如测试最大输入的文字数、单双字节、特殊符号等。
数据的输出结果准确，格式清晰，可以保存和读取。
功能逻辑清楚，符合使用者习惯。
系统的各种状态按照业务流程而变化，并保持稳定。
支持各种应用的环境。
能配合多种硬件周边设备。
软件升级后，能继续支持旧版本的数据。
与外部应用系统的接口有效。
用户界面（User Interface，UI）是和用户进行交互的窗口。仅从这一点，就可以清楚地知道用户界面友好程度的重要性。用户界面是否友好直接影响用户对软件产品或软件服务的满意度，即我们经常提到的用户体验，用户界面设计就是给用户一个良好的体验，不仅使用软件简单、方便和明了，而且心情舒畅、愉悦。对于Web应用，更强调网页内容和文字表述，但这些往往是开发人员容易忽视的地方。对于开发人员来说，注意力常常集中在功能的实现上。文字不仅误导用户的操作或影响用户的体验，而且有时可能会引起法律方面的问题。测试人员应确保内容表达符合习惯，更专业、流畅，有时需要招聘1～2个语言学（文学、中文、英文、日文等）专业的人员参加测试队伍。在UI上，主要的质量要求如下。
通用框架、浮动窗口和文字等整体上布局合理、位置恰当。
文字没有乱码、换行正常，而且内容格式、顺序正确。
文字标记和超链接可以打开和跳转成功。
色彩搭配要协调，要形成对比强烈的色彩效果，也要恰到好处。
以前面Google Talk作为例子，其产品的质量要求一定会包括功能正确、性能好、易用，但这样的质量要求还不够明确，对设定测试目标帮助不大，还需要进一步分析其质量要求。对于功能，可以逐条列出其主要功能，然后分析功能在质量上有没有一些特定的要求。例如：
（1）支持语音、视频通话，就要确定语音、视频通话的质量要求，是否支持电信级业务服务水平即严格的QoS标准（服务质量）？支持高清视频（如720p、1080p等）通话吗？视频通话质量能够根据网络状况可调整吗？语音在延迟、回声、噪音、颤音等上面有具体的质量要求吗？视频通话对带宽最低限制是多少？
（2）是否支持基于行业标准的会话发起协议（SIP）？
（3）单击姓名打开聊天窗口，可同时打开任意多个聊天窗口。可能就会问，最多能打开多少个窗口？有没有性能问题？
（4）邮件、通讯录等涉及个人隐私，在安全性上有什么要求？
（5）口令设置有哪些参数约束？这些约束能否保证其较高的安全性？
（6）好友列表有没有限制（容量问题）？
（7）不同颜色的小球图标及不同的符号表示好友的在线状态，多少时间（如几十、几百毫秒，几秒）刷新一次？
（8）正常连接情况下，添加好友的时间是多少？
对应Google日历，可能就简单些，其质量要求和一般Web应用软件的质量要求基本一致，主要体现在功能、性能、安全性、易用性等主要方面的同时，可能还会有下列的质量要求。
（1）功能：计算正确、显示正常、逻辑合理等。
（2）性能：正常时每个页面刷新显示时间不超过3秒，高峰时不超过10秒。
（3）安全性：登录安全，被邀请人只能看到当前事件，不能查看他人的其他事件等。
（4）易用性：日历能在不同显示方式之间方便、快捷切换，显示内容也能根据不同方式改变、能支持“直接拖拽”操作日历等。
为了进一步理解产品质量要求，可以看看大家熟悉的拼音输入法有什么具体的质量要求。《Windows软件测试探秘》一书第6章就给出很好的实例，如表2-1所示。
2.1.2 测试目标
软件测试的目标就是根据质量要求，逐项确定、验证软件的实际表现，提供软件产品完整的质量信息；同时，为了帮助团队向客户提供一个高质量的软件产品，软件测试的目标就是更早地、尽可能地将软件产品或软件系统中所存在的各种问题找出来，并促进各类开发人员尽快地解决问题。衡量测试目标的实现，就是通过测试覆盖率来衡量，通过对测试结果的分析，来明确产品质量要求、功能点或代码行（分支、条件等）的测试覆盖率。例如：
1.需求项和功能点覆盖率100%；
2.代码行覆盖率95%。
但针对具体项目或具体产品的测试目标，不仅根据产品质量要求进一步明确测试目标，还要根据项目背景环境（如进度、预算等）、测试团队能力和现有的技术来确定测试目标。例如，预算和进度限制测试的充分性，包括是否有足够的时间和资源去做兼容性测试、性能测试、安全性测试和可靠性测试等。即使对某项特定的测试，能够测试到什么深度和广度，都需要因地制宜地考量。因为从理论上讲，希望该有的测试都做了，每项测试都能做到100%，但实际项目中，进度、资源、能力等都有限制，不可能达到理想的目标，也没必要。例如单元测试，理想的目标是百分之百覆盖代码行、分支和条件，但在实际项目中，可能将单元测试的目标定为代码行的覆盖率50%、60%或80%。
再举一个例子。国际标准IEC 61508把系统安全完整性分为0、1、2、3.和4等5个级别，而作为《铁路应用—通信、信令和处理系统—控制和保护系统用软件》欧洲标准50128:2011，根据安全完整性，确定这一领域的软件系统的测试目标，即要所完成的测试，如表2-2所示。
测试的目标要有具体的指标，可以被度量，在测试执行结束之前或之后，能够判断测试目标是否被达到。对各项质量要求的验证达到什么程度，能够给出数字描述的就尽量给出，从功能、性到安全性、兼容性等逐项给出明确的目标。
2.1.3 基本的测试需求
先谈软件产品的功能测试需求。在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。例如，在讨论软件测试方法时，经常谈到黑盒方法的等价类划分、边界值分析、决策表、因果分析等方法，实际上这些只是功能测试的冰山一角，不仅要对输入空间进行验证，而且还要对用户界面、业务逻辑等进行验证。总之，为了更全面地验证或评估软件功能的质量，需要在各个层次（单元、接口和系统）和各个方面（代码、文档和系统）进行测试。也就是说，在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。概括起来，功能测试的需求包括下列这些内容。
（1）单元之间调用、函数之间调用的各种参数的数据测试。
（2）系统的不同输入、结果输出的数据测试。
（3）数据库默认值、数据备份和恢复的测试。
（4）系统各个界面的验证。
（5）用户操作的易用性、用户体验的测试。
（6）单元逻辑、算法的测试，如通过代码评审发现算法问题。
（7）系统的业务逻辑验证，如端到端的测试。
（8）文档的验证，包括用户手册、安装文档逐行逐字的验证。
（9）各类关键代码的评审。
（10）功能的错误操作、异常操作的测试。
（11）功能一致性、多功能互操作的测试。
如果系统只是满足了功能要求，没有满足一些非功能特性（性能、安全性等）要求，还是不能满足客户的需求，不能获得用户的信任。如某个网站功能（注册、信息查询等）齐全，也可以被访问，但是，每打开一个页面都需要两分钟。结果，用户不能忍受，再也不会访问这个网站。这种非功能性的需求满足和功能性的需求满足同样重要。
为了验证系统是否符合非功能特性的质量需求而进行的测试是系统非功能性测试。非功能性测试需求覆盖软件系统的所有质量属性，包括性能、安全性、可靠性、兼容性、易维护性和可移植性等，它们存在对应的关系，如图2-2所示。
但每一类测试可能需要单独考虑，性能测试和兼容性测试、安全性测试都不一样，考虑的着眼点不一样。例如，性能测试的目的之一就是为了验证当前系统实际所具有的性能。如果实际性能达不到系统使用的需求，就需要改进设计，优化算法或程序代码，直至达到要求。除了以上的目的之外，性能测试还可以进一步分为基准测试和规划测试，具体分析如下。
对于新建立的系统，测试人员并不了解某些具体的性能指标，所以性能测试的首要任务就是获取这些指标的标准值，然后基于由这些标准值所设定的基准，进一步制定产品性能改进计划，也就是性能指标的变更需求计划。
产品最终要被部署到运行环境中，在部署之前要进行规划，例如，根据用户的数量或数据负载来决定服务器的选型和数量，如果10万个用户需要4台双核CPU、内存4GB的服务器，如果是100万个用户是否需要16台双核CPU、内存8GB的服务器等。这些规划的数据依赖于性能的规划测试。
容量测试可以看做是性能测试的一种，或者认为系统的容量是系统的性能指标之一。如某个Web站点可以支持多少个并发用户、网络在线会议系统中与会者的人数。如果实际容量已满足要求，就能帮助用户建立对产品的信心。如果不能满足要求，就应该寻求新的解决方案，以提高系统的容量。若一时没有新的解决方案，就有必要在产品发布说明上明确容量上的限制，避免引起软件产品使用的纠纷。
概念：
（1）负载测试（Load Test），也称压力测试（Stress test）、强度测试。负载测试通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，逐渐加载或一次性加载，长时间或超大负荷地运行软件，以测试系统的稳定性，并试图找出系统性能的瓶颈和异常的地方等。通过负载测试，也可以确定系统的正常工作条件、极限条件等，并了解系统可靠性等，从而提高软件系统的可靠性、稳定性，减少系统的宕机时间。
（2）性能测试（Performance test），通过测试确定系统运行特性的性能指标数据，如数据吞吐量、响应时间、CPU使用率等。性能测试可以分为3类：
验证测试，针对系统验证事先（如产品规格说明书）已定义的性能指标；
基准测试，就是在系统标准配置下获得有关的系统指标数据，其测试结果应具有高度的一致性、标准性，可作为将来性能改进的基准线；
规划测试，是为软件部署而进行的测试，即在多种特定的环境下，获得系统不同性能的指标，从而决定在系统部署时采用什么样的软、硬件配置。
（3）容量测试（Capacity test），预先分析出反映软件系统应用特征的某项指标的极限值，了解该软件系统的承载能力或提供服务的能力。系统在极限值状态下，主要功能还能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载（数据量、事件规模等）。容量测试可以看作负载测试和性能测试的组合。
（4）安全性测试（Security test），检验系统权限设置的有效性，防范非法入侵的能力，数据备份和恢复的能力等。例如，测试人员可以假扮非法入侵者，试图采用各种办法突破系统防线，修改权限或存取权限之外的数据。
（5）容错测试（Recovery test），检查软件在异常条件下是否具有防护性的措施或者恢复某种灾难性破坏的手段或能力。容错性测试包括两个方面：
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，不会导致系统出错甚至崩溃；
灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复或在指定时间间隔内恢复。
对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。容错测试和故障转移（fail-over）、可用性测试等有直接的关系。
2.2 项目的测试需求
在掌控了软件项目的背景，了解了产品的质量要求和软件测试的基本需求之后，同时，测试人员也会阅读相关软件需求文档，参与需求评审。在这些基础之上，可以进行测试的需求分析，即包括下面这些工作：
明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试；
知道哪些测试目标优先级高、哪些目标优先级低；
要完成哪些相应的测试任务才能确保目标的实现。
然后才能估算测试的工作量，安排测试的资源和进度。测试需求分析是测试设计和开发测试用例的基础，测试需求分析得越细，对测试用例的设计质量的帮助越大，详细的测试需求还是衡量测试覆盖率的主要依据。只有在做好测试需求的基础上，才能规划项目所需的资源、时间以及所存在的风险等。
2.2.1 测试需求分析的基本方法
无论是功能测试，还是非功能性测试，其测试需求的分析都有以下两个基本的出发点。
（1）从客户角度进行分析：通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。
（2）从技术角度分析：通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。
如果有完善的需求文档（如产品功能规格说明书），那么功能测试需求可以根据需求文档，再结合前面分析和自己的业务知识等，比较容易确定功能测试的需求。如果缺乏完善的需求文档，就需要借助启发式分析方法，从系统业务目标、结构、功能、数据、运行平台、操作等多方面进行综合分析，了解测试需求，并通过和用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。
业务目标：所有要做的功能特性都不能违背该系统要达到的业务目标，多问问如何更好地达到这些业务目标，如何验证是否实现这些业务目标？
系统结构：产品是如何构成的？系统有哪些组件、模块？模块之间有什么样的关系？有哪些接口？各个组件又包含了哪些信息？
系统功能：产品能做哪些事、处理哪些业务？处理某些业务时由哪些功能来支撑、形成怎样的处理过程？处理哪些错误类型？有哪些UI来呈现这些功能？
系统数据：产品处理哪些数据？最终输出哪些用户想要的结果？哪些数据是正常的？又有哪些异常的数据？输入数据如何被转化、传递的？这中间有哪些过渡性数据？输出数据格式有什么要求？输出数据存储在哪里？
系统运行的平台：系统运行在什么硬件上？什么操作系统？有什么特殊的环境配置？是否依赖第三方组件？
系统操作：有哪些操作角色？在什么场景下使用？不同角色、场景有什么不同？有哪些是交集的？
上面这些分析，更多是从测试对象本身来进行分析，还包括用户角色分析、用户行为分析、用户场景分析等。我们还可以通过如下一些其他方面的资料，帮助我们更好地完成测试的需求分析。
对竞争产品进行对比分析，明确测试的重点。
质量存在哪些风险，包括安全性漏洞等。
对过去类似产品或本产品上个版本所发现的缺陷进行分析，总结缺陷出现的规律，看看有没有漏掉的测试需求。
在易用性、用户体验上有什么特别的需求需要验证？
管理者或市场部门有没有事先特定的声明？
有没有相应的行业规范、特许质量标准？
测试需求分析过程，可以从质量要求出发，来展开测试需求分析，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求形成已分解的测试项，结合质量要求，这些测试项再扩展为测试任务，这些测试任务包括了具体的功能性测试任务和非功能性测试任务。在整理测试需求时，需要分类、细化、合并并按照优先级进行排序，形成测试需求列表，
2.2.2 测试需求的分析技术
在软件测试需求分析过程中，可以采用有效的问题分析技术来帮助我们提高测试需求的有效性和工作效率。从测试需求分析来看，我们力求通过与各相关干系人的沟通，收集足够的、有价值的信息或数据，借助下列途径来达到良好的分析效果。
（1）通过提炼，抓住主要线索，或作为整体来进行分析，使测试需求分析简单化。
（2）通过业务需求或功能层次的整理，使测试需求分析结构化、层次化。
（3）通过绘制业务流程图、数据流程图等，使测试需求分析可视化。
（4）通过类比、隐喻，加强用户需求的理解，更好地转化为测试需求。
在测试需求的分析中，能采用静态分析技术与动态分析技术、定性分析技术和定量分析技术，其中以静态分析技术、定性分析技术为主，但产品性能、用户行为分析和用户体验分析等也常采用定量分析技术。有时，会采用综合分析技术、模型分析技术等。
在测试需求分析时，产品本身往往处于需求分析和设计过程中，静态分析技术是常用的分析技术。静态分析技术包括如下。
通过系统建模语言（SysML）的需求图，可以更好地分析各项需求之间的关系，比较容易确定测试需求的边界。
通过状态图、活动图更容易列出的测试场景，了解状态转换的路径和条件，哪些是重要测试场景等。
实体关系图可以明确测试的具体对象（实体）及其之间的关系，进行相关分析。
鱼骨图法、思维导图等，有一个清晰的分析思维过程，迅速展开测试需求，随时补充测试需求等。
代码复杂度静态分析工具，代码越复杂，测试的投入也需要越多。
还可以用一些普通工具，如检查表。
脑力激荡法，让大家发散思维，相互启发，让任何测试需求不会被错过。
而动态分析技术应用相对少一些，但在一些应用场景的分析中还是有帮助的，如前面提到的竞争对手产品分析，这是一种动态分析技术，通过操作竞争对手产品，全面了解相同业务的需求，在功能、逻辑、界面等各个方面深入挖掘测试需求。同样道理，需求原型分析技术——基于开发已构建的原型来进行测试需求分析，更能直观地理解产品，进而有助于测试需求的分析，达到类似效果。可以采用仿真技术、模拟技术、角色扮演等手段，也能帮助测试需求的分析。
2.2.3 功能测试范围分析
在分析测试范围时，一般先进行功能测试的范围分析，然后再进行非功能性测试的范围分析。对于功能测试，可以借助业务流程图、功能框图等来帮助我们进行测试的需求分析。在面向对象的软件开发中，也可借助UML用例图、活动图、协作图和状态图来进行功能测试范围分析。这里通过前述两个实例简单地说明如何做功能测试的需求分析。
1．GoogleTalk客户端软件
基本功能测试需要根据具体功能的逻辑、黑盒测试方法等进行测试用例的设计，并考虑用户的习惯思维，把功能划分成如下若干个模块。
登录与注销。
主面板功能设置。
文字聊天。
语音聊天。
用户设置。
消息/呼叫的提示。
文件与语音邮件发送。
然后按模块分别进行分析，但同时也要明确系统的边界，以及各个模块之间是否存在关联关系、互操作性等。让我们首先快速分析一下各个模块的测试需求。
安装与卸载。安装的界面检查、正常安装、中途退出、操作逻辑检查等。卸载后检查用户数据是否被删、有无遗留文件、对其他应用程序运行是否产生影响。
注册、登录与注销。用户注册Google账号，在客户端登录，其他好友能看到其登录后上线和注销后下线等相关状态信息。
好友管理。可以方便地添加、删除好友，Google Talk会自动将最常联系的好友排在列表的最上面，也可以用查找框快速地查找好友。
文字聊天。聊天窗口分菜单、消息显示、消息输入几个部分，Talk的功能相对简单，重点要求是方便地在用户之间传递消息，以及不同输入语言的正确显示。
语音通话。分为呼叫、通话、结束三个阶段。要求控制反应灵敏，语音清晰连续。
邮件管理。Talk 和Gmail做到了很好的整合，聊天记录也可以保存在Gmail邮件服务器上，在客户端我们重点只看邮件提醒的功能。
2．Google日历的测试范围
Google日历的功能可以分为4部分——日历页面显示、事件（包括各种活动、会议和待办事项等）添加功能、搜索功能和选项设置，如图2-3所示。测试关键点在于确保Google日历的组件能够准确、安全、无错误地实现事件定制及浏览、预约提醒、日历共享、个性化设定等功能。而对某个具体功能的测试，其测试范围一般包括输入、编辑、查询、显示等。如在数据输入方面，要测试最大输入的文字数、双字节文字、特殊符号等各种情况，还要测试输入区域支持复制、粘贴等操作。
对于Web的功能分析，也可以从页面帧结构、布局来进行分析。例如Google日历的显示区域设定为以下4个子区域。
顶部是搜索框和协作分享。
左边区域，快速创建事件、日历、我的日历和其他日历等。
右边上面区域，按日、周、月等方式浏览活动，打印以及设置。
右边大区域就是日历显示和操作的主区域。
如图2-4所示。在显示上，要测试日历和各个分类框架显示格式是否正确，排序是否正确，文字标记和超链接是否可以打开和跳转成功。重点要测试右边的主显示和操作区域，要求在输入很多且很长的待办事项的情况下，显示内容可以自动换行，字符没有乱码和截断，相互之间的日、周、月、年表单之间相互跳转没有问题。
在进一步进行功能分析后，可以了解更具体的功能测试范围。
（1）登录，是最基本的功能需求，对用户身份进行合法性验证，对各种登录模式的安全性验证，包括Cookie和Session的有效期验证。
（2）活动定制功能。
定制会议后，能正确显示。
循环会议可以成功指定与显示。
会议可以被成功修改。
跨日会议的准确性，以及夏令时的准确显示。
与其他日历的兼容，如导入/导出数据是否正常。
（3）提醒功能。根据活动的设置，系统能够在活动之前发送提醒到Google
alk、电子邮件地址、移动设备等。
（4）共享功能。可以根据用户的权限设置来决定是否让他人看到自己的日历。
（5）时间表能将用户所注意或关心事件的时间和用户的个人行事整合起来，直接了解效率手册中的重要活动，并可查看朋友的效率手册、俱乐部的效率手册、运动队的比赛日程以及其他更多内容。按照合并视图或栏视图方式显示。
3．一般性的Web测试项目
（1）用户登录，登录的用户名、口令能否保存？口令忘了，能否找回来？允许登录失败的次数是否有限制？口令字符有没有严格要求（如长度、大小写、特殊字符）？是否硬性规定经过一段时间后必须改变口令？
（2）站点地图和导航条。每个网站都需要站点地图，让用户一看就能了解网络内容，而且当新用户在网站中迷失方向时，站点地图可以引导用户进行浏览，找到所想访问的内容。需要验证站点地图每一个链接是否存在而且正确，有没有涵盖站点上所有内容的链接。是否每个页面都有导航条?
导航条是否一致、直观?
（3）链接，去正确地方，即链接地址正确，并能显示正常、自然，不要给人突然的感觉。
（4）表单，各项输入是必需的、合理的，各项操作正常，对于错误的输入有准确、适当的提示，并完成最后的提交。提交后，返回提交内容的显示，使用户放心。如用户通过表单进行注册，能输入用户名、口令、地址、电话、爱好等各种信息，当格式、内容不对或不符时，及时给予提示，在用户提交信息后，进一步检查各项内容的正确性，然后写入数据库、返回注册成功的消息。
（5）数据校验，根据业务规则和流程对用户输入数据进行校验，是许多系统不可缺少的。通过列表选择、规则提示或在线帮助，能很好解决这问题。
（6）Cookie，在Web应用中到处可见，用来保存用户注册、访问和其他本地客户端信息，所保存的信息要加密，并能及时更新。Cookie被删除了，能被重建。
（7）Session，是否安全、稳定，而且占用较少的资源。
（8）SSL、防火墙等的测试。使用了SSL，浏览器地址栏中URL的“http:”就变为“https:”了，服务器的连接端口号则由80变为433，应用程序接口API也要和页面保持一致。防火墙支持更多的设置，包括代理、验证方式、超时等。
（9）接口测试，与数据库服务器、第三方产品接口（如电子商务网站信用卡验证）的测试，包括接口错误代号和列表。
4．UI测试的需求
过分地使用粗体字、大字体和下画线可能会让用户感到不舒服。
背景颜色使用不当，虽然美观，但不易阅读，内容阅读才是最重要的。通常来说，文字和背景对比较大比较适宜，背景浅淡则文字采用深颜色；背景深黑则文字采用亮色。对比要采用适当，和谐往往更容易被人接受。
每一张图片都是必要的，位置和大小合适，采用了JPG和GIF格式，而且和文字吻合。
不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
表格显示是否清晰，必要的数据能否在一个页面显示？翻页、水平移动是否流畅等？表格里的文字是否能折行且保持内容完整，或者使用表格栏宽度设置协调？
2.2.4 非功能性的系统测试需求
对于非功能性的系统测试，主要目的是验证软件系统的整体性能等是否满足其产品设计规格所指定的要求，涉及非功能性的质量需求有系统性能、安全性、兼容性、扩充性等的测试，可能还会涉及第三方产品的集成测试。对于每一个应用软件系统，非功能特性的质量需求都是存在的，这类测试需求会因不同的项目类型差异比较大，这些需求的程度、重要性不同，因此要求为非功能性测试需求设置优先级，下面就做一个简单的分析。
纯客户端软件，如字处理软件、下载软件、媒体（音频/视频）播放软件等在系统测试要求上是最低的，对性能、容错性、稳定性等有一定的要求，如占用较少的系统资源（CPU和内存），而且能运行在不同的操作系统上，一般分为Windows、Linux和Mac等。在Windows上要支持Windows
NT、Windows 2000、Windows XP和Windows Vista等。
纯Web（B/S）应用系统，如门户网站、个人博客网站、网络信息服务等在系统测试上要求较高，特别强调性能和可用性，对安全性有一定的要求，主要是保证数据的备份和登录权限。性能要求好，可以允许大量并发用户的访问，而且用户在任何时刻都可以访问，即每周7天，每天24小时（7×24）运行。
客户端/服务器（C/S）应用系统，如邮件系统、群件或工作流系统、即时消息系统等在系统测试需求上与Web应用系统接近，也可能出现大量并发访问的用户，但安全性相对好写，客户端是特定的开发软件，相对于浏览器来说，对端口、协议等的限制比较容易做到。
大型复杂企业级系统涉及面广、集成性强，包括B/S、C/S、数据库、目录服务、服务器集群、XML接口等各个子系统。在系统测试需求上，这类系统要求最高，不论是在性能、可用性方面，还是在安全性、可靠性等方面，都有很高的要求。
系统非功能性测试的需求在不同应用领域也体现较大差异。如网上银行、信用卡服务等系统，其安全性、可用性和可靠性等多方面的测试至关重要，因为这方面的缺陷很可能会给用户造成较大的损失。这些系统需要得到充分的安全性测试、容错性测试和负载测试。多数情况下，还需要独立第三方的安全认证。
而对于局域网内的企业级应用来说，有关权限控制、口令设置等安全性测试依然重要，但兼容性测试就相对简单，因为可以指定某些特定的硬件和软件，如打印机只用HP
LaserJet，操作系统和浏览器只用Windows XP和IE，无须对各种各样的硬件和软件进行兼容性测试。对于客户端软件，一般情况下，性能不是问题，而容错性、稳定性的测试则显得重要些。
对于企业级应用系统来说，存在着不同的应用模式，其系统的架构也不一样，可以分为“以功能为中心、以数据库为中心和以业务逻辑（工作流）为中心”等，在进行系统测试时，所设定的目标也有一定的区别。
以功能为中心的系统，强调模块化的低耦合性和高内聚性，这类系统的可扩充性、维护性要求很高。
以数据库为中心的系统，强调数据处理的性能、正确性和有效性，使数据具有良好的一致性和兼容性，同时，确保数据的安全性，包括数据的存储、访问控制、加密、备份和恢复等。
以应用逻辑（工作流）为中心的系统，强调灵活、流畅和时间性，系统的可配置性强，接口规范，如采用XML统一各工作流构件的输入和输出。
除此之外，还有其他一些因素的影响，如项目的周期性和依赖性等。如果项目是一次性的，对可扩充性、可移植性等要求低，而长期性的项目（产品开发）对可扩充性、可移植性要求就很高。
Google日历实际上是一种软件服务，即属于软件即服务（Software as aService，SaaS）的应用模式，对软件运行的服务质量（QoS）也有很高的要求，需要支持7x24不间断的服务。对于这样的Web服务软件，非功能性测试的需求涉及性能、安全性、容错性、兼容性、可用性、可伸缩性等各个方面。
服务级别协议（SLA）指定了最低性能要求，以及未能满足此要求时必须提供的客户支持级别和程度。与
QoS 要求一样，服务级别要求源自业务要求，对要求的测试条件及不符合要求的构成条件均有明确规定，并代表着对部署系统必须达到的整体系统特性的担保。服务级别协议被视为合同，所以必须明确规定服务级别要求。如表2-3所示。下面侧重性能、可用性、安全性和兼容性的测试需求讨论，而对其他非功能性属性就不进行过多的讨论，这并不意味着这些属性就没有测试需求，例如可维护性（即系统维护的容易程度）的测试需求也是很多的，包括系统监视、日志文件、故障恢复、数据更新和备份等测试。
1．性能测试
性能测试分为服务器端性能测试和客户端性能测试，需要考虑“哪些负载（如并发用户数200、400、1000等）、哪些基本配置（最低配置、标准配置等）需要进行性能测试”等测试需求。服务器端的性能测试还可进一步分为基准性能测试、性能验证测试、压力测试、容量测试、可伸缩性测试等。
客户端性能测试，需要对页面显示、刷新的时间进行测试获得相关性能指标数据，如在Google日历中添加大批量的待办事项，然后查看页面浏览的响应时间。客户端软件性能测试，还要考察其运行时所占有资源（如CPU、内存）情况，占有资源越少越好。
如Google Talk在好友数量以及对话窗口非常多的情况下，CPU、内存的使用仍然处在一个合理的范围内，如CPU使用率不超过20%（正常运行时间，不是软件启动的短暂时刻）。
网络资源占用，如Google Talk的语音占带宽大约24～32K（24000～32000bit/s）。
在较差的网络条件下，语音与文字聊天能保持流畅。
移动应用app测试时，不仅要测试其网络流量，还要测其耗电量，耗电量和CPU的开销也有关系。
在长时间运行（7×24小时）下，没有内存泄漏等问题。
这些既是性能要求，也是性能测试需求，性能测试要覆盖各项要求。
在服务器端，通过改变网络带宽或延迟、负载模式和大小，对一些关键业务（如Google日历中登录、提交新事项时、按月显示、查询等）进行测试，以获取或验证系统整体的性能指标。如系统要求在正常使用情况下其响应时间为3～5秒，即使在使用高峰期（如上下班时间）系统的响应时间也不应该超过15秒，这就意味至少要进行两种场景——平均负载和高峰负载的性能测试。在对实际系统进行性能测试时，往往会结合其关键业务考虑其关键性能测试需求。
多人同时登录（并发用户活动）、设置活动时，页面的响应速度要求在3秒之内。
通过页面进行搜索时，查询时间应控制在5秒以内。
设置共享时、用户更新活动信息时，是否能快速同步，即在另一共享好友处即刻显示更新过的信息。
当活动/事件达到一定数量（200～1000）时，页面响应速度要在5秒之内。
当循环会议较多时，页面的处理速度正常（5秒之内）。
在哪些负载、测试周期（8个小时、24小时、7天等）的组合情况下进行压力测试。
压力测试往往和容量测试结合起来，以测试系统的限制和故障恢复能力，如测试应用系统在长期高负载下会不会崩溃、在什么情况下会崩溃，并确定系统能承受的最大负载（如最大连接数、并发用户数等）。
可伸缩性通常要求在对部署体系结构的设计不做修改的情况下增加资源以满足系统增加的容量，从而使系统容易支持来自现有用户或扩大的用户群体的额外负载。可伸缩性测试也可以归为性能测试，如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两倍或接近两倍。如果是，系统就具有良好的可伸缩性。
2．可用性测试
可用性是指系统正常运行的能力或程度，在一定程度上也是系统可靠性的表现，可用性测试就基本上等同于可靠性测试。可用性一般用正常向用户提供软件服务的时间占总时间的百分比来表示，即：
可用性 = 正常运行时间 /（正常运行时间 + 非正常运行时间）? 100%
系统非正常运行时间可能是由于硬件、软件、网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或连接中断不能被访问，或性能急剧降低不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个“9”，即99.99% 或99.999%。
如果可用性达到99.99%，对于一个全年不间断（7?24的方式）运行的系统，意味着全年（525600分钟）不能正常工作的时间只有52
分钟，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5 分钟。
所以一个系统的可用性达到99.999%，基本能满足用户的需求。当然，不同的应用系统，可用性要求是不一样的，非实时性的信息系统或一般网站要求都很低，可能在99%和99.5%之间，而对一些军事系统，则要求很高，如美国防空雷达系统全年失效时间不超过两秒，可用性高达7个“9”之上，达99.999994%。
可用性测试就比较困难，不可能有足够的时间来进行测试，就只能采用空间换时间的办法，例如在高负载情况下进行为期一周或一个月的测试，以判断其可靠性。其次，就是对提高可靠性的措施进行测试，如故障转移的测试。
容错处理系统能够处理异常、错误操作而不至于系统崩溃，从而能够提供系统的可用性。例如，业务处理过程中中断事务时，系统能保存当前状态，程序能自动或提示重连，或在某个时刻可以恢复操作。
3．安全性测试
安全性是一个复杂的主题，涉及部署系统的各个级别。安全性要求分析，包括确定可能的或潜在的各类安全威胁和找到处理这些威胁的策略，即：
确定关键（有形的和无形的）资产，并找到对这些资产的威胁；
确定使组织暴露于可能带来风险威胁的薄弱环节；
开发减轻组织风险的安全规划。
分析安全要求应由软件组织的各方面风险承担者参与，包括管理员、业务分析师和信息技术人员等。通常，组织会指定一个安全结构设计师来领导安全措施的设计和实现。
安全性测试就是全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。所以，安全性测试的需求点还是比较多的，任务还是比较重的，特别是对复杂的系统。这里举一些常见的需求点：
各种登录模式的安全性验证、对口令各种要求的测试；
用户权限的验证；
所有入口的验证，即对数据输入的验证；
Cookie和Session的有效期验证等特殊机制的验证；
数据访问权限设置验证，如服务器上的目录设置；
敏感数据加密、数据存储安全性的验证；
验证系统的日志文件是否得到保护；
在异常条件下操作、错误操作，测试软件以表明不会因可能的单个或多个输入错误而导致不安全状态；
其他各种安全漏洞（如跨站点攻击、SQL注入等）的检查。
4．兼容性测试
兼容性测试需求是指明确要测试的兼容环境，考虑软、硬件的兼容，就软件兼容来说，不仅要测试系统自身的版本兼容、用户已有数据的兼容，还要测试与操作系统、应用平台或浏览器、和其他第三方系统以及第三方数据的兼容性。操作系统包括Windows、Mac、Solaris、Linux等，浏览器包括IE、FireFox、Chrome和Safari等，如表2-4所示，形成环境组合矩阵，更能明确兼容性测试需求。兼容性测试的组合不仅仅局限在操作系统、浏览器这两个因素，还有其他因素，如：
32位、64位CPU；
手机平台 Android、iOS、Windows Phone；
支持不同的Internet连接速度；
是否支持SSL。
兼容性测试需要根据被测试应用的具体情况决定。像Google日历应用，支持移动平台是必须的，而且日历有较多的个人信息，需要支持SSL，但32位、64位CPU对其没有什么影响，不需要考虑。而对于像Google
Talk这样客户端应用程序，就不需要考虑浏览器支持，而且不同的操作系统（Windows、Mac OS、iOS、Android等）有不同的应用程序，需要单独处理，只是每类操作系统还有多个版本，如iOS有iOS
5、iOS 6和iOS 7等。
兼容性测试，不仅是软件系统之间兼容、和第三方系统之间的兼容，而且还需考虑系统版本之间的兼容，特别是用户数据的兼容，数据兼容测试也是重要的需求。例如：
不同客户端软件（如Google Talk）版本和服务器系统的兼容，服务器上一般部署的都是最新版本，但客户端就不一定；
新版本的软件能够兼容以前各种版本产生的历史数据，确保数据向上兼容，如Word2013 能够正常打开之前多个Word版本（如Word
2003，Word 2007等）产生的用户.doc文件。
2.3 测试工作量估算
在确定了测试需求、明确了测试范围之后，就需要明确测试任务，估算测试工作量。基于质量需求和测试的工作量、测试环境、产品发布的设想时间等要求，就可以确定测试进度和所需的测试资源，或者基于现有的测试资源来决定测试的日程表。
在传统开发模式中，测试工作量估算是测试计划的基础工作之一，但在敏捷开发中，虽然也强烈建议有一个测试计划，但其测试计划简明扼要，主要是列出测试目标、测试边界、测试点、主要的测试风险和注意事项等。其测试任务在迭代计划（如Scrum的SprintPlanning）会议中和开发任务一并考虑，可以采用Scrum估算扑克牌的方式来完成估算，这样测试工作量估算主要依赖个人经验、团队沟通等完成。即使是采用这种方式，对下面内容了解之后，有一个科学估算的基础，在敏捷开发中依旧会发挥作用。
2.3.1 工作量的估计
测试的工作量是根据测试范围、测试任务和开发阶段来确定的。测试范围和测试任务是测试工作量估算的主要依据。如何确定测试范围已在上一节做了充分的讨论，可以根据产品需求规格说明来决定。测试任务是由质量需求、测试目标来决定的，质量要求越高，越要进行更深、更充分的测试，回归测试的次数和频率也要加大，自然，测试的工作量要增大。处在不同的开发阶段，测试工作量的差异也挺大。新产品第一个版本的开发过程，相对于以后的版本来说，测试的工作量要大一些。但也不是绝对的，例如，第一个版本的功能较少，在第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%。
2.3.2 工作分解结构表方法
要做好测试工作量的估算，需要对测试任务进行细化，对每项测试任务进行分解，然后根据分解后的子任务进行估算。通常来说，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮动幅度，来确定实际所需的测试工作量。比较专业的方法是工作分解结构表（WBS），它按以下3个步骤来完成。
（1）列出本项目需要完成的各项任务，如测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。
（2）对每个任务进一步细分，可进行多层次的细分，直到不能细分为止。如针对测试计划，首先可细分为：
确定测试目标；
确定测试范围；
确定测试资源和进度；
测试计划写作；
测试计划评审。
“确定测试范围”还可再细分为功能性测试范围和非功能性测试范围的分析。“测试计划评审”可以再分为测试组内评审、项目组评审、公司质量保证小组评审和最终批准。
（3）列出需要完成的所有任务之后，根据任务的层次给任务进行编号，就形成了完整的工作分解结构表（如表2-5所示）。
WBS除了用表格的方式表达之外，还可以采用结构图的方式，那样会更直观、方便，如图2-5所示。
当WBS完成之后，就拥有了制定日程安排、资源分配和预算编制的基础信息，这样不仅可获得总体的测试工作量，还包括各个阶段或各个任务的工作量，有利于资源分配和日程安排。所以，WBS方法不仅适合工作量的估算，还适合日程安排、资源分配等计划工作。
2.3.3 工作量估计的实例
结合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日历所要的测试工作量。
2.4 测试资源需求
分析测试范围之后，所需要的测试资源就比较清楚了。测试的资源需求，包括人力资源和软、硬件资源。人力资源，侧重如何组建测试团队——项目测试组，而软、硬件资源，对于不同的项目差异很大。这里只讨论一般的操作方法，设计测试环境的建立，将在第7、第9章进行详细介绍。
如果将测试资源进行较为详细的分类，可以归纳为如图2-6所示。
1．人力资源需求
在完成了测试工作量的估算之后，软件测试项目所需的人员数目就能够基本确定了。软件测试项目所需的人员和要求在各个阶段是不同的。
（1）在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。
（2）在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。
（3）在测试中期，主要是测试的执行，测试需求的数量取决于测试自动化实现的程度。如果测试自动化程度高，人力的投入则不需要明显的增加；如果测试自动化程度低，对执行测试的人员要求就比较多了。
（4）在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。
2．测试环境资源
把建立所有必要的测试环境所需的计算机软件资源和硬件资源合称为测试环境资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源包括操作系统、第三方软件产品、测试工具软件等，具体如下。
硬件：交换机、路由器、负载均衡器（Load balance）、服务器、客户端PC、摄像头、特殊的显示卡和声卡、耳机、麦克风等。
支撑的系统软件：Linux操作系统、Web服务器（如Apache）、中间件（如Tomcat、WebLogic）、数据库系统软件MySQL/Oracle等。
测试工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。
2.5 测试里程碑和进度安排
软件测试贯穿软件产品开发的整个生命周期，从产品的需求分析审查到最后的验收测试，直至软件发布。从测试实际的前后过程来看，软件测试的过程是由一系列不同的测试阶段组成的，这些阶段主要有：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。在软件测试项目的计划书中，需要给各个阶段制定一个明确的开始和结束时间，这就是通常所说的日程进度表（schedule）。项目进度安排，实际上取决于测试工作量和现有的人力资源。当人力资源充足时，测试周期短；当人力资源较少时，测试周期就会长。
里程碑一般是项目中完成阶段性工作的标志，即用一个结论性的标志来描述一个过程性任务明确的起止点，进度安排就是确定里程碑的起止点。一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry
Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。里程碑具有很强的时序性，还具有下列特征。
里程碑也是有层次的，在一个父里程碑的下一个层次中定义子里程碑。
不同类型的项目，里程碑可能不同。
不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
2.5.1 传统测试
在软件测试周期中，建议定义下列6个父里程碑。
（1）M1：需求分析和设计的审查。
（2）M2：测试计划和设计。
（3）M3：代码（包括单元测试）完成。
（4）M4：测试执行。
（5）M5：代码冻结。
（6）M6：测试结束。
每个里程碑再划分为子里程碑，如果项目周期很长，还可以对每个子里程碑进一步划分为更小的里程碑，以利于更有效的控制，如表2-7所示。
2.5.2 敏捷测试
在本书一开始的引言中，以Scrum为例，简要阐述了敏捷测试流程。而在敏捷测试项目中，如何明确测试的里程碑呢？万变不离其宗，敏捷测试也需要从测试计划到测试设计、再到执行，只是测试设计和执行的界限不那么分明，测试设计和执行往往交替或并列地开展。在敏捷测试中，甚至可以不需要测试用例，而是针对Use
Case 或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发相对稳定功能的自动化测试脚本，为后期的回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合上述考虑，敏捷测试的实际操作流程如图2-7所示，简单有效。
在这样的流程中，大框架也没有什么不同，而且各项测试件（测试计划、需求、自动化脚本等）的评审还是需要的，只是没有明确的评审阶段，测试是一个持续的质量反馈过程，阶段性不那么突出，但还是可以设定一些控制点，即里程碑：
（1）测试任务定义；
（2）测试计划制定和评审通过；
（3）测试需求或测试点（或测试场景）列表明确和评审通过；
（4）验收测试结束。
2.6 测试风险分析
在1.1.4节讨论了测试的风险观点，测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这意味着软件测试有较高的风险，所以软件测试的风险分析非常重要。软件测试风险，就是要将测试范围、测试过程中的风险识别出来，确定哪些是可避免的风险，哪些是不可避免的，对可避免的风险要尽量采取措施去避免。
风险识别的有效方法是建立风险项目检查表，按风险内容进行逐项检查、逐个确认。对于测试的风险，可以给出如下一个风险项目检查表，如表2-8所示。
在测试风险分析中，逐项检查，确认风险之后，要找出对策，以避免风险产生或降低风险所带来的影响。表2-9给出了软件开发中常见的风险，说明这些风险发生的可能性、对测试的影响和影响程度以及如何进行预防和控制。
下面会针对本书的两个典型案例给出简单的风险分析。客户端软件的测试风险相对来说会低一些，所以不做讨论。而且本书对软件测试中普遍存在的风险也不做讨论。
1．GoogleTalk的几个测试风险
如果基本功能方面的问题太多，将严重影响性能压力测试的进度。
在第二轮测试后，产品应该基本无大的问题。开发要在第三轮测试开始前保证修复好所有已发现的主要问题。
多语言版的测试要求测试人员前期准备充分，测试人员对所测语言有可能不太了解，对该语言国家的使用习惯也不是很熟悉。
开发人员拿出产品的第一版本时，要提供或与测试人员共同完成压力测试工具的开发。
2．Google日历的测试风险
（1）项目复杂度。由于开始对项目的复杂度估计不足，导致项目后期的产品代码不能按时完成，这样势必会影响到测试的环节。
（2）需求的变化。用户的反馈、市场需求的变化会导致项目后期增加一些新的产品功能，这样就会使产品不能按照原定的测试计划完成，以致测试人员处于等待状态中。
（3）服务器的升级。基于Web方式的产品，随着不断推出的新服务器产品（如Linux和Apache的版本升级），其兼容性需要验证，而且其安全性、稳定性和性能等方面所受到的影响需要分析，在测试过程中更换第三方产品的新版本，就要面临这样一个问题——是否要重新测试已测试的范围。往往不会从头再来，而是根据已定义的策略进行选择性的测试。
（4）数据库的升级。基于Web方式的产品，后台一般都离不开数据库的支持。如果测试过程中遇到数据库表结构的变化、版本升级（例如Oracle
9i升级到Oracle 10G），都会给测试过程带来风险。例如，升级后的数据库变得不稳定，有可能退回到原来的版本，影响测试甚至导致测试的失败。
（5）测试环境的不稳定性。例如被测试的服务器不能被访问，需要重新启动和配置，这会占用一定的时间。一旦不能访问测试环境，测试人员不仅无事可做，还常常会抱怨。这种情况影响了测试人员的情绪，最终也影响了测试结果。
（6）国际化和本地化的影响。如支持哪些语言版本？国际化版本的测试策略和方法、翻译公司是否能及时完成任务，以及翻译是否准确也会带来风险。
3．测试风险的控制方法
（1）根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险。如测试环境不对，可以事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查。
（2）风险转移。有些风险带来的后果可能非常严重，能否通过一些方法，将它转化为其他一些不会引起严重后果的低风险。如产品发布前发现某个不是很重要的新功能给原有的功能带来了一个严重的Bug，这时处理这个Bug所带来的风险就很大。对策是去掉那个新功能，转移这种风险。
（3）有些风险不可避免，就设法降低风险。如“程序中未发现的缺陷”这种风险总是存在，就要通过提高测试用例的覆盖率来降低这种风险。
（4）为了避免、转移或降低风险，事先要做好风险管理计划。例如，把一些环节或边界上有变化、难以控制的因素列入风险管理计划中。
（5）对风险的处理还要制定一些应急的、有效的处理方案。例如，为每个关键性技术人员培养后备人员，做好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍可以继续下去。对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。
（6）在做计划时，估算资源、时间、预算等要留有余地，不要用到100%。
（7）制定文档标准，并建立一种机制，保证文档及时产生。对所有工作多进行互相审查，及时发现问题。
知识点:
风险管理的基本内容有两项：风险评估和风险控制（如图2-8所示）。
（1）风险评估，主要依据三个因素：风险描述、风险概率和风险影响。可以从成本、进度及性能三个方面对风险进行评估，它是在建立在风险识别、风险分析和风险排序基础上的。通过评估可以确定这些风险的特点或可能带来的危害。
（2）风险控制，制定风险管理计划和风险应急处理方案，来降低风险和消除风险。
2.7 制定有效的测试策略
为了最大限度地降低测试风险，尽早地发现各种潜在的软件缺陷，在测试实施之前，测试组必须确定合适、有效的测试策略，并以此为依据选定测试方法、测试工具和测试用例设计思想。通过制定测试策略来指导测试用例的设计、测试工具的选择和执行，特别是能解决测试当中经常碰到的一些问题。良好的测试策略必将给软件测试带来事半功倍的效果，可以充分利用有限的人力和物力资源，高效地完成测试目标。
测试策略描述当前测试项目的目标和所采用的测试方法，针对某个应用软件系统或程序，具体的测试项目要达到的预期结果还包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略还要描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法，以及每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）。其内容包括如下。
对测试的公正性、遵照的标准做一个说明，证明测试是客观的，软件功能要满足整体需求，实现正确，并与用户文档的描述保持一致。如声明测试完成的标准是95%的测试用例通过并且两个最高级别的缺陷全部被修正，用以计划、实施及通报测试结果。
描述测试用例是什么样的，如何执行，用了什么样的数据，又如何执行后续的回归测试。
选定要使用的测试技术和工具。如采用了什么工具，工具的来源是什么，是否60%用Rational Robot自动测试、40%用手工测试。
根据经验判断和头脑风暴，对以往测试中经常出现的问题加以考虑。又如采取一些发散性的思维，往往能帮助找到新的测试途径。
考虑影响资源分配的特殊情况。例如有些测试必须在周末进行，有些测试必须通过远程环境执行，有些测试须考虑与外部或硬件的接口。
为了更好地确定软件测试策略，可以试着问如下一些问题，在寻找这些答案的过程中，也就找到了最佳的测试策略。
回归测试的范围如何确定？
如何利用可重复性的测试？
测试缺乏可预见性，如何收集衡量测试结果的指标？
如何建立稳定的、模拟系统实际运行的测试环境？
如何从无穷的输入数据中选择合理的、有效的测试数据集？
如何加强静态测试——规格说明书、设计文档和程序代码等的审查？
如何处理单元测试和集成测试的关系？
如何处理手工测试和自动化测试之间的平衡，使它们的互补性得到发挥，使测试的效率和质量达到最佳状态？
如何衡量这种测试策略的有效性？
1．测试策略制定的三项基本要素
软件测试策略制定有三项基本要素：输入、输出和过程。
（1）输入，作为制定测试策略的依据，包括限制条件和已具有的资源：
所要求的软、硬件的详细说明，包括测试环境、测试工具等；
人力资源和测试进度的约束，包括测试组成员的角色和职责说明；
测试方法和衡量测试是否通过的标准；
被测软件组件或系统的功能性和技术性需求文档，及其变更请求的控制流程；
软件系统所受到的其他限制。
（2）输出，制定策略的成果，即最终对所制定策略的定义或说明：
通过/失败的准则和测试风险评估的结果；
已批准和签署的测试策略文档；
和测试策略相对应的测试计划、测试用例的设计思想和思路。
（3）制定策略的过程。测试组分析需求，参与设计的讨论，要求开发、编写针对所有测试级别的测试策略，并和项目组一起复审测试策略和测试计划。测试策略应该覆盖整个项目的生命周期，需要各类技术人员（系统架构师、数据库管理员、编程人员等）参与。各类技术人员相互之间应多交流、讨论，以保证制定正确的测试策略。
2．基于测试技术的测试策略
著名的软件测试专家Myers指出了使用各种测试方法的综合策略。
在任何情况下都要使用边界值分析方法，因为为边界值分析方法所设计的测试用例能很有效地发现软件代码的缺陷。
等价类划分方法是对边界值分析方法的有效补充。
如果软件某些功能的输入数据/条件存在多种组合情况，则一开始就可选用因果图法。
错误推测法可以帮助追加一些比较特殊、不易直接推理出来的测试用例。
对照程序逻辑来审查已有测试用例的逻辑覆盖程度。如果没有达到要求的覆盖率，则应当再增加一些测试用例。
尽管用户更倾向于基于程序规格说明的功能测试，但是白盒测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。
3．分阶段的测试策略
严格地执行代码复查，以保证在早期就发现问题，而不是在代码发布之后。
利用单元测试和集成测试，可以尽早地发现更多的问题，并准备好自动化测试的BVT（Build Verification
Test，软件包验证测试）。
需要建立一个正规的且自动化的冒烟测试，只有100%通过冒烟测试，才能进入下一个阶段。
系统测试中，以每次发布用户基线为结束标志，用户基线会增长，同时也会逐渐地要求一些更为精确的性能测试。
不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。
在功能性测试、安全性测试、配置测试中可进行一些探索性测试。
制定更为详细的UAT（用户验收测试）测试计划，将其与测试脚本和培训材料一起提供给用户，以帮助用户快速提高并完成任务。
4．基于测试方案的综合测试策略
（1）根据软件产品或服务特性对客户的使用价值以及特性失效所造成的损失，来确定相应特性的测试优先级。产品特性的优先级越高，其被测试的时间越早，测试的力度也越大。
（2）要使用尽可能少的测试用例，发现尽可能多的程序错误。一次完整的软件测试过后，如果程序中遗漏的（较）严重错误过多，则表明本次测试是不足的或失败的，这意味着可能让用户承担较大的利益损失风险。反过来说，如果过度测试，则又会浪费软件企业自身的宝贵资源。所以，需要在以上两点——风险和效率上进行权衡，找到一个最佳平衡点。
（3）测试策略应该尽量的简单、清晰，例如可以在有限的白板上通过2～3行字和1～2个图就描述出测试策略来，或者可以通过一个简短的会议（20～30分钟），就能把测试策略解释清楚。
（4）基于缺陷分析的测试策略。通过缺陷分析，可以更好地了解开发人员的习惯，找到容易犯错误的地方，可以更好地设计测试用例，更快地发现缺陷。也可以从缺陷出发，反推回去，找到合适的测试策略。
5．测试策略的示例
在Google日历的测试项目中，要考虑在浏览器和操作系统的不同组合下进行测试。最简单的办法就是完成所有组合的测试，如5个操作系统（Windows2010
server、Windows 7、Windows 8、Mac 10.8、Linux）和7个浏览器（IE8、IE9、某个中文、Chrome、Firefox、Opera、Safari）的组合有近35种——因为有些组合是很少出现在实际的环境中。以前面所说的360个测试用例为基础，在各种环境上共要执行12
600多个测试用例，工作量太大。这时就需要根据操作系统和浏览器的市场占有率、对测试用例的影响程度、缺陷分析的结论和经验等，简化或优化组合。从表2-10可以看出，等价组合降到了8，只要执行大约2880个测试用例，测试的工作量大大减少。
针对Google日历这样的产品，还可以制定针对功能性和用户界面的测试策略。如按照Google日历的功能划分来设计测试用例，保证一系列的逻辑被有效地验证。
输入时间或活动的组合（不同长度和单双字节的字符串长度）。
在相同的时间或活动在不同日历里面的显示和跳转（用户界面）。
改变用户的不同设置。
测试上述的功能在不同的分辨率和上述操作系统、浏览器的组合。
概念
（1）冒烟测试（Smoke Testing）是在代码被检查进入（check in）代码库之前对代码修改进行验证的流程或活动。在代码复审（code
reviews）之后，冒烟测试是识别和修正软件缺陷的最有效方法。它可以确认代码的修改符合要求和期望，且不会造成软件包构建的失败。冒烟测试和自动化回归测试的脚本集一起被用来测试那些高风险的功能或高容量的事务处理。
（2）BVT（BuildVerification Test）是软件包构造之后由测试工具（脚本）完成的验证测试，用以确认基本功能正常，没有出现严重的缺陷。BVT通过后，才进行手工测试，或者进一步的自动化测试。
2.8 完整生成测试计划书
在软件测试需求和测试范围分析、工作量估计、测试资源和进度安排、测试风险评估、测试策略制定等工作做完之后，测试计划也就基本大功告成了。测试计划本身就是为了解决测试目标、任务、方法、资源、进度和风险等问题，所以当这些问题被解决或找到相应的对策和处理措施之后，测试计划剩下的工作就是写好这个文档，将上述内容描述清楚。有一点必须在这里说明的是，测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情况的变化不断进行调整，以便于优化资源和进度安排，减少风险，提高测试效率，并及时修改“测试计划书”。
在计划书中，有些内容是介绍测试项目的背景、所采用的技术方法等的，这些内容仅仅作为参考，但有些内容（如人员组成、日程安排）也可以看作是一种结论，或者承诺，是必须要实施或达到的目标，如测试小组的结构和组成、测试项目的里程碑、面向解决方案的交付内容、项目标准、质量标准、相关分析报告等。测试计划内容的焦点则集中在下列内容上。
（1）目标和范围：包括产品特性、质量目标，各阶段的测试对象、目标、范围和限制。
（2）项目估算：根据历史数据和采用恰当的评估技术，对测试工作量、所需资源（人力、时间、软硬件环境）做出合理的估算。
（3）风险计划：对测试可能存在的风险进行分析、识别，以及对风险的回避、监控和管理。
（4）进度安排：分解项目工作结构，并采用时限图、甘特图等方法制定时间/资源表。
（5）资源配置：人员、硬件和软件等资源的组织和分配包含每一个阶段和每一个任务所需要的资源。人力资源是重点，而且与日程安排联系密切。当发生类似到了使用期限或者资源共享的时候，要及时更新这个计划。
（6）跟踪和控制机制：包括质量保证和控制、变化管理和控制等，明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者，问题发生的频率，是用什么样的测试用例测出该问题的，以及明确问题产生时的测试环境。
测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。为每一个阶段制定一个计划书，还可以为每个测试任务/目的（安全性测试、性能测试、可靠性测试等）制定特别的计划书。
同时，可以为上述测试计划书的每项内容制定一个具体实施的计划，如将每个阶段的测试重点、范围、所采用的方法、测试用例设计的思想、提交的内容等进行细化，供测试项目组的内部成员使用。对于一些重要的项目，会形成一系列的计划书，如测试范围/风险分析报告、测试标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。对于更为详细的要求，可以参考国家标准《测试计划（GB8567—88）》中制定的测试计划通用模板。
2.9 小结
本章主要讨论测试需求和如何创建有效的测试计划。测试需求包括功能测试需求和非功能性测试需求，而非功能性测试需求包括性能、安全性、可靠性、兼容性、易维护性和可移植性等测试需求。对于非功能性测试需求，既要独立考虑它们各自的特点和各自的测试需求，也要考虑它们之间的关系和相互影响，例如安全性和可靠性密切相关，越安全越可靠，越可靠越安全。而安全性会增加许多保护措施，往往会降低性能。在整个系统测试需求分析时，不仅要考虑来自整体系统的测试需求，还要考虑系统数据、外部接口等测试需求，如图2-9所示。
在测试计划过程中，主要做好下列各项工作。
确定软件功能性、非功能性的测试需求，以及各个阶段的测试任务。
进行测试范围分析，从而对测试工作量进行估算。工作量估算方法主要介绍工作分解结构表方法，并给出了实例。
测试资源需求、团队组建，包括培训。
测试里程碑和进度的安排。
对测试风险进行分析。
制定有效的测试策略。
最后完整地生成测试计划书，进行计划书的评审、跟踪和及时修改，测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情况的变化不断进行调整，用以优化资源和进度安排，降低风险，提高测试效率。
| 
