怎样依据需求文档进行测试设计？

测试人员通过批判性阅读需求文档，重新组织信息，加深对软件产品的理解，由此他可以建立一些测试模型和测试想法。

1. 测试模型

• 功能列表

功能列表就是测试人员将从需求文档中识别出功能点根据它们的隶属关系构造出的一份脉络清晰、逻辑合理的树形结构层次列表。

功能列表不但帮助测试人员更好地梳理需求，还为功能测试的测试用例设计提供了基础。

• 质量特性列表

质量特性列表就是测试人员通过阅读需求文档所识别出的明确的或隐含的质量特性（如能力、安全性、兼容性等）列表。

质量特性列表为质量特性测试提供基础。

• Google ACC

测试人员可以用Google ACC模型来组织属性、功能、组件这三方面的信息，从而洞察产品特性和产品元素之间的联系。

它为进一步的测试设计奠定了基础。

• 启发式测试策略模型HTSM

HTSM是功能列表、质量特性列表和Google ACC的超集，它将思维导图形式的HTSM作为信息架构，将需求文档的产品元素、项目过程、质量标准、测试技术等信息逐步填入其中。

测试人员可以通过HTSM模型产生许多好的测试想法。

• 输入与输出模型

测试人员从需求文档中获取软件产品的输入、输出信息，据此建立输入与输出模型，以梳理输入和输出之间的关系。

测试人员通过建立输入输出模型检查是否遗漏了重要的输入和输出参数，是否完整地思考了输入检查、异常处理、错误报告等问题。

• 系统生态图

系统生态图描述了系统部署的拓扑结构、与外部环境的通信方式和子系统之间的联系。

与需求文档所提供的相似的图不同，作为测试模型的系统生态图是从测试视角绘制并且加入不相应的测试想法。

• 实体关系模型

实体关系模型描述了一组业务对象的关系。

测试人员通过实体关系模型不但能够获得测试想法，还可以检查模型中实体和关系的一致性。

• 状态机模型

状态机模型描述软件状态、状态变迁以及在特定状态下的约束规则。

测试人员通过状态机模型可以更好地理解软件产品的细节，从而发现一些业务设计上的深层次问题。

1. 测试想法

测试人员可以针对需求文档中每一项陈述设计攻击性的测试用例，尝试让软件行为不符合需求文档的陈述。

• 利用条件分析设计测试用例

例如，对于功能需求“在用户键入单词时，显示相应的查询建议”，测试人员可以设计一组测试：

如果用户在键入单词时，服务器没有返回查询建议，用户会观察到什么？如果用户键入了没有意义的字符串，用户会观察到什么？……

• 改变陈述中的参数值

例如：针对功能需求“能够打开、编辑并保存服务器上的共享文档”，测试人员可以改变这个论述中隐含的几个参数（包括网络带宽、文档尺寸、被编辑的内容、共同编辑文档的人数等）设计测试用例，

• 情景测试

测试人员设计测试用例同时覆盖多个模块、功能、情景以测试当前陈诉和与之相关的陈述有无不一致。

测试人员可以参考以下模板来描述测试想法。

“使用<资源>，探索<对象>，以求发现<信息>”。

总之，测试人员通过阅读需求文档，可以建立各种测试模型帮助自己更加理解软件产品，可以针对文档中的陈述来设计测试用例。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。