测试的软件出现了致命问题,应该怎么做?

本文围绕软件测试中致命问题展开讨论。首先明确致命问题定义及来源,指出公司应统一缺陷严重级别标准。接着说明测试人员处理问题与公司制度密切相关,有bug管理工具支持,致命问题应报告负责人。最后强调测试要权衡取舍,不必追求完美答案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

        在csdn的软件工程论坛,有人问这个问题,原帖参见:http://community.youkuaiyun.com/Expert/TopicView3.asp?id=3749711。
        我第一时间抢答了。后来也有很多的人对这个问题表达了自己的看法。但对其中的一些观点我颇不赞同,就写了个比较长的发了出来。下面就是我回复的内容。

首先面试人员的问题,主要说明了两点:一是出现了致命问题。二是测试人员怎么办。其次就是redvale (秋秋) 的问题,怎么“完美”的回答。我们来一一分析。

一、致命问题
要回答怎么处理致命问题,首先要弄清楚什么才是致命问题,其次是致命问题是从哪里来的。
从 语意上,“致命问题”这个说法是及其不严谨的,因为没有一个公认的标准,每个人对致命问题的理解都可能不同,而且随着软件过程中不同的阶段,对致命问题的 认识可能也不一样。从我个人的理解来说,致命问题就是导致软件无法再继续进行测试的缺陷。比如:死机,数据丢失,主要功能组完全丧失,系统悬挂等等。也许 别人的理解和我不同,对此我不会和别人争论。
在一个公司中,对缺陷的严重级别应该有一个标准,明确说明各种缺陷应该属于什么严重程度,另外,应该 有专人(测试组长、测试主任、测试经理等能说了算的人)统一处理所有人的错误级别,多人负责很容易出现不同的标准(特别是缺陷和工作、考评等联系的时候, 如果没有一个统一的标准,很容易陷入人事关系的泥潭中。呵呵,大家看最新的几期程序员了吗?原来微软也干这种事情,缺陷数和考评联系,结果各地的测试员抢 bug)。
致命错误的来源是程序,换句话说,需要测试的程序出现了问题,从这个角度来看,致命错误和严重错误、轻微错误等对程序来说并没有本质的差别。也许换个角度,轻微错误可以变成致命错误。
二、测试人员的处理
这个问题其实和测试人员的关系不大。对错误问题的处理,和公司制度才有最密切的关系。
想当年,我们还曾经使用过测试单,发现问题就填表格,最后统一交给项目经理。
现在一般都很先进,有各种bug管理工具的支持,所以对缺陷的提交、管理、跟踪、统计等都很方便。
无论遇到什么级别类型的问题,大概的处理流程在bug管理工具的支持下其实都应该差不多。
既然这样,你们就会问,既然是致命问题,总应该和其它的有些不同吧。否则“致命”两个字不是浪费了吗?
还是老话,公司是否制定了对致命问题的处理?如果有,很简单,按照公司的流程去处理;如果没有,就看你自己的了。
上面我说了,我的个人理解是致命缺陷是无法继续测试的问题,这样的问题优先级应该是最高的,因为有阻塞的效果,没有处理的时候,无法继续进行下面的工作。这个时候应该报告测试负责人,由测试负责人和开发经理联系,最后让项目经理找相关的人员处理。
在这里,除非是测试人员直接附属于开发部门,否则不建议由测试人员直接找程序员处理。一个公司,越权是可大可小的事情,如果可能,最好由领导之间协商,测试人员所要做的仅仅是测试。
与此对应的,什么进度、市场、需求、缺陷解决等,和测试人员的工作有什么关系?也许在有时间的时候可以自己想想这些,但在没有制定的支持下,还是老老实实做好测试员这份也许有前途的工作吧。
三、完美的解决问题
其 实在测试中,很重要的一个原则就是,不多不少,在恰当的时候结束。程序中的bug是抓不完的,在有限的时间内,却要做需要无限时间的工作,这需要一个衡量 取舍的过程。测试的少了,可能程序中剩余的bug太多;测试过多,则会浪费项目资源,得不偿失。既然测试过程本身无法做到完美,为什么对一个具体的问题还 是要一个完美的答案。
微软的一个经典测试题目,就是随便找一个东西,说明应该如何进行测试,没有人要求完美的回答,只能说尽力的从各个角度、各个方面去说明。
说了很多,和没说一样,算我灌水好了。
<think>嗯,用户问的是软件开发的测试主要做什么。首先,我需要确定用户对测试的了解程度,可能他们刚开始接触软件开发,或者想更深入了解测试的具体职责。之前用户已经询问过提示词工程师,可能现在想了解另一个相关领域。 测试的主要目的是确保软件质量,但具体职责可能包括哪些呢?测试人员需要设计测试用例,执行测试,发现并报告缺陷,验证修复后的功能,可能还有自动化测试。不过用户可能需要更结构化的回答,比如分点说明核心职责。 另外,用户可能想知道测试的不同类型,比如单元测试、集成测试、系统测试、验收测试等,或者不同的测试方法如手动测试和自动化测试的区别。可能还需要提到测试在整个开发周期中的位置,比如敏捷开发中的持续测试。 用户可能还关心测试工具,比如Selenium、JUnit、TestNG等,或者测试流程,比如测试计划、测试用例设计、执行、缺陷管理。是否需要举例说明测试用例的设计?比如等价类划分、边界值分析等。 还要注意用户是否有技术背景,可能需要用更通俗的语言解释。比如测试用例就像检查清单,确保每个功能按预期工作。缺陷报告需要详细描述问题,帮助开发人员复现和修复。 可能还要提到回归测试,确保新改动不影响旧功能,以及性能测试、安全测试等非功能测试是否需要强调测试的重要性,如预防成本,提高用户满意度? 另外,结合之前的回答模式,用户喜欢分点、结构清晰,可能用核心职责、测试类型、常用方法、工具这样的结构。是否需要使用LaTeX公式或代码块举例?比如用代码块展示测试用例的格式,或者用流程图说明测试流程。 需要确认回答是否覆盖了用户潜在的问题,比如测试在DevOps中的作用,或者自动化测试的优势。可能用户想知道测试工程师和开发人员的协作方式,或者持续集成中的测试环节。 最后,总结测试的主要目标,确保软件质量、减少风险、提升用户体验,并可能给出学习路径建议,如学习测试理论、工具使用、参与实际项目等。</think>软件开发中的测试(Software Testing)是通过系统化的方法验证软件功能、性能及安全性的关键环节,主要目标是确保软件质量符合预期。以下是测试工作的核心内容: --- ### **一、核心职责** 1. **缺陷探测** 模拟用户使用场景,找出代码中的逻辑错误、功能缺失等问题 ```text 示例:电商系统购物车测试 - 正常流程:添加3件商品 → 结算金额正确 - 异常测试:添加-1件商品 → 系统应拦截非法输入 ``` 2. **质量验证** 通过多维度检查确保软件达标: $$ \text{质量} = \sum_{i=1}^n (功能正确性 + 性能指标 + 安全防护 + 用户体验) $$ 3. **风险防控** 识别可能引发系统崩溃的致命问题,如: ```text 压力测试:模拟10万用户同时支付 → 检查系统是否出现数据丢失 ``` --- ### **二、测试类型** | 类型 | 执行阶段 | 典型方法 | 工具示例 | |------|----------|----------|----------| | **单元测试** | 编码阶段 | 白盒测试 | JUnit, PyTest | | **集成测试** | 模块联调 | 接口测试 | Postman, SoapUI | | **系统测试** | 整体交付 | 黑盒测试 | Selenium, Appium | | **验收测试** | 上线前 | 用户场景 | Cucumber | --- ### **三、关键方法** 1. **等价类划分** 将输入数据划分为有效/无效类: ```text 密码强度测试: - 有效类:Abc123!@ - 无效类:abc(缺少大写+特殊字符) ``` 2. **边界值分析** 针对数据临界点测试: $$ \text{年龄输入框}[18,60] \rightarrow 测试17,18,19,59,60,61 $$ 3. **自动化测试** 通过脚本实现高频测试(提升10倍效率): ```python # Selenium示例:自动登录测试 driver.find_element(By.ID, "username").send_keys("test_user") driver.find_element(By.ID, "password").send_keys("123456") driver.find_element(By.ID, "login-btn").click() assert "欢迎页" in driver.title ``` --- ### **四、测试流程** ```mermaid graph TD A[需求分析] --> B[制定测试计划] B --> C[设计测试用例] C --> D[执行测试] D --> E[缺陷跟踪] E --> F[回归测试] F --> G[输出测试报告] ``` --- ### **五、行业现状** - 微软的统计显示:早期发现缺陷可降低30倍修复成本 - 自动化测试覆盖率已成为DevOps成熟度核心指标 - 新型测试方向:AI模型测试、区块链智能合约验证 **学习建议**:从手工测试入门 → 掌握SQL/Linux基础 → 学习自动化工具 → 深入性能/安全测试 → 参与CI/CD实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值