1、软件的概念
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。
- 程序是按事先设计的功能和性能要求执行的指令序列。
- 数据是使程序能正常操纵信息的数据结构。
- 文档是与程序开发，维护和使用有关的图文材料。
2、软件生命周期
2.1、可行性分析
可行性研究的结果是客户做出是否继续惊醒这项工程的决定的重要依据，一般来说，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力。该阶段产出可行性研究报告。
可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。
2.2、需求分析
在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础。因此必须准确完整地体现用户的要求。这个阶段的一项重要任务，是用正式文档准确地记录堆目标系统的需求，这份文档通常称为规格说明书。
软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。
数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。
2.3、概要设计
定义实现需求的工作产品技功能、技术构架，定义设计准则及共通处理方针，分解划分功能模块，定义各功能模块的功能和业务处理，定义模块间的接口关系。典型的工作产品有《概要设计书》、《设计准则》及《共通处理方针》。一般包括系统技术构架，机能一览，机能迁移图，数据库逻辑设计，数据文件逻辑定义，系统各单位功能模块及接口定义，设计准则及共通处理方针（外观、操作、错误处理、日志、提示信息、异常处理、命名规约、编码规约等方针）等内容。
2.4、详细设计
定义各功能模块的功能单元的详细实现，包括接口的物理定义，明确数据库/数据文件的物理定义等。典型的工作产品：《详细设计书》。典型的内容包括各模块的功能单元实现的详细描述，数据库物理设计，数据文件物理定义，接口物理定义，状态码物理设计，输出信息（MSG/LOG）设计等内容。如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关 内容合并入概要设计说明书。
2.5、编码阶段
将系统设计阶段的设计内容用编码的方式实现，最终形成可运行的软件代码。在这个阶段需要在系统设计的框架内按照系统设计文档进行编码。这个阶段中不仅仅是 需要编码，还需要进行单元测试，每完成一个模块应进行单元测试。最后，进行集成，按软件组织结构的要求将各个子系统组合起来。
2.6、调试和测试阶段
这个阶段的关键任务是通过各种类型的测试使软件达到预定的要求。
测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。
2.7、运行与维护阶段
系统投入运行后，系统运行包括系统的日常操作、维护等。任何一个系统都不是一开始就很好，需要经过多次开发，运行，在开发，再运行循环不断上升。
2.8、废弃
系统终止运作，停止使用。
3、软件测试
3.1、软件测试概念
3.1.1、经典定义
软件测试(Software Testing)，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
3.1.2、标准定义
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
3.2、软件测试的目的
- 验证软件是否满足软件开发合同或项目开发计划、系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量需求。
- 通过测试发现软件缺陷。
- 确保产品是健壮的、适应用户环境的。健壮性即稳定性，是产品质量的基本需求。软件稳定的运行才不会中断用户的工作。
- 发现尽可能多的缺陷,成功的测试在于发现了迄今为止尚未发现的缺陷。
3.3、软件测试的原则
1）应当尽早地不断地进行软件测试。
2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。
3）程序员应避免检查自己的程序。
4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5）充分注意测试中的群集现象（80/20原则），百分之80的缺陷集中出现在百分之20的核心功能区域，在测试中发现缺陷越多的地方,存在的未被发现的缺陷也就越多。。
6）严格执行测试计划，排除测试的随意性。
7）应当对每一个测试结果做全面的检查。
8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
9）不可能执行穷尽测试，基于风险的测试是必要的。
10）杀虫剂悖论，相同的功能，相同的用例，多次执行，后几轮就慢慢找不到缺陷了。用例在每次执行完之后应该及时进行更新和维护，升级你的装备。
11）不同测试活动依赖不同的测试背景。金融公司测试，安全性就是第一位。电子商务测试，功能性则更加重要。
12）不存在缺陷的谬论：假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。
3.4、软件测试的对象
根据不同的测试阶段，每个阶段的测试对象都不一样：
需求阶段：需求文档
系统设计阶段：概要设计文档、详细设计文档
编码阶段：源代码
系统测试阶段：可运行程序
4、软件测试的分类
4.1、按测试阶段分类
4.1.1、单元测试(Unit Testing)
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义。单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
- 测试阶段：编码后
- 测试对象：最小模块
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：代码和注释+详细设计文档
- 测试方法：白盒测试
- 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
4.1.2、集成测试(Integration Testing)
集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。一般单元测试之后进行，由白盒测试工程师或者开发工程师执行测试。是一个白盒和黑盒相结合的测试。
- 测试阶段：一般单元测试之后进行
- 测试对象：模块间的接口
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：单元测试的模块+概要设计文档
- 测试方法：黑盒测试与白盒测试相结合
- 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
4.1.3、系统测试(System Testing)
对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测 试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。
- 测试阶段：集成测试通过之后
- 测试对象：整个系统（软、硬件）
- 测试人员：黑盒测试工程师
- 测试依据：需求规格说明文档
- 测试方法：黑盒测试
- 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
4.1.4、验收测试(Acceptance Testing)
验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试行动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
- 测试阶段：系统测试通过之后
- 测试对象：整个系统（包括软硬件）。
- 测试人员：主要是最终用户或者需求方。
- 测试依据：用户需求、验收标准
- 测试方法：黑盒测试
- 测试内容：同系统测试(功能...各类文档等)
4.2、按是否执行程序划分
4.2.1、黑盒测试(Black-box Testing)
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
4.2.2、白盒测试(White-box Testing)
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
4.2.3、灰盒测试(Gray-Box Testing)
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像 白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
4.3、按是否查看代码划分
4.3.1、手工测试(Manual testing)
由测试人员手工编写测试用例，由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。优点是自动化无法替代探索性测试、发散思维类无既定结果的测试。缺点是执行效率慢，量大易错。
4.3.2、自动化测试(Automation Testing)
就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。通常所说的自动化是指功能测试自动化。自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。
4.4、其他
4.4.1、冒烟测试(Smoke Testing)
在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。冒烟测试目的是确认软件基本功能正常，冒烟测试的执行者是版本编译人员。现基本执行对象为测试人员，在正规测试一个新版本之前，投入较少的人力和时间验证基本功能，通过则测试准入。
4.4.2、随机测试(Ad-hoc Testing)
随机测试主要是根据测试者的经验对软件进行功能和性能抽查。根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。
4.4.3、安全测试(Security Testing)
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。Findyou觉现在对安全知识的普及，大家意识都提上来了。比如现在越来越多的不支持HTTP协议，转用HTTPS等。
4.4.4、探索性测试(Exploratory testing)
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。探索性测试自动化暂时无法代替。
4.4.5、回归测试(Regression Testing)
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
4.4.6、α测试(Alpha Testing)
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
4.4.7、β测试(Beta Testing)
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别：
- 测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
-
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
-
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
5、软件质量
5.1、软件质量的定义
质量促进组织所关注的以行为、态度、活动和过程为结果的文化。通过满足客户和相关方的需求和和期望实现其价值。组织的产品和服务的质量取决于满足客户的能力，以及对相关方有益、无意的影响。产品和服务的质量不仅包括其预期的功能和性能，还涉及顾客对其价值和利益的感知.
- 质量是物体本身的属性，域形态，动态及其所属的空间无关，是物体的基本属性。
- 软件产品是否满足用户规定的显性或隐性需求的程度。
- 内部质量：软件内部的设计和静态测度是否合格。
- 过程质量：关注软件的整个生产流程是否规范是否合理。
- 外部质量：关注软件产品本身的功能和性能表现。
- 使用质量：关注软件在使用过程中易用性满意度的表现。
5.2、质量铁三角
1）流程（Flow）
*1*流程指一个或一系列有规律的行动，这些行动以确定的方式发生或执行，导致特定结果的出现。
*2*流程的好处
a）使得不可见的软件开发过程变得可见并可控；
b）流程驱动每一个研发人员的活动，减少了内耗，提高了效率。
2）技术
*1*技术的承载者是人
a）现有员工所承载的技术能力
b）公司发展过程中积累下来的技术能力
*2*技术从类型上分
a）开发技术
b）测试技术
d）结构工艺技术
3）组织
*1*通过技术和流程间接影响质量。
*2*组织对技术的影响
a）能确保具备相应技术能力的人去从事相应的活动
b）是否重视对技术的积累
4）流程、技术、组织三者之间的关系：
*1*组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；
*2*流程对于产品的成功有着关键作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量。
*3*对企业来说，人是技术的载体，技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。
5.3、软件质量特性
5.3.1、功能性(Functionality)
功能性是指软件在指定的使用环境下，满足用户显性或隐性需求的能力。
合适性
提供的功能是用户所需要的，及用户所需要的功能软件系统已提供。
准确性
此特性容易理解，在实际的工程应用中也常遇到，例如财务类软件系统提供给用户的功能是否满足用户对该功能的精确度要求。软件，如果不涉及特殊用户的需求（如科研机构的特种应有），精度一般都容易满足。
互操作性
软件系统与一个或多个周边系统进行信息交互的能力。例如，运行在windows操作系统上的应用软件，与运行在Linux系统上的软件进行通信，如:Linux系统是数据的发送方，把数据发送到windows系统上，在windows系统上运行的应用软件需能读出特有数据格式的能力，然后在界面上显示。
安全性
指软件系统保护信息和数据的能力。可以从以下两方面理解：
1、防止未得到授权的人或系统访问相关的信息或数据；
2、保证得到授权的人或系统能正常访问相关的信息或数据。
常见的安全性测试：
1、用户验证：登录密码验证（如windows登录验证，邮箱验证等）、IP地址访问限制等；
2、用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。例如windows 7操作系统，某些应用程序的运行必须以管理员身份才允许；
3、系统数据的保护:例如对系统文件、用户密码文件等进行隐藏，机密文件内容进行加密、备份；
功能性的依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。例如：在中国研发与生产的医疗设备如果要在美国上市销售必须经过FDA（Food and Drug Administration美国食品及药物管理局）的审核，并通过。
5.3.2、可靠性(Reliability)
可靠性是指软件是否能够一直在一个稳定的状态上满足可用性。
成熟性
软件系统防止内部错误扩散而导致失效的能力。测试过程中常遇到的例子如：模块A更改了某参数，但没考虑到某参数同时被模块B调用，由于模块B并未作相关更改，结果使得模块B的相关功能失效。
容错性
软件系统防止外部接口错误扩散而导致系统失效的能力。
例如：应用软件在操作过程中需操作一个文件，但由于此文件已遭破坏，由于缺少容错处理，结果执行文件操作时，软件崩溃。
易恢复性
系统失效后重新恢复原有功能、性能的能力，包括对原有能力恢复的程度与速度。
例如：我们经常使用的windows系统有时会遇到系统不响应的情况，只好按Reset或关掉电源重新开机。这种情况，当前未保存的数据当然是丢失了，系统重启后能否正常进入系统便是易恢复性的一种体现。
5.3.3、可用性(Usability)
可用性,是衡量用户使用软件需要付出多大的努力的质量属性。其中，我们经常提到的易用性就是可用性的一个重要方面，指产品易于学习和使用，可减轻记忆负担等，具体可从以下几方面进行理解。
易理解性
易理解性指用户在使用软件系统的过程中，展示给用户的信息是否准确、清晰、易懂，能帮助用户准确理解系统当前真实的状态，并指导其进一步的操作。
易学性
易学性是指软件提供相关的辅助手段，帮助用户学习使用它的能力。例如：是否具有在线帮助。在线帮助常见的有两种，一种是跟随功能而变的帮助，如Word、Excel中的菜单项鼠标提示（tips）；另一种是在线帮助手册，如同windows程序按快捷键F1自动调出帮助手册内容。
易操作性
易操作性指用户基本不用额外学习即能操作软件，包括多方面的内容。例如：
1、常用功能路径不要太深，最好能提供快捷键，且这些快捷键具有普适性（用户已广泛接受），如前面提到的windows程序**帮助功能的快捷键F1。目前有很多软件采用这种已符合人们的使用习惯的操作。
2、最好提供一键返回桌面的功能，这一点苹果的Iphone手机做得比较好，无论用户当前在什么位置，只要按下“返回桌面”主键，立即可退出。
3、操作尽量简单，例如软件的安装或升级，按提示点击“下一步”且不要太长的时间或多个选择路径。
5.3.4、效率(Efficiency)
效率，这里指衡量软件正常运行需要耗费多少时间及物理资源，是性能测试的重点内容。
时间效率
时间效率主要指软件系统在各业务场景下完成用户指定的业务请求所需的响应时间。
例如：我们在互联网上发表博文，点击“提交”后，一般情况都需等待几秒钟，然后自动跳转到博文显示页面，那么此等待时间，我们可以理解为系统响应的时间。
资源效率
资源效率主要指软件系统在完成用户指定的业务请求所消耗的系统资源，如CPU占有率、内存占有率、通信带宽占有率、软件内部消息包资源占有率等。例如不同业务功能之间，不同GUI界面相互之间的切换，如果切换过程中有明显的后影，或速度太慢，很可能资源占用方面没有处理好。
5.3.5、可维护性(Maintainability)
可维护性，衡量对已经完成的软件进行调整需要多大的努力，其又可分为下面四个子属性。
易分析性
指软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。这也是工程实践中很重要的一方面，可以减少缺陷定位的时间，提高开发人员工作效率。采用系统日志记录的方法，如同windows的事件查看器（eventvwr），把软件执行代码的轨迹或某些错误、状态进行记录，是一种常见的方法。
易改变性
指软件缺陷的修复容易被实施，这与软件的设计有着密切关系。例如设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合的代码，为未来可能的变化留有扩充余地，它的易改性会更好。
稳定性
指软件系统在长时间连续工作环境下能否正常工作，不出错，无异常情况等。测试人员常用长时间压力测试的方式检验软件的稳定性，稳定性与资源效率有紧密联系，例如内存的慢泄漏，时间越长，系统稳定性越差，内存资源占用越多，最后可能导致系统瘫痪。
易测试性
指从测试验证角度，软件存在可测试性的难易程度。例如：UI界面，提示框对话框，按钮响应状态变化等是很容易观察到的，可测试性强；有明确的输入输出数据，尽管此数据对于用户来说可能不容易被看到，但通过某种方法仍 可验证到，可测试性次子。对鉴于系统设计原因，某种用户场景难于验证，测试的条件苛刻，需特定的实验室条件，如高温高压等，这种情况需考虑改变软件内部状 态，通过发布特殊版本进行测试。易测试性作为可维护性的子属性之一，与质量是否存在必然的正向关系呢，即能不能说越容易测试的软件，其质量将越好。从工程 最佳实践来看，这种必然的关系倒并不成立，但反过来是成立的，越难验证的软件，其存在问题的风险将可能成倍增大。
5.3.6、可移植性(Portability)
可移植性，是衡量软件是否能够方便地部署到不同的运行环境中的能力,它有下面几个特性。
适应性
指软件系统无需做任何相应变动就能适应不同运行环境的能力，其中运行环境通常是指操作系统平台、数据库平台、硬件平台等。例如我们在项目常遇到的情况，某系统软件原来运行在windows XP操作系统上，但后来由于Microsoft推出了windows 7,windows 8，应用新系统的用户比比皆是，新用户需要某系统软件能在新平台上正常运行。这种因平台的变化，系统应用软件的适应性在设计之初是需考虑的。
易安装性
指平台变化后，成功安装软件的难易程度。有些软件可不作任何变化即可成功部署，有些需作部分变化，如安装过程增加用户选项等。对于软件的安装过程，能尽量考虑用户少参与，多一些自动安装过程会让用户更放心。
共存性
指软件系统在公共环境与其共享资源的其他系统共存的能力。这个特性表明我们在测试时不仅需要关注自身软件特性的实现，还要关注本软件是否影响了其他软件的正常功能。
关于共存性，笔者曾遇一个这样的案例，在应用程序进行输入中文时，只要打开紫光拼音，则软件将自动退出。还有一种是人为的限制，在已知情况下，软件A打开，限制软件B不能运行，有意防患，适合某特殊应用场景。
易替换性
指软件系统的升级能力，包括在线升级、打补丁升级等。易替换性相对于嵌入式产品软件系统来说，由于涉及硬件物料的更新换代，如某主控芯片、USB接口芯片的换代，还可能会触发底层驱动的升级。
6、软件缺陷
6.1、缺陷定义
软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。
6.2、缺陷类型
功能：影响了各种系统功能、逻辑的缺陷。
用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷。
文档：影响发布和维护，包括注释，用户手册，设计文档
软件包：由于软件配置库、变更管理或版本控制引起的错误
性能：不满足系统可测量的属性值，如执行时间，事务处理速率等
系统/模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
6.3、缺陷级别
致命(Fatal)：系统任何一个主要功能完全丧失、用户数据收到破坏、系统崩溃、悬挂、死机，或者危及人身安全。
严重(Critical)：系统的主要功能部分丧失、数据不能保存，系统所提供的功能或服务受到明显的影响。
一般(Major)：系统的部分功能没有完全实现，但不影响用户的正常使用，例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。
较小(Minor)：使操作者不方便或遇到麻烦，但它不影响功能的操作或执行，如个别的不影响产品理解的错别字文字排列不整齐等一些小问题。
6.4、缺陷状态
**或打开(Active or Open)：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。
已修正或修复(Fixed or Resolved)：已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证。
关闭或非**(Closed or Inactive)：测试人员验证后，确认缺陷不存在之后的状态。
重新打开(Reopen)：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复。
推迟(Deferred)：这个软件曲线可以在下一个版本中解决。
保留(on hold)：由于技术原因或者第三者软件的缺陷，开发人员不能修复的缺陷。
不能重现(Cannot duplicate)：开发不能重现这个软件缺陷，需要测试人员检查缺陷复现的步骤。
需要更多信息(Needmoreinfor)：开发能重现这个软件缺陷，但开发人员需要一些信息，如缺陷的日志文件、图片等。
重复(Duplicate)：这个软件缺陷已被其他的软件测试人员发现了。
不是缺陷(Notabug)：不是软件缺陷
需要修改软件规格说明书(Spec modified)：由于软件规格说明书对软件设计的要求，软件开发人员无法修复这个软件缺陷，必须要修改软件规格说明书。
6.5、缺陷的跟踪和处理
6.5.1、软件缺陷处理跟踪
软件缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，而对软件缺陷进行跟踪管理的目的是确保每个被发现的缺陷都能够及时得到处理。软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理，一般而言需要达到以下目标：
- 确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式（例如，延迟到下一个版本中修正或者由于技术原因不能被修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；
- 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段；
- 决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。
- 收集缺陷数据并在其上进行数据分析，作为组织过程改进的财富。
6.5.2、简单的缺陷生命周期
生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态的变化，来跟踪项目进度和软件质量。一个简单、优化的软件缺陷生命周期：
- 发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。
- 打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。
- 修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
6.5.3、复杂的缺陷生命周期
在实际工作中，软件缺陷的生命周期不可能像如上那么简单，需要考虑其它各种情况，给出了一个复杂的软件缺陷生命周期的例子，如图所示（此图来自https://blog.csdn.net/qq_33642117/article/details/54406625）：
6.6、缺陷的描述
软件缺陷的详细描述，如上所述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论：
- “步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里；
- “期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。
- “实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。
6.7、缺陷报告
任何一个缺陷跟踪系统的核心都是“软件缺陷报告”，一份软件缺陷报告详细信息如下：缺陷状态、缺陷标题、严重程序、优先级、产生频率、提交人、提交时间、所属项目/模块、指定解决人、指定解决时间、验证人、验证结果描述、验证时间、复现步骤、期望结果、实际结果、必要附件如log/图片