关于一位国外测试工程师的职业经历

你是如何开始做测试工作的？

1989年，我在田纳西大学读研究生的时候，完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨，我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被安排在星期六早上，很不方便。

而怍为一个生平第一次离开家的新入校的研究生，这个时间段有些麻烦。十分有意思的是，等待我的惩罚并不是一纸解聘通知书，而是被判罚为该小组的唯一一个测试人员，且不能与开发团队有任何交流。

对于我的职业生涯来说，这是一个意义多么重大的决定啊！正是这个决定最终成就了几十篇关于测试的论文，构建了多得连我自己也记不清的各种工具，出版了五本书，带来了无尽的快乐工作时间。测试一直就是我拥有的那份具有创造性和技术挑战性的快乐职业。不过，并不是所有人都喜欢这样。可以说我最早接触测试是在攻读研究生期问，不可否认，那时的高强度学习和工作确实让我受益匪浅。另外，我认为从初学者阶段到专家阶段之间存在着一个“测试的山峰”，人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的，成为职业的测试人员也并不艰难。本章的重点正是讨论如何翻越那座位于职业测试人员和测试专家之间的山峰。

回到未来

在软件测试领域，时间似乎已经停滞了。我们在21世纪做事的方法与上个世纪几乎完全相同。Bill Hetzel在1972年出版的测试知识丛书至今仍然相当有价值。而我自己所写，于2002年首次出版的How to Break Software（如何攻破软件）系列，到今天仍被作为实用软件测试技术主要资源的代名词。

确实，如果我们可以把20世纪70年代的测试人员转换时空用在今日，我猜想他们的的技巧足够应付现代软件的测试。当然，他们需要学习网络和各种网络协议，但是他们拥有的实际测试技术将能得到很好的应用。如果从20世纪90年代找一个测试人员，则不几乎不需要任何训练。

对于开发人员来说，却不是这样，他们所掌握的那些上世纪的技巧几乎已经完全过时。让一个有一段时间不写代码的人重新开始编程，看看会有什么样的反应。让我感到很不安的是，我们可以从马路上直接雇用人手，而雇来的这些人从第一天起就能够测试，就能够有收获。事情真的有那么简单吗？或者是我们的期望值只有那么低？让我更加不安的是，我们没有任何可预测的方式将合适的测试人才从胜任工作状态训练为测试专。测试真的就那么困难吗？

这又是那个山峰了。门槛很低，但通往精通的道路却很艰难。

在通往测试山峰的入口，我们倚仗的是这样一个事实：测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要将一点点常识应用于输入的选择，就可以，我出缺陷。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为自，自己很聪明。然而过了入口以后，道路迅速陡峭起来，而测试知识变得越来越晦涩难懂。我们发现有人擅长于此，我们称这些人为“有天赋的人”，并欣赏他们的本能。

难道一定要依靠本能么？对于那些看起来不具备特长的人们，是否存在着一条翻越山峰的途径？是否可以以某种方法传授测试技能以培养出更多的专家呢？为认为这座山峰是可以通行的，而这一章正是我关于应该如何走这条路的笔记，你可以在自己的职业生涯中加以应用。这并不是一份食谱配方，一份职业生涯烹调书。不过你可以做一些事情来加速你的职业成长。但是，正如你可能已经猜到的，真正是说来容易，做起来难。

上山

测试职业的早期阶段主要是为征服测试山峰的漫长攀登做准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每一个项目，都有两部分（不一定相等）的任务。第一部分的任务是保证当前的测试项目获得成功。而第二部分的任务是学习你应该做些什么以便使下一个测试项目更加容易。我把它称为“测试今天的项目，准备明天的项目”。如果你做每一个项目把它都分割成为上述的两半，那么几乎可以保证你能持续获得进步。这样，你就可以随着每一个参与的项目逐渐成长为更优秀的测试人员。

现在就让我们来关注第二部分的任务——为下一个项目做准备。我们需要注意三个概念：重复、技术和漏洞。

重复

做任何一件事，绝不要重复两次而不意识到或质疑这其实是个问题。我希望所有年轻的测试人员都牢记这一点。我见过很多初学者，他们在单调的任务上浪费了太多的时间，比如，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版本来测试-这些任务列表可以变得很长，最后你会发现真正花在测试软件上的时间少得可怜。

这是许多新手常犯的错误。他们没能看到他们日复一日所做的工作的重复本质，儿当他们意识到这种重复时，几个小时已经过去了，而在这几个小时内他们没有做任何实际的测试工作。关注这些重复劳动，并且留意由此造成的真正的软件测试工作时间的流逝。为了能翻过测试的山峰，必须做一个测试人员应该做的工作，而不是实验室管理员或者测试机管理员的工作。

测试自动化是解决重复劳动的方案，也是本章稍后的主题。

技术

测试人员常常会对软件失效进行分析。分析缺陷时，我们从开发人员的失败中学习如何编写可靠的代码。我们也分析那些被我们忽略的缺陷。在应用程序上市以后，客户就会开始报告缺陷，我们将要面对处理一大堆失效的情形并寻找其中的重要缺陷。用户报告的每一个缺陷都说明我们的流程用问题，我们的测试知识还不够完善。

但是分析我们的成功也同样重要，儿许多新入职的测试人员却没能利用这个唾手可得的资源。我们在测试中找到的每一个缺陷都说明我们的的测试流程正在有效工作，都是一次成功。我们需要紧紧抓住这种绝好的机会，只有这样才能使成功不断的重复下去。

运动队常常这样做，他们会观看比赛录像，并分析每一个动作为什么奏效或者为什么不奏效。我清楚地记得一个小故事，我的一个朋友拍下了我儿子踢足球的一些照片。其中一张照片记录了她踢球的瞬间，那个球超过对方守门员成功进球了。当我把它给我儿子看时，我之处他站立的那条腿的姿势非常完美，他踢球的脚尖紧绷且出球点在鞋带间恰到好处的位置上。他盯着那张照片很长时间，从那以后他很少用不正确的姿势踢球。他那次得分可能只是碰巧做对了，但从此以后他有意识的运用这些技术使之接近完美。

现在回到新手测试人员的课程上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间考虑一下整体状况。我们使用什么技术找到了那个缺陷？我们是否可以创建一种方法来找到更多这类缺陷？我们是否可以记住…些实际的测试经验并不断地加以应用来帮助提高我们的工作效率？软件的哪些症状可以提示我们它具有缺陷？我们将来能否从那些症状中得到更多的警示？换句话说，这不仅仅是一个缺陷或是一次成功，这个缺陷教会了我们什么，是否使得我们将来成为更好的测试人员正如我儿子的进球一样，尽管第一个缺陷是偶然间发现的，但它不代表其余的成功都是偶然。理解我们成功的原因很重要，只有这样做，成功才能被复制。对于测试人员来说，这种保证成功的原因就是一系列的测试技术、建议和工具，它们可以提高我们在未来项目中的工作效率。

漏洞

测试人员最终都会变得很擅长寻找缺陷，但是要翻过测试的高峰，我们必须更快并且更有效率：高速低阻。换句话说，我们必须拥有一种本身不含缺陷的缺陷查找技术！

我喜欢这样来考虑问题：测试人员检视自己的工作时也需要发挥那种寻找缺陷的能力。我们必须使用和寻找产品缺陷一样的流程来寻找我们自己的测试流程，测试过程中的缺陷。我的测试流程是不是有问题？这里面是否有缺陷？这里是否存在着妨碍我提高效率的障碍？

你必须一直寻找更好的方法。有意识地去确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样，是什么限制了测试的能力？使用你拥有的测试能力来最优化自己的测试流程，这会帮助你在测试的山峰上快速攀登并增加你翻越山峰后成为专家的机会。

测试山峰的巅峰处是一个美好的地方。如果你成功地到了那里，恭喜你．但这并不是最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。自己一个人登顶是一回事，帮助其他人（那些能力不如你的人）登顶却完全是另外一回事。

一般来说，那些成功登上测试巅峰的人会成为使用工具的大师。那些商业工具、开开源免费工具，和自己写的工具（我个人最喜欢的工具）是极好地提高工作产出、增加工作成效的方法。不过，工具只是实现该目标的一种方法，但在许多其他方面它反而是一种限制，因为太多的人看不到工具的功能之外的东西。他们被限制在工具能为他们所做的事情中，没能看到或理解对工具还有更多的需求。登顶需要真正掌握的是“信息”。因为很多工具能处理信息，并使得信息的获取更加容易，所以测试人员变得过于依赖于他们的工具。但是信息本身以及如何利用这些信息才是真正的成功关键。

熟练掌握信息，指理解有哪些信息，这些信息将如何影响测试，保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自之前测试的信息。

来自应用程序的信息包括需求、体系结构、代码结构、源代码……甚至是关于应用程序在执行时做了哪些事情的运行信息。在编写和执行测试用例时，需要考虑这类信息，但信息的多寡在很大程度上取决于测试人员的能力，这是一种能够使测试更高效的能力。在测试中使用这类信息越多，测试就越偏向于工程而不是猜测。

在微软，我们有一个游戏测试组织（Games Test Organization，GTO），负责Xbox和PC游戏的测试。谈到利用应用程序的信息，他们是最优秀的。游戏是难以想象的丰富，测试起来非常复杂。游戏中很多可测试的内容都是隐藏的（因为让那些玩家找寻可以交换的物品正是游戏的乐趣之一）o如果GTO的测试人员所做的仅仅是玩游戏，那么他们找到的问题不会比最终用户更多。为了能做得更好，他们与游戏的开发人员合作创建了一些信息控制板，这些控制板暴露了一些基本上可以算得上作弊的信息给测试人员。这样，测试人员就能提前知道怪物会被投放在何处、物品被隐藏在哪里，他们可以看到墙的另一边，可以控制敌方的某些行为。他们的作弊工具（即测试上具）基本上使他们成为游戏里的神，让他们可以控制看到的信息以便更快更巧妙地测试。这个例予给有测试人员都上了一课。

来自测试的信息意味着你必须关注在测试时所做的一切，并使用获得的信息来影响今后的测试。你是否知道你的测试是如何与需求结合的，知道何时某一特定需求已经得到足够的测试？你是否使用代码覆盖率来影响未来的测试？你知道当代码更新或缺陷修复时那些测试会受到影响，还是知识重新运行所有的测试？理解测试进行到什么程度并随着测试调整测试策略，这是测试成熟的标志。

我以前曾在微软的Visual Studio的一个小组工作过，我们大量使用代码改动量（由于添加新特性或修复缺陷而改变的代码）和代码覆盖来影响我们的测试。我们花了很大的力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时，我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口，特性和代码覆盖率产生作用的，从而指导我们的测试人员，让团队中的每个人在他们所创建的所有测试用例基础上，写出更有意义的测试。

你用哪些信息来指导你的测试？你如何保证信息是可获取的，以便在测试中随时可以得到？你如何使得信息变得有用，以便它能以良好的方式影响你的测试？这些问题的答案将决定你在走下专家测试山峰时的前进速度。

下山

到达测试山峰的顶峰的时候，你已经成为一个十分能干的测试人员了，能力也许相当于你组里所有同事能力的总和。无论你在做什么，请不要试图做得比你的整个团队都好，不管你对此感觉有多好，或是你的老板对你遏得有多紧。一旦你走在下坡的路上，就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺陷的人”这样的荣誉头衔。反而我推荐你减少花在测试上的时间，而把创新作为你的首要任务。

在测试上创新指不急于向前，而是仔细观察、洞察先机、找到瓶颈并改进团队中所有其他人的工作方式。你的工作变为帮助其他人进步。在微软，我们有一个专门为此而设的正式职位——测试架构师。不过，不要因为缺少一个很酷的头衔而让你沮丧。无论别人怎么称呼你，当你在“下坡的路上，你能做的最好的事就是尽量保证更多的人能成功地爬上山峰的另一侧。

转自: http://m.elecfans.com/article/701700.html

不知不觉已经从事软件测试六年了，2006毕业到进入外包公司外包给微软做软件测试，到现在加入著名的外企。六年的时间过得真快。长期的测试工作也让我对软件测试有了比较深入的认识。

软件测试人员应该居安思危

每当经济不好，公司业绩不好的时候，公司都可能进行裁员。首先裁的就是测试人员。因为测试人员的技术水平相对来说比较低，容易被替代，招起来也比较容易。公司往往先拿测试人员开刀。

身为测试人员，虽然我们平常的工作大部分都比较安逸。但是千万不能温水煮青蛙。应该自强不息，要像开发人员一样，不断学习，提高自己的编程水平。这样就算被裁也能很快找到新的工作。

测试人员应该比开发人员更熟悉业务需求

测试人员的水平主要体现在测试用例的设计上。要设计出全面，覆盖广的测试用例，需要测试人员对自己所测试的项目的业务需求非常熟悉，甚至要比开发人员还要熟悉。

如果是测试银行系统，通信行业，或者ERP软件。这些业务知识非常有用的，学习起来比较有激情。

要做到精通业务需求谈何容易。

1. 要熟读功能需求文档，任何有疑问的地方都要去和PM确认。

2. 把自己当成最终用户，经常使用自己所测试的软件。模拟用户的行为。

3. 熟记软件的每个功能。

假如倒霉碰到一些又没用，又繁琐的软件，真的是不想去学习它的业务（出了这个公司就再也用不到的业务）

学会如何跟开发人员相处

测试人员必须跟开发人员密切合作，所以跟开发人员搞好关系是相当重要的。

1. 和开发人员成为朋友。

熟悉了干啥都方便

2. 不要打扰开发人员

看到开发在聚精会神写代码的时候，千万不要去打扰人家。写代码需要集中精力，如果被打扰，就会中断思考。

3. 集中问问题。

把需要问的问题都总结起来，集中起来问开发，这样能节省大量的时间。

4. 写好Bug，不被开发人员烦。

如果开发人员看到一个Bug 描述不清楚，还无法重现，他肯定会骂测试人员。所以测试人员一定要写好Bug，描述精确，简洁，没有歧义，详细简洁的重现步骤，加截图。

测试人员应该懂一些基本的编程

你的产品是用C# 开发的，那测试人员应该有C#的入门知识。你测试web程序，你起码要了解HTML，CSS， Javascript， Jquery吧，否则你测了一两年web程序，都不知道这东西是怎么做的，悲剧了吧。

只有懂代码你才能和开发人员交流，不被开发鄙视。

测试人员搭建开发环境

产品的代码是最好的学习资料了，我们不能总跟在开发屁股后面做测试，不能老是等开发build一个版本后，我们就测试这个版本，开发check in了什么代码，测试人员一点都不知道。偶尔我们应该了解下产品代码是怎么设计的，了解下开发人员是如何修复bug的。说不定编程水平高了，还能帮开发做code review.

使用源代码工具把产品代码check out到本机。经常看看代码，经常看看开发修复bug时候提交的代码。

写文档是测试人员的核心能力

我记得我以前的test lead说，之所以她能当lead，是因为她很会写文档发邮件。写文档需要总结归纳的能力，还要逻辑清晰。她非常擅长分析几十页的Spec，写出几十页的测试计划。她还非常擅长汇总测试报告。每天将完整，清晰，漂亮的测试报告发给各个组，让公司所有的人都能清晰的看到测试组的工作。

在她的带领下，我们总结出很多文档，比如，”New hire checklist”， “on boarding traning”，测试工具使用的文档，等等。

写多了博客后我发现我写文档能力提高了很多。

测试后期应该做两天交叉测试

交叉测试，就是指两个测试工程师，互相交换下测试的项目。这样做有很多好处。

1. 有利于找出bug，测试工程师测久了自己的项目，容易形成眼盲。会对一些Bug熟视无睹。

2. 有利于知识和业务共享，避免人员离职，请假，造成无人测试的情况。

3. 测试思想不一样，可以互相找出很多问题

测试人员的瓶颈

手动测试工作做个两三年，基本上就能掌握测试需要的大部分知识，如果没有爬到test lead的位置，很多人就感觉到发展瓶颈了，每天重复测试，学不到东西，很快就会对测试工作失去激情。

学不到东西，技术水平低下，是测试这个行业最大的毛病。

如何突破瓶颈？我也不知道。

尽量实现自动化

一点要抽时间尽量把自己的测试工作实现自动化，可以节省测试的时间，提高自己的技术水平，也可以避免老是重复测试。

自动化测试VS手动测试

现在很多公司招测试的要求越来越高，很多好公司招senior QA，都要求5年工作经验以上，掌握一门编程语言，有丰富的自动化测试经验。当然自动化测试的待遇也会比手动测试好很多。

自动化是趋势，只会做手动测试的人，以后肯定会失去竞争力。

自动化测试的技术和开发用到的技术相差太远

以前很多同事想由测试转开发，现在几年过去了，还是没转成，他们原先想利用自动化测试的技术积累，转去做开发。哪知道自动化测试用到的技术跟开发用到的技术相比，实在是相差太远。

测试转开发？难

努力学习编码，然后用于测试，才是正道

做测试最郁闷的是无法听懂开发人员讨论技术

有时候跟开发人员一起开会，会议上开发人员都热烈讨论。而我做为测试人员基本上听不懂这群开发在说什么，根本插不上话。很多会议我甚至都没说过一句话。

优秀的测试人员非常稀少

想把测试做好非常不容易，优秀的测试人员需要很广的知识面，良好的沟通能力（不但要和开发人员和项目经理打交道，还要跟其他组的人交流）。丰富的测试经验，对测试工作有极大的热情，耐心。还需要测试人员有丰富的业务知识，还要会写代码。

代码写得好的人，肯定就不会做测试，而是做开发去了。

大部分的测试经理都是有开发背景的

我发现我的几任上司都是由开发转来做测试的。他们都是有几年的开发经验，然后不知道什么原因转行做测试经理了。他们既能开发又能测试，啥都会，能给手下的测试人员提供技术支持。

假如一个测试经理啥技术都不懂，对内hold不住手下的人，对外其他组的人不鸟你。

软件测试的确非常枯燥，需要花费大量精力

不可否认测试工作需要耗费大量的精力，所以欧美才会把大量的测试职位外包给中国，一遍又一遍的重复测试，不停地执行测试用例，测得天昏地暗，头发晕。

我还记得我以前测试过一个程序的各个版本在Windows update中的升级，先安装老版本的程序，然后Windows update 重启后看看有没有升级，最后卸载。然后又安装，又卸载。最后测的差点吐血。

英语是测试人员的救命稻草

技术上已经不如开发了。在英语上一定占有一些优势。

同等的技术水平下，英语好的测试人员可以进外企，比一个英语不好的测试人员的待遇要高不少。

尽量少用UI自动化测试，多使用单元测试，接口测试

能找到bug的自动化测试，才是有用的，否则就是个噱头

UI自动化测试比较不稳定，对于测试结果的分析也困难。而且UI改动也大。所以应该尽量多做一些底层的的自动化测试，比如ASP.NET MVC 中UI和逻辑分开了，针对逻辑的自动化测试就比较好做了。

转载: http://m.elecfans.com/article/699537.html

软件测试工程师工作经验分享相关推荐

软件测试工作经验分享
最近,部门刚毕业入职的小MM跟大家提议,让大家把自己的软件测试工作经验分享一下,我整理了一下,可能不全. 测试工作经验分享天晴于2016年7月13日一.测试阶段划分 1. 单个模块功能测试时间相对 ...
应用交付工程师Troubleshooting经验分享2
本文接续之前的文章:应用交付工程师Troubleshooting经验分享前面讲述了设备登录管理以及可能遇到的网络问题,下面继续讲述4-7层配置及调试中可能遇到的问题: (一)服务器负载均衡 1. ...
软件测试工程师工作日常100问系列三【乐搏TestPRO】
上两个系列讲了软件测试基本常识问题,包括软件测试概念.流程及工作日常及需要具备的只是体系.请参阅: 软件测试工程师工作日常100问系列一软件测试工程师工作日常100问系列二今天我们来讲讲接口测试在 ...
软件测试工程师工作有多累?怎么入门学习软件测试呢？
软件测试随着时间的发展,越来越受欢迎了.那么,你了解过软件测试吗?软件测试工程师工作累吗?跟随千锋一起来了解一下吧. 1.其实IT行业都需要经常加班的,所以软件测试和软件开发其实都一样.当然了,一般来 ...
java 防渗透_「java、工程师工作经验怎么写」-看准网
java.工程师工作经验一工作时间:2014年10月03日-2019年10月03日 | 行业:计算机软件 | 职位:java.工程师 1. 根据移动端产品需求和逻辑流程提出合理.清晰的API结构. ...
浙大研究生Hadoop工作经验分享
为什么80%的码农都做不了架构师?>>> 浙大研究生Hadoop工作经验分享http://pan.baidu.com/s/1sjt5YKP 更多精彩内容请关注: 转载于:ht ...
UI设计汪汪Yuki丨云沃客工作经验分享
原文链接 UI设计汪汪Yuki丨云沃客工作经验分享笑一笑930509 2017-05-15 18:53:19 浏览27 评论0 发表于: 云工作平台 IT众包云沃客远程工作摘要: 一枚来自 & ...
1000个已成功入职的软件测试工程师简历经验总结：软件测试工程师简历项目经验怎么写?（含真实简历模板）
目录:导读一.前言:浅谈面试二.软件测试工程师:简历模板三.软件测试工程师:简历包装 1.基本信息: 2.教育背景: 3.专业技能 4.工作经历 5.项目经验 6.自我评价四.软件测试工程师: ...
3年汽车软件测试工程师的经验总结
入行汽车电子行业已经要三年了,闲下来的时间爱总结总结,感受一下现在自己的行业水平,技术水平和发展想法. 首先,工作三年了,除了业务知识积累之外,我觉得增长更多的是沟通与做事方式的长进.经常挂在嘴边的一 ...

软件测试工程师工作经验分享