“自动化测试”浅析
对于“自动化测试”的误解
很多人认为“自动化测试”就是自动执行并自动分析程序正确与否的测试方法，那让我们看看事实是否如此吧。
以百度(www.baidu.com)搜索界面为例，测试页面Layout的正确性：
1. 页面元素（元素是否齐全、位置是否正确、文字是否正确、超链接是否正确、多媒体是否正确）
2. 页面展示（样式是否正确、缩放窗体自适应、浏览器自适应）
3. 脚本兼容
一个如此简单的设计，倘若为了实现全“自动化测试”，仅实现以上检查点各元素枚举所需的（用例设计、脚本开发、代码审核的）工作量就相当可观，对这个庞大脚本的维护成本更是难以估算。既然实现“自动化测试”如此复杂，还有必要推广吗？
答案是肯定的。因为导致上述困境的唯一原因是我们忽略了“自动化测试”成立的前提：
1. 工具的支持
2. 人力、时间成本的投入
3. 投入人员的技术能力
4. 测试用例、测试数据的完备性
5. 环境部署的独立性与正确性
6. 测试代码的可维护性、重用性及正确性
所以当
1. 程序更新频繁
2. 程序耦合度高
3. 程序优先级高
时，可将不同模块不同场景不同优先级的功能抽离出基本业务逻辑，构成所谓的通用用例进行自动化。
除了日常对系统的例行检测外，还可根据具体场景排列出各种组合，满足大项目所需的首轮smoke test，识别功能性block。
另，“自动化测试”还存在许多附加收益，比如：
1. 测试数据构建
2. 测试数据积累
（不同场景下的数据积累可在日常手工测试中得到复用和维护）
3. 基本功能展示
（对于员工熟悉产品起到直观的展示作用）
4. 等等
1. Excel: 满足一定规律的数据统计
2. SQL: 数据验证、还原
3. LoadTest: Web Test（简单业务的检查点校验）、Load Test（并发处理正确性）
4. UnitTest: 白盒测试（含覆盖率统计）
“单元测试”浅析
同样，也有人认为实现了单元测试就等于实现了该单位功能所有业务场景的校验，这也是没有根据的。因为1行代码需要多少句进行验证是无法估算的。
即便有人写出了所谓的单元测试代码，那他的测试代码的正确性又该有谁来保证？这就构成了死循环。
所以常见的Unit Test真正起到的作用，是保证在data contract一定时，功能不被block且输出结果满足约定，仅此而已。
