第一个问题：需求不明或者需求不合理在很多公司，不同团队都有，需求不明，首先需要跟产品沟通下，确认需求，我们确认需求是在确认预期结果，所以只能产品给预期。需求不合理，首先清楚每个岗位的职责，QA 是对保证产品质量，也就是说最基本产品功能逻辑需要 OK，那这些都是根据 PRD 来进行测试的，所以当 QA（还是开发）对需求有疑问，或者不赞同的时候，通过沟通跟产品和业务，给出我们自己的建议，让他们接受你的建议，假如你的建议是合理的，而且是对产品的质量是有很大的改进的，假如产品跟业务不接受你的建议，你还是对自己的看法建议坚持，你可以找 QA manager，他会产品主管或者跟开发经理谈，通过上级去沟通。

第二个问题，首先清楚，QA 的工作是怎么量化的？BUG 数量是其中之一，那为什么不录入 BUG 系统？BUG 系统不止有 BUG 跟踪管理的功能，还是很多对项目开发有帮助的功能，而且 BUG 管理系统是可以作为以后跟开发有分歧的依据，各个 team 的老大都可以看得到，有记录可循，BUG 系统作用是很大的，不要简单理解。

第三个问题，项目一开始 PM 就会给出一个项目进度的时间表，什么时候需求评审，什么时候测试评审，都会有一个明确的时间点，那在需求评审还没有开始之前，你可能认为是一个 QA 的工作真空期，但是你确认自己在即将到来的测试工作需要的技能掌握好了吗？这个阶段可以作为你积累的阶段，至于你这个阶段提 BUG，还没进测，BUG 是不可能提的，清楚自己的工作，你提了开发也不会鸟你，可以以各种理由 reject。

第四个问题，用心，用心去看书，积累，才能积累到东西，想这里兼顾，那里兼顾，肯定会得不偿失。
综上所述，仅是给一个参考，其实我觉得根本原因还是自己不清楚自己的工作，没有给自己一个清晰的定位和规划。

• 是 bug， 是问题肯定提。
• 大小 bug 都要记录，可以不进 bug 系统，但是一定要记录，一定要让开发知道。
• 在没有基本框架的时间，也就是开发人员开发的时候，可以帮忙 code review，做做 BDD
• 很多时候，是流程的问题，改变不是一早一夕的，如果你的 leader 不想推动的话，那你就做点自己的事情呗。

#5 楼 @lihuazhang 前期开发还没有完成，发现的 BUG 可能在进测之后已经修复，当然记录是有必要的，BDD 和 code review 对于大部分测试人员来说难度大了，而且国内开发素质参差不齐，BDD 估计都很少人会了解，叫你 review code 可能不会。

#6 楼 @kevin_xu_v 谢谢你码那么多字来启发我。thanks

和我遇到的情形苟同

我很希望你能够认真的看我的回复。谢谢。

1、需求没有时，发现不合理的地方，这个到底算不算 bug？我提了会不会说我多事；不提，好难受，因为就是不合理，以后项目经理 PM 发现了肯定会问，我岂不是遭殃。

Monkey：从 bug 的定义来讲，不算。但是从测试人员本身来讲是需要提的。但是这个提并非就一定是要提到公司所谓的缺陷系统中，你可以和 pm 和 designer 一起进行讨论，再来确定到底是不是缺陷。我们始终要秉持一点，就是我们无论做什么都是为了推动项目产品往好的方向发展，而不是仅仅为了提 bug，或者为了不遭殃！

2、小 bug 是直接跟开发人员说，还是直接 QQ 或者当面说当面解决。录入 bug 系统麻烦，还浪费人力财力精力。

Monkey：必须录入系统。这个是一个测试人员最最最基础的行为。这个第二点我觉得你根本不需要考虑。

3、基本框架都没开发出来时怎么测试？尤其当需求也没有的时候，我测试也就是点点，其实连点点都不想点，1，开发们还在加急开发，不会搭理我；2,框架出来后还会去测试，现在测试重复测试，浪费时间和精力。

Monkey：首先这个问题分成两个。从项目的安排上来讲是需要测试介入吗？如果需要，那么如何介入？是 TDD 呢，还是用别的方法？如果可以点，那么就是某些模块的功能测试了。那么也是有一定的计划去测试的，如果你的测试任务就是要点点点的，那么你没有什么好疑惑的。如果是从项目角度来讲就不知道测试到底要做什么，那么你自己真的对于你要测试的产品了解吗？你真的对于你的技能那么有自信吗？如果不是，那么这个真空期你除了写测试用例，我相信你应该还有很多事情可以做。

4、当开发在工作，工作量不大的时候，我要做什么？此时，测试 leader 要求我先看看，第 3 条我已经说了，心想没有意义你让我点什么？！但是毕竟是领导，点点就点点，努力找找 bug（页面开发都没完全开发，找出 bug，开发说我刚要开发，你别急，这不扯淡的吗），汗￣□￣｜｜，一边还让我写用例，要用例评审，但是需求都不是很清楚啊，呜呜。。。 然后我还想自己看点自己的书，毕竟 IT 日新月异，而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了，不知不觉 1 星期，2 星期过去了，最后书也没看到，测试也没测试好。

Monkey：我不得不说，你有点好高骛远。是的，大部分公司的产品（至少我去拜访过的公司）都是枯燥无味的，如果你觉得你的 leader 或者项目中的安排有任何不妥，你可以提出来，我相信大家想把产品做好的话，只要有意义的建议多少都会采纳点。另外来说你的好高骛远，学习每个人都想学，但是真的就从你做的事情当中没有什么可以学的吗？难道就只有自己看点自己的书才能够学习了吗？如果是这样的话，无论你到什么企业，什么项目你都会是这样的心态。而且从公司来讲，做好自己本份工作才是第一的，你这样的想法根本就没有人敢用你

以上

我个人说实话，我从第一个问题回答到第四个问题，要我碰见你这样的，要么滚要么做，废话多什么。我的原则很简单，有什么不爽的，觉得自己是对的话，那么就说出来，去改变。论坛上诉苦没有什么意思的。

1

1.需求没有时，发现不合理的地方，这个到底算不算bug？我提了会不会说我多事；不提，好难受，因为就是不合理，以后项目经理PM发现了肯定会问，我岂不是遭殃。

发现问题就要提出, 不要过虑, 多跟队友沟通可以增加很多的了解, 沟通有助于你了解产品, 也让所有人目标更明确.这是个成长的过程, 所以不要闷着. 在质疑和挑战中会出现很多有价值的思想火花.

2

2、小bug是直接跟开发人员说，还是直接QQ或者当面说当面解决。录入bug系统麻烦，还浪费人力财力精力。

小 bug 要提的 需要录入系统, 当小问题逐渐累积的时候, 就会发现一些规律, 比如这些小 bug 的分类是如何, 属于什么方面的问题, 如何针对性的解决, 如果这些问题不录入系统, 将来也就没法发现瓶颈了, 包括你的 leader 也不能发现产品质量的瓶颈是什么, 是界面, 接口, 亦或者是需求不合理等等. 这些数据对公司评估产品发展是非常有用的.

3

3、基本框架都没开发出来时怎么测试？尤其当需求也没有的时候，我测试也就是点点，其实连点点都不想点，1，开发们还在加急开发，不会搭理我；2,框架出来后还会去测试，现在测试重复测试，浪费时间和精力。

你应该学学分层测试, 在各个层面都有测试点, 过早介入可以评估需求和理性和产品设计的合理性,可以开展 TDD BDD 和 ATDD. 也可以做更多的辅助测试的事情, 比如前期就尽量要求研发提供状态日志和监控, 需要提供什么样的接口才可以让测试更容易. 其实越往前, 对个人的能力要求越高, 所以这么早就介入测试, 你应该感到高兴才对.

其中现实中会越来越多的出现这种摸索式的开发方式, 希望开发直接提供个成品给你测试的方式是上个世纪的产物了. 拥抱变化, 学习敏捷和精益思想吧.

4

当开发在工作，工作量不大的时候，我要做什么？此时，测试leader要求我先看看，第3条我已经说了，心想没有意义你让我点什么？！但是毕竟是领导，点点就点点，努力找找bug（页面开发都没完全开发，找出bug，开发说我刚要开发，你别急，这不扯淡的吗），汗￣□￣｜｜，一边还让我写用例，要用例评审，但是需求都不是很清楚啊，呜呜。。。 然后我还想自己看点自己的书，毕竟IT日新月异，而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了，不知不觉1星期，2星期过去了，最后书也没看到，测试也没测试好。

前面回答了这个阶段是有很多工作可以做的.
关于学习, 这点我觉得你做的不够好啊,
因为就算工作很忙的时候, 我们也能抽出时间学习, 很明显你竟然还没有不忙的时候...
学习的方式也是多种多样的, 工作中也可以融入学习, 页面没完全开发完的时候, 模块代码, 接口都已经完备了. 这个时候就可以做很多的工作和学习了, 比如去读研发的代码, 学习部署, 研究接口调用关系等等. 测试的事情就更多了, TDD BDD ATDD, 估计你都做不过来的.
实践就是最好的老师和学习方式了

总结

你很有自己的态度和想法, 这点很赞. 不会像大多数人那样按部就班而不去思考其中的意义.
从问题中可以发现你目前还是新手, 很多你不了解的地方其实是有很重要的意义的. 多思考和解决你会进步很快.
实践是最好的老师, 希望你多珍惜这样的好机会. 工作和学校是两回事.出学校后就基本没有了那种上自习的机会了. 一切都是工作驱动的. 从工作中学习和成长才是最快的.

加油.
.

#10 楼 @monkey 你偏激了, 他只是个新手.一旦打开疑惑, 会进步很快的. 新人总是需要开导才行的.现在测试行业都是 90 后的天下了. 90 后有自己的思维方式.

#12 楼 @seveniruby 只是说的很现实，客观了点。至于将来是不是 90 后或者 00 后的天下，这个得看他们努力得程度了。

#13 楼 @monkey
#12 楼 @seveniruby ，
关于为啥不直接跟 leader 提出觉得不合理的地方，
1 是在快速开发的过程中，你提出些许建议，不会因为我的建议改变流程（也有我的建议只是很小或者很浅薄的原因），有的时候我提出建议，测试 leader 也说 “目前我们公司就这个情况，没办法”，而且有事情也是直接问开发，没有主动，测试很被动，我就觉得提出也没意思，也不再提了，就这么闭口了；2 是本人我也是内向的人，做事情是那种要有准备，不准备好就紧张的不得了，提意见这种事情，有几次就不错了，我的性格也令我很被动。我以后要逐渐改。
看了 monkey 的回复，我看一句，心里冷汗就滴一滴，确实自己很浅薄。
还有 seveniruby 的回复，很感动，多谢。
我觉得我发这个帖子还是很有用的，起码我内心得到震撼，这跟看别人的帖子是不一样的，就像是老师打屁股，打在自己屁股上才知道疼，疼是什么滋味，才知道继续前行。

以后少说话，多做事。

#14 楼 @jakewendao 我与其他人不同的是，只是接触这个行业事实太多了。我曾经一直说这样一句话 “测试在说别人看不起自己之前，先自己看得起自己”。也就是这个道理。只是对事不对人哈～～我和@seveniruby 以及@lihuazhang 他们反正正反都评论过，不能一味的只听赞美嘛，是吧

#15 楼 @monkey 是的，你们的话我都听进去了

我觉得这句话说的不对，少说话多做事，测试这个职位如果不说话会更加被动，这也就是为什么招聘测试的时候都需要沟通好些的原因。

这几个问题在我刚做测试的时候也都有过困惑的，从个人经历来看：
1、发现了需求 bug 是要提的，跟设定、se 沟通，自己理解错误，设定考虑不足都是有可能的，尽管刚开始开口有点困难，但只要秉着 “我在做正确的事情” 的想法，把问题说清楚了，最终都会发现:原来也没那么不好沟通，并且纠结也就消失了。
2、bug 录入有时候确实会话费一些时间，但却是很有必要录入的。时间充沛的就直接录入，时间紧的时候可以先 QQ 等报告给 SE，有空再整理录入。很多公司对测试的绩效是会通过 bug 数来评定的，bug 信息可以作为自己工作的一个记录，分析总结后也能让自己提高的更快。
3、测试对象的熟悉也是需要花费时间的，何不趁机好好熟悉一把呢，SE 没空搭理的话，可以先把问题记录下来，看他有空的时候再找他集中问下。其实有些时候 SE 不是不想理你，而是他自己正忙的焦头烂额，只是不想思路被打断而已。
4、工作中领导交给的任务，有时候确实是会让人模棱两可，如果有十足的理由说服领导这件事情没必要做，那你大可以找他谈谈，如果不行那最好还是说服自己的心情，想想看怎么处理这个任务比较好。关于学习：有些人用挤挤出来的时间做了很多事情，大多数人大把的时间纠结中度过，要不要做某件事情以前，重要的是先想清楚自己想做什么，想清楚了再去做。接受现在，不放弃努力，这就是我们要做的事情。
以上只是个人现在的一些感悟，希望能够与你分享。共勉

#18 楼 @saraben 好，大赞

都 2022 年了 和楼主几乎一模一样的现状