才上班一个月就独立负责测一个从 0 到 1 的项目，对于增长工作经验还是很幸运的。但是整个项目跟到现在总体感觉来说就是杂乱，无头脑，一直在干一些效率低的无用功。写了两星期的功能测试用例，到测试的时候发现压根没啥用，害。（我真的太菜了）但是写测试用例对需求的理解有一定的帮助，虽然过了两个星期需求的一些细节忘得差不多（沧桑），然后就到了测试环节，是所有的开发都很不喜欢看需求吗，这做的和产品的理念差别真的有点大吧。测试驱动开发串流程，领导还说主要功能能走通就行，emmmm 啥是主要功能，连起来就算？？？上个星期理解错误领导和产品对流程通的理解，导致这个星期又开始返工，真的绝了。能不能大家统一一下思想，具体要求是啥，我一个新人测试真的很懵啊。还有就是开发一会发一个包一会发一个包，我测个寂寞。。。。（吐槽到此结束，沧桑。。。。。。）
1.个人认为对于测试来说还是得充分理解需求，如果写测试用例方式不能很好的理解需求，还是得像做阅读理解一样，标注段落大意，抠细节
2.师父的经验是师父的，不要完全听她怎么说，她说的经验不一定适合我，每个人的做事方式不一样，按照自己的理解结合师父的经验，犯错是不可避免的
3.测试之前向开发问清楚能测了吗，不然就得做无用功，emmmm，新人也不能做无意义的工作
你们公司是外包吗，怎么看起来流程不是很规范。
公司流程混乱啊 测试么有准入标准啊 测试可控的事情太少了
只能说公司流程还有很大的提升空间。。。
问几个疑问：
1、测试用例有拉上开发和产品做评审，确保认知一致么？比如领导说主要功能能走通，哪些是主要功能，可以在用例里表确认下来，避免理解上的偏差。
2、测试之前向开发问清楚能测了吗 这个很奇怪，应该是开发确认能测了再提测给测试，测试冒烟通过就正式进入测试阶段，测试阶段发现的任何问题都当做 bug 进行记录，严重级别高的（比如阻塞流程导致无法测的）直接上升为项目进度风险告知整个项目组，一起想办法去解决。这玩意不应该测试问开发，而是应该开发主动告诉测试。
另外，进入测试阶段后，开发还会不断给新包是正常的。如果有建了 jenkins 自动打包的话，可以从 jenkins 构建信息里了解到这个包相比老包中间有什么提交，大概改了啥。回归测试时只需要测试有改动的地方就行，最后基本没啥 bug 了再做完整回归。
陈恒捷
回复
1.测试用例一直说要评审，然后到开始测了都没给我评审，就是我师父指导我改了好几稿
2.就是公司领导一直催，开发就像应付领导一样丢个包出来，领导不懂开发害
3.现在就是测试推动开发推进，我都坐到开发旁边一个一个指着让他改 bug 了呜呜呜呜
yuyu
回复
可以先了解清楚这个项目的目标，特别是质量目标情况。
时间特别赶的项目，一般质量要求会有所降低，甚至只要求能走通主流程便于演示。所以这种时候质量要求可以适当降低一些，只改影响主流程的 bug
开发一会发一个包一会发一个包
一：跟开发协商，每天固定时间发包，保证测试工作顺畅；二：隔离一套单独的测试环境，自己玩；
我都坐到开发旁边一个一个指着让他改
坐到开发旁边这个是常规操作，便于高效沟通。但是指着改的做法不是很可取，因为这样很容易让测试角色变成保姆，反而不利于提升质量。建议记录 bug，提出 bug，让开发修改 bug，开发自测，再做 bug 验证。