专栏首页搜狗测试关于需求阅读的思路

关于需求阅读的思路

平时工作过程中,少不了要阅读需求,今天跟大家聊一聊关于阅读需求这块,个人的一点心得体会。

阅读需求共分四部:

粗读需求→精读需求→挖掘问题→提出建议,并且这是一个循序渐进的过程。

目的:

粗读需求:了解产品目标、掌握需求内容、评估工作量。

精读需求:提升需求了解程度、设计测试用例

挖掘问题:提高需求完整度、提升产品质量

提出建议:提升产品体验、提高项目效率

本次主要介绍一下:粗读需求和精读需求

粗读需求:

对于敏捷开发而言,当前版本测试过程中启动下一版本,基本上属于标准操作。因此在介入下一版本需求时,对测试同学而言,存在多版本并行的压力。此时可以采取“粗读需求”的方式,缓解压力,同时完成下一版本的前期准备工作。

粗读需求,主要达到以下几个目标:

  1. 了解产品的目的:了解产品的目的,明确要达到一个怎样的目标,始终以该目标为核心,为后续阅读需求打好基础、做好铺垫。
  2. 掌握需求的内容:了解需求大致包含哪些内容,清楚需要做哪些事情,作为后续评估工作量、产出工期的依据。
  3. 评估工作量:对项目而言,介入下一版本需求时,最重要的任务,就是产出工期。通过粗读需求,可以大致评估出工作量。

具体思路:

  1. 通读需求,了解目的和目标。如果需求文档中没有,可与产品沟通。
  2. 建立需求与功能划分的对应关系,以功能为依据评估工作量。可参考需求文档(或交互文档)中对功能的划分。
  3. 针对需求(功能)进行逐一拆分,由大到小、化整为零,提高工作量评估结果的精度。
  4. 以功能点(如数据存储、音频播放)、页面元素(如文本框)等为基准,提取测试对象,暂不深究具体细节,然后根据以往经验,评估测试对象的工作量。如果某个功能点涉及需求细节量级较大,需要特别关注,因为可能会对工作量有较大影响。
  5. 明确功能变化与已有功能之前的关联关系,准确把握测试范围。可通过模块间相互关系列表,作为参考依据。

精读需求:

完全介入新版的项目任务之后,测试同学就可以全面、完整的跟进需求,并且接下来的用例设计工作,也是对需求理解有更高的要求,此时就进入“精读需求”的阶段。

精读需求,主要达到以下几个目标:

  1. 掌握需求细节:详尽掌握所有的需求细节,为用例设计做准备。
  2. 挖掘需求问题:提前暴露需求问题,减少后续的需变,提高产品的质量和项目的效率。
  3. 明确产品预期:明确各种场景下的产品预期,保证开发产出物的合理性,以及与测试理解的一致性,从而形成测试依据。
  4. 设计测试用例:针对需求,我们最终的阶段产出物,一定是测试用例。

具体思路:

  1. 确认需求的准确性。开始精读需求前,先要确认需求是否已经更新到最新,拿到的需求是否与产品和开发手里的一致。不要小看这个点,或多或少都遇到过这种问题。
  2. 按照“粗读需求”的方式,完成对需求(功能)的逐一拆分,由大到小、化整为零。
  3. 针对拆分后的每一个功能点、元素等,进行详细的阅读,掌握每一个细节。
  4. “精读需求”过程中,需要思考是否存在“隐性需求”。这也是设计用例时需要覆盖的部分。
  5. “精读需求”过程中,需要挖掘需求问题,寻求解决,完善需求文档,从而提升测试用例的完整性。
  6. “精读需求”过程中,对于已经覆盖的部分,最好进行标记,然后全部阅读完毕,再重新进行一次复查,通过标记确认是否全部覆盖。

注意事项:

  1. 在“精读需求”一定要仔细,不能遗漏。
    1. 对于功能的拆分,实际上就是用例设计中功能、子功能的拆分过程;
    2. 对于功能点、元素等的拆分,就是用例设计中提取测试对象、检查点的过程;
    3. 每一个细节描述,都有可能对应测试用例中的一个或多个检查点,以及影响因素。
    4. 同时测试用例的预期结果也都体现在细节描述中。
  2. 通过“精读需求”,了解需求细节的目的,有可能对测试的侧重点产生影响。
    1. 了解需求对应内容的应用场景,会影响测试设计时选取什么样的测试环境和测试数据。 例如:当前的同传功能,主要应用于大型演讲会,那么测试数据,就应该选择演讲性的视频/音频。
    2. 看似不合理的需求,更需要通过了解目的,才能有效的理解需求。 例如:为了减少用户的卸载率。当用户卸载程序时,已经进行二次确认后,仍然给用户弹出一个挽留界面,阻拦用户卸载。
  3. 在“精读需求”过程中,解惑答疑。 需求中或多或少会存在部分内容,无法理解,在精度的过程中,与产品沟通,解决相关疑问。
  4. 在“精读需求”过程中,统一概念。 对于需求中的某些专属功能、元素等,在定义或概念上需要与产品和开发达成一致,以免产生歧义。

本文分享自微信公众号 - 搜狗测试(SogouQA),作者:小z

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-01-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 测试思想-文档评审 关于需求评审

    1、 传统的软件开发模式中,太过依赖文档,有各种各样的文档,需求说明书,比如市场需求说明书,业务需求说明书, 软件概要说明书,软件详细设计文档等等,这些文档...

    授客
  • 需求问题挖掘的方法和思路

    作为一个测试,有没有把需求当作产品中的一个组成部分,然后尽到一个测试的责任与义务?

    用户5521279
  • 分享一个 JSON 相关小需求的解决过程与思路

    昨天同事问我,能不能在接口返回中不要将中文转成 Uncode 编码,因为这是 Laravel 框架做的事情,所以我们要实现这个效果无非就是在 json_enco...

    overtrue
  • 关于阅读源码的一点心得

    本文来谈了自己关于阅读源码的一些心得体会,希望大家能够更好的意见,留言回复。另外并发编程系列已经全部放出,想学并发的童鞋可以 单击我 ,学dubbo童鞋可以 单...

    加多
  • 你必需要知道的关键思路; 关于 DevOps、精益、 敏捷开发

    假如,团队整体的分工模式是错误的,那 DevOps 还是没办法消除团队内不同角色间的甩锅与填坑的;能为团队设计出正确的分工模式,是团队能开始协作的关键的第一步。

    Ken Fang 方俊贤
  • 关于jeff的ppt的一篇阅读笔记

    从这张图可以看出,随着集群的增加,延迟增长到一定程度后趋稳,带宽速度在缓慢下载,容量在理所应当的增加。

    哒呵呵
  • 关于小游戏订阅消息的解读

    整个部署过程很简单,但实现的效果却是很重要,未来可以实现诸如“排名下降提醒”、“体力恢复提醒”、“活动开启通知”、“任务完成提醒”等一系列有助于回流的功能,显然...

    花叔
  • 针对阅读数等计数功能的实现思路

    在项目中会遇到这样记录文章或者其他内容阅读量的需求,最常规的方案就是每一次读取内容的时候把内容表中阅读数的值+1。这个方案非常简单而且也很容易实现,但是这个方案...

    我的小熊不见了丶
  • 关于如何阅读源码的一点心得

    本文来自作者 追梦 在 GitChat 上分享 「关于为何以及如何阅读源码的一点心得」

    CSDN技术头条

扫码关注云+社区

领取腾讯云代金券