[[TOC]] 软件测试基础理论
软件测试？
软件测试: 一个或一系列过程。用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。
测试：测试是为发现错误而执行程序的过程。
测试原则？
1.测试用例中一个必须部分是对预期输出或结果进行定义
2.程序员应避免测试自己编写的程序
3.编写软件的组织不应当测试自己编写的软件
4.应当彻底检查每个测试的执行结果
5.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
6.检查程序是否"未做其应该做的"仅是测试的一半，测试的另一半是检查程序是否"做了其不应该做的"
7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
8.计划测试工作时不应默许假定不会发现错误
9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
10.软件测试是一项极富创造性，极具智力挑战性的工作
人工测试方法？
利用错误列表进行代码检查
小组代码走查
桌面检查
同行评审
代码检查错误列表总结：
数据引用错误:
1.是否有引用的变量未赋值或未初始化?
2.下标的值是否在范围之内?
3.是否存在非整数下标?
4.是否存在虚调用?
5.当使用别名时属性是否正确?
6.记录和结构的属性是否匹配?
7.是否计算位串的地址，是否传递位串参数?
8.基础的存储属性是否正确?
9.跨过程的结构定义是否匹配?
10.索引或下标操作是否"仅差一个"的错误?
11.继承需求是否得到满足?
运算错误：
1.是否存在非算术变量之间的运算?
2.是否存在混合模式的运算?
3.是否存在不同字长变量间的运算?
4.目标变量的大小是否小于赋值大小?
5.中间结果是否上溢或下溢?
6.是否存在被0除?
7.是否存在二进制的不精确度?
8.变量的值是否超过了有意义的范围?
9.操作符的优先顺序是否被正确理解?
10.整数除法是否正确?
数据声明错误：
1.是否所有的变量都已声明?
2.默认的属性是否被正确理解?
3.数组和字符串的初始化是否正确?
4.变量是否赋予了正确的长度、类型和存储类?
5.初始化是否与存储类相一致?
6.是否有相似的变量名?
比较错误：
1.是否存在不同类型变量间的比较?
2.是否存在混合模式的比较运算?
3.比较运算符是否正确?
4.布尔表达式是否正确?
5.比较运算是否与布尔表达式相混合?
6.是否存在二进制小数的比较?
7.操作符的优先顺序是否被真确理解?
8.编译器对布尔表达式的计算方式是否被正确理解?
控制流程错误：
1.是否超出了多条分支路径?
2.是否每个循环都终止了?
3.是否每个程序都终止了?
4.是否存在由于入口条件不满足而跳过循环体?
5.可能的循环越界是否正确?
6.是否存在"仅差一个"的迭代错误?
7.DO/END语句是否匹配?
8.是否存在不能穷尽的判断?
9.输出信息中是否有文字或语法错误?
输入/输出错误：
1.文件属性是否正确?
2.OPEN语句是否正确?
3.I/O语句是否符合格式规范?
4.缓冲大小与记录大小是否匹配?
5.文件在使用前是否打开?
6.文件在使用后是否关闭?
7.文件结束条件是否被正确处理?
8.是否处理了I/O错误?
接口错误：
1.形参的数量是否等于实参的数量?
2.形参的属性是否与实参的属性相匹配?
3.形参的量纲是否与实参的量纲相匹配?
4.传递给被调用模块的实参个数是否等于其形参个数?
5.传递给被调用模块的实参属性是否与其形参属性匹配?
6.传递给被调用模块的实参量纲是否与其形参量纲相匹配?
7.调用内部函数的实参的数量、属性、顺序是否正确?
8.是否引用了与当前入口点无关的形参?
9.是否改变了某个原本仅为输入值的形参?
10.全局变量的定义在模块间是否一致?
11.常数是否以实参形式传递过?
其他检查：
1.在交叉引用列表中是否存在未引用过的变量?
2.属性列表是否与预期的相一致?
3.是否存在"警告"或"提示"信息?
4.是否对输入的合法性进行了检查?
5.是否遗漏了某个功能?
测试策略及方法：
黑盒测试：又称为数据驱动的测试或输入/输出驱动的测试，测试过程不需要去了解程序内部的结构。
黑盒测试方法:
等价类划分 -> 通过定义条件和错误类来帮助减少测试的工作量。这总划分假设谋分类的一个代表值能够等价于属于该分类的所有值或者条件
边界值分析 -> 测试等价类中每一个分类取边界值时的请情况，既要考虑输入等价类，也要考虑输出等价类。
因果图分析 -> 通过生成布尔图来诠释测试用例的可能结果，使用该法旨在帮助选择那些有效地测试用例达到比较完整地测试用例设计效果。
错误猜测 -> 依靠直觉和测试专家经验来定位程序可能出错的地方，并由此设计出更高效的测试用例。
白盒测试：又称为逻辑驱动的测试，允许检查程序的内部结构。
白盒测试方法:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖
逻辑覆盖测试：该测试要求程序中的所有判断都应至少覆盖一次，同时每一条语句或者入口点都执行一次。
一组合理的策略如下：
1.如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法
2.在任何情况下都应使用边界值分析方法。应记住，这是对输入和输出边界进行的分析。边界值分析可以产生一系列补充的测试条件，但是，也正如"因果图分析"一节所述，多数甚至全部条件都可以被整合到因果图分析中。
3.应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
4.使用错误猜测技术增加更多的测试用例
5.针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后一个最为完整）。
模块（单元）测试：
模块测试是对程序中的单个子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是先将注意力集中在对构成程序的较小模块的测试上面。
1.测试用例的设计方式：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
2.模块测试及集成的顺序：增量测试优于非增量测试，"自顶向下的测试"和"自底向上"两种增量测试策略。
3.对执行模块测试的建议：使用自动化测试工具对测试用例进行测试，避免随意丢弃测试用例。
增量测试：
自顶向下测试：
优点：
1.如果主要的缺陷发生在程序的顶层将非常有利
2.一旦引入I/O功能，提交测试用例会更容易
3.早期的程序框架可以进行演示，并可激发积极性
缺点：
1.必须开发桩模块
2.桩模块要比最初表现的更复杂
3.在引入I/O功能之前，向桩模块引入测试用例比较困难
4.创建测试环境可能很难，甚至无法实现
5.观察测试输出很困难
6.使人误解设计和测试可以交迭进行
7.会导致特定模块测试的完成延后
自底向上测试：
优点：
1.如果主要的缺陷发生在程序的底层将非常有利
2.测试环境比较容易建立
3.观察测试输出比较容易
缺点：
1.必须开发驱动模块
2.直到最后一个模块添加进去，程序才形成一个整体
一个软件产品开发周期的模型-归结为7个步骤：
1.将软件最终用户的要求转换位一系列书面的需求。这些需求就是该软件产品要实现的目标
2.通过评估可行性与成本、消除相抵触的用户需求、简历优先级和平衡关系，将用户需求转换位具体的目标
3.将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。该规格说明被称为"外部规格说明"
4.如果该产品是一个系统，如操作系统，数据库管理系统，而不仅是一个程序，那么下一步骤就是系统设计。该步骤将系统分割为单独的程序、部件或子系统、并定义它们的接口。
5.通过定义每个模块的功能，模块的层次结构以及模块之间的接口，来设计程序或程序集合的结构。
6.设计一份准确的规格说明，定义每个模块的接口与功能。
7.经过一个或更多的子步骤，将模块接口规格说明转换位每个模块的源代码算法。
需求文档：
1.需求规格说明定义了为什么要开发程序
2.目标定义了程序要做什么，以及应达到什么效果
3.外部规格说明定义了程序对用户的准确表现
4.与后续阶段相关的文档将越来越详细地规定程序是如何建立起来
测试用例的15个分类：
1.能力测试：确保程序的目标功能实现
2.容量测试：发现处理大容量数据时的程序异常
3.强度测试：发现在大规模负载、高强度不间断持续的数据处理中的异常
4.可用性测试：评估最终用户在使用软件并于软件交互时的可用性问题
5.安全性测试：试图攻破程序的安全防线
6.性能测试：评估程序的响应时间以及吞吐量瓶颈
7.存储测试：确保程序可以正确处理其对存储的需求，包括系统的存储和物理上的存储
8.配置测试：检查程序是否能在推荐配置上流畅运行
9.兼容性/转换测试：评估新版本能否兼容老的版本
10.安装测试：确保能够在所有支持的平台上安装软件
11.可靠性测试：评估程序是否能达到规格说明中的运行时长和MTBF（平均故障间隔时间）要求
12.可恢复性测试：测试系统恢复相关的功能是否按设计要求实现
13.服务/可维护性测试：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需
14.文档测试：校验所有的用户文档是否准确
15.过程测试：对软件操作系统或维护所需涉及的流程进行评估和确定
一个良好的测试计划应该 包括：
1.目标：必须定义每个测试阶段的目标
2.结束准则：必须指定准则以规定每个测试阶段何时可以结束
3.进度：每个阶段都须有时间表
4.责任：每个阶段应当确定谁来设计、编写和验证测试用例，谁来修改发现的软件错误。
5.测试用例库及标准：用于确定、编写以及存储测试用例的系统方法是必须的
6.工具：必须确定需要使用的测试工具
7.计算机额实践：计划每个测试阶段所需的计算机时间
8.硬件配置
9.集成：测试计划的一部分是定义程序如何组装在一起的方法
10.跟踪步骤：必须跟踪测试进行中的方方面面
11.调试步骤：制定上报已发现错误机制，跟踪错误修改进程
12.回归测试：对程序功能进行修改或改进后进行回归测试，防止修改引起新的错误。
调试方法：
1.暴力法调试
2.归纳法调试
3.演绎法调试
4.回溯法调试
5.测试法调试
定位错误：
1.动脑筋
2.如果遇到了僵局，就留到稍后解决
3.如果遇到了困境，就把问题描述给其他人听
4.仅将调试工具作为第二种手段
5.避免使用试验法->仅作为最后的手段
修改错误：
1.存在一个缺陷的地方，很有可能还存在其他缺陷
2.应纠正错误本身，而不仅是症状
3.正确纠正错误的可能性并非100%
4.随着程序规模的增加，正确修改错误的可能性反而降低
5.应意识改正错误会引入新错误的可能性
6.修改错误的过程也是临时回到设计阶段的过程
7.应修改源码，而不是目标代码
错误分析：
1.错误出现在什么地方？
2.谁制造了这个错误？
3.哪些做得不正确？
4.如何避免该错误的出现？
5.该如何更早地发现错误？
互联网应用测试：
三层C/S结构：
表示层：第一层，Web服务器运行Web网站
业务层：第二层，运行应用服务器，模拟业务流程
数据层：第三层，从一个关系数据库管理系统中存储和获取数据
表示层测试用例：
1.确保字体在不同浏览器中都相同
2.检查以确保每一个链接都指向正确的文件或站点
3.检查图形以确保其分辨率和大小正确
4.对每一页进行拼写检查
5.让文字变价检查语法和风格
6.在页面载入时检查光标位置，以确保其在正确的文本框中
7.检查以确保在页面载入时选中了默认的按钮
8.检查交互性操作的用户友好度反馈以及体验一致性
9.检查商业或行业的特定术语与风格的使用。
业务层测试用例：
1.检查消费税和送货费计算是否正确。
2.确保提出的响应时间、吞吐率等性能指标得到了满足。
3.验证事务正确完成。
4.确保失败的事务回滚正确。
5.确保正确采集数据。
数据层测试用例：
1.确保数据库操作满足性能要求
2.验证数据存储适当且正确
3.验证可使用当前备份来恢复
4.测试故障处理和冗余功能
5.测试数据加密和安全性
6.测试后端数据输入与管理功能的可用性以及准确性
移动应用测试面临的挑战：
1.设备多样性
2.运营商网络基础设施
3.自动化脚本编程与开发
4.可用性测试
