在进行测试用例设计之前，我们通常需要对需求文档进行分析，甚至在需求评审阶段从测试角度给出建议。通过需求分析，不仅可以输出测试点，也可以发现需求中存在的问题。

业务角度和技术角度

测试需求的分析可以从两个不同的角度进行分析。

从业务角度进行分析：通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。

从技术角度分析：通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。

如果有完善的需求文档（如产品功能规格说明书），那么测试需求可以根据需求文档，再结合前面分析和自己的业务知识、测试工作经验等，比较容易确定功能测试的需求。

启发式分析

如果缺乏完善的需求文档，就需要借助启发式分析方法，从系统业务目标、结构、功能、数据、运行平台、操作等多方面进行综合分析，了解测试需求，并通过和用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。要获得良好的测试需求，就是善于提问，从不同的角度去向用户、业务人员、产品经理、开发人员等提问，获取更多的一手信息。

业务目标：所有要做的功能特性都不能违背该系统要达到的业务目标，多问问如何更好地达到这些业务目标，如何验证是否实现这些业务目标？

系统结构：产品是如何构成的？系统有哪些组件、模块？模块之间有什么样的关系？有哪些接口？各个组件又包含了哪些信息？

系统/业务功能：产品能做哪些事、处理哪些业务？处理某些业务时由哪些功能来支撑、形成怎样的处理过程？处理哪些错误类型？有哪些UI来呈现这些功能？

业务数据：产品处理哪些数据？最终输出哪些用户想要的结果？哪些数据是正常的？又有哪些异常的数据？输入数据如何被转化、传递的？这中间有哪些过渡性数据？输出数据格式有什么要求？输出数据存储在哪里？

系统运行的平台：系统运行在什么硬件上？什么操作系统？有什么特殊的环境配置？是否依赖第三方组件？

系统操作：有哪些操作角色？在什么场景下使用？不同角色、场景有什么不同？有哪些是交集的？

可以通过如下一些途径，帮助我们更好地完成测试的需求分析。

对竞争产品进行对比分析，明确测试的重点。

质量存在哪些风险，包括安全性漏洞等。

对过去类似产品或本产品上个版本所发现的缺陷进行分析，总结缺陷出现的规律，看看有没有漏掉的测试需求。

在易用性、用户体验上有什么特别的需求需要验证？

管理者或市场部门有没有事先特定的声明？

有没有相应的行业规范、特许质量标准？

（一般进行需求分析，会考虑到 需求的逻辑是否正确？规则限制是否有明确？是否有非功能需求需要考虑？是否有隐性需求需要考虑？是否与外部系统有交互？是否会影响到其他模块或者其他功能？是否存在数据兼容需要处理？是否存在版本兼容问题需要处理？有哪些异常场景需要考虑？涉及到哪些系统角色？）

需求分析技术

1、可以画流程图、状态图、业务流程图，数据流程图，实体关系图，UML图

2、使用思维导图，头脑风暴方法发散思维。

测试需求分析过程，可以从源头——质量要求出发展开，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求确定对应的测试项。

功能需求分析

在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证，即业务规则、业务数据等多个方面的验证。总之，为了更全面地验证或评估软件功能的质量，开发者需要在各个层次（单元、接口和系统）和各个方面（代码、文档和系统）进行测试。也就是说，在功能测试中，不仅要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。概括起来，功能测试需求，通常包括下列这些内容。

① 系统各个功能界面的验证。

② 系统端到端的业务逻辑验证，相当于借助业务把功能串起来进行测试。

③ 功能的一致性、交互性（多功能互操作）的测试，如系统应用中设定日期、时间，前后一致性的验证。

④ 面向接口参数及其组合场景的功能测试。

⑤ 系统的不同输入、结果输出的业务数据测试。

⑥ 功能的错误操作、异常操作的测试（属于负面测试）。

⑦ 功能实现用到的算法验证，有时需要建模或人工代码评审。

⑧ 数据库默认值、数据备份和恢复的测试。

⑨ 用户操作的易用性、用户体验，往往结合功能测试同时进行。

⑩ 功能相关的文档验证，如用户手册的验证。

在功能测试上，不仅要考虑业务数据，还要考虑业务规则，如上传文件限制大小，哪些数据是必填哪些是选填？

非功能性需求分析

为了验证系统是否符合非功能特性的质量需求而进行的测试是系统非功能性测试。非功能性测试需求主要涉及性能、安全性、可靠性、兼容性、易维护性和可移植性等，测试需求和质量属性存在对应的关系。

需要根据项目或产品的特点，来分析需要考虑哪些非功能性需求。

非功能性测试就需要深入架构分析，才能更好地把握测试范围和测试方法。

除此之外，还有其他一些因素的影响，如项目的周期性和依赖性等。

可靠性测试

可用性指标一般要求达到4个或5个“9”，即99.99% 或99.999%。

兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软、硬件的兼容，就软件兼容来说，不仅要测试系统自身的版本兼容、用户已有数据的兼容，还要测试与操作系统、应用平台或浏览器、和其他第三方系统以及第三方数据的兼容性。操作系统包括Windows、Mac、Solaris、Linux等，浏览器包括IE、FireFox、Chrome和Safari等，如表6-4所示，形成环境组合矩阵，明确兼容性测试需求

兼容性测试，不仅要覆盖软件系统之间兼容、和第三方系统之间的兼容，还需考虑同一个系统不同版本之间的兼容，特别是用户数据的兼容，数据兼容性测试是重中之重，因为对用户来说，数据更有价值。客户端软件的不同版本和服务器端最新版本的兼容，一般来说，服务器上部署的都是最新版本，但客户端就不一定都升级了。

还有其他非功能性测试。

参考《全程软件测试》第三版。