测试过程中的评审工作及关注事项

2013-12-20  徐丹 

测试过程中的评审工作及关注事项

  公司的软件开发EPG过程规范中对测试领域的工作及其规范做了细致的说明,虽然是CMMI3+,不过还是有些地方只是官样文章,是形而上的东西,在实际工作中不具备任何的指导作用。所以我们领导觉得这个可以自己重新定义一些在测试思维上较为技术性的东西纳入到测试领域的规范当中,而我负责关于用户需求评审和系统测试用例评审的检查点整理工作。由于用户需求评审能够有助于测试人员系统测试工作的开展,所以下面就用户与需求评审所需要准备的工作、用户需求评审时所要思考的问题、系统测试用例评审过程中所需要考虑的一些检查点进行简单的列举。这些内容都是个人经验总结,并不能应用于所有类型的系统,所以请不要拿来硬套,因为不同行业、不同类型的系统特征是不同的,我所关注的只是我所负责的保险系列业务系统。
?

  用户需求评审准备工作
   》向用户或者BA/SA索取原始需求文档;
   》仔细阅读需求文档,大致估算系统改动; 
   》向开发人员了解预计的开发工作量,并且相互印证系统改动的估算; 
   》了解需求排期,预估测试所需人力,估算时需要考虑关联影响测试; 
   》了解相同和接近的版本周期内的其他需求和版本,预估测试环境和人力是否足够,如果有可能资源不足则及时升级并且邀请测试经理参与需求评审会议。 
?

  用户需求评审问题清单
   》本需求提出的背景:现有功能有什么样的问题、由什么市场、行业的变化所导致?
   》本需求所要实现的目标:操作流程简化、业务成本降低或者客户满意度提高等等? 
   》本需求是否有前置和后续需求排期?其优先级是否合理,实现情况分别是怎样的? 
   》本需求的内容是否会与现有业务逻辑或者系统逻辑的冲突?如果有,该如何解决? 
   》本需求所包含内容是否有冗余:与现有某些系统功能或流程重复,造成重复开发? 
   》本需求是否有足够的资源去实现,包括测试人力、开发人力或者测试环境等资源? 
   》本需求完成之后的效益是否足够抵消其在IT版本的成本投入?是否可能会出现在这个需求上“得不偿失”或者说“入不敷出”的情况? 
   》本需求用户验收测试有什么样的案例?对应的数据类型和数据量的需求是怎样的? 
   》本需求的UAT所需要的时间应该有多少?用户是否有足够的测试人力投入?IT应该保证的最短UAT时间需要多少天? 
   》UAT人员是否有就此需求测试的其他特殊要求或疑问?如果有,这些要求是否合理、是否有必要、是否需要IT同事支持或者是否有变通解决方法? 
?

  系统测试用例评审关注点
   》用例描述、操作步骤、预期结果和数据使用等信息是否准确、完整、无歧义;
   》用例是否包含了足够多的业务类型分支或数据场景分支; 
   》用例中是否设计了操作源表包含百、万、百万甚至亿级数据,结果集输出包含十、百、千等不同级别的数据场景,对其性能是否可接受是否有可行的验证方法; 
   》用例是否考虑了用户使用的频率,若使用非常频繁,那么是否需要做并发测试; 
   》被测功能是否为无操作界面的系统自动任务,若无操作界面,那么用例中是否考虑了用户测试的方法;若有界面,是否有界面规范性性检查测试用例(CQ中有界面变更项为是的需求);

本文选自:http://www.spasvo.com/news/html/20131219105430.html

362°/3629 人阅读/0 条评论 发表评论

登录 后发表评论