你跟我上一份工作的情况相同，最明显的区别是我有一个好的项目经理。我是说客户意见也是bug，和你在实际测试过程发现的bug是相同的，可以统一管理。我们公司也是开发更新程序，但我们建立了一个群。凡是开发有任何更新必须发群消息出来，测试员对更新情况做出记录。这样在一定程度上做到了版本控制，另外程序能不能提交给客户由测试员说了算（尽可能的）。

　　----------------------------------------------------------

　　liuygneusoft回复江潭素月

　　千里的回答很好，很明确，我再补充一点

　　（1）没有版本控制

　　之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳

　　是如千里所说，这工是配置管理员的专职工作，当前公司没配备，那我们只能从己有人员中想办法，谁最合适呢，当然是研发经理，也不要求正经八百的做配置管理，只是控制一下，什么时候发布下一个版本到测试人员那，或是定在每周五（多长时间，可以视情况定）发布一个新版本测试，这样也促使开发人员尽量在下一版本前修改优先级高的BUG，这对开发经理的要求也不高，我原来就这么做过，我来发布版本，连测试服务环境都是我来配置，我们是分布式环境。那测试人员如何去说服呢，首先不要让人地位低，其次要和经研发经理讲清当前做法产生的严重后果，你可以发邮件建议，并抄送他的领导，我上面的改进办法也不复杂吧，只是控制一下发布时间，把时间点当成版本。

　　当然我这是权宜之计，不过比没有强。

　　心态上也不要自认为测试人员地位很低，当然要证明测试人员存在的价值，就是用业绩和专业来反映；按我的理解，测试比开发人员更操心，开发人员，只管实现自己的业务，而不用向测试人员那样，通盘考虑。开发除了复杂系统外，MIS系统都是增删改查，很简单的。

　　（2）关于写测试用例

　　首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能

　　这时候不要再强调需求分析了，因为没有。我上一回贴说的测试需求分解，和开发的需求分析并不是一个东西，它只是定义了要测试的功能点有哪些。在没需求分析的情况下，你甚至可以，按功能菜单划化测试需求，并细化到增删改查功能点，这么做是为了好理清功能点，然后再这个测试需求分解的基本上来组纷测试，为什么我说要写用例呢，且是一边测试一边写，既然进入测试了，系统也有了，随着测试的深入，测试人员头脑中一定有业务，那为什么不一边测试一边补充呢，且有了那个测试需求分解，写用例时也能把握住，而不是随意的。这么做的好处是，可以慢慢积累用例，如中间有测试人员离职，也还有用例在.呵呵这是也是在做MYPM时加入BUG和用例关联功能的初衷。在测试期间，有空时（如，等待开发人员提交下一版本），也可以安排一定的时间写用例。

　　（3）关于bug的提交

　　您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低

　　关于这个，我前面没讲清，不同的时间段内，测试肯定是要有侧重点的，可用性的BUG不是说不能提，如果不经意发现的当然要提，我是想表达，不要有意去执行可用性测试，在功能没实现前。要不开发的会误认为，你发现不了什么BUG，尽提些不重要的。目标是把有限的时间，用到当前紧要的事情上。

版权声明：本文出自千里的51Testing软件测试博客：http://www.51testing.com/?180565

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。