提高软件测试能力的19条建议原文地址：Chcczbufgcrs and Testing Advice作者：Alan Myrvold,软件安全高级测试工程师译者注：本文主要面向软件测试的初入门者，但对有经验的软件测试工程师也应有益。我起初准备口己写10条建议给刚入门的软件测试员们。但之后我看了1 o 1 cats/icanhascheezburger上的名人Ben Huh的一段演讲。Ben指出,有了互联网,信息成 了免费资源,但组织,编辑,以及表达却都需要技巧。受Ben和cheezburger网站的启发，我请 求60名成功的软件测试工程师每人为刚入门的测试人员提出三条建议。其中的40多名答复了我, 使我最终有了一个长达100条的建议列表。出于保护他们的隐私，我不会原封不动的把这些建议罗列出来。但是有趣的是，我发现他们 的建议中有很多共同的地方，而所有这些建议加起來要比我原先自己想到的好得多了。我把这些我搜集的建议总结成以下19项：1. 想客户之所想在测试的过程中时刻想着川户。培养口己对川户需求的共鸣。和丿IJ户沟通并目观察他们怎们样使 用你的软件。2. 多读Bug如果你和一个团队的软件测试工程师一起工作，那么请阅读他们每天发的Bug,特别是那些针 对你的测试部分的Bug。你可以从别人如何找到Bug中学到很多东西。3. 多读代码找到你测试的那部分功能的代码。虽然写代码并不是你的书，但是读那些代码常常会帮助你找到 潜在的边际情况利软件缺陷。4. 为你发现的Bug而骄傲促成一个软件Bug的修复是从写好Bug标题和描述开始的。我每次发完一个Bug都会把这个Bug 重读一遍以确保它是合理的并提供恰倒好处的细节。如果一些重要的Bug没冇被纠正，要追根 究底，确保决定和利弊权衡是正确的。5. 参加软件功能的设计在软代码编写之前，在仍有可能有人的设计变更的时候，积极参加软件的计划阶段，这会帮助你 了解正被考虑的折衷和权衡。6. 设计你的测试无论是寻找边界值，运用组合技术，画图表，或创建测试模型，把你的想法放进你的测试设计中 总是有用的。在试探性测试的时候，有意识地去交替你的测试计划利产品学习。7. 了解你测试的功能不管你测试的是那一块功能，你应该了解它的设计，它的局限性，别人发现的Bug,代码的变动, 以及它和其它功能间的交互关系。8. 和别人合作测试你负责的部分和有不同少长的人起测试你的功能模块，起讨论测试的点子并且征询他们的反馈意见。9. 学习你测试的软件即使你只是测试一个软件中的很小一部分，成为英它新功能和整个软件的专家都会帮助你成为一 个更好的测试工程师。10. 培养和开发人员的良好关系测试工作有时候是对抗性的，以致很容易使有些与你共出的人在做决定时忽略你的意见。打修复 Bug的开发人员建立坚实的关系对了解最新进展和促成Bug的修复会有裨益。11扩大你的领域和人际网络成功的人都有一个的坚实可信的交际圈。他们可以从中得到他们需耍的专业知识和建议。不断在 你的公司内部和外部结交新朋友并发展专业领域的联系。12寻找良师或榜样我和许多出色的测试工程师一起匸作过，并且从他们那电学到了很多东两。为了提高你的测试技 能，你应该寻找“顾问”与他们见面或者榜样向他们效仿。13. 保持自省测试工程师善于发现软件的缺陷。如果把这种敏锐运用到自己身上，我们一定能更有效的发现自 身的不足之处。14. 管理你的时间我们的时间很容易被人块的工作和不断的会议所占据，导致我们没有时间去学习，公深挖更多的 Bug,甚至没有时间保持健康的生活状态。为了避免透支，你需耍学习如何管理你的时间。15. 明智地选择测试自动化自动化测试可能缺乏熟练测试人员的那种“余光视力”。不止确的自动化有时会变成一推庞人而 难以维护的代码，并且对衡量软件质量没有什么实际意思。但是精心设计的口动化测试有助于及 早发现软件缺陷。16. 提高你的编程能力我遇到过一些很有天赋的测试人员，他们倾向于不去写代码。这有一定道理。就像电影评论家在 变得挑剔而富有陈见后不会公考虑电影观众的喜恶一样，在我充当编程员的角色时，我想的就不 再和用户样了。但是编程还是一项有价值的技能，他能?耳助你更好地阅读代码，理解产品的内 在，同时帮助你写一些小工具使得平淡反复的工作变得简单。17. 参加Bug的审阅（Triage）在产品发布前的最后一些H子里，Bug帀阅组开会决定哪一些Bug应该修复，哪一些应该留到以 后的版本去修复。如果你通常不在这个会议的邀请乞单中，那么去主动耍求参加。你会看到在测 试员信誉，用户影响和已知风险等因索间做出折衷决定的过程。这将会是一种非常有趣的经历。18. 不断学习不管是“软技能”，比如公开演讲，或者编程语言，亦或新的测试技术，成功的测试工程师总 是会从繁忙中抽出时间来坚持学习。19. 爱你所做的事，并把它做好如果你不能承担放芥当前工作的代价，那么就学着去热爱它。测试人员有时会变得嫉惟愤俗，尤 其是在因难的发布周期中。享受工作并且不满足于仅仅完成计划内日标的人才会成为优秀的测试 工程师。细心，耐心，责任心等。是做好软件测试的基本要求而且做好软件测试还需要几个非常重要的索质，并且也是经常会被人遗忘的。一，分析能力，软件测试考研测试人员的是对功能的分析和总结能力，而且仅对功能的描述, 如果是对功能的描述，从人街上随便拉个人都可以来做软件测试。二，全局能力，为何这么说呢？软件测试现在基本都是在项Hi开始就介入，为何，我相信 很多人比我都清楚，因为早介入能早发现问题，但是确实是不是真的能早发现问题呢？还是需要 我们从全局去考虑到，需求分析工程师，架构师，开发都是人，是人就会有考虑不全的地方，所 以对于测试来说，能够有“众人皆醉我独酥”的心态和全局观是非常重要的，而且这往往也能体 现测试人员在相关部门的价值和可信度。如何做好测试，这个问题在面试的时候经常会被HR问到。当然，她们对答案的了解几乎都定照 本宣科。业内普遍认为测试是技术含量偏低的工作，确实刚毕业的学工能做测试，因为我们理解的测 试就是_群“鼠标点击者”在电脑前按照文档机械性重复着枯燥的爭情,最好写份报告，工作就 算完成了。对于部分企业或部分项口，这是做测试工作的基本现状。这也是人部分局外人和小部分局内 人所理解的测试。就是这种外界或部分局内人对测试错谋理解的氛围，才一定程度的影响了测试人员就业血的 狭窄和即将从事测试行业人的认知。每次，我在跟各个公司的HR讲解如何做好测试和测试与开发的区别冇多人的时候，她们都 很难真止理解到我对测试的看法，也更难说服她们我还可以做开发，而且会比以前更好。那么，测试究竟是怎样的工作呢？测试比开发究竟差多少呢？先从开发与测试的发展讲起：开发从1946年初计算机诞生开始，到现在，顶多有五I几年 的历史。在人陆，开发也就有20年左右的丿力史。能正规的开始测试应该从95年微软把windows 系统的注册表本地化业务交给国内算起，发展将近巧年，但真止的测试还是耍从93年做软件外 包开始，实际发展也就7年时间。再说什么是开发：人部分人都容易理解了开发，就是按照需求创造出一个新的应用程序呗。 那么测试，就是检测开发出来的东西（如api, II, user experience, internal function, environment-demond such as network bnndwidth and System and Memory, etc.）打需求冇无 枷,还能挖掘出潜在需求，实际结果址舎址期塑的行为。我们常说测试是为了能保证产品质量，尽早找出bug。这么说也对，不过还是很抽象，并且 在概念的理解上，简单化了测试。测试一由于历史发展佼短，不象开发那样发展那么迅速，可借鉴的东西不象开发那么明显 （代码是可见的，测试就难了），所以这就意味着一点：测试更需耍人的创新，验证程序的正确 性更是需要人们人量的创造性劳动。验证程序的E确性，远不象普通人想象的那样简单。开发是开发人员使用编程语言按照需求文档写出來另外一套API。测试就是测试人员为了更 好验证开发出来的AP】需求文档，不用去关心产品功能实现，而是首先去考虑开发出来的API 是否符合需求（这就是BVT/Function Test）,其次是通过设计和搭建好的测试情景公分析对系 统，网络，其他API, module模块的影响（白盒测试,集成测试），有些时候需要做性能压力测 试。如果出现问题，就要进一步分解测试用例，定位问题所在。要做到以上几点，会遇到很多挑战，说门了，就是会遇到很多困难，如同开发人员一样，都 需要用专业知识与想法来解决。现在说下困难是怎样的，你才能了解测试人员每天遇到的问题，才会知道需要什么样的人才 能做好测试。第一，测试产品是否符合需求，需耍用有效的方式，全面验证需求点。高级测试人员耍写很 多专业的文档，应用很多IT方面的知识，与更高级更资深的人士探讨需求，去开发出不同的文 档来保证将在产品生命周期中的乞个阶段祁作最匸确的事情。普通测试人员每天耍做好记录和报 告，说明测试了哪些，哪些还没有测试。要求有很好的自我管理的能力。第一，设计与搭建测试环境。随着开发技术的不断进步，诸如多线程，虚拟化，超大规模数 据量的并发，安全性，软件间、不同系统平台间的交互响应这类问题会给搭建环境，模拟真实客 户的使用环境，对测试人员來讲都很有挑战。而开发人员更关注于需求实现细节，不做架构师的 普通开发人员不会考虑，只耍实现出来功能，做个单元测试，接下来就交给测试人员来综合考虑 这个开发出来的东西是不是很好用，会带来哪些问题，开发人员很懒，等测试人员检查出来问题, 他们才去应付问题，注意，我说的是有些情况他们都是应付而已，掩盖问题。所以，测试人员 往往比开发人员更懂得需求，而且要懂得很多IT知识，才能最人限度的评估出开发出来的东两 到底有哪归问题。开发就好比去制作出一个玩具模型，测试人员就是研究这个玩具模型，拆开, 放到事前预备好的装模型的模具甲检测是否符合规格；再放到更人的玩具模型甲，看看这些小 东西跟具他的模型玩具能一起工作。这些工作有些时候是无可借鉴的，不象开发那样，上网搜索 就能找到答案，测试就很难，几乎是不可能，只能自己想办法，找出解决办法。第三，如何去验证程序的止确性本身就是个很有挑战的问题。因为它耍求了测试人员耍比开发人 员考虑更多的东西。比如开发人员开发个客户端的程序,此客户端能跟别的机器上的客户端交互, 开发人员只要开发出send和receive的功能，而不玄实现多台机器上实际运行的情况是什么样 子，但测试人员就必须要做出來实际运行的情况才能验证程序是否止确。再比如开发人员开发出 来一个按钮，它不会考虑这个按钮在哪些&什么情况下会被点击，并且结果是怎样的.测试人员 要想尽办法甚至是创造性的找岀这样的环境并目能够模拟点击效果与检資结果。再比如，开发人 员不会考虑如何造出5000人同时在线的情况，也很少开发人员考虑到异常访问会不会对开发使 用到的对象（假如说cache, session, Page_Load中的方法，事件event, handler）产生不 期望的行为。测试人员需要对不同情形作测试，来找到答案。再看开发与测试的区别：第一，开发人员关心局部，测试人员要关心全部。测试人员只有细心才能找到bug。第二，好的测试人员将來更容易成为项日管理者，因为PM就不用关心技术实现细节，测试 人员比开发人员更注重流程和管理，更会沟通。第三，开发人员由于开发周期短，所以会比较急躁，而测试人员更具有好奇心，好奇心能一 定程度上的帮助测试人员产生出逆向思维的想法，超出开发人员的考虑边界。第四，开发人员比测试人员惯得如何实现功能，测试人员也可以去弄愦如何实