标签：style blog http os 使用 文件 数据 2014 问题
每一个对软件测试有兴趣或者专业的软件测试人员，在软件自动化测试之初都会有浓厚的兴趣也充满着激情。因为都能理解到自动化做好之后会减轻测试人员重复劳动的工作量、全面的测试数据覆盖可以提高软件质量、丰富的日志以及截图功能可以提升交付效率与便于分析问题等等的优点，都会令软件自动化测试者为之疯狂；然而，自动化测试却常常带给我们沮丧和失望，因为自动化在为我们解决问题的同时也会引入更多的问题，很多自动化技术的研究以及实施工作就会止步于此了。因此，在开展自动化测试之前，就应该制定自动化测试计划，目前基本从改进软件测试过程，定义需求，支持产品的可测试性，具有可延续性的设计，有计划的部署。
我们在软件测试的过程中，除了保证软件质量之外更多的就是想着如何提升测试效率，因此首先就得定义好提升效率的具体过程，然后在投入人力物力的同时应该采用更简单、成本更低的的方法。在这样的一个过程中，我们就可以引入自动化测试。
在当下，越来越多的项目组引入了敏捷，频繁的迭代、频繁的回归与执行令匮乏测试人员的项目组大喊吃不消；因此无自动化不敏捷的思路也悄然散播开来。
现在很多项目组都在冒烟测试与回归测试环节开始引入自动化测试。冒烟测试需要在提测之初对其主干流程进行测试的一个过程，例如某一航空公司电商网站每次的需求比较小(即每次改动比较小)，但每次提测都需要测试主干流程如“预订 -> 出票 -> 退票”；相对本次修改的功能，在这样的一个主干测试过程中会投入大量的人力保证主干流程功能，如果这部分用自动化测试来代替测试人员，会把测试人员的主要精力都集中在本次修改的功能点。回归测试需要频繁的执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。此时需要测试负责人准确的分析可能因为变动哪些功能点会受到影响，将这些功能点做成列表形成回归测试文档，然后对照列表与文档检查。引入自动化测试能够大大减少工作量、与随机性出错；但是这项工作也会带来很多问题，因为某些模块功能特性导致实现自动化非常困难。此时需要对提过的缺陷进行分析，针对每个缺陷写了一个能够发现该问题的测试执行操作，从而形成自动化测试的需求。拥有这样一份良好的设计文档，设计测试脚本就是就是按部就班的事情了。
自动化测试需求是要根据测试需求加上可测性分析，再加上自动化测试能取得的预期成效所决定的。自动化测试通常有解决如下这些问题的优点：重复的简单逻辑的测试、覆盖面范围很广的测试、加快测试进度提高发布进度等。
在设计测试需求时就应该明白自动化测试不只是为了自动化，而是为了能发现更多的缺陷而设计，不只为提高自动化测试人员的技能，而是为软件质量与软件发布服务的。
在制定测试需求的时候就应该确定自动化测试成功的标准，不要在测试过程去中随意增加自动化测试功能点。也不要为了自动化的覆盖率，强行在测试的每个部分都采用自动化方式，我们要寻找能够带来最大回报的部分，部分采用自动化是最好的方法，而不是仅仅了寻求挑战在每个环节都采用自动化；也不要为了单纯的追求复杂度与功能完整度，让自动化完全替代手工将每个功能点细化到每一个细节，越做越复杂，最后做不动了；因此我们在做自动化测试的过程中就要去权衡一个回报与付出比，这是一个临界点需要我们自动化测试人员的经验去把控。
定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使项目相关人员更加合理的提出自己对自动化测试的期望。
产品的可测试性分析是自动化测试必不可少的环节，也是我从技术人员角度出发认为最重要的环节。特别是GUI的自动化测试，在整个开发过程中，图形界面经常被修改或者完全重设计，如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。
如何避免上述问题呢？这时候就需要对所测产品进行可测性分析了，更准确的说不是避免问题而是绕开困难，因为我们不能反对开发人员改进图形界面。我们都知道软件产品可能会用到的三种接口：命令行接口、应用程序接口(API )、图形用户接口(GUI)。从本质上看，API 接口和命令行接口比 GUI 接口容易实现自动化，因此可以从这两个容易实现自动化的接口去入手，如果产品没有类似的接口，需要鼓励开发人员提供相应的接口，从而支持产品可测性。
往往我们最初的自动化都是从直接操作UI开始的，因为做自动化之初总希望机器能够模拟人工形象的在页面上操作，不过UI页面自动化测试却是最复杂、最难维护、最不稳定的，因此做好WEB的UI自动化测试首先就是要做好可测性分析。最常见的就是把页面稳定的流程、主干功能点、重复性强的功能点等做为WEB的UI自动化测试的可测性标准。
无论你需要支持图形界面接口、命令行接口还是 API 接口，还是直接操作UI的自动化测试，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，将会增加你的自动化测试信心，在这条路上继续前行。
可能跟上面提到的测试需求里所说的有些冲突，但是此处的具有可延续性的设计不是让我们在同一版本中不停的扩充需求以满足自动化测试需要，而是有计划有阶段性的完善相关文档与脚本。最初我们会把注意力放在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的自动化测试。失败的自动化测试通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。
可延续性设计必须注意脚本的简单性、可读性、可维护性、独立性、可重复性，自动化框架的测试库设计、数据驱动测试，日志结果的可分析性。脚本方面的注意点跟我们平时编码习惯是分不开的，这是一个长期磨炼的过程，需要自动化测试人员的技术沉淀；而自动化框架、日志结果方面就要求我们必须要选择一个好框架来支撑我们庞大的自动化测试体系。
当自动化测试的前期准备工作与设计工作都完成之后，部署问题也尤为重要，是否是成功的部署将会直接影响到测试执行。
目前有许多流程的部署执行的工具，如开源工具jenkins等，只有有简单的安装、使用文档就可以完成实施部署了。
这里我们就不对Autosky框架进行过多描述了，我们有详细的使用手册文档与Demo文件，并且框架具备前面提到的可延续性设计里的测试库设计、数据驱动测试，日志结果的可分析性。
测试库设计：框架中有对Selenium使用方法的封装、系统文件的读取、eTerm的PNR预订与K座、HTTP请求的操作、获取各种日期时间、XML与Excel数据源的操作、压缩文件的处理、截屏的处理等等，几乎包含了所有UI与接口测试的测试库。
数据驱动测试：框架支持XML、EXCEL、SQL的数据驱动测试，这里展示一下EXCEL表的数据组合形式。
日志结果：
模块执行信息：
用例执行信息：
步骤信息：
使用过Autosky框架之后都知道框架在执行完成后都会在本地形成一份完整的日志报告，而Flysky也是在自动化项目执行完成之后向日志管理平台发送日志信息，可以展示各个实施项目的日志展示结果，方便自动化负责人或者测试经理监控项目执行情况，便于数据分析；且此平台还能接受其它自动化框架的接口调用。
标签：style blog http os 使用 文件 数据 2014 问题
原文地址：http://www.cnblogs.com/cqrdcp/p/3914983.html
