关于软件的基于流程图的验证方法和流程

threshold

手头有一个项目，实现过程是由一套相对标准的软件流程图配合界面方案为依据的，想达到软件完成后的全面验证，基于原始流程图做验证，实现对流程图所有节点，分支的验证，
目前的验证过程类似debug，有没有一些比较成熟的案例，比如如何设计对验证结果的交付件，如何设置检测点，如何确保验证的可行性

具体一些的方面，比如对于赋值等行为我通过输出log日志达到验证，界面行为通过 截图对比原始文档验证

有没有类型情况的一些更科学的验证模式，更专业的验证流程

目前比较大的问题就是节点走向的验证方法，如果一个节点行为正确，但是走不到下一个节点，验证结果该如何定义，
同一个情况分支的条件有小的问题，导致根据标准条件软件无法进行，但条件稍做改动即可往下进行流程，这时是否后面所有节点的验证结果都定义为失败
如何界定问题性质，怎么算通过，怎么算不通过，如果不通过，后续的验证是否应该继续
如何统计整个验证的结果，例如对于一个函数何种情况算是完全失败，何种是可通过，但有问题，何种是无法验证，等等。。。。

愚人

问题好长啊……

msnshow

是想搞自动化测试对吧

threshold

是人工通过单步调试来测试，我的问题主要是怎么设计测试检测点

threshold

我本身是做开发的，赶鸭子上架去做一个验证方案，目前的做法就是开发人员自己通过手工修改运行环境方式去跑所有分支，根据日志或者软件表现去得到验证结果。

目前仍然觉得验证点的划分 和 验证结果状态的定义不是很理想，所以想找一些测试专业方面的参考，我搜了一下关于白盒逻辑覆盖的东西，总觉得都说得比较宽泛，不知道去哪找一些资料

threshold

继续up

archonwang

回复 1# threshold

你的想法本身没什么问题。至于说更专业、更科学的方法，也不是没有。只不过这些个方法并不一定是最合适你目前的情况。

举个例子：
测试用例中任何一点不满足要求，就是背离了用例，背离用例要么是失败，要么是使用了另一个用例，要么是用例缺失需要补充。任何统计的方式都离不开基础数据的，如果你的基础数据存在问题，统计出来的结果也不会正确到哪里去。

archonwang

回复 1# threshold

你的想法本身没什么问题。至于说更专业、更科学的方法，也不是没有。只不过这些个方法并不一定是最合适你目前的情况。

举个例子：
测试用例中任何一点不满足要求，就是背离了用例，背离用例要么是失败，要么是使用了另一个用例，要么是用例缺失需要补充。任何统计的方式都离不开基础数据的，如果你的基础数据存在问题，统计出来的结果也不会正确到哪里去。

目前比较大的问题就是节点走向的验证方法，如果一个节点行为正确，但是走不到下一个节点，验证结果该如何定义，
同一个情况分支的条件有小的问题，导致根据标准条件软件无法进行，但条件稍做改动即可往下进行流程，这时是否后面所有节点的验证结果都定义为失败
如何界定问题性质，怎么算通过，怎么算不通过，如果不通过，后续的验证是否应该继续
1. 节点在流程上有几个入口和出口，都是确定的。
2. 覆盖节点和覆盖节点间的连线，在进行整体验证时，以线为单位，不能以节点为单位
3. 你说的条件改动时会走不同流程，并不属于在整体验证中的工作，而是更小单元的验证
4. 若作为整体验证，则设计时要求覆盖线，所以一旦一个流程走到了偏离预定义方向的情况时，则定义为失败或是（不）满足其他的用例
5. 问题性质的定义实际很简单。你想得过于原子化，导致无法判断——只要判断是否满足输入，并得到该输入应出现的结果即为通过，否则则失败。如果说中间还有条件更改等处理，则说明你划分的粒度过大，流程过于粗略，无法将流程节点最小化导致。

threshold

多谢斑斑，说了这么多测试相关的东西。可能我不是搞测试的，没有一种对测试理念的把握，还需多多研究