软件测试：
软件测试，是一个过程或一系列过程．用来确认计算机代码完成了其应该完成的功能不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。更准确的说，“测试是为发现错误而执行程序的过程”。
软件测试的重要原则：
| 编号 | 原则 |
| 0 | 软件测试是为发现错误而执行程序的过程 |
| 1 |
测试用例中一个必需部分是对预期输出或结果进行定义
|
| 2 |
程序员应避免测试自己编写的程序
|
| 3 |
编写软件的组织不应当测试自已编写的软件
|
| 4 |
应当彻底检查每个测试的执行结果
|
| 5 |
测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效
和未预料到的输入情况
|
| 6 |
检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程是
否“做了其不应该做的”
|
| 7 |
应避免测试用例用后即弃，除非软件本身就是个一次性的软件
|
| 8 |
计划测试工作时不应默许假定不会发现错误
|
| 9 |
程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
|
| 10 |
软件测试是一项极富创造性，极具智力的挑战性的工作
|
| 11 | 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性 |
| 12 | 一个成功的测试用例能够发现某个尚未发现的错误 |
用于代码检查错误列表：
主要有八种：数据引用错误、数据声明错误、数据运算错误、数据比较错误、控制流程错误、接口错误、输入输出错误、其他检查；
|
数据引用错误
|
运算错误 |
|
1.
是否有引用的变量未赋值或未初始化？
|
1.
是否存在非算术变量间的运算？
|
|
2.
下标的值是否在范围之内？
|
2.
是否存在混合摸式的运算？
|
|
3.
是否存在非整数下标？
|
3.
是否存在不同字长变量问的运算？
|
|
4.
是否存在虚调用？
|
4.
目标变量的大小是否小于赋值大小？
|
|
5.
当使用别名时属性是否正确？
|
5.
中间结果是否上溢或下溢？
|
|
6.
记录和结构的属性是否匹配？
|
6.
是否存住被
0
除？
|
|
7.是否计算位串的地址？是否传递位串参数？
|
7.
是否存在二进制的不精确度？
|
|
8.
基础的存储属性是否正确？
|
8.
变量的值是否超过了有意义的范围？
|
|
9.
跨过程的结构定义是否匹配？
|
9.
操作符的优先顺序是否被正确理解？
|
|
10.索引或下标操作是否有“仅差一个”的错误？
|
10.
整数除法是否正确？
|
|
11.
继承需求是否得到满足？
|
| 数据声明错误 | 比较错误 |
|
1.
是否所有的变量都已声明？
|
1.
是否存在不同类型变量间的比较？
|
|
2.
默认的属性是否被正确理解？
|
2.
是否存在混合模式的比较运算？
|
|
3.数组和字符串的初始化是否正确？
|
3.比较运算符是否正确？ |
|
4.变量是否赋予了正确的长度，类型和存储类？
|
4.布尔表达式是否正确？ |
|
5.
初始化是否与存储类相一致？
|
5.比较运算是是否与布尔表达式相混合？ |
|
6.
是否有相似的变量名？
|
6.是否存在二进制小数的比较？ |
|
7.
操作符的优先顺序是否被正确理解？
|
|
|
8.编译器对布尔表达武的计算方式是否被正确理解？
|
|
控制流程错误
|
输入/输出错误 |
| 1.是否超出了多条分支路径？ | 1.文件的属性是否正确？ |
|
2.
是否每个循环都终止了？
|
2.0PEN 语句是否正确？ |
|
3.是否每个程序都终止了？
|
3.I/O 语句是否符合格式规范？ |
|
4.是否存在由于入口条件不满足而跳过循环 体？
|
4.缓冲大小与记录大小是否匹配？ |
|
5.可能的循环越界是否正确？
|
5.文件在使用前是否打开？ |
|
6.是否存在“仅差一个”的迭代错误？
|
6.文件在使用后是否关闭？ |
|
7.DO/END 语句是否匹配？
|
7.文件结束条件是否被正确处理？ |
|
8.是否存在不能穷尽的判断？
|
8.是否处理了 I/O 错误？ |
| 9.输出信息中是否有文字或语法错误？ |
| 接口错误 | 其他检查 |
|
1.形参的数量是否等于实参的数量？
|
1.在交叉引用列表中是否存在未引用过的变量？
|
|
2.形参的量纲是否与实参的量纲相匹配？
|
2.属性列表是否与预期的相一致？ |
|
3.形参的量纲是否与实参的量纲相匹配？
|
3.是否存在“警告”或“提示”信息？ |
|
4.传递给被调用模块的实参个数是否等于其形参个数？
|
4.是否对输入的合法性进行了检查？ |
|
5.传递给被调用模块的实参属性是否与其形参属性匹配？
|
5.是否遗漏了某个功能？ |
|
6.传递给被调用模块的实参量纲是否与其形参量纲匹配？
|
|
|
7.调用内部函数的实参的数量、属性，顺序是否正确？
|
|
|
8.
是否引用了与当前入口点无关的形参？
|
|
|
9.
是否改变了某个原本仅为输入值的形参？
|
|
|
10.
全局变量的定义在模块间是否一致？
|
|
| 11.常数是否以实参形式传递过？ |
测试方法：
|
黑盒测试
|
白盒测试 |
|
等价类划分
|
语句覆盖 |
|
边界值分析
|
判定覆盖 |
|
因果图分析
|
条件覆盖 |
| 错误测试 | 判定/条件覆盖 |
| 多重条件覆盖 |
因果图分析：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表，从而设计相应的测试用例。
错误测试：指接到具体的程序之后，他们利用直觉和经验猜测出错的可能类型， 然后编写测试用例来暴露这些错误。
合理的测试策略：
1. 如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。
2. 在任何情况下都应使用边界值分析方法，边界值分析可以产生一系列补充的测试条件，但是，也正如“因果图分析”一节所述，多数甚至全部条件都可以被整合到因果图分析中。
3. 应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
4. 使用错误猜测技术增加更多的测试用例。
5. 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。
上述策略并不能保证可以发现所有的错误，但实践证明这是一个合理的折中方案。
好的测试计划应包括：
1. 目标。必须定义每个测试阶段的目标。
2. 结束准则。必须制定准则以规定每个测试阶段何时可以结束。一般两条准则：1. 用完了安排的测试时间后，测试使结束。 2. 当执行完所有测试用例都未发现错误，测试便结束。也就是说，当所有的测试用例不成功时便结束。
3. 进度。每个阶段都须有时间表。应指出何时设计、编写和执行测试用例，某些软件技术，如极限编程，要求在程序编码开始之前就设计测试用例和单元测试。
4. 责任。对于每一个阶段，应当确定谁来设计、编写和验证测试用例，谁来修改发现的软件错误。由于在大型项目中讨论特定的测试结果是否代表错误时，有可能出现争端，因此还需要确定一名仲裁者。
5. 测试用例库及标准。在大型项目中，用于确定、编写以及存储测试用例的系统方法是必须的。
6. 工具。必须确定需要使用的测试工具，包括计划由谁来开发或采购、如何使用工具以及何时需要使用工具。
7. 计算机时间。计划每个测试阶段所需的计算机时间，包括用来编译应用程序的服务器（如果需要的话）、用来进行安装测试所需的桌面计算机、用来运行基于 web 应用程序的 web 服务器、联网的设备（如果需要的话）等等。
8. 硬件配置。如果需要特别的硬件配置或设备，则需要一份计划来描述该需求，该如何满足需求以及何时需要满足。
9. 集成。测试计划的一部分是定义程序如何组装在一起的方法（例如自顶向下的增量测试）。一个系统如果包含大的子系统或程序，可按增量的方式组装在一起，例如可以使用自顶向下或自底向上的方法，但是这些构造块是程序或子系统，而不是模块。如果是这种情况，就需要一个系统集成计划。系统集成计划规定了系统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部件的职责分工。
10. 跟踪步骤。必须跟踪测试进行中的方方面面，包括对错误易发模块的定位，以及有关进度、资源和结束准则的进展估计。
11. 调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。调试计划中还应包括进度、责任分工、工具以及计算机时间/资源等。
12. 回归测试。回归测试在对程序作了功能改进或进行了修改之后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。回归测试通常重新执行测试用例中的某个子集。回归测试很重要，因为对程序的改动和对错误的纠正要比原来的程序代码更容易出错（与报纸排版错误很相似，这些错误通常由于最后所做的编辑改动而引起的，而不是修改先前版本而引起的）。回归测试计划规定了测试人员、测试方法和测试时间，它也是必须的。
测试相关名词：
security testing（安全性测试）系统测试的一种形式，用以考验程序或系统的安全保密机制。