如何做需求分析

软件测试凡哥

于 2023-07-21 14:55:24 发布

阅读量207

点赞数 2

分类专栏：软件测试经验分享文章标签：需求分析功能测试软件测试程序人生测试工具软件测试工程师接口测试

本文链接：https://blog.csdn.net/m0_70618214/article/details/131851988

版权

软件测试同时被 2 个专栏收录

320 篇文章 32 订阅

订阅专栏

经验分享

225 篇文章 15 订阅

订阅专栏

本文阐述了测试人员在产品需求中的重要角色，强调了挖掘需求问题对于提升产品质量和提高项目效率的核心价值。具体思路包括检查需求描述的准确性、完整性，需求覆盖度的全面性，预期结果的明确性，需求合理性，用户体验和可行性等方面。同时，提出了在审查需求时应注意的事项和版本管理问题。

摘要由CSDN通过智能技术生成

核心理念：

首先需要想清楚一个问题：作为一个测试，有没有把需求当作产品中的一个组成部分，然后尽到一个测试的责任与义务？只有建立这样的意识和规则，才能够把挖掘需求的事情做好，否则始终抱着“需求是产品负责，我不关心”的心态，那接下来的事情就无法进行。

主要目的：

挖掘需求问题，有两大核心目的：

1. 提升产品质量通过挖掘需求中的问题，解决需求中的问题，完善产品需求，从而完善产品，提升产品的质量。

2. 提高项目效率通过挖掘需求中的问题，尽早查漏补缺、解决分歧，避免问题遗留到项目中后期，导致返工、进度delay等风险，从而提高项目的效率。

具体思路：

由于专业度上的差别，测试同学在挖掘产品需求问题时，确实存在一定的困难。但基于以往的经验，还是能够总结出一套思路，具体可以从以下几个角度进行：1. 需求描述层面的问题：

a) 错别字、病句等

需求文档中难免会存在一些错别字、病句等文案错误，此类问题我们有必要给产品同学指正（但不要带着嘲讽的心态），因为有些时候这种错误一样会对产品、需求理解造成影响，例如：“未进行”和“为进行”，一字之差，谬之千里。又如：“账号”和“帐号”，用字用户提示中，影响产品的专业度问题。

b) 描述存在歧义

需求描述的含义必须明确，描述存在二义性甚至多义性的问题，比较严重，可能会导致多方理解的不一致，导致开发、测试等团队的产出物不正确，进而返工，增加项目成本。我们需要与产品确认，并要求产品进行更正。例如：分身添加两个动作之间需要间隔字数的需求，需求描述为：4（以默认语速1.0为基准，覆盖4个字符）乘以语速（0.7～1.3）*视频长度取值（四舍五入）。产品和测试前期讨论的方式为：（4个字符*语速）取值四舍五入*视频长度。开发的实现结果为：（4个字符*语速*视频长度）取值四舍五入。结果就导致结果与预期不符。

c) 需求内容遗漏

此处不等于需求遗漏，而是指需求已经明确，但产品没有写入需求文档的情况。对下游团队，尤其是测试团队，需求文档是极为重要的依据，我们需要检查产品的需求文档是否编写完整，如果存在没有写入的情况，需要要求产品同学补充。例如：经过讨论已经规定该文本框中输入的最大字符数为100，但需求文档中没有更新。

2. 需求覆盖度的问题：

a) 缺少流程节点

在需求中涉及功能流程的地方，需要重点关注是否缺少某些流程节点，流程中的各个环节是否能够顺利连通。例如：用户没有权限使用某个功能时，应该给出跳转到购买该权益的入口，但需求中没有提供这个入口。

b) 缺少逻辑分支

在需求中设计判断分支的地方，需要重点关注是否分支路径是否覆盖全面，是否存在分支路径的缺失。例如：提示用户购买高级会员，只规定了进行购买的后续流程，但没有规定用户取消购买的后续流程

c) 缺少需求定义

在需求中涉及需求定义的地方，需要重点关注定义是否考虑充分，是否存在遗漏。例如：规定了高级会员有什么权益、普通会员有什么权益，但没有规定同时具备高级会员和普通会员的情况。

d) 缺少用户场景

平时用户使用过程中经常出现的场景，在需求中是否有明确说明。例如：用户播放音频过程中，进行程序的前后台切换操作、手机锁屏状态下该如何处理等等。

e) 缺少异常处理和容错机制

需要关注需求中，是否针对异常处理有约定的处理方式，用来提升程序的健壮性。例如：视频聊天过程中手机来电、断网，或者进行获取数据时服务器异常等等。

3. 需求预期的问题：

a) 预期结果不明确

需要关注需求中的内容是否都有明确的预期结果，需要让其提供明确的预期结果。例如：当网络出现异常的时候，弹出错误提示，但没有个出错误提示的具体内容。

4. 需求合理性的问题

a) 必要性

需要针对需求的必要性进行评估，要把产品的目标和用户的实际情况进行结合，综合考虑需求的必要性。例如：用户对转写结果的准确率要求极高，但本地转写的准确率又极差，那么添加本地转写这个需求的必要性，就需要探讨。

b) 与目标的一致性

需要关注需求中的内容，能否实现产品的目标。例如：产品需要收集用户是否主动关闭某个功能的数据，但该功能的入口做的非常的深，一般用户发现不了，那么这种需求就很难实现目标。

d) 连贯性

需要关注需求持续迭代过程中的连贯性，前后的风格或操作习惯尽量保持统一，否则每个版本都在变，增加用户熟悉的成本。例如：之前版本中的页面都支持右滑返回上一页，而新版本中的新增页面，则不支持右滑返回上一页。

d) 耦合度

需要关注需求中不同功能之间的耦合度，尽量简单处理，保证各功能之间的相对独立性，如果耦合度太高，会导致功能复杂度变高，增加开发和测试的成本，也增加出现bug的几率。例如：文件存在语音转写和文件存储两部分功能，尽量让转写和存储这两部分的功能策略保持独立，不要把转写状态和存储状态增加组合的策略，如未转写状态只能按照条件1的情况存储、转写中状态只能按照条件2的情况存储、已转写状态可以按照条件1和2和3的情况存储。

5. 需求的用户体验问题

a) 易操作性

需要考虑需求中的功能是否容易操作。包括不限于：

i. 操作行为是否简单（如：单手点击）

ii. 操作路径是否简短（如：一键生效）

iii. 操作入口是否直观（如：开关放在设置首页，而不是三级菜单中）

iv. 是否符合用户习惯（如：继承用户之前的设置风格）

v. 是否符合系统环境的标准规范（如：Windows的支持键盘操作、iOS下确认弹窗中按钮的左右摆放规则）

b) 易理解性

需要考虑需求中对功能或名词的定义是否容易理解，用户能够一看就明白具体是怎么回事。如果不易理解，是否有清晰的解释说明。

b) 吸引力

需要关注需求中的功能，是否对用户有足够的吸引力。例如：抽奖活动的需求，奖品的价值以及中奖的概率，是否足够诱人。