我们中的一些人认为一个公司的自动化工作可以采用演化模式来进行。
First generalization (7 yes, 1 no): In the absence of previous automation experience, most automation efforts evolve through:
第一代(7票赞成，1票反对)：在缺乏以前的自动化经验时，大多数自动化工作将经历以下三个过程：
a. Failure in capture /playback. It doesn’t matter whether we’re capturing bits or widgets (object oriented capture/replay);
截取/回放失败。我们截取的是比特还是窗口部件都无关紧要(面向对象的截取/重放)
b. Failure in using individually programmed test cases. (Individuals code test cases on their own, without following common standards and without building shared libraries.)
使用个人编程的测试用例失败。(个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库)
c. Development of libraries that are maintained on an ongoing basis. The libraries might contain scripted test cases or data-driven tests.
开发维护在正在进行的基础之上的函数库。这个库可以包括脚本测试用例或数据驱动测试。
Second generalization (10 yes, 1 no): Common automation initiatives failures are due to:
第二代(10票赞成，1票反对)：一般自动化的主动失败源于以下几点：
a. Using capture/playback as the principle means of creating test cases;
把截取/回放作为创建测试用例的原则性方法。
b. Using individually scripted tested cases (i.e. test cases that individuals code on their own, without following common standards and without building shared libraries);
使用个人编写脚本测试用例 (个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库)
c. Using poorly designed frameworks. This is a common problem.
使用设计不好的框架。这是一个普遍问题。
5. Straight replay of test cases yields a low percentage of defects. (Consensus)
测试用例的直接重放会带来低缺陷(一致同意)
Once the program passes a test, it is unlikely to fail that test again in the future. This led to several statements (none cleanly voted on) that automated testing can be dangerous because it can gives us a falsely warm and fuzzy feeling that the program is not broken. Even if the program isn’t broken today in the ways that it wasn’t broken yesterday, there are probably many ways in which the program is broken. But you won’t find them if you keep looking where the bugs aren’t.
文章来源于领测软件测试网 https://www.ltesting.net/
