自动化测试实践经验和教训

　序言：在部门做自动化有好一段时间了，经历了自动化从无到有，然后到框架，到现在的平台，以及持续集成，回顾发现由于自己之前经验太浅，走过的弯路太多，现在也还在谨慎的前进着，上次又回顾了一遍”软件测试经验和教训”里的自动化测试章节，发现早前很多懵懂的经验，现在稍稍清晰，于是想着结合自己的历程精简出一些经验吧。现在经验还是尚浅，如果有更深认识的朋友，互相讨论，谢谢

　　一、所谓自动化是为了软件发布服务的，并不只是为了测试服务

　　来源：自动化测试目标建设

　　以前一直怀疑自动化测试的用处，我们之前花费大力气开发了大量的基于关键字方式的脚本，用来提高测试的覆盖率，每次测试耗费大量时间，但是发现的问题少之又少，虽然说，自动化测试不是用来发现问题的，是用来验证软件没有问题，但是有一个矛盾在于我如果不做自动化测试，问题还是那么少，那么做自动化测试我们难道只是为了追求一个心理感受吗？这个概率问题怎么平衡

　　后来，这个经验是在与开发一起合作冒烟测试建设，到现在的持续集成建设，开始明白，自动化测试的好处是为了增强开发的灵活性和保证软件开发流程的有序性

　　1）快速检测新版本的不稳定变更，即冒烟测试，能够快速验证当前build版本是否可以继续下一步或者提测，此处冒烟测试可以是单元测试、集成测试和基本功能覆盖测试，常用的框架和工具：Junit、TestNG和接口测试框架（soapui、httpClient等）、界面测试框架用于基本的界面测试（QTP、RFT、selenium）。

　　2）尽可能的暴露回归程序的错误，即例行回归测试，测试部门在开发提测后，基于开发的测试单，手工重点测试变更内容，利用自动化有选择性的覆盖其他功能。此处更多的是到了系统测试层面。

　　3）验收测试，在发布前应用自动化的各种手段进行一次基本功能验收测试，通过率在多少以上才可以提交发布，而且此处环节还可以加入非功能测试。

　　所以说，我们做自动化测试的目标一切都是为了软件发布服务，也可以理解为部署软件生产流水线，在这里，推荐一本书，《持续交付-发布可靠软件的系统方法》

　　二、不要事后去计算人工替代率，而是要参考自动化测试有效性

　　来源：自动化测试度量和ROI分析

　　之前在年底做自动化测试度量的时候，要求每个产品线将自动化测试执行次数和时间进行统计，这样做的目的是为了统计自动化测试执行时间，然后要求测试人员算出每个模块的人工耗时，然后进行换算，得到自动化替换人工的时间，后来算完后，发现这样的数据其实是没有意义的

　　1）测试的本质是不可以比较的，一次手工测试执行有可能比自动化测试执行也许是更有意义的。

　　2）大多数的人工耗时都是拍拍脑袋想出来的

　　3）运行只是表明自动化测试被执行，但不能证明这次执行是有效的，只有真正本来需要手工的测试被自动化执行时才有意义。

　　所以，在度量上，一定要保持维度一致，可以横向比对，即不同模块之间进行比对，有效性上可以从自动化测试模块的应用场景和执行次数、执行频率去评估，成本上，即是自动化测试开发和维护成本

三、度量一个自动化测试的可实施性可以从其可控制性或者可测试性上来考虑

　　来源：自动化测试可测性分析

　　有的人说单元做自动化比较好，有人说接口测试做自动化比较好，但奇怪的是也有人说他们做界面自动化比较成功，其实说接口测试和单元测试比较好的人，单元测试往往是开发来定义的，所以开发来控制可测性，接口测试的话，接口协议都是约定好的，所以可控制性和可测性有保证，而界面的话，有些产品的界面可测性控制比较好，例如都有唯一的debug id，或者界面变动性很小，那么也是考虑可以用界面自动化的。所以说，我们在推广自动化测试过程中，不是人云亦云，而是要结合当时的环境，从可测性上去考虑自动化测试的开展。

　　四、试点推进自动化测试

　　来源：自动化测试推广

　　自动化思路重要，但是做自动化本身也是具有一定机遇性的，其环境相关性很大，所以在开展自动化测试前，一定不要过度自信，铺天盖地的推广，而是要找好试点项目。之前做过一个接口录制工具给测试人员推广使用，由于不是试点分析，每个组的测试人员拿着这个工具开发了一堆一堆的线性脚本，导致存积了大量的接口线性脚本，然后后来由于脚本的维护性和不稳定，慢慢的流于形式，甚是可惜。如果采用试点分析的方式，先在小范围进行使用，并且跟踪效果。

　　业内有一个分层测试的理念很好，可以基于IP和地域选择性的发布新产品，根据使用效果，然后再根据情况逐步推向全国。

　　五、自动化测试框架的重要作用之一是为了职责分层

　　来源：自动化测试推广和框架建设

　　所谓软件框架功能，我觉得很重要的一点是能够将每一层次的责任细分出来，数据驱动框架就是将数据单独抽离，让测试人员能更有效的管理数据，例如：可以构造重复的、组合的、随机的或者大量的数据包；关键字测试框架就是将对象封装、任务封装、业务组装分层，这样，可以让代码能力稍强的人员面对对象和任务封装，让业务能力稍强的测试人员面对业务组装，这样可以通过框架将各个人员的职责细分，做自己所擅长的事。

　　关键字框架推荐robot framework，利用其可视化界面ride，其中还有一些拓展包，例如selenium2Lib可以应用在web测试。

　　六、可以的话，让开发一起参与自动化测试

　　来源：自动化测试可测性分析

　　曾几何时，我基于RFT和QTP都试点推行了公司的界面自动化，但是效果不佳，究其原因还是界面的变化太大，加上一些自定义控件或者一些自定义图片展示的动态搜索无法查找，只能用存储对象的方式，后来大力发展接口自动化，将界面自动化先搁置了一段时间，后来开发自己做了一部分自动化，说是效果甚佳，去学习才发现，他们有一些图形和事件是基于xml配置定义文件描述的，这样利用JDOM技术，解析出文件，然后根据QTP的脚本编写规范，生成QTP脚本，而测试动作基本上涵盖增删改查。这种情况是我们测试之前无法知道的，因为开发流程原因，我们无法知道开发所采用的开发技术，所以说，我觉得可以和开发一起来评估自动化测试。

　　七、自动化测试是可以成为一种习惯的，尽早自动化

　　来源：自动化测试推广

　　之前，和几位华为的开发朋友聊天，问他们一个问题：你们自动化怎么样，我原来以为开发是不太了解自动化的，没想到他们给我的答案是，什么怎么样，这是必须做的工作呀。原来他们华为的持续集成过程，开发自己写测试脚本做冒烟测试，以前这是华为的规定，现在是他们开发人员的一种习惯。

　　所以，我觉得，推广自动化不一定一开始就要大张旗鼓的，也不是所谓的等到一切时机成熟，自动化测试是一种辅助测试的方法，不同的情况可以采用不同的方式，几行脚本，一个bat部署文件，一个数据统计，也是自动化的一种应用。用另外一种说法：不管黑猫、白猫，能抓到耗子的就是好猫。

　八、自动化应该立即见效，见效后应该慎重评估

　　来源：自动化测试推广

　　有时候如果我们对目的不够清晰，不能抓好本质问题解决，就很容易走极端，有人说录制不好，我们就反对录制，有时候我们抓到一个录制工具就以为遇到了神器，孰知后面是一个一个的大坑；而我觉得，录制不是不好，而是如何将它用在合适的地方，录制的好处是无需编程技能即可快速上，但是他的缺点是相对脆弱，一旦UI或者接口变化测试就会受到影响，分散的脚本不可重用且难以维护，而且系统在测试前必须可用（也就意味着无法使用A-TDD方法）。因此这种方法并不适合大型自动化测试。而关键字驱动，将数据与关键字结合来描述如何使用数据执行测试，这种方法是具备数据驱动的优势，同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行，无需不同的驱动脚本。然而初始成本很大，但是可以使用开源方案，因此非常适合大型项目。所以，我们刚开始的时候，选择合适的项目，可以采用脚本录制这种方式，让自动化测试立即见效，小范围推动项目进度，然后，就严格控制，开始设计框架，把握可测性。

　　九、不要指望用自动化测试平台一下子解决所有的问题

　　来源：自动化测试平台建设

　　当年在作自动化测试过程中，遇到瓶颈，就想当然的认为要开发业内所说的自动化测试平台，即先弄出一个线，然后再想办法去线上发展每个点，后来历时几个月，加班加点的，总算基于STAF开发出了一套分布式的自动化测试平台，但是后来用着用着就不了了之了，分析出原因是问题本身和目的都没有明确，单纯的开发出了一个架子，然后再去找衣服强塞进去是不可行的，架子本身是为放衣服服务的，所以平台本身是为让自动化更有序的进行而服务的，之后我们大力发展点，而平台是等点都满足需求后，开始将点串起来，自然而然的形成了一条线，然后再加以修饰，就成为了平台。所以说，不要舍本求末，追求花哨，而要踏踏实实的做好每一个点，以需求为导向，自然而然的才能把架子搭好。

　　在这里也推荐几个用来搭建平台的较好的工具和框架：STAF， Jenkins，selenium grid可以用来做分布式测试执行和测试节点管理，sonar可以用来做质量管理平台，更多的是面向白盒测试分析。Toast也是一款不错的自动化测试平台，我觉得它的理念更多的像项目管理+jenkins。

　　十、将所有的测试资源都版本控制起来

　　来源：自动化测试配置管理

　　这个很重要，在我们的自动化建设过程中，因为我们是多产品线的，每个产品线的有些功能模块是共用的，我们的方法是将每个模块的功能抽象成关键字接口，所有产品线共用接口，只是实现上不一样，而这种方式前期的问题是版本管理的问题，因为一个产品线开发出一个模块后，各个产品线开始互相迁移，导致迁移混乱，还有一个问题是产品功能模块也在不断的更新，不同的产品版本要对应不同的测试脚本，所以后来，加入版本管理，而最终的测试脚本版本用V1.0.0进行跟踪，第一位表示接口版本、第二位表示产品特性，第三位表示当前产品线的脚本维护。

　　版本控制中重要的两个概念就是分支与合并，随着开发的版本控制的不断深入，测试的版本管理也需要跟上，常用的版本控制工具是svn、cvs以及分布式版本控制git，和基于流的版本控制系统Clearcase，个人觉得，前期可以用手工的方式定义好版本，等到开发协作强大到一定程度后，可以采用这些版本控制系统。

　　十一、时刻反省自动化测试过程

　　来源：自动化测试推广

　　自动化测试是一个长期的过程，我们即要低头走路，也要不时抬头看路，也需要不时的休息一下，回顾自己走过的路程，整理之后才可继续向前，所以需要我们每隔一个阶段，就要好好反省自动化测试的开展和推广过程，大家的时间都是很宝贵的，珍惜自己的时间，更要珍惜大家的时间。

　　总结；因为时间仓促和水平有限，有些经验和教训不一定很全面，或者还有朋友在推广或者平时观察到有更好的自动化测试实践经验和教训，希望可以一起总结，总之，个人觉得，学习过程最有效的方式是理论和实践相结合，知行合一，在实践中发现问题，然后去推敲理论，解决问题，最终总结从而变成自己的东西。

posted @ 2013-04-19 10:36 顺其自然EVO 阅读(289) | 评论 (0) | 编辑收藏

软件全程质量保障TQA概述

　　全程质量保障（Total Quality Assurance(TQA) In the system development，以下相同处简称TQA）是基于对信息系统建设的再认识构建的，从信息系统规划与选型、信息系统建设与开发、信息系统交付与验收和信息系统运行与维护四个阶段的质量保障需求出发，定制质量保障内容，有的放矢、精准执行！

　　全程质量保障整合了我们十年来在数千个实施项目中积累的丰富实践经验、服务内容和模式的众多创新，实现模块级组合，能够更适应用户各类项目千差万别的需求。

　　为什么选择TQA？

　　当前在项目建设过程中的问题

　　在KPMG（毕马威，国际顶级会计事物所）的一份对失败项目的统计调查中，我们看到导致项目失败的前10项影响因素主要有以下几个（如图）：

图1项目失败因素统计

　　一般系统建设可以划分为系统规划、系统建设、系统验收和运行维护四个阶段，我们对这些影响因素作进一步分析发现这些因素分布在系统建设的各个阶段（如图），也就是说在整个信息系统建设过程中每个环节出了问题都有可能导致整个项目的失败。因此，全程质量控制势在必行。

图2失败因素分布情况

　　软件生命周期是一个包括项目规划、需求分析、软件设计、系统集成、软件测试、系统验收及运行维护几大阶段的长程软件构建开发过程，从上述统计图表上我们可以看到这些问题既有前期系统规划、建设方面的问题，也有后期验收、维护过程中出现的问题，因此要想确保一个项目成功建设和应用，单纯解决某一方面的问题只能是“头痛医头，脚痛医脚”的短视行为，现代系统建设需要一套科学、全面、有效的质量保障解决方案。

　　软件过程质量保障就是针对软件生命周期的不同阶段及其特点，计划并实施一系列质量管控活动，对软件产品的开发过程和交付成果进行质量保证和质量控制，这正是构成TQA的两个核心模块，也是精髓所在。

　　通过质量保障方案的实施，将完整有效的质量保障手段灌装到软件工程的各个阶段，才能将软件开发过程透明化、数字化，软件质量度量才更有依据、更加可信，项目的有关决策才更加客观、合理。

http://www.51testing.com

posted @ 2013-04-19 10:31 顺其自然EVO 阅读(207) | 评论 (0) | 编辑收藏

浅谈软件测试工程师的培训工作

　国内软件测试工程师的职位从无到有，经历的时间还不足10年。成熟的软件测试理论体系构建也仅有10余年的历史。而纵观现在如雨后春笋般蓬勃增长的计算机软件企业，对优秀软件测试工程师需求和渴望的现实，不禁让我们不得不去思考一个问题：如何开展并做好软件测试工程师的培训工作。

　　对于软件测试的重要性，很多人有些误解。因为刚刚开始做软件测试的人员往往是从黑盒测试做起，而黑盒测试不需要编程经验，所以总是给人感觉测试人员不需要太多的知识，无论谁上了岗都能做，因此也就导致软件企业不愿意、也认为不需要对软件测试工程师开展培训工作。一旦软件产品发货到用户手中，发现质量低劣、效率低下、维护成本昂贵，又都毫不留情地骂测试人员无能，为什么测不出Bug（软件缺陷）。

　　中国有句老话：磨刀不误砍柴工。看到上面这种恶果，显而易见，现在至少我们应该达成一种共识：软件测试工程师也需要培养，并且需要接受正规培训。培训什么？我想应至少从三个方面入手培训工作。

　　一、入职培训

　　软件测试工程师初来乍到一个公司，往往兴趣十足，预备全身心投入到“捉虫”的战斗中。但往往不得其法，事倍功半，因为抓不到虫子，或是即使抓到了虫子并不重要也被开发人员视而不见。设身处地的为这些雄心勃勃的测试工程师想想，他们是多么需要入职培训。

　　软件测试工程师的入职培训可以从三个方面来分头进行。产品的培训、测试技术的培训和测试工具的培训。软件测试的工作对象即是企业开发的软件产品，所以务必要对软件产品有一个全面的了解和清醒的认识。作为一个测试管理者，应至少安排足够的培训时间，让测试新手研习被测试软件的内容。我们可以利用一切可利用的培训资料。软件产品本身、用户手册、开发组的需求规格说明书、技术文档，包括熟悉产品的人员进行功能讲解等等，用这些形式不拘一格的产品内容来迅速武装起测试工程师的头脑。光有这些培训还不能罢休，要善于检查测试工程师的学习情况，及时地向他们提问产品中那些最关键性的问题，如产品的核心概念、业务流程等。有培训有检查，通过一问一答的方式，既了解了初学者对产品的了解程度，同时也传授了产品中的精髓，并且还能够从初学者的疑问中抓到培训工作中的漏洞，为今后更好地开展培训奠定基础。

　　因为软件测试工程师总是如人们所预料的一样，来自于各行各业、五湖四海。有测试经验的，无测试经验的，统统汇集到企业中。所以必须的测试技术培训一定是要有的。培训内容主要以黑盒测试技术为主，一是因为黑盒测试技术是基础，二为的是成本更为昂贵的白盒测试人员在需要的时候，也能够出色的完成黑盒测试的任务。黑盒测试常用的测试方法、测试用例的设计、黑盒测试常见的测试类型、不同测试类型各自关注的主要问题等等，在入职培训中都应有所全面接触。同样，方法的学习离不开实践的过程。可以找一些具有普遍性的功能点，由测试人员尝试设计测试用例。只有通过由易到难，由简单到复杂，不断反复的练习，才能慢慢建立起测试人员的测试概念、设计方法、捉虫的敏感度，并且保证他们不会走不必要的弯路。

　　在入职培训中，测试工具的培训已经逐渐提到议事日程上来。随着软件规模和复杂度的提高，纯粹意义上的人工测试已经不能满足软件测试各个方面的要求，因此对于测试工具的使用需求应运而生。为了使大家尽早成为会使用工具的高端测试人员，所以在入职培训中也应重视测试工具的培训。LoadRunner、WinRunner、TestDirector，这些常用的测试工具是需要让测试工程师尽早掌握的。网络上汇集了这些工具的大量资料，只是看我们如何自己整合打包形成适合自身需要的培训资料。

　　二、在职培训

　　入职培训不过是软件测试领域的一块敲门砖，能够带领初学者尽早领悟到测试工作中最精华的那部分内容。要想真正培养出一位合格的软件测试工程师，只靠入职培训显然是远远不够的。几年前曾听一位资深软件开发工程师提到过InJobTraining的概念。意思是说，作为工程师自己要注重工作过程中的自我培训，作为管理者更需加强在工作进程中对员工的知识灌输和能力培养。

　　InJobTraining可以是正式培训，也可以是非正式培训。按照以往经验，一对一式的非正规培训，其培训效果更容易得到保证。每经历一个产品或是项目的测试，都将是一次在职培训的极好机会。从跟随开发组开发用户需求开始，到协助开发组并审核开发组的功能设计，而后是测试工程师独立的完成测试设计工作，到最后的测试执行，测试管理者始终需要指导和带领测试工程师，教会他们在软件开发全生命周期的各个阶段，软件测试的工作目标、工作内容和结果物是什么。那些在入职培训中刚刚建立起的一点点测试概念和技术理论，需要在实际工作中得到最大化的尝试和实践。在在职培训过程中，测试管理者务必要花费较大的力气去审核测试工程师的各项工作，就如同在软件产品中捉虫一样，需要尽早发现每位测试工程师的工作漏洞、工作缺陷和改进的重点方向。不能以为通过入职培训，测试工程师就真的什么都已经学会了。不要忘记软件测试工作也是技术性很强的工作，和功能设计、代码开发一样，需要反复的实践，找出其中的不足，不断的加以改进，工作技能才能得到稳步的提高。

　　现在企业中定义软件测试工作范畴，恐怕大多数情况已经不再单纯是测试执行本身了。所以一批批软件测试工程师入职企业后，企业应该按照各位工程师不同的特点和特长，在在职培训过程中，为其选择重点进行培训，也就是进一步加强在职培训的趋向性。比如说，有人可能擅长完成较大规模功能的测试设计工作，那就重点培养其测试设计的能力；有人可能擅长利用测试工具开发测试案例，那就重点培养其测试工具开发的能力；有人可能具有极强的耐心、探究精神和怀疑的态度，那就重点培养其测试执行的能力；还有人可能具有一两年、两三年的开发经验，那就重点培养其白盒测试的能力。总之，在职培训过程中，应当依照测试工程师不同的工作经验和技术背景，为其正确选择重点培养方向。如果面面俱到，很有可能发生投入大产出小的低价结果，而且会挫伤测试工程师的积极性，同时也会影响到测试管理者对测试工程师的客观评价。更何况作为测试管理者，也不可能有足够的时间和精力，逐个培养每位测试工程师的每项能力。所以基于这点考虑，在职培训中加强目的性、重点性，明确培训的方向和目标就显得尤为重要了。

　三、软件测试工程师的职业生涯发展规划

　　相信经过正规的入职培训和有的放矢的在职培训之后，我们的测试工程师在一两年时间里都应该能够有一个长足的进步了。但此时新的问题发生了。做了几年的软件测试之后，我的发展前途在哪里？好像我该学的我能学的都已经学会了。这时候，一系列的危险信号会陆续出现在测试工程师的身上。敷衍了事，吃老本，另谋职位找工作。哎，测试管理者发出一声叹息：仿佛曾经的培训投入都将付之东流了。要想遏制这种不良事态的发展，我们有一解：做好软件测试工程师的职业生涯发展规划。

　　勿庸置疑，谁都不想一辈子只做一个测试工程师。更何况按照自然规律，做了两三年测试工程师之后，一定有更好的发展前景等待测试工程师们去开拓。高级测试工程师、测试经理、测试主管；软件品质保证工程师、高级品质保证工程师、品质保证经理、品质保证主管、品质保证总监，几个职业发展序列都可以由测试工程师去自由选择，而从一位普通的测试工程师发展成为品质保证总监，没有十年八年的技术积累和经验沉淀，也是很难实现的。

　　选择适合于测试工程师自身条件的目标，并为其明确目标，并在目标基础上为其设计呈阶梯状的职业发展规划，也是测试管理者对测试工程师实施培训工作的重要组成部分。

　　现代软件企业一般都已有一套科学合理的职位序列，并每年在固定时间内为每位员工评定企业内部的职位。在此期间，测试管理者应在充分了解和掌握测试工程师实际工作水平和当年业绩的情况下，评定出最新的职位水平。更为重要的是，要在此时为测试工程师仔细设计和规划下一年度的职业发展方向。是向高级测试工程师序列发展，还是向测试经理序列发展，还是向品质保证工程师序列发展，要定义好明确的方向。一是为了便于测试工程师了解自己当前的工作状态，以及与今后的发展目标存在的差距；二是为了加强测试工程师的工作热情和动力，让他们体会到企业的发展要依赖于他们个人的发展；三是为了企业能够明确自身人才结构和知识结构的现状，扬长避短，为今后不断发展壮大企业，积累自身实力并增强信心。

　　在设计软件测试工程师的职业生涯发展规划时，往往会陷入到一个两难的境地：一个工作出色的测试工程师，今后是往测试经理方向发展，还是向高级测试工程师方向发展。

　　从人们的传统意识上来讲，总是觉得当了测试经理好像就有了一官半职，远远要比高级测试工程师显得高贵得多。所以形成了千军万马想过测试经理独木桥的现象。如何决策，一句话，要以人为本，从测试工程师的自身条件出发。很显然，高级测试工程师主打自身的技术优势，只要保持技术优势就行了。而测试经理需要从无到有大量累积管理的能力和经验。最起码要具备经营能力、成本控制能力、工作统筹安排能力、人员管理能力、沟通协调能力等等。也就是说，如果选择了测试经理的发展方向，则无疑要付出更多的艰辛和努力，方可达到职位目标的要求。所以测试管理者在为测试工程师设计职业发展规划时，务必要冷静头脑、全面分析，不应也不能轰轰烈烈的一拥而上，让技术型人员去做管理工作，而擅长管理工作的人员就只在技术单方面谋求发展。

　　设计职业生涯发展规划的过程，严格意义上应该属于年度培训工作的开端工作，制定既定目标的工作。所谓万事开头难，为了一年甚至更长时间的软件测试工作卓有成效，测试管理者在开展好职业生涯设计工作的同时，务必要与每位测试工程师做好充分的沟通，达成双方的理解和共识，保证大家一条心，劲往一处使。在此测试管理者还可以借助外部的力量来完成沟通工作。如利用企业的人力资源部门、技术委员会的资源和力量，群策群力，优势互补，减少设计工作中的偏差，积累设计工作的经验和技巧。

　　以上只是凭借实际的一些工作经验，总结出来的有关软件测试工程师培训工作的一些心得。潦草几笔，不成体系，欢迎大家批评指正。

　　看看现在软件企业的发展前景，以及对测试人员、测试环境、测试工具的需求增长，我们真的要脚踏实地的做好软件测试工程师的培训工作了，抓好软件企业的第一生产力，凭借人的智慧和才干，提高我国软件企业的核心竞争力。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

posted @ 2013-04-18 10:13 顺其自然EVO 阅读(249) | 评论 (0) | 编辑收藏

自动化测试最佳实践连载一

　　《自动化测试最佳实践：来自全球的经典自动化测试案例解析》第0章案例研究反思，本章高度总结了现有经验中需要吸取的最重要的教训。本节为大家介绍自动化测试目标。

　　第0章　案例研究反思

　　成功的自动化测试需要智慧和毅力。你的经验可能和本书所描述的有一些相似之处，但每个人的故事都是独一无二的。通向成功的道路并不简单，但是正如书中案例研究所描述的那样，自动化测试已经在各种应用领域、各种环境和项目的各个生命周期中取得了成功。

　　通过思考，我们根据书中出现的案例和奇闻轶事总结出了一些方法。本章高度总结了现有经验中需要吸取的最重要的教训。你可能会在阅读完后面各个案例研究章节后再次阅读本章。

　　哪些主要因素促成了自动化测试的成功？导致自动化测试失败最常见的因素有哪些？

　　对这些问题没有简单而通用的答案，但存在一些公共的要素。我们认为最重要的两个要素是管理问题和测试件架构：

　　对自动化的管理层支持，包括设置切实可行的目标，以及提供足够合适的资源来取得已计划的ROI。

　　一个好的自动化测试件架构，拥有正确的抽象层，在降低自动化测试件维护和自动化测试各个方面成本的同时提供灵活性和适应性。

　　除了共同的要素外，还有其他一些方面，甚至是一些令人吃惊的要素，将它们也考虑进去可以帮助你在自己的自动化测试中取得更大的成功。这是我们写这本书的希望和目的！

　　在以下的大多数小节中，我们会着重强调一些章节号，并讨论一些特定的主题。这些主题可能也在其他章节涉及，我们会在这里列出各章针对某一特定主题进行的专门讨论。

　　我们首先在0.1节讨论管理层问题，但经理们也需要注意0.2节描述的技术问题。

　　0.1　管理层问题

　　从许多案例研究中可以清晰地了解到，管理层的支持力度关系到自动化测试的成功与失败。举例而言，第4、6、11、17和20章都叙述了管理层支持欠缺导致自动化测试失败的情形。

　　0.1.1　自动化测试目标

　　制订一个合适的目标对自动化测试的成功实施至关重要！这似乎是显而易见的，但令人惊讶的是，在没有任何清晰目标或仅仅是只有一些模糊的陈词滥调作为目标（如“更快的测试”、“做得更好”、“节省时间”）的情况下，一个自动化测试就开始了，这类事情经常发生。目标越具体，自动化测试越有可能得到好的评价并取得成功。

　　将软件测试所要达到的目标与自动化所要达到的目标区分开来是很重要的。自动化是运行测试的一种方法，无论这些测试是好还是坏。一个好的测试目标是发现许多bug。这没有必要成为一个好的自动化测试目标：在近期对项目进行一些改动之后，需要进行回归测试以确保变更的部分不会影响系统的行为，而这类测试很少发现新的错误。这并不意味着自动化测试不成功，只是因为它有了错误的目标。如果一个高层经理感到自动化测试没有达到预期目标（即使这个目标是一种误导），那么资金也可能被撤掉。

　　0.2.9节讨论了一些能够有效地找到bug的自动化测试示例。一些好的自动化测试目标在第1、2、3、6、7、10、11、12、14、20、21、25、27和29章中讨论。

　　0.1.2　管理层支持

　　在一个无法对自动化测试进行精心培育并有效引导的组织中，自动化测试很难成功发展起来。对于个人来说最好先亲自试验一下，如果想要大规模地进行自动化测试，并能收获自动化测试对于产品最终发布所带来的巨大好处，则需要管理层的大力支持。一种“自下而上”的方法并不是通向良好自动化测试的一条长期可持续的道路。

　　管理层支持对自动化测试的成功至关重要；我们可以在本书的很多案例研究中看到这一点。管理层支持包括多种形式：对工具的资金支持，对于一个试点项目和测试件架构的开发过程的资金支持，以及为此需要付出的时间，管理层还要有兴趣去理解自动化行为以监督成本与回报（参见A.3节的ROI）。

　　对于经理来说很重要的一点是，对于自动化过程他能够提供什么，以及对要达到期望的结果需要付出时间与努力有着很明确的了解。

　　在某些案例中，一些高层的经理并不十分了解好的自动化测试意味着什么。这可能是因为他们没有很好地亲自调查，但另一个因素可能是做自动化测试的人员没有积极沟通，虽然沟通是他们本应该做好的事情。

　　与管理层沟通的重要性主要在第1、4、6、13、20和29章中进行强调，而具体作法则在第16、19和29章中涉及。管理层支持作为示例学习的关键因素在第1、2、6、11、18、21章中进行了强调。　
0.1.3　ROI和度量标准

　　一个普遍的误解是，成功的自动化测试仅仅需要购买相应工具的投资（如果你得到一个开源工具，那就不需要其他任何花费）。如果在自动化方面的投资为0，则其投资回报率可能为负值。简而言之，如果你什么也不投入，你将会陷入麻烦！

　　要在以下方面进行投资：对于观点的研究和实验；设计和开发一个好的自动化测试件架构；学习和了解失败和成功的因素；找到符合特定情况的解决方案；就自动化测试计划、进度及测试方法进行沟通。

　　常常在一个自动化测试开始时评估ROI。这是一个很明智的做法：相对于自动化测试的投入，是否获得了更多的收益并节约了资金？执行自动化测试的理由通常是比较执行同一测试手动和自动所花费的时间。尽管这是证明自动化测试有用的方法，但仅仅执行自动化测试并不是全部。实现自动化测试的时间，对自动化测试的维护，分析错误测试的时间以及其他一些可能比手动测试花费更多时间的任务。这些其他任务可能是一个重要的额外开销，也应该考虑。要知道如果你使用一个工具供应商的ROI计算器，这些其他的开销可能不包括在ROI的计算中。

　　其他需要考虑的因素包括：更高的覆盖率（已经测试过的系统数量），最少的时间推向市场，以及增长的信心。但这些益处在早期的自动化测试实施中可能无法实现。它们会在自动化测试一旦完成之时变成现实。它们同样难以量化，因此也可被看做额外的收益。

　　一旦一个自动化测试建立，看它能否达到预期也是非常重要的，因此最好定期做这样类似的比较（将所有因素考虑进去），并且将这一信息和负责资金的管理层交流，这是非常重要的。

　　许多人混淆了收益（benefit）和ROI。收益只是收益，而ROI则是将收益与成本有效地进行比较。

　　请记住，你决定收集的度量标准可能被误解，也许它没能传达你所希望的意思。也请注意，那些在新的上下文中不再有用的度量标准；第28章描述了自动化测试的职业生涯的影响。

　　ROI和量化收益在第1、2、9、12、13、18、23、26和29章中讨论。在第9章有一个用来评判投资的基于模型测试的ROI计算器的范例。

　　0.1.4　在敏捷开发中的自动化测试

　　随着敏捷开发变得更加普遍，其自动化测试也变得越来越重要。持续的集成就是测试自动化；回归测试每天都要进行，有时候甚至更为频繁。自动化测试也需要在出现变更时能做出响应，就像敏捷开发中那样，于是测试件架构便显得更加至关重要（参见0.2.1节）。自动化测试在传统开发和敏捷开发中都取得了成功，没有自动化测试，敏捷开发就不会成功。

　　敏捷技术，如测试驱动的开发（Test-Driven development，TDD）可以确保自动化的单元测试，但是对使用敏捷方法开发的系统仍需要进行系统测试。第1章主要讲述的是敏捷开发中的自动化测试；敏捷项目中的自动化测试也在第6、7、17、18、19和21章中提及。

　　0.1.5　技能

　　测试人员所需要的技能和自动化测试人员不同，自动化测试人员的角色可以看做测试人员和工具之间的桥梁（参见0.2.1节）。

　　自动化测试人员的角色有着严格的区分：一类是高层次的自动化设计人员（测试架构师，test architect），另一类是自动化测试件的实现人员，自动化测试人员（test automator）可以用于这两类人员。自动化测试架构师的任务是设计自动化测试的整体结构，或者为了创建好的测试件架构而选择框架，或是将现有框架进行改进以适应新的需求。自动化测试人员的任务是设计、编写、维护自动化测试的软件、脚本、数据、期望结果以及额外的实用工具。自动化测试人员负责实现多个层次的抽象（在0.2.1节中讨论），这使得测试人员不必学会编程就可以使用这些自动化手段。自动化测试人员同样可以帮助测试人员，包括解决技术上的问题、决定花费/ 收益的比率，以及实现新的测试需求等。自动化测试人员必须有好的编程基础。

　　有这样一种趋势，即测试人员同时也是开发人员。如果测试人员同时还是一名好的程序员，那么这个人既可以成为测试人员也可以成为自动化测试人员——我们讨论的是不同的角色，他们不一定是不同的个人。

　　然而，很多测试人员并不一定擅长技术，而且他们也不想成为程序员。就如Hans Buwalda说的，强迫一名非技术的测试人员去做程序员，不仅会使你失去一名好的测试人员，还会让你得到一名不称职的程序员。非技术的测试人员也应该参与自动化测试！如果将他们从自动化测试的过程中排除，就不能充分发挥这些测试人员的技能，从而也无法充分挖掘出自动化测试的潜力。

　　测试人员和测试自动化人员的角色在第10、12、18、19、20、23和29章中讨论。

　0.1.6　计划、范围和期望

　　当自动化测试有好的计划时，它通常更有可能获得成功。计划应当包括，在自动化测试应用于整个项目前花些时间进行一些实验。例如，一个限制时间的试点项目，让你能更清晰地看到如何达到自动化测试长期目标的方法，当然这个项目也要有清晰的目标和足够的资源。

　　不要期望自动化项目中不会出现任何问题；没有什么事情是没有问题的！应该随时准备应对可能出现的问题。记住即使是最好的计划也仅仅是一项指导——要根据情况去重新审视这些计划。

　　设定符合实际的目标，即在规定时限内完成任务，并且定义好项目的范围。不要太过于关注细节，否则就无法在公司中获得那些潜在的收益。要关注在早期就能得到的一些有用的结果，而不要以减少有用的自动化测试为代价，去构建过量用于支持测试复用的库。一旦自动化测试开始运行，要继续寻找方法去改进这些自动化测试，并且为自动化测试设立新的目标以减少花费和增加收益。

　　第1、5、6、11、16、20、25和29章讨论了这些问题，第1、3、23和27章还讨论了如何持续地改进自动化测试过程。

　　0.1.7　和开发人员的关系

　　在成功的自动化测试实践中通常有一项因素，即在测试人员、自动化测试人员和开发人员之间保持良好的关系。如果他们的关系不好，那么自动化过程就会更加艰难，即便自动化测试在最后还是会带来一些收益。如果软件在设计时没有考虑到自动化，那么自动化测试就会变得非常困难。例如，如果软件使用了非标准的控件，那么自动化测试就很难和软件进行交互。测试人员或者自动化测试人员或许会对开发人员说：“请仅仅使用标准的控件——这会使得我们的工作更加容易。”但是开发人员的时间很仓促，可能会说：“我们为什么要做一些不会给我们带来好处的事情呢？”这个开发人员并非很无理，这确实是一个相当合理的原因（虽然一些测试人员不会同意这个观点）。

　　更好的方法是告诉开发人员自动化测试是如何让他们受益的，并且和他们保持良好的合作关系。例如，如果你能够在15分钟内在测试环境中对一个新编码的函数运行测试，你就能够在一定时间内向开发人员提供有用的信息（找到了bug或者测试已经通过），这对他们是极大的帮助。

　　关于开发人员和自动化测试人员的关系在第1、2、6、9、17、20、27和29章中讨论。

　　0.1.8　促进项目改变并启动自动化测试的触发器

　　是什么让一家公司决定它们应该采用自动化测试？有时，因为测试不足所带来的严重问题或者近期的灾难，促使公司做出改变；有时，来自公司外部的观点也会带来更好的解决方案；有时，管理层决定公司需要自动化测试，这甚至决定了公司的生存。人们总是先尝到了苦头，然后才会进行实际的改变。

　　对于那些打算应用自动化测试的公司，最重要的建议是要从小范围开始应用。试点项目（pilot project）是个好主意，在将自动化测试扩展到更广的范围之前先在小范围内尝试不同的方法，来判断哪种方法最好。

　　这些问题在第1、9、10、12、17、23、26、27和29章中讨论。

0.1.9　工具和培训

　　人们经常会问一个问题，哪个工具是最好的？这就像问哪个汽车最好一样。一个人认为最好的车是能够容纳四个小孩和两条狗的车；另一个人可能更关注于车的速度和性能；还有一些人关注哪个车更经济一些。因此，没有完美的工具，但是有很多工具是足以应对某些特定场景的。

　　事实上，正如第17章讲述的那样，有时可能会选择错误的工具，因此为所要做的工作选择合适的工具是很重要的。在第17章中错误使用的工具却在第7章和第25章中取得了成功。

　　但是工具不是测试自动化最重要的因素。是的，通常确实需要使用工具来执行测试，但是在大多情况下，好的自动化测试的其他方面远远比因单独工具之间的差异所带来的影响要大得多。拥有好的工具不能保证在测试自动化中取得成功——必须对整个测试框架进行良好地计划、定制和维护，工具仅仅是一小部分。

　　使用一个工具失败并不意味着使用其他工具就能取得成功；一些公司尝试了一些工具但是在每次尝试中都以相同的方式失败了。遗憾的是，公司经常将这些失败归咎于工具或者个人，而实际原因在于自动化测试项目没有进行足够的计划和管理。

　　工具的主要用处是为人员提供支持！那些将要使用工具的测试人员应该在如何使用这些工具上有话语权，而且公司应当为工具提供基础设施以支持他们。

　　无论使用什么工具，培训都是很重要的。那些将会直接使用工具的人应该在早期就接受一些深入的培训，无论是通过工具生产商的课程或者在线教程。如果公司引进组织外部的顾问或者工具生产商的技术支持人员来进行培训，将每次会议的间隔日期进行适当调整，以便在这段时间中测试人员能够吸收这些知识并且对他们所学到的内容有实践的时间。之后，为那些需要使用这个自动化工具的人提供培训，告诉他们自动化测试应该如何进行——这是内部培训，而不是外部培训。良好的培训能够避免浪费很多时间。

　　关于工具和培训相关的问题会在第1、6、11、12、13、18、19、21、23、25、26和29章中讨论。

　　0.1.10　行政因素

　　在自动化过程中，有一些因素是测试人员、测试自动化人员，甚至是经理或者其他利益相关者无法控制的；例如，可能会因为一个主要项目的取消，导致为成功的自动化测试付出的努力也变成徒劳。

　　很多测试人员和自动化测试人员之所以艰难地进行一些项目，可能仅仅是因为他们经理的一句看起来随意的话。第29章中的奇闻轶事就举了这方面的例子，还有在第4章中，经理的行为“谋杀”（虽然这可能是“过失杀人”，而不是“谋杀”）了自动化测试。第28章举了一个例子，即当自动化测试带来的改进是如此巨大，以致经理都不肯相信这些结果。

　　行政因素是生活的一部分；做出的决定并不经常像看上去那样合理。

　　（未完待续...）

posted @ 2013-04-18 10:12 顺其自然EVO 阅读(207) | 评论 (0) | 编辑收藏

基于APPIUM的移动自动化测试

　Appium一款开源自动化测试工具，可以非常快捷的为iOS和Android移动平台创建功能自动化测试用例。相比其他的移动自动化测试工具，Appium测试由于调用了Selenium的client库使其可以使用任意的语言，包括Python、Ruby、Node.js,Objective，java等。

　　本文我们主要讨论如何通过junit java example tests测试完成iOS sample apps的测试（此处我们还会创建TestNG example Tests）

　　当然在开始之前，我们首先需要下载Appium，下载地址为https://github.com/appium/appium，根据安装说明我们可以完成Appium的安装。

　　运行以下命令行构建sample projects：

grunt buildApp:TestApp
grunt buildApp:UICatalog

　　一旦sample projects完成构建，即可通过以下命令启动Appium：

grunt appium

　　变更工作目录到sample-code/examples/java/junit，运行测试

mvn test

　　或运行单个测试：

mvn -Dtest=com.saucelabs.appium.SimpleTest test

　　Java Appium测试与Selenium Test非常的相似，你可以创建一个RemoteWebDriver实例并指定DesiredCapabilities，脚本如下：

@Before
public void setUp() throws Exception {
    // set up appium against a local application
    File appDir = new File(System.getProperty("user.dir"), "../../../apps/TestApp/build/Release-iphonesimulator");

    File app = new File(appDir, "TestApp.app");
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(CapabilityType.BROWSER_NAME, "iOS");
    capabilities.setCapability(CapabilityType.VERSION, "6.0");
    capabilities.setCapability(CapabilityType.PLATFORM, "Mac");

    //tell Appium where the location of the app is
    capabilities.setCapability("app", app.getAbsolutePath());

    //create a RemoteWebDriver, the default port for Appium is 4723
    driver = new RemoteWebDriver(new URL(http://127.0.0.1:4723/wd/hub), capabilities);
}

　　完成以上脚本后即可直接通过类似selenium测试的方式完成测试脚本：

@Test
public void example() throws Exception {

    // find an element by tag name
    WebElement button = driver.findElement(By.tagName("button"));
    button.click();

    // get the value of the element
    WebElement texts = driver.findElement(By.tagName("staticText"));
    assertEquals(texts.getText(), "some expected value");
}

posted @ 2013-04-18 10:07 顺其自然EVO 阅读(533) | 评论 (0) | 编辑收藏

中国平安银行关于软件测试笔试试题（三）

　　接：

　　中国平安银行关于 软件测试笔试试题（一）

　　中国平安银行关于软件测试笔试试题（二）

　　多选题

　　1、基于组件设计的系统特征包括(该题为必答题)

　　封装
　　耦合
　　内聚
　　抽象

　　2、可能与正在运行的进程无关的中断事件有（）等(该题为必答题) 2 5

　　硬件故障
　　外部
　　访管
　　程序性
　　输入/输出

　　3在oracle数据库中，关于索引描述正确的是(该题为必答题) 2 3 4

　　需要对大数据类型创建索引
　　对于大表，索引能明显提高查询效率
　　在数据表上创建唯一约束，会自动生成唯一索引
　　我们最常用到的是B-Tree索引

　　4、以下关于主键和唯一索引的区别有哪些是正确的？(该题为必答题) 2 4

　　主键：默认将是聚簇索引唯一索引：默认将是非聚簇索引
　　主键不能空，唯一索引可以为空
　　主键顺序为数据的物理顺序
　　主键每个表只能有一个，唯一索引可以多个

　　5、下面哪些是DML语句(该题为必答题) 2 4

　　MERGE…
　　UPDATE…
　　COMMIT…
　　DELETE…

　　6、下面那条语句编译不会出现错误？(该题为必答题)

　　float f = 123;
　　int x = (int)(1.23);
　　Boolean b = new Boolean(“abcd”);
　　byte b = 127;

　　7、以下对于会话跟踪的描述，正确的是(该题为必答题)

　　客户浏览器禁用了cookie后，可以使用HttpServletResponse接口中的encodeURL（）方法对URL编码。但客户如果没有禁用Cookie，使用HttpServletResponse接口中的encodeURL（）方法对URL编码会出错
　　使用HttpServletResponse接口中的encodeURL（）方法对URL编码后，这个方法把以分号开头的字符串形式的路径加入到输入的URL中，如：jsessionid＝123456789
　　客户浏览器禁用了cookie后，在Servlet中的getSession方法就无法获得HttpSession对象了。
　　只要使用HttpServletResponse接口中的encodeURL（）方法对URL进行编码，Web应用程序的用户在浏览器中禁止cookie和不禁止cookie都是一样的

　　8、黑盒一般知识可以发现以下类型的错误：(该题为必答题) 1 2 4

　　性能错误
　　功能错误或遗漏
　　数据结构或外部数据库访问错误
　　界面错误

　　9、常用的黑盒一般知识方法一般知识包含以下哪些类别？(该题为必答题) 1 2 5

　　边界值分析
　　决策表法
　　因果图法
　　控制流测试法
　　等价类划分

　　10、如下哪些工具可以作为缺陷管理工具：(该题为必答题) 1 2 4

　　Bugzilla
　　ClearQuest
　　FindBugs
　　QualityCenter

　　11、软件开发模型包括(该题为必答题) 123

　　迭代模型
　　螺旋模型
　　瀑布模型
　　扇形模型

　　12、上下文关系图(context diagram)的作用是(该题为必答题) 2 4

　　定义业务规则
　　外部系统和人与系统之间交互的方式
　　定义系统的上下文和范围
　　概括与系统之间相互影响的重要的外部系统和人

　　13、系统出现死锁必然出现以下情况(该题为必答题) 1 2 4

　　不可抢夺资源
　　互斥使用资源
　　循环等待资源
　　占有并等待资源

　　14、关于Oracle的LONG类型描述正确的是：(该题为必答题) 1 3

　　LONG类型主要用于不需要作字符串搜索的长串数据，如果要进行字符搜索就要用varchar2类型
　　LONG 数据类型中存储的是可变长字符串，最大长度限制是2GB
　　一个表中只能包含一个 LONG 类型的列
　　索引LONG类型列会明显提升查询效率

　　15、在ORACLE的排序SQL，下面哪些写法是正确的。(该题为必答题) 2 4

　　Select distinct ename,sal from emp where deptno=30 order by deptno
　　Select * from emp where deptno=30 order by ename
　　Select ‘Name: ‘|| ename ,sal from emp Where deptno=30 Order by 2,1
　　Select ename “Employee”,sal “salary” from emp Order by “salary” desc , “Employee”，deptno

　　16、关于JSP和SERVLET的描述正确的是：(该题为必答题)134

　　JSP能够访问Java API，具备SERVLET的全部优点
　　JSP页面只能在接受请求时动态编译成SERVLET
　　JSP技术构建在SERVLET上，它是支持HTML和XML页面制作的SERVLET技术的扩展
　　JSP页面支持嵌入javascript内容

　　17、下面叙述哪些是正确的(该题为必答题)234

　　java中，子类不可以访问父类的私有成员和受保护的成员
　　java接口包含函数声明和常量声明
　　在java中，可以用异常（Exception）来抛出一些并非错误的消息，但这样比直接从函数返回一个结果要花费更大的系统开销
　　java中的集合类（如Vector）可以用来存储任何类型的对象，且大小可以自动调整。但需要事先知道所存储对象的类型，才能正常使用

　　18、log4j中输入日志有哪些级别设置(该题为必答题)1234

　　FATAL
　　WARN
　　DEBUG
　　INFO

　　19、软件的可测试性包括以下方面（）(该题为必答题) 13

　　可观察性
　　可分解性
　　可确认性
　　可重用性
　　可控制性

　　20、常用的白盒一般知识方法一般知识包含以下哪些类别？(该题为必答题)234

　　边界值覆盖
　　条件覆盖
　　路径覆盖
　　语句覆盖

　21、关于黑盒一般知识，说法正确的有：(该题为必答题)1234

　　黑盒测试把软件系统看成一个黑盒子，完全不考虑软件内部逻辑结构和处理过程
　　黑盒测试是基于规格和数据驱动的测试，它的依据是需求规格
　　黑盒主要关注被测软件的功能和非功能属性的实现
　　测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性

　　22、下面哪些属于静态分析？(该题为必答题) 2 4

　　程序复杂度分析
　　代码规则检查
　　内存泄漏检查
　　程序结构分析

　　23、多线程技术具有哪些优越性(该题为必答题) 3

　　通信简洁、信息传送速度快
　　创建速度快、系统开销小
　　并行性高
　　安全性高

　　24、The ThreadGroup class instance()(该题为必答题)

　　Must contain threads of the same type
　　May contain other ThreadGroups
　　Provides support for ThreadDeath listeners
　　Allows threads to be manipulated as group

　　25、下面关于继承的叙述哪些是正确的(该题为必答题) 23

　　在java中一个类不能同时继承一个类和实现一个接口
　　java的单一继承使代码更可靠
　　在java中只允许单一继承
　　在java中一个类只能实现一个接口

　　26、关于软件测试，正确的描述包括( )。(该题为必答题) 1234

　　要尽量避免测试自己编写的程序
　　测试前应该假设被测试的软件有错
　　测试是相对的，不能穷尽所有的测试，要据人力物力安排测试，选择好测试用例与测试方法。
　　测试要兼顾合理输入与不合理输入数据

　　27、软件验收测试的合格通过准则是：(该题为必答题) 1 2 3

　　立项审批表、需求分析文档、设计文档和编码实现一致
　　验收测试工件齐全
　　软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求
　　所有测试项没有残余一级、二级和三级错误

　　28、关于等价类划分测试方法一般知识说法正确的是(该题为必答题) 13

　　等价类划分可有两种不同的情况：有效等价类和无效等价类
　　测试某等价类的代表值就等于对这一类其它值的测试
　　等价类是指某个输入或输出域的子集合
　　同一等价类中输入数据对于揭露程序中的错误的作用有大有小

　　29、涉及到“数字”的软件功能，在设计测试用例时要优先考虑（）的测试方法一般知识(该题为必答题) 3 4

　　错误推测法
　　因果图方法
　　边界值分析法
　　等价类划分法

　　30、某程序规定：“输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形及等边三角形时，分别做计算…”。

　　用等价类划分方法为该程序的构成三角形部分进行测试用例设计。下面那些等价类划分是合适的？(该题为必答题) 13

　　整数
　　正数
　　非零数
　　函数
　　负数

　31、关于UML类图下列描述正确的是(该题为必答题) 1 2 3 4

　　关联是两个类之间的一条实线
　　类图表示各个对象的类型以及其间存在的各种静态关系
　　类间的两种重要关系就是关联与泛化
　　UML中抽象类是将名用斜体表示

　　32、关于用例，描述正确的是(该题为必答题)12345

　　包括至少一个参与者
　　由一组场景组成,包括主流程和备选流程
　　定义一系列系统完成的活动
　　围绕一个完整功能块
　　描述参与者与系统之间的交互
　　产生的结果对某个参与者有价值

　　33、在ORACLE中，下面哪些命令用来处理事务：(该题为必答题)1 2 3 4

　　set transaction
　　commit
　　savepoint
　　rollback

　　34、java中overload与overwrite的区别(该题为必答题) 1 3

　　overwrite 重写继承到的那个方法的代码，原方法被放弃。
　　overload 覆盖继承到的那个方法，那个方法仍然没有放弃。
　　overload 完全新的方法，参数和原方法不同。
　　overwrite 完全新的方法，参数和原方法不同。

　　35、正则表达式的主要功能是(该题为必答题)1 2 3

　　替换代码
　　提取代码
　　查询代码
　　分割代码

　　36、下面的说法正确的是：(该题为必答题) 2 3 4

　　File类是输入/输出流类的子类。
　　Java中IO流的处理通常分为输入和输出两个部分。
　　InputStream与OutputStream类通常是用来处理字节流，也就是二进制文件。
　　Reader与Writer类是用来处理字符流，也就是纯文本文件。

　　37、进行自动化测试的评估标准有（）(该题为必答题) 1 2 3 4

　　可自动化率
　　测试进度要求
　　版本规模
　　版本稳定程度

　　38、下面哪些属于动态分析？(该题为必答题) 14

　　系统压力测试
　　设计复审
　　程序数据流分析
　　代码覆盖率

　　39、正则表达式 a*b*c 匹配( )(该题为必答题) 1 3 4

　　ac
　　a*b*c
　　abc
　　bbc

　　40、在ORACLE中，以下语句出错，哪些改动能够正确执行：(该题为必答题) 3

SELECT deptno, max(sal)
FROM emp
GROUP BY deptno
WHERE max(sal)>2500;

　　将WHERE max(sal)>2500语句改成WHERE sal>2500
　　将WHERE max(sal)>2500语句改成HAVING sal>2500
　　将WHERE max(sal)>2500语句改成HAVING max(sal)>2500
　　将WHERE和GROUP BY 语句顺序调换一下\\

41、java线程实现有哪几种方式？(该题为必答题) 1 3

　　实现Runnable接口
　　通过线程池创建
　　继承thread类
　　自主开发

　　42、关于synchronized和java.util.concurrent.locks.Lock描述正确的是(该题为必答题) 1 2 3 4

　　Lock拥有更精确的线程语义
　　Lock要求程序员手动释放锁，synchronized会自动释放锁
　　Lock能完成synchronized所实现的所有功能
　　Lock有比synchronized更好的性能

　　43、java中io与nio的差异(该题为必答题) 1 2 3 4

　　io采取了多个线程处理运算
　　nio采取了轮询方式节省了咨询提高了效率
　　nio解决了数据的处理速度
　　nio采用了一个线程处理运算

　　44、一个测试需求应该包括以下要素：(该题为必答题) 1 2 3 4

　　重要性，测试需求对最终用户的相对重要程度
　　稳定性，测试需求发生变化的可能性
　　需求描述
　　需求名称，对需求的简短说明。

　　45、关系数据库中，典型的实体关系模型有哪几个要素(该题为必答题)1 2 4

　　关系
　　属性
　　索引
　　实体

　　46、以下赋值语句，错误的是：(该题为必答题) 23

　　char c5=65;
　　Char c3=’x';
　　char c4=”;
　　char c1=’\”‘;

　　47、关于static的含义说法正确的是(该题为必答题) 2 3 4

　　被定义为static的方法可以被继承
　　我们不可从一个static方法内部发出对非static方法的调用
　　被定义为static的方法不可以被继承
　　它意味着一个特定的方法没有this

　　48、编写测试计划的目的有(该题为必答题)12345

　　软件工程以及软件过程的需要
　　使测试工作顺利进行
　　使测试工作更加系统化
　　使项目参与人员沟通更舒畅
　　软件过程规范化的要求
　　控制软件质量

　　49、正则表达式 a?b?c 匹配( )(该题为必答题)1 2

　　abc
　　ac
　　a?b?c
　　bbc

　　50、性能测试包含了以下哪些测试(该题为必答题)1 2 3

　　并发测试
　　UAT测试
　　压力测试
　　负载测试
　　安全测试

判断题

　　1、UML图中带虚线的箭头表示的是两个模型间的关联关系(该题为必答题) 错

　　2、在当前目录下解压归档文件this.tar.gz ，我们可以使用命令：$tar xvzf this.tar.gz(该题为必答题) 对

　　3、truncate和delete都可以用来删除表中所有的记录。区别在于Delete是DDL操作,不需要rollbacksegment(该题为必答题) 错

　　4、选择索引字段，首先考虑查询数据区分度是否高，如果区分度不高则适合创建索引(该题为必答题) 错

　　5、在java中GC的含义是垃圾收集器(该题为必答题) 对

　　6、forward 执行在客户端而sendRedirect() 执行在服务器端。(该题为必答题) 错

　　7、自动化测试不一定需要专用的工具，使用通用的程序语言也可以进行自动化测试(该题为必答题) 对

　　8、在时间有限的情况下，应该优先测试典型值，而不是边界值(该题为必答题) 错

　　9、系统测试的测试目标一定是软件系统，而不会包含硬件环境(该题为必答题) 错

　　10、文字错误均属于严重程度很低的缺陷，因此不需要过多关注(该题为必答题) 错

　　11、系统测试的测试对象，仅仅是对应于被测软件。(该题为必答题) 错

　　12、UML中表示一个抽象类的方法是用斜体来书写类名的(该题为必答题) 错

　　13、目前32位操作系统可以指定的堆大小的上限是1G(该题为必答题) 对

　　14、SYNONYM是指向其它数据库对象的数据库指针(该题为必答题) 对

　　15、Java 程序里创建新的类对象使用关键字new，回收无用的类对象使用关键字free。(该题为必答题) 错

　　16、每个类都继承了Object类，所以都实现了toString()方法。(该题为必答题) 对

　　17、性能测试应该仅从请求和响应情况评价系统性能(该题为必答题) 错

　　18、有了专职的测试人员，开发人员就可以专注于开发，不需要再做测试(该题为必答题) 错

　　19、测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。(该题为必答题) 对

　　20、边界值出现缺陷的几率较高，因此应该优先对边界值进行测试(该题为必答题) 对

　　21、白盒是较黑盒更有技术含量，等级更高，更有效的测试，未来将最终代替黑盒(该题为必答题)错

　　22、类图中的关联包含单向关联和双向关联两种(该题为必答题) 对

　　23、Collection是集合类的上级接口，Collections是针对集合类的一个帮助类。(该题为必答题) 对

　　24、classloader是分层次的，它只能加载比它层次高的类及它自身的类，同层次的类及比它层次低的类都不能加载(该题为必答题) 错

　25、软件实现了需求规格说明书中未指定的功能，这也是一种缺陷(该题为必答题) 错

　　26、在测试算法时，应该尽量使用与被测程序相同的计算方式（最好是借用其代码片段）来计算预期结果(该题为必答题) 错

　　27、测试时除了依照软件需求规格说明书以外，还可以参照标准、惯例和通用法则。(该题为必答题) 对

　　28、并发用户数一般指一段时间内访问系统的用户数量。(该题为必答题) 错

　　29、开发人员自己认为很可能存在缺陷的地方，真正存在缺陷的可能性也很大。(该题为必答题) 对

　　30、一个用例包包含用例、角色，可能包含其他用例包(该题为必答题)对

　　31、线程是进程的中的一个实体，通常一个进程有若干个线程，但同一进程中的多个线程不能并发执行。(该题为必答题) 错

　　32、表的设计必须遵循第一范式，尽量达到第二范式及第三范式(该题为必答题) 对

　　33、接口可以继承接口。(该题为必答题) 对

　　34、当系统内部实现发生变化，而外部接口不变时，黑盒案例也需要随之改变(该题为必答题) 错

　　35、划分了等价类后，应该在每个等价类选取20%以上的值进行测试(该题为必答题) 错

　　36、构建阶段的详细设计和编码，可以采用结对编程等极限编程的方式来带新人，提高代码质量；采用迭代编程来降低风险(该题为必答题) 错

　　37、选择索引字段，首先考虑查询数据区分度是否高，如果区分度不高则适合创建索引(该题为必答题) 错

　　38、java中对于后递增和后递减（如A++或A–），会先执行运算，再生成值(该题为必答题) 错

　　39、在java代码中输入字符时，向操作系统传递的数据经过了中间的编码环节(该题为必答题) 错

　　40、自动化测试脚本与程序不同，通常不需要写注释(该题为必答题) 错

　　41、使用黑盒方法分析被测系统，不需要了解其内部实现(该题为必答题) 对

　　42、测试活动可以为软件质量改进和管理提供帮助(该题为必答题) 错

　　43、在测试术语中，“验证”指保证软件正确的实现了某一特定功能的一系列活动(该题为必答题) 对

　　44、发现错误多的模块，残留在模块中的错误也多(该题为必答题) 对

　　45、软件测试就是找到软件的错误(该题为必答题)对

　　46、Order by 子句仅对检索数据的显示有影响，并不改变表中行的内部顺序(该题为必答题) 对

　　47、四则运算中，除法会产生错误（被0除），而乘法不会产生错误(该题为必答题) 对

　　48、如果一个软件既要做白盒也要做黑盒，那么应该首先设计黑盒的用例(该题为必答题) 错

posted @ 2013-04-17 11:16 顺其自然EVO 阅读(3780) | 评论 (0) | 编辑收藏

软件测试与开发的未来

　今天与何老大的一些交流，引发一些心中很久的感想表达一下，主要是针对我们开发过程一些幻想，最后给出实现的规化方式。

　　1、云开发平台

　　我们开发人员整天忙忙碌碌，重复最多的就是编写代码->编译->简单测试->改代码->编译...

　　云开发平台正是为解决这个问题而来，它是什么呢？

　　所谓云，就是对使用者透明，所谓云开发平台，是指对我们开发人员（测试人员）几乎透明的编译调试环境。

　　你要做什么？

　　告诉它你的项目地址，告诉它你的编译方式。

　　它帮你做什么？

　　1、监控你的项目，有提交时帮你编译，返回编译结果。

　　2、准备环境，提供一个云端返回的编译完成的主机（我们的测试机），可以登录ssh进行测试。

　　2、开发过程自动化测试

　　我们现在正在测试前移，甚至在需求阶段介入，我这里不关注需求的测试方法，只说测试前移怎么去做？我们现在在强调前期的代码审查测试，前期的逻辑检查，这些属于白盒但是静态检视，我以为这些可以去做好，但仅仅对前期测试来说能暴露的问题有限，更多的时候需要靠更多的编码经验。

　　而开发人员在编码时更多的时间花费在调试（大约80%不为过），这部分工作实际上可以减少很多，而且大家也知道，如果更多的时间用来设计与编写高质量代码，测试的工作量也会更少，能够有效提高整个研发效率，而现在的问题是，开发不知道如何利用工具改进开发过程。

　　开发过程自动化测试是指，提供一种易用性框架，利用自动化测试优势，将过程的重复工作实施自动化测试，将每次都需要验证的测试点实现自动化验证。

　　效果是：

　　开发设计完成，开发编码。

　　测试前移，准备测试点，编写自动化用例。

　　利用某一个统一的平台进行交付自动运行。

　　难点一：对测试人员要求较高，但我们可以培养。

　　难点二：对开发有一定惯例限制，但每一次的限制用的好可以带来更大的自由（好处）。像如今满大街的智能机不是对键盘的限制使用吗？

　　最后一点，也是最宏大的。

　　3、研发管理平台：

　　越来越多的流程，越来越繁琐的文档，越来越混乱的IT系统，经常这个账号记不清另一个账号无法登录的。

　　申请序列号这种小事都需要助理来处理，试想我们如果有一套完善的认证系统不可以自动下发序列号吗？系统会记录的更清楚。使用的人也会得到最快速的响应。

　　开发改了需求没有通知我！！！

　　忘了xx文档的svn地址了！！！找其他人问还十分不好意思，有时候还得不到立刻答复，又影响他人。

　　SQA累死累活的跑路收集各种信息，但却依然可能受到大家的数据置疑。

　　一项流程更新，通报了全研发体系却大部分的人在真正执行时仍然遗忘。

　　。。。

　　问题已经比较突出了。我们应该怎么做？

　　研发管理平台，正是我们的需要。

它的核心功能：

　　1、统一接入认证体系。保证内网安全可靠，并提供完善的日志。

　　2、集成研发流程，提供从需求到发布的过程跟踪。可强制限定开发经理与测试经理的活动。并做到智能提醒。（试想，每天我作为开发经理只需要登录一下系统就知道接下来该干什么，每天只需要一次提交每日进展即可，并可随时查询项目成员的代码提交质量；而项目责任人无需过多信息，通过研发管理平台即可收集到项目的信息）

　　例如，需求过程可以简化，只需要一次录入需求，以后每次需求变更，所有相关人员自动接受邮件，任何需求过程均被记录，系统发布前提供需求完成情况，自动形成可发布文档。

　　3、集成自动化测试，提供统一的静态扫描并与ATM做接口。提供数据仓库可以随机构建有效数据，提供虚拟化硬件平台，任何人在需要的时候一键获取测试主机进行快速接入验证。

　　4、具备数据分析甚至挖掘能力，提供一定的SQA职责，供决策使用。

　　我们来初步分析一下，

　　1、云开发平台

　　实现难度：中（监控svn应该不成问题，提供调试编译环境，这点可通过部门虚拟设备解决，我们自动化已经基本解决虚拟设备实现克隆，开启，关闭，甚至修改ip，执行任何命令的操作，剩下的就是工作量与需求问题，其他难度在于解决不同环境部署的约束）

　　实现工作量：低

　　实现效果：能够节省每个开发人员的重复操作并易出错的问题。

　　限制：需要开发人员配合实现代码文件存放和命名约束，以及相关需求细化。

　　2、开发过程自动化测试

　　实现效果：大规模提高发包与测试回归速度

　　实现难度：中

　　实现工作量：中（在于如何设计一个简单易用的框架来快速编写和执行自动化，这里与ATM平台不同的在于它是轻量级，更易于完成非关键字级的验证。并支持更多的语言。）

　　3、研发管理平台

　　实现效果最佳。

　　这个就不分析了，可以通过分步去做。

　　为什么想到这些？

　首先，测试与开发是分不开的。我们测试的目的，保证版本质量，另一个也十分重要的在于提高测试效率。

　　开发的目的，快速高质量发布新版本，高可维护。细致一想，提高测试效率不简单在于测试过程，而是整个开发过程；而高开发快速发布一部分依赖于测试的快速测试，除了高可用的架构以外，依赖于快速有效的自动化，依赖于高效率的工具。

　　不然，开发每次迭代10%开发，测试验证110%的功能局面无法得到任何改变，我们又苦又累却得不到结果。

　　为什么单元测试在我们项目中实施失败？

　　1、没有好用的工具，如果有一个只需要写业务测试代码的单元测试框架被牛人整合出来，何担心没人去用？

　　2、没有明确的目标，或对目标效果要求太紧。我们缺乏十分有效的数据度量，缺乏有经验的人，仅仅靠人的自觉基本上很难推行这些项目走向成功。

　　关于开发语言，

　　大多数人就像大多数人一样倾向于选择大多数人使用的语言，而谓之于“最佳实施”...

　　而如果我说，学一门脚本语言吧，你可能会说，没听说过图灵等价吗？（意指任何计算机语言的表达能力是等价的，一门语言可以完成的事件，理论说另一门语言肯定可以完成）脚本语言啊，太弱了吧？不能开发大项目吧？

　　实际上，目前是Lisp类的语言的天下，从perl开始， python， ruby已经不只是开发小型项目了。大家都在使用vCenter的时候，知道它是什么写的吗？实际上，它的web页到启动脚本均用的python。 javascript已经火了N久了，最近的Node。js把它从前端发展到后端。

　　是什么原因？高效的开发效率，强大的表达能力，越少的代码往往意味越少的维护成本。有兴趣的同学可以关注下<<黑客与画家>> 作者是硅谷的投资之父，揭秘了viaweb快速开发的秘密。

　　我们可以尝试部分内部项目采用它。

　　关于开发效率，最近关注：

　　github.com（一个git托管平台）开发语言rails，python，ruby 开发周期，3个人3个月上线（2008年），目前管理项目5000万

　　zhihu.org（一个知乎类似的问答）开发语言rails，开发周期1周2个人。

　　淘宝运维平台（内部）（一键发布平台，目标：关闭运维部门，说笑了，这个正是运维部门在做：））开发语言rails，开发周期6个月1个人，目前基本上线。

　　如何充分利用动态语言的开发效率可以在这些内部项目更快的发布与维护。

　　说这样好像与上面没关系啊，就像老大说的，没有人限制你要做什么。能够达到目标的一切措施都可以试试。

　　以上一点想法，吐吐为快。

33/3<1 23

posted @ 2013-04-17 09:38 顺其自然EVO 阅读(217) | 评论 (0) | 编辑收藏

个软件测试员的跳槽前后

辞职前

　　过年后上班的第二天开始提出辞职，其实也早有辞职打算，外包公司发展空间有限，当然这不妨碍随着工龄的增加，薪水的提高，也许提高的比非外包公司还快。被放到一个规范的流程里，和流水线上的工人没有任何区别，只是流水线上的工人需要几秒钟一个动作循环，我们需要几天或一两个月循环一次。当然，这都不是主因，哪有那么多新鲜给你尝试。

　　促使我跳槽的主要原因，一方面自我膨胀了，以为自己懂的很多（其实皮毛而已）。另一方面是外包工公司福利不好。我自认为我跳槽可以拿到更高的工资或得到更好福利。这是大部分人跳槽的主因。为了接触到更好的项目或更有发展空间的环境，其最终目的还是为了更高的工资与福利。

　　然后，就定在3月22号辞职到期。在提出辞职其间请假面试了一个公司，被面试惨了，他们有30%工作要用到自动化，因为自己面试经验不足，或者说没有为面试做任何的准备，本该知道的问题，结果回答不上来。可能给面试官留下一个好高骛远的印象。

　　因为感觉自认为性能方面还算可以，也决定要找份性能相关的工作，于是重新对loadrunner进行了学习，于是，你看到我最近整理的10篇loadrunner的使用技巧。查了招聘网站性能测试职位，寥寥无几，投了简历都没什么回信。没有广投简历是怕接到太多的电话没时间面试（后面才知道完全多虑了）。

　　找工作

　　辞职前的几天发一下简历，3月22号辞职期，3月25号开始面试，4月10号开始新工作。半个月的时间，共面了8家外包，6家非外包。面试的好少~！是的，太少了！清明节前后是个分水岭，节前，广发简历都接到几个面试通知。以至于，不管合适不合适的我都去碰碰运气。其间也开始怀疑自己的学历、工作年限、和项目经验；到后面甚至后悔自己盲目的跳槽。

　　下面从笔试内容、面试内容和项目类型谈谈我的面试感受：

　　先说笔试内容：

　　测试基础题：什么是黑盒、白盒，冒烟、回归等各种模式分析；项目流程，V模型，W模型；工作中开发说测试提交的问题不是问题，测试怎么办？甚至有个公司的题目是，什么是软件测试？ “软件测试可以保证质量”你怎么看？你当然可以这些当名词解释。如果能加入自己的理解最好。

　　还有SQL题出现的几率非常高，几乎做的笔试都有，但都非常简单，增、删、查、改的几个命令。这块是我最大的不足。部分面试题也遇到了linux 的一些基本命令、一个简单程序的输出结果等。

　　当然，不同的公司也根据自己的特点出相关的笔试题，我笔试一个做安全软硬件的公司，上面有大量的网络题，比当年考三级网络题难多了，结果肯定不及格。面试一个新闻检索公司，有一道英语翻译（手机上装了词典，怕浪费时间就没翻译），前面面试效果很好，当被问到英语这块时深深受伤了，因为邮件与文档是全英文的，焦虑的等几天结果，了无音信了。

　　面试：

　　面试被问到最多的是你们公司的项目/测试流程，是否用过自动化测试、安全测试，有的面试官会顺着一个问题深入下去，比如安全测试，有哪些安全攻击，说一个某种安全攻击的原理，通过什么手段（工具）发现这些安全问题，如何在工作中避免此类安全问题的发生。所以，很容易被问死，要让面试官感觉到自己的谦虚与不足，或转移到自己熟悉的东西上。

　　面试腾讯外包，面试官比较难缠：给我讲个你印象最深的bug ，约~！还会编程，给我写个求一到一百之间的素数。所以，碰到中意的公司还是要做做准备的，不然可能会被绊倒。腾讯要求前端知识扎实，http请求头，状态码、tcp/ip ，TCP三次握手、cookie和session 区别；GET 和 POST的区别等；想面腾讯的多学点前端知识不会错。

　　还有一类发散性思维题，面腾讯外包进拿现场的一个桌子想测试用例，面百度外包时拿一个QQ聊天窗口想测试用例，面快播时拿现场的一个转椅想测试用例。如果能说到面试官没想到的用例，他一定会默默地对你产生好感的。哈哈~！

　　再来说说测试的产品类型：

　　本来最想进的是银行外包，此类的工作薪资比较高，也许是我运气不佳，被学历和工作年限卡了，我问到的几个情况是要求必须本科和必须09毕业。

　　手机测试的职位也比较多，页游也不少，但感觉工资不高；还有安全软件，各种企业应用系统等。我个人兴趣偏向于web互联网测试，之前的测试经验也基本都是B/S架构的。

　　再次感觉，清明节后，深圳的面试机会多了许多，在经历半个月的找工作，我已经没有什么耐心继续了，因为每天都回答着差不多的问题也烦，一天不上班就损失我两三百大洋，房租什么的都伤不起。

　　最后纠结在两家公司，快播给的工资伤不起，和我没跳槽之间差不多，但福利肯定要比外包好，也是web测试，是我比较感兴趣的工作；另一家要高出一千元左右的样子，做通信优化的，项目不太感兴趣。所以，我在两个公司徘徊（纠结）了一天；本次跳槽的目的不就是为了找个更高薪资的，但快播更符合我的兴趣，也相对更有发展。

　　好吧！大家都懂的，但是我们真的不做毛片^_^ ，我也没资源。

　　方向：

　　最终没能做性能测试，因为都没有面试机会，没有太多的相关工作经验，因为......好吧！不找借口了，学到性能调优也是个瓶颈，与其纠结，暂时先放放也无所谓。

　　通过这次换工作，我太浮躁了，学习、积累、沉淀是需要时间的，想想我博客里的东西，又有多少是真正可以拿出手的呢？

　　学历对我来说也是个硬伤，如果想一直搞技术的话。报了个自考本科，可能以后会把大部分的精力放在自学考试上。当年学校还给老师的东西，是时候该要回来了。有同学“善意的”提醒我，不少公司是要正规的，全日制的，211的的本科。那肯定，有些岗位还必须要硕士、博士、海归呢，只不过是给自己的不想进阶找个借口而已。我就知道如果一个只要求本科的机会摆我面前时，我可能因为学历眼睁睁看它溜走。

　　英语是最大的短板，一般情况下都要用到阅读，如果想进外企可能还需要听说，最不能坚持的也是英语，不是没兴趣，是效果太慢很容易消磨自信心。

　　认真的深入的学门语言，什么测试工具、技术，学来学去都回归到了编程能力上，动能自动化，测试开发。

posted @ 2013-04-17 09:24 顺其自然EVO 阅读(245) | 评论 (0) | 编辑收藏