自动化测试用例设计.docx
《自动化测试用例设计.docx》由会员分享，可在线阅读，更多相关《自动化测试用例设计.docx（25页珍藏版）》请在冰点文库上搜索。
自动化测试用例设计
自动化测试用例设计
序言：
自动化测试中，自动化测试用例是一个重点中的重点，个人以为，到底如何去定位自动化测试用例设计的形式和发展是决定自动化测试成败的关键，根据一些研究和看法，我写了一个自动化测试用例设计的一个大概情况，当然一家之言而言，当然，大家在测试过程中，接触过自动化测试的，肯定就接触过自动化测试用例，其是自动化测试脚本本身也是一种自动化测试用例，看看以下的情况大家遇到过么，希望大家有什么想法，提出来吧。
一、自动化测试用例应用
手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。
而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。
所以，根据其各自的特点，需要将两者有很好的定位：
手工测试是在软件版本前几轮测试的重点，目的是验证功能，发现问题；自动化测试是应用在后几轮版本，保证软件版本模块修改或者添加新功能后，没有影响开始的功能模块（因为软件中，各模块之间的接口以及类、函数方法等的互相引用，也是容易出问题的地方）。
二、自动化测试用例设计发展
1、自动化测试用例设计发展前期
记得，当时的自动化测试开展是针对测试设备设计一套测试环境系统，用于自动化例行测试，根据此，专门撰写了一套自动化测试用例，并转化成自动化测试脚本。
之后整套系统都失败了，失败原因包括：
a、系统太过于庞大，测试用例也过于繁琐，每次测试运行下来，测试结果都夹杂着一大堆各种错误，有可能是产品问题，有可能是脚本问题，也有可能是用例问题，这样下来，测试人员每次运行一遍都要面对大量的问题，维护的几次就放弃了，问题越来越多，根本没办法去定位，这样反而浪费了大量的成本和时间。
b、搭建的一套测试环境系统，各个产品功能模块都互相联系在一起，都互相有影响，容易造成问题。
c、更重要的是，由于是单独搭建的一套测试环境系统，其自动化测试用例与手工测试用例没有太大关系，这样就造成了其自动化测试很难对手工测试进行辅助。
2、自动化测试用例设计发展前中期
这时，自动化测试用例来源于手工测试用例，首先，自动化测试根据手工测试用例进行转换而来（举个例子：
CLI测试时，自动化测试用例是根据手工测试用例的步骤，将其需要输入的CLI命令和回显进行填写），之后，自动化测试脚本人员根据其自动化测试翻译为脚本。
这样做的好处就是手工测试用例与自动化测试用例的结合，保证了自动化测试的明确性，后期的改进还包括
a、将自动化测试用例根据手工测试用例进行了分层，把一些共性功能和全局变量抽象到了更上一层，保证复用性和降低维护性。
b、设计的自动化测试框架的管理。
经过一段时间之后，问题还是很大，主要问题在于
1）前期为了追求自动化测试覆盖率，往往忽视了自动化测试用例的质量，大家想想，出产一个自动化测试项目，得经过手工测试用例—自动化测试用例—自动化测试脚本三个阶段，而自动化测试用例是手工测试人员来撰写，因为其懂业务；自动化测试脚本是由专门的自动化测试人员撰写，但是这导致了一个项目出产的周期长（需要经过两个阶段，而且还要反复调试），而且由于经过了两个阶段，所以伴随问题也多了，特别是接口这方面，往往由于两者的沟通和认知问题，使得自动化测试项目的发布后还隐藏大量问题，往往使测试人员疲于调试和维护。
2）虽然是按照手工测试用例设计出来的，但是由于手工测试用例开始没有考虑到自动化测试者一块，因此手工测试用例的每个测试模块往往测试步骤很长，而且测试前后不能保证测试环境的恢复，所以也造成了后期一个自动化测试项目的问题以及出产成本。
（这里建议最好自动化测试用例的每个功能模块的步骤不长，而且每个模块之间不要有联系，这样是要从手工测试入手的）
3、自动化测试用例设计发展中期
在这个过程中，最好的是测试人员能够根据自动化测试框架与平台来自行进行测试脚本的设计，往往在前几轮的测试中，手工测试人员就能在手工测试的同时将自动化测试脚本设计了出来
a、录制就是这样一种思想，测试人员在测试过程中，本身就是在测试过程中，将测试人员的测试过程进行了记录，所以，我的想法一直是，录制的方向是没错的。
b、而针对CLI测试，也可以制作了这么一个录制工具，就是模拟制作一个超级终端，测试人员应用其进行手工测试，其工具自动记录其命令行操作，而且手工测试人员能进行回显的需要匹配的某一个字段进行选择，然后在后台根据模板，自动生成一个自动化脚本，之后测试人员自行进行维护即可，这样可以缩减环节，降低出错几率和维护问题。
c、当然，要做到这一步，一个强大的自动化测试框架和平台是其支撑，我曾经做过一个基于GUI的自动化测试框架，部门里面也动员过一次试用，每个产品线都出了一两个人进行脚本开发，测试人员往往对脚本开发没什么太大兴致，更多的是一种好奇，而且调试工作大多是我做的，整整10多个产品线，调试了我大部分时间，因此其难点本身不是在于脚本的开发，因为当时测试人员开发出这些脚本是很快的事情，其真正难点在其测试人员的调试和维护方面，而且测试人员往往疲于去进行这方面，他们在乎的是测试和业务本身，要协调这方面的冲突是一件很难的事情，需要不断思考和总结吧。
4、自动化测试用例设计发展中后期
留一个中后期，现在的自动化测试用例设计发展还是很浅，还需要一个长远的发展过程，中后期发展成什么形式，因为见识有限，所以请大家积极猜想啦。
希望能给我带来一些见识和想法。
三、一些感想
下面感想仅我个人之言：
自动化测试就本身而言，其实技术方面的前瞻性是需要的，但是自动化测试确实是一个长期的过程，对自动化测试的定位很重要，然后是一系列的细节问题，每一个问题都是需要值得重视的问题；定位、细节、技术真的都是缺一不可啊，而且还要把握这么一个平衡，想到自己以前注重需求，后到注重技术，后又因为技术怀疑需求，最后又回归到认识需求，短短时间，总有变化，现在想想，三者，技术是基础，需要不断学习，但却不能看的太远而忽略了现在的最重要的需求，在实现现在需求的同时，不断步步跟进，进行探索。
自动化测试还真是一个“步步惊心”的过程啊。
IBM软件测试理论——功能测试和回归测试
功能测试的内容是：
功能测试，在每一个开发阶段，去验证在每个业务功能操作上都和设计文件（内部和外部）中规定的一样。
开始点：
功能测试开始于成功完成单元测试后，和功能测试计划已经被有关各方已批准，并且在基线控制之下。
结束点：
功能测试结束于执行完所有的计划的测试用例，结果中没严重性为1或者2的缺陷。
如果未被测试的用例应该被记录下来，并标明原因；所有测试应该被记录下来；有相应的测试报告和总结。
功能测试的作用：
功能测试，验证了系统执行和设计中规定的功能一致。
当功能测试正确后才能进入系统集成测试。
确定关键功能缺陷和修复缺陷，以避免在系统集成和用户验收测试阶段出现缺陷进行昂贵的返工。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行功能测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成功能测试报告。
功能测试的评估有：
成本和进度偏差，缺陷，生产力，效率和测试覆盖度。
回归测试的内容有：
回归测试验证，当系统某部分修改（增加新的功能或者修改bug）后，去验证这部分是否被成功修改和其他部分是否会被这部分的修改所影响。
要执行回归测试，应用程序必须运行相同的测试用例通过至少两次。
第一次测试是修改前应用程序的特定部分是否正确响应。
第一次测试获得的应用程序的正确反应做为第二次运行后判定程序是否正确运行的判定标准。
开始点：
因为增加新功能或者修改缺陷而对代码进行的修改后开始回归测试。
结束点：
回归测试结束于成功的执行相关的回归测试用例，并且修改后的程序相关部分没还未解决的缺陷。
回归测试的作用：
回归测试验证了系统的行为是不会受到由于修改系统而产生的影响。
它减少了重新验证的时间消耗，它给与验收测试以可信任措施。
当时间回归测试相关用例的执行是自动化的时候，显着的好处将被取得。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；确定修改的程序（必需的元素）结构属性，然后选择一个可重复执行的测试用例集去执行；制定一个回归测试执行和缺陷的详细报告。
回归测试的评估有：
缺陷评估，失败率，覆盖度。
功能测试就是验证的系统功能，是软件测试中很重要的一部分。
所有的defect被修改后，都会去验证这个bug是否成功被修复，而且会验证这个defect周围相关的一些功能是否出现了新的defect，这就是回归测试。
当软件增加了一个比较大的新功能后，在这个新功能被测试完成后，一般都会有一个专门的回归测试阶段，来进行验证这个软件的其他主要功能是否受影响，是否出现新defect。
一般只测试主要功能的主要流程，不会像对待新功能那样详细的测试。
在游戏测试中，当某一个功能模块被做了比较大的修改后，都会进行一些主要功能模块的主要功能流程的测试，比如背包有比较大的更新，都会去测试背包相关的仓库、装备、生活技能等功能的主要流程。
每次系统进行升级前，都要进行开机测试，验证系统是否能够进行正常的升级，然后才放出来。
某些回归测试是非常适合自动化测试的，出名的功能测试工具是QTP（quicktestprofessional）和RFT（Rationalfunctionaltester）。
这2个功能测试工具非常适合做功能方面的回归测试，核心思想就是一个录制和回放的过程，用在回归测试上面的话，录制就是录制被修改前系统的正确反应，回放是回放被修改后的系统来观看系统的反应。
我在后面的章节中会介绍这2个工具。
IBM软件测试理论——测试类型和测试阶段
从第一张图片可以看出，最上面一条是典型的软件开发生命周期，那是一条时间轴，给下面的测试定义在那项测试发生在软件生命周期上的哪一部分做参考。
很多不懂测试的或者只是懂点点测试知识的朋友，对测试中的很多定义是混乱的，把各类按照不同标准划分的测试类型混在啦一起。
这一节将会把按照不同标准划分的测试类型讲述清楚，后面的章节会把这些测试中的定义阐述得比较清楚。
从软件质量保证上来划分测试，测试可以划分成静态测试和动态测试。
静态测试就是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性，静态测试可以分为代码审查、代码走读、文档审查等行为。
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能的测试过程。
从那条参考的时间轴上来看，动态测试和静态测试可以发生在整个软件生命周期的全过程。
关于静态测试和动态测试的更多讨论在我的博文《静态测试和动态测试》中有比较详细的讨论。
按照测试技术（testtechniques）划分，测试可以划分为白盒测试、黑盒测试和灰盒测试。
在这套理论的介绍中，后面会有专门的一节来介绍这三种测试。
其中灰盒测试是指白盒和灰盒测试相混合的一种测试。
从那条参考的时间轴来看，白盒测试发生时间比较靠前，黑盒测试发生时间比较靠后，而灰盒测试发生的时间介于2者之间。
按照测试阶段（testlevels）划分，测试可以划分单元测试、集成测试、系统测试、系统集成测试、用户验收测试和维护测试，这一划分是根据软件生命周期和测试生命周期中自然形成的阶段进行划分的，当然越靠前的测试越先进行。
从第二幅图可以看出，单元测试和集成测试是由开发团队来做的，而集成测试和系统集成测试是由测试人员来做的，用户验收测试是由用户和测试团队来做的，及时用户不参与，测试人员也是在用户的角度进行测试的，这里没有做维护方面的测试。
单元测试是指针对各个单元模块进行的测试；集成测试就是由更多的已经完成了单元测试的测试单元构成的测试，集成测试仍然不是在一个完整的测试过程上测试；系统测试是程序第一次以一个完整的个体形式进行运行而进行的测试；而系统集成测试在系统测试的基础上，还要关注整个软件系统与外界的交互，比如调用打印机，比如与本软件系统以外的其他系统进行交互；用户验收测试也就是通常大家所说的UAT，这个时候整个软件系统已经有了比较好运行状态，可以接受用户验收测试啦。
每一阶段的结束被看做是输出，都是作为下一阶段的输入，在测试流程上有明确的定义什么这些输入和输出的标准，后面的章节会对这些标准做详细的阐述。
每一阶段的测试，都应该包含前一阶段的测试内容，也就是前一阶段的测试内容，但是侧重点不一样，从红色的箭头和红色的边框可以看出各个阶段的测试侧重点。
比如UAT过程中遇到了不属于UAT测试项的bug，当然也是属于UAT的内容。
按照测试类型（testtypes）划分，这些划分包含审计和控制、文档和过程、功能、需求、接口、回归测试、备份和恢复、工作流、性能、压力、容量、变换、安装、错误处理、并行、事物流、可用、UI、可操作性和安全性等方面的测试。
具体的一些测试类型的定义，可以从网上搜索得知。
各个测试类型可以发生在各个的测试阶段，从第三幅图可以看出，每个测试阶段所涉及到的测试类型，而静态测试应该和这些测试阶段并列开来，也可以理解成这些测试阶段都是属于动态测试的。
从横行可以看出错误处理和回归测试发生在所有的测试阶段，因为每个阶段都会有bug，有bug就会有回归，当然回归测试会发生在各个测试阶段。
从竖行上可以看出，系统测试涉及到了最多的测试类型，因为这个时候软件系统是第一次以一个完整的个体而运行，需要的测试方面是最多的。
也并不是所有阶段都要进行所有的类型测试。
IBM软件测试理论——单元测试和集成测试
从网上可以搜索到很多关于单元测试的定义，比如XX百科中就有详细的介绍。
而此理论中关于单元测试的内容有：
单元测试是对新的或者更改过的代码模块进行的初步测试。
它验证程序或模块的内部逻辑和程序规范。
开始点：
单元测试开始在开发阶段，当编码已经完成，单元测试计划已经被有关各方已批准。
结束点：
单元测试结束后，所有的测试案例被成功执行，没有严重缺陷1或2。
一项行动计划已经被记录在案，以解决还未解决的其他缺陷。
单元测试的作用：
单元测试有助于早期识别和修复缺陷，早期消除单元模块的不确定性。
通过测试程序的各个部分，然后再测试其各部分的总和，集成测试就更简单啦。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行单元测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成单元测试报告。
单元测试的评估有：
代码覆盖率的百分比，符合组编码标准，圈复杂度，行代码，路径，参数，缺陷密度。
从网上可以搜索到很多关于集成测试的定义，比如XX百科中有详细的介绍，而此理论中关于集成测试的内容有：
集成测试验证多个已经完成了单元测试的模块的执行。
所测试的应用程序通常不连接到系统中的其他应用程序。
子系统模块的通信测试是在一个控制和隔离的环境。
开始点：
集成测试开始时，单元测试已经顺利完成，当集成测试计划已经被有关各方已批准，并且在基线控制之下。
结束点：
集成测试结束后，所有的测试案例的成功执行，没有严重缺陷1或2。
一项行动计划已经被记录在案，以解决所有还未解决的缺陷。
集成测试的作用：
集成测试有助于较早的识别和修复中缺陷，降低了成本。
它也减轻了系统测试过程中的风险。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行集成测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成集成测试报告。
集成测试的评估有：
成本和进度偏差，缺陷，生产力，效率和测试覆盖度。
圈复杂度
一种代码复杂度的衡量标准，中文名称叫做圈复杂度。
在软件测试的概念里，圈复杂度“用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很大关系”。
在这套理论中，大多用的是缺陷（defect）一词，认为缺陷（defect）包含的范围大于bug所代表的意思，认为软件一切不足的地方都是可以当做defect处理，而Bug所代表的内容比defect更少一些。
其实现在各个公司有各自的叫法，还有叫issue的，但是意思都是一样的，都是指软件的不足之处。
此套理论的后面部分都是称呼为缺陷（defect）。
以后介绍的各种测试的定义，都是按照图中所展示的那样结构来展示。
左上角是一堆相关的测试类型或者测试阶段，第一页的最下面一排是关于这个测试类型中的各种文档，相关的文档并不一定全展示完了。
第二页的右上角都涉及到了这个测试阶段或者测试类型所常用到的测试工具。
“参与者”里面详细地介绍了这个测试阶段有哪些测试角色参与，带点的测试角色就被包含在这个测试中，在实际工作中，各个角色之间可以由同一人担当。
这套理论中，测试团队中都有一两个叫“Testarchitect”的人，测试架构师是团队中的关键人物，类似于系统架构师或者系统分析师，他的作用是参与系统的研发与架构，分析系统与功能模块，找出测试的难点与关键点，决定测试工具环境平台等方面的主意，在技术上主导团队的测试过程。
第二页的右下角有相关的评估方面，这些评估方面就是测试用例设计的依据。
单元测试和集成测试都是由开发人员完成，在写完代码后进行的。
单元测试和集成测试都有明确定义的开始点和结束点，并且测试结束的时候都要提供相应的输出。
测试开始的时候，测试计划都已经被各方批准了才开始，各方是项目经理、测试经理、开发经理、需求分析负责人甚至是客户或者投资者。
当这个阶段的测试过程中未出现严重性为1和2的defect的时候才能结束此阶段的测试，并且未解决的所有defect都应该被记录下来，并且做好何时解决的计划。
一个缺陷被解决得越早，越能节省成本；一个发现的缺陷越到后面才来修复，需要更多的成本。
很多时候，并没有把单元测试和集成测试分开来做，而是一起当做单元测试来进行的。
IBM软件测试理论——白盒测试、黑盒测试和灰盒测试
我用google翻译翻译了每页左下角解释什么是白盒测试、黑盒测试和灰盒测试的部分，不太准确，准确的话请看英文原文。
在这套理论中，关于白盒测试的描述是：
1、白盒测试，是对一个软件组件或系统内部的设计知识为基础的测试。
2、白盒测试是逻辑为导向，重点是通过对某些软件测试的执行路径。
3、测试设计决定被测软件所需要的一定路径下输入设定，并指定每个输入的预期将要采取的路径和输出。
4、测试执行运行有指定输入的软件，检查了预期的路径追踪，有产出符合预期的结果。
5、代码覆盖测试经常被用来评估白盒测试的彻底情况。
在这套理论中，关于黑盒测试的描述是：
1、“黑盒测试”描述的是不管一个软件组件或系统内部的设计知识的测试。
2、黑盒测试是需求导向，在所有测试阶段使用。
3、黑盒测试专注于输入和输出的软件测试。
所有可能的输入和/或输入组合输入到测试系统。
有效和无效的输入也是用来测试系统。
4、测试设计根据软件的设置，在确定的输入情况下，指定每个输入的预期输出。
5、测试执行是运行有指定的输入情况下的软件，检查对预期输出的结果。
在这套理论中，关于黑盒测试的描述是：
1、“灰盒测试”描述的测试是一个黑盒测试与白白盒试组合，我们知道被测程序的一些部分（不是全部）是如何工作的。
2、灰盒测试，侧重于输入与产出（预期结果），但是测试设计和执行是基于算法，架构，数据库的知识。
3、一个关于灰盒测试的例子，测试人员将到数据库中建立自己的测试数据库中的数据，并实际上将要到数据库中通过SQL查询来确认/验证输出/测试结果。
4、灰盒测试被最多的用在测试数据的覆盖范围，但也可能是单独使用在确认配置文件的变化。
网上关于白盒和黑盒测试的定义介绍很多，关于白盒测试的设计也很多，我这里就不在多介绍。
我是个专职的测试人员，所以只了解黑盒测试，因为白盒测试一般由开发人员或者专职的白盒测试人员来做。
每页的左上角的红框部分都是指明白盒测试、黑盒测试和灰盒测试所涉及到的测试阶段。
更大的图请看前面一节的博文内容。
白盒测试涉及到的是单元测试和部分集成测试，黑盒测试涉及到的是绝大部分的系统测试和所有的系统集成测试用户验收测试，而灰盒测试涉及到全部集成测试、系统测试、系统集成测试和少量的单元测试、用户验收测试。
其实网上有很多关于灰盒测试的内容，只是平时很多人没有明确提出灰盒测试。
一些软件公司的测试过程中已经使用了比较多的灰盒测试，当他们遇到灰盒测试的定义和内容后，明白起来很容易。
而只知道白盒和黑盒测试的朋友，希望心里有灰盒测试的概念。
每页右边的inputcase对白盒、黑盒和灰盒的概念都有一个明确的图示，很容易帮助理解他们的概念。
IBM软件测试理论——系统测试和系统集成测试
从网上可以搜索到很多关于系统测试的定义，比如XX百科就有详细的介绍。
而此理论中关于系统测试的内容有：
系统测试把系统的所有组件和对其他系统的接口当作一个整体来测试，包含功能性的测试和结构性的测试，证实这个系统可以正确的运行。
开始点：
系统测试开始于成功的上一阶段的单元测试和集成测试，当系统测试计划已经被有关各方已批准，并且在基线控制之下。
结束点：
当系统测试执行完所有的系统测试阶段的测试用例，结果中没严重性为1或者2的缺陷。
如果未被测试的用例应该被记录下来，并标明原因；所有测试应该被记录下来；有相应的阶段测试报告和总结。
系统测试的作用：
系统测试验证一个系统的所有模块和接口能够作为一个整体而且正确的工作。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行系统测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成系统测试报告。
系统测试的评估有：
成本和进度偏差，缺陷，生产力，效率和测试覆盖度。
在网上系统集成测试比系统测试相关的资料更少些，比如XX百科有详细的介绍。
而此理论中关于系统集成测试的内容有：
系统集成测试，验证了系统的整体运作。
它测试近似在生产的环境中的应用程序，硬件和网络的合作。
开始点：
系统集成测试开始于成功的上一阶段的系统测试的结束，系统集成测试计划已经被有关各方已批准，并且在基线控制之下。
结束点：
当系统集成测试执行完所有的这阶段的测试用例，结果中没严重性为1或者2的缺陷。
如果未被测试的用例应该被记录下来，并标明原因；所有测试应该被记录下来；有相应的阶段测试报告和总结。
集成测试的作用：
系统集成测试验证在近似生产环境中把系统作为一个整体来验证整个系统的功能。
关键缺陷识别和修复，以避免在用户验收测试阶段去进行昂贵的返工。
相关活动：
测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行系统集成测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成系统集成测试报告。
集成测试的评估有：
成本和进度偏差，缺陷，生产力，效率和测试覆盖度。
据我个人所知，很多公司并不清楚系统测试和系统集成测试之分，确切的说在这些公司里面做测试的时候，并没有把系统测试和系统集成测试分成2个阶段来做。
系统测试是系统第一此以一个完整的个体运行，它所涉及的测试类型也是最多的，在前面的博文《IBM软件测试理论3——测试类型和测试
升级会员 