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

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

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

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

也可以发送邮件至：Eds5146@163.com

（如有转载，请保留以上信息东敬谢）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.结语

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

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

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

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

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

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

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

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

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

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

扩展阅读：工作当中一些项目管理的心得体会

工作当中一些项目管理的心得体会

基本上，产品开发过程中的一些重大的关键问题，都是需要产品经理来拍板;至于拍板之前的种种沟通、权衡等，就要靠产品经理本身的“素质”了，正文开始：

“1人100个月完成的项目，不是100个人1个月就可以完成。”

项目管理是让项目活动中相互竞争的各类制约因素：质量、进度、资源、风险等取得平衡的艺术，同时也是平衡项目干系人的各种需要、关注和期望，带领不同的人朝着相同目标迈进的领导艺术。

成功的项目管理可以简单理解为：按时、在预算内+满足产品需求+满足质量需求地完成项目。以下是我对项目管理的一点体会记录。需求等级

视觉A：图片没有分享功能吗?

技术K：图片有链接转发分享、微博或邮件形式分享等多种分享，全部开发的话需要推延时间表。策划D：图片只做预览、下载已经足够了，暂时不做分享。

交互E：如果我们的用户是基于邮箱用户，图片的邮件分享还是建议做。

如果在前期产品需求文档中没有明确定义每个需求的优先等级，或者说项目成员对需求的优先等级没有明确的意识，可能类似的争论会时常发生在项目成员之间，每个人会基于自己对产品目标的理解来考虑这个需求是否要做，什么时候做，做到什么程度而产生分歧，因而增加项目推进的阻力。

所以在前期产品需求文档中，必须明确定义出每个需求的优先等级，需求的粒度可细化到每个大功能下的子功能需求，如：图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等;一般的需求等级划分：

深圳市宝安区西乡宝源路F518时尚创意园F4栋408室电话：0755-29558872传真：0755-29558862网址：

P0-Musthave：如果缺失，产品不能发布

P1-Shouldhave：如果缺失，产品能发布，但不能达到预定目标(功能/性能)P2-Nicetohave：做了则更好

P3-Neutral：对产品没有明显的好处，用户不在意

每个需求的优先等级确定之后，产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线，高于或等于这个等级分界线的需求在本期开发，部分根据成本、运营计划等因素调整到下期开发，而低于这个等级分界线的需求则只会在下期开发，这样让全体项目成员对本期要做的需求达成共识。需求等级的实际应用：

WBS各工作包Triage的参考基准之一;Triage即确定需求任务是否要做，是否要现在做的一个共同决策过程;在Triage的过程中，任务owner对自己的任务以及其他人的任务有更全局的认识。

Bug的Triage的参考标准参考基准之一(也是zerobug*注1和codefreeze*注2时间节点计算的参考基准之一);Triage即确定测试中的Bug是否要修，是否要现在修;如：在功能开发期间，P0、P1、P2及以上的Bug都要修;当进入接口冻结期后，只有P0、P1normal及以上的Bug才允许修，以保证优先的Bug问题更快地被解决。

*注1ZeroBug：当前不存在activebug，或不存在高优先级或特别严重的bug*注2CodeFreeze：除高优先级或特别严重的bug外，代码冻结不再接受提交WBS

技术K：相片上传的界面还没有搭建好吗?这部分我们需要先做起来。前端J：视觉设计师没有完成呢!

视觉A：我在做相片的展示页面，还没有做到相片上传。

项目各成员对自己需要负责的任务粒度细分不到位，每个任务的交付时间点不够明确，对任务之间的依赖关系也不够清晰，造成项目推进中的协作成本提高，项目时间预估准确率不高，项目控制的风险增加;

因此在产品需求文档确认之后，必须做工作分解WBS(WorkBreakdownStructure)，即把需求分解成较小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必须详细到可以对该工作包进行估算(成本和工时)、安排进度、分配负责人员或组织。项目经理、项目成员和所有参与项目的职能主管都应该参与WBS工作，根据项目规模情况，可以由项目经理或各模块主策划来组织。组织方负责召集有关人员，集体讨论所有项目工作，确定项目工作分解的方式后，各职能方提交各自的WBS，汇总后画出WBS的层次结构图。结构图中应包括每个工作包名称(内容定义)、指派人员名称、所需工时、可能的依赖关系等;WBS的工作包，最终以任务形式录入到QA中进行跟踪管理。WBS的好处：

深圳市宝安区西乡宝源路F518时尚创意园F4栋408室电话：0755-29558872传真：0755-29558862网址：

为资源、成本、进度、质量等控制奠定共同基础，确定项目进度和控制的基准;为各独立工作包分派人员，规定这些人员的相应职责，便于项目职责的落实和明确划分;

针对各独立工作包，进行时间、资源需要量的估算，提高时间、资源估算的准确度，并确定工作顺序，提高协作效率，利于更准确的制定项目进度计划表;

QA可视化项目管理

技术K：我完成到图片分享功能，图片下载的bug已经就提交上来了，但是我现在没有时间改bug。测试F：我已经提了一轮的bug了，但是我不知道bug什么修好，然后我可以去复查。交互E：图片分享功能开发完成了?可以测试了吗?

产品经理：现在大概还有多少P0的bug?zerobug时间节点是否需要后延?如果没有QA，项目的状况不是对每个项目成员透明化，就会出现以上的各种情况;

QA作为协同式任务管理工具，通过对每个任务的记录和跟踪，让项目成员对整个项目的情况有直观的了解，项目经理可随时监控项目推进中的风险是否在可控范围，并提前快速作出调整。

不管是前期开发的工作包还是后期的测试bug，均以任务的形式录入在QA里，然后对这个任务的一些基本属性做设置，如：属于哪个milestone、哪个模块等，然后由各个阶段的Triage的负责人按照需求等级标准来对任务作分类定级，并确定是否做，是否现在做;所有的任务都必须经过Triage并approve通过，才能开始工作。Triage的决策需要多个层面的知识(结合产品、技术、进度等多方因素)，特别是在大项目中，Triage往往是一项群体工作，以功能小组(featureteam)或产品决策组的方式来进行。在项目的不同阶段，可以由不同的角色来主导Triage流程。

在任务approve后，各职能方leader将任务指派给相应具体执行的人员。执行人员，也就是任务的owner，必须设置任务的Statusdate，如：Status任务状态是Working(进行中);Statusdate即完成日期点，Statusdate应真实反映实际工作计划，并应契合项目时间表。在执行人员完成任务时，QA会通知各职能方leader去关闭这个任务，关闭的意义在于通知任务的相关跟踪者，可以着手下一部分的工作，如某功能代码任务关闭，即相关测试人员就知道可以开始这个功能点的测试工作;

通过任务在QA系统里的记录和跟踪，以及任务状态的实时更新，最终会汇总生成各种可视化的图表，项目进展直观，且可度量，能够很好的把握整个项目推进的节奏，对项目中各项问题和风险定位更容易，并可在周会上对项目的所有成员公开进度信息，便于协调一致;其中最重要的图表：glidepath任务走势图：

深圳市宝安区西乡宝源路F518时尚创意园F4栋408室电话：0755-29558872传真：0755-29558862网址：

“实际任务走势”与“计划任务走势”的对比，可以衡量出计划与实际的偏差。每日构建

技术K：我们只在每个小milestone才会打build。

交互E：希望可以每日bulid，我可以每天拿到最新的版本进行测试。

测试Q：我建议测试前期可以每个milestoen打版本，但是中期开始，每日build。

每日构建(dailybuild)是指每天对整个项目做一次完整的自动构建，生成可执行文件的过程，对Web类产品，每日构建通常要伴随自动部署的过程，将这些可执行文件部署至测试环境，并按照一定的规则对这个安装包或测试环境做版本编号，是一种Publicbuild的管理方式。

每日构建是编译管理的一种方式，项目初期，可根据根据需要按照一定的频率打，如：每周、每个milestone，随着项目的进行频率逐渐增加build的频率，如：每天build。每日构建的好处：

每日构建让从产品经理、项目经理、策划、交互、视觉等所有的项目人员从第一个小功能模块完成开始，能够随时测试最新的版本提交bug，并能及时了解技术开发的进度;

每日构建让测试人员从第一个小功能模块完成开始，能够每天测试最新的版本，提交新bug和复查部分bug，而不需要等着某个小milestone或者所有的功能代码都实现了，再开始测试，大大增加了测试和开发的重叠时间，测试更充分，测试和开发的迭代效率更高，产品质量控制得更好;而且bug提交到qa上，也会一并附上build版本号，方便技术还原现场，更快地解决bug;

每日构建使得技术必须对每天自己输出的代码负责，一旦每日build失败，必须检查原因，并纠正不可再犯，以避免再次build失败，这样能非常有效地提高所提交代码的质量，减少bug的产生，加快开发效率;虽然搭建并维护dailybuild，需要比较大的工作量，但绝对物有所值。

文章来源：

深圳市宝安区西乡宝源路F518时尚创意园F4栋408室电话：0755-29558872传真：0755-29558862网址：

友情提示：本文中关于《测试工作中的一些心得体会》给出的范例仅供您参考拓展思维使用，测试工作中的一些心得体会：该篇文章建议您自主创作。

来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。

《测试工作中的一些心得体会》由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
链接地址：http://www.bsmz.net/gongwen/559201.html

• 上一篇：软件测试工程师试用期的心得体会
• 下一篇：合规大讨论心得