我的经验manual tester在刚入手的时候发现漏洞的机会越多，因为刚开始更像客户，更容易做出不可预知的乱七八糟的行为。
这次有点像白盒测试，要测试一组转换过后的代码。
1）用parser转换代码。
2) 凭经验直接编辑代码至没有语法错误及避免常见问题。将现实参数代入。差不多就得到一个可测试的脚本了。
3) 编写测试脚本:
i. 复制所有的函数名字。有些函数之间类似，不能顺序测，或者看上去铁定铁定没有问题；还是要都复制下来。
ii. 归类函数：
可以顺序测试的放在一组
类似的可以一起顺序测试的放在一组
类似的必须独立测试的放在一组
被其他函数调用的底层函数可以不测
其实原则就是：分类测试，不要遗漏
重复性的劳动不要做，包括重复性的思考。在原则清楚的情况下执行易行的操作步骤，而不是每次操作都需要思考，更省力，不容易出错。
4）还有时间的话加上一些边际的数据。
5）这样测试容易遗漏的是什么呢？ 一个是那些developer以为肯定没有问题的代码：类似的函数，微小的函数，简单的函数； 还有这样测试最多能做到这些代码能正常工作，不容易发觉设计上的漏洞。更复杂的情况比如操作顺序等等 如果在设计时没有想到测试时也没有覆盖到就会出问题。
我觉得写代码的人的目的只是代码能用，不是在各种情况下万能。测试脚本是比较硬代码的测试方法，要覆盖到所有的执行路线工作量比较大，而且需要更多的‘设计’。在新代码时应该考虑尽量多的应用环境。在新代码稳定后再形式化，固化这些测试的路径。
尤其是大型项目，一个零部件难以预知它在大环境下的操作情境。
那么在有新功能加入项目时呢？ 代码有改动时呢？保持基本功能的运行能保证上层的功能吗？
TBD