软件测试知识整理
软件测试
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试常用术语
1、软件【Software】
软件（software）是计算机中与硬件（hardware）相结合的一部分，包括程序（program）和文档（document）。用一个等式表示为：软件＝程序＋文档。其中，“程序”指的是能够实现某种功能的指令的集合，如C语言程序，Java程序等；“文档”指的是在软件开发、使用和维护过程中产生的图文集合，如《系统需求规格说明书》、《用户手册》、readme，甚至是一些软件市场宣传资料，包装文字和图形等。
【备注：软件测试绝不等同于程序测试，文档测试也是软件测试的一个重要组成部分。通常，程序测试主要包括程序逻辑功能、界面、性能、易用性、兼容性、安装等的测试；文档测试主要包括文档内容和截图的校验，排版风格的检查，错别字的校验等】
2、客户端/服务器【C/S】
C指的是客户端（Client），S指的是服务器端（Server）,这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ、MSN和各种网络游戏就属于C/S结构的软件。
【备注：C/S结构的软件过去比较流行，但是不便于升级和维护，现在逐渐被B/S结构软件所取代】
3、浏览器/服务器【B/S】
B指的是浏览器（Browser），S指的是服务器（Server），这种软件同样是基于局域网或互联网的，它与结C/S构软件的区别就在于，不需要安装客户端（client），只需要有IE等浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件。
【备注：B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点】
4、缺陷【Bug/Defect】
软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题。
【备注：这个定义是判断一个软件问题是否是Bug个唯一标准】
5、软件测试【Software Testing】
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别（1983，IEEE软件工程标准术语）。
6、测试环境【Testing
Environment(TE)】
软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用一个等式来表示：测试环境＝软件＋硬件＋网络。其中，“硬件”主要包括PC机（包括品牌机和兼容机）、笔记本、服务器、各种PDA终端等；“软件”主要指软件运行的操作系统；“网络”主要针对的是C/S结构和B/S结构的软件。
【备注：作为一个合格的软件测试工程师，不仅要熟悉软件的知识，也要了解硬件和网络的相关知识】
7、测试用例【Test Case(TC)】
指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。用一个等式来简单表示：测试用例＝输入＋输出＋测试环境。其中，“输入”包括测试数据和操作步骤；“输出”指的是期望结果；测试环境指的是系统环境设置。
8、黑盒测试【Black-Box Testing】
通俗：指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
定义：是把测试对象当做看不见内部结构的黑盒，在完全不考虑程序内部结构和处理过程的基础上，测试者仅根据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。又称功能测试或数据驱动测试。
备注：黑盒测试既包括功能测试，也包括性能测试。
9、白盒测试【White-Box
Testing】
通俗：指的是把盒子盖打开，去研究里面的源代码和程序结构。
定义：一种按照程序内部逻辑结构和编码设计结构测试数据并完成测试的测试方法。又称结构测试或逻辑驱动测试。
10、灰盒测试【Gray-Box Testing】
可以把它看作是黑盒测试和白盒测试的一种结合。
11、静态测试【Static Testing】
是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
12、代码走查【Walkthrough】
静态测试的一种方法，由开发组内部进行，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
13、代码审查【Inspection】
静态测试的一种方法，由开发组内部进行，采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。
14、技术评审【Review】
静态测试的一种方法，由开发组、测试组和相关人员（QA、产品经理等）联合进行，采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。
15、动态测试【Dynamic Testing】
是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
16、单元测试【Unit Testing】
是指对软件中的最小可测试单元进行检查和验证。例如，在C语言中，单元一般指1个函数；Java里，单元一般指1个类；在图形化的软件中，单元也可以指1个窗口、1个菜单等。
17、桩模块【Stub】
是指模拟被测模块所调用的模块。
18、驱动模块【Driver】
是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块，并输出结果。
19、集成测试【Integration Testing】
是指将通过测试的单元模块组装成系统或子系统，在进行测试，重点测试不同模块的接口部分。
20、系统测试【System Testing】
指的是将整个软件系统看作是一个整体测试，包括对功能、性能的测试，以及对软件所运行的软、硬件环境的测试。
21、验收测试【Acceptance Testing】
指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
① α测试：
验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试。
② β测试：
验收测试的一种，指的是内测后的公测，即完全交给最终用户测试。
22、功能测试【Function Testing】
是黑盒测试的一种，它检查实际软件的功能是否符合用户的需求。
23、界面测试【UI Testing】
UI是User Interface，即用户界面的缩写。一般情况下，都把软件的界面测试用例同软件的逻辑功能测试用例分开去写。
24、易用性测试【Usability Testing】
是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
25、安装测试【Installation Testing】
这里的安装测试是指广义上的，包括安装、卸载。
26、兼容性测试【Compatibility Testing】
兼容性测试包括硬件兼容性测试和软件兼容性测试；硬件兼容性主要是指软件运行的不同硬件平台的兼容性，如PC机、笔记本、服务器等；软件兼容性主要是指软件运行在不同操作系统等软件平台上的兼容性。
27、性能测试【Performance Testing】
是指对软件的运行反馈速度、所消耗系统资源等各种性能指标的测试。
28、可靠性测试【Reliability Testing】
也叫稳定性测试，是指连续运行被测系统，检查系统运行时的稳定程度。人们通常用MTBF（Mean Time Between Failure）来衡量系统的稳定性，MTBF越大，系统的稳定性越强。
29、负载测试【Load Testing】
是性能测试的一种，通常是指被测系统在其能忍受的压力<极限范围之内连续运行>，来测试系统的稳定性。
30、压力测试【Stress Testing】
是性能测试的一种，通常是指持续<不断地>给被测系统增加压力，直到将被测系统<压跨为止>，用来测试系统所能承受的最大压力。
31、回归测试【Regression Testing】
是指对软件的新版本测试时，重复执行上一个版本测试时的用例。
32、冒烟测试【Smoke Testing】 又名：ad-hoc
是指在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
33、随机测试【Random Testing】
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
34、软件质量保障【Software Quality Assurance(SQA)】
为了确保软件<开发过程和结果符合预期的要求>，而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。
35、软件能力成熟度模型【Capability Maturity Model(CMM)】
CMM就是SQA用来监督项目的一个标准质量模型，是由卡耐基－梅隆大学于20实际80年代制定的，最初只是应用于本校的软件项目开发，后来逐渐推广为主流的行业标准。CMM共为5级：初始级、可重复级、已定义级、已管理级和优化级。
36、有效等价类【Valid Equivalence Class】
是指符合《需求规格说明书》，合理地输入数据集合。
37、无效等价类【Invalid Equivalence Class】
是指不符合《需求规格说明书》，无意义地输入数据集合。
38、软件生命周期【Software Life Cycle】
是指软件开发和测试全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。
39、黑盒测试工具【Black-Box Testing Tools】
是指测试功能或性能的工具，主要用于系统测试和验收测试；其又可分为功能测试工具和性能测试工具。
40、白盒测试工具【White-Box Testing tools】
是指测试软件的源代码的工具，可以实现代码的静态分析、动态测试、评审等功能，主要用于单元测试。
41、测试管理工具【Testing Management Tools】
是指管理整个测试流程的工具，主要功能有测试计划的管理、测试用例的管理、缺陷跟踪、测试报告管理等，一般贯穿于整个软件生命周期。
42、测试工作的正确四步曲
① What to
do 第一步, 确立测试范围和对象, 如果这一步漏了,后面的质量全打折扣--测试计划
②
How to do 第二步, 决定用什么测试技术或手段来测试这些测试对象 --测试方案
③ When to
do 第三步, 决定先测试哪些测试对象和先应用哪些测试技术 --测试策略
④
Automation 第四步,
尽可能把how to do的工作都自动化,从而提升执行效率(仅仅是执行效率) --测试效率
43、产品所有的架构和设计缺陷 ：
异常处理；功能组合处理；算法选取考虑不周全；以及非功能属性的设计需求。
44、需求的质量也是有维度的：
二义性、可测性、完整性、前后一致性、可实现性、必要性。
第一章 软件工程要点
一、软件的定义及其特性
1、定义：软件包含 程序、数据和文档
（1）当运行时，能够提供能够提供所要求功能和性能的指令或计算机程序集合；
（2）改程序能够具有满意的处理信息的数据结构；
（3）描述程序功能需求以及程序如何操作和使用所要求的文档。
2、特性：
（1）软件是一种逻辑实体，具有抽象性
（2）软件没有明显的制作过程
（3）软件在使用过程中没有磨损、老化的问题，但有退化问题
（4）软件对硬件和环境有着不同程度的依赖性
（5）软件的开发至今尚未完全摆脱手工作坊式的开发方式，生产效率低
（6）软件是复杂的，而且以后会更加复杂
（7）软件的成本相当昂贵
（8）软件工作牵涉很多社会因素
二、软件危机的定义，产生原因及消除方法
1、定义：
落后的软件生产维护方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。概括地说主要包含两方面的问题：如何开发软件，怎样满足对软件日益增长的需求；如何维护数量不断膨胀的已有的软件。
2、产生原因：
（1）主要原因是对用户的需求不明确；
（2）缺乏正确的理论指导；
（3）软件开发规模越来越大；
（4）软件开发复杂程度越来越高。
3、消除方法：主要是 组织管理 + 技术措施
①应当对软件有个正确的认识（程序+数据+文档）；
②在软件开发过程中学会研制和使用软件工具，用来辅助进行软件项目管理和技术生产；
③必须充分认识到软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
三、软件工程的定义，三要素，目标，方法及原则
1、定义：软件工程是一门研究如何系统化、规范化、数量化等工程原则和方法去进行软件开发和维护的学科。
2、三要素：方法、工具和过程。
3、目标：生产具有正确性、可用性、开销适宜、进度保证并且项目成功的软件产品。
4、方法：项目计划与估算 → 软件系统需求分析 → 数据结构 → 系统总体结构的设计 → 算法过程的设计 → 编码 → 测试
5、原则：
①采取适宜的开发模型，用以控制易变的需求；
②采用合适的设计方法，支持软件的模块化、抽象化等设计要求；
③提供高质量的工程支持；
④重视开发过程的管理。
四、软件生命周期的定义、阶段、模型 以及 敏捷开发
1、定义：同任何事物一样，软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（又称软件生命周期），是指软件开发和测试全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。
2、阶段： ①可行性分析和开发项目计划； ②需求分析； ③设计（概要设计和详细设计）； ④编码； ⑤测试； ⑥维护。
3、模型： ①瀑布模型 ②迭代式模型 ③快速原型模型 ④增量模型 ⑤螺旋模型 ⑥V模型
4、敏捷开发：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法；核心思想是：测试驱动开发，测试与开发并行；常用方法有：XP（策划、设计、编码、测试。）
五、软件体系结构
1、软件体系结构大体上分为主机终端模式、文件服务器模式、C/S模式和B/S模式。
2、C/S结构 ： (Client/Server)
（1）C/S结构的节本原则是将计算机应用任务分解成多个子任务，由多台计算机分工完成，克服终端/主机结构中主机负担过重、用户界面不友好等缺点。
（2）C/S系统由3个基本部分组成：客户机、服务器和中间件。
（3）C/S体系结构的技术特点 ：C/S根据服务的观点对功能进行明确划分，共享资源，不对称协议，定位透明性，基于消息的交换，可扩展性。
3、B/S结构 ： （Browser/Server） 浏览器/服务器模式
（1）B/S模式是指在TCP/IP协议簇的支持下，以HTTP为传输协议，客户端通过Browser访问Web服务器以及与之相连的后台数据库的技术及体系结构。
（2）B/S结构由客户端、应用服务器和数据层（数据库系统和遗留系统）组成。
（3）B/S结构的优势在于： 简化了客户端；简化了系统的开发与维护；用户操作变得更简单；适用于网上信息发布。
六、惠普应用生命周期管理（ALM）
1、惠普应用生命周期管理（ALM）主要应用于整个应用生命周期中管理跨项目的应用发布： ①项目计划和跟踪；②跨项目报告；③资产共享和重用；④流程标准化；⑤缺陷共享；⑥无限的高可用服务器。
2、这样带来的好处有： ①对于跨项目的计划，项目跟踪，趋势和实时应用状态提高可见性；②集中管理，保证一致的流程和规范，减少成本；③减少重复工作，共享最佳实践，降低成本，提高效率。
第二章 软件测试基础
七、软件测试的定义，目的，原则，包含的概念，质量的度量方法以及与软件开发之间的关系
1、软件测试
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别（1983，IEEE软件工程标准术语）。
2、软件测试的目的：验证需求
（1）发现软件缺陷，提高软件质量；
（2）验证软件是否满足用户的需求；
（3）建立软件质量的信心。
3、软件测试的原则：
（1）足够好原则：good-enough原则；
（2）二八原则（BUG的80-20原则）；
（3）测试显示缺陷的存在；
（4）穷尽测试是不可能的；
（5）测试尽早进入；
（6）杀虫剂悖论（更新修改用力测试库）；
（7）测试活动依赖测试背景；
（8）不存在缺陷（就是有用系统）的谬论。
4、软件测试包含的概念
（1）软件测试是对程序或系统能否完成特定任务建立信心的过程，也是帮助识别开发完成（中间或最终版本）的计算机软件（整体或部分）的正确度、完全度和质量的软件程；
（2）软件测试就是为了发现程序中的错误而分析或执行的过程，或者说是根据软件开发各阶段的规格说明和程序的内部而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程；
（3）软件测试的目标在于尽可能地发现错误（缺陷）；
（4）软件测试的目的在于鉴定程序或系统的属性或功能的各种活动，是软件质量的一种度量，是SQA的重要值域
（5）用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求（遗漏、超出）或是弄清楚预期结果与实际结果之间是否有差别。
5、如何度量
对于软件测试的度量，应该从对软件产品的度量转移到软件测试产出物的度量，以及测试过程的度量。
6、软件测试和软件开发的关系
软件开发是自顶向下，逐步细化的过程。软件计划阶段定义软件作用域；软件需求分析阶段建立软件信息域、功能和性能需求、约束等；软件设计阶段把设计用某种程序设计语言转换成程序代码。测试过程依相反顺序自底向上，逐步集成的过程。对每个程序模块进行单元测试，消除程序模块内部逻辑和功能上的错误和缺陷；对照软件设计进行集成测试、检验和排除子系统或系统结构上的错误；对照需求，进行确认测试；最后从系统整体出发，运行系统，看是否满足。
八、软件测试工作的内容，流程，测试工具的作用以及人们对测试工作的误解
1、软件测试工作包括的内容
测试工作的流程、测试工具的支持、测试人员的素质
2、流程
（1）需求阅读与评审
（2）用例设计与评审
（3）环境搭建
（4）软件测试
（5）编写有关测试文档（测试用例设计、测试报告、问题报告）
（6）SE与测试经理审核
3、测试工具的支持
（1）提高工作效率
（2）保证测试的准确性
（3）有些测试很难开展，必须使用工具（如性能测试）
（4）测试工具很好的保证测试工作的规范性和一致性
（5）测试工具体现了先进的测试思想、方法和技术
4、对测试工作不正确的认识
（1）整体认识上重开发轻测试
（2）软件开发完成后进行软件测试
（3）软件测试时为了证明软件的正确性
（4）软件发布后如果发现质量问题，那是软件测试人员的错
（5）软件测试要求不过，随便找个人就行
（6）软件测试是软件开发的对头
（7）软件测试是测试人员的事情，与程序员无关
（8）项目进度吃紧时少做些测试，时间富裕时多做些测试
（9）软件测试时没有前途的工作，只有程序员才是软件高手
（10）软件测试就是程序测试，测试发现了错误就说明程序员编写的程序有问题
（11）期望用测试自动化代替大部分人工劳动
（12）所有软件缺陷都可以修复
（13）认为软件测试文档不重要
（14）期望短期通过增加软件测试投入，迅速达到零缺陷率
（15）规范化软件测试会增加项目成本
第三章 基于生命周期的软件测试
九、生命周期测试包含的内容、测试计划以及基于风险的软件测试方法
1、生命周期测试包含的内容：生命周期测试应伴随整个软件开发周期，此时测试的对象不仅仅是程序，需求、功能和设计同样需要测试：①在项目需求分析阶段就要开始参与，审查需求分析文档、产品规格说明书；②在设计阶段，要审查系统设计文档、程序设计流程图、数据流图等，③在代码编写阶段，需要审查代码，看是否遵循代码的变量定义原则、是否有足够的注释行等。 测试与开发同步进行，有利于尽早的发现问题，同时缩短项目的开发建设周期。
2、测试计划：
（1）测试计划是描述要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。5W1H → what where when why who how
（2）测试计划最关机的一部就是将软件分解成单元，写成测试需求。这样做的好处有：①测试需求是测试设计和开发测试用例的基础，分成单元可以进行更好的设计；②详细的测试需求使用来衡量测试覆盖率的重要指标；③测试需求包含各种测试设计和开发，以及所需资源。
3、基于风险的软件测试
（1）风险可以定义为事件、危险、威胁或情况等发生的可能性以及由此产生的不可预料的后果，即潜在的问题。风险级别由出现不确定时间的可能性以及出现后所产生的影响两个方面来决定。
（2）基于风险的软件测试（Risk Based software Testing，RBT）是指首先评估被测软件的风险，然后根据不同的风险采用不同的测试力度。
（3）基于风险的软件测试的方法：①列出风险列表；②对每个风险进行分析和评估，确定风险级别；③进行考察每项风险的测试；④当风险消失而新的风险出现的时候，调整测试策略。
十、生命周期各个测试阶段的测试需求
1、需求阶段测试：在需求阶段测试中，需要建立风险列表，进行风险分析和检查，以此确定项目的风险；建立控制目标，确保有足够的控制力度来保证项目的开发与测试。在彻底的分析需求的充分性后，生成基础的测试用例。
2、设计阶段测试：①分析测试要素②给测试要素打分③对设计进行评审④检查修改的部分。
3、编码阶段测试：在编码阶段，测试需要解决的首要问题是编码是否和设计一致；其次是系统是否可维护，系统的规格说明是否正确的实现，编码是否按照既有的标准进行，是否有充分的测试计划评价可执行的程序，程序是否提供足够的文档资料，程序内部是否有足够的注释行等。
4、测试阶段：
（1）典型的测试类型：
①手册和文档测试：测试软件的操作说明文档是否全面、正确、简单和满足标准，即测试软件文档的易用性；
②一致性测试：包括测试软件的授权、安全性和性能是否达到需求分析中的要求；
③符合性测试：验证软件系统和相应标准的符合程度，如授权规则是否正确实现，安全方法是否合适，是否按照相应的标准、指南、规程进行测试等。
④功能测试：运行部分或全部系统，确认用户的需求被满足这包括可靠性、文件完整性、审计追踪、功能正确性、互连等项测试，检验系统在各种环境和重复的事物条件下能否正确的执行系统的需求，控制计算机文件的完整性，追踪原始事物到总的控制，按用户规定的需求测试应用功能，以及与其他应用系统能否正确的通信。
⑤覆盖性测试：检验软件代码中各语句及分支等是否全部执行到（死代码等）。
⑥性能测试：通过测量响应时间、CPU使用和其他量化的操作特征，评估软件系统的性能指标。（量化标准/时间/硬件要求）
⑦压力测试：以大信息量的数据进行输入，测试软件的性能。（在线系统必须进行压力测试）
⑧强度测试：对系统进行验收测试，测试系统对极端条件的反应，标识软件的薄弱点，指出系统能够承受的正常工作量。
⑨操作测试：在没有开发人员指导和帮助的情况下，由操作人员进行测试，以评估操作命令的完整性和系统是否容易操作。
⑩恢复测试：故意使系统失败，测试人工和自动的恢复过程。
（2）测试用例
①IEEE称测试用例为“编写用于输入的实际数值和预期输出结果数据。测试用例也明确指定使用具体测试用例产生的测试程序的任何限制”。
②在设计测试用例的输入数据时，要包含合法和非法的输入，要尝试将测试数据违反程序的规则进行输入；在设计输出数据时，要描述测试用例的预期结果。
③测试用例包含的基本信息：标识符、输入说明、输出要求、环境要求、特殊过程要求、用例之间的依赖性。
（3）测试报告：测试总结报告的内容有：测试结果数据，测试任务、测试集合和测试事件的描述，目前的软件状态描述，各个阶段的项目测试总结等。
5、安装阶段测试
6、验收阶段测试
7、维护阶段测试
第四章 软件测试分类与分级
十一、软件测试分类
1、对于软件测试，可以从不同的角度进行分类：
（1）从是否关心软件内部结构和具体实现的角度：白盒测试、黑盒测试、灰盒测试
（2）从软件开发过程的角度：单元测试、集成测试、系统测试、验收测试
（3）从是否执行程序的角度：静态测试和动态测试
（4）从程序执行时是否需要人工干预的角度：人工测试和自动化测试
（5）从测试实施组织的角度：开发方测试、用户测试、第三方测试
2、计算机软件配置项：
计算机软甲配置项缩写为CSCI，是为独立的配置管理（技术状态管理）而设计的且能满足最终用户需求的一组软件，简称软件配置项。
3、基于CSCI的软件测试分类：
单元测试、集成测试、配置项测试（确认测试）、系统测试、验收测试和回归测试。
十二、各类测试的名词解释
1、单元测试：单元测试又称模块测试，是针对软件设计的最小阶段（程序模块或功能模块）进行正确性检验的测试工作。
2、集成测试：集成测试也叫组装测试、联合测试，是一种旨在暴露接口以及集成组件/系统间交互时存在缺陷的测试。
3、配置项测试：配置项测试又称确认测试，是在完成集成测试后，依据确认测试原则，针对软件需求规格说明进行的测试，以确认所开发的软件系统能否满足规定的功能和性能需求。
4、系统测试：系统测试是为判断系统是否符合规定而对集成的软、硬件系统进行的测试活动。它是将已经集成好的软件系统作为计算机系统的一部分，与计算机系统硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列严格有效的测试。
5、验收测试：验收测试通常有使用系统的用户来进行测试，目的是确保系统功能、系统的某部分或特定的系统非功能性特征满足验收准则，发现缺陷不是验收测试的主要目标。
6、回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
第五章 软件缺陷管理
十三、什么是软件缺陷？软件缺陷的五条规则？产生软件缺陷的原因？一般如何描述和分类软件缺陷？
1、软件缺陷的定义：
（1）从产品内部来看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
（2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
2、软件缺陷的五条规则
（1）少：软件未实现产品说明书要求的功能；
（2）错：软件出现了产品说明书指明不应该出现的错误；
（3）多：软件出现了产品说明书未提到的功能；
（4）软件未实现产品说明书虽未明确提及但应该实现的目标；
（5）软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户认为不好。
3、产生软件缺陷的原因：
（1）需求的不完善定义；
（2）客户—开发者通信失败；
（3）对软件需求的故意偏离；
（4）逻辑设计错误；
（5）编码错误；
（6）不符合文档编制与编码规定；
（7）测试过程不足；
（8）规程错误；
（9）文档编制错误。
4、软件缺陷的描述：
对软件缺陷进行有效的描述涉及以下内容：
（1）可追踪信息：缺陷ID
（2）缺陷的基本信息
①缺陷标题 ②缺陷的紧急程度 ③缺陷的严重程度 ④缺陷提交人 ⑤缺陷提交时间 ⑥缺陷所属项目/模块 ⑦缺陷指定解决人 ⑧缺陷指定解决时间 ⑨缺陷处理人 ⑩、缺陷处理结果描述 11、缺陷处理时间 12、缺陷验证人 13、缺陷验证结果描述 14、缺陷验证时间
（3）对缺陷的详细描述
（4）测试环境说明
（5）必要的附件
（6）从统计的角度上出发，可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。
5、软件缺陷的分类
（1）在对缺陷进行分类之前，首先定义缺陷的属性：属性名称描述、缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源。
（2）缺陷分类方法
①Putnam分类法：需求缺陷、设计缺陷、文档缺陷、算法缺陷、界面缺陷和性能缺陷。
②军标分类法：程序错误、文档错误和设计错误
③Thayer分类法：16类：计算错误、逻辑错误、I/O错误、数据错误加工、操作系统和支持软件错误、配置错误、接口错误、用户需求改变、预置数据库错误、全局变量错误、重复的错误、文档错误、需求实现错误、不明性质错误、人员操作错误、问题。
④IEEE分类法：分类过程由识别（RR）、调查（IV）、行动计划（AC）、实施处理（DP）四个步骤组成，每一个步骤包括三项活动：记录、分类和确定影响（IM）。
⑤正交缺陷分类法：由IBM公司提出。
缺陷特征包括8个属性：发现缺陷的活动、缺陷影响、缺陷引发事件、缺陷载体、缺陷年龄、缺陷来源、缺陷类型和缺陷限定词。
缺陷类型被分为8大类：赋值、检验、算法、时序、接口、功能、文档、关联
（3）按照缺陷的生命周期划分：new（新建）、confirmed（确认）、fixed（解决）、closed（关闭）、reopen（重新打开）。
每个缺陷都是由测试人员发现并提交的，这个状态标注为new（新建）；缺陷被提交后，有相应的负责人接受，即confirmed（确认）状态；相应的负责人员解决了该缺陷后，该缺陷的状态就改为fixed（解决）；并且将其发给测试人员进行回归测试，如果确定已经解决，那么缺陷的状态就改为closed（关闭），否则就需要返还给该缺陷的负责人重新修正；有的缺陷在以前的版本中已经关闭，但是在新的版本中又重新出现，则需要将其状态改为reopen（重新打开）。
十四、软件缺陷管理
1、软件缺陷管理是软件测试的一个有机组成部分，是CMM2级的要求。在CMM第二级的软件组织中，软件项目从自身的需求出发，制定项目的缺陷管理过程。项目组将完整记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
2、却见缺陷跟踪管理的目标“
（1）确保每个被发现的缺陷都能够解决；
（2）手机缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；
（3）收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
3、缺陷记录日志用于缺陷数据的收集，收集软件缺陷数据的步骤如下：
（1）为测试和同行评审中发现的每个缺陷做记录；
（2）对每个缺陷记录足够详细的信息，以便以后能更好地了解这个缺陷；
（3）分析这些数据以找出哪些缺陷类型引起大部分的问题；
（4）设计出现和修复这些缺陷的方法（缺陷排除）。
4、软件缺陷管理流程图：
十五、软件缺陷的度量、分析和软件缺陷报告
1、软件缺陷度量
（1）缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有效而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。
（2）主要的度量方法：
①缺陷密度 = 已知的缺陷数量 / 产品规模；
②缺陷率：一定时间范围内的缺陷数与错误几率的比值；
③缺陷清除率：缺陷清除率 = 已发现的缺陷 / 潜在的缺陷（已发现的缺陷+以后发现的缺陷）；
④缺陷趋势：缺陷趋势是在一定周期时间或一定阶段内，产生/发现缺陷的动向或规律，是缺陷率按时间或按阶段增长/下降的动态分布；周期可以是天、周、月，阶段可以是版本；通常用缺陷趋势图来表示缺陷趋势；
⑤缺陷发现率 = ∑提交缺陷数（个） / ∑执行测试的有效时间（小时）
2、软件缺陷分析
（1）缺陷分析是将软件开发各个阶段产生的缺陷信息进行分类和汇总统计，计算分析指标，编写分析报告的活动。
（2）通过软件缺陷分析可以发现各类缺陷发生的概率，掌握缺陷集中的区域、明确缺陷发展趋势、挖掘缺陷产生的根本原因，便于有针对性的提出遏制缺陷发生的措施，降低缺陷数量。
（3）缺陷分析的步骤：
①记录缺陷；
②对于测试出来的缺陷进行缺陷分类，找出关键的缺陷类型，进一步分析其产生的原因，针对性的制定改进措施；
③进行缺陷预防分析，它是整个缺陷分析过程的核心；
④编制缺陷分析报告，绘制缺陷分析图。
3、软件缺陷报告：
（1）缺陷报告记录了缺陷发生的环境，如各种资源的配置情况、缺陷的再现步骤以及缺陷性质的说明。更重要的是还记录着缺陷的处理过程和状态。
（2）报告软件缺陷的基本原则：
①尽快报告软件缺陷；
②有效的描述软件缺陷；
A.短小精悍：只解释事实和演示、描述软件缺陷必须的细节，解释错误的实质；
B.单一：每个缺陷报告只针对一个软件缺陷；
C.使用IT业界惯用的表达术语和表达方式；
D.明确指明错误类型。
③在报告缺陷时不作任何评价；
④确保缺陷可以重现。
第六章 软件测试过程及测试过程管理
十六、软件测试过程的模型、活动、内容和度量
1、软件测试过程模型
（1）V模型
①单元测试和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的标准；有测试人员和用户进行软件的确认测试和验收测试，追溯软件需求额说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。
②V模型的局限性在于没有明确的说明早期的测试，不能体现“尽早的和不断的进行测试”的原则。
（2）W模型（V&V：验证和确认）
（3）H模型
2、软件测试过程活动
提取测试需求，确定测试策略，制定测试计划，开展测试设计，执行测试用例，分析测试结果
3、软件测试过程内容
测试过程的主要内容是 ： 基于项目目标，制定测试计划，确定测试策略，选定测试方法，排定优先级，建立里程碑，组织测试资源（测试团队、软硬件资源等）；然后，以测试计划为基础，明确测试需求、测试对象和测试目标及功能与性能指标；最后，依据测试计划和测试设计，测试人员可以开展测试的相关活动（开发和设计测试用例、选定测试工具、设计自动化测试框架、编写测试脚本、执行测试用例及测试脚本、分析测试结果、发现和报告缺陷等）。
4、软件测试过程度量
4个度量指标：
（1）测试覆盖率 = 已设计测试用例的需求数 / 需求总数
（2）测试执行率 = 已执行的测试用例数 / 设计的总测试用例数
（3）测试执行通过率 = 执行结果为“通过”的测试用例数 / 实际执行的测试用例总数
（4）缺陷解决率 = 已关闭的缺陷数 / 缺陷总数
十七、软件测试过程管理
1、软件测试过程图：
2、软件测试过程管理的理念
（1）今早测试；
（2）全面测试；
（3）全过程测试；
（4）独立的迭代测试。
3、测试需求的收集
（1）与被测软件相关的各种文档资料；
（2）与客户或系统分析员的沟通；
（3）业务背景资料；
（4）正式与非正式的培训；
（5）其他（如新旧系统）。
4、测试策略
测试策略包括：
（1）要使用的测试技术和工具；
（2）测试完成标准，用于计划和实施测试，及通报测试结果；
（3）影响资源分配的特殊考虑（例如：有些测试必须在周末进行，有些测试必须通过远程环境进行，有些测试需要考虑外部接口或者硬件接口等）。
5、测试用例设计的方法
软件测试用例设计的方法有“白盒”测试 和 “黑盒”测试 ：
（1）“黑盒”测试：（适用于功能测试和验收测试）
①等价类划分；
②因果图法；
③边值分析；
④用户界面测试；
⑤配置测试；
⑥安装选项测试等。
（2）“白盒”测试：
①采用逻辑覆盖的结构测试用例的设计方法（代码的语句覆盖、条件覆盖、分支覆盖）；
②基于程序结构的域测试用例设计方法（域是指程序的输入空间，域测试正是在分析输入空间的基础上，完成域的分类、定义和验证，从而对各种不同的域选择适当的测试点（用例）进行测试）；
③数据流测试用例设计的方法（通过程序的控制流，从建立的数据目标状态的序列中发现异常的结构测试方法）；
④根据对象状态或等待状态变化来设计测试用例；
⑤给予程序错误的变异来设计测试用例；
⑥基于代数运算符号的测试用例设计方法（受分支问题、二义性问题和大程序问题的困扰，使用较少）。
第七章 软件静态测试
十八、软件静态测试的定义、被测对象、原因、目的及内容。
1、静态测试是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。
2、被测对象是各种与软件相关的有必要进行测试的产物（各类文档、源代码等）。
3、原因：
（1）软件内部结构复杂、混乱，代码的编写也没有规范，使得软件内部存在一些不易被察觉的错误，这些错误在特定条件下会造成重大影响；
（2）软件产品升级维护时，由于代码的复杂度、代码编写的杂乱造成软件的维护工作很难进行。
4、静态测试的目的就是对代码标准以及质量进行监控，以此来提高代码的可靠性，使系统的设计符合模块化、结构化、面向对象的要求。
5、静态测试主要包括：各阶段的评审、代码检查、程序分析和软件质量度量等。
十九、评审、同行评审、代码检查及其方法、代码编程规范检查、数据流分析、代码安全性检查
1、评审：
（1）评审是对软件元素或项目状态进行评估的活动，用于确定与预期结果之间的偏差和相应的改进意见，通常由人来执行。
（2）一般评审包括：培训评审、预备评审、同行评审。
2、同行评审：同行评审一般包括：审查、小组评审、走查、桌面评审、临时评审五种类型。
3、代码检查及其方法
（1）代码检查是“白盒”测试的一种静态测试方法，主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性、代码结构的合理性。
（2）代码检查一般采用静态“白盒”测试的方法：代码审查、桌面检查、代码走查和技术评审。
4、代码编程规范检查
编程规范又称代码规则、编码规则，是对程序代码的格式、注释、标识符命名、渔具使用、函数、类、程序组织、公共变量等方面所做的要求。
5、数据流分析：
在数据流最初分析中，可以集中关注定义/引用异常的缺陷（如：变量被定义，但从来没有使用；所使用的变量没有被定义；变量在使用之前被定义了两次）；另外，因为程序内的语句阴变量的定义和使用而彼此相关，所以使用数据流测试方法更能有效的发现软件缺陷；但在度量测试覆盖率和选择测试路径的时候，数据流测试很困难。
6、代码安全性检查
（1）所谓代码安全性，就是你的代码在寻行时，或被别人调用时产生错误的容易程度。
（2）代码安全性检查方法
①对变量类型和单位进行检查；
②对变量引用进行检查；
③对表达式运算进行检查；
④接口分析。
（3）代码安全性关注的错误
①坏的存储分配；
②内存泄露；
③指针引用；
④约束检查；
⑤变量未初始化；
⑥错误逻辑结构；
⑦其他（如缓冲区溢出、非法类型转换、非法算术运算（除零错误、负数开方）、整数和浮点数的上溢出/下溢出、多线程对为保护数据的访问冲突等）。
二十、软件复杂性度量
1、规模度量元Line Count 复杂度：统计程序的源代码行数
2、难度度量元Halstead 复杂度
（1）根据可执行代码行的操作符和操作数的数量来计算：
①操作符：程序调用、数学运算符以及相关的分隔符等；
②操作数：常数和变量。
（2）n1：程序中不同运算符的个数 n2：程序中不同操作数的个数
N1：程序中实际运算符的总数 N2：程序中实际操作数的总数
N：实际的程序长度或简单长度（N=N1+N2） N^：程序的预测长度
①N^ = n1 log2 n1 +n2 log2 n2
②程序容量（程序体积）：V=N log2（n1+n2）
③程序级别：L^=（2/n1)*(n2/N2)
④编程时间（以小时计）：T^=E/（S*f） （S=60*60；f=18）
⑤程序中的错误数目预测值：B=N log2 （n1+n2）/3000 （B为改程序的错误数）
3、结构度量元 McCabe复杂度
（1）McCade圈复杂度：
强连通图指从图中任一个节点出发都能到达所有的其他节点
① V=m-n+p （m为弧数，n为节点数，p通常为1）
② 圈复杂度 = 判定节点的数目 +1
③ 圈复杂度 = 强连通程序图在平面上围成的区域个数
（2）McCade圈复杂度的优点：
①避免软件中的错误倾向；
②指出极复杂模块，这样的模块也许可以进一步细化；
③度量测试计划，确定测试重点；
④在开发过程中通过限制程序逻辑，指导测试过程；
⑤指出将要测试的区域；
⑥帮助测试人员确定测试盒维护对象；
⑦与所用的高级程序设计语言类型无关。
二十一、软件质量模型
1、软件质量定义
（1）国际标准化组织ISO： 反应软件产品满足规定需求和潜在需求能力的特征和特性的综合。
（2）MJ.Fisher ： 所有描述计算机优秀程度的特性的集合。
2、软件质量的特性：
（1）功能性
（2）可靠性
（3）可用性
（4）效率
（5）维护性
（6）可移植性
3、软件质量分层模型
第八章 动态测试
二十二、动态测试的分类
1、从是否关心软件内部结构和具体实现的角度：白盒测试、黑盒测试、灰盒测试
2、从软件开发过程的角度：单元测试、集成测试、系统测试、验收测试
3、从程序执行时是否需要人工干预的角度：人工测试和自动化测试
4、从测试实施组织的角度：开发方测试、用户测试、第三方测试
二十三、白盒测试的定义、目的、特点、内容及方法
1、定义：一种按照程序内部逻辑结构和编码设计结构测试数据并完成测试的测试方法。又称结构测试或逻辑驱动测试。
2、目的：白盒测试的目的是发现问题；而调试的目的是改正缺陷。
3、特点：
（1）可以构成测试数据，使特定程序部分得到测试；
（2）有一定的充分性度量手段；
（3）可获得较多工具支持；
（4）通常只用于单元测试。
4、内容：
（1）对程序模块的所有独立执行路径至少测试一次；
（2）对所有的逻辑判定，取真与取假的两种情况都至少测试一次；
（3）在循环的边界和运行的边界限内执行循环体；
（4）测试内部数据结构的有效性。
5、方法：
（1）逻辑覆盖：以程序内部的逻辑结构为基础的测试方法。
①、语句覆盖：要求设计足够多的测试用例，使得每条语句至少被执行一次：
A.优点：
a、检查所有语句；
b、结构简单的代码的测试效果较好；
c、容易实现自动测试；
d、代码覆盖率高；
e、如果是程序块覆盖，则不必考虑程序块中的源代码。
B.缺点：不能检查出来的错误有：
a、条件语句错误；
b、逻辑运算错误；
c、循环语句错误（循环次数错误、跳出循环条件错误）。
②、判定覆盖（分支覆盖）：要求设计足够多的测试用例，使得程序中的每一个分支至少通过一次，即每一条分支语句的“真”值和“假”值都至少执行一次：
A、优点：
覆盖能力比语句覆盖强
B、缺点：
缺点通语句覆盖
③、条件覆盖：是指选择足够多的测试用例，使得运行这些测试案例后，要使每个判断中每个条件的可能取值至少满足一次，但未必能覆盖全部分支:
A、优点：能够检查所有条件错误；
B、缺点：不能实现对每个分支的检查，用例数增加。
④、判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够执行一次，同时每个判断的所有肯呢搞的判定结果都至少执行一次（即要求各个判定的所有可能的条件取值组合至少执行一次）：
A、优点：既考虑了每一个条件，又考虑了每一个分支，发现错误能力强于分支覆盖和条件覆盖；
B、缺点：并不能全面覆盖所有路径，用例数量增加。
⑤、条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次：
A、优点：条件组合覆盖是前面几种覆盖标准中最强的；
B、缺点：不一定使程序中的每条路径都执行到。
⑥、路径覆盖：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次。
（2）路径测试：根据程序的逻辑控制所产生的路径进行测试用例设计的方法，他是从一个程序的入口开始，执行所经历的各个语句的完成过程
①、DD路径测试（Decision-to-Decision Path）
主要着眼命令式程序语言的测试覆盖率问题
②、基本路径测试：
A、根据过程设计结果画出相应的控制流图；
B、计算控制流图的圈复杂度；
C、确定线性独立路径的基本集合（列出路径）；
D、设计可强制执行基本集合中每条路径的测试用例。
③循环路径覆盖：
A、0次循环：检查跳出循环；
B、1次循环：检查循环初始值；
C、2次循环：检查多次循环；
D、m次循环：检查某次循环；
E、最大次数循环，比最大次数多一次、少一次循环，检查循环次数边界。
（3）数据流测试
（4）信息流测试
（5）覆盖率分析及测试用例准则
①、覆盖率=（至少被执行一次的item数）/ item的总数
Item ：需求、语句、分支、条件、路径。
②、覆盖准则：
A、ESTCA覆盖准则
B、LCSAJ覆盖准则（Liner Sequence and Jump Coverage）：线性代码顺序和调准覆盖
二十四、黑盒测试的定义、要求、方法、缺点及黑盒测试设计测试用例的两个标准
1、定义：黑盒测试是把测试对象当做看不见内部结构的黑盒，在完全不考虑程序内部结构和处理过程的基础上，测试者仅根据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。又称功能测试或数据驱动测试。
2、要求：
（1）要求每个软件特性或功能必须被一个测试用例或一个被认可的一场所覆盖；
（2）要求构造数据类型和数据值的最小集测试；
（3）要求测试不排斥输入的能力；
（4）要求对影响性能的关键模块测试其模块性能。
3、方法：
（1）等价类划分：等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性数据当作测试用例：
等价类的划分有两种不同的情况：
A、有效等价类是指对于程序的规格说明来说是合法的、有意义的输入数据构成的集合；
B、无效等价类是指对于程序的规格说明来说，是不合理的、无意义的输入数据构成的集合。
（2）边界值分析
（3）因果图
（4）随机测试
（5）猜错法
（6）探索性测试
4、缺点：
（1）如果软件外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的；
（2）测试用例数较大；
（3）测试用例可能会产生很多冗余；
（4）功能性测试的覆盖率不可能达到100%；
（5）黑盒测试不能替代白盒测试，而是用来发现白盒测试以外的其他类型的错误。
5、黑盒测试方法设计测试用例要满足的两个标准
(1)所设计出的测试用例能较少为达到合理测试所需要设计的测试用例的总数；
(2)所设计出的测试用例能告诉我们，是否存在某些类型的错误，而不是仅仅指出与特定测试相关的错误是否存在。