qileilove

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)

第1章  什么是软件测试

　　在我国宋代，有一位叫宋慈的法医学家写了一本《洗冤集录》。在书中，他讲述了很多断案的经验，其中有一个用银针验毒的方法至今仍广为流传。比如在很多电视剧中，我们能经常看到皇帝在进膳的时候，由于害怕被人暗害，总要让可怜的太监或者宫女先用银筷子尝上几口饭菜，没有出现问题再正式用餐。这种用银针进行的试验就可以说是一种测试的雏形吧，银针充当了测试工具，而太监或者宫女就是古代的测试工程师。

　　时光飞逝。随着科技的发展，我们生活周围有了越来越多的产品，它们在出厂销售前都要进行测试，不仅要保证功能完好，还要确保对使用者的伤害在允许范围内。因此在工厂里，逐渐出现了这样一个部门，由它来负责检验产品，被称之为质量检验或者质量保证部。

　　上个世纪中后期，软件出现了，它作为人们日常生活中天天都会使用的产品，同样也需要质量的保证。有一种误解：软件的质量问题并不那么重要，比如Windows等操作系统，各种桌面的应用软件，像IE浏览器，如果它出现了问题，程序会失去响应甚至严重的系统会蓝屏，那么只需要在任务管理器中将它删掉就可以了，最多重新启动电脑，一般都能够继续使用。这只是一方面，另一方面，有很多非常重要的软件在我们看不见的地方默默地运行着，如果它们出现了问题，影响就很大了。

　　为了说明软件质量的重要性，这里举一个比较著名的软件质量造成的事故。

　　1962年，美国的航海家1号（Mariner 1）火箭升空，由于控制火箭的软件出现问题，直接导致火箭升空后因偏离轨道而被迫引爆，造成当时1800万美元的损失。事后查明，是程序员在编写软件代码时，误写了其中一个公式的上标造成轨道计算失误的。

　　因此，软件公司也需要质量保证部门。我们把该部门的组成人员称为QA工程师，QA即Quality Assurance质量保证的简称。软件是否符合质量是通过测试来验证的，因此他们也被称为软件测试工程师。在本书中您即将遇到的各种行为，绝大多数都将是软件测试工程师在工作中所要实现和完成的。

　　1.1  软件开发的基本知识

　　对于每一位进入软件测试行业的新人来讲，公司的入职培训是一个很好的学习机会。

　　1.1.1  软件开发公司技术部门的基本结构

　　可将软件测试部门类比于工厂车间的质量保证部门，那么显而易见，如果在工厂中要做好质量控制的工作，必须熟悉本厂生产的产品和流程。换句话来说，作为软件生产的参与者，了解被测试的软件也是非常重要的一件事情。这也正是经理要求小白在短期内尽快熟悉的内容。

　　【什么是软件】

　　中国大百科全书中对软件的定义是：软件是计算机系统中的程序和相关文件或文档的总称。软件是从英文Software翻译过来的名词，与硬件（Hardware）相对应。

　　因此，软件开发公司就是制造这些程序和相关文件或文档的商业机构。一般来说，软件开发公司的技术部门由几个子部门或者角色组成：开发部门、测试部门、部门经理或者项目经理，另外有的公司还有技术支持部门。对应于传统行业，分别相当于生产车间，质量控制部门，部门经理和售后服务部门。如表1-1列出了常见软件开发公司技术部门的不同职责。

表1-1  常见软件开发公司技术部门的角色分类

　　Web应用是一种特殊的软件。那么开发Web应用的网站与一般的软件开发公司有什么不同呢？

　　对于小白所处的商业网站来说，网站程序和相关文件或文档也可以称之为软件，其技术部门的结构也和软件开发公司基本类似，但是各部门日常工作的方式则有所不同。

　　商业网站每天都要有很多页面的更新，每次更新后当时浏览网站的人立即可以看到；而软件开发公司一般一年或者几年推出一个产品，在产品没有上市的时间内，用户只能使用旧的版本。也就是说网站软件的变化要比软件开发公司频繁，网站软件的开发与用户使用处于同一时间段内。

　　商业网站以服务器为核心，网站软件主要运行在服务器上；而软件开发公司的产品主要运行在用户的电脑上。

　　【演唱会与专辑】

　　商业网站与软件开发公司的运作模式有点类似于歌手开演唱会和发专辑的区别。在演唱会上，歌手与观众的互动性更强，每一个细节的变化也都能被观众捕捉到；而歌手专辑则相当于软件产品的某个版本，是提前制作完成之后再上市销售的。

1.1.2  软件危机

　　小白在熟悉了技术部门的大致结构，网站与软件开发公司的区别之后，经理开始介绍和软件测试相关的背景知识。软件危机就是产生软件测试这一职业的重要推动力之一。

　　从20世纪50年代以来，软件的规模越来越大，复杂性也越来越高，另外，在20世纪80年代，伴随着计算机的普及和应用需求的飞速增长，互联网开始蓬勃兴起。现在，现代人的生活已经越来越依赖各种各样的软件，软件不再是大学实验室里科学家的工具，而成为我们生活的一部分。从操作系统，比如每一台个人电脑所安装的Windows XP或者Vista系统，到小小的桌面程序--一个简单的连连看小游戏，再到Google网站上可以编辑的在线文档工具，软件的开发、管理、维护的复杂性和高成本现象也日益突出，在某一段时期，暴露了很多问题。因此在20世纪，有人提出了"软件危机"的说法，来说明这种现象。

　　【软件复杂性的类比】

　　其实我们中国人是很容易理解软件复杂性的。一些在人口少的国家不成为问题的问题，放在十几亿人口的环境中，就会产生不大不小的麻烦，比如每年的春运--需要火车票的人是如此之多，而火车的座位是固定数量的；需要回家的人的分布是如此之广，而火车站的位置也是固定的。依此类比，当软件的代码量越来越庞大，要满足的需求越来越广泛时，出现局部的危机是很容易理解的。

　　1.1.3  软件危机的几个体现

　　随着软件越来越复杂，质量越来越难于控制，于是出现了所谓“软件危机”。具体而言，软件危机有以下几个体现。

　　软件需求的增长无法快速得到满足。这一点在前文已经有所讲述。

　　软件生产成本变高，价格越来越昂贵。软件的代码量增加，所投入的人工成本，也就是软件开发相关人员的成本也会增加，还要增加采用各种新技术的成本等。

　　软件生产进度难于控制。

　　软件的用户需求不容易定义。这一点也很重要：目前绝大多数的软件已经不止满足单一的需求，因此用户真正所需要的不一定能够完美地实现。

　　软件质量不容易保证。这一点也是由软件复杂度的增加而增加。还是举春运的例子，如果火车上人人都有座位，那么每个人的心情都会很好；但如果到处挤满了人，每位旅客回家的心情总会受到影响，从而影响对列车服务的评价。软件质量和用户的评价同样是相关的：经常造成死机、异常退出或者按钮单击后没有反应的软件，很难说是质量好的软件。

　　软件可维护性变差。软件同样是需要维护的：一方面是对于用户使用过程中的维护，这一功能由客户服务或者技术支持部门来完成；另一方面是对于软件本身代码和文件文档的维护，这一功能由开发部门或者测试部门来完成。随着软件的日益庞大，软件本身经历的修改越来越多，管理维护软件的各种版本变得日益困难。

　　由于软件危机有这么多的影响和危害，所以促使人们静下心来研究软件开发过程中的规律，这就产生了软件生命周期的概念。

　　1.1.4  软件生命周期

　　软件生命周期，英文为Software Lifecycle，就是软件开发、使用和消亡的过程，具体而言，包含软件需求分析、软件设计、软件实现与测试和软件发布、部署与维护这4个过程。

　　在商业软件开发公司内部，人们往往遵循一定的软件生命周期模型，这样和被开发软件相关的所有人员都按照这个模型的标准或者步骤开展工作，统一行动，有助于提高生产效率，从而减少沟通和实施的成本，获得更大的商业利益。而对于软件生命周期的不同理解和划分，就形成了不同的软件生命周期模型。

　　1.1.5  常见的软件生命周期模型

　　目前来讲，主要的软件生命周期模型有如下几种。

　　Big-Bang：大爆炸模型。

　　Waterfall：瀑布模型。

　　Spiral：螺旋模型。

　　Code and Fix：边做边改模型。

　　由于本书并不是以软件工程为探讨内容，因此在这里只通过人们过河的类比来简单介绍一下前述这几种软件生命周期模型的特点。

　　小学课本里有个寓言叫做"小马过河"，小马在过河前遇到了不同的小动物，它们对于河水深度的理解是不同的，会导致小马过河时的不同选择，参见图1-1。假设把待开发的软件产品比喻为小马面前横着的那条小河，那么开发软件的过程也就是过河的过程，那么如何过河就会有不同的结果。

图1-1  小马过河：对河深度的理解影响过河的方法

　1.1.6  直接冲过河去的大爆炸模型

　　大爆炸这个名称来自于天体物理有关宇宙形成方式的一种理论：宇宙是在亿万年前的大爆炸中诞生的。与此类似，软件开发公司把金钱、办公场地和人员全部投入到一个产品的开发当中，经过一段时间，产品出炉，这样的形式就是大爆炸模型。

　　大爆炸模型的优点就是简单，没有很多的软件设计，对项目的管理也很少，目前不少小公司由于各方面的限制不得已或者不自觉地采用了这样的开发模型。但是它的优点也造成了它的缺点：开发出来的软件质量不可控制。

　　在这样的模型中，由于没有周密的计划，软件测试往往是在产品即将上市的前夕才开始，在很多公司中甚至没有专职的测试工程师，由开发人员或者其他人员代劳，因此测试人员面对的产品与客户、使用者要面对的产品基本一致。从前文所述可以得知，在这样的阶段发现Bug，返工修改代码的代价是非常大的。

　　回到过河的比喻中来，大爆炸模型就相当于小马先退后几步，集中精力和能量，然后快速冲过去。这样的结果取决于河的宽度和深度。如果软件非常复杂，很可能过河的小马半途就淹死了，无法到达对岸。

　　1.1.7  摸着石头过河的边做边改模型

　　边做边改模型比起大爆炸模型来说进了一步。在开发软件产品的开始阶段，先有一个大概的设计，然后开始编码，测试，发现Bug，修改Bug这样的循环，直到整个产品的轮廓日渐清晰，最终完成产品。用一句俗话来描述，就是"摸着石头过河"的过程：先以河里的一些石头为支点，走入河道，再经过不断的试探和返回得到一条路线，最终到达目的地。

　　由此可见，边做边改模型中测试的参与要比大爆炸模型中要早得多，而且也重要得多。边做边改模型的优点就是适用于某些中小型项目的快速开发，软件产品的成果也会在最早的阶段显现出来：和在岸边冥思苦想如何过河的人相比，先站在河道里的石头上，总是让人看到更多的希望。

　　【边做边改模型被较多采用】

　　这种开发模型被大多数公司所采用，是大多数测试工程师在实际工作中最常遇到的开发模型之一。而且，它和最近几年很流行的敏捷开发也有一定的关系。

　　1.1.8  制定周密过河计划的瀑布模型

　　从现在开始，下面的这两个模型就不适合小马了，只有人和外星人才有这样的能力。如图1-2介绍了软件开发的瀑布模型，由于图中的箭头好像瀑布的水流，从上至下，因此得名。

图1-2  瀑布模型示意图

　　回到过河的例子中来，瀑布模型过河具备如下特点：

　　过河前，首先花费大部分的时间对河进行详细的勘察，选择合适的下水点，选择合适的过河工具，制定详细的分步骤过河计划。

　　一旦过河计划制定，将不会大更改，开始过河。在河中完全按照计划进行，无法返回起点。这也是为什么称此模型为瀑布的原因，瀑布是飞流直下三千尺，想从下面返回瀑布的顶端，何其难。

　　在每步骤即将完成时，都会对这一步骤进行总结，如果进行下一步骤的条件不具备，将停留在原地，等待条件具备。

　　瀑布模型看起来给人很专业的感觉，所以，对于软件开发人员有比较高的要求。

　　要对待开发的软件（或者要过的河）有细致、全面、准确的了解。如果理解错误，将导致计划失败，没有返回重来的机会。

　　职业素质、职业纪律要比较高。软件开发人员要具备坚定执行计划的能力。

　　这种要求也就产生了瀑布模型的缺点，那就是无法完美适应当今要求快速开发产品，从而占领市场的软件行业现状。因为制定详细的、理解完整的计划很难，聚合很多专业的开发人员有时候也很难，而市场对于软件更新换代的要求期限越来越短。为了适应变化，人们又提出了螺旋模型。

1.1.9  计划赶得上变化的螺旋模型

　　前文提到，为了适应计划和变化两方面的因素，螺旋模型被提出。螺旋模型的示意如图1-3所示。可以看到，它的确很类似一个螺旋。

图1-3  螺旋模型示意图

　　与边做边改模型类似，螺旋模型也具有循序渐进的特点，对软件最终实现什么不一定有完全确定的理解，而是摸着石头先下水。但是在选择过河的每一个石头前经过了周密的计划和考虑，从这一点看，又类似瀑布模型。可见，螺旋模型实际上是边做边改模型和瀑布模型的有机结合。螺旋模型有如下4个步骤。

　　（1）确定项目目标、可用资源、各种实现的方法，项目的各个阶段。

　　（2）在某个阶段中，确认、解决当前阶段项目进展中出现的风险。

　　（3）评估各种方法，开发、测试代码，实现当前阶段的目标。

　　（4）总结当前阶段，计划下阶段的目标和实现方法，重复第（2）步。

　　在图1-3中螺旋线被两条直线划分成4个部分，分别是上述的4个步骤。在每一步骤中由于被直线切割会有多段曲线，每一段曲线就代表了在不同阶段中所进行的相同某个步骤。

　　【螺旋模型的优点】

　　由此可见，螺旋模型是多次计划，边做边改，这样既保证了软件开发任务的清晰，也降低了开始一次计划，因为理解不完整或者市场变化后导致项目失败的可能性。

　　1.1.10  4种模型的总结

　　前文讲述了4种软件开发模型，那么在具体项目开发中采取哪一种最好呢？答案是它们各有利弊，需要灵活采用。这几种开发流程的优缺点比较如表1-2所示。

表1-2  4种软件开发流程的优缺点

　　当然，在几十年的软件开发过程中，人们还提出了很多其他的开发模型，不过，作为测试工程师，我们对这几种主流模型有所了解就可以了。进一步深入的内容并不是本书所讲述的范畴，读者可以参看软件工程的相关书籍。

　1.1.11  软件开发的几个阶段

　　不管采用哪一种开发模型，按照时间顺序，所有的软件开发项目都要经历如下4个阶段。

　　（1）项目启动阶段：了解客户需求、配置相关资源。

　　（2）项目设计阶段：明确客户需求，确立软件开发、测试的方法。

　　（3）项目执行阶段：开发与测试阶段。

　　（4）项目竣工阶段：软件的上市、后期维护与技术支持。

　　这一分类很好理解，下面再结合小白的工作场景，进行展开介绍。

　　（1）项目启动阶段。这一阶段一般技术人员参与较少，主要是市场部门，销售部门，技术总监、项目经理等角色的参与：项目成本是多大，开发人员有多少，测试人员有多少，完成时间在什么时候等。

　　（2）项目设计阶段。这一阶段主要参与者就是需求分析人员、开发人员、项目经理和小白这样的测试人员了。主要目的是确定软件该如何做，做什么：开发人员利用何种技术开发，测试工程师该如何测试该软件，客户如何使用该软件等。这些问题都要确定，形成各自的开发文档、测试文档和需求文档等。

　　（3）项目执行阶段。开发、测试以及对其的管理就是执行，这一阶段的参与者是开发人员、测试人员和项目经理。开发人员编写程序代码，进行单元测试；测试人员编写测试代码、测试用例，进行功能测试等多种测试。项目经理控制进度，协调各种资源，与设计人员沟通等。

　　（4）项目竣工阶段。当项目执行完毕的时候，依然要进行部署、软件光盘生产、客户支持、升级补丁包开发和测试等多项工作。这阶段主要的参与者是项目经理，少量的开发人员和测试人员，售后技术支持人员、客户服务人员等。

　　1.1.12  软件发布的方式

　　按照目前的软件发布方式，一般有RTM（Ready To Market，市场发布）、RTW（Ready To Web，在网络上发布）、RTO（Ready To Operation，可以运营）等多种方式。

　　RTM方式需要在工厂进行光盘的复制生产，用户购买光盘后安装。大部分的操作系统和应用软件采用这种方式的比较多。

　　RTW方式需要在网络上提供下载链接，一般的软件升级包或者游戏软件采用这种方式的比较多。

　　RTO方式则很简单，在服务器上部署软件产品，用户购买其中的某项或者多项服务即可，这是大部分网站或者在线游戏采用的方式。

　　1.1.13  项目管理与甘特图

　　前面提到软件项目的流程很重要，那么这种流程的控制一般是由项目经理来完成的，他或者她所从事的这个工作叫做项目管理。

　　小白所在的技术部门一般一周都要开一个例会，在会上，开发部门、测试部门和项目经理都要对上一周各自所做的工作进行一番总结，安排下周将要做的工作。在这样的例会上，同事们经常会查看项目的进度图来进行讲解，他们把这样的进度图称为甘特图（Gantt Chart）。

　　如图1-4显示的是软件开发过程中常用的项目管理工具Microsoft Office Project软件（在这里是2003版本，最新为2007版本）运行的界面，在其中我们可以清楚地看到软件生命周期中的各个子任务的时间分配，负责人员和项目进度的甘特图。

图1-4  Project 2003中的甘特图

　　【甘特图的来历】

　　甘特图的名称由发明者亨利·劳伦斯·甘特（Henry Laurence Gantt，1861-1919）而来。甘特早年从事的是电气工程师的职业，后来转而从事管理业界的咨询。甘特图是他在晚年发明的一种用于显示项目计划和进度的图表。在诞生的初期，甘特图就被誉为20世纪20年代的最重要发明之一，广泛应用于一系列的大工程之中。比如1931年前后修建的美国胡佛水坝（如果你看过2007年的热门电影《变形金刚》，那么对关押威震天的那个水坝应该有印象，它就是胡佛水坝）。在软件开发领域，很多公司也应用甘特图这一工具来进行项目管理，比如著名的微软公司。

　　（未完待续）

posted @ 2013-05-13 09:42 顺其自然EVO 阅读(393) | 评论 (0) | 编辑 收藏

软件测试员，敢问路在何方？（第二部分）

　　第二部分 - 我的一些建议

　　在这部分的文章中，我将专注于提供建议，以此帮助你的职业生涯发展。的确改变可能需要一段时间，有一天，你将成为一个资深员工。不断学习，不断思考和壮大自己的兴趣是你的职业成功的关键。我希望本文可以帮助你思考和开始积累你的力量。以我自己为例，我曾只专注于我的项目，只用很少的时间来思考。有一天，我无意中访问了一个网站，和听到了“被夸大的测试(Testing is Overrated)” 的会谈。阅读后，我把我的想法分享给我的同事们，并认识到，在我工作之外还有这么多出色的信息。我开始阅读这些文章，并借阅测试??书籍。培养这样的学习和思考的习惯会花费时间，但一旦你有了这样的能力，你会发现，你可以成长得非常迅速。

　　激情和动力

　　有时，人们每天都做类似的事情就会觉得乏味。他们开始失去激情，感觉自己的职业生涯发展变得缓慢。我们应该如何处理这种情况？我可以给你一些建议。

　　● 考虑离开自己的舒适区域。

　　一旦你在一个地方里待了很长一段时间，你就有了一个舒适区域，它让你觉得你的工作失去挑战，你的技能不在提高。因此，是时候来改变了。你既可以换到其他公司也可以换到其他不熟悉项目。请大家认真考虑这个问题，因为这对你的职业生涯有重要影响。在未来的博文中，我将详细讨论改变或不改变。在一般情况下，我认为改变是应该的，你应该常常对此进行思考。我看到过很多例子，换到其他团队，并获取到更好的职业生涯。另外，还要考虑到换到其他团队，会给你提供机会，去学习新的、最终将有利于你的技能。

　　● 考虑做一些某些副项目(side project)。

　　我的第二个建议是，考虑做一些副项目。在过去的几年里，我发现，大家在他们的空闲时间里或主要任务责任外打造的项目往往比资助项目有更大的影响(the side projects which people build during their free time or out of main responsibility tend to have much larger impact that the funded project.)。作为一个专业的工程师，我们应该自我激励，自我组织。如果我所做的事情正是我的兴趣所在，我将会对它充满激情，并会为它做出持续努力。

　　● 拓展你的兴趣点。

　　我的第三个建议是，试试其他领域的兴趣。例如，当我觉得日常工作很枯燥时，我经常去公司内部微博，了解今天微软内部发生了些什么事。我喜欢阅读文章，了解公司外部又发生了些什么事。我喜欢阅读谷歌测试博客了解他们正在做些什么。你可以选择一个你特别有兴趣的领域，然后保持这个卓越的习惯，每天都学习些新东西。

　　最后，我有一些建议给我们的经理：宏观管理而不是微观管理；给大家一些做其他事情的自由；鼓励大家去尝试不同的机会。我知道我们的承诺，我们的任务必须要完成。然而，让大家愉快和受到激励比交付一个功能更为重要。一个快乐的团队能提供更好的产品，我们都不希望总是压力山大。

　　开放的思想和广泛的兴趣

　　一旦你在一个地方里待了很长一段时间，在你所在领域你获得了非常深厚的领域知识和测试方法。在这种情况下，我们往往是安于我们现在所做的，并有时还会避免改变。然而，作为一个专业的软件测试员，我们应该始终更宽更广地思考，思考有我们可以采用些什么新技术，思考你所在领域的未来测试技术。在一般情况下，一个优秀的软件测试员应该思考的比我们目前已有的东西更远，并有一些应对更改的计划。

　　为什么呢？究其原因是技术变化太快，如果我们不提前考虑，提前做好准备，有一天，当变化发生时，你会发现，你得仓促地面对这么多的挑战。例如，我总在浏览技术网站，以此提高我的技能。当我们的团队决定用列存储来实现数据仓库时，我已经知道我们为什么应该这样做的，这个领域中最热门的技术是什么。

　　为了培养这样的技能，我们需要的是开放和广泛。我们需要知道公司内部发生了什么事，社区里又发生了什么事。我们应该很开放地聆听和学习别人的想法。我强烈的主张，我们的资深测试员应与其他团队成员保持密切联系，尤其是微软里其他团队，并培养一种学习技术并能迅速吸收的能力。有一天，你会觉得学习的投入将为你的工作带来巨大的回报。

　　我可以给你一个例子，我如何做到这一点。就我而言，我订阅了微软内部和外部的大量非常活跃的博客，接收别人的更新。我也参加了会谈和培训，来提高自己。讲座范围可以非常广泛，如云计算中的系统工程方法(service engineering)，基于场景的工程方法(scenario focus engineer)，即以用户需求为导向的系统开发，等等。通过参加这样的培训，你将收获更广的技术知识。另外，你能知道公司内部发生了什么事。在过去的一年，我就参加了两个$99外训，然后我引入ATDD和个人看板(Personal Kanban)到我们的团队之中。SQL团队中许多成员所使用的技术和ATDD，其实早已被微软内部的很多团队使用过。你可以看到开放和广泛的价值，它能帮助你成长为一个资深测试员。

　　提升影响力(Making Big Impact)

　　今天，我想谈的另一个话题是作为一个资深测试员，需提升影响力。衡量一个人的成就的重要途径之一就是你对团队，对项目，对客户有多大的影响。我有三个方面提升影响力的建议。

　　● 帮助他人的成长

　　我们需要意识到，无论你是多么聪明，只靠你自己，你是不可能成功的。你帮助他人成长越多，你越可能会成功。作为一名资深测试员，我总是很喜欢看到初级测试员提高他们的技能，发展他们的职业，我也将提供建议和指导他们，帮助他们成长。就我的心里而言，我认为帮助别人是最重要的事情，我们应该每一天都帮助别人。有很多方法可以帮助他人成长，帮助他们做项目，回答论坛里问题，指导新成员，教他们如何编码和如何测试。对一个团队来说，建立这样的文化氛围是极其重要的，因为大家会感到其他人的温暖，并鼓励分享和学习。最后，我们一个团队一起都能成长起来

　● 影响他人

　　一旦你变得越来越资深，你已经掌握了非常深厚的技术知识，大量的项目经验。你得到别人更多的尊重，成为某一领域内的大牛(GOTO person)。换句话说，你有能力影响他人。如果我们看看，架构师，技术潮人(Techiques Follows)，大牛的工程师(Distinct Engineers)，他们的观点和思想能影响了很多人，类似这样的能力是他们独一无二的资产。

　　你认为我们能够像大牛一样影响其他人吗？我想是可以的。每个人都有一个你擅长的领域。你应该用你的专业知识来帮助人们作出决定，并提供宝贵的建议。例如，对于每一个我参与过的或我学习到的项目，我都对它有些独特的看法，我试图理解为什么我们应该开发这样的项目，我会更多思考为什么我们不使用另一种方式来构建它，我常常把我的想法分享给项目里的所有人然后我们一起再作出决定。我写了大量的博客，分享我的想法，并希望影响更多的人。

　　● 更多的跨团队协作

　　以我自己为例，在最近几年，我引入ATDD(验收测试驱动开发 - Acceptance Test-Driven Development)到我们的团队，并把它介绍给很多微软内部的其他团队，如Bing，Lync团队。我也参加不同类型的会议和研讨会，了解其他团队是在如何做测试。每当我看到有人做我所熟悉的项目，我也问他们是否需要帮助。

　　总之，当你努力提升你的影响力时，你的经验同样也会积累越来越多，你不断成长为一个资深测试员。

　　编码，编码，编码

　　今天，我想讨论一个最重要的技能，我们的软件测试员应该在自己的职业生涯中所掌握，这就是编码。

　　● 为什么编码这么重要？

　　因为你是软件测试员(SDET)，软件测试开发工程师(Software Development Engineer in Test)，你是软件工程师。作为一个软件工程师，编码就是每一天你应该做的任务，这是你应该掌握的技能。你可能会问是否编写测试用例没有编码更重要。这里的原因是，编写测试用例可以帮助提高产品的质量，但有时它并没有促进你的职业生涯发展。我可以举我的一个例子。当我刚参加到SQL Server团队之中，我们编写以T-SQL脚本为基础的测试，我很少有机会写编码。因此，我的编码技巧并没有提高。幸运的是，SQL Server的测试团队转移到以编程的方式编写测试，今天，我们的软件测试员的编码时间增加了不少。这是相当不错。当然，有时我们花费太多的时间在编写代码和类库上，而花费较少的时间来写真正的测试用例。这是另一个很大的话题，在这里我就不打算讨论了。

　　由于今天我们当中大部分人在编写自动化测试，这意味着我们有很大的机会来提高我们的编码技能吗？答案是不一定。今天我们的测试员做了太多的任务：我们编写测试库，我们验证测试结果，验收产品，我们配置机器和安装新版本进行测试，我们修正我们脆弱的测试，我们创建和关闭缺陷。有时我们花费大量的时间在下载和编译源代码。我们也有其他的任务，如会议，项目跟踪 / 缺陷报告。上述所有任务将需要花费我们每天中的大量时间，而时间提醒着我们，做实实在在编码真得很少，我们的技能提高也非常小。我记得有一天，我曾对我们的测试经理提到过我的梦想——我可以花50％的时间在编码上，他很惊讶，他认为这个数字理应还要大很多。然而，现实是这个数字理应小得多。

　　所以，我们该怎么处理这种情况呢？我们应该尽力尝试，改善我们的工程系统，以减少不必要的时间开销，让系统能够安装配置环境，安装测试版本，运行测试，创建 / 关闭的缺陷和退出测试。所有这些应该是自动化的。我们应给自己承诺每天尽可能多得编码。由于你的工作性质，如果你不能做到这一点，你应该考虑换到其他工作。

　　小结，请记住编码是一个重要的技能，你应该去提高它。

　　花时间去思考

　　在最近几天，我试图去理解，我们应该如何去教导和学生如何去学习。我的Ph.D研究经验和最近戴尔·卡耐基培训，为我提供一些想法：

　　● 教给他人或分享经验给他人最佳的办法是让他们思考。在你的谈话中不管他们思考了什么，他们至少学到些东西。一个好的实践是鼓励他们说话，与你互动。

　　● 思考自身有时可能并不够，我们可能需要实践和应用我们的思考到我们的工作中。

　　就研究论文而言，我们的论文大部分沿用了经典的格式，它必须有简介，相关的研究，实验结果和结论。没有实验结果的论文几乎是不可能被发布的。另一方面，论文的本质观点，似乎是不知为何地被隐藏起来或不是那么容易得找出来。我认为这是做研究里一个的问题。

　　当我们想要向人们做演示展现点东西时，或者我们想要写点东西教给别人时，同样也有上面的问题。首先，你会花很多时间在研究我应该思考些什么。之后，你头脑中就有些想法了，你会渴望通过写些东西与他人分享，这是一个很棒的方式来概括你的想法。

　　最后，我相信资深测试员的价值，是他可以给团队带来的观点 / 技能，而不是他在过去的工作经验。对我们的软件测试员来说，能够努力思考问题，并找出解决方案是一个重要的技能，我希望我们的资深员工应有的最最重要的技能就是思考 ，一个优秀的领导必须首先是一个出色的思考者。

了解产品

　　我相信作为一个资深软件测试员，我们应该充分了解我们正在测试的产品。知道产品的方向 / 未来是创建更好的测试的第一步。换句话说，如果我们不理解为什么我们应该构建这个产品和我们将构建怎样的产品，那么我们将不能编写出优秀的测试。

　　我们应该更多地参与项目 / 产品的规划，并影响产品的的策略（不仅是测试策略）。请注意，这是我们可以提高产品质量的重要途径之一。如果我们可以发现设计时的缺陷，我们可以节省下很多的时间和金钱，而且甚至比发现大量功能上的缺陷要有价值得多。有趣的是，我相信一个优秀的产品设计和一个正确的方向，会带来更少功能缺陷。过去我参与了大量的改进，我发现，如果是精心设计的功能，我们在实现功能的过程中将看到更少的产品问题 / 缺陷 / 后顾之忧。无论如何，如果该功能没有得到很好的设计，我们不应该去实现这个功能，否则你在执行的功能时会看到很多问题。

　　参与产品的设计，也可以帮助我们提高管理 / 构建项目的技能。并提高我们的技术技能，对测试架构师和领域专家的职业道路都是至关重要的。

　　了解产品，可以帮助团队成员讲同一种语言，更顺畅地交流。假设有一天，你想加入另一家公司做云计算，当你和你的面试官谈论时，他们可能会问你很多关于云计算的问题。如果我们只知道在服务中如何测试单个组件，你会发现你是缺乏知识 / 思考的，这将影响你未来的职业生涯。然而，如果你知道并思考过IASS，PASS，亚马逊AWS等云计算技术，我敢打赌，你将有更大的机会得到这个职位。对于一家初创公司来说，有一个除测试以外的技能是至关重要的。这始终是一条金科玉律。

　　最后，我想分享下Erwin Engelsma的观点：

　　“测试能够提高顾客的满意度，前提是你真的知道客户认为什么是真正重要的，并测试了相关的内容。在你的客户几乎不感兴趣的领域，做出很大的改进，虽然是一个值得称道的努力，但是这不会改变他们对产品好坏的看法！”

　　- 改进测试时的关键问题 —— Erwin Engelsma。

　　用不同的方式做事

　　有一天，我的经理问我：“Qingsong，当你还在高级测试员级别时，为什么你可以得到出众的评价结果??”。在高级测试员的阶段，我还没有很丰富的测试知识，对团队的影响也不大。所以，我也想知道是什么让我有这么一个出色的评价结果，答案就是在用不同方式做事情。

　　这个问题的一种思考方式是，你如何把你与其他人区分开来。我发现当我被分配了一些任务时，我会额外地做一些我应该做的事情，这使我跟他人不一样，更主要的原因，我提升了影响力，也发展我的职业。这里有一些在过去我曾做过的事情的例子：

　　● 当我们计划在SQL Server中增加对日期和时间(Date and Time)的支持时，我花了很多时间来研究日期 / 时间和时区在Windows，Linux，.NET和Win32 API上的支持情况。我曾积极参与到项目的规划和设计中。这就让当我们测试功能时，我就有了一个更好的地位。另外，我在该功能的测试过程中承担了更多的责任，包括构建管理，测试运行管理，在线文档审查，并帮助他人编写测试用例。这些增加了我的知识，还帮我产生了更大的影响。

　　● 当我们在SQL Server 2008中实现了稀疏列(Sparse Column)功能之后，在功能提交后我并没有停止思考我们的功能。我曾积极地在内部寻找能够使用我们这个功能的地方。最后，我发现我们团队的VSTS系统可以使用这个功能，所以我和支持团队一起工作，把这个功能部署到系统中去。这样一来，我帮忙提高了团队的业务能力，同时也更好地了解到功能的用户场景。结果就是，我看到这个功能还缺少的一些更细功能。

　　最后，我希望你能体会用不同方式做事的意义。如果你有这样的能力，将会帮助你的职业生涯很多。

　　给测试经理的建议

　　今天，我希望写一篇关于招聘软件测试员的博文。主要读者是我们的招聘经理。这篇博文不是关于如何面试人或决定雇不雇用一个人，我认为这些是具体过程。而我的主要议题将关注为什么，即为什么我们需要聘请一个或多个测试员。

　　我不是一个测试经理，当需要更多的人时，我不知道我们的经理给人力资源那边说的原因是什么。也许先让我列一些可能的原因：

　　1）我们开始一个新的项目或功能，我们需要建立一个新的开发和测试团队。

　　2）我们有一个新的测试主管(test lead)，主管应至少管理5～8人。

　　3）我们在做项目时，测试资源短缺。

　　4）我们的副总裁给测试经理一些名额，如果我们不填上这些名额，就会被“浪费掉”。

　我们真的缺乏测试资源吗？

　　我总是听人说他们的项目缺乏测试资源。但是，我们真的缺乏测试员？不一定，根本不是。微软内部没有测试资源缺乏的问题，而是资源分配问题。今天，我们的测试通常属于一个组件(component)团队，由一个测试主管带领。他深刻理解他的领域并且测试也做得相当不错，以便发展他的职业生涯。人们往往认为，每一个部门都需要一个单独的测试团队人们往往认为，测试是一个专业的工作，需要深入的了解测试。我们可以以另一个角度来看这个问题。今天，现代的测试框架，如NUnit，XUnit，MSTest和Selenium，编写自动化测试起来是非常容易，做测试并不是真的需要太多的测试知识，尤其是对于白盒测试来说（我相信由开发人员来写白盒测试并尽早地跑起来，那么白盒测试的效果将比黑盒测试大得多）。

　　我看到不少的情况是，我们的资深软件测试员对他们负责的组件有着丰富的领域知识，对于这样的组件，深刻理解是必要的。测试查询优化器(query optimizer)就是一个例子。不过，我认为最好的测试员应该把他的知识和测试理念应用到测试类库，让每个人都可以使用它，使得这样的组件测试变得更加容易。在SQL Server中，TestQP和QREL是很好的例子，这两个工具就内嵌了查询优化器和关系数据库的知识。你将你的知识转化为代码后，我觉得你能随意移植到其他团队，我们是没有必要去限制，因为他在这个领域中有着最丰富的知识。

　　扩大我们的团队并不意味着我们的业务扩大？

　　有时，一个团队从5人扩大到20人甚至更多时，人们感到自豪。然而，这并不意味着，我们的业务扩展了四倍。不应该用人数来衡量经理或团队成功与否。

　　你想增加新的测试员来提高团队的工作效率？

　　这可不一定。有时，它是成立的，我们的测试员在项目上非常繁忙，我们有一种感觉，添加一个或多个的测试员可以帮助我们，真的吗？如果原因是我们想招人，那完成这个项目之后又该怎么办？我们永久地保留他们。

　　下面是一些我给我们招聘经理的建议，如果他想雇用一个新的测试员时：

　　1）需要一个测试员时，尝试探索不同的方法来解决这个问题，并把雇用一个新的测试员作为最后的备选解决办法。

　　2）如果在项目上我们需要更多的测试员，我们可以从其他的团队调用些测试员吗？

　　3）如果我们有太多要做的事情，我们能标清优先级，并放弃部分低优先级的任务吗？

　　4）考虑培养一个技术主管，而不是培养一个人事管理主管。我们倾向于培养非常优秀的技术人员成为主管，让他管理更多的人。然而，今天我们的主管，在人事管理和其他的东西上花了太多的时间，他们只是没有时间思考，没有时间去提高他们的技术方面技能。所以，请考虑把我们的主管视为技术主管，这样一来，管理多少并不重要，重要的是能影响帮助到团队的人。

　　5）请务必花时间去改善我们的文化，我们的过程和方法。优秀工程是更高生产力的关键。减少我们的技术负债，投入时间去创新。

　　6）考虑采用一些指标来衡量测试员或测试的效率，因此，我们可以用更好的方式来作出决定。

　　测试新人的职业生涯怎么样？

　　这是一个很大的话题，这里我不会说得太多。一种看法是，我们都希望我们的员工能够快速成长，在未来有一个更好的职业。我们都希望我们的测试员可以很轻松地在其他公司找到测试工作，如果他们决定去追求公司以外的机会。然而，今天许多公司的开发人员与测试员比例相对偏低，并且他们相信他们的产品质量不算坏。我希望有人能在就业市场和测试员的水平上做一些研究，我们可以用更多的事实来分析这个问题。

　　结论

　　这是“成长为资深软件测试员”系列博文的结尾。我希望从我的博客中，你可以学到一些有用的信息，并帮助你决定你的职业道路。近年来，计算机技术的变化日新月异。云计算，社交网络，移动都是热点领域。技术的变更同样也需要不同类型的测试技术。我会开始写另一个系列博文——“对测试的未来和软件测试员的职业的未来”。在接下来的段落中，我将列出一些的最新文章，以此回答软件测试的未来是什么，服务领域测试(testing in the service area)的未来是什么，以及对软件测试员的职业生涯有何影响。

“测试的未来”的相关参考文章：

　　● 在谷歌2011年的测试自动化会议上，谷歌工程和创新倡导者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia负责开幕式主题演讲。他认为，我们曾熟知的软件测试已死 - 或至少是垂死的。我与几位同事看了这个视频两遍，大家都觉得这是很警醒的谈话，让我们更严肃地深思测试和事业。我强烈推荐每个测试相关的人去看看这个视频。主题中提到，初创公司对“我们正在做正确的事情吗？”比“我们正在正确地做事吗？”更感兴趣。也就是说，这里的质量真的不是我的软件或者服务是否有缺陷，而是我的想法是不是吸引顾客的最佳想法。这对我们的软件测试员有一定的影响，因为我们太专注于

　　“我们正在正确地做事吗？”，并可能导致我们很难在初创公司找到工作。

　　● “众包”是最近非常热门的话题。你能想象一家拥有数以十万计的软件测试员的公司吗，它可以帮助其他公司在极短的时间内完成测试。这些兼职软件测试员的薪水和他们找到的缺陷挂钩。他们在不同的地方用不同的语言在不同的设备上运行测试。不同于我们的内部测试，他们像真正的客户般的运行测试。 uTes??t.com就是这么一个公司，该公司在这个领域相当抢眼，它将会对测试服务和测试移动应用的方式上有着极大影响。在内部，我们有几个团队，包括Bing，Lync，都在积极利用众包来测试他们的功能。对我们的测试员意味着是什么？仍是未知数。

　　● 由James Whittaker ， Jason Arbon和Jeff Carollo编写的“ 谷歌怎样进行软件测试 ”，很详细地回答封面的上问题。能在迷雾下看到像谷歌这么一个大型技术公司如何处理软件测试的复杂性，是很具知识性和趣味性。一个有趣的现象是，在此书的出版之前，三位作者都离开谷歌，一位回到微软担任开发主管，和另外两个则加入了uTest.com。下面是 一次访谈 的片断：

　　提问：在本书中，你提出了，“不要雇用太多的测试员”，并且在未来里测试工程师的作用在下降。你对此有何回应，公司认为需要更多的角色，以此划分开发人员和质量保证之间的界线？

　　为什么你要这样的界线吗？谷歌已经证明编写代码和保证代码优秀的界线是模糊的，其结果就是代码被开发更快，并且潜在缺陷更少。雇用太多的测试员是为开发人员创建了一个依靠，对产品来说这就是有害的。当人们过于纠结自己的角色，会使我懊恼。“我是一个测试员”是一种不健康的心态。“我是一名开发人员”同样也是不健康的心态。当人们停止过多关注自己的角色，开始专注于他们的产品，这才是奇迹发生之时。这时候，每个人都专注于尽一切力量来打造他们能打造的最好的产品。

　　提问：对当前那些考虑加入测试相关角色的测试分析师(test analysts)或新毕业生，你能提供最好的建议是什么？可以满足这个角色不断变化的技能。

　　对待测试如同开发一般。获取一个CS学位，并擅长CS。证书和行业培训只会教你简单的东西。学习难的东西，并掌握它。软件测试员只做简单的事情，在很长的时间里仍然会被视为二等公民。不想被这样对待吧？那就获取一等的技能。

　　● Bing团队的融合工程(Combined Engineering)设想，对服务测试和软件测试员的职业生涯都是非常有趣的。在融合工程，软件开发工程师（SDE）们和软件测试开发工程师（SDET）们合并为一个“工程师”的角色，我们为交付服务而优化，而不是为软件而优化。换句话说，许多测试成为开发者，真正的开发人员只写代码，而不是测试。我认为这可能是服务团队的未来发展方向，今天的测试员可以更专注于监测，基础设施和工具，他们和开发人员是一样的。

　　● 我们的生产环境测试(Testing in Production)专家——Seth Eliot，认为TestOps是我们的测试的未来发展道路之一。你可以到这个链接看看相关信息。我认为生产环境测试能真正改变我们如何做测试以及测试员的职业的未来。这是TestOps访谈的一个小段：

　　我认为测试领域的一个重要的变化将是我已经谈到过围绕测试服务和生产环境测试。我把它称为TestOps。

　　测试员需要摆脱定式思维观念，编写测试 - 运行测试 - 评估结果。我们要使用大量数据（一般是指服务）作为产品的质量信号，而不是用日常运行的测试结果作为质量信号。这包括系统数据，如CPU，API请求，系统响应时间，以及（妥善匿名处理的）用户数据。此外，还包括在生产环境中持续运行时交易发出的数据。这些依然是测试用例，你可以得到持续的可用性和性能状况，而不是只获得每天的失败 / 通过的状态。这是一种技术，但它也必定会改变我们的软件工程。角色的分类与归类(role and specialization versus generalization)的问题，答案是应满足每个团队的具体需要。数据科学家做为工程团队的一部分，就是TestOps方法的一个令人兴奋的结果。

版权声明：本文出自 omg 的51Testing软件测试博客：http://www.51testing.com/?166582

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

相关链接：

软件测试员，敢问路在何方？（第一部分）

posted @ 2013-05-13 09:30 顺其自然EVO 阅读(202) | 评论 (0) | 编辑 收藏

批处理脚本实现android应用程序自动化测试

　　测试平台：兼容android所有平台（2.3-4.2）

　　测试背景：由于需要对产品的SDK做接口测试，而这些接口需要在app里面调用，故开发了一个简单的android应用（如图），用来调用需要测试的接口，app中的每个按钮其实都是一个测试模块。

　　测试需求：

　　1、由于某些接口在程序第一次安装打开时调用，需要实现自动化安装打开关闭卸载测试，可设置重复次数。

　　2、由于需要测试接口的稳定性，每个按钮每天都要跑多篇，所以实现简单点击的UI自动化，循环点击。

　　3、自动检查收集logcat日志并解析日志结果；自动发送邮件。

　　下面主要讲下在windows下如何实现以上需求。

　　一、准备测试环境及测试文件

　　1、安装Java JDk，设置好环境变量

　　2、安装Android SDK，设置好环境变量（详细步骤略）

　　3、准备被测apk及测试所需的一些工具

　　接着主要讲下测试主程序如何实现

　　二、启动模拟器，并解锁

　　批处理脚本：

　　三、脚本参数初始化

　　四、循环执行安装打开关闭卸载

　　五、处理source.txt提取关键信息，并发送邮件

　　六、设置windows定时任务，参数填写为测试次数

　　经过以上步骤，安装卸载测试已经完成，接下来讲解如何用adb命令进行UI自动化测试

　　一、打开应用，记录按钮或text在手机屏幕坐标点

　　1、在android 4.0以上版本中，可以实时显示手机屏幕坐标点

　　2、点击设置-应用程序-开发人员工具-指针位置

　　3、打开应用程序，获取按钮的坐标位置，如图坐标为（138.168）

　　二、脚本模拟屏幕点击事件

　　这样就模拟了屏幕点击的事件，若要测试长按，设置等待时间

　　三、脚本模拟键盘事件

　　如图，在text中输入数字134

　　脚本模拟键盘事件

　　这样adb模拟的UI自动化脚本就可以写好了，这种写法的好处在于快捷轻便，适合简单逻辑的自动化。

　　结语：以上就是需求实现的全过程，当然此方法也可以用再ubuntu、mac之类的Unix系统中，只需将相应的批处理语言改成shell语言即可。

posted @ 2013-05-13 09:28 顺其自然EVO 阅读(1507) | 评论 (0) | 编辑 收藏

没有测试怎么敏捷？

　Bug是什么？

　　警告：如果你有挑剔的眼光，并且你已经发现了写软件的唯一正确方法，你可能会感到被挑战。

　　新来的开发人员提交了代码，但是有bug。他们搞砸了代码，一个链接显示为明亮的、刺眼的红色，而不是公司要求的柔和的蓝色。你找到她，坐在一起，开始教导她测试的重要性，这时接到市场部的祝贺——因为最近一次发布，销售额上涨了了50%。

　　你知道唯一的修改是链接的颜色。

　　代码真的有bug？你还要诚实的把它回退？

　　更重要的是，这也是许多人搞错的问题：你从这件事得到什么教训？

　　为什么要测试

　　我们使用敏捷开发是希望改善开发过程，更好的分享信息，特别是更加方便频繁的获得反馈（这是一个反复发生的流程）。有趣的是所有的敏捷开发理论都要求使用者调整敏捷开发理论来满足个性的需求。我之前说过并且现在重复一下：你不能敏捷开发除非你自身是敏捷的。所以一些敏捷团队没有固定的迭代过程。其余的（大多数？）不搞结对编程。代码审查成了tricky bits（译注：不了解的词汇）和初级程序员。然而，尽管方法不同，这些公司往往做的很好。

　　但是他们都没有想要不做测试，他们没有想过。

　　在我们的“红色链接”例子中，如果进行了测试，那么就不会有50%的销售额增长。

　　我们大多数人很早就接触测试并且认为它不错。然后我们了解了TDD 并且意识到这就是测试的涅磐。 FIT testing 被那些FIT测试咨询机构过分的夸大了。现在BDD的情况也是如此：一些人兴奋的不得了，另一些人不以为意。我想这不过是另一次炒作，不是么？

　　但是测试是为了什么？从技术的角度来看，我们也许会争论说测试就是确保软件按我们希望的方式运行。但是这是最重要的事吗？请铭记一点就是：在一咕哝行代码里，所有软件都有bugs，所有的！

　　相反的，我认为更好的说法是所有软件都有无法预料的behavior.我们写测试是因为我们希望软件会按我们期望的那样运行。但是反过来，如果用户按我们希望他们做的方式去操作不是更好吗？你可以建立一个更好的捕鼠器，但是不能确保它们会钻进去。如果有些是从Digg或者一些技术灾害学习来的，那就会是这样：客户将会按他们该死的很乐意的方式去操作，无视你的软件是否是“正常工作”、你咨询的专家们和你举行了多少次讨论组。

　　与其说软件测试是客户行为的一种代理，还不如我们静下来为软件的客户好好想一会儿。

　　意外列表

　　考虑上面的“闪亮红色链接”的例子，再问一次：什么是bug？在那个例子中（不是随机选取的），可以简单说是一个软件bug，仅仅因为按意料外的行为。在这个例子中，是50%的销售增长。

　　现在，bug不再总是坏事情！我们可以用“意料外的行为”来思考——有时好，有时坏。

　　那怎么知道到底是好还是坏呢？

　　做一个意外列表。网站的500错误是坏的，而302呢？难说。也许你希望RAM使用率低于一定水平，或不像看到明显的销售额下降。也可能希望响应时间永远不超过$x毫秒。

　　列出所有明确不合预期的事件（例如：Facebook没有“like”按钮不属此列）并对所有这些行为进行监控。每当你修改或添加一些技术，请再次仔细检查你的不合预期列表。它们是不是最新的？你是否需要修改什么？

　　一些不合预期事情是可逆的（销售下降）且替代方法是好的。因此，也要监控这些。或许当一个版本提升了10%的响应速度时你想得到通知。

　　那然后呢？

　　嗯，这是伟大的但绝对不可能代替测试。你提交了两周的版本，内存消耗猛增，你疯狂地交换以致现在需要检查300行的文件差异。你很难在最佳时间找到内存泄露问题并且正常的测试经常遗漏它们（除了检查Test：：LeakTrace），但现在你要回滚一个巨大的修改然后检查3000行代码来找出你的问题。

　　因此你不必那么多。相反，你可以转换为不间断部署。在这个模型下，在准备好的前提下，可以把代码推送到产品里面。当然，假如你把它推送到盒子里面的话也很好，观察它，推送它到集群里面，观察它，然后把它推送到所有的服务器。通过多方面的监控，不寻常的情况常常出现的很快。并且你的内存泄露是30行的diff而不是3000行的diff.

　　你想处理那种情况呢？

　　（理所当然，我用内存泄露作为例子，但是这是一件经常花很长时间才显露出来的，而且我也懒得去改变这个例子。假装我过去写了5%的增加在404.）

　　在我的这个经验中，顾客对一些小异常简直就是很宽容，像大部分意料之外的行为都是一些诸如“图片不能显示”或者“这些查询结果排序是不正确的。”这些并不会趋向于导致灾难性。事实上，许多次这种异常的行为是被忽视的。就不良的事情而言，大部分时间意料之外的的行为将转变为中性或者不良。但是有时候他们也会转变成为好的意想不到的行为。假如你不试一试的话是永远不会知道的。

　　正如你所预料的，这个技术在“A/B testing”这本书中运用得很好。如果你有勇气查找非预期的行为而不是bugs的话，这本书将是下一个合符逻辑的计划。

　　注意：以上并没有排除编写测试（用例）。我看过“监控不合预期的事件”战略工作得非常好也坚信它可以结合软件测试进行工作。然而，测试软件是不同的，它更依赖客户行为而不是严格规范。因此，这篇博文的标题实际上是有点不对，它只是一个看待测试的不同想法。

　　而这正是这篇博文真正最有趣的想法：客户的行为比你应用的行为更重要。

　　原文链接：http://www.oschina.net/translate/how-to-be-agile-without-testing

posted @ 2013-05-13 09:20 顺其自然EVO 阅读(143) | 评论 (0) | 编辑 收藏

我的“谈心式”软件测试法

　软件测试人员应该在合适时间介入软件开发流程之中，已经不是一个新鲜的问题。

　　许多软件测试前辈或“软件人”告诉我们，测试人员介入开发流程越早越好，这样就能尽早地发挥测试人员的功能，减少出现软件缺陷，降低软件工程后期的成本。

　　测试人员介入软件开发工程，多早是早，多早为好呢？现成的答案：即从需求开始，从整体设计开始。总之，早早介入就是想让测试人员直接参与其中，以测试的视角，超前发现问题，并协助各干系人，将软件缺陷解决在萌芽状态。如此，可收到“未雨绸缪”“防患于未然”之功效。

　　目的已明确，节点瞅准，具体应该如何操作呢？从多年的项目经历中，我总结出一套行之有效的做法，我把它称为“谈心式”软件测试法。

　　不论在任何开发模式下的项目组，都会有日例会、周例会或月例会，以及各种各样的例会。有的例会是为了发布什么消息，有的例会是安排当下的工作，有的例会是讨论某个问题（有时是需求问题，有时是开发问题，有时也可能是测试问题），有的例会是各种评审。我发现，就某些实际问题而召开的例会，大多数情况下是没有什么结果的，而这些问题往往是在会后、少数人参与的局部讨论中，则寻求到了答案。

　　这是为什么呢？我从多年的工作经历中，归纳出这么两个比较突出的原因：

　　1、时间问题

　　例会的时间常常比较短暂，尤其是在快节奏的开发模式（如敏捷模式）下的例会。因为整个项目开发周期短，任务紧，会议时间就十分有限。在例会上，每每是大家的思想还没有或刚刚撞出一星火花儿时，会议就结束了。

　　2、与会人员的性格问题

　　有很多与会人员，并不适应在会议上，面对众多人员的环境下畅谈自己的观点，而在会下人比较少的情况下，反而能畅所欲言。由此，这就严重阻碍了参会人员的思想交流。还有一些人，对跟自己没多大关系的问题，经常持一种不置可否的态度，这也会阻碍相互之间的思想交流。

　　由此，我摸索出来的“谈心式”软件测试法就有了用武之地。

　　一、针对开发设计人员

　　在项目的每一个迭代阶段初始，阅读或分析需求是测试人员必须做的步骤。只有熟悉了需求，测试人员才能更好地参与到需求评审或设计评审中。在这个阶段，我会做两件事：

　　1、分析、思考如何制定相关的测试策略和计划；

　　2、尽可能地发现需求中的问题。

　　这个所谓的需求中的问题有两种：一种是自己不太明白的点；另一种是需求本身可能存在的问题。

　　测试人员在做这些工作的时候，开发设计人员大多数也处在阅读分析需求阶段。这时，我就会带着自己的问题，对症下药，针对不同的性格和喜好的开发设计人员，采用不同的方式去和他们“谈心，以求各个“击破”。对待喜欢直接谈话交流的人，我会选择面谈；对待不喜欢这种交流方式的人，我会选择用一个文档或邮件的形式进行沟通。

　　不管用什么方式，“谈心”的目的无非这么几个：

　　（1）表露自己对这个需求的看法、对新功能或功能改动的测试思路，针对这些思路，询问开发设计人员的看法；

　　（2）针对已经发现需求本身存在的问题，首先寻求开发设计人员的帮助（因为，每个人的经历、阅历和能力有差异，对同一个问题的理解是不一样的）。如果开发人员也已发现了这个问题，或是经你提醒，确认这确实是个问题，而彼此眼下，都还没有较好的解释或答案时，可以联名向需求人员或客户直接提出，以寻求进一步的确认和答复；

　　（3）根据测试人员对开发设计人员工作习惯或“毛病”的了解，可用一种善意的方式，提醒他不要再犯以前曾经出现过的问题（即有可能是粗心或对需求不正确的理解所导致的问题）。

　通过这样的“谈心”交流，有时可以拓展自己在制定测试计划或测试用例时的思路，有时可以解决开发设计时的需求理解问题，甚至可以避免因开发人员的人为因素而造成的缺陷发生。

　　我一直觉得，测试驱动开发，是一种测试“驱动”开发方式。测试人员主动参与设计，诚挚跟设计、开发人员“谈心”，不仅可以帮助他们从测试的角度去看待一些问题，还可以使测试人员本身的思路更加清晰，而且，开发人员也可以拓展测试人员的思维。更为实在的是大大提升了工作效率，缩短了开发周期，降低了公司和客户的成本。共享多赢，何乐而不为？

　　二、针对需求制作人员

　　起初，我仅仅把“谈心式”软件测试法应用到了开发设计人员层面。后来，我发现这个方法不仅可以应用到与开发设计人员的沟通上，也可以用在需求制作人员的身上。

　　需求制作人员在制作需求文档的时候，经常要从两个角度出发，一是从客户的角度出发，因为他们要制作出客户满意的需求来。二是从软件开发角度，他们要思考功能实现的可能和成本。

　　不管怎么说，需求人员在对客户需求做二次加工的时候，就会自然而然地注入其个人的观点或意愿。测试人员在阅读、分析需求文档的时候，如果发现什么疑问，比如说新需求和软件系统以往的风格有出入，或功能点描述模糊，或其他一些问题，测试人员就可以直接与相关需求人员沟通，寻求问题的确认和帮助。这样的“谈心”，不仅仅是对需求的一定评审，同时也是对自己的测试工作的帮助。最为主要的是与需求制作人员多交流，多沟通，致使对需求更加明确无误，以免多走弯路，影响工期，增加成本。

　　三、针对客户

　　随着阅历的拓宽和实践经验的积累，现在的我已不满足和需求人员、设计开发人员“谈心”，有时也会与客户直接“谈心”。

　　在敏捷开发模式或其他快速开发模式下，项目组成员和客户的直接交流已成为可能，而且变得越来越频繁，越来越重要（比如我们现在的项目组）。

　　“测试从客户的原始需求开始”，已经是我的一种工作方式。

　　在遇到需求制作人员也无法给予答案的问题时，我就会直接和客户“谈心”。毋庸讳言，有很多时候，客户的需求是模棱两可的，甚或是想当然的。有时他们提供的原始计算方法或运算流程（在很多软件项目，客户所用到的计算方法或公式是很专业的，所以必须由客户直接提供）是不正确的。在这种状况下，如果测试人员发现了这方面先天不足的问题，并及时与客户“谈心”沟通，将之扼杀在萌芽状态下，必然会避免项目组宝贵时间的浪费，挽回客户相当的损失。

　　“谈心”不仅可以发现问题，解决问题，“谈心”还可以让测试人员更多地了解现在开发的软件所涉及的行业规范及其他知识。同时，也能为测试人员更好地测试当前软件、系统或产品提供准确的知识背景；能让测试人员制定出更符合此软件的测试用例；能有针对性地发现更多不符合行业规范或要求的软件缺陷。多年的经验告诉我，对于一个前沿的测试人，对当前系统所涉及到的行业、领域知识，在一定程度上，比测试技能（测试方法的应用、测试工具的使用）更为重要。

　　测试人员直接与客户“谈心”，似乎有“越俎代庖”之嫌，倘若遇到多虑的需求制作人员，有时难免会造成一些误会，生出一些不必要的嫌隙。在此值得一赞的是，我比较庆幸自己加入了一支奋发向上、相互尊重、团结和谐的团队。只要是有利于项目开发，有利于客户需求，我们这个团队，从不过多计较所谓的“规矩礼数”。

　　其实，测试人员不仅仅可以和文中所提及的这三类人员“谈心”。只要是项目干系人，均可用“谈心”的方式去直接或间接地对软件进行测试。测试人员可以把思路打开，不要仅盯着软件、系统本身。整个项目组从人员、到流程，都可以成为测试人员的测试对象。套一句时髦概念，此可称为“大测试”理论。

版权声明：本文出自 shan0310223 的51Testing软件测试博客：http://www.51testing.com/?624630

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

posted @ 2013-05-10 09:56 顺其自然EVO 阅读(166) | 评论 (0) | 编辑 收藏

不能成为专业软件测试人员的10大理由

　你是一名专业的测试人员吗？

　　如果你看到这篇文章了，你就有机会成为专业的了！

　　我写这篇文章并不是因为这个，其他无数的测试人员有比我更多的好东西拿来分享。总体而言，我的意思是在空闲时间阅读其他测试相关文章来提高自己的测试技能时，你也将是有志成为专业测试人员中的一分子。

　　寻找最佳理由

　　上周我在LinkedIn上看到有人讨论“为什么测试不是一份职业”，有很多答复包括说“因为大学没有专业授教”，但都是说“因为它是新兴的，人们并没有专业的进行学习”。但我没有找到有人反驳这个观点的人并说“因为大多数人工作的方式就不是专业的，才被觉得测试不是一份职业”。

　　我猜大家都注意到了给我们的责备而忙于自怜和抱怨受到的不公平。

　　寻找答案

　　坦白的讲，不管在哪我们不被当成专业人士都是因为我们并没有优先地专业化的开展工作。

　　基于我有限的工作经历，不管什么地方认真对待工作并尝试改进而给组织带来的价值的测试人员都会被尊重，并且会给予高度的评价和感谢。

　　现在切入正题，不能成为专业测试人员的10大理由：

　　1、你认为测试并不是一份技术性的职业，所以并不去尝试学习理解产品的编码

　　如果你从事的是软件开发，至少会理解一些软件工程的知识。而作为测试人员，你应该能够读懂代码来分析产品，来理解代码的变更和修复将会如何引入其他的bug.黑盒vs白盒的日子应该结束了。

　　如果你不想这样，即使不用写任何代码依然可以从事该工作。但是如果你不去读代码，将会失去对整个测试流程很重要的一项投入。

　　2、只有当开发人员告知开始测试时才真正介入到整个流程中

　　大家如实的回答，在整个开发流程中何时开展测试的？

　　理论上我们想在需求收集分析阶段就介入，和其他成员一起完成余下的，事实上我们很难投入进去，只有当开发人员想尽快得到反馈首次提交代码交付给我们时才能介入。

　　为什么要这样持续下去？大多数测试人员会说这种测试工作是开发流程中的最后一环，当其他人忙于计划时我们总是忙于测试。

　　但是实际上，如果不能每天抽两小时做测试设计就意味着你在管理时间上很差劲。而且还意味着，你不想提早介入到开发流程中的唯一原因是没有优先处理，或者换句话根本不想这么做。

　　3、只有在技术支持的同事要求重现bug时才与客户之间交流

　　测试人员一部分工作职责就是基于各种用户使用场景进行测试，一旦产品发布之后基于场景来寻找bug尤为重要。

　　但事实上（这里应该指的是外包项目中），在整个开发流程中你只是代表了客户而不是用户，根据客户的工作行为来计划测试及搭建测试环境，只是被期望基于他们的需求和限制来提供功能反馈。

　　如果真是这种情况，不了解真实的用户如何代表用户模拟他们的行为呢？最后一次访问用户如何使用产品是什么时候？工作中你能真正考虑到他们如何使用产品和工作环境有哪些限制吗？我猜答案一定是NO！

　　去拜访一些用户直到你理解他们，才不会一直做这样差劲的工作。

　4、只有在处理人寿保险时才进行风险管理

　　对于测试有一个简单的真理，也许是最微不足道的：测试人员没有足够的时间验证一切。这时，基本的风险管理派上用场了，帮助我们区分工作的优先级，哪些需要测试，哪些优先测试，可以假定哪些是基于其他测试结果上工作的。

　　但是如我所说，这只是风险管理基本的一面，更高级的是在分析跟测试压根一点关联都没有时候可以提供更大价值。

　　所有测试人员都知道产品中风险更大的区域是哪里，哪里有更多的bug，团队因为什么不定期和无计划的事务被推迟的。

　　作为测试人员我们应该意识这些区域并在项目不同的阶段实时提醒团队。这样，我们也能决定是否使用产品其他模块开发这些功能，或者考虑到这些意想不到的问题迟早都会出现，如果允许的话是否可以花更多的时间来保持系统的稳定。

　　你应该尽力尽早暴露这些影响产品的问题，不管是已知的还是潜在的，帮助团队设定靠谱的目标，在时间和预算上达成目标。

　　5、你没有任何计划来提高自己测试工作的价值

　　测试职业在许多方面都是未知的领域，有很多途径带入到测试行业，一旦进入到测试行业中，就有各种途径来改进测试专业技能。大部分测试技能提升来自于个人，而且将会由测试人员个人能力，当前工作环境的需要和限制，还有就是当前能获取的信息来源等因素决定的。

　　总之，并没有唯一的途径把自己培养成一名专业的测试人员，而且并不容易，成效并不快。所以除非你决定想真正改进开发流程，并且知道如何达到这些目的后才能够真正提高测试技能和提高能够贡献给团队的价值。

　　如何达成呢？

　　开始列出作为测试人员的强项和弱项，想想哪些方面你想改善，最终寻找可取的方法。有一件事很确定，如果你不把握机会或者跟别的测试人员的职业发展牵着一起，将永远不可能得到提高。

　　6、我们认为测试工作就是设计和运行预先定义好的测试用例

　　其实除了运行测试用例之外，还有更多的内容：

　　- 对产品设计上提供反馈；

　　- 分析当前项目计划的风险；

　　- 在不同的开发阶段提供非正式的反馈；

　　- 开发自动化框架，能帮助开发人员维持他们所开发的产品的稳定性；

　　- 运行脚本或用例，但不单单是之前预先设计好的；

　　- 分析测试结果以及能获取的所有信息，帮助我们了解产品的最新进展状况；

　　- 在流程中持续反馈

　　而且我们可以照这些步骤持续开展。

　　总之，如果只是单纯的运行用例并设置为PASS OR FAIL，那价值远远没有实现。

　7、自动化是一门高级学问，测试项目能在以后空闲时间里开展

　　请不要想出一大堆借口解释为什么不做自动化！

　　从另一个角度讲，这是一些测试人员技术弱点的另一面。

　　自动化不是灵丹妙药，并不能处理测试人员遇到的所有问题，但是通过使用脚本或工具仍然能够代替我们做一些重复的劳动，更高效，更省时。

　　问题是，一些测试人员到这里仍然感觉不够有技术含量，所以他们并不选择通过自动化或脚本改进测试。某种意义上讲，就好比使用钻木取火而拒绝用打火机并一边说这种方式很容易。

　　8、大多数时候非常自我自负的做测试

　　一个好的测试人员应该谦卑。我们需要知道如何提供反馈，更重要的是如何从其他组员或同行那获得反馈。

　　如果其他成员特别是开发人员对测试工作提供一些未经请求的反馈，或者他们查出bug遗漏或测试没有执行后，很多测试人员感到很沮丧。其实每次都有很好的理由来解释漏测，只需要冷静下来分享下这些信息，但是很多测试人员认为这是对工作失职的人身攻击，并且反驳说一些难听的话。

　　同时，我们需要知道如何提交bug，并为团队提供消极的反馈，并且需要知道如何从同行那获得建设性的批评。

　　没人期望你是完美的。但是他们期望你能认真对待失误并且同时从获得的反馈中学到经验教训。

　　9、并没有跟进需要改进提升的技能或领域

　　之前我其中一个最好的经理经常谈论我们个人的“虚拟工具箱”，好比我们所携带的技能在需要的时候随时可以使用。

　　在你的工具箱里都有哪些？

　　哪些工具需要改进或更新了？

　　哪些是你需要的，哪些是下一步想要获得的？

　　不容置疑，测试像是一门手艺，没有合适的工具不能创造需要的产品。

　　10、你的职业发展生涯就是成为管理人员或改行

　　有些人转行是因为他们觉得做测试是种很好的途径转做开发，还有部分人根本不知道测试是干什么的，甚至是因为觉得整体玩弄这些程序很好玩。毕竟，也难不到哪里去。

　　一部分人最终成了很棒的测试人员，但是多数人最后失意收场，度日如年的盼着啥时候能结束测试生涯，可以做自己想做的工作，而另外的人并不欣赏测试所带来的挑战，他们觉得唯一获得进步的就是做管理。

　　没错，做管理的确也有挑战和收获。但是不做管理也是要克服无数的问题，这些也许能给予你更大的挑战和收获（绝对还没那么头疼）。

　　我的观点是，如果你一直在想做其他的而不能关注于做一名更好的测试人员，根本不可能做的更专业。所以想想是否入对了行或者可能应该简单地摸索点别的。

　　想成为专业？首先作一个专业的测试！

　　总结上面10点，贯穿始终的是如何改变我们对测试的认知。

　　第一步就是把测试当成你的职业！

　　当我们做到了第一步，第二步就是看看哪些我们遗漏了，哪些我们需要加强，我们要怎么开展工作以及如何与同事及客户处理好关系，以及为了提高我们的价值现在能做什么。

　　第三步是我们应该未雨绸缪，并且意识到作为一种职业在变成大师或专家之前有很多东西需要学习。

　　最重要的是要意识到这种改变要发自肺腑有实际行动，而不是从一些神赐予的法令而来，或者邮件所署名字旁边的标题来证明。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

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

posted @ 2013-05-10 09:54 顺其自然EVO 阅读(315) | 评论 (0) | 编辑 收藏

自动化测试框架AutoRobot介绍

一、自动化测试发展

　　自动化技术在不断的发展，从简单的录制回放到数据驱动到关键字驱动，再到模型驱动，每一次自动化技术的发展都会带来自动化测试工具的革新，而每一次新的测试工具的诞生都会带来新的突破，新工具的出现带来了新的体验但是也不可避免的有一些缺陷，正是因为此，才推动测试框架不断的完善，强大，下图展示了自动化测试技术的发展。

　　二、淘宝自动化测试框架发展

　　随着自动化技术的发展，淘宝自动化测试框架也在不断的完善，从Tcommon到Automan再到现在的AutomanX，测试框架的完善带来的是自动化效率的提升，相对来说，AutomanX已经相当的完善了，但是AutomanX是一个集成化，模块化的的测试平台，需要测试人员具备一定的编码能力，并且对mvn，junit，spring等技术有一定的了解才可以进行测试脚本的编写，同时，AutomanX是基于pageModel的，在进行脚本编写时，需要先建立pageModel，增加了脚本编写的工作量，基于此，我们又开发了新的自动化测试框架AutoRobot，来完善AutomanX的这些问题。下图展示了淘宝自动化测试框架的发展。

　　三、AutoRobot介绍

　　1、功能介绍

　　AutoRobot是关键字驱动的测试框架，核心基于Selenium2.0。AutoRobot针对不同能力的测试人员提供两种脚本设计方式，一种为NoCoding方式，通过选择页面元素及对应操作来完成测试步骤的设计，另外一种为传统的Coding方式，通过编写代码完成测试脚本设计，无论使用哪种方式，AutoRobot都支持自定义的关键字设计，除了框架提供的统一的关键字定义外，不同业务可以根据业务需要设计适合自己的关键字，下图展示了AutoRobot的主要功能

　2、NoCoding脚本设计

　　AutoRobot使用Chrome插件进行元素拾取，使用关键字定义进行元素操作，设计好的测试步骤可以转化为自然语言描述的操作步骤，可以转化为java测试方法，还可以转化为XML语言描述的测试步骤，设计好的测试步骤如下图：

　　3、Coding模式脚本设计

　　使用Coding模式设计脚本，可以完全不需要在WEB上进行操作，但是最好的方式是先使用NoCoding的方式设计好测试步骤，再利用AutoRobot提供的java工程下载功能，将转换为java工程的测试下载到本地，导入IDE后再进行开发，因为通过AutoRobot下载的java工程是一个完全可运行的工程，其中很多的代码已经编写完成，可以节省很多的工作量，下图展示了下载后导入到eclipse中的java工程及及测试用例对应的java代码

　　四、AutoRobot特点

　　相比AutomanX，AutoRobot具有以下特点

　　1、关键字驱动方式使得脚本，业务，数据分离，并且可自定义关键字，易于维护，方便扩展

　　2、页面元素定位方式自动拾取，一边操作被测应用一边进行脚本设计，方便直观

　　3、使用原生selenium元素查找方式，无需建立pageModel，极大的节省了pageModel建立维护的时间，同时提高了元素定位的效率

　　4、测试步骤直接转化为java代码工程，支持NoCoding方式和传统Coding方式的脚本设计，在降低自动化脚本设计门槛的同时也为提高编码技术提供支持。

posted @ 2013-05-10 09:47 顺其自然EVO 阅读(1194) | 评论 (0) | 编辑 收藏

【我的面试经历】美企（一次非常充实的面试）

　面试时间：2013.2.28
　　应聘职位：软件测试工程师（面向应届生）
　　应聘公司：群硕软件（上海）开发有限公司
　　流程：笔试，技术面试，HR面试
　　费时：一天

　　上午九点半开始笔试，有选择题，简答题，程序题，智力题，看图找不同

　　选择题有测试的基础题，还有一题Java程序，选项是程序的运行结果，还有C语言一题

　　简答题有：什么是边界测试，为什么需要边界测试，什么是黑盒，什么是白盒，测试结束的标准是什么

　　一道英文题：设计三角形的三边数据，并说明要什么三角形（我是用中文做答的）

　　程序题：有两题，将两个整形数互换（语言任意），求两个数的最大公约数（不能用递归，题中已给出递归的程序）

　　智力题：小明一家人过桥，小明需要1秒钟，小明弟弟需要3秒，小明妈妈需要6秒，小明爸爸需要8秒，小明爷爷需要12秒，每次最多只能两个人过桥，以慢的那个人的时间为准，因为是晚上，只有一个灯，30秒后会熄灭，如何过桥？？

　　当时我回答错了，后来想出来了答案

　　小明跟弟弟先过桥（3秒），小明返回（1秒），爸爸和爷爷过桥（12秒），小明弟弟返回（3秒），小明跟妈妈过桥（6秒），小明返回（1秒），小明跟弟弟一起过桥（3秒），总共用时29秒

　　看图找不同：与QQ游戏上的大家来找茬的游戏一样，共找出五处不同

　　11点笔试结束，就可以离开了，说改完卷子会通知笔试通过的人来面试

　　下午1点，技术面试

　　技术面试是两个面我一个，面试官一男一女

　　问我对测试的理解

　　问了ECShop的项目，我测的哪些模块，没测的有什么，店铺归谁来管，是不是管理员等等细节问题，当时回答得比较混乱，没有把系统弄熟悉

　　什么是灰盒，用例包括哪些，缺陷报告包括哪些，严重程度与优先级别的区别，举例说明（系统崩溃但发生的概率小，是高严重低优先，界面出现字符的错误，是低严重高优先），如果判断概率小，是一百次还是一千次，我弱弱地回答说：自己看着判断的。。。

　　数据库的发展情况（文件型，关系型，面向对象型。。。），oracle,mysql,sqlserver的sql语句有什么不同（不知道），Linux命令中创建文件与创建文件夹有什么不同，删除文件与删除文件夹有什么不同（都忘记了），缺陷状态的流程（口述的）

　　QC有哪些模块，怎么样让缺陷关联用例

　　懂什么编程语言（回答：c++，C，Java，VB等都学过），最擅长的是哪个（回答C）

　　还问了我简历上以前做的兼职的情况，英语情况（过四级），然后让用英语自我介绍，是事先准备好的，自我介绍中提到一句I have good test skill，然后面试官问：what test skill do you have,我说：use test tools, design test case, write test report然后她用中文说这些不属于skill，我自己都没法回答了

　问的特别多，比较细，基本是问一个，就引出问题接着往下问，技术面试差不多一个小时左右，面试官也比较和蔼，时不时面露微笑

　　技术面试后，有些就被人事的请走了，说回去等通知，其实就是没有机会了

　　我等到最后才HR面试

　　大概下午3点的时候HR面试，是一对一

　　首先中文自我介绍，然后问为什么会选择测试等等，后来说，我们现在这个会议厅，你看一下有什么缺陷，然后我说管子不应该暴露在外面，门口过窄，让人感觉空间小，都是白墙，过于空洞，应该挂些画之类的，感觉让人不是很满意，说的点太少了

　　然后又看着桌上的电话，问我如何测电话，我大略地说完后，HR说了一下自己的思路，比我说的全面多了

　　认为测试应该具备什么素质（我说英语，编程，细心，耐心），后来问对公司的了解，用自己的话概括一下公司，说说公司的网站有什么好的与不好的，我说完后她说我可能了解地比较少，我说只是点开看了一下，后来问如果网页打开出错，我能想到是什么原因（我回答：有可能是网页太多人访问，有可能是浏览器本身的问题，有可能网站在维护，有可能是服务器端的原因）

　　然后问我对技术面试官的评价

　　后来问了期望薪资，我说三千到五千（考虑到还没拿到毕业证），她说范围太广了，然后问跟我一起培训的同学一般就业后是什么薪资，我说四千以上，后来又聊了一些住址，家庭情况等等，最后问我有什么问题，我说公司是有培训的吗，回答说是的，然后问如果通过面试什么时候能给到通知，她说三到五天，然后面试就到此结束了

　　还有很多问题忘记了，基本是聊到哪问哪

　　第二天下午就给了offer，算是比较顺利

　　感受：面试问得特别全面，很细致，给人聊天的感觉

　　如愿以偿地进入了这家公司，刚开始是培训，可以学到很多东西，公司的气氛也非常好，虽然有点压力，但是工作得很开心。

　　这是我今年的第一次面试，收获很多，希望能给到大家帮助。

　　原帖地址：http://bbs.51testing.com/thread-942464-1-1.html

版权声明：本文由会员 Alice1219 首发于51Testing软件测试论坛九周年庆活动。

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

posted @ 2013-05-10 09:46 顺其自然EVO 阅读(294) | 评论 (0) | 编辑 收藏

测试，乐享其中

　最近两年还真做了不少的测试。现在发现测试的重要性，是自己吃过亏。你觉得已经找不出错误的地方，居然还真有；你觉得不会有影响的地方，居然还牵扯上了。还是那句老话：

　　测试只能证明问题的存在，而不能证明问题不存在。

　　回想对待测试的态度，已经做了一个准备。以前真的看不起测试，这在国内是普遍现象，现在逐渐认识到测试活动，不管是对个人，还是对项目公司，都是非常重要的：

　　1、TDD是测试与开发的融合。基本上很少有机会有专门的测试团队来验证你的代码，自己得测试，而且得详尽办法找到尽可能多的问题。

　　2、测试要是可复用的。这个问题比较难解决，测试的粒度太小的话，代码的变动，很容易破坏测试用例。一个方向是，测试输入和输出，而不要过分关注执行流。测试的复用能够保证每个Release都不会破坏既有的行为。

　　3、测试尽量自动化。这个跟应用紧密联系，千差万别，发挥聪明才智，总能找到自动化的解决方案。

　　4、测试适可而止。需要在投入和产出之间做出衡量。应该没有公司对待UT像对待代码一样严谨。可以用往往是成功产品的第一步。

　　5、还有一点需要注意，质量是规划出来的，而不是测试出来的。不要对测试期待太高。一个拙劣的架构或者设计，注定就是Bug的聚集地。前期不重视，没有提供测试的支持，临时抱佛脚，也是回天无力的。

　　我们不应该排斥测试，领导安排你做测试，应该高兴才对。一是可以找别人的茬；二是很好偷懒。当然这样的态度不推荐。测试跟开发是紧密联系在一起的，需要的是沟通，而不是相互指责。因为很难衡量测试的效果，以及对需求的理解偏差，所以测试很好偷懒。可以用下面的公式来衡量测试的效率：

　　测试效率 = 历史测试效率 × Bug数量 / （需求项目数 × 时间）

　　找茬偷懒都不好。好的是测试可以帮助熟悉系统。码农的出路中，两条很重要的就是领域专家和架构师，他们都需求对业务非常熟悉和了解。阅读需求文档不正是给你了解产品，了解用户，了解领域的机会么。实效点的作用，会在编码过程中潜移默化的提升考虑问题的广度和深度。

　　调整心态，测试的目的是保证产品的质量，为用户提供安全可靠的服务。只有将自己重新定位，才能正视自己的工作，为公司创造价值，为个人开辟蹊径。

　　测试是需要方法的。前面说了测试需要适可而止，需要平衡投入和产出，那么测试就应该有针对性，好钢用在刚韧上。两个指导性原则：

　　1、保证基本功能可用，基本测试。

　　2、识别出风险高的部分，比如交互，边界，顺序啊。

　　最后，找出来Bug是不是很有成就感？但请把成就感放在为客户提供高质量高可靠的产品上吧！

　　原文地址：http://my.oschina.net/sulliy/blog/87766

posted @ 2013-05-10 09:44 顺其自然EVO 阅读(202) | 评论 (0) | 编辑 收藏

一个软件测试工程师的成长日记（连载四）

1.4  职业生涯的考虑--技术还是管理

　　职业生涯规划是每个专业人员都应该慎重考虑的问题。测试工程师是一个专注程度很高的技术背景职位，职业上应该往哪个方向发展，是测试工程师到了一定时候应该考虑的问题。在IBM，因为业务涉及很广的范围，因此，提供给员工们选择的空间非常广阔。就技术职位而言，发展的方向主要包括技术方向和管理方向。另外，转向商业业务部门也是可能的选择。那么，作为测试工程师，在技术上或管理上都有哪些可以选择的发展方向？一个菜鸟工程师，应该如何选择方向？

　　1.4.1  测试工程师的技术发展路线

　　作为职业发展起步，测试工程师可以先把自己定位为某种专门测试的专家，如功能测试专家、系统测试专家等。无论从哪种专门的测试开始，测试新手都有机会了解测试的一般方法论和通用的原则，这些知识对于不同的测试领域都是必需的。此外，针对不同的测试，测试新手需要学习特定的测试方法。例如，对于功能测试工程师而言，黑盒测试理论、测试用例构建和分析等技术是必不可少的；而对于系统测试工程师，了解不同种类系统的特性、性能指标，学习系统测试构建方式等技术是必修课；而对于构建测试工程师而言，学习构建技术的原理、系统部署技术、增量和全量发布技术等内容对于进行构建测试是非常重要的。有了一般性的技术和针对特定测试种类的专业技术作为基础，测试新手需要通过项目经验的累积，逐渐达到测试专家的水平。关于测试工程师的技术发展路线见图1-5。

　　由于不同的测试种类之间是有关联的，对于不同的业务步骤也很具有针对性。作为某种测试的专家，通常只熟悉和这类测试相关的系统特性或功能。如果希望对系统有更全面的认识，这时可以考虑转为另一种测试类型的测试工程师。在转换测试类型时，并不需要重新学习测试理论，而仅需要学习新的测试类型的测试技术和被测试的系统模块。测试工程师成为多种测试类型的专家以后，对整个系统的测试方法和测试流程都会有全面且深入的理解。

　　到了这个阶段，测试工程师要面临的是另一次选择。有了对多种测试类型的积累，工程师对被测的业务也有相对深入的理解，这时，可以转向基于基础产品的项目开发的主要测试负责人的角色，或者成为一名技术支持专家，专门解决和客户有关的技术问题。如果希望在测试方面做得更专注，那么，也可以选择成为产品的测试架构师，从不同的高度更深远地影响产品测试的方法论和策略。如果工程师起初并没有转向别的测试类型，而是专注在同一种测试类型上，那么，就有更多的时间集中地把一种测试类型研究透彻，目标是成为这种测试类型的专家或大师。每种测试类型都需要方法和实践上的创新，而测试高手和大师无疑更能推动这种创新。

　　我们说过，在敏捷开发团队中，测试工程师作为开发项目的成员存在。在积累了一些项目经验并具备相关的技能以后，测试工程师可以开始尝试敏捷开发团队的其他角色。一种典型的选择是成为开发工程师，把专注的点从测试变成开发。拥有产品质量控制经验的开发工程师，从技术上更能把握对设计和实现的质量考虑。当然，开发和测试就工作性质而言差别较大，对于刚从测试工程师转型的开发工程师，学习开发模型及相关技术会是一个不小的挑战。

　　本身经验已经比较丰富的测试工程师，可以转成产品架构师，直接参与设计。直接成为架构师以前，测试工程师应该已经了解一些测试以外的内容，如业务需求和市场背景、产品整体架构、适当的实现细节等。因此，从测试工程师转型为产品架构师，也是个很有挑战性的变化。如果希望技术做得更深入，产品架构师也许不是最好的选择；信息架构师角色，如应用架构师、基础设施架构师等，为走深入技术路线的测试工程师提供广阔的选择空间。

　　在IBM，纯技术背景的专家只要做得足够好，都能得到认可。在这种氛围条件下，测试工程师可以根据自己的兴趣选择职业发展方向。有人说，兴趣是一个不时变化的玩意儿，不错，因此，在这里不乏从测试工程师转型成其他角色后又重新回来的案例。有一个足够大的舞台，周围有许多各方面技术的专家，也有许多成功或失败的案例作为借鉴，测试技术专家在确定自己的职业发展路线时拥有非常广阔的选择空间。

　　小艾作为测试工程师加入团队，随着经验的积累和技能的提升，越来越多的选择会摆在面前。当达到一定程度的时候，如何选择职业生涯发展路线的问题会再一次出现在小艾的面前。

　1.4.2  与人打交道--管理测试团队

　　在一个大型的软件开发项目里，完成开发任务的主体是整个团队，而非单独的个人。为了使团队有效运作，管理角色不可或缺。在测试团队中，管理的任务通常由测试组长和测试经理负责。区别于纯技术的职位更多地关注技术的细节，管理人员必须花相当多的时间与人打交道。作为测试管理人员，为了让团队以高效率运作，需要关注人力资源和合理分配，使测试工程师的技术优势得以发挥。在定义测试任务时，测试组长从宏观的角度考虑现有资源是否可以满足完成测试任务的需求；如果资源不足，是否可以通过沟通解决。测试经理还需要关注辖下组员的技术和职业发展诉求。测试管理者好比测试团队的大脑，"大脑"要完成对团队整体行动的决策和总体指挥。从分工角度来看，管理人员和技术专家的区别是非常明显的。

　　相对于一般的项目管理，测试管理需要更专注于风险控制和质量控制。项目出现变更时，测试进度就有可能受影响，进而有可能影响产品的最终质量，或者说，项目的风险有可能提高。管理人员应采取必要措施，控制项目的风险。从技术角度看，测试管理人员需掌握项目管理的相关技能。

　　随着测试工程师的经验累积，以及对相关测试技术和项目管理技术的掌握，到一定程度时，测试工程师就可以选择转向管理角色，成为测试组的技术组长或测试项目经理。技术组长在技术上至少能达到一般组员的水平，而工作上则体现出更强的技术领导力和影响力。因为技术组长关注的面更广，同时有更多和人相关的事情需要处理，因此对技术细节的关注度会不可避免地降低。测试项目经理则关注测试项目的进度和项目管理的细节。

　　测试组长的职位本身还是技术性质的，而测试组长的进一步发展方向又是什么呢？测试组长面临的选择相当丰富，在管理的道路上进一步发展，测试组长可以尝试测试经理或开发经理的职位，把更多的注意力投放在管理方面；从业务方向看，由于已经积累了比较深厚的测试专业知识和一定的业务知识，测试组长可以转而尝试业务方面的职位，如技术销售、技术服务等；如果希望继续从事专注于技术类的工作，测试组长可以基于某个测试种类深入钻研，成为这个测试类型的高级角色。

　　1.5  学习笔记--测试入门之小艾观

　　万事开头难，小艾作为菜鸟测试工程师加入到测试项目团队，以一名新人的视角学习了不少关于测试入门的知识。有了基本的知识及对测试专家广阔的发展前景的把握，小艾将有机会在测试的海洋开始一段新的旅途。学习之余，小艾也得到不少感悟。

　　要成为专业技术人员，花大量时间和精力学习专业技术是不可避免的。学习基本功是一个苦练的过程，但同样需要讲究学习方法。知识学习其实是体系性的，软件测试有一套完整的知识体系，把握知识体系的脉络，会让学习更加得心应手。

　　除了技术，对于测试新手而言，了解测试的业务和基本方法同样重要。测试是一个工程化的过程，测试在软件工程过程中必不可少，而且和项目的成败关系密切。测试新人既应该知道测试人员肩上的重担，同时也会以作为一名测试专家而自豪。

　　同是测试工程师，修为和级别可以有很大的差异。有不少"特性"会从测试专家和测试高手的身上显现出来。如何才能成为测试专家和测试高手？与其说这种修为是专业技能的提升，不如说是思考能力和思维深度的提升。"学而不思则罔"，作为测试工程师，思考（Think）是让学习成果升华的过程，同时也是解决问题所依赖的"必杀利器"。这种思维的能力不光测试专家应当具备，对所有专业技术人员来说都非常重要。

　　"人无远虑，必有近忧"。虽说加入测试团队的时日很短，但作为测试新人，对职业生涯的考虑也是很重要的。测试工程师的职业发展有多种方向可供选择，根据个人的兴趣和特点，以测试工程师作为起步职位，可以尝试的职位也非常多。职业规划的最佳方向可能是：找到自己感兴趣的，同时又是能做得好的。小艾发现，工作也是生活的一部分，只有对感兴趣的事情，才乐意花更多的时间和精力去钻研。随着学习和工作的深入，测试其实是件既有趣又很有挑战的事情。

　　在软件开发团队，最宝贵的资源不是知识，也不是技术，而是人。团队中大多数同事都是乐于分享的人，共享和沟通的氛围对新人的入门很有好处，对于团队的长远发展和提高确实大有裨益。通过向身边同事的提问，小艾了解了许多书本和文档中无从获取的信息，开阔眼界的同时，技术也明显提高了。小艾发现，这里从来不缺能回答问题的人，只要爱动脑筋，多提问题，总有意外的惊喜和收获。

　　（未完待续）

相关链接：

一个软件测试工程师的成长日记（连载一）

一个软件测试工程师的成长日记（连载二）

一个软件测试工程师的成长日记（连载三）

posted @ 2013-05-10 09:43 顺其自然EVO 阅读(251) | 评论 (0) | 编辑 收藏