内容来自千里和我在 51上的回复 我在51上身份这下暴露了 liuygneusoft
http://www.51testing.com/html/50/n-228850.html
原问题如下： 说下从事[url=]测试[/url][url=]工作[/url]近一年来，测试工作中的问题，希望能得到千里兄的指点
一，先说下我们公司的测试流程
公司有测试人员只有2个。如果开发人员有需要测试的程序，给测试人员打个招呼，然后测试人员将源代码从服务器上迁到本机MyEclipse，然后部署运行，进行测试。如果发现有[url=]bug[/url]，提交到bug管理工具mantis中，开发人员访问mantis，修改Bug，提交代码，测试人员更新代码，复测。
不知道是否有公司是这样的测试模式，可否评价一下这样做有什么问题。
目前发现的问题就是：（1）不写[url=]测试用例[/url]，想到哪测到哪，测试很难将功能 点覆盖全面（2）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低。目前公司开发人员修改bug的效率就特别低，而且修改Bug引起新的Bug 的产生，拖拖拉拉，测试最后不了了之，也不知道什么时候测试结束，怎么算是测试结束，也许有人会说bug都改完不就是结束了吗，但是不可能，很多Bug存 在争议，测试人员认为改，开发人员认为不用改，领导也不管
二，关于什么样的问题该提交bug
网上讲测试用例时，讲到用极限值、在输入数字的地方输入字母，但是这样测出来的问题，开发人员很反感，他们不愿意修改这样的问题，只想修改正常操作出 现的问题，甚至他们的主管也是这样认为，认为客户不会那样操作，让我们测试人员很苦恼。我们应该怎么界定需要提交的Bug呢，按主管说的？还是按网上讲到 的方法？网上讲到的方法吧，倒是能锻炼自己，但老是看他们的白眼，认为我们是做无用的工作
----------------------------------------------------
liuygneusoft回复江潭素月
（1）测试流程存在的风险
没有版本管理，会导致[url=]其他[/url]工作会很乱，另外会增加测试人员工作量，测试人 员的工作变成没计划，没管理。比如新发现的BUG，无法去分析，是不是修改带来的，还是这BUG是原来就有，只是没测试到。为什么会增加测试人员工作量 呢，开发人员只要改代码，就会提交到SVN中，频繁的这么更改，测试轮次就会乱，且容易助长发人员，自己修改后不测试，就扔到测试人员手中，在我们公司这 就private build ，测试人员不能没完没了的给开发人员帮private build测试，只有特殊情况下才用，在你们这，感觉就是在做private build的测试，不是[url=]系统测试[/url]。
（2）不写测试用例，想到哪测到哪，测试很难将功能点覆盖全面
先做好测试需求分解，细化到每个功能点。可以一边测试一边补充测试用例，具做法是，每写一个BUG，就现写一个用例并与这BUG关联。另外最后是，写BUG时，BUG要和测试需求关联。
（3）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低
根源还是没有版本管理，有了版本管理，从BUG的发现版本和修复版本，就可以看出来了，有了版本管理，开发人员也不可以改一个BUG就发一个新版本。发版本最多一周发一次；关于存在分歧的BUG，一定是要由开发经理来仲裁的。
另外，还可以从测试管理工具中，统计分析提交BUG曲线，和未修复的BUG曲线中，分析效率，如果说发现的BUG越来越少，但未修复的BUG越来越多，说明是开发人员修复BUG太慢。
（4） 关于什么样的问题该提交bug
我的意见是，测试时你要有测试策略，针对系统的不同阶段，要有不同的测试重点。系统功能都还没稳定时，不要去做可用性测试，这时你提交那些，可用性问 题，开发人员会有情绪的。在实现要求的功能后，再考虑，非功能性需求。比如还在集成测试时，你提校验的问题，开发人员会认为你尽提些无关重要的BUG 。
----------------------------------------------------------
江潭素月回复liuygneusoft
首先，谢谢您的指点，仔细分析了我们工作中的问题。但问题是我们该如何改进呢？
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户 看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功 能
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
-------------------------------------------------------
千里回复江潭素月
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
--如果你了解配置管理的话，你应该会知道这是项目管理的工作，也就是说这是项目经理的活儿。不过这部分工作量确实非常大，我上一家公司也曾碰到了版本控制的麻烦，项目经理也在考虑版本管理，最终因为没人可做这部分工作而一直搁置着
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户 看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功 能
--这部分工作首先要认可是测试员本份的工作，如果是不会做可以理解。这里提到的需求分析是将用户需求抽出成功能点，然后再将功能点具体实现为用例。当然你的问题也存在一定程度上面的需求环节不规范性，只要对客户意见和测试员bug进行了统一管理，情况会相对好一点。
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
--这里涉及到一个缺陷不修复的问题，哪些缺陷可以不修复呢？其实还是能够找到相关答案的：1.确实不是bug的；2.修复的代价太大；3.缺陷本身并不严重，但修复需要很长时间；4.缺陷被暴露的概率非常小，就算被暴露了影响也不是致命的。
-------------------------------------------------------
江潭素月回复千里
我们往往在这样的bug上存在争议：出现频率很高，只要运行程序就出现。但不是致命的bug，不影响功能，修改起来也很比较容易。不属于你说的那几种不修改Bug中的任何一种
例如打开一个页面时，只是在左下角报脚本错误，功能照样用。像这样的Bug，开发人员心情好就改，心情不好就不改。
我们测试人员对于这种bug是倾向于修改的
关于写测试用例，你说“对客户意见和测试员bug进行了统一管理，情况会好一点”，没有听明白，在我们这种情况下，该如何做测试用例的工作
---------------------------------------------------------
千里回复江潭素月
对于问题较严重，开发都很随意的，领导也不管的。我的做法是把问题以邮件的形式反馈给开发并邮件抄送一份给领导。同时把要不要修改的权力交给领导并暗示他，如果是谁说的不改以后出了问题谁来承担责任。
你跟我上一份工作的情况相同，最明显的区别是我有一个好的项目经理。我是说客户意见也是bug，和你在实际测试过程发现的bug是相同的，可以统一管理。 我们公司也是开发更新程序，但我们建立了一个群。凡是开发有任何更新必须发群消息出来，测试员对更新情况做出记录。这样在一定程度上做到了版本控制，另外 程序能不能提交给客户由测试员说了算（尽可能的）。
----------------------------------------------------------
liuygneusoft回复江潭素月
千里的回答很好，很明确，我再补充一点
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
是如千里所说，这工是配置管理员的专职工作，当前公司没配备，那我们只能从己有人员中想办法，谁最合适呢，当然是研发经理，也不要求正经八百的做配置 管理，只是控制一下，什么时候发布下一个版本到测试人员那，或是定在每周五（多长时间，可以视情况定）发布一个新版本测试，这样也促使开发人员尽量在下一 版本前修改优先级高的BUG，这对开发经理的要求也不高，我原来就这么做过，我来发布版本，连测试服务环境都是我来配置，我们是分布式环境。那测试人员如 何去说服呢，首先不要让人地位低，其次要和经研发经理讲清当前做法产生的严重后果，你可以发邮件建议，并抄送他的领导，我上面的改进办法也不复杂吧，只是 控制一下发布时间，把时间点当成版本。
当然我这是权宜之计，不过比没有强。
心态上也不要自认为测试人员地位很低，当然要证明测试人员存在的价值，就是用业绩和专业来反映；按我的理解，测试比开发人员更操心，开发人员，只管实现自己的业务，而不用向测试人员那样，通盘考虑。开发除了复杂系统外，MIS系统都是增删改查，很简单的。
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户 看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功 能
这时候不要再强调需求分析了，因为没有。我上一回贴说的测试需求分解，和开发的需求分析并不是一个东西，它只是定义了要测试的功能点有哪些。在没需求 分析的情况下，你甚至可以，按功能菜单划化测试需求，并细化到增删改查功能点，这么做是为了好理清功能点，然后再这个测试需求分解的基本上来组纷测试，为 什么我说要写用例呢，且是一边测试一边写，既然进入测试了，系统也有了，随着测试的深入，测试人员头脑中一定有业务，那为什么不一边测试一边补充呢，且有 了那个测试需求分解，写用例时也能把握住，而不是随意的。这么做的好处是，可以慢慢积累用例，如中间有测试人员离职，也还有用例在.呵呵这是也是在做 MYPM时加入BUG和用例关联功能的初衷。在测试期间，有空时（如，等待开发人员提交下一版本），也可以安排一定的时间写用例。
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
关于这个，我前面没讲清，不同的时间段内，测试肯定是要有侧重点的，可用性的BUG不是说不能提，如果不经意发现的当然要提，我是想表达，不要有意去 执行可用性测试，在功能没实现前。要不开发的会误认为，你发现不了什么BUG，尽提些不重要的。目标是把有限的时间，用到当前紧要的事情上。
3035
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
