Some of the Conclusions Reached by LAWST Participants [10]
附录
LAWST会议上得到的若干结论
During the last third of each day, we copied several statements made during the discussion onto whiteboards and voted on them. We didn’t attempt to reach consensus. The goal was to gauge the degree to which each statement matched the experience of several experienced testers. In some cases, some of us chose not to vote, either because we lacked the specific experience relevant to this vote, or because we considered the statement ill-framed. (I’ve skipped most of those statements.)
在会议每天日程的后三分之一，我们把在讨论中得到的一些论述抄写到写字版上并进行投票。我们并非想获得一致意见。这样做的目的，是想看看每条论述与这些经验丰富的测试工程师的经验符合的程度。在有些情况下，我们中的一些人并没有投票，可能是因为我们缺乏对要投票的论述的具体经验，也可能是因为我们认为该论述不够合理。(这里我已经省略了大多数论述。)
If you’re trying to educate an executive into costs and risks of automation, these vote tallies might be useful data for your discussions.
如果你正试图把自动化的成本和风险告诉给你的一位经理，那么以下这些投票结果或许是你们讨论的有用数据。
General principles
一般原则
1. These statements are not ultimate truths. In automation planning, as in so many other endeavors, you must keep in mind what problem are you trying to solve, and what context are you trying to solve it in. (Consensus)
这些论述并非终极真理。在规划自动化时，由于投入了这么多的努力，你必须时刻记住哪个问题是你试图要解决的，以及在何种环境下解决它。(一致同意)
2. GUI test automation is a significant software development effort that requires architecture, standards, and discipline. The general principles that apply to software design and implementation apply to automation design and implementation. (Consensus)
GUI级自动化测试是软件开发中的一项重大工作。它需要架构、标准和纪律。适用于软件设计和实现的一般原则同样适用于自动化设计和实现。(一致同意)
3. For efficiency and maintainability, we need first to develop an automation structure that is invariant across feature changes; we should develop GUI-based automation content only as features stabilize. (Consensus)
为了效率和可维护性，我们需要首先开发一个不随特性改变的自动化结构。我们应该开发像特性一样稳定的基于GUI的自动化。(一致同意)
4. Several of us had a sense of patterns of evolution of a company’s automation efforts over time:
我们中的一些人认为一个公司的自动化工作可以采用演化模式来进行。
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.
一旦一个程序通过了测试，那么以后就不太可能不通过该测试了。这种说法导出了一些论述(没有一个被明确赞成)，即自动化测试有危险，因为它给我们一种很舒服的错觉，认为程序没有问题。即使程序今天没有出现昨天出现的问题，但是依然还有很多情况可以使程序出问题。而如果你总是在没有bug的地方寻找，你就永远找不到它们。
文章来源于领测软件测试网 https://www.ltesting.net/
