第一篇：做好软件测试工作的19条建议
提高软件测试能力的19条建议
原文地址: Cheezburgers and Testing Advice 作者：Alan Myrvold，软件安全高级测试工程师
译者注: 本文主要面向软件测试的初入门者，但对有经验的软件测试工程师也应有益。
我起初准备自己写10条建议给刚入门的软件测试员们。但之后我看了lolcats/icanhascheezburger 上的名人Ben Huh的一段演讲。Ben指出，有了互联网，信息成了免费资源，但组织，编辑，以及表达却都需要技巧。受Ben和cheezburger网站的启发，我请求60名成功的软件测试工程师每人为刚入门的测试人员提出三条建议。其中的40多名答复了我，使我最终有了一个长达100条的建议列表。
出于保护他们的隐私，我不会原封不动的把这些建议罗列出来。但是有趣的是，我发现他们的建议中有很多共同的地方，而所有这些建议加起来要比我原先自己想到的好得多了。
我把这些我搜集的建议总结成以下19项： 1.想客户之所想
在测试的过程中时刻想着用户。培养自己对用户需求的共鸣。和用户沟通并且观察他们怎们样使用你的软件。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）
在产品发布前的最后一些日子里，Bug审阅组开会决定哪一些Bug应该修复，哪一些应该留到以后的版本去修复。如果你通常不在这个会议的邀请名单中，那么去主动要求参加。你会看到在测试员信誉，用户影响和已知风险等因素间做出折衷决定的过程。这将会是一种非常有趣的经历。18.不断学习
不管是“软技能”，比如公开演讲，或者编程语言，亦或新的测试技术，成功的测试工程师总是会从繁忙中抽出时间来坚持学习。19.爱你所做的事，并把它做好
如果你不能承担放弃当前工作的代价，那么就学着去热爱它。测试人员有时会变得嫉世愤俗，尤其是在困难的发布周期中。享受工作并且不满足于仅仅完成计划内目标的人才会成为优秀的测试工程师。细心，耐心，责任心等。是做好软件测试的基本要求
而且做好软件测试还需要几个非常重要的素质，并且也是经常会被人遗忘的。
一，分析能力，软件测试考研测试人员的是对功能的分析和总结能力，而且仅对功能的描述，如果是对功能的描述，从大街上随便拉个人都可以来做软件测试。
二，全局能力，为何这么说呢？软件测试现在基本都是在项目一开始就介入，为何，我相信很多人比我都清楚，因为早介入能早发现问题，但是确实是不是真的能早发现问题呢？还是需要我们从全局去考虑到，需求分析工程师，架构师，开发都是人，是人就会有考虑不全的地方，所以对于测试来说，能够有“众人皆醉我独醒”的心态和全局观是非常重要的，而且这往往也能体现测试人员在相关部门的价值和可信度。
如何做好测试，这个问题在面试的时候经常会被HR问到。当然，她们对答案的了解几乎都是照本宣科。
业内普遍认为测试是技术含量偏低的工作，确实刚毕业的学生能做测试，因为我们理解的测试就是一群“鼠标点击者”在电脑前按照文档机械性重复着枯燥的事情，最好写份报告，工作就算完成了。
对于部分企业或部分项目，这是做测试工作的基本现状。这也是大部分局外人和小部分局内人所理解的测试。
就是这种外界或部分局内人对测试错误理解的氛围，才一定程度的影响了测试人员就业面的狭窄和即将从事测试行业人的认知。
每次，我在跟各个公司的HR讲解如何做好测试和测试与开发的区别有多大的时候，她们都很难真正理解到我对测试的看法，也更难说服她们我还可以做开发，而且会比以前更好。
那么，测试究竟是怎样的工作呢？测试比开发究竟差多少呢？
先从开发与测试的发展讲起：开发从1946年初计算机诞生开始，到现在，顶多有五十几年的历史。在大陆，开发也就有20年左右的历史。能正规的开始测试应该从95年微软把windows系统的注册表本地化业务交给国内算起，发展将近15年，但真正的测试还是要从93年做软件外包开始，实际发展也就7年时间。
再说什么是开发：大部分人都容易理解了开发，就是按照需求创造出一个新的应用程序呗。那么测试，就是检测开发出来的东西（如api，UI，user experience，internal function，environment-demond such as network bandwidth and System and Memory，etc.）与需求有无差距，还能挖掘出潜在需求，实际结果是否是期望的行为。
我们常说测试是为了能保证产品质量，尽早找出bug。这么说也对，不过还是很抽象，并且在概念的理解上，简单化了测试。
测试——由于历史发展较短，不象开发那样发展那么迅速，可借鉴的东西不象开发那么明显（代码是可见的，测试就难了），所以这就意味着一点：测试更需要人的创新，验证程序的正确性更是需要人们大量的创造性劳动。验证程序的正确性，远不象普通人想象的那样简单。
开发是开发人员使用编程语言按照需求文档写出来另外一套API。测试就是测试人员为了更好验证开发出来的API需求文档，不用去关心产品功能实现，而是首先去考虑开发出来的API是否符合需求（这就是BVT/Function Test），其次是通过设计和搭建好的测试情景去分析对系统，网络，其他API，module模块的影响（白盒测试，集成测试），有些时候需要做性能压力测试。如果出现问题，就要进一步分解测试用例，定位问题所在。
要做到以上几点，会遇到很多挑战，说白了，就是会遇到很多困难，如同开发人员一样，都需要用专业知识与想法来解决。
现在说下困难是怎样的，你才能了解测试人员每天遇到的问题，才会知道需要什么样的人才能做好测试。
第一，测试产品是否符合需求，需要用有效的方式，全面验证需求点。高级测试人员要写很多专业的文档，应用很多IT方面的知识，与更高级更资深的人士探讨需求，去开发出不同的文档来保证将在产品生命周期中的各个阶段都作最正确的事情。普通测试人员每天要做好记录和报告，说明测试了哪些，哪些还没有测试。要求有很好的自我管理的能力。
第二，设计与搭建测试环境。随着开发技术的不断进步，诸如多线程，虚拟化，超大规模数据量的并发，安全性，软件间、不同系统平台间的交互响应这类问题会给搭建环境，模拟真实客户的使用环境，对测试人员来讲都很有挑战。而开发人员更关注于需求实现细节，不做架构师的普通开发人员不会考虑，只要实现出来功能，做个单元测试，接下来就交给测试人员来综合考虑这个开发出来的东西是不是很好用，会带来哪些问题，开发人员很懒，等测试人员检查出来问题，他们才去应付问题，注意，我说的是有些情况他们都是应付而已，掩盖问题。所以，测试人员往往比开发人员更懂得需求，而且要懂得很多IT知识，才能最大限度的评估出开发出来的东西到底有哪些问题。开发就好比去制作出一个玩具模型，测试人员就是研究这个玩具模型，拆开，放到事前预备好的装模型的模具里检测是否符合规格；再放到更大的玩具模型里，看看这些小东西跟其他的模型玩具能一起工作。这些工作有些时候是无可借鉴的，不象开发那样，上网搜索就能找到答案，测试就很难，几乎是不可能，只能自己想办法，找出解决办法。
第三，如何去验证程序的正确性本身就是个很有挑战的问题。因为它要求了测试人员要比开发人员考虑更多的东西。比如开发人员开发个客户端的程序，此客户端能跟别的机器上的客户端交互，开发人员只要开发出send和receive的功能，而不去实现多台机器上实际运行的情况是什么样子，但测试人员就必须要做出来实际运行的情况才能验证程序是否正确。再比如开发人员开发出来一个按钮，它不会考虑这个按钮在哪些&什么情况下会被点击，并且结果是怎样的.测试人员要想尽办法甚至是创造性的找出这样的环境并且能够模拟点击效果与检查结果。再比如，开发人员不会考虑如何造出5000人同时在线的情况，也很少开发人员考虑到异常访问会不会对开发使用到的对象（假如说cache，session，Page_Load中的方法，事件event，handler）产生不期望的行为。测试人员需要对不同情形作测试，来找到答案。
再看开发与测试的区别：
第一，开发人员关心局部，测试人员要关心全部。测试人员只有细心才能找到bug。
第二，好的测试人员将来更容易成为项目管理者，因为PM就不用关心技术实现细节，测试人员比开发人员更注重流程和管理，更会沟通。
第三，开发人员由于开发周期短，所以会比较急躁，而测试人员更具有好奇心，好奇心能一定程度上的帮助测试人员产生出逆向思维的想法，超出开发人员的考虑边界。
第四，开发人员比测试人员懂得如何实现功能，测试人员也可以去弄懂如何实现的，但他的职责是去使用这个实现的东西。开发人员是制作者，测试是使用者。反恐游戏大家都知道吧，比起佩服开发人员，我们更佩服玩的好的玩家。测试人员是玩家。
什么是好的测试人员：
举国例子：一般的测试人员设计出100的测试用例，仅能找出3个bug，好的测试人员只用30个用例就能找出5个bug，做久了的测试人员，对软件缺陷有灵敏的嗅觉。
很多细节需求在需求文档之外，当测试人员找出这样bug的时候，开发人员都会佩服测试人员的能力。
总结一下，我们目前对测试的成熟度远不如开发，不象开发那样容易找到问题的答案，需要很多IT知识和创造性的劳动（包括开发出测试工具，开发测试框架，搭建模拟出测试环境），要想让测试行业重视与发展起来，就需要从业人员的共同努力，比开发人员更少的浮躁心与突破自我的精神与能力。
开发一个好的软件，40%以上的时间用在测试上,所以软件测试工程师非常重要,用我们的话来说很吃香。现在从事程序员的人有很多,做测试工程师的人少点,工作压力不太大
测试工程师应该具备的三项基本素质[1] 很多年轻或者刚刚从事测试工作的工程师，经常会问：“测试工程师需要什么技能或者具有什么素质才是合格的？”与开发人员相比，测试人员不但需要一技之长，还需要掌握诸如操作系统、数据库、网络等多方面的知识。
经过这几年的发展，国内IT公司的测试水平有了很大的提高，但是与此同时，很多测试工程师也迎来了个人的发展瓶颈：很多人从测试工程师做到了测试经理的职位，不知道下一步如何发展；或者每天机械地从事着功能测试工作。
根据作者多年的经验，一个有竞争力的测试人员要具有下面三个方面的素质：
计算机专业技能
计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。计算机专业技能主要包含三个方面：
测试专业技能
现在软件测试已经成为一个很有潜力的专业。要想成为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目的之一。因此，测试工程师应该努力学习测试专业知识，告别简单的“点击”之类的测试工作，让测试工作以自己的专业知识为依托。
测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。软件编程技能
“测试人员是否需要编程？”可以说是测试人员最常提出的问题之一。实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代码的几乎都去做开发了，而很多人则是因为做不了开发或者不能从事其它工作才“被迫”从事测试工作。最终的结果则是很多测试人员只能从事相对简单的功能测试，能力强一点的则可以借助测试工具进行简单的自动化测试（主要录制、修改、回放测试脚本）。软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程序。只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。
此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。因此测试人员要具备一定的算法设计能力。依据作者的经验，测试工程师至少应该掌握Java、C#、C++之类的一门语言以及相应的开发工具。
网络、操作系统、数据库、中间件等知识：
与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识
软件测试工程师－IT就业新亮点, 根据有关职位统计资料显示，在国外大多数软件公司，1个软件开发工程师就需要辅有2个软件测试工程师。目前，软件测试自动化技术在我国则刚刚被少数业内专家所认知，而这方面的专业技术人员在国内更是凤毛麟角。根据对近期网络招聘IT人才情况的了解，许多正在招聘软件测试工程师的企业很少能够在招聘会上顺利招到合适的人才。
随着中国IT行业的发展，产品的质量控制与质量管理正逐渐成为企业生存与发展的核心。从软件、硬件到系统集成，几乎每个中大型IT企业的产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。而软件测试工程师就是其中之一。
据了解，由于软件测试工程师处于重要岗位，所以必须具有电子、电机类相关专业知识背景，并且还应有两年以上的实际操作经验。他们应熟悉中国和国际软件测试标准，熟练掌握和操作国际流行的系列软件测试工具，能够承担比较复杂的软件分析、测试、品质管理等任务，并能独立担任测试、品质管理部门的负责人。一般情况，软件测试工程师可分为测试工程师、高级测试工程师和资深测试工程师三个等级。
在具体工作过程中，测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。对软件测试工程师而言，必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有专业的技术水准是无法胜任这项工作的。同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。
因此，在企业内部，软件测试工程师基本处于“双高”地位，即地位高、待遇高，有的人月薪可高达8000元。可以说他们的职业前景非常广阔，从近期的企业人才需求和薪金水平来看，软件测试工程师的年工资有逐年上升的明显迹象。测试工程师这个职位必将成为IT就业的新亮点。
软件测试还是比较容易得，尤其是功能性测试，就是一般说黑盒测试。这些测试一般都是手工进行，测试的过程就是使用软件，按组测试，组长会把这个软件的不同模块分给不同的测试工程师进行测试。测试是比较枯燥的。我们进行测试一般是先测试，测试完成后在写用例，主要是为了节省时间。
软件测试，从不同的角度出发会派生出两种不同的测试原则。从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷；从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求。应从用户和开发者的角度出发进行软件产品测试的。
为了达到上述的原则，需要注意以下几点：
1.应当把“尽早和不断地测试”作为开发者的座右铭。
2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
第二篇：软件测试的一些心得和建议（本站推荐）
一、软件测试员自身素质培养
（1）首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信一定能克服。
（2）善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。
（3）打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。（4）保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。（5）做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。（6）灵活一些，聪明一点，多制造一些容易产生bug的例子。（7）在有条件的情况下，多和客户沟通，他们身上有你所需要的。（8）设身处地为客户着想，从他们的角度去测试系统。
（9）不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。
（10）考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。
（11）提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。
（12）追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。（13）幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。
（14）到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？
二、浅谈软件测试之技巧
软件测试虽然辛苦，但是掌握了一定的技巧之后可以事半功倍。
（1）边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。（2）非法测试，例如在输入数字的地方输入字母。
（3）跟踪测试，跟踪一条数据的流程,保证数据的正确性。
（4）在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
（5）接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。（6）代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
（7）突发事件测试，服务器上可能发生意外情况的测试。
（8）外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
（9）在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
（10）认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
（11）文字测试，如果在系统中有用词不当的地方，我想这是不应该的。
（12）系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
（13）用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。
第三篇：软件测试工作周报
周一：熟悉工作环境，接受部门主管分配的任务，熟悉目前公司正在进行的项目软件的相关内容。
周二：学习项目相关内容，主要看软件需求规格说明书
周三：学习项目相关内容，主要看了软件详细规格说明书，了解到UML使项目各个功能模块更加地清晰。
周四：继续学习项目文档，同时学习软件缺陷跟踪记录软件和AVN。了解并学会应用专门记录软件缺陷，以及跟踪软件缺陷的软件工具-Bugfree.周五：测试了开发项目的基础指标模块，编写测试用例，同时学习项目管理工具SVN的使用。
周一：继续测试基础指标模块，编写测试用例，同时学习项目管理工具SVN的使用。周二：画数据流图，测试没有测完的模块，学习下一个模块的相关文档内容。
周三：回归测试之前的模块，测试用户数据模块，继续学习下一个模块的相关内容。
周四：测试系统管理模块，回归测试之前的模块，部门知识分享。初审测试文档，修改文档的相关内容，测试报表中心模块，回归测试各相关模块。周五：复审测试文档，修改文档的相关内容，办理任务交接。总结：两周以来对技术方面的相关知识、软件测试有了新的认识。
第四篇：软件测试（推荐）
一、简答5*6’
1.为什么不让时间有余的人做测试工作
表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。2.软件测试风险主要体现在哪里
我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。因此，我们要尽可能的选择最合适的测试量，把风险降低到最小 3.所有软件测试缺陷都需要修复吗
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，修改缺陷可能引入新的缺陷。
-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。4.如何减少测试人员跳槽带来的损失 建议我们从以下两个方面做起：
-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。
-管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。
5.验收测试的注意点有哪些 测试要注意下面的事项：
（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。（3）永远不能欺骗用户，蒙混过关。6.完全测试程序是可能的吗
实际上完全测试是不可能的。主要有以下原因：-完全测试比较耗时，时间上不允许；
-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；-输入量太大，不能一一进行测试；-输出结果太多，只能分类进行验证；-软件实现途径太多；
-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；因此测试的程度要根据实际情况确定 7.是不是发现的缺陷越多就说明软件缺陷越多 其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。
“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。8.软件测试就是QA吗
软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。9.测试产品和测试项目区别
习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：
-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作 10.如何编写提交给用户的测试报告
测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况,一般外部测试报告要满足下面几个要求：
根据内部测试报告进行编写，一般可以摘录；不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；报告上面的内容尽量要真实可靠；整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。总之，外部测试报告要小心谨慎的编写。
二、论述2*12’
1.请论述为什么要进行软件测试，并列举历史上2~3个著名软件测试（缺陷）案例，说明测试重要性
软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（，另一方面是确认软件以正确的方式来做了这个事情。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。
爱国者导弹防御系统把“枪口”对准了自己人 美国迪斯尼公司的狮子王游戏软件的兼容性问题 售票系统性能问题
2.论述软件测试科学的发展历程 1957年之前－调试为主 20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。
1957–1978－证明为主 当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。
1979–1982－破坏为主 我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。
1983–1987－评估为主 人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展.1988–至今－预防为主 预防为主是当下软件测试的主流思想之一。测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。3.论述软件缺陷的由来
软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
软件本身：①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。
团队工作：系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致。对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。项目组成员技术水平参差不齐技术问题。算法错误：在给定条件下没能给出正确或准确的结果。语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。计算和精度问题：计算的结果没有满足所需要的精度。系统结构不合理、算法选择不科学，造成系统性能低下。接口参数传递不匹配，导致模块集成出现问题。
项目管理的问题：缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。文档不完善，风险估计不足等。4.软件测试V模型
①绘制示意图
②阐述每个步骤是做什么 需求分析
即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能
概要设计
主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。详细设计
对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等。软件编码
按照详细设计好的模块功能表，编程人员编写出实际的代码。单元测试
按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同。集成测试
经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。系统测试
经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。
第五篇：如何做好软件售前工作
如何做好软件售前工作
售前，是一种对销售阶段的工作的统称，不是指固定的岗位。那种将售前理解成为由专门的人员来完成的想法是不正确的。任何的销售过程，其实都是分为售前、售后两个阶段，是以合同签订做为两个阶段的划分标志的。
产品由于其技术含量的不同以及标准化的程度，参与售前的人员会有多有少。标准化的产品，销售人员既承担技术职责又承担商务职责；非标准化的的产品可能会由不同的人员来完成，以知识做为最终产品的软科学的销售过程对参与人员的知识要求更高。
在合同签订以前，所有参与者，为了达到签单的目的，所做的工作统统称为售前。为了区分不同的人员在该阶段所做工作的范围和职责，不同的行业设置了不同的岗位和职责。例如，在IT行业，一般有销售、客户经理负责销售机会的把握和客户关系的联络；由技术支持，咨询顾问，售前工程师，产品经理等做技术方案的选型，由市场推广人员提升品牌价值、提升市场知名度等的工作等。会有不同的人员参与的售前的过程中来，不同的岗位，完成不同的工作，但是大家的目标是一致的。同样的，售后是指合同的执行、交付以及服务过程，也是由不同的岗位参与完成的。签单是售前工作的最终目标。管理软件由于具有很高的知识含量，因此，其销售过程更需要是不同的人员合作完成，团队合作因而显得尤为重要，特别是必须建立一种团队售前的方法论。
那么，如何统一不同的人员的工作方法？必须把握这么几个原则： 必须要有“引导”客户的意识；
必须要从如何体现客户价值来进行软件讲解； 必须要体现出“咨询”的价值。
如何引导客户
如果能够成功的引导客户对项目的成功是非常重要的。引导客户一般有这么几种做法：
一是如果客户处在选型阶段，对产品并没有非常明确的倾向性。这时候要尽量了解客户最关心的问题和客户打算希望了解那些友商的产品。掌握了客户最关心的问题，也大概知道了后面可能碰到的竞争对手，这时候我们可以在软件演示和讲解中，侧重于如何很好的处理客户最关心的问题，并不动声色的横向比较一下和友商的区别。当然，孩子是自家的亲，我们的目的就是要让客户的头脑中体现出：“这家的产品很不错，很有特点。如果选择友商，会存在一些问题„„”——当然，做到这一点，需要我们对自己的产品要非常了解，对其他友商的产品也要尽可能的了解。同时，一定要注意，只有你能确定某个产品的功能和我们的区别，你才可以说出他们的名字。否则，不确定的事情就不要指名道姓的说，要提防万一以后客户看了这家产品，发现你说的和事实有出入，可能会影响客户对你的印象。
二是如果客户选型已经很长的时间了，并且有倾向性的意见。这时候的引导就要多费些力气，尽量采用这样的语气：是，你说的很正确，能这样处理业务的系统确实很好，比起那种只能„„的系统，这样做要好的多，不过，好像还有另外一种处理方式，„„这样比刚才那种处理方式的优点在于„„。总之，这时候的目的是先让客户的立场产生动摇，这样才可能有机会产生奇迹。
如何最好软件演示
做好软件讲解，也是非常具有挑战性的。笔者在近几年的软件讲解中，也有不少的感悟。
如果客户是技术人员，他比较关心的是你实现功能的方式。就像我们技术人员看一些软件，首先关心的是：这个软件采用了一个第三方组件做报表，挺好的；这个软件的架构挺有优势的等等。对这样的客户，那就要解释技术优势。
但如果是管理人员，他关心的是：我的业务，你是怎么实现的？你们这样做，有什么好处？等等。这个时候，就要尽可能用他们听到懂得语言，不要讲有什么功能，而是要描述业务如何处理，这样做的好处是什么。
在软件演示的时候，一定要注意不要急着开始。而是要先和对方聊聊，倾听对方的兴趣点，这个时候，你就可以说：我们是这样做的„...。这个问题演示完了，要先停下，继续和客户交流，发现问题，再演示，如此循环。这样做的效果要比从头到尾，从A功能到B功能的演示方式好的多。
如何体现咨询的价值
在售前的过程中，最重要的是要让客户信任你，对你有信赖感。要做到这一点，就必须站在客户的角度，去帮着客户解决问题，要能体现出咨询的“价值”。什么是咨询？什么是咨询顾问？
我个人觉得这并神秘，并不是只有麦肯锡那样的才能做咨询和咨询顾问。日常生活中，只要存在我们不熟悉的领域，我们问对方，都是咨询，都存在着咨询顾问。例如：我们想买房，我们去已经买过房子的朋友那里了解情况，这就是咨询，朋友就是咨询顾问；我们想买个数码照相机，到处考察，了解情况，这就是咨询，就存在咨询顾问；应聘人员打电话到公司，询问公司的地址，做什么车可以到，这也是咨询。所以，咨询无处不在，人人都是咨询顾问。
在企业的商业行为中，只要是和客户打交道的人，都是顾问，因为客户有从你身上了解你所代表的公司、所代表的产品的信息的需求和行为，所以，这时候你就是顾问。
那么，如何体现顾问的价值呢？ 实际上，你在和客户交往的过程中，已经无时无刻不在解答客户的“咨询”，但是可能客户和你都没有意识到。为什么呢？因为回答问题的方式不对！一般人在和客户的交往中，往往是先听完客户的问题，接着就开始滔滔不绝的讲我们怎么怎么样，同时阐明我们的观点，但是这种方式并不是最好的，因为客户往往不喜欢你把自己的观点强加给他。
所以，改变交流的方式，将一问一答式的方式改为“探讨”的方式。这样，不是你在回答客户的问题，而是在和客户商讨解决问题的方法，慢慢的将自己的观点通过一种柔性的方式展现出来。“润物细无声”，才能达到活跃讨论气氛、引发共鸣的。其次，在和客户交流的过程中，要体现出“咨询”的价值，还要在交流的过程中，做到对客户的业务的理解和尊重，同时结合以前项目中的经验、教训，真诚的给客户一些建议，帮助客户规避一些风险。
最后，最重要的是，要能针对客户的提议，提出一些有益的建议。如果客户的需求没有超出你的预期，可以针对这个需求，提出一些如何更好的实现的建议；如果客户提出了超出你预期的需求，可以委婉的和客户一起分析这样做存在的问题。
总之，软件销售过程中，对售前团队成员的培训和管理就显得尤为重要。客户在与软件公司不同人员的接触过程中，会逐渐形成对软件公司的一种具象的认识，而这些认识是好是坏，与每个售前参与者都有直接的关系。而这些认识很可能与客户经理和售前技术支持所要展现的公司形象是交叉的，即客户可能通过客户经理来认识软件公司的技术水平和产品，又可能通过技术支持工程师来认识软件公司的服务。所以，做好售前工作，需要每个参与售前的人员都有相同的工作原则和方法。这样通过不同层次人员和客户的交流、沟通，会逐渐加深客户对公司的信心。
点击咨询 