探索性测试需求思路
上一篇 /
下一篇 2012-08-07 09:26:57
/ 个人分类:杂谈
51Testing软件测试网e'zBT.o^ 卖点测试法:
^UG:g
t,Z
A0E0JZZ-IM8v0 新需求必需强调功能特性的卖点,关键功能点,核心业务点(哪些必须实现),以user story的故事提出。并且要说明场景的特性,差异化优势,51Testing软件测试网G_'s+wJ-g#]*s
51Testing软件测试网w&xp3i7kT 必备条件:规划经理提交需求时明确客户可能的用户场景
y/_7x4\qG+r/}[00b o/xe/A0 备注:当前的需求经常是一句话就列出了需求,必须细分
(qw{"V,A7`|x051Testing软件测试网
pt m(wU 质疑测试法:51Testing软件测试网&l;I:wt.TsZ
z.gO` Wa#i0KZ0
为什么是这样的客户场景?场景是否合理不是规划经理一个人的事,需要进行讨论。我们要敢于质疑场景的合理性,做出来的产品不能脱离客户,我感觉市场人员
对需求可能会比测试人员更加清楚;研发体系的模块专家对设计更加清楚;市场人员会质疑,如果客户这样操作会怎么样;而模块专家会从模块实现的关联分析提出
自己的质疑51Testing软件测试网O%[?O:G:RXv@(Hp0@
h(w)G.zH P7]^w0 必备条件:测试团队,模块专家和市场人员对规划经理的需求进行质疑,模块专家可以对这样的场景从设计上进行一定的质疑,这样设计有什么缺陷。4.2R1后期发现问题后才召集模块专家对规划经理提出质疑,取得了一定的效果,但我相信这个配合提前的话会更有效。
8o rs0Ln6b*s051Testing软件测试网
Z&_"aU(Cd"qh 破坏测试法:
po.Wz-YaY&Ao-JF0*N+eohgG*`8T0
这个是基于风险测试策略的,一般我们实现功能会有一些业务节点,项目的转发功能业务大概是 A -->B
-->C。考虑如果B挂了怎么处理?C挂了怎么办?(通过这样的质疑,发现了2个需求问题)其实这个也是质疑软件的实现,就是讲我们的业务实现分解
成一个个小的功能特性,考虑如果下个业务节点失败,程序会怎么处理。
N*[W6n8GUAES0C2Er8[*Y&[0A6p3j0 必备条件:画出功能特性实现逻辑图,可以提前和开发一起代码走读(先粗略再细化)
,b^zJ0N0p%pW8Mp@,T0 买一送一测试法:51Testing软件测试网
n5_1xQ%o(e
51Testing软件测试网I3{*P9Jp!Ek{+~M 这个主要是考虑程序并发,如cgi同时下发,程序同时读取,结合AC可以想自动升级的,如果点一次就去请求一次升级,那还得了,所以最终实现是点一次升级后建立一个标志?。所以涉及到脚本,cgi,程序时可以考虑同时下发测试。
}Ia0bo r:Q{051Testing软件测试网 ?9E~ @+_Sh5` 快递测试法:
SgQ+r1]+t&r,zq6N0!me6[n3[w0
用快递来比喻数据经过程序到达别的地方。其实现在我们更多的就是关联的数据分析不到位。我们要对功能特性进行分解,还是结合4.2R1分析,转发注销信
息,那么注销信息的数据来源是什么?城市热点的注销命令,网关强制注销,无流量超时注销,心跳超时注销。。。我的思路是我们的功能肯定是用户操作什么的功
能(功能就带着数据的流动),要对这个数据进行分析,还有哪些地方用到了这样的数据?(可以搜索版本project进行分析)。这个是数据的输入,输出同
理。
9E(X_H
U0#A
vk/qmUt/e0 必备条件:和开发共同确认功能特性,列出影响到的数据
/jBC;@-zr051Testing软件测试网M(G!P+@d.] 上面的测试方法,在最近做的项目用到了一部分,也有部分是后期测试发现了问题后用的方法保证的质量。1,2可以在测试前期用于发现需求或设计问题。
*N%?IG#E h X0
收藏
举报
TAG: