标签：写代码 tom 测试的 一个 分析 而不是 最好 而且 中间
当给你一个需求或者一个系统让你去做自动化的时候你什么都不知道你就去做自动化能行吗？你不去分析系统的哪些模块儿适合做自动化哪些不适合 ？
如果盲目的去做，当你做到后面的时候可能你框架还没弄好需求或者系统又变了，那你是否做了无用功？所以我们第一步一定是确定需求或者系统哪些模块适合做自动化，而且一定要明白这个需求或者系统做自动化给我们带来的好处是什么，而不是说为了自动化而做自动化。
有的人可能对选择方案会比较陌生，不知道这个到底是干什么的？那么问你一个很简单的问题，现在自动化测试框架常见的有robotium、appium、monkeyrunnner、UIAutomator等等，这么多的框架你到底选择哪一个呢？其实这就是一个方案的选择，那么有时候你也会根据你项目的需求去选择一个更加适合的框架，让我们这个需求实现利益最大化。
这个最好理解，方案选择好之后就该准备环境了。这个环境不会像大家想的那样配置一个jdk、appium、ide就行了，你需要考虑的是appium的版本、持续集成、代码管理等等问题。
系统设计主要是对整个测试框架系统进行合理的设计，比如各个公共模块的封装，不同模块的文件管理，配置数据和代码的分离、日志管理等等。就像工程建设实现都是经过严格的方案设计，然后根据设计方案进行施工。
编码故名思意就是编写代码，这里我们的编写代码是根据事设计好的用例来进行编写代码。
测试金字塔分层一般为三层：底层单元测试、中间层为接口测试、顶层为UI层。测试人员一般是在UI层进行测试。
移动APP的UI自动化测试长久以来一直是一个难点，难点在于UI的”变”, 变化导致自动化用例的大量维护。 从分层测试的角度，自动化测试应该逐层进行。 最大量实现自动化测试的应该是单元测试, 最容易实现也最容易在早期发现问题; 其次是接口级测试, 以验证逻辑为目的进行自动化, 由于接口的相对稳定, 自动化测试成本相对也可以接受; 自动化成本最大的便是UI级自动化测试, 然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。
标签：写代码 tom 测试的 一个 分析 而不是 最好 而且 中间
原文地址：https://www.cnblogs.com/uni5/p/11830304.html
