具备什么样性格、素质或非技术方面能力的人，适合做软件测试工作？

　　在我看来一个软件测试人员需要具备多方面的特质：

　　● 细心：这个不用多解释了吧。粗枝大叶的人是没法做好软件测试的。

　　● 耐心：软件测试，特别是当前国内主流的手动黑盒功能测试。基本上软件测试的工作就是一项重复劳动，需要有一定的耐心来保证不在枯燥的重复劳动中放过那些细小的缺陷。

　　● 好奇心：软件测试，是需要保持一颗好奇心的工作。好奇心使得测试人员会多问一个「为什么」，「如果这样，行不行？」。往往这些问题会引导你找到缺陷。

　　● 会沟通：软件测试人员需要与客户，开发，产品等方方面面保持密切的关系，沟通很重要。良好的沟通过程可以有效地控制成本。

　　● 总结归纳能力：这跟「会沟通」有关联，软件测试人员需要找到缺陷的真正关键步骤，归纳出缺陷产生的一般规律，总结出一份详尽的测试报告。

　　● 理解能力：对需求的准确理解，是软件测试人员需要具备的必需条件。

　　● 表达能力：编写的测试用例什么的只有你自己能读懂可不行。

　　● 时间观念：软件测试工作是无止境的，但是软件本身是有交付日期的。软件测试工作需要在保证交付日期之前完成工作，保证软件产出的质量。时间与质量本身需要有一个平衡，为了追求零缺陷而罔顾交付日期的做法是不科学的。前期的制定计划开始，就要对整个过程有一个良好的规划并且按照这个计划的日期来推进。

　　好吧，以上这些差不多是我想到的对与软件测试人员来说比较重要的特质。当然，还有一些不一定是普适的要求，比如英语听说读写的能力。也欢迎补充看看我还遗漏了那些特质。

　　朱杉：

　　其实抽屉同学已经都总结得很好了，我就再说两点我自己的体会就好。

　　● 责任感：责任感是个系数，责任感与个人资质的乘积才是最终体现到工作中的实际能力。尤其是就目前国内的黑盒手工测试来说，极少有需要特别牛x的人才能干得下来的事情，大家的工作成果差异，常常是态度问题而非能力问题。而很多面试中体现出良好资质的人，放到工作中会发现实际效果不理想，也多与此有关。

　　● 原则性：测试需要一颗有原则的正直的心，不会为了凑数量，将同类问题的变体重复提交；不会因为dev简单的一句：”这不是问题“而妥协。

　　● 学习能力：测试需要不断接触新功能、新理论、新技术、新工具，并非一个省心的活儿。对于学习能力还是有一定的要求的。除了工作相关的以外，开阔的知识面，对于测试人员来说有时也意味着思路的可延展性。

　　就这些啦。其实有些能力是可以在做的过程中培养的，而做测试的过程也是对心性的一种历练。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　其实，工作这么久了，但是一直感觉，有个约束套在自己的身上，当自己是个小TestEngineer的时候，想的是如何做TestLead，当梦想成真了，想的就是Manager了，再之后，在管理岗位上换来换去，其实，对manager的需求，已经不那么在乎，更在乎的是钱了，希望工资越高越好。然后当工资基本还算满意的时候，发现，再想突破自己，越来越难了。

　　怎么突破呢，仔细想很久，后来看了写人力资源的文章才略有所悟。他们将职业瓶颈细分了：“一是职位的上升瓶颈，这是我们最常见的理解；二是薪资的上升瓶颈；三是能力和素质的提高瓶颈。”然后发现，其实，这是个瓶颈三角形，你需要完全平衡的突破三角形三个边的长度，才能增大这个三角行的面积。如果仅仅是某一条边或者两条边的突破，就会有风险的存在，很不稳健，换个环境很可能就导致你的下滑。

　　因为基本情况下，职位和薪水是基本上由别人由公司或者有整个社会环境调控的，这方面，我们不太好直接的改变，而“能力”这条边，却可以自己主管能动的改变。所以最好的方式是通过提升自己的能力，突破能力瓶颈，再来突破另外两个瓶颈。具体怎么突破能力瓶颈呢？能力我觉得包括两方面：

　　1、知识本身（理论上的知识）

　　2、实践而产生的经验和技巧（这个是建立在理论知识之上的，这也是为什么好多公司招聘要求有几年某方面经验的原因）。

　　所以，我们的提升也是从这两方面，首先，自学理论，比如学习Oracle，Linux，比如去考OCA，RHCE认证。比如QTP，LR，自动化测试的能力等等。再之后，再去找能够锻炼这方面能力的机会，本公司没有，就换公司呗。为了未来打基础么。因为已经有了理论基础，很多公司还是会考虑接受的。

　　其实，说到换工作，这个过程还是有痛苦的，因为，大部分人不勇于舍弃现在已有的，追寻自己想要的。因为舍弃，是痛苦的，因为曾经强烈的拥有着。

　　回过头来在想一想，其实，我们陷入这个瓶颈之中的人也是可悲的，因为，我们追求的不是幸福本身，而是幸福的外显，是money，是position，是capability，是fame，是别人眼中的幸福，而不是自我的enjoy，不是对技术的热爱，不是生命本身带给我们带来的感动。

本文转载自51Testing软件测试招聘网，查看更多：http://hr.51testing.com/

　　写这篇博客的起因是小晕有点天真提问说：你能不能告诉我或者帮助我找一些关于软件测试行业的最新动态啊，比如新技术啊，新观念啊，新的统计数据什么的，想多了解一下，虽然测试一般都是比较落后于其他技术的，可是百度上搜的都不怎么新了。

　　作为软件测试爱好者回答一下。

　　首先，对原提问者的一个观点表达一下不同意见，那就是所谓的“软件测试没有什么新的技术和动态，而且落后于其他技术”。这个不对，软件测试是作为软件工程中密不可分的一部分存在的，随着软件自身、软件研发技术的演变，测试技术也在不断演变。所以测试技术有许多新的技术和动态。说测试技术落后于其他技术，武断了，无论是测试的方法、工具、理念都已经有几十年的积累，而且在不断演进，测试技术的竞争已经成为各大开发平台竞争的主战场，新的东西正在层出不穷。

　　至于为什么大家在互联网上看不到太多新闻，个人感觉测试是作为工程手段存在的，是专业技术，不像手机、电脑的技术参数那样有很高的认知度，所以流传范围不大。如果新浪科技频道发长文“论空心砖比实心砖的优越性”，我估计也没几个人看。不过，这些信息在圈子里是在快速的流动的。

　　测试的最新动态：

　　● 从测试技术上来说，“自动化测试技术”和“探索性测试技术”是最近大家都在热烈关注的内容。大家讨论这些的背景是：如何通过技术手段减少重复劳动，使宝贵的测试资源可以做更有价值的事情；如何发挥测试人员的测试特长与创造性，而不是仅仅按照写好的测试脚本和测试用例来点鼠标。

　　当然，不论技术如何沿革，当今主流的测试还是依据严谨的文档、设计、计划执行的，因为，测试毕竟是一种工程手段。

　　● 测试是和开发活动伴生的，所以开发模式的新动态对于测试也有影响，最近的一段时间里，大家都在试图回答一个问题：在敏捷开发模式下，测试应该如何做？是重新交回开发人员自己做？完全依赖自动化测试？独立测试工程师在敏捷团队中做什么？需要哪些测试工具？我们真的需要在凌晨2：00把二十个bug提醒发送到刚刚入睡的开发工程师正在充电的小米手机上吗？

　　● 测试活动与测试的对象——软件，密不可分。不同类型的软件，测试方法、技术都不同。所以软件业的新动向也对测试有影响，在“移动互联网”，”前端技术”和“云计算”持续火爆的当下，测试也面临新挑战，如何在安卓平台碎片化的情况下进行软件兼容性测试？如何为云计算应用进行测试？如何测试网站前端？另外，为什么苹果的软件使用起来总是那么顺手，测试做了什么？都是很有趣的话题，对这些话题的讨论和研究也在不断产生新的技术和方法。

　　当然还有一些从外部很难了解细节的测试，例如，安全性测试，大数据量测试，大并发测试，这些都和软件的应用场景有关，就不一一列举细节了，总体上来说，这些测试的目的都是为了保证你在上班期间，可以安全、舒适的刷淘宝。

　　● 测试工具上来说，最近大家讨论的，一是Selenium，这是一个Thoughworks公司推出的开源Web应用自动化测试工具，Selenium原意是一种用于治疗汞（Mercury）中毒的化学元素，而Mercury是一家被HP公司收购的商业测试工具开发商，在测试界享有盛誉，所以…你懂的；二是持续集成工具，比如CruiseControl，Hudson，JIRA Bamboo（竹子的外形和持续集成很像，是吧？），还有一些公司在自主研发的平台，比如淘宝的Toast。测试工具很多，商业的，开源的，为了防止广告嫌疑，就不多提了。关于工具的用途，个人有个见解：工具是用来解决问题的，工具为人服务，而不是人做工具的奴隶，不要为了工具而工具；是好的测试理念、管理、能力守护软件质量，而不是工具。

　　无论测试的新技术如何讨论、沿革，测试还是不离其本来的源头：守护软件质量的重要手段之一，所以，不论做测试、学习测试，理解软件质量都是第一步。另外，测试始终都是一种带有创新性、探索性、社会性的技术工作，是一种严肃严谨的工程工作，无论软件产品从外部看起来如何绚丽，背后都有大量的测试工程师在辛苦勤恳的工作（可能越绚丽的软件，其测试越严苛，比如游戏）。

　　另外，你提到的从百度无法搜索到更多的技术结果，我想这不是搜索引擎的问题，而是你使用的问题。我觉得你可以从关注几位测试圈子里的人的博客和微博开始，从关注测试论坛开始，多了解一些测试有关的专业术语，然后再有针对性的去搜索，一定会有更多收获。

　　最后再废话一句：大部分的技术信息，99%的难题的答案，都在官方文档里。如果要学习，读文档吧。

　　时间所限，就回答到这里，你提问的关于统计数据，真的不在统计局工作，所以没有什么数据。这个只是我个人的问题，别的测试爱好者有他们的回答，欢迎一起讨论。希望我的这篇博客对你有帮助！

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　导言：本专题通过对Web测试的梳理，从对Web测试的扫盲到对Web测试有深层次的理解，希望对Web测试工作者有所帮助。

　　【扫盲区】

　　作为测试新手，web测试从何开始学起？

　　首先我想说一下，不要认为自己是个新手，而轻视自己，其实大家都是从新手阶段过来的，很多人可能刚起步的时候还不如你，所以要坚持自己的选择，一直走下去，才能在这个行业里有所发展。

　　那么我们回到主题，web测试从何开始学起？

　　我们先来弄清楚web测试的测试范围，通常web测试包含：功能测试、性能测试、浏览器兼容测试、安全测试以及用户界面测试等。那么，作为一个初级测试员或者实习测试员，最开始的能做的只能是功能测试和用户界面测试，另外可能还有浏览器兼容性测试。

　　先说功能测试，因为web测试的对象有网站和web应用系统两种；前者主要是静态网页，后者包括网站发布系统、后台管理系统和web应用系统等动态交互性网页。

　　静态网页主要包括的测试对象有：链接的跳转和新窗口打开、表单测试（功能和输入判断）、Cookies测试等，测试起来难度没有多少，建议先了解这些相关的知识，站住脚再来逐步深入。

　　动态网页需要测试的东西就比较多了，因为动态网页有很多交互功能，那么就会有需求设计的内容，也就是有业务的存在了，不同的业务系统需求肯定不同，所以刚开始做测试工作，最先做的是了解当前系统的业务需求，并根据业务需求设计测试用例来进行测试。至于如何设计了解当前的业务需求，如何设计测试用例，你可以在论坛的相应版块搜索学习。

　　......

　　如何进行“网站易用性测试”

　　对于网站易用性测试，可通过如下步骤进行：

　　第一步：前期准备，搭建测试环境。

　　测试环境的搭建包括：一间办公室（会议室），一台电脑（要连接网络），一个屏幕录制软件，一台摄像机（可录制测试者操作行为，也可同时通过视频线将信号传到另外的办公室，以便项目小组的每个人都能进行观察而不会干扰测试用户）。

　　第二步：招募测试对象，找到典型用户。

　　可通过公开招募进行（建议派发一些小礼品或酬劳），之后对报名者进行筛选和面试，最终确定你的典型目标用户。测试可分为多轮，每一轮3-5位用户参与测试即可。

　　第三步：设定任务（目标），观察（录制）其操作轨迹。

　　为测试用户设定任务之前，首先要明确你网站的主要目的。

　　如果是普通企业官网，网站的目的很明确，就是向用户有效传递产品（服务）信息，任务的设定就可以是：让测试用户找到xx产品；

　　如果是电商类网站，网站的目的除了要有效展示产品信息外，还应具备简单、便捷的购物流程体验。任务则可以设定为：让测试用户找到xx产品（制定产品名称或产品属性），并完成购物。

　　其他类型的网站就不一一列举了。为测试用户设定了有针对性的任务后，测试人员就要提起注意力，细心观察用户的每一步操作行为，并及进行详细记录。同时要务必保证“屏幕录制软件”的有效运行，这是后期项目小组进行综合分析的有效参考。

　　Web测试规范

　　任何一个测试的开始都要制定一个完整的测试计划，现在我们就从web安全测试的测试计划开始

　　要做一个测试计划首先要明确测试需求。在写测试计划之前必须要明确测试需求，

　　暗含的要求：例如很少看到这样明确话的文档要求：“入侵这相应手册中不许友拼写错误”但同时有些组织是允许拼写错误存在的。这样暗含的要求我们就要明确，可以通过和主管部门或是用户沟通来明确这样的要求。

　　专题入口：http://www.51testing.com/zhuanti/webtest.html

　　【技术与应用区】

　　性能测试之Web篇

　　随着网络世界的迅猛发展，网站的性能变得日益重要，性能不好的网站将被用户所抛弃。所以性能是用户对软件系统是否满意的一个重要方面。本文将对什么是性能，如何测试性能等方面进行论述。

　　WEB测试兼容性

　　软件兼容性测试在目前软件测试领域占有很只要的地位，无论B/S架构还是C/S架构的软件都需要进行兼容性测试，充分保证产品的平台无关性，使用户群充分的感受到软件的友好。

　　web测试的经典总结

　　基于Web的系统测试在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。

　　Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

　　专题入口：http://www.51testing.com/zhuanti/webtest.html

　　本文中考虑的软件测试过程专指第三方的软件测试过程，即在测试的过程中，不涉及开发人员的修复过程。

　　度量和分析的目的是开发和维持一个用于支持项目信息需要的度量能力。通过对项目的度量，一方面可以逐渐丰富和完善公司的度量财富库，从而为项目经理进行项目工作量、进度等的预估时提供可靠的参考依据；另一方面，通过度量分析，项目经理可以有效的对项目情况进行监控，当度量分析报告中提供的结果超过了一定的阈值时，项目经理就应该采取相应的措施，也就是说度量分析有利于项目经理做出正确的管理和技术决策以及采取适当的纠正活动。

　　从软件生存周期模型中来看，人们常常直观的认为软件测试仅仅是软件生存周期中软件编码完成之后的一个或几个阶段。而实际上，软件测试本身也是一个过程，它可以进一步具体的分成若干个阶段性活动，如：测试计划、测试设计、测试执行、测试总结。对测试过程的度量必须涉及到测试过程中的各个阶段的度量，包括规模、工作量、进度、缺陷等等。下面着重介绍下测试设计和测试执行阶段与效率和质量相关的度量。

　　（1）测试设计

　　软件测试设计阶段主要工作是测试用例的设计与开发，在这个阶段可度量项包括：

　　● 用例生产率

　　用例生产率 = 测试用例个数（个数）/ 设计用例的时间（小时）。

　　在项目组中度量时，既可以得到每个项目组成员的用例生产率，从而来衡量其生产率；也可以得到项目组的用例生产率，与公司的度量财富库中的用例生产率进行比较，可得到自己项目组的整体水平。

　　● 用例质量

　　在用例写完进入测试执行阶段之前或是写用例的过程中，都会有对用例进行评审的过程，用例质量可以通过评审中发现的问题来评价。用例质量 = 评审问题个数 / 用例个数。

　　（2）测试执行

　　软件测试执行阶段，是在准备好的测试环境上依次执行各测试用例并详细记录每一步测试结果，提交缺陷记录的过程。在这个阶段可度量项包括：

　　● 用例执行率

　　用例执行率 = 执行的用例个数 / 执行测试的时间。通过这个派生度量即可以得到项目组每个成员的用例执行率，同样也可以得到项目组的平均用例执行率。

　　● 用例有效率

　　用例有效性 = 发现的缺陷个数 / 用例个数。用例有效性的可比性在项目之间不是很大，因为各个软件项目质量的好坏会直接影响到用例的有效性，若项目质量较好，则同样的用例个数发现的缺陷较少，若项目质量较差，则同样的用例个数发现的缺陷较多，但若在同一个项目中进行比较，还是有一定的可比性可言的。

　　● 缺陷发现率

　　缺陷发现率 = 缺陷个数 / 执行测试的时间。前面提到用例执行率可以看出项目组成员的工作效率，但并不能保证其质量，通过项目组成员各自发现的缺陷个数除以各自所花的时间，通过缺陷发现率这个指标来关注项目组成员的工作质量。

　　● 缺陷等级分布

　　对项目组发现的缺陷，按缺陷等级进行分类统计，得到系统的各个等级的缺陷分布情况。

　　● 模块缺陷率

　　模块缺陷率 = 该模块发现的缺陷个数 / 该模块的用例个数。这样可以得到它与其他模块的横向比较。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　1、对软件测试的要求太高了

　　在国内培训的时候经常遇到的一个说法：“（比如软件测试自动化，工具，流程）的确好处很多，但是它对软件测试的要求太高了”。刚开始的时候我很惊讶，第一次听到对软件测试要求太高的说法，后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后N年的话，我觉得“对测试的要求太高了“的观念就是导致这个落后的根本原因。我一直在观察和对比国内外测试的区别，当然有技术上的，工具上的，流程上的区别等等，但是这些差别都只是表象，根本的差别是观念上的差别，也就是测试在研发中的真正角色。这个不是找到多少个bug的问题，也不是采用什么测试方法的问题，而是是否把测试做为支撑研发两条腿中的一条腿的问题。测试是一个专门的职业，和开发一样有不同级别。初级人员解决简单的事情，高级人员必须负责解决复杂，高难度的事情。这样才能形成一个完善的测试人员职业发展体系。很多测试经理一直很困惑说我们也在加大在测试上的投资，参加很多技术、流程、管理培训，但是效果都不好。原因就是我们不能总是希望通过学习一个技术，或一个工具来解决观念上的问题，当然没有效果。也容易跟风，刚学会手工测试，又要测试自动化了；刚学会测试自动化；又要ET了。刚学会ET，又要敏捷了。没有观念就没有主见。所以改变观念才是提高软件质量的根本途径。

　　那么如何改变观念呢？我也不知道。公司老板不愿改变呢？我也没有办法。但是重要的是你知道问题所在了，这就是解决了最大的难题。如果自己都觉得测试没有难度，没有前途或者对测试要求太高了的话，如何指望得了别人？所以我们搞测试的人的一个重要职责就是：把这个观念灌输给其他人，把测试的门槛提高，对测试的要求没用很高只有更高，其它问题也都解决了。

　　2、Dev不愿意修改bug

　　这是一个很多测试抱怨的问题：自己辛辛苦苦找到一个bug，开发却认为不是bug。或者更？？？令人气愤的是开发在没有沟通之前直接resolved as “by design” or “not repro”。这个情况通常在质量控制成熟度级别（1级或2级）较低的组出现较多。根本上解决的办法是提高整个组的成熟度级别，当然需要在很多方面加以提高，这个问题就随之而去了。可以使用以下几个策略：

　　首先这里牵涉到两个问题：一个是resolve as “not repro”的问题。很多时候dev resolve as ‘not repro’是因为bug本身不清楚没有足够的信息来判断或进一步investigate（当然他应该和你确认一下先）。所以测试在报bug是一定要记录足够信息。基本原则是当别人在看该bug是否有足够的信息来判断该bug是怎么回事或进一步investigate。我总结过一个好的bug描述应该是Concise，Accurate， Searchable， Entirety， 也就是 CASE 原则。可能你会觉得这需要太多的时间才能报一个bug了。的确是，但是总比你花了两天找到一个bug，花了10秒钟就把bug写完了，结果过两天dev resolve 成not repro强吧。另外就是自动报bug的工具，还有就是创建bug模板等都可以减少报bug的时间。

　　其次是’by design’的问题。很多时候测试不服气认为就是bug，但是开发不同意修改。我想借用一句话来说明我的观点：a good idea is not really  good  until it is accepted. 也就是说如果你不可以说服别人接受你的主意，再好的主意也没有用。同样的道理你认为的bug，如果不能说服别人，它也不是一个bug。或者bug只有在被修复时才是真正的bug。如果dev/test有分歧的话，通常PM负责一个功能，应该有PM做最后决定；如果没有PM的话，通常有整个team来决定。当然如果你非常肯定，可以继续找更多的理由来支持你的观点。但是最终如果还是不能说服别人的话，还是要服从team的决定，虽然我们常说真理往往掌握在少数人的手里，但是绝大多数时候都是少数人考虑不周。另外一点就是我们通常很少在是不是bug上有分歧，而是在什么时候修复上有分歧。这是另外一个话题了，需要考虑很多其它非技术因素了。

　　3、如何做到自动报bug，并把相关的信息放到bug里面

　　我在comments里已经回答过了，就把它拷贝一下吧以是完整：我前面提到微软有很多工具来提高测试人员的工作效率，也就是说把时间花在需要专注的地方而不是在其他繁琐的地方浪费时间。其中一个好的实践就是自动报bug。其实整个过程比较直接：首先用来管理bug的工具应该会有API接口，所以可以使用工具来自动报bug。其次是添加分析处理工具，测试的出错信息比较容易获取，比如测试用例出错了，或者抛异常或者返回错误结果，可以容易地把异常信息或错误信息放到bug里面；分析产品的日志找到错误点有写难度，需要和dev共同努力把测试日志和产品日志通过某些属性（时间戳或操作id）关联起来。或者简单地把相关日志、windows event log，等拷贝到network share，在bug中指向该路径即可。还有对于UI测试，如果测试错误，一定要把当时的屏幕截图抓下来放到bug中去。还是那句话，专注于应该要专注的地方而不是把时间浪费在其它步骤上了，测试用例出错，不应该花太多时间去报bug （最多2分钟）。同样道理有了bug后dev可以直接去investigate，而不是花时间去找日志在那里？那里出错了？等等。有条件的产品组还可以进一步提高，比如工具自动报bug的时候可以到到数据库里根据异常或错误信息查找一遍看一看以前有没有类似的bug，或者做BI，这些信息对于将来的分析和决策非常有帮助，而且也可以帮助预防bug。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　最近公司在搞大规模弄自动化测试，所以今天想来谈谈测试自动化这个问题，当然我说的“测试自动化”跟“自动化测试”是不同概念，一样的字，不同的顺序。

　　所谓的“自动化测试”，一般是说用一些工具来帮助测试，比如LoadRunner可以帮忙测试负载，QTP可以帮忙做功能测试，当然很多公司还自己写一些脚本做单元测试。这些工具的帮忙，可以极大地提高公司的测试效率，从而可以解放很多资源去做更加复杂、高级的测试。（所以“自动化测试”只是一个工具或者技术）

　　而所谓的“测试自动化”，主要是说我们的测试流程，应该怎样来充分地结合各种工具/系统（测试管理工具、自动化测试工具等等工具/系统），使得这个测试流程更加合理、更加高效。前面说的LoadRunner这类“自动化测试”工具对于“测试自动化”而言只是一个帮助因素。（所以“测试自动化”是一个方向，一个理论，一门科学研究）

　　在像LoadRunner这类工具出现之前，其实我们对于“测试自动化”的理论早已存在，出现的原因是由于软件发展速度太快，带来了越来越多光靠人力难解决的问题，比如：

　　1、性能问题：很多软件都是很多人一起使用的，比如股票系统，可能会几百万、几千万人在用，但是股票系统开发公司不可能用人力来模拟这么多人一起使用

　　2、功能问题：软件功能和逻辑是越来越多、越来越复杂，但是有不少旧的逻辑其实一直没怎么变，比如新建项目，备份项目等操作，但是这些虽然不变化，但是在每个Release时，总是需要测试的，这样子，就需要人力和时间了

　　3、变更问题：很多功能虽然表面上看起来样子没啥变化，但是其实内在逻辑什么都可能在不断变化，优化算法啊，修Bug，都可能带来改变，怎么去保证能Catch到每次改变呢？这个是问题。

　　4、……

　　就这样子，大家为了解决这种问题，推出了各种各样的工具，而且也解决地很不错，不过其实很多公司还是继续存在着问题，什么原因呢？过度地认为工具能帮忙解决一切，整天叫嚣着工具代替人，而忽视了一个重要因素：人的思维。

　　我们知道工具虽然很厉害，但是思维绝对无法超过人，工具里面的逻辑都是人编进去的，而人的思维确实无限的，如果工具真的解决一切，为啥这些工具还不断经常推出新版本，不正是说明还有很多事情工具做不到，需要人来帮忙去让它们实现吗？

　　所以在“测试自动化”的理论体系中，人总是在“训练”工具，而不是在“使用”工具。

　　在测试自动化现有理论体系中，主要由以下几部分组成：

　　1、人

　　2、自动化测试工具（LoadRunner，QTP，Selenium，Test Complete……）

　　3、测试管理工具 （DevTest， TestDirector ……）

　　关于“人”，我最后介绍了，先把2和3介绍一下，2其实已经介绍过了，对于3而言，虽然表面上可能没2厉害，但是其实起得作用可能比2还大，因为自动化测试工具只能测试产品的一个部分，而怎样能保证整个产品的所有部分都能被测好呢，这个就需要用到测试管理工具，比如TechExcel的DevTest，它的测试用例可以绑定自动化测试工具，而所有的测试用例就代表了一个完整的产品了，当这些测试用例去触发绑定的自动化测试工具运行后返回结果以后，相当于这个产品全部测完了。

　　而最重要的“人”的作用呢？其实我不说，大家应该都能想出很多作用来，接下来我来总结一下：

　　1、维护产品的完整性：需要根据功能的变化，Bug的发现、自动化测试工具的局限性，经常地更新测试用例、测试脚本。这个是最基本的。

　　2、发挥人的能动性、发散性：自动化工具永远无法把一个产品测好，所以作为人而言，不要以为懂了自动化测试工具而骄傲，也不用因为只懂手工测试而感到沮丧，关键是要了解测试的内涵，从而就能了解产品的内涵，最后让产品在你的脑海中能融会贯通，这样子，你自己的脑袋就是无敌的自动化测试工具了。

　　3、吸收+创新+创造：相信我，即使一个完美的产品的测试，如果真正意义上说完成了是永远无法做到的，更何况普通产品了。所以这也就意味着这里面会有大量的地方可以得到加强，吸收以往经验，发掘与加强遗漏点，追寻潜在点，创造新方法，都是一个“人”都能做到的，当然你需要大量地去思考、去探索。

　　4、更新体系：我们说“测试自动化”是一个方向，是一个理论，是一个科学研究，这个就意味着它可以不断进步，至于进步到什么程度，我也无法想象，有可能会出现类似自动分析产品逻辑从而得到测试用例与脚本这样子，不过唯一能知道的是，人还是会占主导地位，无论更新到什么样子，人会一直带领着这个系统前进！

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　随着软件测试在软件开发周期中越来越受到重视，国内软件测试的缺口一直比较大，各种软件和互联网公司都大肆招收测试工程师，有些走在前面的公司甚至从今年开始取消了测试工程师职位，全部变成了软件测试开发职位，比如百度。一方面测试开发表明了对工程师有更高的要求，需要在具有测试能力的基础上兼备开发能力；另一方面自动化软件测试成为趋势，利用开发的技巧解决测试中的问题以提高测试效率，降低QA与RD的人力比。

　　1、技术含量

　　面试过许多的应届毕业生，问及为什么选择测试开发这个职位时，经常听到以下的回答：

　　“我觉得自己开发能力比较弱，但我比较细心，觉得测试职位比较适合。”

　　“我在实验室和实习公司呆过，做过功能测试和性能测试，我比较喜欢测试.”

　　“开发只能了解到项目的局部，但测试需要了解更多，我期望有更好的大局观”

　　无论人们内心真实的想法是什么，但潜意识里面测试的技术含量没有开发高。在校园招聘的时候，我们会将部分倒在开发职位终面的人重新拿到测试开发面试。客观地说，在软件编码方面测试开发的技术含量确实不如纯正的开发职位，更不用说测试职位了。但是，我想说的是这个职位本身所要求的技术水平应该是需要超过单纯的开发职位的，真正高水平的QA至少需要多年的开发经验的，否则他无法从软件产品设计、架构和实现方面提出实质性的意见和风险评估，充其量只是点出交付到手软件中的几个bug。所以基于现阶段国内行情，个人建议如果希望在测试的职业生涯上有所发展的人，先参与几年的研发工作，毕竟那才是软件工程中的主体，然后在开发过程中培养测试意识，这也是程序员的职业素养。Google许多工程师都有强烈的质量意识，许多代码自己不经过自己的单元测试和功能测试是没有人review的。对于投测试或者测试开发职位的目的是为了逃避开发，那么职业道路要发展顺利是很难的。

　　2、基本素质

　　测试开发工程在公司一般有两种，一种是单纯为测试团队开发测试工具或者系统（由于这部分和单纯开发职位本质上区别不大，讨论基于另一种）；另一种就是在测试过程中发挥主观能动，利用自动化把重复劳动降至最低，比如开发适用于特定场景的测试工具（当然这种工具具有普遍性也能推广到整个组或者公司）、测试脚本和测试用例。

　　测试开发工程师应该具备两方面的知识：测试知识和开发知识。之所以把测试排在前面，因为这里的开发建立在测试实践基础之上。其中测试知识又分为两部分：一是理论知识，软件行业发展至今也就几十年，测试方面的积淀就更少了，所以要掌握这部分对于一般人来说不是难事；另外一方面是经验知识，主要在项目测试过程中积累，很多系统的测试点、风险点都需要有丰富的经验来评估，这也是资深的测试工程师价值所在。开发知识当然和开发工程师差不多了，不再多说。在软素质方面，测试开发工程师应该具有更好的组织沟通协作能力。现在许多公司都在推行全流程保证，QA为了发挥更大的影响力以及保证项目的质量，需要从需求到设计，测试到上线全方面跟踪参与，这就涉及到了许多跨部门跨小组的沟通，即便在小组内沟通也极其频繁，工程师需要很好的表达能力。同时，由于测试在软件生命周期中处于靠后的位置，所以在将许多工作推行到上游的环节中存在较多阻力，这也要求工程师有较好的统筹和协作能力，最终达到目的。

　　3、走得更远

　　不可否认，现在许多测试理论，无论白盒测试还是黑盒测试，无论单元测试、集成测试还是系统测试，看似属于测试人员研究的专利，实际上大部分的方法论都是开发人员提出来的。再一次证明，不参与软件主体的研发工作是不可能深入理解测试的，所以开发人员需要具备的开发能力和技巧测试人员也是需要具备的。当然由于项目的安排和时间等各方面的原因，测试人员能难有较多的开发机会，但这不妨碍你不断地学习。我们大组内就有一个多年深入研究的python的QA，一直以此为兴趣，许多开发小组用到python开发系统的时候都会叫他过去培训，他不仅是质量部的资深测试工程师，还亲自开发了多款实用的测试自动化工具。另外，测试可以涵盖的方面很多，但人的精力毕竟有限，测试开发工程师也必须拥有自己的核心竞争力，选定一个方向是个不错的做法，致力成为某方面的专家，比如单元测试（不要认为是开发人员做的，很多开发人员没有单测意识和技巧）、性能测试、安全测试。组里面也有一个对性能测试研究了6年的人，从职业开始发展一直比较顺利，并且发展势头不错。最后是测试开发工程师需要培养自己的大局观，这个是在职业过程中有意培养的，公司现阶段的任务是什么？侧重点是什么？在大公司需要顺势而为，QA的本职工作是保证质量，需要借助与流程、工具和其他外部资源，所以在工作的时候尽量与大方向契合。比如公司去年是QA内部水平提高的一年，需要QA具备单元测试、Code Review方面的能力，今年是保证质量的前提下，提高软件发布周期，主推持续集成。

　　4、测试的本质

　　2V（Validation和Verification）是QA的基本职责，即保证两点：Validation，软件按照既定的需求开发，没有偏离产品方向；Verification，软件在满足需求的基础上保证其正确性，从功能、性能、安全等各个方面验证。传统意义上，第二点是大部分QA的意识，即找bug，认为一个软件找到的bug越多自己的价值越大，实际上QA的最高境界是软件在测试的时候找不到bug，因为在软件的启动阶段你就开始了质量保证工作，从需求、设计、编码这些前期阶段就杜绝了bug产生的可能。当然，以上说的有些理想，但本质是什么？软件背后是人，是PM制定的需求，是RD进行开发的， 那测试背后实际上测的是人而不是软件。人总是可能存在思维漏洞的，人总是可能犯错误的，所以永远会有bug，但有些人心细，有些人负责，自己开发完后会自己进行单测、功能测试，以致后续能发现他的bug已经很少了。明白了这一层就不要单纯从技术角度来思考测试。

　　最后想说的是，无论在大公司还是小公司，大家都有压力，都要发展，心态就很重要了，以创业者而不是打工者的心态来工作看待很多问题就截然不同了。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　这几天看了一些关于软件工程里面软件测试方面的书籍，感觉蛮有收获，试与诸君共分享之。

　　软件测试，对我这个才进入软件领域两年不到的菜鸟来说是一个既熟悉又陌生的词汇。每个软件行业的人不可能没听说过软件测试，但是，我相信大多数和我一样的菜鸟都没有真正对自己写的软件程序做过系统的软件测试工作。

　　说到这里，有很多同学都不乐意了。我怎么没测试了？！！我都是写一段代码就run一下，保证一段代码成功了才写后面的好不好。而且，我写的程序都能正确运行好不好。OK，OK，先不谈这个，当年我也是这么认为的，关于这点我们首先来界定下何为软件测试再说。

　　官话：软件测试的目的是为了发现软件设计和实现过程中的疏忽说造成的错误。

　　我的理解：发现并修改软件中不好的部分。这些不好的地方指错误、低效代码、不合理或不方便的设计等等一切影响功能和最终客户反馈的地方。

　　同学们，还坚持么？

　　一个很吓人的事实是软件界存在8020法则，即大多数好的软件其测试所花费的工作量比其他所有的软件工程加起来都多，比例为80：20。从这个角度来讲，若大型系统的测试还像小游戏一样无规则、无计划的进行测试，结果可想而知...可想而知，好的测试思路与方法在正式的测试工作当中是绝对必要的了...

　　一、软件测试的战略方法与思想

　　1.1 验证与确认（Verification and Validation，V&V）

　　在大的方向，软件测试通常做两件事：验证--即保证软件的功能正确实现，和确认--确保软件合乎客户真正的需求。

　　上面的话可能让人头痛----不是一样的意思么？

　　好吧，换一种说法：验证--我们在正确的构造产品么？ 确认--我们在构造正确的产品么？

　　验证不用说，正确性是软件（其实远不止软件）最基本的要求，做计算器时你至少得保证1+1不等于3吧！！关于确认，很多编程人员都有一个误区，就是我做客户让我做的东西。但一个很重要的问题是，客户提出的需求真的与软件的实际需求一致么？撇去客户表达与需求分析之间的不一致性不谈，在人机设计与界面交互这一块我们能做的更好吧。这里借用MXR同学的成果（见图1）：当我们在做webAPP时，对同样的功能需求，不同的表现方式会达到不同的效果。这也就是说，软件测试，不仅仅是测试错误，更要对软件的可用性与适用性做出修正，即保证软件的质量。同样，测试还应该包括性能监控、可行性研究、数据库评测、算法分析等等一切影响软件质量的属性。

　　图 1

　　1.2 软件测试的组织

　　V&V实现解决了测试是干什么这个基本问题，现在要解决另一个基本问题：谁来做测试工作？

　　很多人会有这样的思想，对同样的东西（这里是指待测试的软件模型），不同的人在认识上肯定会有差异。那么，软件开发人员对软件进行测试是一个很好的选择，谁能比开发者本人更了解程序呢！！！这也是为什么别人列出一长串代码让你找出某个错误时，你不耐烦的原因。

　　然而，一个显而易见的事实是，开发人员本身总是急于展现他们所开发的程序的正确性，是成功的，是符合期望的，这是人之常情。令人遗憾的是，错误时客观存在的。笔者也经常在向别人展示自己花了很大心思做成的程序时，试图掩饰莫名出现的错误。有人说过，从心理学方面来看，软件的分析和设计都是一类建设性的工作。从本文后面可以看到，软件人员总是努力构造测试实例来“破坏”软件。软件工程师也会自豪与自己的“孩子”，这种仇视任何一个企图伤害自己“孩子”的人这种心理是可以理解的。

　　那么是否可以得出结论：开发工作与测试工作应该分离开来？答案是否定的。虽然独立测试组（Independent Test Group，ITG）在所有大公司都是存在的，但开发人员与测试人员在软件开发初期就应该进行交流。一个原因前面已经说了，你能忍受从头看别人给你的100000+行代码，然后找出某个似乎存在的错误么？笔者在前一段时间试图分析hadoop的源代码，不到两天脑袋就歇菜了。另一个可能的原因是，测试并不仅仅是“大家一起来找茬”，而是一个自我修正的过程，完全需要开发人员一起来参与。

　　从这个意义上来讲，ITG是软件开发项目组的一部分。

　　......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/01/n-810301.html

　　我没系统的学习过软件测试相关的技术，从事软件测试岗位已经有3年的时间了。之前从事过2年的软件开发，所以在这里仅仅表述下这3年在软件测试工作中遇到的一些问题和想法。

　　1、Testcase设计的源头

　　这是个基本问题，偏离了主题的软件测试无论如何进行，结果都是错误的。软件测试工作中测试的testcase必须是从用户的使用角度和需求出发来设计，千万不能根据代码或者开发过程中的概要设计和详细设计来做testcase的设计。否则在细致的testcase都不能得出一个正确的结果。

　　刚毕业的几年里我在**大型软件公司做开发工作，这是一家比较注重开发而轻测试的公司，所以大部分开发人员即承担着开发工作也承担着测试工作。

　　中国有句古话“自刀削不了自刀把”，在软件测试上也同样可以应用。当时的testcase都是我一个人设计，然后测试。就是自己写代码自己测试，所以testcase的设计都是按照代码，概要设计，详细设计来写，因此测试的过程中当然会发现不到问题。如果是按照代码来设计testcase基本是发现不了任何问题，如果是安装详细设计和概要设计来写testcase，就发现不到需求上的错误，而且往往概要设计和详细设计在不同人的眼里也许理解也不一样，写出来的功能也可能会千差万别。

　　所以testcase的设计一定要脱离开发，脱离实践。就按照用户的日常的使用和对用户软件的需求来做。这就要求QA一定要参加到前期的用户需求调研工作当中去。

　　在一次客户交流的活动中听到客户如下的抱怨：“购买我们的产品就是因为我们产品设计特征符合他的需要，然而在我们的一次升级中却改变了这个特征。让他很不爽”。

　　测试人员是软件交付的最后一道关口，正是因为没有真正了解到客户的需求，导致了整体软件的更新偏离了用户的需求，把用户关心的东西抹去。

　　其实能抱怨的客户都是好客户，我们要长期与客户沟通，了解其真正的需求，从而去设计产品，测试产品，这样生产出的产品才有其存在的价值。因此我们不是要做全球最优秀的产品，也不是要做出没有bug的产品，只需要做出让客户满意的产品就好。而客户满意的产品，就是Testcase设计的目的。

　　2、测试树

　　这是我自己想到的一个词，测试的产品可以比做一棵大树，每个产品都有一个主干，分支就是这个产品的各个功能，每个功能还有它的枝叶。所以测试的过程就是沿着主干去测试各个分支以及分支的枝叶。

　　每个release发布的时候，都需要确保主干中各个分支能够运行通过，这部分当然最好是由automation来做。不过这个测试希望是由发布release之前开发人员们自己测试好，所以开发者要做好UI和IT测试。因为一旦分支功能不能正常运行，后续的测试工作是无法进行的，而且一旦运行不通过也会让测试人员感到很懊恼。所以有的书中把这个路径定义为快乐路径，这个路径没走通，当然也不会快乐了。

　　这样由主干道枝干，在进行到枝叶，一步步的测试就可以完成了。在测试每个枝叶的过程，加入error handle的测试，就基本可以构建出一颗大树了。

　　3、不要相信开发人员的话

　　测试过程中会发现各种问题，在找到开发人员分析问题的时候，开发人员经常会说出：“这个不是问题，我们就是这样设计的、我们不能调用到**的函数，所以只能这么做、这个问题解决不了。等……“身为开发者，往往都会对自己的代码有着充分的信心和自信。也许他们做的是对的，但是设计出了问题，他们看不到。也许是他们没有找到一种更好的解决方案。

　　在软件细节的领域上测试人员不如开发人员掌握的详细，所以初级测试者往往会被开发人员”忽悠“。接受了开发人员的思想。所以导致很多问题的流出。

　　因此在发现问题的时候，不要管产品当前的设计如何，因为也许设计本身就是错误的。

　　不要管代码能不能做到，因为那是开发人员的事情。测试人员要做的事情就是以用的角度来使用这个产品，任何不爽的地方也许用户也和你一样不爽。

　　人都是有定向思维，很难走出自己的圈子，所以开发人员站在开发的角度上认为一些问题都不是问题。所以在测试过程中要坚持自己立场，不要轻易被开发者讲出的技术理由改变看法。

　　4、好的产品就是简单的产品

　　美国的陪审员都是普通民众，他们不需要有任何专业知识，越普通越好，所以他们才能按照人情常理来断案。

　　优秀的产品也一样，越优秀的产品，就可以让它的使用者越普通，没有任何专业知识就可以熟练的掌握和操作。

　　我最早使用的搜索引擎是搜狐，它把搜索条放在了它主页的中间。后续的其他网站也是如此，当需要搜索时，都需要打开他们的门户网站，然后找到搜索条，在进行查找。直至百度，谷歌的出现。进入主页我就可以直接进行搜索，而百度后续又做出了词条联想功能，在搜索之后，网页下还有许多联想出来的词条供用户使用，叫做”相关搜索”所以因为这个功能，我更多的时候喜欢用百度，因为我的操作变得更简单了。现在谷歌也引进了这个功能，不过在商务中有个”领先法则“，这点注定了谷歌这个功能超越不了百度了。

　　武功的最高境界是忘却，无招胜有招，测试也许也是如此，把”自己伴成用户“，”在用户的环境下“正常使用就完成测试了。这两个条件都不可缺少，第二个条件经常被人遗忘。这里举例说明下：

　　用户的环境：“软件用户人数，同时在线人数，产品所处环境气候温度，产品网络环境等”。

　　总之，明确测试目的是前提，在不偏离前提下模拟用户使用环境和方法进行针对性的测试，步步为营满足用户需要即可做好测试工作，保证软件质量。当然，天下武功唯快不破，加强自动化测试覆盖率更是提高软件产品质量的重中之重。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html