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