在项目启动之后，就要着手软件项目的计划，包括软件测试计划。软件测试计划是整个开发计划的组成部分，同时，它又依赖于软件组织过程、项目的总体计划、质量文化和方针。在测试计划活动中，首先要确认测试目标、范围和需求，其中“测试需求分析”是关键任务，然后在测试需求基础上制定测试策略，并对测试任务、时间、资源、成本和风险等进行估算或评估。
无论何时进行估算，我们都是在预测未来，并会接受某种程度的不确定性。软件项目计划的目标是提供一个框架，不断收集信息，对不确定性进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得项目测试负责人能够对资源、成本及进度进行越来越合理、准确的估算。这些估算是软件项目开始时在一个限定的时间框架内做出的，并且随着项目的进展而不断更新。所以，测试计划强调的是一个过程，计划（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测试目标
软件测试的目标就是根据质量要求，逐项确定、验证软件的实际表现，提供软件产品完整的质量信息；同时，为了帮助团队向客户提供一个高质量的软件产品，软件测试的目标就是更早地、尽可能地将软件产品或软件系统中所存在的各种问题找出来，并促进各类开发人员尽快地解决问题。衡量测试目标的实现，就是通过测试覆盖率来衡量，通过对测试结果的分析，来明确产品质量要求、功能点或代码行（分支、条件等）的测试覆盖率。例如：
?需求项和功能点覆盖率100%；
?代码行覆盖率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文件。
