心念旧安,夙夜忧叹。
如何进行测试用例的同行评审?
上一篇 /
下一篇 2010-08-10 21:18:48
/ 个人分类:原创文章
G |%h}+u0也许是因为统计质量管理中发现了需求的问题占到整个软件缺陷50%-60%的原因,大家都习惯性的把焦点放在评审SRS这个重要的静态测试活动上面了。然而测试用例才是我们测试执行的最终依据——需求写的再好,测试用例没有写好,一切都是白搭!51Testing软件测试网5H*C(tT
w9~^
;V~*M6YD\(G!rYP0而这,恰恰是流程改进中必须浓墨重彩的一笔!下文同样取自一网友博文,并适当做了补充和修润(粗体部分):51Testing软件测试网 Y/Ac C$\ORY!N s
51Testing软件测试网{{!f'm`{o)UC(C 测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面,测试验证的更充分(特别是对于潜藏的业务规则变化和后台数据变化等用户角度难以观测到的悄无声息的改变);对于测试工程师来说,这也是一个快速提高用例设计能力的过程。51Testing软件测试网NhdF5A0k)G
51Testing软件测试网N[
\/u
kV!F}Qp 1、需要评审的原因51Testing软件测试网1B[9\(A9~
C1v%Oz
/A1Xj&xN!@A0 测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例编写人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。此外,测试用例涉及大量对业务规则的验证,对后台数据变化的验证(甚至要精确到关联到哪些数据库表,修改了哪些数据库表的字段,字段值被改为什么),而这些单凭一份需求规格说明书(SRS或PRD)或是验收合同根本无法满足我们的“测试需求”。51Testing软件测试网5KD*HSw tc
4Q~ \:z9pH0 2、进行评审的时机