因为一些私人的事情，本来早已经应该完成的一篇文章一直到今天才可以草草了结。在前面的两篇文章《对“画条线”（Draw a line）的单元测试几点想法和实践》中提到的几种方法，最实用的是Mock法并不是今天的主题。
这篇文章中继续前面的思路，简单写写有关GUI自动化测试的一点想法。
问题
对于画线，画图等应用程序的功能自动化测试的解决方案？
解决思路
采取截图法，即将用例中的输出截图，以图片作为输出结果，当然之前需要一个相应的图片作为预期结果，以便于比较。
对于预期结果图片，可以采用的方式是先运行一次自动化测试代码截得一幅图片，然后手动检查图片是否为与其效果，如是则将该图片作为预期结果。（在功能自动化测试中，在第一次运行自动化测试脚本的时候，是应该在人工监视的条件下进行的，而更多时候在我们调试相应的脚本的时候就已经完成了相应的工作。）
示例代码
1，待测代码示例
}
}
2，截图代码
gSrc.Dispose();
gSave.Dispose();
bmSave.Dispose();
}
3，图像比较类
}
}
4，调用输出
Console.ReadKey();
}
方法改进和总结
我们可以看到这个方法存在着很多缺陷，这也是为什么我的标题中加入了“粗糙”的缘故：
1， 部分代码植入到了源代码中，如我们在源代码中重写了Dispose方法，加入了对于保存图像的调用相关代码，也加入了保存图像的方法到应用程序中。
当然，这一点我们可以通过重构以解决，把保存图片的代码抽离这个应该不会太让人纠结。把调用从Dispose方法中抽离出来，目前我的想法是使用多线程，一个线程用来运行待测程序，另外一个线程则用来截图。简单的多线程操作可以参见我的另外一篇介绍文章《Winform自动化测试解决对话框问题（多线程）》。
2，截图方法使用了Windows API，我们应该使用其他更为合适的方法。
3，上面的示例代码只是为了说明一个大体思路，并不能作为一个完整的解决方案。不过笔者会利用业余时间尽快实现一个具有实践意义的解决方案。
完整示例代码下载