[你问我来答第8期]：软件缺陷管理交流（已结束）

西贝

好面熟呀

manow111

支持!文采不错哦!

smile665

支持千里~   从我注册51testing 就看到千里    应该蛮牛的

liuygneusoft

回复 37# 江潭素月

(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 。

我的一些笨见，详聊加我QQ 31931880

江潭素月

回复 44# liuygneusoft

首先，谢谢您的指点，仔细分析了我们工作中的问题。但问题是我们该如何改进呢？

（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低

marysnow

支持一下千里 ！

千里

原来你就是千里啊，之前接到过宇信易诚的面试通知呢？后来接到offer了就没去！要知道应该去试试的，呵呵
hvein 发表于 2011-1-19 15:48

    幸好你没来，这个公司加班很严重，非常辛苦。

千里

回复 45# 江潭素月


（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
--如果你了解配置管理的话，你应该会知道这是项目管理的工作，也就是说这是项目经理的活儿。不过这部分工作量确实非常大，我上一家公司也曾碰到了版本控制的麻烦，项目经理也在考虑版本管理，最终因为没人可做这部分工作而一直搁置着
（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
--这部分工作首先要认可是测试员本份的工作，如果是不会做可以理解。这里提到的需求分析是将用户需求抽出成功能点，然后再将功能点具体实现为用例。当然你的问题也存在一定程度上面的需求环节不规范性，只要对客户意见和测试员bug进行了统一管理，情况会相对好一点。
（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
--这里涉及到一个缺陷不修复的问题，哪些缺陷可以不修复呢？其实还是能够找到相关答案的：1.确实不是bug的；2.修复的代价太大；3.缺陷本身并不严重，但修复需要很长时间；4.缺陷被暴露的概率非常小，就算被暴露了影响也不是致命的。

江潭素月

回复 48# 千里


    我们往往在这样的bug上存在争议：出现频率很高，只要运行程序就出现。但不是致命的bug，不影响功能，修改起来也很比较容易。不属于你说的那几种不修改Bug中的任何一种

例如打开一个页面时，只是在左下角报脚本错误，功能照样用。像这样的Bug，开发人员心情好就改，心情不好就不改。

我们测试人员对于这种bug是倾向于修改的

江潭素月

回复 48# 千里


  关于写测试用例，你说“对客户意见和测试员bug进行了统一管理，情况会好一点”，没有听明白，在我们这种情况下，该如何做测试用例的工作

medoraemon

你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲

千里

你这张照片貌似还是我们一起去陈家祠的时候照的。。。哈哈。。。占个位置好好听讲
medoraemon 发表于 2011-1-25 16:00

    这都被你看出来了，好神奇啊。测试的眼力真是不错，佩服之。

千里

回复 49# 江潭素月


    对于问题较严重，开发都很随意的，领导也不管的。我的做法是把问题以邮件的形式反馈给开发并邮件抄送一份给领导。同时把要不要修改的权力交给领导并暗示他，如果是谁说的不改以后出了问题谁来承担责任。

千里

回复  千里


  关于写测试用例，你说“对客户意见和测试员bug进行了统一管理，情况会好一点”，没有听 ...
江潭素月 发表于 2011-1-25 15:03

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

liuygneusoft

回复 45# 江潭素月

千里的回答很好，很明确，我再补充一点
（1）没有版本控制
之前给公司提过建议，让开发人员打包，将包部署到测试环境下测试不同版本的包。但是这样会增加开发人员的工作量，所以建议没有被采纳。我用什么来说服他们呢，因为做这个工作主要是对我们测试人员有帮助的，而我们测试人员地位很低，所以这样的建议很难被采纳
  
  是如千里所说，这工是配置管理员的专职工作，当前公司没配备，那我们只能从己有人员中想办法，谁最合适呢，当然是研发经理，也不要求正经八百的做配置管理，只是控制一下，什么时候发布下一个版本到测试人员那，或是定在每周五（多长时间，可以视情况定）发布一个新版本测试，这样也促使开发人员尽量在下一版本前修改优先级高的BUG，这对开发经理的要求也不高，我原来就这么做过，我来发布版本，连测试服务环境都是我来配置，我们是分布式环境。那测试人员如何去说服呢，首先不要让人地位低，其次要和经研发经理讲清当前做法产生的严重后果，你可以发邮件建议，并抄送他的领导，我上面的改进办法也不复杂吧，只是控制一下发布时间，把时间点当成版本。
当然我这是权宜之计，不过比没有强。
  
  心态上也不要自认为测试人员地位很低，当然要证明测试人员存在的价值，就是用业绩和专业来反映；按我的理解，测试比开发人员更操心，开发人员，只管实现自己的业务，而不用向测试人员那样，通盘考虑。开发除了复杂系统外，MIS系统都是增删改查，很简单的。

（2）关于写测试用例
首先我们公司没有需求分析这回事。都是在一个系统的基础上进行修改。客户首先拿到我们已经有的系统，然后指出哪里不合适，开发人员就改，改完再让客户看，再提哪里不合适。这样，需求变更很多次，开发人员做完一部分，想给客户更新了，然后就让我们测测，我们无法预知他们什么时候要测试，要测试什么样的功能
这时候不要再强调需求分析了，因为没有。我上一回贴说的测试需求分解，和开发的需求分析并不是一个东西，它只是定义了要测试的功能点有哪些。在没需求分析的情况下，你甚至可以，按功能菜单划化测试需求，并细化到增删改查功能点，这么做是为了好理清功能点，然后再这个测试需求分解的基本上来组纷测试，为什么我说要写用例呢，且是一边测试一边写，既然进入测试了，系统也有了，随着测试的深入，测试人员头脑中一定有业务，那为什么不一边测试一边补充呢，且有了那个测试需求分解，写用例时也能把握住，而不是随意的。这么做的好处是，可以慢慢积累用例，如中间有测试人员离职，也还有用例在.呵呵这是也是在做MYPM时加入BUG和用例关联功能的初衷。在测试期间，有空时（如，等待开发人员提交下一版本），也可以安排一定的时间写用例。

（3）关于bug的提交
您说开始测试时，对于像可用性、易用性这样的Bug暂时不要提交。难道发现问题先记到本子上吗？我们是不管发现什么bug都提，怕以后忘记，然后把这些不重要的bug优先级设置为低
  关于这个，我前面没讲清，不同的时间段内，测试肯定是要有侧重点的，可用性的BUG不是说不能提，如果不经意发现的当然要提，我是想表达，不要有意去执行可用性测试，在功能没实现前。要不开发的会误认为，你发现不了什么BUG，尽提些不重要的。目标是把有限的时间，用到当前紧要的事情上。

江潭素月

谢谢千里和liuygneusoft ，帮我分析了问题还提供了解决方案。我已经将问题和改进办法进行了归纳，写了2010年测试总结。再次谢谢你们

liujianigali

我来捧场的，千里，进步很快，我的进步比较小了，以后要以你为榜样！

carolyeaph

老师，你好！
请问如何保证测试达到要求的需求覆盖率？　谢谢。

819longjiayan

终于见到了千里的真面目了。支持支持。。。


我想问几个问题：
1.在做提取测试功能点时，在只有需求分析文档时，我们怎样提取测试功能点，然后怎样进行根据功能点写测试用例？我正在做的这个cmmb项目时，写出的测试用例完全不能测开发出来的系统，有很大的偏差。不知道这个在前期怎么做比较好，才会减少这样的偏差，不造成测试用例不可用。
2.关于职业发展方面的问题，我想以后向测试管理方面发展，如测试组长或测试主管经理什么的，但是现在我存在一个问题，我说话什么的缺少一种气势，我想改变这种现状，不知道如何改变。我如果向测试管理方面发展，需要做学习哪些东西，需要做好哪些工作，然后我个人的素质需要达到什么要求。
请千里兄给点意见

huxb_dowant

问一个问题:
如果你到一个公司做测试经理,你的下属中80%的人压根就不适合做软件测试，你会怎么处理？公司考虑所谓成本，你不能开除不合适的人。