软件缺陷即计算机系统或程序中存在的任何一种破坏正常运行能力的问题、错误或者隐藏的功能缺陷、瑕疵。

软件测试的目的包括以下三点：

(1) 测试是程序的执行过程，目的在于发现错误，不能证明程序的正确性，仅限于处理有限种的情况。

(2) 检查系统是否满足需求，这也是测试的期望目标。

(3) 一个好的测试用例在于发现还未曾发现的错误；成功的测试是发现了错误的测试。 软件测试的原则：

1.尽早地和不断地进行软件测试

2.测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

3.程序员应避免检查自己的程序。

4.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

5. 测试中的群集现象。

6. 严格执行测试计划

7. 对每一个测试结果做全面检查。这是一条最明显的原则，但常常被忽视。

8. 保存测试计划，测试用例，出错统计和最终分析报告

软件测试按照是否执行被测软件的角度分为静态测试和动态测试，动态测试又分为黑盒测试和白盒测试

按照软件测试的策略和过程分类，软件测试可分为单元测试，集成测试,确认测试,系统测试和验收测试.

软件测试阶段的输入信息包括两类：

软件配置：指测试对象。通常包括需求说明书、设计说明书和被测试的源程序等；

测试配置：通常包括测试计划、测试步骤、测试用例以及具体实施测试的测试程序、测试工具等。

单元测试是对软件基本组成单元进行的测试。单元测试的对象是模块。

单元测试的主要内容有：模块接口测试；局部数据结构测试；独立路径测试；错误处理测试；

边界条件测试。

辅助模块可分为两种：

(1) 驱动模块（driver）：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

(2) 桩模块（stub）：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

集成测试的定义是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。

集成测试三个层次：模块内集成测试；子系统内集成测试；子系统间集成测试。 确认测试是检验所开发的软件是否能按用户提出的要求运行。（合格性测试）

系统测试是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的流程：制定测试计划、设计测试用例、执行系统测试、缺陷管理与改错

验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，通过了验收测试，产品正式进入发布阶段。

黑盒测试的具体技术方法主要包括边界值分析法、等价类划分法、比较测试法、因果图法、决策表法等。

白盒测试是基于被测程序的源代码设计测试用例的测试方法。常见的白盒测试方法有逻辑覆盖测试和路径分析测试两大类。

在逻辑覆盖测试中，按照覆盖策略由弱到强的严格程度，介绍了语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖和路径覆盖六种覆盖测策略。

? 语句覆盖：每个语句至少执行一次。

? 判定覆盖：在语句覆盖的基础上，每个判定的每个分支至少执行一次。

? 条件覆盖：在语句覆盖的基础上，使每个判定表达式的每个条件都取到各种可能的

结果。

? 判定/条件覆盖：即判定覆盖和条件覆盖的交集。

? 条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。

? 路径覆盖：每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次。 在路径分析测试中，介绍了独立路径测试和Z路径覆盖测试两种常用方法。

? 独立路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行

一次，对程序中所有独立路径进行测试。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证程序的每一个可执行语句至少要执行一次。

? Z路径覆盖测试是指采用简化循环的方法进行路径覆盖测试。被测源程序中的循环

体执行零次或一次。

测试用例（Test Case）是为了高效率地发现软件缺陷而精心设计的少量测试数据。

自动化测试就是希望通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动地测试，目的是减轻手工测试的工作量，从而达到提高软件质量的目的。

CMM（Capability Maturity Model）即软件能力成熟度模型,划分为5个等级:初始级 可重复级 已定义级 已管理级 优化级

 

第二篇：软件测试总结

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

测试的基本原则

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：

1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。 2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。

3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。

4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.

测试的基本原则<二>

1．应当把“尽早和不断的测试”作为开发者的座右铭

2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

什么是测试用例

1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目 的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息， 如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步 骤和期望结果。

2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是 需要完整的考虑应用的整个操作。正因为这样，需要在开发的早期准备测试用例。