阿里年薪50w和5w都是如何进行需求分析,过来围观!

工作中难免会遇到并不“完美”的需求文档,比如牵一发而动全身却不清晰的交互逻辑、子条目频繁的变更、交流缺失导致的歧义等,都会让测试在项目推进中手足无措。

一份好的需求文档,不止能够加速开发和测试的脚步,还能够提前发现风险,是产品的第一道风险保障。

 

需求分析概览图

 

业务类需求

背景&目标

在阅读需求文档时,首先我们要对项目或者功能本身有一个宏观的认识,首要针对需求的整体作用进行评审。如果整体的方向错误,那么细节上也没有再讨论的意义了。

完整性

站在完整性的角度看需求文档,实际上是将当前的负责的项目模块化(或者抽象化),根据功能的需求确定功能的影响范围,再细化,同时对比需求文档,这样对目标的操作有个明确的预期结果

1)结构化项目流程

  • 原型图
  • 流程图

无论是功能类的需求、质量类的需求还是解决用户反馈的需求,都可以把这些需求抽象成为操作(增、删、改)、查询两个大模式。要么是纯查询类需求(即刻俊译),要么就是两者结合操作类+查询类(灵犀)。

扫描二维码关注公众号,回复: 17160632 查看本文章

862c372d61ed98d95cc26cb96cd3db53.jpeg

2)确认影响因素

比如一个纯查询类的功能需求,我们通过以上的图就可以知道,整个过程影响我们的因素有:

  1. 用户输入
    1. 类型(中文、汉字、英文、数字、不支持编码、表情、符号)
    2. 长度(最短、最长)
    3. 异常输入
    4. ...
  2. 查询条件
    1. 完全匹配查询、部分匹配查询(简拼、暴力)
    2. 需求中定义的查询规则(匹配规则、优先级逻辑)
  3. 查询内容
    • 这里的查询内容指的是被查询内容的特性,存在/不存在,同步/异步,正常/异常,或某些需求文档中指明的情况
  4. 效果展示
    1. 展示位置
    2. 排序优先级
    3. 展示个数
    4. 标记情况

3)综合外界因素

这里的外界影响因素,指的是有可能改变这四个过程中的某些外界因素,比如开启繁体下会改变用户输入,比如当用户关闭用户词会使用户词查询内容失效,再比如某些固排的词会影响效果展示。

还有一些效果性的需求,比如提高查询效率,我们知道这个功能只需要改动查询条件就可以,但是在需求文档中也应明确是否有用户输入和查询内容的约束。当然这些综合考量离不开测试人员对项目知识的掌握程度,在这里建议类比相似功能、总结记录(bug、特殊场景)以及用例评审去提升外界因素的覆盖度。

将以上因素排列组合和归纳,再对比需求文档,我们就可以知道某种特定的输入下,有哪些预期结果。那这些预期结果到底好不好,这就涉及到需求细节的明确性、合理性以及优先级。即明确性、合理性以及优先级的相关影响因素是在完整性的考量中确定的,所以结构化项目流程,明确影响因素范围尤其重要。

明确性

明确性是需求阅读中的痛点,因为阅读的时候人都是主观的,所以很难有这个明确性的意识。经常出现问题的地方是歧义和没有约束

  • 歧义的建议是多次阅读,特别是那些觉得非常拗口的地方,往往都是问题频发的根源。

  • 约束的问题往往依赖个人经验,比如键盘类型的约束以及异常校验的约束等。

合理性

  1. 是否符合用户需求:需求是否解决了用户痛点。

  2. 是否符合大众逻辑:解决的这个痛点会不会只考虑到小范围的用户,从而影响到大众关注的逻辑。

  3. 是否满足用户体验:同时要及时发现对于用户操作过程中的体验问题,在糗事百科创始人著作的《结网》一书中,提出了用户体验的三大原则:别让我等,别让我想,别让我烦

优先级

某些需求项与已有功能有“冲突”,针对这些需求项,是否明确了优先级,并评估优先级的合理性。

 

技术类需求

为了能有助于测试开展,我们同样需要了解开发技术,毕竟在测试环境的搭建及维护,测试过程中各种场景的模拟特别是异常情况,以及自动化测试等,都需要借助于开发技术。

  1. 理解研发设计的架构及设计思路,并考察开发设计是否满足业务需求
  2. 确认技术方案设计的影响点(代码影响、依赖模块、历史功能/数据兼容等)。
  3. 了解并熟悉开发使用的技术及开发框架(视不同项目具体情况而有所不同)。
  4. 考察代码的质量属性是否满足以下要求:

猜你喜欢

转载自blog.csdn.net/m0_59868866/article/details/134866164