开发&测试

2012辉

在开发组与测试组开会讨论是否为Bug时，最常见的一句话就是，一般情况下都不会这样操作，只有测试的时候才会这样 ！！！！

omg

挺抓狂的。挺常见的。

找客户代表来看看，找项目经理聊聊。

黑鱼白

1.测试的目的是提高产品的质量，达到客户的满意度。
2.测试时出现的bug，有可能是测试环境与真实环境的差异造成的，但是不能肯定的是这种bug，在用户操作时不会发生。"一般情况下都不会这样操作，只有测试的时候才会这样 ！！！！",这就意味着，开发已经承认它是个bug，也意味着开发认为不需要修复这个bug,然而这个Bug可以考虑是否会影响产品的功能的实现呢？客户是否可以接受这样的bug存在？这种bug是否潜伏着对产品造成更大的危害？等
3.当然，也可以再用户手册中，将这种bug写在遗留缺陷中，可以再后期进行服务时进行修复。

我是新手，如有说的不对的地方，请见谅，也很乐意高手纠错。

2012辉

回复 3# 黑鱼白


    你是新手啊，说的挺好的呀。不过真正的测试流程感觉没这么正式。

lyhgq321

在无必须的情况下，应该是挂起吧……

lyhgq321

在无必须的情况下，应该是挂起吧……

zzlagi

一般情况下，那特殊情况下呢？你就能保证客户不会这样进行操作吗？改  必须改   一定要改

zhjueqing

一般情况下是有多一般，是某种特定环境下？还是一般用户不会这么操作？

可以通过用bug出现的步骤数目来确定，用户是否容易遇到。越少的这越要改。

跑跑跑跑

这种问题大多数都是要修改的

Jodo

客户才是王道啊，不过按照BUG等级分就是了，到时报告中也涉及，等待最终确定的时候，再按照客户使用后会出现的概率分，然后待上层决定是否可以跳过吧，什么只有测试才会遇到，这也是为了后期的维护，还有减少客户抱怨度嘛

千里

挺抓狂的。挺常见的。

找客户代表来看看，找项目经理聊聊。
omg 发表于 2013-4-10 21:21

    确实因为没有第三方的时候，两方PK是最没有结论的。

千里

1.测试的目的是提高产品的质量，达到客户的满意度。
2.测试时出现的bug，有可能是测试环境与真实环境的差异 ...
黑鱼白 发表于 2013-4-11 10:33

    你只是测试，不是客户，怎么知道客户的满意度是什么呢？

千里

回复 3# 黑鱼白


    你还需要想一个问题，就是你认为是遗留BUG，可能开发项目经理认为这不是一个BUG，这个时候才是让你抓狂的。

千里

一般情况下，那特殊情况下呢？你就能保证客户不会这样进行操作吗？改  必须改   一定要改
zzlagi 发表于 2013-4-15 11:54

    如果人家完全不鸟你，压根不修改，你还能这么强势吗？很多时候测试没有站在道德的制高点，反而让开发站在了那个高点。

虫盲

回复 3# 黑鱼白

谨慎的反对一下第一点：
    测试的目的不是提高产品的质量，而是测试该款产品是否符合用户的需求。另外，测试并不能提高产品的质量，一个产品的质量，是开发出来就已经决定了的。测试只能说尽可能的去发现缺陷，而并不能解决缺陷，也就不能提高产品的质量。软件的质量是靠开发出来的，而不是靠测试出来的。
    愚人小见。

51testing-wn

1、一般来讲，求助第三方的产品经理、需求分析工程师、开发经理或者测试经理，可比较快速的定位问题。
2、如果缺陷有明显不符合需求和系统要求，找到确认过的需求信息作为证据反驳。
   对于开发人员说的，客户不会那样做的问题？也可以试问，我们能保证客户只能按照A的方式操作，不能按照B的方式操作。答案显而易见。我们也可以从软件的易用性和健壮性，来分析问题。
3、在发布软件或者版本的时候我们是允许软件包含缺陷的，这需要评判缺陷的质量高低和优先级，通过这个标准来确认改与不改，及解决问题的优先级别。同时记录在发布说明书和测试记录文档中，比便跟踪问题。
4、总结缺陷的分布，包括一致同意认可的和争执的缺陷，归纳问题以数据来说明问题，并以此作为促进“改进软件质量”的目的。

另外，同意15楼。软件质量不是测试出来的，是靠开发人员开发出来的。测试人员是软件质量保证的一个重要环节。

guoguo2005

软件质量不是测试出来的，也不是靠开发人员开发出来的。
质量靠的是对开发流程的管理。
在项目的每个时间点上，投入恰当的资源，会大幅提升项目的绩效。

51testing-wn

你们是传统的瀑布开发模式，还是敏捷模式？

在"错误"的问题上达成一致，才能解决问题。如何达成一致的方法是跟开发模式和管理模式有关系的。
不存在开发和测试，那种对立关系。如果懂程序，懂业务 更加容易以他们的思维方式考虑和交流问题。

Jackc

其实我不太明白，测试人员为什么总会纠结于bug 改与不改的问题。。 个人认为已经超出普通测试人员的权限和职责了。
------------------------------
1.通常的 测试流程规范里已经写清楚了哪些bug需要改，并不需要测试人员去督促，只需要在产品周期测试报告中写清楚，并保证高层领导知晓就行了。比如，P1的必须修复。
2. 普通测试人员的主要职责是实时反馈正确的产品质量，那么只需要发现bug，并正确进行bug分类和分析即可。
3. 通常，产品上线后被客户反馈bug了，对于测试人员来说，只要bug库里有与之关联的bug，貌似不会受到什么指责吧。
4. 测试人员是需要对产品负责，但是如果自身本来就没有协调其他部门（如，开发）的权限，又如何去要求其他部门的人员必须做某事呢？（这里涉及QA/QC的职责和权限，没有权限QA不能称之为QA）
--------------
通常，测试人员可分为以下3类：
1. 省心型： bug 提了，报告发了，改还是不改，开发的事，我不管。
2. 职业性： bug提了，开发沟通了，领导问过了，其他就没我什么事了。
3. 抓狂型： bug提了，开发沟通了，领导问过了，威逼利诱让开发把bug改了。。。

PS：开发不改某条bug, 经常原因是“代码或逻辑改动较大，存在不可控风险”，但是通常开发不会直接对测试人员坦白其中缘由。这个就像是自己对某人说：我错了，我设计的东西是垃圾。
当然，如果是开发人员只是单纯得想混日子，打酱油的话，我认为可以时不时就用“抓狂型”让他经常自己去“抓狂”去吧。

Jackc

额。。。貌似偏题了。。。
“是否是bug”的问题被我理解成“是否需要修改bug”了。。。

算了，基础思想都差不多：提不提bug是测试人员的职责，改不改bug是开发人员的事。

某条bug，开发人员觉得不是bug，他就去将bug状态改成“无效”呗，这说明别人有完全承担这条bug危害的觉悟了。不管是潜意思还是有意的，至少产品上线后出现类似的问题，测试部门的标准回复无非是：“测试人员在前期已发现，开发人员理解为无效bug，故发生泄漏。以后将加强测试/开发/需求人员的沟通。。。”