架设IT人桥梁,呈现有价值东西

QA如何高效参与需求评审

上一篇 / 下一篇  2011-03-05 01:27:51 / 个人分类:web测试

目标与方法
    带着如果按这个做出来后,真的能实现我们的需求与功能吗?用各类用户场景去构想他的设计与实现是否可行,是否存在遗漏。(即提前去把所需功能按设计的思路,我们在脑海里来运行一下)对关键的设计决定进行验证,并帮助关键项目从设计阶段转化为最后的实现
从下面几个方面去评审这份文档
    第一:设计方案正确性、先进性、可行性;
    第二:系统组成、系统要求及接口协调的合理性;
    第三:软件实现的功能是否覆盖了产品需求文档中要求的功能;
    第四:功能的实现中,是否考虑到了所有可能的分支情况,以及这些分支情况的处理是 否合理,和PD要求是否一致;
    第五:对于功能模块的输入参数、输出参数的定义是否明确;
    第六:系统性能、可靠性、安全性要求是否合理;
    第七:文档的描述是否清晰、明确。

从以下经验点,类似问题去着手和参考:
大类检查点
数据库设计相关问题日期的考虑:默认有creat和modify时间,是否因业务需要增加:审核时间,生效时间,过期时间等
 默认值的考虑:需结合业务某操作时该表新插入数据中,各个字段默认值的合理性:如:允许null是否对后继业务有冲突?
 关键的状态标志/类型标识中,各个值是否有缺失某种状态/类型的可能,特别需考虑处理失败和异常的标识;是否要增加某个字段来标识中间的一些状态变化的记录?如取消,失败?
需结合数据什么时候插入,什么时候被更新,什么时候会删除。删除是表记录删除还是有状态标识来考虑,表的设计值是否正确
 增减字段:是否增加操作员/审核员字段?是否要有备注字段?或为便于业务未来的查询,增加一些金额,pv值之类的字段?
 是否增减表:是否需要操作日志记录表,是否主表与明细表分开?是否要有历史表来分担大数据?
 有关联的字段设计类型/长度确认: 如果表中的字段与现系统中其他表字段有关联或存放内容一致。 需核对原有表字段类型与长度,确认无偏差
 表名不可超过25个字符,表字段名称命名是否合理
 vachar类型的长度,是否不需要250长度
 结合业务考虑合理性:若表中有多个字段有各状态位标识时,务必结合实际业务有哪些类型,这些类型,对应表中各状态位是什么来区别,一一分析,找出差错,那些自我矛盾?是否可以对业务的需求进行支持(只有提前进行这类测试分析,才能确认表设计的合理)
 如果设计中使用现有表,对现有表原有数据来源必须了解清楚
流程逻辑图在有是否这类判断后面,下一步处理正确吗?
 多个判断条件,先后顺序会有什么影响?到底哪个应该在另一个判断条件的前面,为什么?是业务需要还是技术实现需要? 
 是否漏了某个条件判断吗?如:是否需要在运行时刻要判断对象的类型或条件?是否要判断对象的数据存不存在数据库中?
 对异常或出错,是否要增加一个 启动重新处理数据的脚本或重试机制?
 对并发的处理考虑?特别是界面的处理与数据库状态不一时,判断的处理。
 特别是活动等有时间段的业务,QA需结合,多个活动时间段活动结束/中断 与下一次活动开始的衔接逻辑。 是否与流程图中的流转有冲突?
 新老客户,新老流程,用户对接,数据对接问题的考虑(老客户老数据要统一迁移新系统吗?或新系统对老客户要有一定控制吗?)
  
角色功能关系图某角色可以操作的内容,QA应拿着整个流程操作来看是不是各类操作全了? 另外需以逆向(是否可取消,删除,退回至上一步)逻辑状态来考虑
 附加操作: 除一般的增删改查,是否有下载打印,发邮件短信类
 访问权限是否合适? 需进一步区分吗?需多一些角色人员区分审核吗?
  
实现细节与范围考虑与其他功能有关联,其新增的一系列操作,需考虑通知或改变其他相关点
  
设计中有配置文件配置文件中各值的作用与何时会被调用到,需要提前了解清楚
 配置文件中各值哪些是固定的,那些是可随时在一定区间修改的,哪些配置项修改需要测试,必须确认。
  
  
交互和接口设计交互中的代码转换机制的确认,二边特殊字符处理清单确认
 接口参数与结果中,是否缺少所需内容与信息
 接口通信与返回异常处理机制确认 (要重发吗?要默认返回一个值吗?)
 数据生成有时间间隔时,间隔合理吗?能连惯展现吗?如:在界面获取显示也有时间段(定期自已刷新或重取方式等),设计上会因这个时间差而取数不正确
 正常业务与异常业务不在同界面或模块实现,对异常退款、删除、终止等进行记录时,可能有关键id字段冲突,或异常业务取不到这个关键id字段等
 因表中数据来源多处进行insert,但又要求某些关键字段内容唯一,当多处来源并发时,可能会有重复记录出现,破坏唯一性要求
 交互时二边数据唯一性,不应出现重复记录的考虑
  
sql条件审核在金额统计上计算的正确性检查
 在比对的数字与字符类型不一而会有问题(30 >150是因为进行字符比对)
设计实现的合理性QA结合对业务的熟悉,提出更好的设计实现方案
 实现的可测试性的考虑
 考虑实现是否有性能问题


TAG: 需求评审 Web测试 web测试 测试 设计评审

xin_晴的个人空间 引用 删除 xin_晴   /   2011-03-07 10:57:30
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/59/n-231459.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
 

评分:0

我来说两句

日历

« 2024-03-24  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 17512
  • 日志数: 34
  • 建立时间: 2010-12-06
  • 更新时间: 2011-04-09

RSS订阅

Open Toolbar