测试工程师 6年工作经验总结

第一篇：测试工程师 6年工作经验总结

[测试工程师 6年工作经验总结 观后感]

1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来，测试工程师 6年工作经验总结 观后感。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！

2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。

3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。

5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，!00%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。

6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的，观后感《测试工程师 6年工作经验总结 观后感》。试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！

7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀的开源框架？在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式？为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题？？？“他山之石、可以攻玉”。

8、养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知，对软件开发人员而言，有、无经验的一个显著区别是：无经验者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题（其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面）。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是，最好还是自己实现，这样没有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。

9、理论与实践并重，内外双修。工程师的内涵是：以工程师的眼光观察、分析事物和世界。一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发的思想精髓的人（个人观点、欢迎探讨）。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个角度来看，这只是外在的东西，并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题，才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些思想与方式，最终形成自己的理论体系和实用方法论。

10、心态有多开放，视野就有多开阔。不要抱着自己的技术和成果，等到它们都已经过时变成垃圾了，才拿出来丢人现眼。请及时发布自己的研究成果：开发的产品、有创意的设计或代码，公布出来让大家交流或者使用，你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具，5、6年之后的今天，还是那个样子，今天流行的好多Windows系统工具都比自己的晚，但进化得很好，且有那么多用户在使用。并且，不要保守自己的技术和思想，尽可能地与人交流与分享，或者传授给开发团队的成员。“与人交换苹果之后，每个人还是只有一个苹果；但交换思想之后，每个人都拥有两种思想”，道理大家都懂，但有多少人真正能做到呢？

11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”，网上有很多的开源项目、合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工作是做ERP，就不去学习和了解嵌入式、实时、通信、网络等方面的技术，反过来也是一样。如果当他别人拿着合同找你合作，你却这也不会，那也不熟时，你将后悔莫及。

12、书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明：

“对于一个有一定基础的人来说，他只要真正肯下功夫，在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果，故命名为西蒙学习法。可见，掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识，有空花时间看看，韬光养晦、未雨绸缪。

13、本文的总结与反思： A：不要去做技术上的高手，除非你的目标如此。虽然本文是关于提高软件开发知识的建议，做技术的高手是我一向都不赞同的。你可以提高自己的专业知识，但能胜任工作即止。

B：提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理，可以很容易地延伸、应用到生活的其它方面。

C：在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质，尤其是那些目标不在技术方面的朋友。

〔测试工程师 6年工作经验总结 观后感〕随文赠言：【人生舞台的大幕随时都可能拉开，关键是你愿意表演，还是选择躲避。】

第二篇：测试工作经验总结

测试工作经验总结

功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。

要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。

了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。

测试用例的编写经验步骤和数据的分离

将输入的各种数据已参数的形式表达在操作步骤中，而不需要为每一种输入数据创建一个测试用例。

例如：atm存款

好的测试用例，在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

1.密码正确的登录

2.密码错误的登录

3.密码输入三次错误，卡被锁定

4.取少于余额的款项

5.尝试取大于余额的款项

6.尝试取等于余额的款项(考虑手续费)

6.取款额度大于当次的限制

7.取款额度大于当天的限制

7.取款次数大于限制次数

等等

不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下(此处只列出了操作的步骤，略去了系统的交互中的反馈结果)：

1.插入卡->A:输入密码->B:按“确定”键->重复A-B

2.A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?单独的测试基础数据准备工作

将测试基础数据提前准备好，写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。测试用例的前后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

第三篇：软件测试工程师面试经验总结

首先说明我算上找实习的时候的面试总共就经历了不到5次，没有多少经验，就在网上和书上摘录了些我认为比较重要的，分享给大家，希望各位都能找到一份适合自己的好工作。1.笔试题

对于笔试，有的公司笔试题是不区分开发和测试岗位的，测试人员除了要掌握好测试的基本知识外最好也是有编程基础，具有尽量多的计算机的知识，像操作系统的基本知识（线程等），数据库的基本操作（增删改查，关联查询，授予权限等），数据结构的知识（像二叉树的前序、中序、后序查询）。2.面试

如果在笔试中没有考测试的基本知识，那在面试中是肯定要被问到的。面试前一定要做好准备，可以在网上搜一下关于这个公司的笔试题和面试题，以供参考。如果时间充裕可以找一本自己能看的进去的讲软件测试的书，认真的有侧重点的看看。软件测试的几个主要的阶段，不一定死记硬背能用自己的话说出来也可以或者能举例说明，那几个主要的白盒和黑盒的测试方法能熟练的应用到实际的例子中，等价类划分和边界值分析经常被问到。

每个公司做的项目都不一样，最好先了解下要应聘的那家公司主要是做哪方面的，比如对美外包的公司就要求英语水平，能看懂英文文档甚至能同外国人交流，最好能提前先看些英语的文章，准备下英文的自我介绍，临时提高下英语水平。

我被问到的面试题（答案仅供参考）

1.为什么不考研？

2.想要一份什么样的工作

3.做软件测试人员需要具备什么样的职业素质

（1）专业技能，包括测试的技能和开发的技能（2）积极的态度

（3）良好的沟通能力（4）细心（5）耐心

（6）团队意识 4.对他们公司的了解

5.再就是些工作地点能否接受，有没有男朋友之类的基本问题 以下是针对实习项目问的问题（答案仅供参考）

6.缺陷报告有几个状态，都包括哪些内容

状态：新建，打开，修复，关闭，重复的bug，无效的bug，被拒绝的bug，其他 内容：：标题、模块名称、项目名称、测试环境、重现步骤、期望结果、实际结果、严重级、优先级、发现人、接收人和附件（截图，说明等）。7.有一个文本框，只能输入0-5个字母的组合，如何进行测试 从字符串的长度考虑，按照边界值方法设计测试用例

从字符串的组成内容考虑，按照等价类划分方法设计测试用例 8.简单的说一下性能测试和压力测试 9.写过自动化测试的脚本吗

10.我实习的项目是一个金融的网站，技术的面试官问我，商品的价格是左对齐还是右对齐（对于这个问题我也不知道为啥会被问到，有什么具体的含义，猜想可能是判断我的项目经验是否真实）

下面是我网上摘录的一些可能被问到的面试题

1.您认为做好测试用例设计工作的关键是什么？

答：白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

2.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

3.谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面

4.什么是软件测试。

5.Alpha 测试与beta 测试的区别。

6.测试结束的标准是什么？

7.测试项目：杯子

需求测试:查看杯子使用说明书 界面测试:查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

国际化：杯子上的图案有没有触犯到某个国家或宗教的禁忌

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路公路航空运输

测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出：该期望输出需查阅国标、行标以及使用用户的需求 说明书测试: 检查说明书书写准确性

给大家提三个产品:1.手机 2.电饭锅 3.电梯

8.图书（图书号，图书名，作者编号，出版社，出版日期）

作者（作者姓名，作者编号，年龄，性别）

用SQL语句查询年龄小于平均年龄的作者姓名、图书名，出版社。

9.软件测试分为几个阶段 各阶段的测试策略和要求是什么

10.您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

11.请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程

12.您认为做好测试计划工作的关键是什么？

13.您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

14.测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？ 答：软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

15.为什么要在一个团队中开展软件测试工作？ 答：因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

第四篇：电气工程师工作经验总结

电气工程师工作经验总结

------------------

本人系2005年毕业的，专业是机电一体化，在一家轮胎知名企业工作。刚毕业的前三个月在该公司的各车间进行轮流实习，也让我第一次接触到了轮胎设备，看着眼花缭乱的设备动作和工人紧张的操作，心里默默的想着，自己到底分到哪，做什么工作，慢慢的熟悉了车间，熟悉了车间的技术人员，熟悉了他们所负责的工作，知道自己如果分到车间将会成为一名电气技术员。

可是面对斜交胎车间老掉牙的设备，半钢车间一流进口的设备，工程胎国产刚开始安装的设备，自己何去何从，虽然无法左右自己以后的命运，但我始终都在学习，在深入的了解设备，也许是因为自己那股虚心学习的劲头被领导发现，在各车间实习时就被各车间的领导看好，一度想把我留到他们车间，但偏偏被装备处室的领导看好，成为装备选拔的六人中的一人，当时看来形势一片大好。后半个月继续去模具车间实习，这个车间没有什么大型设备，只有几台洗模机和几台行吊，其他五人在这期间陆续的被调到装备，唯独我还在车间实习，找装备的领导询问情况，原来车间不放，没有办法，只得先暂时干下去，因为我是学机电的，并且该车间是新成立的，所以要负责设备机械电气各项工作，做备件计划，画图加工件，润滑，维修，检查线路所有的都由我来做，因为设备的自动化程度不高，动作也不复杂，所以真正在技术上学到的并不多，只有AB SLC的PLC，和欧姆龙200的PLC，而且我一直都在偏向于电气.但我学会了适应环境，学会了沟通，学会了自己单独思考解决问题，学会了用CAD画加工件，学会了指挥别人干活，学会了看电路图，学会了基本的PLC理论，学会了给别人安装电脑系统。一转眼半年过去了，到了2006年的3月份，也是我事业转机的时候.因为我们车间设备少，所以我喜欢在没有事的时候去半钢，全钢车间溜达，看看那里设备出现了问题，看他们如何维修，交谈之余才知道自己的工资太低了，还是700多。于是想到了辞职，想到了换工作，经我从前的车间实习师傅介绍，有机会到该轮胎公司的第二半钢生产基地去，拿是该集团的重点，据说全是进口设备，在辞职和该生产基地领导的大力推荐下，总于被跳到该半钢基地。

去报到时，设备还没有到货，面对巨型的车间，我又一次看到了希望，设备陆续到货安装，韩国，日本的压出生长线，荷兰，捷克成型机，德国的裁断机，韩国的硫化机，真的都是进口一流的设备，我当时就是专门负责电气，在设备的安装调试中，我有一次迅速的成长起来，AB 1756,西门子400，三菱的PLC，DEVICENET总线，PROFIBUS总线，ASI，伺服，变频，BST纠偏系统，LOGIC5000编程软件，STEP7,GX Developer，RSRSView Studio,PRTOOL触摸屏,各分布式模块，让我总感觉自己知道的太少太少，要学的太多太多。

2006.8月份设备陆续的交付使用，在操作工不熟练的过程中，也出现了各种各样的问题，开始分析解决问题的时间很长，慢慢的，慢慢的，自己的能力提高了，解决问题也不那样挠头了，各种设备编程软件也开始熟练掌握，把原来英文的触目屏界面纷纷改成中文版的，英语水平也开始在和老外的对活中慢慢提高，2006年年底被该集团评为设备管理标兵，一晃到了现在。水平提高了，工资却涨的太慢，现在才拿1600，所以感到了不满，付出和汇报不成正比。

第五篇：测试经验总结

1.测试人员和用户的联系与区别

黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。

八个字归纳：用户是用，测试是测。

用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。

应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。

2.带着问题去测试

阿猪工作守则第一条：带着问题去测试

测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。

3.测试期间提问题和交流的时机

什么时候应该提问题？

我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？

培训

培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。

阿猪工作守则第二条：培训时脑子灵活转动，多想多问

以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。

计划评审

提出对于软件不理解、安排的任务不明白的地方。

测试期间

这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此，影响测试流程和进度的问题,马上问！

不影响流程的问题，记下来统一问！

不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！

好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制

坏处（？）：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸

张等资源

阿猪工作守则第三条：先做事，后学习

在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。

要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。

但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。测试中期评审测试问题

答疑解惑的时间。

测试报告评审

对一些结论有疑惑和不解的地方，提！

4.记笔记

一个老生常谈的话题。

阿猪工作守则第四条：好记性不如烂笔头

测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。

养成一个良好的习惯，会使以后的工作更加顺利。

5.在公司和学校的学习的区别

学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。

学校 公司 备注

内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了

时间上 大块时间的连续学习相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课＋自学 培训＋交流＋测试过程中自学

个人觉得，一个高效的测试流程应该如下：

a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；

这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。

如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。

b.利用培训时间消化吸收的知识

c.软件上手

几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。

d.细测

主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：

50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。阿猪工作守则第五条：软件不是一次能测透的Rome is not built in one day.工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。

综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。

一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^

要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。

新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。评价自己是否可以转入下个模块的几个因素：自我提问与别人提问、测试进度

如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！NEXT-->转入下个模块。

否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。

e.小结

一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.f.性能测试

性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。g.安装盘测试

安装盘程序测试，简单过一下软件功能有无错误。

安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。

h.测试总结

测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。

5.小结

 用户用软件，测试测软件

培训时多想多问

好记性不如烂笔头

带着问题去测试，在测试中解决问题

 先做事，后学习，争取双赢

软件不是一次能测透的