[你问我来答第8期]：软件缺陷管理交流

帖子地址：http://bbs.51testing.com/viewthread.php?tid=374495&extra=&page=3

第37楼，江潭素月的问题解答：

原问题如下：

说下从事测试工作近一年来，测试工作中的问题，希望能得到千里兄的指点

一，先说下我们公司的测试流程
公司有测试人员只有2个。如果开发人员有需要测试的程序，给测试人员打个招呼，然后测试人员将源代码从服务器上迁到本机MyEclipse，然后部署运行，进行测试。如果发现有bug，提交到bug管理工具mantis中，开发人员访问mantis，修改Bug，提交代码，测试人员更新代码，复测。

不知道是否有公司是这样的测试模式，可否评价一下这样做有什么问题。

目前发现的问题就是：（1）不写测试用例，想到哪测到哪，测试很难将功能点覆盖全面（2）测试、修改Bug、复测的时间混在一块，分不清是谁的效率低。目前公司开发人员修改bug的效率就特别低，而且修改Bug引起新的Bug的产生，拖拖拉拉，测试最后不了了之，也不知道什么时候测试结束，怎么算是测试结束，也许有人会说bug都改完不就是结束了吗，但是不可能，很多Bug存在争议，测试人员认为改，开发人员认为不用改，领导也不管

二，关于什么样的问题该提交bug
网上讲测试用例时，讲到用极限值、在输入数字的地方输入字母，但是这样测出来的问题，开发人员很反感，他们不愿意修改这样的问题，只想修改正常操作出现的问题，甚至他们的主管也是这样认为，认为客户不会那样操作，让我们测试人员很苦恼。我们应该怎么界定需要提交的Bug呢，按主管说的？还是按网上讲到的方法？网上讲到的方法吧，倒是能锻炼自己，但老是看他们的白眼，认为我们是做无用的工作

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

liuygneusoft回复江潭素月

(1)测试流程存在的风险
没有版本管理，会导致其他工作会很乱，另外会增加测试人员工作量，测试人员的工作变成没计划，没管理。比如新发现的BUG，无法去分析，是不是修改带来的，还是这BUG是原来就有，只是没测试到。为什么会增加测试人员工作量呢，开发人员只要改代码，就会提交到SVN中，频繁的这么更改，测试轮次就会乱，且容易助长发人员，自己修改后不测试，就扔到测试人员手中，在我们公司这就private build ，测试人员不能没完没了的给开发人员帮private build测试，只有特殊情况下才用，在你们这，感觉就是在做private build的测试，不是系统测试。
（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.缺陷被暴露的概率非常小，就算被暴露了影响也不是致命的。