大叔大婶带你走一条接地气的测试进阶之路

告诉你如何从执行测试到管理测试(8)

上一篇 / 下一篇  2017-10-06 20:51:08 / 个人分类:项目管理

第八章 你真的理解了什么是软件需求吗?

当我只是个测试执行人员

我走进老大的办公室,把我自己梳理的答案告诉了他,他冲我微微一笑,问了我一个问题:“你真的理解了什么是软件需求吗?”

我不假思索地回答道:“当然理解啊,我好歹也看过很多需求文档,并且评审过不少需求了呀。我平时接触的过的需求文档和评审,都是由各种各样的产品功能和产品优化组成的,比如新增一个用户取消订单的功能,或者是提高用户搜索结果的匹配精准度等等,所以,需求就是指的产品一个个功能要求。”

老大说,“你跟很多人一样,都把用户自己提出的或产品经理给出的解决方案当作了需求,不管是取消订单,还是提高搜索结果匹配精准度,都不是用户最原始或者说最真实的需求,这些其实都是最后的功能性需求。”

“我们要理解的不就是最终的功能性需求吗?”

“你平时看到的的确就是这些功能性需求,如果你只是从依据需求梳理测试点或者设计测试用例的角度来看,理解了功能性需求,也差不多满足要求了。但是,如果你想站在测试项目管理者的角度,做好需求的评审、分析和设计,那还有些不足。”

当我是个测试项目管理者

我们先来看下软件需求的基本概念:

  1. 为了解决问题或达到目标,用户所需的条件或能力;
  2. 为了满足协议、标准、规范或其他限定性文档、系统、系统组件、产品或服务需要具备的条件或能力;
  3. 需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望;

我再把老大跟我说了 N 个小时的有关需求的理解提炼成了一句话:

软件需求就是为了满足用户想解决某个问题、想达成某个目标,或作为某种角色时需求提供的一些功能或非功能性的软件能力。

当我理解了这个概念之后,也就很清楚自己在评审需求时最应该首先弄清楚哪些东西:

  1. 产品的用户是谁,如果不清楚用户,也就谈不上需求,需求只可能来自用户的期望,而不可能来自产品本身;
  2. 用户有哪些不同的角色,以及每个角色之间的关系,和每个角色都有哪些业务;
  3. 业务流程和逻辑关系,根据 1 和 2,是可以绘制出 Use Case 图(UML,统一建模语言)的;
  4. 产品的功能模块、分类,模块之间的关系和优先级,在理清楚不同角色的用户、业务流程和逻辑关系之后,这些也可以梳理出来了;
  5. 不同角色的用户是怎么使用每一个功能的,也就是每一个功能被使用的场景;
  6. 非功能性的需求有哪些,比如性能上的要求,安全上的要求,兼容性上的要求等等;

如果弄清楚这些,到了后面的测试设计阶段,也是受益匪浅。

《告诉你如何从执行测试到管理测试》带你迈出第(8)步!,点击这里可查看完整地图

作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵


TAG:

 

评分:0

我来说两句

日历

« 2024-02-22  
    123
45678910
11121314151617
18192021222324
2526272829  

数据统计

  • 访问量: 70615
  • 日志数: 82
  • 建立时间: 2017-09-03
  • 更新时间: 2018-01-11

RSS订阅

Open Toolbar