第四，软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短，一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易，成本越来越低。可是当一个项目死掉了，自动化还有什么用。而且最新的敏捷开发，软件的要求，程序，接口，界面在不断变化，自动化怎么可能跟得上变化。与其去搞自动化，不如多理解变化，直接测试变化的东西。
如何进行有效测试？
第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug. 懂程序的人每个test case都可能发现一个或多个bug. 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug.
第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。
第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。
第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之，少做自动化，多写小工具，读懂程序，是高效省钱的测试方法，除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架，告诉他"That is bullshit".
omomo
有需求才会有程序.测试自动化也是. 楼主是一个很有分析能力的测试人员,而且编程能力也不弱,所以才说出读程序+测试小工具+测试的经验.但你这样的牛人仍然只能保证你的模块的质量,如果我们需要让你保证更多的人的模块的质量,总归要从自动化测试上面来打主意了.否则你的这种测试经验没有办法容易的被人拷贝学习.而你的测试代码是很容易被人拷贝学习的.呵呵
所以一种情况是,你想出来的测试用例,可以利用自动化测试框架自动运用到各个模块中去.比如,你想出来界面上不能有重复的hotkey,那么一个好的自动化测试框架应该允许你迅速把这类测试用例运用到各个UI上去测试.
另外一种情况是,人没有办法做的,比如并发的压力测试,像gamerrob提到的那种.
其次说到,regression test,我觉得也是有用处的:"软件做对了一次,以后就永远不会错?", 这话说得太离谱,很多看似没有关联的改动,往往会导致隐藏的bug的出现,有一个完整的自动化测试集的好处是,至少当你的开发人员改动了基类或者基本底层API的时候,可以通过运行上层功能的自动化测试集保证改动没有破坏功能.否则,难道他的改动要求所有测试人员把所有功能手工的全部跑一便?光协调通知各个测试组,恐怕就得花一周时间.
文章来源于领测软件测试网 https://www.ltesting.net/
