其次，很多优秀的黑盒测试人员并没有编程经验。他们能提供紧要问题的意见，以及其它大多数程序员无法提供的与客户沟通方面的经验。他们是完成大型测试工作所不可缺少的。但是，你不能指望这些人编写自动化代码。因此，你需要一个不要求每个人都编写测试代码的岗位安排和开发策略。你还需要避免产生一种带有歧视性的想法，认为测试编程人员要高于测试非编程人员。这是一种在使用自动化工具的测试组中普遍存在的偏见，但在我看来，这是不理智的和降低生产率的。它会排挤你的高级非编程测试人员，并且会使你把大量精力投入在与实际客户需求无关的程序测试中。
Non-programmers can be well served by data-driven approaches that let them develop test cases simply by entering test planning ideas into a spreadsheet.
数据驱动方法使非程序员能很好的工作，因为它使他们能通过简单地把测试规划放入电子表格中来开发测试用例。
Third, be cautious about using contractors to implement automation. Develop these skills in-house, using contractors as trainers or to do the more routine work.
第三，在把自动化外包给承包者时要特别谨慎。最好是在内部开发，把承包者视为培训者或让他们处理更多的常规事务。
Finally, you must educate management that it takes time to automate, and you don’t gain back much of that time during the Release in which you do the initial automation programming. If you are going to achieve your usual level of testing, you have to add staff. If a project would normally take ten testers one year for manual testing, and you are going to add two programmer-years of automation work, you will have to keep the ten testers and add two programmers. In the next Release, you might be able to cut down on tester time. In this Release, you’ll save some time on some tasks (such as configuration testing) but you’ll lost some time on additional training and administrative overhead. By the very end of the project, you might have improved your ability to quickly regression test the program in the face of late fixes, but at this last-minute point in the schedule, this probably helps you test less inadequately, rather than giving you an opportunity to cut staffing expense.
最后，你必须让你的管理者知道，自动化是要花费时间的，而且在做初始自动化编程工作的发行版中你也无法赶回这段时间。如果你要达到你通常的测试级别，你必须增加人力。例如，如果某项目通常需要十个测试人员手工测试一年，而你想要为自动化工作投入两个人年，那你就需要保持这十个测试人员，并增加两个程序员。在下一个发行版中，你才会缩短测试时间。在这一版中，你会在某些任务上节省时间(比如配置测试)，而在额外的培训和行政管理上付出更多时间。到项目结束时，你可能已经改进了面对今后困难时快速回归测试的能力，但是在进度的最后时刻，它很可能反而使你缺乏足够的测试，而并非让你有机会削减人力开支。
6. Consider using other types of automation
6.考虑使用其他类型的自动化
The LAWST meeting focused on GUI-level regression tools and so I have focused on them in this article. Near the start of the LAWST meeting, we each described our experiences with test automation. Several of us had dramatic successes to report, but most of the biggest successes involved extensive collaboration with programmers who were writing the application under test. The types of tools used in these success stories varied widely, reflecting the many different kinds of benefits available from many different kinds of testing tools.
LAWST会议的重点在GUI级回归测试工具，所以本文的重点也是这个内容。在LAWST会议召开前夕，我们每人都介绍了我们在测试自动化方面的经验。其中的一些人报告了大量的成功案例，但大多数案例都涉及到那些编写测试应用程序的程序员的协作。这些成功案例中用到的工具各式各样，说明不同的测试工具能带来不同的收益。
There is too much hype, mythology, and wishful thinking surrounding GUI-based regression automation. They can create an illusion of testing coverage where no significant coverage exists, they can cause serious staff turnover, and they can focus your most skilled staff into designing and maintaining test cases that yield relatively few bugs.
对于基于GUI的回归自动化测试，有很多带有欺骗性的、不切实际的想法。它们制造出测试能覆盖所有地方的假象，并且引起严重的员工跳槽，并且还使你最有技术的员工专注于设计和维护相对较少bug的测试用例。
These tools can be genuinely useful, but they require a significant investment, careful planning, trained staff, and great caution.
这些工具确实很有用，但是它们需要大量投资、审慎规划、培训员工以及十分小心地使用。
文章来源于领测软件测试网 https://www.ltesting.net/
