自动化测试实施方案

自动化测试想要顺利开展，管理者需要做具体的规划。下文是之前为自动化测试项目启动会梳理的思路，算是一个草稿。笔者在自动化开展工作上也是一个探路者，希望在这方面有成功经验的同行不吝赐教。

本文档要阐释的问题

1. 自动化测试开展的必要性（自动化测试要解决的问题，自动化测试能做哪些工作？预期收益）
2. 自动化测试要哪些投入，人、时间和资源。如何分工？
3. 自动化测试开展的里程碑，输出物
4. 自动化测试要如何跟我们现有流程相结合
5. 从哪些方面避免自动化测试工作的失败？ 需要避免的陷阱
6. 自动化的测试目标,测试的用途是什么？怎样帮助发现程序错误？发现什么程序错误？测试需要理解产品的用户领域吗？

测试自动化的目的

1. 迅速监测出新版本中的不稳定变更
2. 尽可能迅速暴露回归程序错误
3. 快速报告问题，因为这会使程序错误修改更容易

快速修改会使代码稳定，使代码稳定会节省时间（不会有多人在相同程序错误上浪费时间），并促进通过重新分析或者其他工作改进代码结构，并解决不稳定代码问题。如果代码基础大体是稳定的，并有很强的自动化测试包，则程序员可以尝试以较低的风险做更大的变更。项目团队还可以通过调整产品的范围和发布时间，迅速抓住市场机会。

以下是加速开发的两个例子：

自动化冒烟测试：在有限的时间内，广泛的检验产品的功能。如果关键功能不能正常运行，或关键程序错误还没有被清除，测试小组就不必浪费时间安装或测试该版本了。解决这些问题对程序员来说也是同样紧急的事情。

自动化单元测试：这些测试也会使测试过程流畅、避免回退，并保持开发动力。这些测试有更大的测试集，针对的是被测产品功能中的下层功能和类。

自动化措施和冒烟测试的最大价值，在于可以由任何人在任何时候运行。作为开发过程的一部分，自动的运行这些测试。开发这样的测试有助于个体程序员创建一些只包含了一个或者少量变更的微版本。如果其中一个微版本失效，程序员会知道应该检查什么地方。如果微版本没有问题，会向程序员提供更大的版本，其中包含了所有程序员包含的所有的变更，这种版本出现问题的可能性也更低。这对于项目非常有好处。

自动化测试要做什么？能做什么？

POS

功能回放测试 自定义脚本在真机回放； 详细的日志、截图、屏幕录像。 负载测试： 例如模拟几百上千人同事使用被测软件； 性能基准测试： 通过自动化测试，在每次运行时都捕获时间度量参数。通过收集这些度量参数，按时间顺序观察，就会发现性能退化现象。 资源利用基准，如内存或外村的使用，也可以通过同样的方法获得。 深度性能测试 精准获取App多维度性能参数； 模拟典型使用场景及状态； 全面获得启动时长、电量、流量、CPU、内存等。 耐力测试： 被测系统长期运行，用于发现内存泄漏、栈破坏、指针越界和类似的错误 配置测试 适配各种机型,同时捕获性能数据； 记录测试过程中完整日志、截图、录像； 捕获CPU、内存、流量、电量等性能数据； 定位闪退、crash、ANR等问题。 安全漏洞扫描 扫描权限漏洞、静态漏洞、运行漏洞等。 组合错误 竞争条件

VM后台、SYS

以后补充

windows pos

以后补充

接口自动化

参考接口自动化实施方案

自动化测试应用阶段

接口自动化

冒烟测试，系统测试，线上回归（监测），详情参考接口自动化实施方案

UI自动化

自动化冒烟测试，自动化单元测试，系统测试，线上回归（监测）

单元自动化

后期规划

自动化测试环境

压测、自动化、本机

自动化测试规划-里程碑

测试套规划

跟随功能测试用例的测试套进行。良好的测试套件有多方面的用处：

1. 良好的测试套支持对产品新版本的测试；
2. 良好的测试套在新的软件平台上可以很方便的验证产品的功能；
3. 良好的测试套支持每天晚上开始的软件每日构造过程；
4. 甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

项目讨论-自动化覆盖率

• 项目中符合自动化测试的部分有哪些？(目标和范围 scope， 准入准出标准)

1. 稳定的需求点、变动较少的页面2. 每日构建后的测试验证 daily build3. 比较频繁的回归测试4. 需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务

• 自动化用例在整个项目的测试用例的覆盖率

1. 一般的要求 50% +2. 重点的要求 80% +

• 根据项目的具体要求，变动特别大的项目需要额外单独考虑覆盖率
• 根据项目中的历史bug，按照bug重现步骤编写用例
• 根据测试用例，评估可以自动化的部分
• 在自动化测试时考虑什么样的程序错误没有被发现

团队建设 岗位职责

建立自动化测试的组，理想状态下有4个人员，测试开发、中高级自动化测试工程师、2个初级自动化工程师；目前有2个人，未来还会在组内培养2个（兼职）。

测试经理：

在开发编码之前，对测试自动化作了整体设计，推动测试自动化开发的顺利开展 识别并修改测试套中的所有问题 规划自动化方向，提供需求，如要求自动化工程师为某项测试任务研发工具、脚本

测试开发：

基本工作：

1. 自动化框架的建设，确定自动化框架的设计模式、第三方代码工具的封装、中间公共模块的设计和调用
2. 测试用例、测试套件的管理和执行
3. 测试报告和测试结果的输出（文件输出和邮件通知）
4. 提供自动化测试程序的安装文档和使用文档。
5. 保证自动化测试是符合一般测试执行人员的思维习惯的

长期规划：

1. 搭建持续集成服务器的环境，进行持续交付和自动化的冒烟测试等。
2. 测试工具编写。
3. 安全测试（以后单独一个专题，本次细说）

培训的任务：

1. 需要将设计的框架以及封装的驱动，对其他成员进行培训。
2. 保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果

中高级自动化测试工程师：

1. 配合测试开发人员，实施测试框架的建设。主要负责中间公共模块的实现和实例化等，以及部分高难度和流程复杂的自动化用例脚本编写和调试等工作。
2. 提交及跟踪自动化测试发现的bug。

初级自动化测试工程师：

1. 根据中间公共模块的设计，进行实例化公共模块、方法组合，实现自动化用例脚本的编写。
2. 提交及跟踪自动化测试发现的bug。

功能测试人员：

1. 提供具体测试任务相关的咨询，并且提供测试自动化的需求。
2. 帮助检验所开发自动化测试是否有用、可理解和可信赖。

程序员

1. 参与评审自动化测试的体系结构
2. 规划程序架构，提供加入产品可测试机制的更多机会
3. 帮助自动化测试工程师开发用例设计网页等辅助工具。

技术方案

Android pos

技术方案：APPium

Appium是一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Appium支持IOS、Android及FirefoxOS平台。Appium使用WebDriver的json wire协议，来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。Appium对IOS系统的支持得益于Dan Cuellar’s对于IOS自动化的研究。Appium也集成了Selendroid，来支持老android版本。 Appium支持Selenium WebDriver支持的所有语言，如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure，或者Perl语言，更可以使用Selenium WebDriver的Api。Appium支持任何一种测试框架。如果只使用Apple的UIAutomation，我们只能用javascript来编写测试用例，而且只能用Instruction来运行测试用例。同样，如果只使用Google的UIAutomation，我们就只能用java来编写测试用例。Appium实现了真正的跨平台自动化测试。 appium选择了client-server的设计模式。只要client能够发送http请求给server，那么的话client用什么语言来实现都是可以的，这就是appium及webdriver如何做到支持多语言的；

接口自动化

技术方案：Python

首先技术工具是免费的，Python的工具用PyCharm社区版。利用比较简洁的Python语言进行自动化测试，对于人员的学习成本来讲比较实用，学习时间短，有优势。 另外Python自带的unittest单元测试框架可以很方便的实现自动化用例的设计和执行以及自动化用例套件的管理等任务。Python是纯面向对象的语言，后续也可以过渡到Java + Selenium进行更加丰富的自动化测试。 此外，可以选择Jenkins作为持续集成服务器，配合Python+Selenium的方案进行自动化冒烟测试。

性能测试

技术方案：Jmeter、 LoadRunner、自写脚本

源代码管理

代码，以及测试套的管理、分享机制。

文档管理

保存路径在git

测试交付物

性能测试计划、报告模板参考：

自动化测试计划、报告模板参考：

代码编写规范

编写人：

完成时间：

可能遇到的问题

几个使自动化测试项目陷入困境的因素：

1. 自动化测试时间不充足：自动化也要尽早介入，争取保持与开发周期同步，而不是与测试周期同步。
2. 缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动 性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。
3. 缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。
4. 更新换代频繁：测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。
5. 不关注测试工作中的实际情况：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。
6. 关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。
7. 其他：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工 作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。
8. 如何保证需求变更后，能够及时提供更新后的自动化测试？如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。关注项目里程碑，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。

自动化测试需要的支持

开发帮忙开发页面--接口测试用例编写 自动化测试线上--整理需要的场景，评估需要哪些表加标记 硬件资