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格式，而且和文字吻合。
·不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
·表格显示是否清晰，必要的数据能否在一个页面显示？翻页、水平移动是否流畅等？表格里的文字是否能折行且保持内容完整，或者使用表格栏宽度设置协调？
