此文是在下从事测试工作一年以来的点滴心得和体会，一家之言或有不足之处，欢迎各位同仁批评和指导，大家也可通过空间或是搜狐博客给我留言：
此文是在下从事测试工作一年以来的点滴心得和体会，一家之言或有不足之处，欢迎各位同仁批评和指导，大家也可通过空间或是搜狐博客给我留言：
也可以发送邮件至：
如有**，请保留以上信息——东敬谢）
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. 产品的可用与否并不仅仅是由测试人员判定的。
如上所述，测试是一个求证过程，检验过程，是在已有的条件下做出各种尝试，以验证产品的功能点，并挖掘产品的缺陷点。
测试人员所发现的缺陷点，反馈到开发人员处后，有的或许能得到改善，有的则未必需要改善，还有的则未必能够改善——基于需求，技术，成本，市场等诸多因素的考虑，这是无可厚非的，因为开发并不是理想化的，不能因为缺陷点未改善而否决一款产品。
这个东西不行，这样的东西简直就是垃圾！’—作为测试人员，千万不要说出类似这样的，带有自以为是意味的话。测试人员并不能决定产品的可用与否，事实上开发人员同样不能决定，做出这个判决的应该是客户，准确点来说应该是客户的需求。
有一款迷你小音箱的产品，由于产品的定位是可以挂在钥匙扣上的，方便携带用的，所以结构上限制了产品的喇叭尺寸，也就限制了这款小音箱的音量和音质。
“双提升”学习中的一些心得体会
集团公司启动基建期 双提升 活动以来，筹建处工程部全面贯彻落实活动指导思想，以对标管理为抓手，分析基建期常见问题做好预防 以收集各专业意见想法为切入点，多次组织专题学习讨论。作为一名刚来筹建处不久的工程部成员，在 双提升 学习的过程中受益匪浅 收获颇丰，针对热控基建工作的几个重点内容，有一些心得体会...
新课改物理教学中的一些心得体会
一 新课改要重视控制变量法，在科学 中的运用和理解。所谓控制变量法，就是只研究一个物理量和另一个物理量之间的关系时，要保持影响这个物理量的其他物理不变，从而研究这个变化的物理量与要研究的这个物理量之间的关系，这种研究方法称为控制变量法。我们在需要用控制变量法解题时，要注重理解 控制什么，改变什么 如...
听课的一些心得体会
听了几位优秀教师的展示课，几节课的共同特色 从教材出发 进行再加工，并且较好地体现了教材特色，从情境出发 提出问题 利用已有知识经验解决问题 得到新知识，充分体现了数学化过程 建立数学模型过程。每一节课上，我都被教师所营造的流畅 和谐的课堂所感动，也从中学到了很多，虽然有些教师也出现了这样那样的失误...