|
5#
楼主 |
发表于 2007-8-15 13:26:56
|
只看该作者
面试人员问,在你所测试的软件中出了致命问题,你应该怎么办?请问各位应该如何完美回答这个问题?
回答肯定不完美,供参考:
1、详细记录bug的各项信息,例如上面提到的环境,操作过程等,这样对于bug后期的分析、重现和验证都很有意义;
---------------------------------
一般就是利用大家经常提到的BUG跟踪系统;
2、完成常规bug记录和简单分析后,要立即将这些记录整理的信息反馈给相关人员,例如开发和项目经理等,以便开发及时修改,项目经理及时调整策略等;
-----------------------------------
BUG跟踪系统会通过邮件系统自动反馈BUG给相关研发经理,研发经理按照不同的功能模块将BUG转发给相关的研发人员,研发人员如果对BUG有疑问或者在研发所处环境下无法复现问题,可以找相关测试人员来协助.
3、以发现的致命bug为中心,向相关周边扩展范围测试,因为bug具有群聚现象,也就是问题集中出现在某一区域;
-------------------------------------
其实不是说你发现了问题后才做这样的测试,而是你做测试用例的时候就应该这样考虑.发现严重问题后.除这个问题所在的功能模块可以暂停测试外,其它功能可以照常测试.我之所以说暂停,是因为后续的修改可能会带来另外的问题,你目前测试所发现的问题后续可能就不存在,有时候会成为一种时间的浪费.
4、根据前面的测试情况,分析该致命bug对于当前测试影响,如果严重,测试也许要及时调整测试策略;
----------------------------------------
可以根据项目的时程来确定这个问题的影响,如果此问题会影响到项目完成时程,那就要需求规划/研发/测试,甚至用户出来对这个问题做出修改的意见,因为致命问题不都是程序逻辑等问题,还有可用性/实用性方面的问题.所以这个时候确定修改意见并根据此确定下一步测试的走向以及重点.我说的这个情况只会在问题严重的已经影响需求的条件下发生.一般的致命问题,不涉及到需求的,照常修改,至于会影响时程的还是要向上实时反应.
?
首先面试人员的问题,主要说明了两点:一是出现了致命问题。二是测试人员怎么办。其次就是redvale (秋秋) 的问题,怎么“完美”的回答。我们来一一分析。
一、致命问题
要回答怎么处理致命问题,首先要弄清楚什么才是致命问题,其次是致命问题是从哪里来的。
从语意上,“致命问题”这个说法是及其不严谨的,因为没有一个公认的标准,每个人对致命问题的理解都可能不同,而且随着软件过程中不同的阶段,对致命问题的认识可能也不一样。从我个人的理解来说,致命问题就是导致软件无法再继续进行测试的缺陷。比如:死机,数据丢失,主要功能组完全丧失,系统悬挂等等。也许别人的理解和我不同,对此我不会和别人争论。
在一个公司中,对缺陷的严重级别应该有一个标准,明确说明各种缺陷应该属于什么严重程度,另外,应该有专人(测试组长、测试主任、测试经理等能说了算的人)统一处理所有人的错误级别,多人负责很容易出现不同的标准(特别是缺陷和工作、考评等联系的时候,如果没有一个统一的标准,很容易陷入人事关系的泥潭中。呵呵,大家看最新的几期程序员了吗?原来微软也干这种事情,缺陷数和考评联系,结果各地的测试员抢bug)。
致命错误的来源是程序,换句话说,需要测试的程序出现了问题,从这个角度来看,致命错误和严重错误、轻微错误等对程序来说并没有本质的差别。也许换个角度,轻微错误可以变成致命错误。
二、测试人员的处理
这个问题其实和测试人员的关系不大。对错误问题的处理,和公司制度才有最密切的关系。
想当年,我们还曾经使用过测试单,发现问题就填表格,最后统一交给项目经理。
现在一般都很先进,有各种bug管理工具的支持,所以对缺陷的提交、管理、跟踪、统计等都很方便。
无论遇到什么级别类型的问题,大概的处理流程在bug管理工具的支持下其实都应该差不多。
既然这样,你们就会问,既然是致命问题,总应该和其它的有些不同吧。否则“致命”两个字不是浪费了吗?
还是老话,公司是否制定了对致命问题的处理?如果有,很简单,按照公司的流程去处理;如果没有,就看你自己的了。
上面我说了,我的个人理解是致命缺陷是无法继续测试的问题,这样的问题优先级应该是最高的,因为有阻塞的效果,没有处理的时候,无法继续进行下面的工作。这个时候应该报告测试负责人,由测试负责人和开发经理联系,最后让项目经理找相关的人员处理。
在这里,除非是测试人员直接附属于开发部门,否则不建议由测试人员直接找程序员处理。一个公司,越权是可大可小的事情,如果可能,最好由领导之间协商,测试人员所要做的仅仅是测试。
与此对应的,什么进度、市场、需求、缺陷解决等,和测试人员的工作有什么关系?也许在有时间的时候可以自己想想这些,但在没有制定的支持下,还是老老实实做好测试员这份也许有前途的工作吧。
三、完美的解决问题
其实在测试中,很重要的一个原则就是,不多不少,在恰当的时候结束。程序中的bug是抓不完的,在有限的时间内,却要做需要无限时间的工作,这需要一个衡量取舍的过程。测试的少了,可能程序中剩余的bug太多;测试过多,则会浪费项目资源,得不偿失。既然测试过程本身无法做到完美,为什么对一个具体的问题还是要一个完美的答案。
微软的一个经典测试题目,就是随便找一个东西,说明应该如何进行测试,没有人要求完美的回答,只能说尽力的从各个角度、各个方面去说明。
说了很多,和没说一样,算我灌水好了。 |
|