51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 8492|回复: 21
打印 上一主题 下一主题

[讨论] 客户验收时,简单的按键使整个软件Crash了,你......怎么处理?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-12-6 09:43:50 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
当客户验收时,你给客户演示软件的功能,然而一个简单的按键(比如Back键)操作,使软件Crash了,客户很不满意,你应该怎么办!
如果你是QA PM(测试项目经理),你会怎么做?
如果你是QA Engineer(测试工程师),你会怎么做?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-12-7 09:48:34 | 只看该作者
不知道啊.
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2007-12-7 16:17:48 | 只看该作者
谢谢!
没人有处理办法么?
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-12-10 15:48:00 | 只看该作者
原帖由 leevon 于 2007-12-6 09:43 发表
当客户验收时,你给客户演示软件的功能,然而一个简单的按键(比如Back键)操作,使软件Crash了,客户很不满意,你应该怎么办!
如果你是QA PM(测试项目经理),你会怎么做?
如果你是QA Engineer(测试工程师), ...


如果我是演示的人,我这个时候直接去踢电源线,说电脑坏了,然后演示的时候跳过,其它的人重现好了,记录下相关的信息,查看这个测试负责人是谁,对应的测试用例是谁写的。
其实rp一般不会差到这个程度,因为程序写出来能运行还是基本能保证的
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-12-10 17:01:58 | 只看该作者

个人意见

楼上的那位,您也太强悍了~~~都能想出来踢掉电源??佩服~~

   我个人觉得呢,如果是我的话,不管是作为QA PM还是QA Engineer,首先必须做的都是道歉,这是礼貌问题,毕竟没有能把握产品的质量是我们的失职。当然了,道歉要有艺术性,不能完全的就否定了本公司的成果产品。这样就会更加助长客户的气焰。然后并会保证会查明原因,并保证不会再出现类似的问题。(这种保证是一种信誉的象征,但是,前提是你要能够保证以后不要出现这样的问题,不然,信誉全失)
   总之,事情当时,发挥你的应变和交际能力,搞定现状。本人建议千万别踢电源,第一,踢不好会损坏公物。第二,是一种逃避的表现。治标不治本。第三,会有生命危险。呵呵

   最后要最的更加关键,就是你要在事后第一时间追查出开发人员和相关测试人员。因为这是他们的责任,很简单的操作就会出现问题,那么,负责质量把关的测试人员,就存在着更多的失职。

   不管怎么做,就是保证这样的事情不能再发生了,或者把发生的概率控制到极小的程度。

P.S:这样的问题比较少见,因为质量控制要是做到这样的话,我觉得,就有必要撤销这个部门了。……

[ 本帖最后由 sunchunyue 于 2007-12-10 17:03 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-12-10 17:28:20 | 只看该作者
楼上说的真好
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-12-10 18:22:25 | 只看该作者

回复 1# 的帖子

但愿这种事情不要发生,一旦发生,虽然你有备份的东西,但公司的形象可就完蛋了。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2007-12-10 21:12:25 | 只看该作者
原帖由 leevon 于 2007-12-6 09:43 发表
当客户验收时,你给客户演示软件的功能,然而一个简单的按键(比如Back键)操作,使软件Crash了,客户很不满意,你应该怎么办!
如果你是QA PM(测试项目经理),
---
作为结果去承受,我想,必须和客户坦诚,说明这个问题确实是没有被测试覆盖到。然后请求客户的原谅并道歉。如果有可能的话,重启应用重新演示。---
如果你是QA Engineer(测试工程师), ...


当然,对于用户验收这样的活动,我们不仅要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势,从而做出是否放行的决定。同时还要做好以下三件事情以确保用户验收测试的顺利通过:
1,必要的时候,能依据UAT Case在内部利用生产数据补充一轮测试;
2,不考虑Case,利用1-2天做随机性测试;
3,条件容许的情况下,预演一次UAT环境部署并覆盖主要的功能场景,以便在客户现场不丢丑。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-12-11 16:25:23 | 只看该作者
study
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-12-11 17:06:44 | 只看该作者
要明白在客户面前出现致命的问题影响很不好的不是道歉能搞定的,这个时候要灭杀证据!

很多演示活动中出了问题都可以这样解决,直接关电脑,然后找借口就行了!只要你动作快,用户不一定能反映出来是系统的问题。

想当年我的boss在一次有名的招标会上演示产品就出了个问题,好像是算出来的金额有问题,结果一出来下面还没看清楚的瞬间他把电脑重启了,最后那个项目还是谈下来了!

崇拜死了!!!

当然还有一个朋友给我了另外一个看起来更好的方法

我现在演示一下如果我们的软件因系统问题一但crash的处理机制. ******** 请大家等一下.我们来换一台系统正常的机器.

[ 本帖最后由 云层 于 2007-12-11 17:18 编辑 ]
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2015-4-7 16:40
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    11#
    发表于 2007-12-11 21:56:17 | 只看该作者
    既然发生了问题,那就说明你的软件确实存在某些漏出的BUG,如果只是想办法逃避的话,这些问题终究还是会暴露在用户面前的。最后的方法就是勇于承认错误,拿出你的诚意,拿出你的真诚来挽回你在客户心中的形象。过后,分析问题发生的原因,测试设计有问题还是Tester的问题。
    当然,如果一个程序烂到这种程度的话,只能说明开发或者测试的流程出现了最根本的错误,这个才是致命的
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2017-11-13 16:46
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    12#
    发表于 2007-12-12 14:59:22 | 只看该作者
    如果出现这样的情况的话,首先是看一下这个问题是不是能重现,Crash当然是很严重的,但是可能并不是软件本身所导致的,可能是也其他的软件不兼容,可能是硬件配置的问题,也可能是偶然发生的,如果在客户那边能重现的话,了解客户的机器配置及软件的详细信息,在分析是我们的测试用例没有覆盖到,测试的环境不到位,还是测试人员没有尽到责任,最终解决问题,给客户一个明确的答复。
    BTW:测试人员不要将思维光局限在测试用例上
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2007-12-15 22:14:11 | 只看该作者
    原帖由 云层 于 2007-12-10 15:48 发表


    如果我是演示的人,我这个时候直接去踢电源线,说电脑坏了,然后演示的时候跳过,其它的人重现好了,记录下相关的信息,查看这个测试负责人是谁,对应的测试用例是谁写的。
    其实rp一般不会差到这个程度,因为程 ...


    直接踢电源?呵呵,很好,很强大!不过,咱们要讲求和谐,很和谐的那种,呵!
    事后倒是要好好处理哦!
    rp这个很难说哦,说不定啥时就真碰上了,呵呵,思考多的话,也有个准备嘛~~~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
     楼主| 发表于 2007-12-15 22:36:13 | 只看该作者
    原帖由 sunchunyue 于 2007-12-10 17:01 发表
    楼上的那位,您也太强悍了~~~都能想出来踢掉电源??佩服~~

       我个人觉得呢,如果是我的话,不管是作为QA PM还是QA Engineer,首先必须做的都是道歉,这是礼貌问题,毕竟没有能把握产品的质量是我们的 ...


    说的很不错噢,学习了,谢谢!
    首先,要有艺术性地道歉;其次,要给与带有风险性的承诺!
    事发当时要通过合理的办法搞定现状,之后要避免类似问题重范或发生率降到最低!
    这样的概括,Ok么?呵呵~~~谢谢!!
    最关键的应该不是追究责任,而是寻求根源,总结原因,避免重蹈覆辙吧?

    P.S:这样的问题是比较少见,但要是RP不好的话,也会碰到的吧,有必要撤销这个部门了?没这么严重吧,呵呵……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
     楼主| 发表于 2007-12-15 22:47:17 | 只看该作者
    原帖由 luoyear 于 2007-12-10 21:12 发表


    当然,对于用户验收这样的活动,我们不仅要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势,从而做出是否放行的决定。同时还要做好以下三件事情以确保用户验收测试的顺利通过:
    1,必要的时候,能依据UAT C ...


    谢谢,很不错阿,学习了~~~
    重启程序重新演示,这个不错,是一个方法。
    要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势?测试覆盖率要如何评估?
    还有,UAT Case跟Test Case是同一个概念么?
    谢谢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
     楼主| 发表于 2007-12-15 23:04:43 | 只看该作者
    原帖由 云层 于 2007-12-11 17:06 发表
    要明白在客户面前出现致命的问题影响很不好的不是道歉能搞定的,这个时候要灭杀证据!

    很多演示活动中出了问题都可以这样解决,直接关电脑,然后找借口就行了!只要你动作快,用户不一定能反映出来是系统的问题。 ...


    很好,直接重启电脑,然后找借口,这个方法很不错,绝对可以借鉴!
    至于第二种方法,换一台系统正常的机器,万一不是系统的问题,而是我们软件问题,就不好办了,呵呵!
    谢谢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
     楼主| 发表于 2007-12-15 23:29:25 | 只看该作者
    原帖由 czqiqi 于 2007-12-11 21:56 发表
    既然发生了问题,那就说明你的软件确实存在某些漏出的BUG,如果只是想办法逃避的话,这些问题终究还是会暴露在用户面前的。最后的方法就是勇于承认错误,拿出你的诚意,拿出你的真诚来挽回你在客户心中的形象。过后, ...


    勇于承认错误,用真诚来挽回公司在客户心中的形象!
    谢谢!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2020-8-11 08:18
  • 签到天数: 114 天

    连续签到: 1 天

    [LV.6]测试旅长

    18#
    发表于 2007-12-16 12:25:12 | 只看该作者
    这个还是要看实际情况
    商场如战场
    客户并不是在找什么知心朋友
    很多时候不是一句道歉可以挽回的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-12-16 12:43:27 | 只看该作者
    要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势?测试覆盖率要如何评估?
    1,形式上的覆盖,也就是每个细化到一定程度的需求必须要有1个正向的和一个反向的case去覆盖;
    2,抽样检查:检查那些第一轮系统测试后,缺陷比较多的模块,抽样一些需求,看看真正用来测试这些需求的testcase够不够。
    3,缺陷趋势方面,一方面可以参考自己公司的历史项目的缺陷分布模型,做个比对,另外一方面,就是发布前的最后1-2个星期,版本需要具备一定的稳定性。具体什么叫稳定,需要自己根据具体情况提出一个目标,如最后一周不能出现高等级的bug,每天发现的缺陷不能少于2个等。

    还有,UAT Case跟Test Case是同一个概念么?
    UAT case是客户从实际使用的角度提出的用例。比较象我们内部设计的End to End测试用例。

    谢谢! [/quote]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2008-5-4 14:28:16 | 只看该作者
    看到各位高手的见解,自知需要学习的还很多,进入测试行业不久,虚心来此学习
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-15 00:59 , Processed in 0.100210 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表