自动化测试：测试经验与总结

　　

　　之前自己一直在写自动化测试脚本，基础的手工测试基本没怎么搞过，但是既然跟测试挂钩，那么多少得了解点基础知识，下面是自己平时学习或工作中对测试的一些摘抄与体会。

 

测试理论:

　　个人认为不管是手工测试，自动化测试，亦或是性能测试，测试理论是必不可少要学习掌握的知识。我主要负责的是自动化测试脚本这一块，对测试理论的运用不是很多，时间久了，还真怕记不得了，所以下面就先复习一下测试的理论知识：

 

软件测试人员的目标：找出软件缺陷，尽可能的早一些，并确保其得以修复。

 

软件缺陷的定义：软件未达到产品说明书标明的功能；

　　　　　　　　 软件出现了产品说明书指明不会出现的错误；

 　　　　　　　　软件功能超出产品说明书指明范围；

　　　　　　　　 软件未达到产品说明书虽未指出但应到达的目标；

　　　　　　　　 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。　

 

软件测试分类：

1.按结构与内部实现：

　　黑盒测试：关心的是输入与输出。

　　白盒测试：可以访问程序代码，并且通过检查代码来协助测试，测试员根据代码检查结果判断什么样的数据输入可能导致　　　　                    　　　　　　　bug的产生，并根据此调整测试程序。

　　灰盒测试：介于白盒测试与黑盒测试之间。 

2.按是否执行程序分：

　静态测试：测试不运行的部分——知识检查与审阅。

　动态测试：运行与使用。 

3.按过程分：

　　A.单元测试：集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

　　B.集成测试：把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试

　　C.确认测试：检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确

　　D.系统测试：把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试

　　E.验收测试：用户对软件产品投入实际应用以前进行的最后一次质量检验活

4.按测试类型分：

　　A.功能测试

　　B.性能测试

　　C.安全测试

　　D.易用性测试

　　E.兼容性测试

 

测试方法：

　　静态测试：需求评审、设计评审、代码走查、代码检查、

　　黑盒测试：等价划分、边界值、因果图。

　　白盒测试：语句覆盖、分支覆盖、判定覆盖、路径覆盖。

 

 Bug的生命周期：

　　bug的生命周期：new->open->fixed->closed

　　new:找到新的bug

　　open：将bug提交给开发

　　fixed：开发修复提交的bug，

　　closed：开发修复后，测试人员需要验bug，确认修复如否。如果没有修复的重新提交bug，这是bug的状态就变成renew。

 

Bug的描述：

　　1.主题：用一句话简明扼要的描述出软件遇到的问题

　　2.环境：这个主要是描述自己操作软件的环境：比如什么语言的系统，多少位，什么版本，安装的测试软件是什么版本等等。

　　3.重现步骤：描述bug的重现步骤，在这个描述中药条理清晰，不要添加自己的主观意见，语句中不要出现人称，最好每句话以动词开头，比　　　　　　　　如：打开什么，点击什么等等，每一步都要简明清晰。

　　4.实际结果：描述自己看到的实际结果的时候，要客观真实的描述

　　5.期望结果：描述期望得到的结果。

　　6.附加信息：这个可以根据实际情况，比如在win7上这个bug发生，但是在xp上不发生；在64位上发生，在32位不发生等等。添加这些信息的目的，有助于开发快速的找到bug并尽早的解决。

 

 

自动化测试流程:

　　上面有提到测试理论，其实，要自己总结的话，也只能是照着书上抄，这个方面的知识，理论性太强。但提到这方面，主要也是想提醒自己要注意这方面的东西知识。下面就主要是对这两年的工作中用到的东西进行一个梳理。

　　测试一般都讲流程，我们这边的自动化测试其实也有个不成规定的流程，大概是这样的：

　　需求分析->制定测试计划->制定测试策略->编写测试用例->编写测试脚本->调试脚本->执行测试-维护脚本 ->提交报告 ->跟踪缺陷　　    

　　之所以上面说我们这个测试流程是不成规定的，是因为我们这边没有怎么规定该怎么做，也从来没有谁提出该走怎么样的流程，上面这个是我自己按照我们平时工作习惯归纳的，虽然多少有些出入，但是大概应该也差不多。

 

　　1.需求分析：我们的需求分析，基本上没有什么条条框框，一般都是客户来一封email，告诉我们他们需要做哪个方面的自动化，比如说软件的安装或者某个模块的功能啊等等。当我们收到email 后，会有业务熟悉的同事对软件进行一个简单的摸底，然后会跟客户进行一个详细的语音沟通，具体了解其需求。其实，这个方面一般情况下都会同后面的制定测试用例一起进行。

 

　　2.制定测试计划：需求分析确定后，那么我们就开始要制定计划了。这个过程，一般由Leader与主要负责人（A）参加，他们主要是结合业务流程（Leader起主要作用）与自身的编码能力（A起主要作用）对项目工作量（不包括从执行测试开始后面的部分）进行一个大概的评估，估算出工作量，同时给出一个大概的工作时间表，标识出各阶段应该完成的工作。一般情况下，会多给出个2-3个工作日的量。

 

　　3.制定测试策略：一般情况下，这个部分基本都省略掉了，因为大部分情况下，我们都是只需要用QTP就基本能完成所有自动化的脚本了。但是有些时候QTP不能很好的识别对象，那么这时就需要借助其他的自动化测试技术，如：使用UIA，编写独立的dll文件等等，所有这个时候，就需要确认下那些功能部分需要借助其他的自动化测试技术了。此外，有时候有些业务的操作用QTP直接识别很麻烦，需直接使用键盘发送，或者直接点击鼠标等，这个时候也会讨论下到底用什么技术更好。

 

　　4.编写测试用例：大多数情况下，我们会先拿手工测试用例进行参考，在此基础上根据客户的需求进行编写测试用例，对某些很难实现的需求或操作太复杂且不够稳定的部分需要跟客户进行沟通，将其删减。此外，有时候，有的并没有手工测试用例，有的是手工测试用例的操作与自动化的操作需求相隔甚远，那么这个时候，就得自己根据需求，进行用例设计了，必要时还需要根据业务熟悉的人与客户进行沟通与交流，以便判断测试的侧重点了。

 

　　5.编写测试脚本：这一块主要就是根据测试用例使用QTP以及其他辅助技术对其进行自动化脚本的编写，以完成全部需求的自动化。由于业务涉及到本地化、系统兼容性的问题，我们使用QTP，在这一块没有使用它的对象库，我们使用的是描述性编程。其实在网上看到不少同学讨论到底是对象库好还是描述性编程好，其实就这个问题，个人愚见：没有什么好不好，只有适不适合。你的项目适合用什么方式处理起来是脚本更加稳定，易维护，就用那种方式。

 

　　6.调试脚本：脚本完成后，像开发一样，也需要就行调试了，因为有时候软件运行的时候，会有一些突发状况的产生，比如说操作失败了，软件崩溃了等等，因为很多时候，自动化测试都是在无人值守的情况下进行的，那么这个时候就需要添加一些异常处理脚本，使得即使出现异常状况，脚本也要能流畅的进行。（这其实也就是脚本的‘健壮性’）

 

　　7.执行测试：脚本完成后，就开始执行测试了。这个过程一般都会涉及到脚本的维护，有时还有可能涉及到业务的更改问题。

 

　　8.提交报告：测试完了，就得提交测试报告了，将自动化测试找到的bug提交，说实话，做回归测试的时候，自动化测试一般很难找到bug　

 　 9.缺陷跟踪：从第7步开始，基本就同手工测试差不多了，开发将这边的bug确认并修改后，就该我们验证了，通过，关闭。。。

 

 

自动化测试框架

　　谈起自动化测试，大家都会谈到自动化测试框架。下面我就简单的介绍下我所熟悉的自动化测试框架。

　　1.安装VMware Workstation：VM允许操作系统(OS)和应用程序(Application)在一台虚拟机内部运行。虚拟机是独立运行主机操作系统的离散环境。测试环境，讲究的是在clean 系统下，为了满足这个条件，那么在VM里装系统，那是再爽不过了。搞测试的都知道，测试环境是相当重要的，配置测试环境也是相当费时的。那么我们在运行自动化测试之前，做一个干净的测试环境，每次要测试时，恢复到这个快照，开始运行脚本，再也不必为配置环境浪费时间而苦恼了，是不是很爽！

 

　　2.配置管理工具：当夜晚或者假期的到来时，在无人值守的情况下，我们需要脚本自动的开始运行我们希望它跑的case，怎么办？这个时候，我们需要利用一点点开发知识，开发出属于我们自己的配置管理工具。这个工具需要实现如下功能：

　　a.自动的启动我们指定的vm快照，启动QTP并加载我们的脚本，并且按照我们的需求运行脚本。

　　b.大家都知道QTP有时容易hang，软件有时容易crash。这个时候我们就需要我们的配置管理工具‘智能’的识别到这些情况，并且能够从善如流的处理它们而不影响我们接下来的测试。

要实现上面的两个功能，这又涉及到很多知识：

首先，启动我们指定的vm快照：参见《自动化测试：VMware Workstation提供的可编程接口》

然后，启动QTP并加载我们的脚本：参见《自动化测试：C#启动QTP》

其次，我们的配置管理工具需要实现b功能，这个就需要我们自己动脑子了，如何配合脚本去实现了。

最后，我们还要处理一点尾巴，那就是我们需要在做vm快照的时候，将我们的本地盘Map到vm中，让vm中的系统可以像我们本地系统一样的使用这个盘里面的内容。因为我们的脚本需要放在这里，以便QTP自动的运行。

 

　　外部的架子就是这样的，具体实现，本人现在已经很熟练了，不需要再这里细说。下面就讲讲我们这个架子里面的实体内容——脚本。

　　为了后期的维护，那么我们在前期写脚本的时候，的主要注意以下几点：

　　　　1.全局变量尽量放在一起，最后建一个VBS文件，给一个一看就懂的名称。这样当有问题的时候，直接到这个VBS文件　　　　              　　　　　里面Ctrl + F就找的到。

　　　　2.公共函数尽量放在一起，这里的公共函数指的是，不含业务操作的。这个函数库不涉及到任何业务，知识单纯的操作，

　　　　　比如说：对文件的操作（创建、删除、检查存在与否等等），这个函数相当的重要，因为这个函数库里所有的东西，我

　　　　　们在每个项目中都重复使用。

　　　　3.业务操作与控制操作分离：这里的业务操作指的是对软件的具体操作，控制指的是对没一个测试用例的控制，对操作步

　　　　   骤的控制，这个一来是为了在report中清晰明了，同时也是为了好维护。

　　　　4.在自动化介入较早的时候，写的业务操作代码，尽量做到分离，因为后期软件肯定有变动，测试重点也会变动，那么这

　　　　   个时候，因为前期我们对操作模块分的比较细，那么这个时候，我们就可以有很多'公共'的业务函数库了。除此之外，这

　　　　    样做也能降低耦合度。

 

　　我们跑完每一个task，我们需要生成我们想要的结果集，这个结果集里面应该包含有：步骤图、错误图、与错误图相匹配的error log、结果report表。那么我们需要的这些东西都应该是我们的脚本能够生产给我们的。

　　除了这个之外，我们的脚本里面还应该包含场景恢复的方法。比如说，如果因为QTP自身的原因，比如说像QTP hang住了，那么我们就需要利用我们外面的配置管理工具关闭QTP，将其重启，那么这个时候，如果从头再来，就有些浪费时间了，并且你也不知道这次QTP回不回hang住，对吧，那么这个时候，我们就需要场景恢复了。