测试用例的设计 非传统 example based testing,每个测试用例对应的预期基于 某种属性。非银弹。提供一种测试思路。
组合
基于微软的 pict 工具
基于状态迁移图(有向图分析)
graphwalker
自己写的 有向图解析
fuzzing testing
模糊测试及 property based testing
上述的方案的优缺点
组合:
优点:组合生成用例全,约束也可以很好的加入,减少非必要的输入。可以两维度组合,或者多维度组合
缺点:生成用例顺序不可控。对单接口测试效果较好,但流程性欠缺。
基于有限状态机的测试用例生成
优点:测试状态覆盖度高
缺点:用例数据录入 数据多
模糊测试或者基于属性的测试
基于属性的测试,如测试工具 Hypothesis+contracts
优点:事先定义输入的属性或者可能的取值,然后机器会执行
如
@given(s.interger(),s.interger())
def testadd(a,b):
assert add(a,b)==add(b,a)
assert add(a,add(a,b))==add(b,add(a,a))
#etc...
assert "no core"
assert "logfile no error"
assert "db no ditry data"
@given(s.sampleFrom(F),s.sampleFrom(F))
def testadd(a,b):
assert add(a,b)==add(b,a)
assert add(a,add(a,b))==add(b,add(a,a))
assert add(a,0)==add(0,a)==a
assert add(a,-a)==0
2 根据测试结果反馈修改 参数的权重
如 当 覆盖率分析工具得出 当前 xx 场景缺少,则相应提升 yy 参数的权重, 使得 生成的用例中 yy 比重较大,则场景中覆盖可能性提升。若依然无法覆盖,则进一步提升权重。
权重的取值 由 其他参数投票所得??pagerank?
3 拆分 pict 的 model
基于有向图分析得到需要测试的状态集
人为的拆分 测试集
如需要测试订单报入状态,则该用例集 只做单方向上的订单报入,下一模板再生成其他状态