标签：style io ar 使用 sp java strong 数据 on
自动化测试是我从进入这个行业开始，听到最多的词汇之一了。大家，特别是手工测试工程师，很多都想了解自动化测试，学习工具，并以此提高自己的收入。今天我不讲工具。而是讲讲这个词背后的原理，为读者从事自动化测试工作打一个理论基础。如果打算从事专职自动化测试工作，不论是你原来是开发人员，还是手工测试人员，都必须了解这个基础。以我实际上的工作中遇到的新人来看，最缺的就是这个理论基础，而工具大家都能学会。我下面用自顶向下的方式来解释自动化测试的原理，从高度抽象讲到具体内容。当然这些只是我的个人理解，整理这些也是为了明确我对职业发展路线的思考。
首先，自动化测试只有三个核心步骤：1.获取预期结果；2.获取实际结果；3.比较1和2的结果以判断测试是否通过。下面我先举一个最简单的三步走例子：
第一步，获取预期结果的方法：直接知道。
比如说，我测试一个网站的用户登录模块，当我要测成功登录的情况时，我的预期结果就是登录成功。
第二步，获取实际结果的方法：编写和执行测试，再获取执行结果。
知道预期结果之后，我就去编写自动化测试脚本，操作浏览器，然后做登录，最后根据页面上显示的文字或数据库里的信息，得知用户是否登录成功。
第三步，比较第一步和第二步的结果。
第一步里，我预期登录成功，第二步里我知道了登录实际上成功了，那么第三步对比结果是相同，测试通过。假如第二步里实际上登录失败了，则第三步对比结果是不同，测试失败。
接下来，实际上，我们会发现，这三个步骤可以扩展和细分，也都有相应的困难和解决的方案。
比如说，第一步，获取预期结果的方法，有可能我们不知道。
举个例子，我们知道Java语言有sdk，sdk里有提供基本数学运算。那么假如要测试java sdk里两个整数Int做乘法的结果是否正确。怎么确定预期结果？手工测试时，我可以每做一个乘法调用，然后拿出纸和笔，使用数学方法列竖式来做乘法。但自动化测试里，我们做不到这一点。然后通常有以下解决方法：
1.只测少量已知样本：也就是我预先算好一些输入值和输出值，做一个表格，或者说测试数据和预期结果表。但这样做，我的测试覆盖率是比较低的。
2.用另一种算法重新实现程序：用这个算法的计算结果作为第一个待测算法的结果的预期结果。但这样的局限性是，成本太高（我的测试程序等于是另一个独立程序），可靠性存疑（测试程序可能自己出错）
3.从已知的可靠程序里获得结果：比方说我把这个待测程序跟某个正规通用的商业计算器连接起来，用这个计算器的结果来做为我的待测程序预期结果。局限性自然是受限于这个商业计算器本身
4.编写一些已知的规则来做不完全的校验：比方说我两个正整数相乘结果应该是一个正整数而是不会是负数。那么我把这个定义为一条规则，然后跑很多组测试，每组测试的结果里都去判断是否符合这个规则。假如正数相乘乘出一个负数结果来，那就是BUG了。
其中最常用的是1和3，然后4也可以跟1、3一起用。在某些测试领域获取预期结果是难题，特别是方法4是用来解决难题的，另一些领域则经常是直接知道预期结果。
再比如说，第二步，获取实际结果的方法，这一步也就是我们在网上看到过无数的工具使用的讲解，都是为了获得实际结果。你看到的大多数资料都是讲这一步骤。
举个例子，你要用selenium操作浏览器做网页测试。那么获取实际结果这个步骤再次划分为两个小步骤：1.定位页面元素；2.操作页面元素；
1.定位页面元素，就是selenium里的WebElement.findByxxxx,通过dom对象里的一些属性或xpath等定位方法来定位元素，找到我要操作的页面元素，比如某个按钮或者某个文本框。
2.操作页面元素，则是使用selenium的api提供的方法对按钮作出点击，对文本框输入文字等。
在做第一步定位页面元素的时候，有时你定位不到，这时就要想办法去定位或者绕过这个难点。
在做第二步操作页面元素的时候，我们根据实际情况，可能要先做数据准备再来操作，比方说我填表单要填哪些数据进去，要先确定，也就是做数据准备。
数据准备又可以细分下去有很多方法来准备。
1.最简单的就是预先定义好有限的样本，顺便还可以把预期结果也定义好
2.也可能要从数据库里实时去查询我要用的数据
3.也可能我的数据要来自外部的其他系统或系统内部的其他模块，比方说某个web服务接口，如果这个接口实际不存在而需要自动化测试人员写一个代替品，那么这个代替品我们叫他桩（Stub）。
4.还有可能我的数据来自自动化测试人员写的某一程序，比如我写过一个插件用于生成符合数据类型定义的随机数据。像用户注册规定用户名是多少位的字符串，哪些符号不能出现，然后密码要符合什么规则，出生年月要符合什么规则，我的插件就在规定的范围内随机生成合理的数据。
准备数据在很多项目中都是难点，有时获取到的数据还需要进行转换，此时又要写程序，比如我们编写一个插件把某web服务接口返回的二进制编码转换成另一个web服务接口需要的输入数据的类型。
另外，除了selenium，还有很多其他层次的自动化测试，这一个步骤也会遇到其他很多难题，但至少这些原理定义是需要有个大概概念的。
题外话，请记得把自己写的小程序/脚本都称为"插件"（plugin），这样听上去专业而且高大上（笑）。
最后第三步，结果对比。
就是简单对比第一步和第二步的结果。但是问题是要用何种方式组织第一步和第二步的结果，如何管理这些结果数据，并反映到测试报告中去。
以Java语言下的网页自动化测试为例，和测试执行器结合起来做断言是最常见的情况。
仍有很多种做法：
1.简单对比，比方说 assert（1+1 == 2），等于号左边是实际结果，右边是预期结果。
2.编写静态断言类，如assert（xxxPage.userIsSignedIn（））这样在XXXpage里自己写一个userIsSignedIn（）方法来判断用户有没有登录成功
3.封装DSL做断言，如mobilePhoneNumber.isNumbers().hasCorrectLength().notExistedInDataBase()这样一个方法链来判断某个文本框里输入的电话号码全由数字组成、长度正确、数据库里无重复记录。
等等
在自动化测试这个话题的最后谈一下我理解的自动化测试成功的前提：产品适合自动化、技术基础到位、成本估计充分
1.产品适合自动化：比如别人举过的一个例子：某项目要做8年，主要内容是做某产品的40国语言本地化测试。这样的项目很适合自动化
适合不适合自动化要综合考虑，一般来说，要看
UI是否稳定、业务需求是否稳定、现存功能BUG多不多、待测程序是否具有可测性、项目周期够不够长、对质量要求高不高、可用资源够不够等等
2.技术基础到位：有没有招到自动化测试的专家，技术难题有没有解决。自动化测试项目要当作一个开发项目来做，可想而知在没有专家的情况下开发一个高难度的自动化测试项目想成功太难了。
3.成本估计是否充分：自动化测试项目通常要长期投入才可见效，小项目切勿轻举妄动。
而且有一点就是，自动化测试和手工测试能发现的BUG是不同的。自动化测试做得好，不一定能减少手工测试的工作量，也不一定能够在脚本执行时发现多少BUG。从技术负责人到上层管理需要对自动化测试有一个相对正确的认识，判断好产品究竟是否做自动化，是否有钱搞自动化，是否招到了合适的人才来搞自动化。
实际上我面试过一些小单位，技术负责人说很重视自动化测试，希望搞100%的自动化测试，但他在技术面试时没问我任何技术问题就爽快地给了offer，我不禁心里问，既然重视自动化测试技术，为什么不问技术问题。还有一些单位嘴上说以自动化测试为主，很少做手工测试，说测试经理很重视开发能力，但同样在面试中没有问我任何技术题。有时我们要鉴别一个单位是否真的适合做自动化测试，就从这些小细节上看出来。当然反过来，还有公司问一大堆用不到的技术的问题，最后进去了发现还是做手工测试为主，这也是很有可能的。
通常，自动化测试是否成功和具体的公司类型，如互联网公司、传统软件公司、金融机构、通信公司这些关系不一定很大。但也不能说无关，通常我要考虑这些：
一个是软件开发的节奏和项目周期的长短，比如互联网公司的节奏比传统软件公司快得多。
一个是新技术的应用，比如很多银行只使用商业工具，拒绝开源工具。
一个是对软件质量的要求，比如造航天飞机的，对软件质量要求会高于做游戏的。
一个是产品手工测试的难度，比如大量数据的测试，手工实在太累。
一个是资金的投入，比如巨头级公司和小创业公司相比，前者的投入更大，后者往往没有测试或刚招了一个初级测试。
一个是测试人员的平均技术水平，你千辛万苦设计出技术很超前的工具、框架，普通小测试不会用，也是惘然。（最后成品超前一步就够了，超前两步就醉了）
所以我最后的择业倾向是成熟的、质量占据重要地位的大公司，带有一定技术壁垒和行业壁垒的偏技术的自动化测试岗位，一方面顺着大公司大平台能提供的方向发展，另一方面积累更通用的技术（如×nix、脚本语言等）保持不被业界淘汰。当然每年还都要阅读足够数量的技术文献资料、保持对新技术的接触、了解各种测试行业会议的业界新动态。重点则是通用的开发相关技术，弥补一开始缺少的开发经验积累。
标签：style io ar 使用 sp java strong 数据 on
原文地址：http://www.cnblogs.com/sdet/p/4098872.html
