下载掌阅APP，畅读海量书库
立即打开
在掌控了软件项目的背景，了解了产品的质量要求和软件测试的基本需求之后，同时，测试人员也会阅读相关软件需求文档，参与需求评审。在这些基础之上，可以进行测试的需求分析，即包括下面这些工作：
● 明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试；
● 知道哪些测试目标优先级高、哪些目标优先级低；
● 要完成哪些相应的测试任务才能确保目标的实现。
然后才能估算测试的工作量，安排测试的资源和进度。测试需求分析是测试设计和开发测试用例的基础，测试需求分析得越细，对测试用例的设计质量的帮助越大，详细的测试需求还是衡量测试覆盖率的主要依据。只有在做好测试需求的基础上，才能规划项目所需的资源、时间以及所存在的风险等。
无论是功能测试，还是非功能性测试，其测试需求的分析都有以下两个基本的出发点。
（1）从客户角度进行分析：通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。
（2）从技术角度分析：通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。
如果有完善的需求文档（如产品功能规格说明书），那么功能测试需求可以根据需求文档，再结合前面分析和自己的业务知识等，比较容易确定功能测试的需求。如果缺乏完善的需求文档，就需要借助启发式分析方法，从系统业务目标、结构、功能、数据、运行平台、操作等多方面进行综合分析，了解测试需求，并通过和用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。
● 业务目标：所有要做的功能特性都不能违背该系统要达到的业务目标，多问问如何更好地达到这些业务目标，如何验证是否实现这些业务目标？
● 系统结构：产品是如何构成的？系统有哪些组件、模块？模块之间有什么样的关系？有哪些接口？各个组件又包含了哪些信息？
● 系统功能：产品能做哪些事、处理哪些业务？处理某些业务时由哪些功能来支撑、形成怎样的处理过程？处理哪些错误类型？有哪些UI来呈现这些功能？
● 系统数据：产品处理哪些数据？最终输出哪些用户想要的结果？哪些数据是正常的？又有哪些异常的数据？输入数据如何被转化、传递的？这中间有哪些过渡性数据？输出数据格式有什么要求？输出数据存储在哪里？
● 系统运行的平台：系统运行在什么硬件上？什么操作系统？有什么特殊的环境配置？是否依赖第三方组件？
● 系统操作：有哪些操作角色？在什么场景下使用？不同角色、场景有什么不同？有哪些是交集的？
上面这些分析，更多是从测试对象本身来进行分析，还包括用户角色分析、用户行为分析、用户场景分析等。我们还可以通过如下一些其他方面的资料，帮助我们更好地完成测试的需求分析。
● 对竞争产品进行对比分析，明确测试的重点。
● 质量存在哪些风险，包括安全性漏洞等。
● 对过去类似产品或本产品上个版本所发现的缺陷进行分析，总结缺陷出现的规律，看看有没有漏掉的测试需求。
● 在易用性、用户体验上有什么特别的需求需要验证？
● 管理者或市场部门有没有事先特定的声明？
● 有没有相应的行业规范、特许质量标准？
测试需求分析过程，可以从质量要求出发，来展开测试需求分析，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求形成已分解的测试项，结合质量要求，这些测试项再扩展为测试任务，这些测试任务包括了具体的功能性测试任务和非功能性测试任务。在整理测试需求时，需要分类、细化、合并并按照优先级进行排序，形成测试需求列表。
在软件测试需求分析过程中，可以采用有效的问题分析技术来帮助我们提高测试需求的有效性和工作效率。从测试需求分析来看，我们力求通过与各相关干系人的沟通，收集足够的、有价值的信息或数据，借助下列途径来达到良好的分析效果。
（1）通过提炼，抓住主要线索，或作为整体来进行分析，使测试需求分析简单化。
（2）通过业务需求或功能层次的整理，使测试需求分析结构化、层次化。
（3）通过绘制业务流程图、数据流程图等，使测试需求分析可视化。
（4）通过类比、隐喻，加强用户需求的理解，更好地转化为测试需求。
在测试需求的分析中，能采用静态分析技术与动态分析技术、定性分析技术和定量分析技术，其中以静态分析技术、定性分析技术为主，但产品性能、用户行为分析和用户体验分析等也常采用定量分析技术。有时，会采用综合分析技术、模型分析技术等。
在测试需求分析时，产品本身往往处于需求分析和设计过程中，静态分析技术是常用的分析技术。静态分析技术包括如下。
● 通过系统建模语言（SysML）的需求图，可以更好地分析各项需求之间的关系，比较容易确定测试需求的边界。
● 通过状态图、活动图更容易列出的测试场景，了解状态转换的路径和条件，哪些是重要测试场景等。
● 实体关系图可以明确测试的具体对象（实体）及其之间的关系，进行相关分析。
● 鱼骨图法、思维导图等，有一个清晰的分析思维过程，迅速展开测试需求，随时补充测试需求等。
● 代码复杂度静态分析工具，代码越复杂，测试的投入也需要越多。
● 还可以用一些普通工具，如检查表。
● 脑力激荡法，让大家发散思维，相互启发，让任何测试需求不会被错过。
而动态分析技术应用相对少一些，但在一些应用场景的分析中还是有帮助的，如前面提到的竞争对手产品分析，这是一种动态分析技术，通过操作竞争对手产品，全面了解相同业务的需求，在功能、逻辑、界面等各个方面深入挖掘测试需求。同样道理，需求原型分析技术——基于开发已构建的原型来进行测试需求分析，更能直观地理解产品，进而有助于测试需求的分析，达到类似效果。可以采用仿真技术、模拟技术、角色扮演等手段，也能帮助测试需求的分析。
在分析测试范围时，一般先进行功能测试的范围分析，然后再进行非功能性测试的范围分析。对于功能测试，可以借助业务流程图、功能框图等来帮助我们进行测试的需求分析。在面向对象的软件开发中，也可借助UML用例图、活动图、协作图和状态图来进行功能测试范围分析。这里通过前述两个实例简单地说明如何做功能测试的需求分析。
基本功能测试需要根据具体功能的逻辑、黑盒测试方法等进行测试用例的设计，并考虑用户的习惯思维，把功能划分成如下若干个模块。
● 登录与注销。
● 主面板功能设置。
● 文字聊天。
● 语音聊天。
● 用户设置。
● 消息/呼叫的提示。
● 文件与语音邮件发送。
然后按模块分别进行分析，但同时也要明确系统的边界，以及各个模块之间是否存在关联关系、互操作性等。让我们首先快速分析一下各个模块的测试需求。
● 安装与卸载。安装的界面检查、正常安装、中途退出、操作逻辑检查等。卸载后检查用户数据是否被删、有无遗留文件、对其他应用程序运行是否产生影响。
● 注册、登录与注销。用户注册Google账号，在客户端登录，其他好友能看到其登录后上线和注销后下线等相关状态信息。
● 好友管理。可以方便地添加、删除好友，Google Talk会自动将最常联系的好友排在列表的最上面，也可以用查找框快速地查找好友。
● 文字聊天。聊天窗口分菜单、消息显示、消息输入几个部分，Talk的功能相对简单，重点要求是方便地在用户之间传递消息，以及不同输入语言的正确显示。
● 语音通话。分为呼叫、通话、结束三个阶段。要求控制反应灵敏，语音清晰连续。
● 邮件管理。Talk 和Gmail做到了很好的整合，聊天记录也可以保存在Gmail邮件服务器上，在客户端我们重点只看邮件提醒的功能。
Google日历的功能可以分为4部分——日历页面显示、事件（包括各种活动、会议和待办事项等）添加功能、搜索功能和选项设置，如图2-3所示。测试关键点在于确保Google日历的组件能够准确、安全、无错误地实现事件定制及浏览、预约提醒、日历共享、个性化设定等功能。而对某个具体功能的测试，其测试范围一般包括输入、编辑、查询、显示等。如在数据输入方面，要测试最大输入的文字数、双字节文字、特殊符号等各种情况，还要测试输入区域支持复制、粘贴等操作。
图2-3 Google日历的功能框图
对于Web的功能分析，也可以从页面帧结构、布局来进行分析。例如Google日历的显示区域设定为以下4个子区域。
● 顶部是搜索框和协作分享。
● 左边区域，快速创建事件、日历、我的日历和其他日历等。
● 右边上面区域，按日、周、月等方式浏览活动，打印以及设置。
● 右边大区域就是日历显示和操作的主区域。
如图2-4所示。在显示上，要测试日历和各个分类框架显示格式是否正确，排序是否正确，文字标记和超链接是否可以打开和跳转成功。重点要测试右边的主显示和操作区域，要求在输入很多且很长的待办事项的情况下，显示内容可以自动换行，字符没有乱码和截断，相互之间的日、周、月、年表单之间相互跳转没有问题。
图2-4 Google日历的显示区域分析
在进一步进行功能分析后，可以了解更具体的功能测试范围。
（1）登录，是最基本的功能需求，对用户身份进行合法性验证，对各种登录模式的安全性验证，包括Cookie和Session的有效期验证。
（2）活动定制功能。
● 定制会议后，能正确显示。
● 循环会议可以成功指定与显示。
● 会议可以被成功修改。
● 跨日会议的准确性，以及夏令时的准确显示。
● 与其他日历的兼容，如导入/导出数据是否正常。
（3）提醒功能。根据活动的设置，系统能够在活动之前发送提醒到Google alk、电子邮件地址、移动设备等。
（4）共享功能。可以根据用户的权限设置来决定是否让他人看到自己的日历。
（5）时间表能将用户所注意或关心事件的时间和用户的个人行事整合起来，直接了解效率手册中的重要活动，并可查看朋友的效率手册、俱乐部的效率手册、运动队的比赛日程以及其他更多内容。按照合并视图或栏视图方式显示。
（1）用户登录，登录的用户名、口令能否保存？口令忘了，能否找回来？允许登录失败的次数是否有限制？口令字符有没有严格要求（如长度、大小写、特殊字符）？是否硬性规定经过一段时间后必须改变口令？
（2）站点地图和导航条。每个网站都需要站点地图，让用户一看就能了解网络内容，而且当新用户在网站中迷失方向时，站点地图可以引导用户进行浏览，找到所想访问的内容。需要验证站点地图每一个链接是否存在而且正确，有没有涵盖站点上所有内容的链接。是否每个页面都有导航条？ 导航条是否一致、直观？
（3）链接，去正确地方，即链接地址正确，并能显示正常、自然，不要给人突然的感觉。
（4）表单，各项输入是必需的、合理的，各项操作正常，对于错误的输入有准确、适当的提示，并完成最后的提交。提交后，返回提交内容的显示，使用户放心。如用户通过表单进行注册，能输入用户名、口令、地址、电话、爱好等各种信息，当格式、内容不对或不符时，及时给予提示，在用户提交信息后，进一步检查各项内容的正确性，然后写入数据库、返回注册成功的消息。
（5）数据校验，根据业务规则和流程对用户输入数据进行校验，是许多系统不可缺少的。通过列表选择、规则提示或在线帮助，能很好解决这问题。
（6）Cookie，在Web应用中到处可见，用来保存用户注册、访问和其他本地客户端信息，所保存的信息要加密，并能及时更新。Cookie被删除了，能被重建。
（7）Session，是否安全、稳定，而且占用较少的资源。
（8）SSL、防火墙等的测试。使用了SSL，浏览器地址栏中URL的“http:”就变为“https:”了，服务器的连接端口号则由80变为433，应用程序接口API也要和页面保持一致。防火墙支持更多的设置，包括代理、验证方式、超时等。
（9）接口测试，与数据库服务器、第三方产品接口（如电子商务网站信用卡验证）的测试，包括接口错误代号和列表。
● 过分地使用粗体字、大字体和下画线可能会让用户感到不舒服。
● 背景颜色使用不当，虽然美观，但不易阅读，内容阅读才是最重要的。通常来说，文字和背景对比较大比较适宜，背景浅淡则文字采用深颜色；背景深黑则文字采用亮色。对比要采用适当，和谐往往更容易被人接受。
● 每一张图片都是必要的，位置和大小合适，采用了JPG和GIF格式，而且和文字吻合。
● 不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
● 表格显示是否清晰，必要的数据能否在一个页面显示？翻页、水平移动是否流畅等？表格里的文字是否能折行且保持内容完整，或者使用表格栏宽度设置协调？
对于非功能性的系统测试，主要目的是验证软件系统的整体性能等是否满足其产品设计规格所指定的要求，涉及非功能性的质量需求有系统性能、安全性、兼容性、扩充性等的测试，可能还会涉及第三方产品的集成测试。对于每一个应用软件系统，非功能特性的质量需求都是存在的，这类测试需求会因不同的项目类型差异比较大，这些需求的程度、重要性不同，因此要求为非功能性测试需求设置优先级，下面就做一个简单的分析。
● 纯客户端软件，如字处理软件、下载软件、媒体（音频/视频）播放软件等在系统测试要求上是最低的，对性能、容错性、稳定性等有一定的要求，如占用较少的系统资源（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 a Service，SaaS）的应用模式，对软件运行的服务质量（QoS）也有很高的要求，需要支持7x24不间断的服务。对于这样的Web服务软件，非功能性测试的需求涉及性能、安全性、容错性、兼容性、可用性、可伸缩性等各个方面。
服务级别协议（SLA）指定了最低性能要求，以及未能满足此要求时必须提供的客户支持级别和程度。与 QoS 要求一样，服务级别要求源自业务要求，对要求的测试条件及不符合要求的构成条件均有明确规定，并代表着对部署系统必须达到的整体系统特性的担保。服务级别协议被视为合同，所以必须明确规定服务级别要求。如表2-3所示。下面侧重性能、可用性、安全性和兼容性的测试需求讨论，而对其他非功能性属性就不进行过多的讨论，这并不意味着这些属性就没有测试需求，例如可维护性（即系统维护的容易程度）的测试需求也是很多的，包括系统监视、日志文件、故障恢复、数据更新和备份等测试。
表2-3 影响QoS要求的系统特性
性能测试分为服务器端性能测试和客户端性能测试，需要考虑“哪些负载（如并发用户数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天等）的组合情况下进行压力测试。
压力测试 往往和容量测试结合起来，以测试系统的限制和故障恢复能力，如测试应用系统在长期高负载下会不会崩溃、在什么情况下会崩溃，并确定系统能承受的最大负载（如最大连接数、并发用户数等）。
可伸缩性 通常要求在对部署体系结构的设计不做修改的情况下增加资源以满足系统增加的容量，从而使系统容易支持来自现有用户或扩大的用户群体的额外负载。可伸缩性测试也可以归为性能测试，如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两倍或接近两倍。如果是，系统就具有良好的可伸缩性。
可用性是指系统正常运行的能力或程度，在一定程度上也是系统可靠性的表现，可用性测试就基本上等同于可靠性测试。可用性一般用正常向用户提供软件服务的时间占总时间的百分比来表示，即：
可用性 = 正常运行时间 /（正常运行时间 + 非正常运行时间）× 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%。
可用性测试 就比较困难，不可能有足够的时间来进行测试，就只能采用空间换时间的办法，例如在高负载情况下进行为期一周或一个月的测试，以判断其可靠性。其次，就是对提高可靠性的措施进行测试，如故障转移的测试。
容错处理 系统能够处理异常、错误操作而不至于系统崩溃，从而能够提供系统的可用性。例如，业务处理过程中中断事务时，系统能保存当前状态，程序能自动或提示重连，或在某个时刻可以恢复操作。
安全性是一个复杂的主题，涉及部署系统的各个级别。安全性要求分析，包括确定可能的或潜在的各类安全威胁和找到处理这些威胁的策略，即：
● 确定关键（有形的和无形的）资产，并找到对这些资产的威胁；
● 确定使组织暴露于可能带来风险威胁的薄弱环节；
● 开发减轻组织风险的安全规划。
分析安全要求应由软件组织的各方面风险承担者参与，包括管理员、业务分析师和信息技术人员等。通常，组织会指定一个安全结构设计师来领导安全措施的设计和实现。
安全性测试就是全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。所以，安全性测试的需求点还是比较多的，任务还是比较重的，特别是对复杂的系统。这里举一些常见的需求点：
● 各种登录模式的安全性验证、对口令各种要求的测试；
● 用户权限的验证；
● 所有入口的验证，即对数据输入的验证；
● Cookie和Session的有效期验证等特殊机制的验证；
● 数据访问权限设置验证，如服务器上的目录设置；
● 敏感数据加密、数据存储安全性的验证；
● 验证系统的日志文件是否得到保护；
● 在异常条件下操作、错误操作，测试软件以表明不会因可能的单个或多个输入错误而导致不安全状态；
● 其他各种安全漏洞（如跨站点攻击、SQL注入等）的检查。
兼容性测试需求 是指明确要测试的兼容环境，考虑软、硬件的兼容，就软件兼容来说，不仅要测试系统自身的版本兼容、用户已有数据的兼容，还要测试与操作系统、应用平台或浏览器、和其他第三方系统以及第三方数据的兼容性。操作系统包括Windows、Mac、Solaris、Linux等，浏览器包括IE、FireFox、Chrome和Safari等，如表2-4所示，形成环境组合矩阵，更能明确兼容性测试需求。兼容性测试的组合不仅仅局限在操作系统、浏览器这两个因素，还有其他因素，如：
● 32位、64位CPU；
● 手机平台 Android、iOS、Windows Phone；
● 支持不同的Internet连接速度；
● 是否支持SSL。
表2-4 兼容性测试的环境组合
兼容性测试需要根据被测试应用的具体情况决定。像Google日历应用，支持移动平台是必须的，而且日历有较多的个人信息，需要支持SSL，但32位、64位CPU对其没有什么影响，不需要考虑。而对于像Google Talk这样客户端应用程序，就不需要考虑浏览器支持，而且不同的操作系统（Windows、Mac OS、iOS、Android等）有不同的应用程序，需要单独处理，只是每类操作系统还有多个版本，如iOS有iOS 5、iOS 6和iOS 7等。
兼容性测试，不仅是软件系统之间兼容、和第三方系统之间的兼容，而且还需考虑系统版本之间的兼容，特别是用户数据的兼容，数据兼容测试也是重要的需求。例如：
● 不同客户端软件（如Google Talk）版本和服务器系统的兼容，服务器上一般部署的都是最新版本，但客户端就不一定；
● 新版本的软件能够兼容以前各种版本产生的历史数据，确保数据向上兼容，如Word 2013 能够正常打开之前多个Word版本（如Word 2003，Word 2007等）产生的用户.doc文件。