测试人员每天纠结，怎么办？
测试人员的纠结1、需求没有时，发现不合理的地方，这个到底算不算bug？我提了会不会说我多事；不提，好难受，因为就是不合理，以后项目经理PM发现了肯定会问，我岂不是遭殃。2、小bug是直接跟开发人员说，还是直接QQ或者当面说当面解决。录入bug系统麻烦，还浪费人力财力精力。3、基本框架都没开发出来时怎么测试？尤其当需求也没有的时候，我测试也就是点点，其实连点点都不想点，1，开发们还在加急开发，不会搭理我；2,框架出来后还会去测试，现在测试重复测试，浪费时间和精力。4、当开发在工作，工作量不大的时候，我要做什么？此时，测试leader要求我先看看，第3条我已经说了，心想没有意义你让我点什么？！但是毕竟是领导，点点就点点，努力找找bug（页面开发都没完全开发，找出bug，开发说我刚要开发，你别急，这不扯淡的吗），汗￣□￣｜｜，一边还让我写用例，要用例评审，但是需求都不是很清楚啊，呜呜。。。 然后我还想自己看点自己的书，毕竟IT日新月异，而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了，不知不觉1星期，2星期过去了，最后书也没看到，测试也没测试好。唉，其实我不想打酱油。。。打酱油。。。。酱油。。。油。。。。 软件测试，尤其是黑盒测试人员，大多数认为项目开发完毕才能介入测试。殊不知，不同的软件生命周期测试介入点不同；不同能力素质的人，测试的深度也不同。对于测试流程而言，个人一直主张从需求分析到上线前验收测试都要参与。Bug当然要提，尤其是有扯皮现象，有绩效考核，Bug多且容易忽略时。我们需要了解各种测试方法，在不同阶段应用起来。有问题总是好的，领导比我们更清楚项目组的问题，我们要做的是快速响应，努力提升自己。 1、当然提，同时强烈要求明确需求。测试就是要‘来事’,当然你的有理有据。你担心提了他们不高兴，是你底气不足；2、小bug前期就当面交流了，中后期走正式流程
3、这个时候不如熟悉同类产品，和产品经理及其它相关的同事交流
4、充电。 1、需求不合理，不一定要通过提bug的方式来解决。可以通过讨论的方式，了解需求设计的来龙去脉。
2、提bug有几点好处：（1）告诉开发有bug；（2）方便测试跟踪自己的工作；（3）统计数据，方便流程方法等的改进；
3、可以分成小模块，分批测试。
4、bug发现的越早，修复的成本越小。比如，可以多想想需求，或者看看代码实现，都是可以找到很多bug的。 1、需求没有时，发现不合理的地方，这个到底算不算bug？
跟项目经理/产品经理/需求分析人员沟通解决。有可能真的不合理，也有可能其实是合理的。
2、小bug是直接跟开发人员说，还是直接QQ或者当面说当面解决。录入bug系统麻烦，还浪费人力财力精力。
均可，具体选择根据你的领导要求来。你一定不能怕麻烦。
3、基本框架都没开发出来时怎么测试？
你可以写测试用例。或者随便怎么混混时间。。。
4、当开发在工作，工作量不大的时候，我要做什么？
按照你的领导要求的做。 基本框架都没开发出来时怎么测试？
框架没出来时，你对需求完全了解了吗？你的测试用例还可以完善吗？需求都没有出来，你可以了解测试环境啊，充电啊
当开发在工作，工作量不大的时候，我要做什么？
测试leader叫你看看是有道理的，你需要了解啥你想过吗？这时候发现问题其实是有意义的，记录下来，等正式测试的时候重点关注它和类似的问题，出现过问题的地方那说明开发是容易忽视的地方。要不然就直接发下好了，管他忙啥，等正式测试的时候再开始测试好了，我做自己的事情好了。
不明白为什么想读书，书却没有看成，不是有时间吗？ :lol 迷茫才会纠结 1.没事做的时候，就看看51testing测试论坛，长长见识。
2.在项目开发前认真了解下业务也是很有必要的。
3.bug虽小，还是要生成文档，或者有bug管理软件提交上去，这样有理有据，以后经理怪罪你没提，你可以给他拿出证据。
4.一定不要怕麻烦，一个团队要能形成合理有效的沟通，不要因为是新人就胆怯。
5.存电，就是要实打实的看书，练习，再看书，再练习，不是只有说说而已。 1.没事做的时候，就看看51testing测试论坛，长长见识。
2.在项目开发前认真了解下业务也是很有必要的。
3.bug虽小，还是要生成文档，或者有bug管理软件提交上去，这样有理有据，以后经理怪罪你没提，你可以给他拿出证据。
4.一定不要怕麻烦，一个团队要能形成合理有效的沟通，不要因为是新人就胆怯。
5.存电，就是要实打实的看书，练习，再看书，再练习，不是只有说说而已。 有事没事都来一下51testing论坛，哈哈 没事逛逛
页:
[1]
