一、致命问题

　　要回答怎么处理致命问题，首先要弄清楚什么才是致命问题，其次是致命问题是从哪里来的。

　　从语意上，“致命问题”这个说法是及其不严谨的，因为没有一个公认的标准，每个人对致命问题的理解都可能不同，而且随着软件过程中不同的阶段，对致命问题的认识可能也不一样。从我个人的理解来说，致命问题就是导致软件无法再继续进行测试的缺陷。比如：死机，数据丢失，主要功能组完全丧失，系统悬挂等等。也许别人的理解和我不同，对此我不会和别人争论。

　　在一个公司中，对缺陷的严重级别应该有一个标准，明确说明各种缺陷应该属于什么严重程度，另外，应该有专人（测试组长、测试主任、测试经理等能说了算的人）统一处理所有人的错误级别，多人负责很容易出现不同的标准（特别是缺陷和工作、考评等联系的时候，如果没有一个统一的标准，很容易陷入人事关系的泥潭中。呵呵，大家看最新的几期程序员了吗？原来微软也干这种事情，缺陷数和考评联系，结果各地的测试员抢 bug）。

　　致命错误的来源是程序，换句话说，需要测试的程序出现了问题，从这个角度来看，致命错误和严重错误、轻微错误等对程序来说并没有本质的差别。也许换个角度，轻微错误可以变成致命错误。

　　二、测试人员的处理

　　这个问题其实和测试人员的关系不大。对错误问题的处理，和公司制度才有最密切的关系。

　　想当年，我们还曾经使用过测试单，发现问题就填表格，最后统一交给项目经理。

　　现在一般都很先进，有各种bug管理工具的支持，所以对缺陷的提交、管理、跟踪、统计等都很方便。

　　无论遇到什么级别类型的问题，大概的处理流程在bug管理工具的支持下其实都应该差不多。

　　既然这样，你们就会问，既然是致命问题，总应该和其它的有些不同吧。否则“致命”两个字不是浪费了吗？

　　还是老话，公司是否制定了对致命问题的处理？如果有，很简单，按照公司的流程去处理；如果没有，就看你自己的了。

　　上面我说了，我的个人理解是致命缺陷是无法继续测试的问题，这样的问题优先级应该是最高的，因为有阻塞的效果，没有处理的时候，无法继续进行下面的工作。这个时候应该报告测试负责人，由测试负责人和开发经理联系，最后让项目经理找相关的人员处理。

　　在这里，除非是测试人员直接附属于开发部门，否则不建议由测试人员直接找程序员处理。一个公司，越权是可大可小的事情，如果可能，最好由领导之间协商，测试人员所要做的仅仅是测试。

　　与此对应的，什么进度、市场、需求、缺陷解决等，和测试人员的工作有什么关系？也许在有时间的时候可以自己想想这些，但在没有制定的支持下，还是老老实实做好测试员这份也许有前途的工作吧。

　　三、完美的解决问题

　　其实在测试中，很重要的一个原则就是，不多不少，在恰当的时候结束。程序中的bug是抓不完的，在有限的时间内，却要做需要无限时间的工作，这需要一个衡量取舍的过程。测试的少了，可能程序中剩余的bug太多；测试过多，则会浪费项目资源，得不偿失。既然测试过程本身无法做到完美，为什么对一个具体的问题还是要一个完美的答案。

　　微软的一个经典测试题目，就是随便找一个东西，说明应该如何进行测试，没有人要求完美的回答，只能说尽力的从各个角度、各个方面去说明。