关于测试部工作中遇到的若干问题及解决方案大全

第一篇：关于测试部工作中遇到的若干问题及解决方案大全

关于测试部工作中遇到的若干问题及建议方案

关于测试部在测试过程中所遇到的若干个问题，请相关领导和研发人员作参考，并提出建议。

1.关于提交测试申请单和样机不同步的问题。

关于申请单提交与样机接收不同步的现象一直存在，仍得不到很好解决，以致使测试往往不能如期（超期）的完成测试任务。

建议： 请相关产品负责人在提交测试申请单时与样机一起提交后，测试部负责人再接收。又或者相关产品负责人把测试申请单与样机一起先提交给测试人员。由测试部人员对申请单和样机核对正确后再提交给测试部负责人签收。相关产品负责人应对测试计划完成时间的填写进行客观评价。

2.关于样机在提交给测试部之前确认对产品进行基本调试的问题

此问题现象发生在所提交给测试部的样机，有时候出现相关产品负责人没有对其进行基本功能的调试，以致在测试过程中发现一些常见的不合格性问题，这样一来回进行再修改再提交测试，这样会导致工作的效率过低，形成一种依赖性。

建议：在提交样机之前，相关产品负责人应对产品进行一些基本的调试，对常见的问题进行及时的修改，这样得出来的效果就会事半功倍。

3.关于样机提交的数量问题

对提交产品数量的问题，有时候提交过少，导致出现是问题时无概率性，无对比性。理论来说要实行0缺陷的。所以建议按照产品项目验证方案所定的数量进行提交才签收（如无测试要求，测试部建议所提交的数量至少为3台）

4.关于测试过程中遇到的无规律出现，不常见的不合格问题。

在测试过程中经常遇到一些无规律出现问题（时有时无或出现的概率很少），不常见的问题，当通知相关负责人时，可能由于相关负责人没空而一段时间进行问题重现时就无法得出当时的结论。

建议：在发现问题时要及时通知相关负责人，相关负责人应尽量抽时间去分析解决（在测试部未能及时解决问题的根源所在时）。如果一段时间再进行问题重现时，这样既浪费公司资源又体现工作效率的问题。

5.关于测试不合格项不及时回复的问题

按照规定测试记录在发放后，不合格项回复应在三个工作日内完成，有时候相关产品负责人都对此不予以重视，测试部有出过类似的通知，得出效果不明显。建议相关负责人予以重视。

第二篇：业管理工作中遇到问题的解决办法

业管理工作中遇到问题的解决办法

1.当与开发商合同条款、管理处前期接管时的操作手段、发现的房屋设计缺陷等问题无法取得一致意见时，怎么办？:I 答：尽力沟通，可适当放弃部分次要要求，保证重要意见和建议达成一致。如确实无法取得最基本的共识，可采用两个途径解决：{Pm-1}依照开发商要求执行，但以不良事实性后果给开发商施压，使开发商自动妥协E2}取得公司高层帮助，在高层以上争取协调。@ 2．当管理处员工在工作中遇到较大困难与抗性时，怎么办？=T;答：首先分析抗性与困难，通过自己的专业能力和集思广益，设计几套解决问题的方法，并由自己在实际操作中实际演示，取得良好效果以增强其他管理人员的信心。q# 3．当管理人员取得良好工作成绩，暴露出自满骄傲情绪时，怎么办？c-©答：1}正向引导，通过单独的沟通，对该人员的能力结构进行分析，让其明白仍有很多欠缺，需进一步提高。j7 2}反向引导，加重工作量和扩大工作范围，布置部分人员力所不及的事。一定程度上让其产生挫折感，再通过单独的沟通使其清醒。Q(4．当管理人员之间因工作责任担负问题而发生冲突时，怎么办？d-$+ 答：首先制止冲突，然后按即定的岗位职责来处理相应发生的工作问题，如岗位职责存在一定的漏洞，必须马上及时调整，调整过程和处理过程应该是透明的，应该让整个管理处明白规则。GsQ 5．当一个平时与你关系较好的管理人员犯错误时，怎么办？d答：关系较好是私交，犯错误是在工作中，两者绝对不可合并考虑，为了维护公平、公正的原则，必须照章办事，该怎样处理就怎样处理。./'q 6．当一个平时与你关系一般的管理人员取得很大成绩时，怎么办？p@3jK ©答：同上一次问题，私交与工作不可混淆，应对该人员公开表扬和进行一定奖励。|pg 7．当一个管理人员连续一段时间工作能力未进步，工作情况较差时，怎么办？qy答：首先分析能力未有进步的原因：`G0D 1)本人不努力，对自身工作的钻研精神极度欠缺，列为调整对象，经过限定时间观察后调整。7-79[ 2]领悟力不够，不能举一反三，加大辅导力度，限定时间内作细致观察，若仍无进步仍需调整。^<, 3)仔细判断后认为该人员有实力、有潜力未发挥，处于瓶颈期时，应继续予以信赖、鼓励和支持，放宽一定的时限，期待一定的改观。QwF5@Y 8．当一个管理人员因个人客观因素情绪低落，精神不振时，怎么办？o" ©答：1)单独沟通，作思想工作，要求将主要精力引导到工作中去。Ht 2)必要的休假，使其精神放松。X ©9．当管理人员自恃经验丰富，成绩突出，不尊重你的决定时，怎么办？c ©深答：必须制止这种情况，必须要树立自己的领导权威，明确在会议上要求该人员严格执行，同时大力扶植其他有潜力的人员，形成竞争，让其感受到压力。95 ©10．当公司即定的对员工工作的种种奖励条件，迟迟不能兑现时，怎么办？ ©深答：1）稳定管理人员情绪，使管理处工作保持正常。W 2）向上力争，要求在限定时间内兑现。pgR ©11．当管理人员过份依赖于你来亲自处理各个问题时，怎么办？G]6H ©答：需要一定的勇气，宁可让某个问题处理的不是那么完美和及时，也要让管理人员充分认识到这个问题的危害性，使管理人员主观能动地学习并尝试处理各种问题的手段。)%#d ©12．当你休息或不在时，发生种种特殊情况，怎么办？maJv/ C答：1）预防：休息前一天准备工作有条理地作好安排，减少发生意外的可能。*o+? 2）放权：指定某人当天在授权范围内处理管理处各项情况。3）检查：电话检查，询问当日情况，并进行一定的指导。t*!©13．当你召开工作讨论会时，要求大家发表意见，而人人保持沉默时，怎么办？C ©答：会议气氛一定要轻松，形成讨论的要求之一是主持人要暂时淡出主导地位，由其他人员自由发挥，或在会前要求个别人员先作适当准备，以避免冷场。&c=O ©14．当公司制定的或许存在一定不合理现象的制度，确定要实施时，怎么办？_/J/ ©答：先实施，并且保持一定的弹性，在实施过程中整理意见和事实，迅速向上反应，阐述自己的观点，希望制度得以调整，努力避免在执行过程中，因制度的不合理性急剧地损害到下属人员的利益。1UwK6 15．当你急需公司各领导或其他部门配合完成某事时，对应方反应过慢，怎么办？[Gki ©答：横向合作建立在垂直管理的基础上，按正常途径逐级要求配合与帮助，但明确要求截止时间，在这一段时间中，对此事要进行跟踪催办。% 16．当你与公司管理部在新接管理项目定位，及采取的管理和服务方案等问题上无法统一时，怎么办？I 答：这些方案问题上一下子很难分出优劣，好坏，但管理处的情况毕竟是第一手资料，应坚持自己的观点，但注意表达方式应局限于方案可行性的讨论范围之内，仍无法一致，则将双方的两种方案上报，由上级决定取舍。l 17．当公司的新接管理方案即定，但现实可行性较小时，怎么办？Kv#0 ©答：公司的管理方案既定，作为下级只有严格地执行，并且要动足脑筋，设法使其可行，在做的时候尚需将客观事实向上反应，适度对管理方案进行调整，但对下仍需保密，避免管理人员认为管理方案是儿戏，可随时变化。Q 18．当管理处成员大部分无法适应你的管理风格时，怎么办？x ©答：1]反省自己的管理风格，优劣势在哪里，劣势能不能改变。]} 2）会议上坦率地谈这个问题，希望大家能够形成共识，以诚恳的态度表明自己的观点，即搞好管理处工作是重心中的重点，希望大家能够互相很好地合作，自己也将努力改变自己的缺点。$4O ©19．当前期接管时期内，管理处成员抱怨过于辛苦时，怎么办？tD 答：鼓励信心，现身说法，指出前期接管是管理处走向成功管理的必经之路，前期接管的辛苦是一种知识的积累，对自己的意志、品质也是一个难得的考验，同时检查前期接管的工作计划，如确实有工作量过大，任务安排过紧的情况，则作适当调整。73x ©20．当前期接管，业主入伙进入后期，管理处成员普遍出现身心疲惫的情况的，怎么办？tR,tq ©答：1)适度调整，使人员有一定的休整时间。g 2)信心鼓励，肯定成绩，肯定大家的努力，同时设定新的目标，使大家有新的追求。B9,I[s 21．当管理处成员因个人正当理由，与即定排班（调休时间）发生冲突时，怎么办？e0-©答：根据实际情况，如存在可调整性则予以一定方便，但必须告诉他，下不为例。2oHIa 22． 当管理处日常工作进入正轨，管理人员不思进取时，怎么办？4.K1^ ©答：不思进取无非是工作量减小，工作难度加大等因素，可通过加大任务来刺激，或通过奖惩

制度来激励。Ht © 23．当管理处工作步入正轨，管理处工作纪律松懈时，怎么办？3 © 答：可采用杀鸡儆猴的方式，提醒其余人员，振作精神。[tU z R24．当管理处人员情绪不稳定，有大量人员准备辞职时，怎么办？a 答：仔细分析每个人准备辞职的原因，为了支撑管理处的日常工作，必需对其中的一部分人员进行挽留，在挽留成功的同时，向公司寻求后备人员的支援，对态度坚决的辞职者，必经要求其将工作进行完整移交，保证正常工作的延续性。]#_ 25．当管理处内部拉帮结派，出现小团体时，怎么办？w{P?S 答：坚决制止这种现象，注意分化瓦解，小团体是因为共同的观点或利益而形成的，改变这部分人的观点或利益关系，另外，还可以通过人员的调动方式解决这个问题。pgos © 26．当管理处内男、女发生微妙感情时，怎么办？8W;Q ©答：此类事情比较敏感，在公司内部不宜过多宣扬，在没有明显证据之前，不能草率处理，保持紧密的关注，一旦产生影响正常工作的状况，需立即按公司有关规定妥善处理，最好采取低调，在处理后可暗示管理处其他人员引以为戒。

i27．当管理处工作人员突然陷入工作低潮期，信心不足时，怎么办？o/UvVq © 答：1）了解原因，突然的低潮势必和某些个人原因有联系，需要了解这些原因h i 2）鼓励信心，以以往的工作成绩来增强他的信心，使其相信自己是有能力的。}PPA 28．当管理处的部门主管处理部门内部事物不公时，怎么办？8h 答：如系确实的不公平，应对部门主管严肃处理，并拨乱反正，消除基层管理人员的积怨。32Ra 29．当管理处内两名管理人员出现恶性纠纷（争吵、打架）时，怎么办？O0# © 答：视情节轻重，予以处罚，必要时可提交人员淘汰建议报告，绝不姑息，绝不能让害群之马影响整个管理处的团结与相对稳定。cQ,r?: © 30．当某管理人员因悟性不足，无法提高自身基本管理服务技能，工作成绩不佳，但同时平常的工作又勤勤恳恳时怎么办？twdY_ © 答：对于勤恳而悟性不高的管理人员，要给多些时间锻炼，不要急于求成，假以时日，工作成绩应该会所有所突破。-© 31．当管理处内人员不注重合作精神，经常独善其身时，怎么办？!|(@` 新闻标签：

特别说明：由于各方面情况的不断调整与变化，教育人生网所提供的所有考试信息仅供参考，敬请考生以权威部门公布的正式信息为准。

第三篇：测试工作中的一些心得体会

测试工作中的一些心得体会

此文是在下从事测试工作一年以来的点滴心得和体会，一家之言或有不足之处，欢迎各位同仁批评和指导，大家也可通过百度空间或是搜狐博客给我留言：

也可以发送邮件至：

（如有转载，请保留以上信息——东敬谢）

1.测试需要一份测试指导书

测试前要明确测试目的。如：需要做哪方面的测试？具体进行测试的步骤有哪些？功能实现与否如何判定？哪些现象是允许的？而哪些现象是不允许的等等。

测试目的不明确会造成测试工作的混乱，因为测试并不是简简单单地得出一个结果——测试OK，产品可用。

产品凭什么判定可用？产品可用到什么程度？

凭什么判定测试过程OK（或是不OK）？产品完成了哪些功能？完成度有多高？产品没完成哪些功能？没完成体现在哪些方面？产品有哪些缺陷？缺陷的严重程度？等等诸如此类的问题才是测试工作的关键所在。

比如说开发一个台灯，我们都知道，台灯的重要功能是必须能照明，没有达到这个要求的产品一定是NG的。

但测试并不是说，你把台灯接上电源，开开关一看灯亮了，OK，这个产品是可以用的……

测试必须检测到跟重要功能配套的一些基本指标，如台灯的亮度是否可调？灯泡长时间工作发热量多大（如果使用的是钨丝灯泡）？灯泡的工作寿命是多久？等等。

如果灯泡开半小时，1米范围内的温度可以达到70摄氏度，哇，有哪个用户敢用这样的产品？这不叫台灯，应该叫取暖器，再比如灯泡的寿命是10个小时，用户每天使用4小时，不到三天就要换一个灯泡，这样的产品恐怕会被归入假冒伪劣类。那么，灯泡开半小时，1米范围内的温度应该是个什么标准？开一小时，两小时后温度应该是个什么标准？0.5米内，0.2米内，灯泡的温度又是个什么标准？灯泡的使用寿命必须大于多少小时？等等等等。

这些由谁来给？难道要让测试人员自己来找么？

假如上述指标都给了，测试过程中发现，开台灯工作两小时零三分钟的时候，台灯居然熄灭了，当你把这现象提交开发人员报缺陷的时候，开发人员告诉你，这是因为加了定时关断功能（或是加了温控开关，当发热温度过高时会自动关灯）

为什么测试之前不说？

如果是加了定时关断，用十个台灯进行检测，关断时间从一个半小时到三个小时的都有，那么是不是都是正常的？

不正常？那么正常应该是在什么时间？

又比如，开发一个遥控器，让人测试的时候不给一个键位表，问开发人员要的时候，开发人员回答——不会自己试啊！

好吧，我自己试，试过之后把功能自己做了一个表，提交给开发人员，问对不对？ 开发人员回答：你猜，你猜，你猜猜猜……

好吧，让我猜是吧，那我猜实际遥控距离只有1米也是正常的，就不告诉你。

有的人可能认为，测试就是让测试人员随便拿产品去用，把使用后的现象和结果记录下来，拿给开发人员这边判定就是了，不需要给出什么资料——这应该是用户体验测试，不是我这里所要说的，开发过程中的测试，再说了，就算是把产品卖给用户也得附上一份使用说明书吧，什么都不给就叫人测试，莫非是在考验人智商么？

测试工作是产品的一个求证过程，是对设计的一个检验，需要忠实，详细，有效地记录产品在测试过程中的现象（包括已实现功能，未实现功能，所存在缺陷等），并将信息反馈至开发项目组的一个必须过程。

测试的目的是为了验证产品的功能，性能，同时找出产品的BUG点，以完善产品的开发。就某种意义上而言，发现BUG点比验证功能是OK的更加重要，因为——你最好别指望客户或用户来帮你找BUG，否则代价会非常大。

如果一开始有明确的项目计划，清晰的产品需求，那么可作为测试工作的前期导入，但仅靠这些还是远远不够。产品的功能，性能，可拓展性，兼容性，安全性，稳定性，这些都是测试时必须考虑到，也是必须测试到的内容（除非没有相关方面的需求），很多东西并不一定能在项目立项时就能够考虑到就能够预判到。

举个例子，腾讯QQ我相信大多数人都用过，作为一款即时通讯软件，与好友及陌生人在网络上自由聊天是产品的重要功能，这个功能是必须的。

视频聊天和传文件是QQ的两个拓展功能，假如现在是在产品开发过程中，开发人员让检测这两个功能。

经过测试，视频聊天可在不同的两台电脑进行连接，在连接的时候，发起视频的一方在点击视频聊天后，会弹出一个确认框，问是否确认要给对方发视频——我们都知道，实际QQ上发起视频不会有这个动作，因为这个动作多余了。

但是假如开发人员没有给出相应的需求，测试人员完全可以判定这个动作合理，因为计算机软件在用户作出重要操作时，弹出对话框让用户确认的动作是很正常的。

又比如，在传文件的过程中，发送文件的一方点取消传送不能中断传送过程，只有接收文件的一方才能中断传送，如果是这样设计的话，发送文件的一方发错文件就很麻烦了，要么让对方取消，要么强行关断QQ进程甚至是强行重启电脑。

假如开发人员在事先没有提到要测试这方面的功能，测试人员很可能会忽略此点，主要去测试文件传输的速率，稳定性，出错率等等这些指标。

当产品快交付或交付后，发现这个功能缺陷，开发指责是测试的失误，居然连这个问题都没测试到，测试可以立马反驳——测试前你有要求过要测这里吗？然后就开始邮件，口水满天飞……

在这里，讨论谁对谁错毫无意义，重要的是，这样的情况其实是可以避免的。怎么样去避免？事先说清楚需要测试到的内容不就OK了？

作为测试人员，对于产品的测试需求，如测试方式，测试要点，测试重点等有自己的一套思路，但是，在测试之初他们并不是最了解产品的人，需要开发人员给出一定的指引，毕竟并不是所有产品的测试需求都一致，仅凭经验办事有时会走入误区，比如说：忽略掉很多本应该注意到的东西；对产品的BUG点判断失当；在不重要的测试点上花费太多精力，而在真正应该测试到的地方投入过小等。

做出太多的无用功不仅浪费时间，精力，也容易使人产生倦怠，影响之后的测试工作。就像蒙着眼睛瞎抓一样，根本不知道自己在干什么，不知道自己应该干什么，甚至不知道自己干的到底有没有作用——这样的工作状况恐怕是很多人都不能接受的。

所以，就跟产品开发需要一个项目计划一般，测试也需要一个测试指导。这份测试指导应该包括测试的目的，测试的步骤和预期的结果。

从测试人员的角度上来讲，由工程师直接附上测试指导书虽然省事，但是并不理想，最好是由测试人员根据产品情况，列举出值得检测的地方，主动向工程师请教，双方进行讨论后再决定测试内容——如果时间允许的话。

知其然也要知其所以然，才有利于更准确，更合理地进行测试，也有利于积累经验和技术，对于职业的长期发展是至关重要的。

请注意，测试人员不要养成一个非常不好的习惯，就是拿到待测试的样品后什么都不考虑，直奔开发人员那里索要测试指导书，拿到测试指导书后就照本宣科地进行测试，这是非常不负责任的行为，对于测试人员以后的发展也是非常不好的。

拿到产品之后先想一想，在没有任何资料的前提下先自己摸索一下这款产品的设计思路，预期功能，可能会存在的缺陷等，然后再对照项目组或工程师提供的资料进一步确认，在心中有个底之后再请教开发工程师，把测试内容给理解透彻——注意，记得要以请教的心态而不要以索要的心态。

2.产品的可用与否并不仅仅是由测试人员判定的如上所述，测试是一个求证过程，检验过程，是在已有的条件下做出各种尝试，以验证产品的功能点，并挖掘产品的缺陷点。

测试人员所发现的缺陷点，反馈到开发人员处后，有的或许能得到改善，有的则未必需要改善，还有的则未必能够改善——基于需求，技术，成本，市场等诸多因素的考虑，这是无可厚非的，因为开发并不是理想化的，不能因为缺陷点未改善而否决一款产品。

‘这个东西不行，这样的东西简直就是垃圾！’——作为测试人员，千万不要说出类似这样的，带有自以为是意味的话。测试人员并不能决定产品的可用与否，事实上开发人员同样不能决定，做出这个判决的应该是客户，准确点来说应该是客户的需求。

有一款迷你小音箱的产品，由于产品的定位是可以挂在钥匙扣上的，方便携带用的，所以结构上限制了产品的喇叭尺寸，也就限制了这款小音箱的音量和音质。

当时有两位客户对这款小音箱感兴趣，其中一个客户在看过产品之后，指出音箱音量太小，要改善。

于是工程师做出了改进，牺牲了部分音质，把音量给加大了一些，在改善之后我们又重新给两位客户寄出了样品。

提出音量太小的客户收到样品很满意，而另一位客户却很惊异地问我们，为什么这一次送样的音箱的音质变差了？之前的那一款挺好的啊。

说到这里大家应该都知道后续我们是怎么做的了——这款小音箱保留了两个方案，一款音量稍小，音质稍好；一款音量稍大，音质稍次些，然后不同的方案交付给不同需求的客户。

想想，如果在开发中将音箱交给测试人员来检测，测试人员该怎么判定？

这个方案的音量太小，NG；这个方案的音质太差，NG。

这样的判定合理吗？

本来嘛，这就是事实啊，凭什么不能这么判定呢？

偷偷的告诉你，开发任何产品，咱们说了不算，客户说了才算，除非这产品是为你自己开发的——如果是这样，你不就是这款产品的客户么？还是客户说了算。

发现缺陷点是客观认知，而否决产品通常是个人的主观意识决定的，个人的判断往往是片面的，也许你认为不能接受的缺陷在客户的接受范围内，反之亦然。

当然，如果缺陷点严重到已经影响产品的正常使用，已经违背了客户的需求，那么，这款产品理应做出改善，作为测试人员提交一份报告，表示产品并未达到项目计划的要

求即可。说出否决产品的话实际上也否决了开发人员所付出的辛勤工作，不管是有心还是无意。

可能很多人认为，测试就是质检，是产品流向市场之前的最后一道关口，不过，就我个人的理解，测试着眼于改善产品，是开发流程中一个不可或缺的过程，与质检不同的是，质检是根据指标判定产品是良品还是不良品，而测试是根据指标判定产品缺陷，反馈回项目组进行改善。

测试是开发流程中的环节，产品还未成型，改善产品是最重要的。

质检是生产过程中的环节，产品已经定型，控制出货良品率是最重要的。

对产品的缺陷进行追踪是测试人员的本职工作，至于缺陷是否需要改善，产品是否可以交付给客户或流向市场，测试人员可以提出自己的看法和建议，仅此而已。

3.测试要准确而详细地记录测试过程

测试是个很繁琐的事情，测试过程是非常考验人的细心和耐心程度的。

问题往往就发生在未知的地方——这句话并不意味着在已知的地方就不会出现问题。

有的测试人员可能会自持经验丰富，凭经验办事，这是测试工作的大忌！同样的用例，用在不同的产品上，判定的标准可能截然相反，不要想当然地凭感觉和经验办事。你可以参考之前的案例，但是每一次测试都应该当做新的测试来做，这样才能保证测试工作的准确性。

以下是我亲身经历的两次案例。

1.索尼的PS3主机有一次升级版本时，对未经过官方认证的蓝牙设备做出了一些限制，之前版本可以顺利使用的三款产品在主机升级版本后出现了一些问题。

问题现在已经解决了——这不重要，我这里想要说的是，这三款产品依照未升级的游戏主机来测试是完全没有问题的，如果我没有及时更新我的测试环境，还是以未升级的游戏主机进行测试，那就不会发现这些问题，等产品上线生产，或者是顺利出货到客户手上再发现问题，那么补救所需要付出的代价是非常大的。

2.有一款产品是用在PS3主机上的PS3手柄充电器，这款产品需要连接PS3主机上的两个USB接口进行供电。

在产品的使用说明书中特别强调了一点，使用时要先连接PS3主机上的USB接口，再将另一端的DC接头接入充电器。

为什么？因为如果先连接充电器，再连接PS3主机的话，充电电流很小，小到几乎可以判定为不能充电。

就因为先接这头还是先接那头，就能产生截然不同的两个结果，在接触这个案例之前我都没有意识到，也是在这之后，对于自己测试过程中的每一个操作步骤，每一个细节都留上了心。

细心一点，耐心一点，很多缺陷其实是可以被发现的。

准确地记录测试过程这点也许大部分人都能理解，但是详细地记录则未必都能做到。其实在有的时候，相同的输入，仅仅是因为操作的细微差别，就会导致产品输出不同的结果（其实这就是测试所要找出的问题点），当你记录的时候敷衍了事，发现问题再想回放问题的时候，往往会无处下手，不得不重新进行测试，这才是费时又费力。

小小地吐槽一下：测试工作真的很磨蹭人，如果不是对品质精益求精到有些偏执，如果不是极具耐心，非常注重细节的话，很难把测试工作做得非常到位。

有些时候就是一点小小的疏忽，就会错过一个或多个本应该被发现的缺陷，当缺陷在生产时或是在客户手上被发现的时候，作为测试人员心里并不好受。真的，就算没有

任何人指责你，只要你有一点职业操守，足够负责敬业的话，你会认识到那是自己的责任，任何辩解都是白费。

当然，就算再细致，也不能保证可以发现所有的缺陷，因为缺陷往往都是意料之外的，这点可以理解，但这绝不能构成你偷懒的接口，做好自己应该做的，尽自己最大的努力，不求事事如意，但求无愧于心。

4.测试要对结果进行反复验证

作为技术开发人员，严谨是非常重要的一个工作态度，而作为测试人员，更是要以此作为自己的工作准则。

测试是要得出一个结果，但是得出结果并不代表测试就完成了。在交付这个结果之前，先要确认结果的正确性，准确性，否则并不能算是一次成功的测试。

虚假BUG这个词是指提交的BUG本身就不准确。

为什么会出现虚假BUG？

并不是测试人员有心弄虚作假，也不是测试人员小题大做，毕竟没有哪个测试人员会拿自己的饭碗当赌注，用这样的手段来哗众取宠，又或是存心折腾开发人员。

虚假BUG的产生除了测试人员本身的经验和技术问题外，最大的原因就是没有对BUG进行反复验证。

测试过程中就算再细致，测试结果也未必能百分百准确，尤其是仅对单个产品进行单次测试，一旦测试过程中出现少许纰漏或是意外，测试结果与正确结果往往会相差十万八千里。要想避免或是减少因偶然或误差而出错的几率，多次验证是最佳的办法。

我们都知道，抛硬币出现正面与反面的几率均是50%。如果你拿一个硬币抛一次后，假如出现正面，你能说抛硬币出正面的几率是100%么？

假如你还是做上面那个测试，你抛了两次，都出现正面，你能说抛硬币出正面的几率是100%么？我们知道，其实抛两次都出现正面的几率是50%*50%=25%，好巧不巧你碰在这25%上了，抛硬币100%出正面是你测试得出的现象，却未必是正确的结果。

要想验证上述抛硬币的几率，最好的办法就是反复多抛，因为当你抛的次数越多，因为偶然性导致的偏差就会越小，当你抛硬币抛50次，一次反面都不出的可能性微乎其微，比你买一张彩票就中500万大奖的概率还要低得多。

当然，反复验证并不是说要你每一次测试都要十几二十次以上。根据实际情况，在觉得有疑问或异常，或是出现缺陷的地方验证个三五次，如果还是没把握再加测几次，确定结果无误，且可以准确进行现场还原后，即可提交至开发人员进行改善。

5.测试人员的自我定位

一切以客观事实说话——这是测试人员必须遵守的工作信条。耐心，细心，严谨是测试人员必须具备的职业素质。

测试人员千万不能说出类似‘这个东西是个垃圾’这样自以为是的话——如果产品没有缺陷，那还要测试人员来干嘛？测试人员就是为了缺陷而存在的，当然，验证产品功能的实现也很重要。

任何一款产品在开发之初都会有或多或少的缺陷，把它们找出来是测试人员的职责，但要留意，不要陷入任何不合理都是缺陷的怪圈，与开发人员及客服人员沟通，了解产品和客户的真正需求，不要自以为是。

测试人员也千万不要因为能找出产品的缺陷而洋洋自得，自以为比开发人员高端，因为主观及客观上的原因，开发人员并不能很好地从自身的角度来审视产品，所以才需

要有专门的测试人员对产品进行检测，作为测试人员应该尊重开发人员，以及开发人员的劳动成果。

人与人之间是需要相互理解，相互尊重的。不管技术谁高谁低，测试人员与开发人员是处于一个互通有无，互补互助的地位。测试人员不必看轻开发人员，以为对方总是处处漏洞；开发人员也不必看轻测试人员，以为对方总是拾人牙慧。

作为测试人员，还要有自己的底气，要有自己的坚持，这份底气和坚持从何而来？就从你准确而严谨的测试报告中来，只有你自己做到了，做好了，你才能直面别人的追问和质疑，用不卑不亢的语调回答：是的，事实就是如此，我现在就可以演示给您看。

如果你本身就是错的，那要别人如何信服？

作为测试动作本身，并不会对已存在的产品做出任何变更，变更是开发项目组的动作，如果力所能及的话，测试人员可以在测试报告后附一份缺陷改善方案表，以便于开发人员改善产品，但是改善（变更）必须由开发人员来完成——因为这是开发人员的权利和义务。

6.结语

测试工作并不是像很多人所想的那样，是个卑微的工种，是被开发设计人员排挤在外的没有多少技术含量的职业。

其实测试的这个过程是很重要的，根据产品或是企业侧重的不同，测试人员的地位和要求都不一样。

如果可以，在技术上测试人员能够优于开发人员最好，对于发现的缺陷能自己找到原因并提出改善意见，那么缺陷的处理将会非常的迅速，在产品开发流程的质量控制环节可以起到主导作用，产品的质量也能得到很好的保证。

——敢于投入如此大成本于质量控制，将测试优先于开发之上的，恐怕只有那些行业拔尖，且对产品质量精益求精的企业才能做到。

这也是测试工作的极致……是的，真正对产品质量要求很高的话，测试在整个开发流程中应该占据很大的比重，而对于测试人员的专业和技术要求甚至比开发人员还要高，据说国外的某些高端技术企业都是把顶尖的开发人员转到测试岗位用。

或许这也能从一个方面反应出，为什么国内大多数企业的产品质量都比不过国外的企业，因为对于产品的质量控制，对于人才和成本的资源搭配不一样，所以结果自然也就不一样。

如果测试人员技术方面稍有欠缺，不能自行查找原因和提出改善，那么应该加强自身职业上的技能，力求与开发人员做到互补，即把验证流程做到准确，高效，并与开发人员保持良好的沟通氛围，一起为完善产品的质量而努力。

测试是个体力活，也是个技术活，更加是个折磨人的活计，不但枯燥，烦躁，也很容易让人暴躁。然而，只要你能够从种种不顺心的事情中脚踏实地地慢步前行，你会发现突然之间，很多问题都不再是问题，不管生活上的，还是工作上的。

这是从事测试工作一年以来，最大的收获。

最后再重申一遍：耐心，细心，严谨，加上务实与勤奋，调整好心态，相信自己，你会把这工作做好的。

第四篇：ICT测试常见异常解决方案

ICT测试常见异常解决方案

一、当测试员把ICT治具装好后,发现测试不良连续2 PCS以上应首先检查：

1、ICT程式是否选用正确，确认是否有升版，ECN，重工单，暂代料等；

2、排线是否插正确，对号入座；

3、所测试PCB板是否曾经过功能测试而没放电的板子，如没放电则烧坏ICT开关板；

4、ICT压床是否完全压到位，检查ICT气压是否在4—6Pa之间。

二、零件不良：

1、查看所有不良零件测试的高低点的位置是否有许多相同的，相同：A、则寻找相应有排插是否良好后再重新插好；

B、寻找相对应的探针是否有异物、氧化、变形、断针等。如有则清理好及更换新探针。不同：A、小电容&热敏电阻受温度影响，其测试值偏低，应加强冷确方法；

B、个别零件测试不稳定，及时通知ICT工程师进行调试。

三、短路不良：

1、ICT治具护板上以及各探针之间是否有锡渣，铜丝等。应及时清理好；

2、ICT治具底部针套是否有被压断（出现开路不良）压弯倒一起（出现短路不良）；

3、若是相邻两点短路不良，检查针点是否变形或靠在一起，见意换成小尖针。

四、开路不良：

1、算出相应针点的排插序号（用开路针点号除以32，有小数点都进1位，如100/32=3。125 就是第四号排线。）重新插好。多次插拔仍开路，则用ICT探针笔测试其排插是否为良品,如不良排线进行更换；

2、检查其针点表面是否有异物，探针是否完全陷下去，已失去弹性等，应及时更换探针。

PS：如果以上问题没有能够及时解决，请尽快找ICT工程师进行处理。测试员不能擅自改动ICT测试程式。

第五篇：测试部年终总结

测试部年终工作总结

光阴似箭，岁月如梭，一转眼，我来到英特华已经九个月了，在这段时间里，我们公司从没有测试人员，到测试部的建立；从没有测试环境到测试服务器的建立，测试工具QC、性能测试软件LoadRnner的安装使用；测试部规章制度的建立-----测试流程、测试规范、bug等级制度的建立、测试报告模板的建立、QC使用手册的书写等等； 在这近九个月工作中，我们测试部苦过、累过、紧张过。但这一切最后都被成功的喜悦所代替，我们测试部也就是在这苦中、累中、成功、失败中一步步成长起来。

2013年5月，我来到英特华，在李经理的指导下负责测试部的组建、部门制度文档的建立、安全测试软件的研究、盘点机系统的测试、新订单系统的测试等工作。

虽然测试部在2013年中取得了不小的成绩，但是还是存在很多不足，比如新订单系统的长期测试，工期长期推延，迟迟不能结束！这是测试部在下一年要重视的地方，要认真总结的地方！

下面是这一年测试部遇到的重大问题及原因与对策：

1.新订单系统的多伦测试后还不能封版完工

原因：

1）1级bug太多，严重影响阻碍测试的进度（尤其是报黄页的bug）；具QCBUG管理系统统计，新订单系统中bug总共209个，一级竟然有109个之多！

2）存在拆西墙补东墙的严重现象（很严重）

原来好的没有bug模块，由于修改bug重新出现缺陷，出现拆西墙补东墙，bug循环出现，杜绝bug遥遥无期！

3）软件开发基本定型后，还在修改数据库结构，修改底层代码！

4）软件开发基本定型后，还在修改需求！

5）开发人员不按照需求开发软件；开发出来的模块或功能和需求有出入

6）部分模块需求在测试快结束后，需求还没出来，开发人员在等需求！（如新订单系统中的利润表模块）

7.）测试人员不足；软件模块太多，测试周期长！

对策：

1）检查：对于1级bug太多，只要开发人员开发出的模块后或修改的bug后自己先走查一下流程，看看流程是否能走通，是否还报错，这样就能确保一级bug出现的机会大大减少！

2）开发人员在修改bug之前一定要认真先想一下，我这种修改方法会不会给其他模块带来bug？会不会影响其他人员的模块出错？然后在下手修改代码！

3）一旦所有人进入全面开发软件后，数据库和底层代码就不能变动！

4）一旦进入开发阶段，需求就不能再随意增加变动！

5）开发人员严格按需求开发项目，不能私自变动开发；如有变动需要，要所有部门领导在一起商量，并下发通知商量后的结果！

6）要做到在写代码之前需求必须全部写完！

7）大型项目，测试人员必须配足，岗位齐全，从而缩短测试周期，一个人的精力与技术经验必定有限！

下面是展望2014

丰收的2013已经过去，让我们迎接展新的2014！

2014努力的方向：

为了公司开发软件的质量与专业，我们测试部要往更高层次发展，这就要吸收更专业的白盒测试人员-----性能测试工程师、安全测试工程师！

2014测试部要努力增加的岗位人员：

一名功能测试人员

一名性能测试人员

一名安全测试人员

2014年测试部需要的物理资源

一台做压力测试用的物理服务器（可以用一台配置好的pc机代替）—— 一个专业的，准确的性能测试需要模拟接近真实服务器的干净的环境！虚拟机的各项性能还是和物理机的性能是有很大区别的，并且虚拟机上已经装了很多的服务和软件，环境不干净，影响真实的性能测试结果！

2014年测试部的工作目标：

电商俱乐部CRM系统2014年3月之前完成测试工作 ERP-产品系统2014年6月30日之前完成测试工作 ERP-采购系统2014年8月25日之前完成测试工作 ERP-仓储系统2014年9月30日之前完成测试工作 ERP-物流系统2014年11月5日之前完成测试工作 ERP-订单系统2014年12月10日之前完成测试工作 最后感谢领导和各部门的同事对测试部工作的大力支持！

测试部：张兴升