什么是软件测试

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试的目的

Grenford J.Myers提出的观点

（1）软件测试是为了发现错误而执行程序的过程。

（2）测试是为了证明程序有错，而不是证明程序无错。

（3）一个好的测试用例在于它能发现至今未发现的错误。

（4）一个成功的测试在于它发现了至今未发现的错误。

测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正这种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和商业风险。当然测试是不可能找出全部的错误的。

软件开发与软件测试的关系

软件开发经过制定计划、需求分析、设计阶段后，才能进入编码阶段。软件故障可能出现在软件开发的各个阶段。因此，软件测试应贯穿于软件定义与开发的整个期间。

测试在开发的各个阶段如下：

（1）项目规划阶段：负责整个测试阶段的监控。

（2）需求分析阶段：确定测试需求分析、制定系统测试计划。测试需求分析是指分析产品生存周期中测试所需的资源、配置、各阶段评审通过的标准等。

（3）概要设计和详细设计阶段：制定集成测试计划和单元测试计划。

（4）程序编写阶段：开发相应的测试代码或测试脚本。

（5）测试阶段：实施测试，并提交相应的测试报告。

软件测试的原则

（1）测试应基于用户需求

（2）做好软件测试计划是做好软件测试工作的关键

（3）应尽早的开始软件测试并不断的进行软件测试测试尽早介入

（4）测试前必须明确定义好产品的质量标准

（5）避免测试自己的软件

（6）应充分注意测试中的集群现象

（7）必须检查每个实际输出结果

（8）穷举测试是不可能的

（9）测试设计决定了测试的有效性和效率

（10）注意保留测试设计和说明文档，并注意测试设计的可重用性

软件测试需要考虑的测试方面

功能测试（满足需求）

安装/卸载/升级

异常处理（接听电话、短信、断电、切换网络、前后台切换等操作）

兼容性测试（不同机型、不同版本、不同尺寸、不同分辨率）

性能测试（安装卸载响应时间、打开app速度、各类功能性操作响应时间、反复长时操作）

安全测试（权限测试、安装卸载安全性、数据安全性-密码不会被存储到设备中）

用户体验测试

UI界面测试

典型的软件开发模型

（1）边做边改模型（build-and-fix model）

（2）瀑布模型（waterfall model）

（3）快速原型模型（rapid prototype model）

（4）增量模型（incremental model）

（5）螺旋模型（spiral model）

（6）演化模型（evolutionary model）

（7）喷泉模型（fountain model）

（8）智能模型（Intelligent model）

（9）混合模型（hybrid model）

软件测试模型

V模型：强调了整个软件项目开发中需要经历的若干个测试级别，每个级别都与一个开发阶段相对应，但它没有明确指出应该对需求、设计进行测试。

W模型：对V模型进行了补充。强调了测试计划等工作的先行和对系统需求和系统设计的测试，但和V模型一样，没有专门针对软件测试的流程予以说明。

H模型：表现了测试是独立的。就每一个软件的的测试细节来说，都有一个独立的操作流程，只要测试前提具备了，就可以开始进行测试。

软件测试的分类

（1）按测试阶段划分：单元测试、集成测试、确认测试、系统测试、验收测试，在测试中如果有需要还会进行回归测试。

（2）按执行主体划分：Alpha测试（验收测试或开发方测试）、Beta测试（用户测试）、第三方测试

（3）按执行状态划分：静态测试、动态测试

（4）按测试技术划分：黑盒测试、白盒测试、灰盒测试

（5）其他测试：回归测试、随机测试

单元测试的测试对象、测试目的、测试依据、测试方法

单元测试的测试对象是模块内部的程序错误；测试目的是消除局部模块逻辑和功能上的错误和缺陷；测试依据是模块的详细设计；测试方法采用白盒测试。

集成测试的测试对象、测试目的、测试依据、测试方法

集成测试的测试对象是模块间的组装和调用关系；测试目的是找出与软件设计相关的程序结构模块调用关系，模块间接口方面的问题；测试依据是概要设计；测试方法采用灰盒测试。

系统测试的测试对象、测试目的、测试依据、测试方法

系统测试的测试对象是整个系统；测试目的是对整个系统进行测试；测试依据是需求规格说明书；测试方法采用的是黑盒测试。

单元测试----白盒测试、自动化测试、静态测试

1、单元测试概念？

单元测试是完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

2、单元测试的内容？

接口测试：保证进出单元模块的数据流是正确的

内部数据结构：保证临时存储的数据在算法执行过程中的完整性

全局数据结构：全局数据结构对单元模块的影响应当审查

边界：才用边界值分析技术，保证模块在边界条件和极限情况下正常执行

语句覆盖：保证每个语句执行一次

错误路径：对所有处理错误的路径进行测试

集成测试----白盒测试、黑盒测试、自动化测试、静态测试

1、集成测试概念？

通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。

自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

2、集成测试的过程？

a.明确测试的目标和完成准则，并确定关键部分

b.确定阶段和进度安排

c.测试和修正协调的计划

d.清理系统结构

e.确定集成测试方法的组合策略

f.描述集成顺序

g.针对每次集成编制测试用例，从而形成测试方案

h.进行附加软件（测试桩）的开发

i.测试软件和测试准备准备

j.依据测试方案进行测试

k.根据测试结果提交测试报告

l.测试报告的分析

m.缺陷的管理

n.修正和测试工作

o.完成测试软件提交

系统测试----黑盒测试、自动化测试、手工测试

1、系统测试概念？

根据软件需求规范的要求进行系统测试，确认系统满足需求的要求，系统测试人员相当于用户代言人，在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作

2、系统测试主要内容？

a.所有功能需求得到满足

b.所有性能需求得到满足

c.其他需求（如安全性、容错性、兼容性等）得到满足

回归测试----黑盒测试、自动化测试、手工测试

1、回归测试概念？

当发现并修改缺陷后，或在软件中添加新的功能后，重新测试。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。回归测试可以通过人工重新执行测试用例，也可以使用自动化的工具来进行。

2、回归测试方式？

a.覆盖全部测试用例。选择基线测试用例库中的全部测试用例组成回归测试包，测试成本最高

b.基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包，首先运行最重要的、最关键的和最可疑的测试用例，测试从主要特征到次要特征

c.基于操作剖面选择测试。测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些最重要或最频繁使用的功能的测试用例

d.重新测试修改的部分。当测试者对修改的局部化有足够信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和他的接口上

用户验收测试----黑盒测试、自动化测试、手工测试

1、用户验收测试内容？

a.配置审查。确保已开发软件的所有文件资料均已编写齐全，并分类编目

b.Alpha测试。是由用户在开发者的场所来进行的，在一个受控的环境中进行。

c.Beta测试。由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件

白盒测试常用的技术

（1）逻辑覆盖法：语句覆盖、判定覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖、路径覆盖

（2）程序插装技术

（3）基本路径法

（4）符号测试

黑盒测试的方法

（1）等价类划分法

（2）边界值分析法

（3）因果图法

（4）决策表法

（5）错误推测法

（6）场景法

非功能测试的测试方法：

（1）性能测试

（2）压力测试

（3）容量测试

（4）健壮性测试

（5）安全性测试

（6）可靠性测试

（7）恢复性测试与备份测试

（8）协议一致性测试

（9）兼容性测试

（10）安装测试

（11）可用性测试

（12）配置测试

（13）文档测试

（14）GUI测试

性能测试分类：

1.负载测试

2.压力测试

3.可靠性测试

4.数据库测试

5.安全性测试

6.文档测试

负载测试可以和压力测试结合进行

请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。

单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。

集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。

系统测试：在所有都考虑的情况下，对系统进行测试。

验收测试：第三方进行的确认软件满足需求的测试。

软件测试与软件质量的区别？

质量保证（QA）：主要工作是通过预防，检查与改进来保证软件质量。它所关心的是软件质量的检查与测量。着眼软件开发活动中的过程、步骤及产物，而不是对软件进行剖析进而找出问题。

软件测试：测试关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物—开发文档和源代码进行走查、运行，以找出问题，报告质量。测试人员也必须假设软件存在问题，所以所做的操作都是为了找出更多的问题，而不是仅仅验证每一件事儿是正确的。

软件缺陷概述：

软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。

从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。

从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。

确定缺陷的几个标准（P5）

（1）软件未达到产品说明书中已经标明的功能，即没有完全实现功能。

（2）软件未达到产品说明书中虽未明显指出但应达到的目标。

（3）软件出现了产品说明书中指明不会出现的错误，即基本实现用户需求，但运行时会出现一些功能和性能上的问题。

（4）软件功能超出了软件产品说明书中指明的范围，即实现了多余的功能。

（5）软件难以理解，不易使用，运行缓慢或最后用户会认为不好。

缺陷的特点

（1）雪崩效应

缺陷的雪崩效应是指缺陷数目会随着软件开发过程的深入而不断地增加，类似于滚雪球的效应。

产生的原因：

a.开发过程中前一阶段出现缺陷的地方，在后一阶段同样会出现，并且通常来说前一阶段的缺陷数目比前一阶段更多

b.即使前一阶段是正确的软件工作产品，由于人容易犯错误，在后继的阶段也可能引入新的缺陷，从而导致缺陷数目的增加

（2）成本放大效应

不同阶段发现和修复缺陷的成本是不一样的；到软件开发生命周期的后期发现缺陷，其修复成本是急剧增加的，而不是线性增加。

测试人员应尽早参与静态测试，例如：尽早参与软件文档的评审，可以有效地发现其中的缺陷并尽早修复，因此可以有效地减缓缺陷的雪崩效应，并降低修复缺陷的成本。

（3）集群效应

测试过程中发现的缺陷分布在测试对象的不同功能模块，同样也满足20/80原则：测试对象20%模块中可以发现80%的缺陷，即缺陷的集群效应。

测试人员根据该原则，可以在后继的测试中重点关注该20%模块。同时分析在该20%模块中集中引入缺陷的原因，以发现开发和测试过程中存在的问题，从而帮助后续项目的过程改进。

缺陷的状态一般有如下几种

（1）新建（打开）：当QA人员汇报新的缺陷时。

（2）延后处理：如果这个缺陷和当前发布的这个版本没有直接关系，或当前版本无法修复，或这个缺陷不是很严重，不需要立即修复，那么项目经理可以把状态设为“延后处理”。

（3）已指派：“指派给”这个值是由项目组长或项目经理来填，指定给具体的某个开发人员。

（4）已解决/已修复：当开发人员做了某些必要的代码改动，并确认修改后，他就可以把状态改为“已修复”，然后交给测试组进行回归测试。

（5）无法重现：如果开发人员根据QA人员在缺陷报告里描述的步骤，都无法重现这个缺陷的时候，那么开发人员可以把这个缺陷标为“无法重现”，QA人员需要检查这个缺陷是否可以重现，并把更为详细的重现步骤提供给开发人员。

（6）需要更多信息：如果开发人员认为QA人员提供的缺陷重现步骤不够清晰，因而无法重现缺陷的时候，那么他可以把这个状态改为“需要更多信息”，在这种情况下，QA人员需要提供更为详细的重现步骤，并把缺陷返回给开发小组。

（7）重新打开：如果QA人员不满意这个修复结果，或者说即使在修复之后，依然出现同样的问题，那么QA人员可以把这个状态标记为“重新打开”，这样的话，开发人员就可以采取相应的行动了。

（8）关闭：如果QA小组已经验证过这个缺陷的修复结果，并且这个问题已经得到了解决，那么QA人员就可以把状态改为“关闭”。

（9）驳回/无效：如果这个系统的确是按照规格说明运行的，而缺陷的产生只是由误解引起的，那么开发人员或者小组长可以把这些缺陷标记为“驳回”或者“无效”。

缺陷的严重程度

A类-严重错误

1.由于程序引起的死机，非法退出。

2.死循环。

3.数据库发生死锁。

4.数据通信错误。

5.严重的数值计算错误。

6.与数据库连接错误。

7.因错误操作导致的程序中断。

B类-较严重错误

1.功能不符。

2.数据流错误。

3.程序接口错误。

4.轻微数值计算错误。

C类-一般性错误

1.界面错误（详细文档）。

2.打印内容，格式错误。

3.简单的输入限制未放到前台进行控制。

4.删除操作未给出提示。

D类-较小错误

1.辅助说明描述不清楚。

2.显示格式不规范。

3.长时间操作未给用户进度提示。

4.提示窗口文字未使用行业术语。

5.可输入区域和只读区域没有明显的区分标志。

6.系统处理未优化。

E类-其他错误

1.光标跳转设置不好，鼠标（光标）定位错误。

2.一些建议性问题。

缺陷的优先级

立即解决P1—缺陷导致系统几乎不能使用或测试不能继续，需要立即修复。

高优先级P2—缺陷严重影响测试，需要优先考虑。

正常排队P3—缺陷需要正常排队等待修复。

低优先级P4—缺陷可以在开发人员有时间的时候再被纠正。

缺陷的类型

（1）功能：影响了各种系统功能、逻辑的缺陷。

（2）用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷。

（3）文档：影响发布和维护，包括注释、用户手册、设计文档。

（4）软件包：由于软件配置库、变更管理或版本控制引起的错误。

（5）性能：不满足系统可测量的属性值，如执行时间、事务处理速率等。

（6）系统/模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突

缺陷来源

（1）需求说明书：需求说明书错误或不清楚引起的问题。

（2）设计文档：设计文档描述不准确和需求说明书不一致的问题。

（3）系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷。

（4）数据流（库）：由于数据字典、数据库中的错误引起的缺陷。

（5）程序代码：纯粹在编码中的问题所引起缺陷。

缺陷的根源

a)测试策略：错误的测试范围，误解测试目标，超越测试能力等；

b)过程、工具和方法：无效的需求收集过程，过失的风险管理过程，不适用的项目管理方法，无效的变更控制过程等；

c)团队/人：项目团队职责较差，缺乏培训，没有经验的项目团队，缺乏士气等；

d)缺乏组织和沟通：缺乏用户参与，职责不明确、管理失败等；

e)硬件：硬件配置不对、缺乏等；

f)软件：软件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件错误，编译器错误等；

g)工作环境：组织机构调整，预算改变，工作环境恶劣等。

Bug报告包括哪些内容？

Bug出现的位置、可重现的步骤、所使用的数据、bug的截图、发现人以及日期

如果一个bug只出现一次，该怎么处理？

1.bug出现的同时立即截图留下异常的画面；

2.使用相同的环境、设备、测试步骤、方法，使用相同的输入数据看能否重现；

3.不能重现，则告诉项目经理发现的过程，分析优先级，讨论解决方案。

缺陷的生命周期

缺陷的生命周期就是从缺陷开始（即被发现）到结束（即该缺陷被确保不会再出现）的周期。

一个缺陷的生命周期通常有以下几个阶段（各个公司通常都会有自己对缺陷阶段的定义，下面只是一个范例）

1.New :缺陷被测试人员发现，但是没有提交给任何开发。

2.Open:缺陷被测试人员提交给开发，由测试人员更改为Open。之后开发可能会Rejected(拒绝修复)，或者改为duplicate（该bug被重复提交，也或者是改为deferred（延期解决）

3.Update：开发修复了但是还没有提交给测试人员，由开发将状态更改为Update。

4.Fix :开发修复之后并自测通过并提交给测试人员，由开发将状态更改为fixed.

5.Close :由测试验证确实修改正确后，将状态改为Close.

6.Reopen：由测试验证仍然没有修复，则将状态更改为Reopen，再次提交给开发，让其修复。

缺陷周期一般分为3段和1个特殊阶段

1、发现缺陷：测试执行过程中，发现bug，并记录相关bug情况

2、跟踪修复缺陷：测试人员追踪bug修复情况，开发人员及时获得bug情况进行修复。

3、修复确认缺陷：验证bug，确认bug已经被修复（当第三步失败的话，将重新回归至第2步）

4、挂起阶段：当bug所需要修复的成本过于庞大或特殊原因，造成bug无法修复的话，会进入bug的挂起阶段

软件的生命周期

软件的生命周期，亦称软件的生存周期。它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段，每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件。

1、问题的定义及规划

此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析

在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

3、软件设计

此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试

在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

软件测试的流程

1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team

2.测试计划:根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager

3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester

4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)

5.执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)

6.defect tracking：追踪leader分配给你追踪的bug.直到bug fixed。--everytester

7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.

8.编写安装文档或者使用手册

9.结束

软件测试结束的标准

1．模块测试用例执行完毕，覆盖了全部软件需求；

2．缺陷收敛趋势符合质量要求；

3．缺陷修复率达到产品设计人员的需求；

4．达到预先的缺陷度量原则（缺陷密度值达到客户的需求）。

对C/S和B/S结构的软件进行测试时有何不同？

C/S又称Client/Server或客户/服务器模式。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库。客户端需要安装专用的客户端软件。

B/S又称Brower/Server，客户机上只需要安装一个浏览器。浏览器通过web server同数据库数据进行交互。