软件测试之测试需求分析与测试计划.docx
《软件测试之测试需求分析与测试计划.docx》由会员分享，可在线阅读，更多相关《软件测试之测试需求分析与测试计划.docx（17页珍藏版）》请在冰豆网上搜索。
软件测试之测试需求分析与测试计划
软件测试之测试需求分析与测试计划
在项目启动之后，就要着手软件项目的计划，包括软件测试计划。
软件测试计划是整个开发计划的组成部分，同时，它又依赖于软件组织过程、项目的总体计划、质量文化和方针。
在测试计划活动中，首先要确认测试目标、范围和需求，其中“测试需求分析”是关键任务，然后在测试需求基础上制定测试策略，并对测试任务、时间、资源、成本和风险等进行估算或评估。
无论何时进行估算，我们都是在预测未来，并会接受某种程度的不确定性。
软件项目计划的目标是提供一个框架，不断收集信息，对不确定性进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得项目测试负责人能够对资源、成本及进度进行越来越合理、准确的估算。
这些估算是软件项目开始时在一个限定的时间框架内做出的，并且随着项目的进展而不断更新。
所以，测试计划强调的是一个过程，计划（Planning）的过程，而不仅仅是为了一个文档——“测试计划书”（TestPlan）。
测试计划活动过程伴随着需求文档的审查，而需求文档的评审反过来也有利于测试计划的制定。
而且，测试计划必须建立在软件需求定义之上，为软件的质量需求验证和确认活动的开展进行规划和指导。
1.1软件测试的目标和基本需求
在分析测试需求之前，先要确定测试目标，而测试目标的确定，取决于质量要求。
虽然在理论上，对软件质量的要求是比较明确的，但对不同的软件开发项目，其质量要求是不一样的。
根据特定的质量要求，确定测试目标。
然后再根据测试目标，来分析测试需求。
1.1.1质量要求
关于什么是软件质量，包括软件产品的质量属性，如功能性、易用性、性能、安全性、兼容性、可用性、可维护性、扩展性等。
但是，仅仅根据这些质量属性不够，还要参考业务领域专业知识、行业标准、地方标准或其他规范等，才能明确特定产品的质量要求。
只有明确质量要求，才能明确测试目标。
让我们先讨论特定软件产品的质量要求。
对质量的具体要求，可以参考国际标准ISO/IEC25030的相关描述，质量不仅局限于最终用户的需求（通常指外部质量要求、软件使用质量），还要考虑产品或项目的干系人（Stakeholders）的质量要求，包括组织的管理层、系统运维等，对软件内部质量也有具体要求，包括软件的可维护性、可扩充性等。
从质量来看，用户的需求会显得更重要，我们会在使用质量（QualityinUse）上有更多的关注，使用质量的具体要求见图2-1。
手机也是大家熟悉的产品，不同的用户群对一部智能手机的要求也是不同的，如低档手机和高档手机有着不同的质量要求、老年人和年轻人对手机也有不同的期望，商务人士对手机也有一些特定的需求（如Blackberry的实实在在的全键盘）。
低档手机的质量要求如下。
·通话正常、稳定。
·通话质量要有一定保障。
·待机时间长。
·安全，电池不能发生爆炸。
·外观大气美观，不要太重。
·通讯录、短信、闹钟等功能使用方便。
·支持手写输入功能。
但对智能手机，对手感、用户体验、性能、外观质感等有更高的要求。
虽然不同的产品类型、不同的应用领域，功能的质量要求是有差异的，但一般来说，通用的功能质量要求如下。
·程序安装、启动正常，有相应的提示框、错误提示等。
·每项功能符合实际要求。
·每一项功能能正常运行、输出结果正确。
·能处理各种不正常的操作，对异常数据的输入可以进行提示、容错处理等。
·系统的界面清晰、美观。
·菜单、按钮操作正常、灵活，能处理一些异常操作。
·能接受正确的数据输入，如测试最大输入的文字数、单双字节、特殊符号等。
·数据的输出结果准确，格式清晰，可以保存和读取。
·功能逻辑清楚，符合使用者习惯。
·系统的各种状态按照业务流程而变化，并保持稳定。
·支持各种应用的环境。
·能配合多种硬件周边设备。
·软件升级后，能继续支持旧版本的数据。
·与外部应用系统的接口有效。
用户界面（UserInterface，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所示。
1.1.2测试目标
软件测试的目标就是根据质量要求，逐项确定、验证软件的实际表现，提供软件产品完整的质量信息；同时，为了帮助团队向客户提供一个高质量的软件产品，软件测试的目标就是更早地、尽可能地将软件产品或软件系统中所存在的各种问题找出来，并促进各类开发人员尽快地解决问题。
衡量测试目标的实现，就是通过测试覆盖率来衡量，通过对测试结果的分析，来明确产品质量要求、功能点或代码行（分支、条件等）的测试覆盖率。
例如：
·需求项和功能点覆盖率100%；
·代码行覆盖率95%。
但针对具体项目或具体产品的测试目标，不仅根据产品质量要求进一步明确测试目标，还要根据项目背景环境（如进度、预算等）、测试团队能力和现有的技术来确定测试目标。
例如，预算和进度限制测试的充分性，包括是否有足够的时间和资源去做兼容性测试、性能测试、安全性测试和可靠性测试等。
即使对某项特定的测试，能够测试到什么深度和广度，都需要因地制宜地考量。
因为从理论上讲，希望该有的测试都做了，每项测试都能做到100%，但实际项目中，进度、资源、能力等都有限制，不可能达到理想的目标，也没必要。
例如单元测试，理想的目标是百分之百覆盖代码行、分支和条件，但在实际项目中，可能将单元测试的目标定为代码行的覆盖率50%、60%或80%。
再举一个例子。
国际标准IEC61508把系统安全完整性分为0、1、2、3.和4等5个级别，而作为《铁路应用—通信、信令和处理系统—控制和保护系统用软件》欧洲标准50128:
2011，根据安全完整性，确定这一领域的软件系统的测试目标，即要所完成的测试.
测试的目标要有具体的指标，可以被度量，在测试执行结束之前或之后，能够判断测试目标是否被达到。
对各项质量要求的验证达到什么程度，能够给出数字描述的就尽量给出，从功能、性到安全性、兼容性等逐项给出明确的目标。
1.1.3基本的测试需求
先谈软件产品的功能测试需求。
在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。
例如，在讨论软件测试方法时，经常谈到黑盒方法的等价类划分、边界值分析、决策表、因果分析等方法，实际上这些只是功能测试的冰山一角，不仅要对输入空间进行验证，而且还要对用户界面、业务逻辑等进行验证。
总之，为了更全面地验证或评估软件功能的质量，需要在各个层次（单元、接口和系统）和各个方面（代码、文档和系统）进行测试。
也就是说，在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。
概括起来，功能测试的需求包括下列这些内容。
（1）单元之间调用、函数之间调用的各种参数的数据测试。
（2）系统的不同输入、结果输出的数据测试。
（3）数据库默认值、数据备份和恢复的测试。
（4）系统各个界面的验证。
（5）用户操作的易用性、用户体验的测试。
（6）单元逻辑、算法的测试，如通过代码评审发现算法问题。
（7）系统的业务逻辑验证，如端到端的测试。
（8）文档的验证，包括用户手册、安装文档逐行逐字的验证。
（9）各类关键代码的评审。
（10）功能的错误操作、异常操作的测试。
（11）功能一致性、多功能互操作的测试。
如果系统只是满足了功能要求，没有满足一些非功能特性（性能、安全性等）要求，还是不能满足客户的需求，不能获得用户的信任。
如某个网站功能（注册、信息查询等）齐全，也可以被访问，但是，每打开一个页面都需要两分钟。
结果，用户不能忍受，再也不会访问这个网站。
这种非功能性的需求满足和功能性的需求满足同样重要。
为了验证系统是否符合非功能特性的质量需求而进行的测试是系统非功能性测试。
非功能性测试需求覆盖软件系统的所有质量属性，包括性能、安全性、可靠性、兼容性、易维护性和可移植性等，它们存在对应的关系.
但每一类测试可能需要单独考虑，性能测试和兼容性测试、安全性测试都不一样，考虑的着眼点不一样。
例如，性能测试的目的之一就是为了验证当前系统实际所具有的性能。
如果实际性能达不到系统使用的需求，就需要改进设计，优化算法或程序代码，直至达到要求。
除了以上的目的之外，性能测试还可以进一步分为基准测试和规划测试，具体分析如下。
·对于新建立的系统，测试人员并不了解某些具体的性能指标，所以性能测试的首要任务就是获取这些指标的标准值，然后基于由这些标准值所设定的基准，进一步制定产品性能改进计划，也就是性能指标的变更需求计划。
·产品最终要被部署到运行环境中，在部署之前要进行规划，例如，根据用户的数量或数据负载来决定服务器的选型和数量，如果10万个用户需要4台双核CPU、内存4GB的服务器，如果是100万个用户是否需要16台双核CPU、内存8GB的服务器等。
这些规划的数据依赖于性能的规划测试。
·容量测试可以看做是性能测试的一种，或者认为系统的容量是系统的性能指标之一。
如某个Web站点可以支持多少个并发用户、网络在线会议系统中与会者的人数。
如果实际容量已满足要求，就能帮助用户建立对产品的信心。
如果不能满足要求，就应该寻求新的解决方案，以提高系统的容量。
若一时没有新的解决方案，就有必要在产品发布说明上明确容量上的限制，避免引起软件产品使用的纠纷。
概念：
（1）负载测试（LoadTest），也称压力测试（Stresstest）、强度测试。
负载测试通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，逐渐加载或一次性加载，长时间或超大负荷地运行软件，以测试系统的稳定性，并试图找出系统性能的瓶颈和异常的地方等。
通过负载测试，也可以确定系统的正常工作条件、极限条件等，并了解系统可靠性等，从而提高软件系统的可靠性、稳定性，减少系统的宕机时间。
（2）性能测试（Performancetest），通过测试确定系统运行特性的性能指标数据，如数据吞吐量、响应时间、CPU使用率等。
性能测试可以分为3类：
·验证测试，针对系统验证事先（如产品规格说明书）已定义的性能指标；
·基准测试，就是在系统标准配置下获得有关的系统指标数据，其测试结果应具有高度的一致性、标准性，可作为将来性能改进的基准线；
·规划测试，是为软件部署而进行的测试，即在多种特定的环境下，获得系统不同性能的指标，从而决定在系统部署时采用什么样的软、硬件配置。
（3）容量测试（Capacitytest），预先分析出反映软件系统应用特征的某项指标的极限值，了解该软件系统的承载能力或提供服务的能力。
系统在极限值状态下，主要功能还能正常运行。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载（数据量、事件规模等）。
容量测试可以看作负载测试和性能测试的组合。
（4）安全性测试（Securitytest），检验系统权限设置的有效性，防范非法入侵的能力，数据备份和恢复的能力等。
例如，测试人员可以假扮非法入侵者，试图采用各种办法突破系统防线，修改权限或存取权限之外的数据。
（5）容错测试（Recoverytest），检查软件在异常条件下是否具有防护性的措施或者恢复某种灾难性破坏的手段或能力。
容错性测试包括两个方面：
·输入异常数据或进行异常操作，以检验系统的保护性。
如果系统的容错性好，系统只给出提示或内部消化掉，不会导致系统出错甚至崩溃；
·灾难恢复性测试。
通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复或在指定时间间隔内恢复。
对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
容错测试和故障转移（fail-over）、可用性测试等有直接的关系。
1.2项目的测试需求
在掌控了软件项目的背景，了解了产品的质量要求和软件测试的基本需求之后，同时，测试人员也会阅读相关软件需求文档，参与需求评审。
在这些基础之上，可以进行测试的需求分析，即包括下面这些工作：
·明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试；
·知道哪些测试目标优先级高、哪些目标优先级低；
·要完成哪些相应的测试任务才能确保目标的实现。
然后才能估算测试的工作量，安排测试的资源和进度。
测试需求分析是测试设计和开发测试用例的基础，测试需求分析得越细，对测试用例的设计质量的帮助越大，详细的测试需求还是衡量测试覆盖率的主要依据。
只有在做好测试需求的基础上，才能规划项目所需的资源、时间以及所存在的风险等。
1.2.1测试需求分析的基本方法
无论是功能测试，还是非功能性测试，其测试需求的分析都有以下两个基本的出发点。
（1）从客户角度进行分析：
通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。
（2）从技术角度分析：
通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。
如果有完善的需求文档（如产品功能规格说明书），那么功能测试需求可以根据需求文档，再结合前面分析和自己的业务知识等，比较容易确定功能测试的需求。
如果缺乏完善的需求文档，就需要借助启发式分析方法，从系统业务目标、结构、功能、数据、运行平台、操作等多方面进行综合分析，了解测试需求，并通过和用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。
·业务目标：
所有要做的功能特性都不能违背该系统要达到的业务目标，多问问如何更好地达到这些业务目标，如何验证是否实现这些业务目标？
·系统结构：
产品是如何构成的？
系统有哪些组件、模块？
模块之间有什么样的关系？
有哪些接口？
各个组件又包含了哪些信息？
·系统功能：
产品能做哪些事、处理哪些业务？
处理某些业务时由哪些功能来支撑、形成怎样的处理过程？
处理哪些错误类型？
有哪些UI来呈现这些功能？
·系统数据：
产品处理哪些数据？
最终输出哪些用户想要的结果？
哪些数据是正常的？
又有哪些异常的数据？
输入数据如何被转化、传递的？
这中间有哪些过渡性数据？
输出数据格式有什么要求？
输出数据存储在哪里？
·系统运行的平台：
系统运行在什么硬件上？
什么操作系统？
有什么特殊的环境配置？
是否依赖第三方组件？
·系统操作：
有哪些操作角色？
在什么场景下使用？
不同角色、场景有什么不同？
有哪些是交集的？
上面这些分析，更多是从测试对象本身来进行分析，还包括用户角色分析、用户行为分析、用户场景分析等。
我们还可以通过如下一些其他方面的资料，帮助我们更好地完成测试的需求分析。
·对竞争产品进行对比分析，明确测试的重点。
·质量存在哪些风险，包括安全性漏洞等。
·对过去类似产品或本产品上个版本所发现的缺陷进行分析，总结缺陷出现的规律，看看有没有漏掉的测试需求。
·在易用性、用户体验上有什么特别的需求需要验证？
·管理者或市场部门有没有事先特定的声明？
·有没有相应的行业规范、特许质量标准？
测试需求分析过程，可以从质量要求出发，来展开测试需求分析，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。
也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求形成已分解的测试项，结合质量要求，这些测试项再扩展为测试任务，这些测试任务包括了具体的功能性测试任务和非功能性测试任务。
在整理测试需求时，需要分类、细化、合并并按照优先级进行排序，形成测试需求列表，
1.2.2测试需求的分析技术
在软件测试需求分析过程中，可以采用有效的问题分析技术来帮助我们提高测试需求的有效性和工作效率。
从测试需求分析来看，我们力求通过与各相关干系人的沟通，收集足够的、有价值的信息或数据，借助下列途径来达到良好的分析效果。
（1）通过提炼，抓住主要线索，或作为整体来进行分析，使测试需求分析简单化。
（2）通过业务需求或功能层次的整理，使测试需求分析结构化、层次化。
（3）通过绘制业务流程图、数据流程图等，使测试需求分析可视化。
（4）通过类比、隐喻，加强用户需求的理解，更好地转化为测试需求。
在测试需求的分析中，能采用静态分析技术与动态分析技术、定性分析技术和定量分析技术，其中以静态分析技术、定性分析技术为主，但产品性能、用户行为分析和用户体验分析等也常采用定量分析技术。
有时，会采用综合分析技术、模型分析技术等。
在测试需求分析时，产品本身往往处于需求分析和设计过程中，静态分析技术是常用的分析技术。
静态分析技术包括如下。
·通过系统建模语言（SysML）的需求图，可以更好地分析各项需求之间的关系，比较容易确定测试需求的边界。
·通过状态图、活动图更容易列出的测试场景，了解状态转换的路径和条件，哪些是重要测试场景等。
·实体关系图可以明确测试的具体对象（实体）及其之间的关系，进行相关分析。
·鱼骨图法、思维导图等，有一个清晰的分析思维过程，迅速展开测试需求，随时补充测试需求等。
·代码复杂度静态分析工具，代码越复杂，测试的投入也需要越多。
·还可以用一些普通工具，如检查表。
·脑力激荡法，让大家发散思维，相互启发，让任何测试需求不会被错过。
而动态分析技术应用相对少一些，但在一些应用场景的分析中还是有帮助的，如前面提到的竞争对手产品分析，这是一种动态分析技术，通过操作竞争对手产品，全面了解相同业务的需求，在功能、逻辑、界面等各个方面深入挖掘测试需求。
同样道理，需求原型分析技术——基于开发已构建的原型来进行测试需求分析，更能直观地理解产品，进而有助于测试需求的分析，达到类似效果。
可以采用仿真技术、模拟技术、角色扮演等手段，也能帮助测试需求的分析。
1.2.3功能测试范围分析
在分析测试范围时，一般先进行功能测试的范围分析，然后再进行非功能性测试的范围分析。
对于功能测试，可以借助业务流程图、功能框图等来帮助我们进行测试的需求分析。
在面向对象的软件开发中，也可借助UML用例图、活动图、协作图和状态图来进行功能测试范围分析。
这里通过前述两个实例简单地说明如何做功能测试的需求分析。
1．GoogleTalk客户端软件
基本功能测试需要根据具体功能的逻辑、黑盒测试方法等进行测试用例的设计，并考虑用户的习惯思维，把功能划分成如下若干个模块。
·登录与注销。
·主面板功能设置。
·文字聊天。
·语音聊天。
·用户设置。
·消息/呼叫的提示。
·文件与语音邮件发送。
然后按模块分别进行分析，但同时也要明确系统的边界，以及各个模块之间是否存在关联关系、互操作性等。
让我们首先快速分析一下各个模块的测试需求。
·安装与卸载。
安装的界面检查、正常安装、中途退出、操作逻辑检查等。
卸载后检查用户数据是否被删、有无遗留文件、对其他应用程序运行是否产生影响。
·注册、登录与注销。
用户注册Google账号，在客户端登录，其他好友能看到其登录后上线和注销后下线等相关状态信息。
·好友管理。
可以方便地添加、删除好友，GoogleTalk会自动将最常联系的好友排在列表的最上面，也可以用查找框快速地查找好友。
·文字聊天。
聊天窗口分菜单、消息显示、消息输入几个部分，Talk的功能相对简单，重点要求是方便地在用户之间传递消息，以及不同输入语言的正确显示。
·语音通话。
分为呼叫、通话、结束三个阶段。
要求控制反应灵敏，语音清晰连续。
·邮件管理。
Talk和Gmail做到了很好的整合，聊天记录也可以保存在Gmail邮件服务器上，在客户端我们重点只看邮件提醒的功能。
2．Google日历的测试范围
Google日历的功能可以分为4部分——日历页面显示、事件（包括各种活动、会议和待办事项等）添加功能、搜索功能和选项设置，如图2-3所示。
测试关键点在于确保Google日历的组件能够准确、安全、无错误地实现事件定制及浏览、预约提醒、日历共享、个性化设定等功能。
而对某个具体功能的测试，其测试范围一般包括输入、编辑、查询、显示等。
如在数据输入方面，要测试最大输入的文字数、双字节文字、特殊符号等各种情况，还要测试输入区域支持复制、粘贴等操作。
对于Web的功能分析，也可以从页面帧结构、布局来进行分析。
例如Google日历的显示区域设定为以下4个子区域。
·顶部是搜索框和协作分享。
·左边区域，快速创建事
升级会员 