引言
上一篇接用户需求调研https://editor.csdn.net/md/?articleId=109381844
用户需求规格说明一般也不由测试人员整理,但大部分中小型公司在这方面也是非常残缺,上篇也说到许多公司需求直接从项目标书来,由用户直接提供,或者领导层从各种会议零零散散收集拼凑成一个文档,稍微好点由产品经理整理一份完整一点,然后草草开始立项开发。所以测试人员想要做好测试工作,有必要在用户需求分析上面下功夫,针对输出的用户需求规格说明书进行测试,重新做需求分析,执行需求差异化对比。
用户需求分析方法
一般都是用户故事导向,这里分享一个认为写得比较好的博主文章,可以参考一下
产品经理如何做用户需求分析
分析思路上总体意思大致无差:
测试的重点关注点主要在应用场景上,博主引用自己平时在项目中常使用的方法,因为很多地方用到,单独作一小篇封装,避免重复。
基于用户故事测试应用场景分析
用户需求规格说明书
将分析整理结果整理在输出物用户需求规格说明书中。有些流程执行得比较好或者走CMMI模式的公司,一般分用户需求说明书和软件规格需求说明书,但大多会简化,提高效率将两者合并,甚至产品原型图也合在同一个阶段输出。
-
用户需求规格说明书目录结构:
-
产品介绍
-
产品面向用户群体
-
产品遵循的标准规范
-
产品功能性需求
*产品功能列表
*功能需求规格说明
(各模块功能需求设计说明) -
产品非功能性需求
*界面需求
*软硬件环境需求
*性能需求
*产品质量需求 -
附录
(调研表)
产品功能列表模板
功能序号 | 功能分类 | 功能点 | 优先级 | 备注 |
---|---|---|---|---|
产品非功能列表模板
功能序号 | 特性 | 要求 | 优先级 | 备注 |
---|---|---|---|---|
针对用户需求说明书的测试工作
博主使用需求说明书标准的评测规范。
测试建议:
1.尽管文档可能非常不完善,领导层评审也默许,但作为测试人员一定要按照规范逐个问题提出,这不是杠精行为,其他人可以不严谨,测试和QA不能不严谨。这有不仅有利于测试也有利于项目甚至乎公司流程。
2.不要认为用户需求分析与测试自身无关,在针对测试用户需求说明书以及下篇文章说到的整理测试需求时用户需求分析是必要的手段,这正是测试人员的技术多面性的表现,应该以一个产品经理的心态面对每一个需要测试的需求。切合用户的实际需要、用户痛点,切合应用场景,切合市场价值方方面面考虑测试手段。
分享至此!写得不好仅当参考!欢迎交流。