测试自动化

自动化测试有两种含义：开发过程的自动化单元测试和功能验证阶段的自动化黑盒测试。这两者融合到Daily Build中，是Daily Build的最重要核心。Daily Build和自动化单元测试另文详述，此处主要说说自动化功能测试。

自动化测试的投入产出比以及实际应用效果其实不高：自动化测试作为提高测试生产率的一个“终极”方法，往往被说得神乎其神。但实际上它被寄予了太高的期望。应用程序必然要和外界发生联系，必然有输入、输出。粗略分析一下：GUI/Web应用需要用户的输入，执行结果的正确性很大程度上要通过GUI界面回显文本/弹出提示框来判断。网管应用需要操作设备，需要保证各种各样类型设备的可连通性，对于设备版本升级，还要保证对设备独占使用。
自动化测试依赖于稳定的GUI风格：由于GUI程序的自动化测试与应用的界面元素关系太紧密，任何对GUI元素的小修改都可能影响到自动化测试程序的正确运行——甚至一个标点符号。因此说，GUI程序的自动化测试是一项耗时耗力的工作，对于敏捷开发，在界面没有基本稳定下来的情况下就匆忙上马搞自动化测试，是一件费力不讨好的事情。
通过支持自动化测试的GUI框架提升自动化测试的生产效率：为了达到高效率的自动化测试，一个有益的实践是在新产品的设计阶段就将开发和测试拉通，开发一个支持自动化测试的GUI框架。这种思路可行的前提是：该应用有大量的GUI操作基于相似的模式，例如左树右表的GUI风格加上增删改的用户操作。这个框架的大体设计原理是给GUI元素(如按钮，表格单元格等)加上规范的tag，便于自动化测试框架识别特定的元素，判断操作的结果。

商业的自动化测试框架有Rational Robot和Rational Functional Tester等。