软件缺陷

0.软件缺陷的产生 软件缺陷 - Software Defect - Bug； 缺陷 的存在会导致软件产品在 某种程度上不能满足用户的需要 。 IEEE729-1983 对缺陷的标准定义： 从 产品内部 看，缺陷是软件产品开发或维护过程中 存在的错误、毛病等各种问题 ； 从 产品外部 看，缺陷是系统所需要实现的 某种功能的失效或违背 。 在软件的开发测试过程中项目组会特别关注软件缺陷的状况，这是因为一方面软件缺陷状况是项目质量和状态的重要指示数据，另一方面越到软件生命周期的后期修复软件缺陷的成本越高。 1.常见的缺陷 功能没有实现或与需求规格说明不一致； 界面、消息、提示、帮助不够准确或误导用户； 屏幕显示、打印结果不正确； 软件无故退出或没有反应; 边界条件未做处理，输入错误数据没有提示和说明； 运行速度慢或占用资源过多； 与常用的交互软件不兼容； 有时把尚未完成的小 功能 也归属于 软件缺陷 2.产生原因 在软件开发的过程中，软件缺陷的产生是不可避免的， ” 零缺陷 ” 是软件产品很难达到 一个 状态。 导致 软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷，概括来说这些原因可以归结为四大类。 软件本身的复杂性 和抽象性： 在产品真正完成之前，每个人对软件的理解都不完全相同

大家好，我是来自SAP成都研究院Revenue Cloud 团队的质量工程师 , yoyo。很高兴可以和大家分享我个人的工作体会。每个团队都有QE（Quality Engineer）, 相信大家对QE 的工作并不陌生，我也就不唠叨QE 的具体工作啦。作为从事软件质量保证工作十年的“老人”，我想就我个人的工作经历和大家探讨下软件质量保证工作的变迁。 当我们谈论软件产品的质量保证工作时，必然是基于某种软件开发模式上的。皮之不存，毛将焉附？脱离了软件开发模式，质量保证工作就是空中楼阁。相信大家都感受到，近十几年，软件开发模式不断涌现新的概念和词汇，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人应接不暇。我们首先要理解软件开发模式的变迁，然后才能进行与开发模式匹配的质量保证活动。 1. 瀑布开发 传统的瀑布模式如下图： 在这种模式下，测试活动仅仅是线性开发活动的后期活动。质量保证严格依赖于各个文档（需求文档，设计文档，测试计划和测试报告）以及评审会议，自动化测试可有可无。 2.增量开发 团队把产品的需求，设计，实现以及测试放在若干迭代周期里完成，每个迭代结束的交付物视为产品的增量，不要求增量达到能交付的要求，但需要能够基本可以工作。产品的交付仍然发生在最后，如下图所示： 增量开发的核心就是持续测试和持续集成

左耳朵耗子 发 表了 《 我 们 需要全 职 的 QA 吗 ？》 后 ， 一石激起千重浪 ， 赞 成者有之 ， 激烈反 对 者有之 ； 有人 说 文中 对QA 的定 义 不 对 ， 还 有人 说 以偏概全 …… 的确 ， 在需不需要 专职 的 QA 角色 这 个 问题 上 ， 很 难 用一个 简单 的 “ 需要 ” 或 “ 不需要 ” 来回答 。 前两天我写了一篇 对该 文的回 应 文章 ， 但由于文章写就得比 较仓 促 ， 很多 观 点来不及完整表述 ， 因此 ， 在 “ 真理越 辩 越明 ” 的原 则 下 ， 在 这篇 文章中 ， 我准 备 就 “ 我 们 需要什么 样 的 测试”这 个 问题说说 我自己的看法 。 首先要说明的是， 这篇文章完全不是讨论“我们是否需要专职QA”这个问题的 ， 也不是讨论“各种情况下QA或测试工程需要做什么” ，而是从我自身对测试的认知和个人经验出发，说一说我对不同特点的产品需要的测试的看法。 本文讨论的前提是：“ 不同的产品需要不同的测试 ”。当我提到“产品”时，除了产品本身所对外展现的特性外，还会隐含地包含了该产品开发团队的状况。这篇文章没有把行业作为一个划分的维度，是因为我相信，即使在同一个行业中，也存在各种截然不同的产品。 测试是为质量服务的，测试活动围绕质量进行。这个定义是我们今天讨论的出发点。ISO

软件当中为什么会引入缺陷？ 只要是人，都会犯错。即使是一个优秀的程序员，也会犯低级性的错误，根据数据统计，即便是优秀的程序员，开发的软件产品中，如果未经过测试，代码中遗留的缺陷至少在每千行代码6个以上。 常见的导致软件中存有缺陷的根源有： 1、缺乏有效的沟通，或者没有进行沟通 2、软件复杂度 3、编程错误 4、不断变更的需求 5、时间的压力 6、缺乏文档的代码 7、软件开发工具 8、人员的自大 缺陷的类型及严重级别 软件错误（software error） 软件缺陷（software defect） 软件故障（software fault） 软件失效（software failure） 软件失效机理可描述为：软件错误->软件缺陷->软件故障->软件失效 软件错误：在整个软件生存周期的每个阶段，都贯穿着人的直接或间接地干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的认为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。 软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号，多一个语句等，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。 软件故障：软件故障是指软件运行过程中出现的一种不希望或不接受的内部状态。比如

软件测试含义： 通过手动或者工具对被测对象进行测试操作，从而验证实际结果与预计结果之间是否存在差异。 软件测试作用： 1、发现和修复软件中存在的缺陷 2、记录软件运行过程中产生的数据，为以后的决策提供数据支持。 3、降低同类型产品开发遇到问题的风险。 软件测试原则： 测试证明软件存在缺陷 不能进行穷尽测试 缺陷存在集群现象 某些测试依赖特殊的执行环境 测试应该尽早介入：为了发现和更好的解决软件中的缺陷 杀虫剂现象：同样的测试用例不能重复的进行多次，软件会产生免疫 任何软件不可能是完美的 软件生命周期： 软件计划与可行性研究 需求分析 软件设计（概要设计和详细设计） 编码 软件测试 软件生存周期 软件生存周期 运行与维护 测试级别： 单元测试：软件的底层代码结构，类、函数、组件等 集成测试：将多个单元模块组合，验证他们之间的沟通桥梁是否能正常工作，重点测试不同模块的接口部分。 系统测试：由测试人员充当用户，对软件主体进行测试，以需求说明书为指导 验收测试： α测试：内测，软件是初步完成品，不对用户进行开放，α测试不能由程序员或测试人员完成，发现的错误可以在现场立刻反馈给开发人员，由开发人员及时分析和处理。α测试可以从软件产品编码结束后开始 β测试：公测，软件有了较大的改进后进行的测试 γ测试：针对正式版本的候选版本。 其他： 回归测试：修改代码后

＃1）Alpha测试 它是软件行业中最常用的测试类型。该测试的目的是在将其发布到市场或用户之前，确定所有可能的问题或缺陷。 Alpha测试在软件开发阶段的最后但Beta测试之前进行。尽管如此，作为此类测试的结果，可能会进行较小的设计更改。 Alpha测试是在开发人员的网站上进行的。可以为这种类型的测试创建内部虚拟用户环境。 ＃2）验收测试 的验收测试是由客户端和验证结束系统的流量到底是否是按照业务需求或不执行，如果是按照最终用户的需求。仅当所有功能部件均按预期工作时，客户端才接受该软件。 这是测试的最后阶段，此后该软件将投入生产。这也称为用户验收测试（UAT）。 ＃3）临时测试 名称本身表明该测试是在临时基础上执行的，即不参考测试用例，也没有针对此类测试的任何计划或文档。 该测试的目的是通过执行应用程序的任何流程或任何随机功能来发现缺陷并破坏应用程序。 临时测试是一种发现缺陷的非正式方法，项目中的任何人都可以执行。没有测试用例就很难识别缺陷，但是有时可能无法使用现有的测试用例来识别临时测试期间发现的缺陷。 ＃4）辅助功能测试 可访问性测试的目的是确定残疾人是否可以访问该软件或应用程序。 在这里，残疾是指聋哑，色盲，智障，盲人，老年和其他残疾群体。进行各种检查，例如用于视觉障碍的字体大小，用于色盲的颜色和对比度等。 ＃5）Beta测试 Beta测试是由客户执行的正式类型的软件测试

这是敏捷开发绩效管理的第四篇。（ 之一 ， 之二 ， 之三 ， 之四 ， 之五 ， 之六 ， 之七 ） 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。 敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。 “内向型”绩效及其导向 进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。 质量：“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。 成本：“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。 功能：“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。 此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码

软件测试的十三原则 一、ISTQB的6项原则 1、原则一： 测试显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。 2、原则二： 穷尽测试是不可能的。由于有太多的输入组合、有太多的路径，而且时间是有限的，无法做到完全的测试（100%测试覆盖率）。通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。 3、原则三： 测试尽早介入。软件项目一启动，软件测试就应开始，也就是从项目启动的第一天开始，测试人员就应参与项目的各种活动和开展对应的测试活动。测试工作进行的越早，软件开发的劣质成本就越低，并能更好的保证软件质量。例如：在代码完成之前，可以进行各种静态测试，主导或积极参与需求文档、产品规格说明书等的评审，将问题消灭在萌芽阶段。 4、原则四： 缺陷集群性。版本发布前进行测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。一段程序中发现的错误数越多，意味着这段程序的质量越不好。错误集中发生的现象，可能和程序员的编码水平、经验和习惯有很大的关系，也可能是程序员在写代码时情绪不够好或不在状态等。如果在同样的测试效率和测试能力的条件下，缺陷发现的越多，漏掉的缺陷就越多。这也就是著名的Myers反直觉原则：在测试中发现缺陷多的地方，会有更多的缺陷没被发现

软件测试 软件的定义 软件(software)、硬件(hardware）、程序(program）、文档(document） 软件=程序（包括数据）+文档； 缺陷的定义 1.从产品外部看， 缺陷是软件产品开发或维护过程中存在的 错误 、 毛病 等各种问题； 2. 从产品内部看，缺陷是系统所需要实现的某种功能的 失效 或 违背 3. 简单的说，用户在软件使用过程中遇到的任何软件 错误 、 异常 都可以称之为“软件缺陷”； 计算机基础 裸机也包含软件？ 裸机包含软件，主要是 BIOS 程序（Basic input/output system 基本输入/输出系统）； 常见的操作系统？ Windows、Unix、Linux、苹果 软件分类 基本分类 a. 系统软件：操作系统、操作系统的补丁程序、驱动程序（操作系统的内核程序通过调用硬件的驱动程序完成硬件管理功能）； b. 应用软件：；； 按照软件结构分类 a. 看软件的运行是否基于网络 -----不是，单机软件； -----是，分布式软件； 操作系统的主要功能？ 硬件（设备）管理：通过驱动程序调度控制硬件设备； 进程管理：对运行的程序进行管理； 存储（内存）管理：使小内存可以运行大程序； 文件管理：管理文件和文件夹； 如何区分C/S和B/S结构软件？ 主要看客户端需不需要安装专门的软件？ - 需要—C/S - · 不需要—B/S 来源：

Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。 操作系统 这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。 浏览器 对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。 不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。 其它（这个“其它”非常重要） 对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。 对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响