最近在看Daniel J.mosley的著作-《软件测试自动化》这个也是网上很多同行推荐的自动化经典书籍，当你仔细品读时，你会发现确实是不错的，里面对自动化的一些认识、理论以及实践的探索确实值得每一个做自动化的人去深入体会。这里从里面提到的一个测试用例需求说明包含的几个要素或部分要素开始为起点，谈谈自动化测试在测试中的位置，并进一步深入认识自动化。我希望把这个写成一个系列性日志记录，把目前我对自动化的理论、应用、框架等的学习研究记录下来。在工作中做过很多框架、工具的研究与开发，但同时也看到了很多过程中的问题，希望以后一一记录下来。
测试用例需求说明应该包含以下部分及其子部分：
1） 测试前设置
2） 测试条件
·有效条件
·无效条件
3） 测试数据
·用于有效条件
·用于无效条件
4） 测试条件的预期行为
·对于有效条件
·对于无效条件
5） 测试执行
手工
自动化
6） 测试结果验证过程
7） 测试后清理
从这个角度来看自动化，其实它仅仅是一种执行用例的方式，一种测试的手段罢了，可能由于用例执行成本或者难易度等方面的考虑，我们需要用自动化的方式来执行这样的用例。
从另外一个思路来考虑，假如我们能把对一个系统、一个功能或者小到一个控件、一行代码的测试（测试需要测试用例）的一个整体集合勾勒出来，而此时又能看到哪些用例是用自动化的方式来执行的，这样我们可以用一个大饼图包含一个小饼图或者横纵坐标的方式来表达出一个测试的集合和自动化的集合。此时至少可以这样理解自动化了，那就是如果这个用例用自动化的方式来运行了，手工就可以不用执行了，这样手工也节约了这个时间。当然实现这个自动化是要花比手工多的多的时间的，这就是为什么自动化需要执行多次，不断回归后才值得做的原因，这个也是在做实际项目自动化实现评估时考虑的。
那如何才能达到这样理想的境界呢，这个其实是需要基础的测试做到足够细致，其实说白了，公司手工测试没做好，你的自动化也不可能好到哪儿去，自动化仅仅是测试的一种手段而已。就跟开发软件一样，需求都不明确，做出来的东西能符合客户的要求吗？
当然这样去认识自动化可以得到一个很概括的认识，但这是一个纵向的思考，相对应用还是非常不清晰的，而真正实现自动化的时候可能还需要我们横向来继续思考，因为光纵向来考虑，然后你去实现自动化的时候，你会发现，要测的东西很多，具体哪些该实现自动化，实在太多太没头绪了。
其实这个时候我们需要再转换思维来思考它们，就像用例设计的等价划分等方法一样。比如我们对界面一个输入框进行测试，输入框样式、输入框接受输入数据的能力、相关属性以及与其他控件间的关联性等等，此时我们可以这样去看这些小元素本身需要进行的测试，需要执行的用例集合有哪些。等等这些也给大家提供了一个自动化实现的思考思路，我们需要对功能或者模块或者更小的元素的测试点进行分类、归纳并总结，从基本或从简单开始，不断的实现自动化，最后不断扩大自动化的覆盖率。
工作中笔者曾参与过一个输入数据测试工具的开发（我们内部称为通用用例测试，其实就是对一些输入框进行不同值的输入测试并扩展查看各个字段的属性校验，看输入框输入数据的接受是否正确、展示属性值是否正确）。
太晚了，就写到这先，后续再慢慢更新吧。
总结下吧，我们该如何看待自动化测试-一种测试的手段而已；如何更好的应用自动化呢-需要我们总纵横多方面来思考我们的测试，归纳总结，从简单入手，不断提高自动化覆盖率。
版权声明：本文出自JackieChan的51Testing软件测试博客：http://www.51testing.com/?192995
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
