软件测试的实质
- 不需要修复软件缺陷的原因有几个：
- 没有足够的时间
- 不算真正的软件缺陷
- 修复的风险太大
- 不值得修复
- 软件缺陷的定义
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的错误
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解、不易使用、运行速度慢或者软件测试员认为最终用户会认为不好
检查产品说明书
- 测试在大分类上可以分为黑盒测试和白盒测试，也可以分为静态测试和动态测试。
- 测试产品说明书属于静态黑盒测试
- 对产品说明书进行高级审查
- 假设自己是客户。了解并测试软件是否符合客户的要求。
- 研究现有的规范和标准。举例：公司惯用语和规定，行业要求，政府标准，图形用户界面，安全标准。
- 审查和测试类似的软件。审查竞争产品时需要注意规模，复杂性，测试性，质量和可靠性，安全性。
- 产品说明书低层次测试技术
- 检查产品说明书属性：完整，准确，精确，一致，贴切，合理，代码无关，可测试性。
- 产品说明书术语检查清单
- 总是、每一种、没有、所有、从不：看到这些术语，需要考虑违反这些情况的用例。
- 当然、因此、明显、显然、必然：这些术语在说服你接受某种假定情况，测试用例需要考虑是否会出现这种假定情况。
- 某些、有时、常常、通常、惯常、经常、大多、几乎：这些词太过模糊，有时发生的功能无法进行测试。
- 等等、诸如此类、以此类推、例如：用这种词语结束的功能清单无法进行测试。功能清单要绝对或者就解释明确。
- 良好、迅速、廉价、高效、小、稳定：这些是无法量化的术语，无法进行测试。如果说明书中出现这些术语，必须进一步准确定义含义。
- 处理、进行、拒绝、跳过、排除：这些词语隐藏了大量需要说明的功能。
- 如果···那么···：这个语句缺少了配套的否则，那么如果没有发生会怎么样。
黑盒测试
- 动态黑盒测试又叫做行为测试。清楚了被测试软件的输入和输出之后，接下来要开始定义测试用例。
- 通过性测试和失效性测试是测试软件的两种方法。
- 通过性测试实际上是确认软件至少能做什么，而不会考验其能力。
- 失效性测试或错误强制测试是纯粹为了破坏软件而设计和执行的测试用例。
- 等价类划分
- 在寻找等价类划分时，可以把软件具有相似的输入、相似的输出、相似的操作的分为一组。
- 一个等价类或者等价类划分是指测试相同目标或者暴露相同软件缺陷的一组测试。
- 等价类划分的目标是把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。
- 数据测试
- 对数据进行软件测试就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。
- 边界条件：边界条件是指软件运行在计划操作界限的边界的情况。提出边界条件时，一定要测试临界边界的有效数据，测试最后一个可能的有效数据，同时测试刚超过边界的无效数据。
边界条件数据类型:数值，字符，位置，数量，速度，地点，尺寸。
缓冲区溢出是由边界条件缺陷引起的，是造成软件安全问题的头号原因。 - 次边界条件（内部边界条件）：在软件边界内部，最终用户看不到的边界也是需要检查的。
-
2的幂：在建立等价类划分的时候，要考虑等价类划分是否需要包含2的幂的边界条件。
幂单位 中文 范围或值 Bit 位 0 or 1 Nibble 半字节 0-15 Byte 字节 0-255 Word 字 Kilo Mega Giga Tera -
ASCII表：举例：如果测试进行文本输入或者文本转化的软件，在定义数据划分包含那些值时，参考一下ASCII。如果规定输入字符是a ~ z和A ~ Z，那么非法划分就应该包含ASCII表中这些字符前后的值@、[、’、和{
字符 ASCII值 字符 ASCII值 Null 0 B 66 Space 32 Y 89 / 47 Z 90 0 48 [ 91 1 49 ’ 96 2 50 a 97 9 57 b 98 : 58 y 121 @ 64 z 122 A 65 { 123
-
- 默认、空白、空值、零值和无：好的软件通常将输入内容默认为边界内的最小合法值，或者在合法划分中间的某个合理值，或者返回错误提示信息。因为这些值在软件中通常进行不同的处理，所以不要把这些值与合法情况进行混合。
- 非法、错误、不正确和垃圾数据：这些都是失效性测试的对象。
- 状态测试：软件状态是指软件当前所处的条件或者模式。软件测试的另一个方面就是通过不同的状态验证程序的逻辑流程，软件测试员必须测试程序的状态及其转换。
- 测试软件的逻辑流程
- 建立状态转换图
转换图应该包含：
软件可能进入的每一种独立状态
从一种状态进入另一种状态所需要输入的条件。这个条件可能是按键、菜单选择、传感器信号或者电话振铃等。
进入或者退出某种状态时的设置条件及输出结果。包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等。这些是状态转换时发生的全部或部分现象。 - 减少要测试的状态及转换的数量
- 每种状态至少访问一次。
- 测试看起来是最常见和最普遍的状态转换。
- 测试状态之间最不常用的分支。
- 测试所有错误状态及其返回值。
- 测试随机状态转换。
- 测试状态及其转换包括检查所有状态变量，与进入和退出状态相关的静态条件、信息、值、功能等。
- 建立状态转换图
- 失败状态测试
- 竞争条件和时序错乱
计算机具备多任务执行能力导致竞争条件问题，由于软件未预料到运行过程会被中断，以致造成混乱。 竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。
以下可能面临竞争条件：
两个不同程序同时保存和打开文档。
共享同一台打印机，通信端口或者其他外围设备。
当软件处于读取或者改变状态时按键或者单机鼠标
同时关闭或者启动软件的多个实例
同时使用不同程序访问同一个数据库 - 重复、压迫和重负：这个测试的目标是那些处理程序员没有考虑到，但是在极端恶劣的条件下可能发生问题的状态。
重复测试是不断执行同样的操作。进行这种反复测试的主要原因是检查是否存在内存泄漏。
压迫测试使软件在不够理想的条件下运行（比如内存小，磁盘空间小、CPU速度慢、调制解调器速度低）。
重负测试尽量提供条件任其发挥。比如，让软件处理尽可能大的文件，最大限度发掘软件的能力。
重复、压迫和重负测试可以联合使用，同时进行。
- 竞争条件和时序错乱
- 测试软件的逻辑流程
动态白盒测试
- 动态白盒测试（结构化测试）是指利用查看代码功能和实现方式得到的信息来确定哪些需要测试，哪些不需要测试，如何展开测试。在进行白盒测试之前要先进行黑盒测试。
- 动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件。
动态白盒测试包括以下4个部分
- 直接测试底层函数、过程、子程序和库
- 以完整程序的方式从顶层测试软件
- 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时强制软件以正常测试难以实现的方式运行
- 估计执行测试时命中的代码量和具体代码，然后调整测试 - 分段测试
- 单元测试和集成测试：采取这种策略很容易隔离软件缺陷。这种测试有两条途径，自底向上和自顶向下。
自底向上的方式需要编写测试驱动模块。
自顶向下的方式需要编写桩模块。
- 单元测试和集成测试：采取这种策略很容易隔离软件缺陷。这种测试有两条途径，自底向上和自顶向下。
- 数据覆盖
- 数据流覆盖指在软件中完全跟踪一批数据。
- 次边界
- 公式和等式通常隐藏在代码中，从外部看，其形式和影响不是非常明显。
- 错误强制如果执行在调试器中测试的程序，不仅能够观察到变量的值，还可以强制改变变量的值。
- 代码覆盖
测试数据只是一半的工作，为了全面覆盖，还必须测试程序的状态以及程序的流程。
代码覆盖要求通过完全访问代码以查看运行测试用例时经过了哪些部分。
代码覆盖测试最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。
对于大多数程序进行代码覆盖测试要用到称为代码覆盖分析器（code coverage analyze）- 程序语句和代码行覆盖：代码覆盖最直接的形式称为语句覆盖或者代码行覆盖。目标是保证程序中的每一条语句最少执行一次。
- 分支覆盖：试图覆盖软件中的所有路径称为路径覆盖，而路径测试中最简单的是分支测试。分支测试就是每个判断取真分支和取假分支至少经历一次。
- 条件覆盖：使得每个判断中每个条件的可能取值至少满足一次，但是未必覆盖全部的分支。
- 条件组合覆盖：使得每个判定中条件的各种可能组合至少出现一次。
兼容性测试
- 综合性测试综述：软件兼容性测试是指检查软件之间是否能够正确地交互和共享信息。
- 平台和应用程序版本
- 向前兼容指可以使用软件的未来版本。
- 向后兼容指可以使用软件的以前版本。
- 兼容性测试
在开始兼容性测试任务之前，需要对所有可能的软件组合等价划分，使其成为验证软件之间正确交互的最小有效集合。
- 标准和规范
- 高级标准是产品普遍遵守的规则，例如外观和感受、支持的特性等等。
- 低级标准是本质细节，例如文件格式和网络通信协议。
- 数据共享兼容性
- 在应用程序之间共享数据实际上是增强软件的功能。
文件保存和文件读取是人人共知的数据共享方式。
文件导出和文件导入是许多程序与自身以前版本、其他程序保持兼容的方式。
剪切、复制和粘贴是程序之间无需借助磁盘传输数据的最常见的数据共享方式。
DDE,COM,OLE是Windows中在两个程序之间传输数据的方式。DDE表示动态数据交换，而OLE表示对象链接和嵌入。DDE和OLE数据可以实时地在两个程序之间流动，数据传输可以自动进行。
- 在应用程序之间共享数据实际上是增强软件的功能。
易用性测试
- 优秀的UI标准
-符合标准和规范
-直观
-一致
-灵活
-舒适
-正确
-实用- 符合标准和规范：如果测试在特定平台上运行的软件，就需要把该平台的标准和规范作为产品说明书的补充内容。
- 直观：考虑用户界面是否洁净、不唐突、不拥挤。UI的组织和布局要合理。是否有多余的功能。
- 一致：被测试软件本身以及与其他软件的一致是一个关键属性。在审查产品时考虑以下几个术语：快捷键和菜单选项。术语和命名。听众。OK和Cancel按钮位置。
- 灵活：不要太多，但是足以允许他们选择想要做的和怎么做。
状态跳转：灵活的软件在实现同一任务上有更多选择和方式。结果是增加了通向软件各种状态的途径。状态转换图将变得更加复杂，则需要花更多的时间决定测试的路径。
状态终止和跳过：测试具有跳过众多提示直接去达想要的地方的功能的软件时，如果中间状态被跳过或者提前终止，就需要保证在跳过所有状态或提前终止时变量被设置正确。
数据输入和输出：用户希望有多种方式输入数据和查看结果。 - 舒适
恰当：软件外观和感觉应该与所做的工作和使用者相符。
错误处理：程序应该在用户执行关键操作之前提出警告，并且允许用户恢复由于错误操作而丢失的数据。
性能：如果操作缓慢，至少应该向用户反馈操作持续时间，并且显示它正在工作。 - 正确：测试UI是否完成了应该做的事情
一般正确性问题在测试产品说明书时可以发现，但是要特别注意：市场定位性偏差，语言和拼写，不良媒体，是否所见即所得。 - 实用：实用不是指软件是否实用，而是指具体特性是否实用。
- 辅助选项测试
- 需要考虑视力损伤，听力损伤，运动损伤，认知和语言障碍。
- 软件可以有两种方式提供辅助。最容易的方式是利用平台或者操作系统内置的支持，软件只需要遵守启用辅助选项与键盘、鼠标、声卡和显示器通信的平台标准。如果测试软件不在这些平台上运行或者本身就是平台，就需要定义、编制和测试自己的辅助选项。
- Windows提供了以下能力
粘滞键，允许Shift、Ctrl或者Alt持续生效，直至按下其他键。
筛选键，主要防止简短，重复击键被认可。
切换键，在Caps Lock、Scroll Lock 或者NumLock键盘模式开启时播放声音。
声音卫士，每当系统发出声音时，给出可视警告。
声音显示，让程序显示其声音或者讲话的标题。
高对比度，利用为了便于视力损伤阅读而设计的颜色或者字体设置屏幕。
鼠标键，允许用键盘代替鼠标操作。
串行键，设置一个通信端口读取来自外部非键盘设备的击键。
测试文档
- 软件文档类型
- 包装文字和图形
- 市场宣传材料、广告以及其他插页
- 授权/注册登记表
- 最终用户许可协议(EULA)
- 标签和不干胶条
- 安装和设置指导
- 用户手册
- 联机帮助
- 指南、向导和CBT
- 样例、示例和模板
- 错误提示信息
- 好的软件文档以下3种方式确保产品的整体质量
- 提高易用性
- 提高可靠性，可靠性是指软件稳定和坚固的程度。
- 降低支持费用
- 审查文档要做什么
- 如果文档时非代码的，那么可以用静态的过程，可以视之为技术编辑和技术校对。
- 如果文档和代码紧密结合，就要用到动态测试。
计划测试工作
- 软件测试文档：规定测试活动的范围、方法、资源和进度。明确正在测试的项目，要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
- 测试计划主题
- 定义测试小组的高级期望，明确要测试的是什么产品，测试计划过程和软件测试计划的目的是什么，产品的质量和可靠性目标是什么？
- 人、地点和事，测试计划明确项目种工作的人，知道如何和他联系；知道文档放在哪里等等。
- 定义
- 构造，测试计划应该定义构造的频率以及期望的质量等级。
- 测试发布文档(TRD)，对每一个构造都声明新特性、不同特性、修复问题和准备测试内容。
- Alpha版本，意在对少数主要客户和市场进行数量有限的分发。
- Beta版本，意在向潜在客户广泛发布正式的构造。
- 说明书完成，说明书预计完成并且不再更改的日程安排。
- 特性完成，程序员不再向代码增加新特性，并集中修复缺陷的日期安排。
- 软件缺陷会议。由测试经理、项目经理、开发经理和产品支持经理组成的团队，每周召开会议审查软件缺陷，并确定哪些需要修复，应该如何修复。
- 团队之间的责任，团队之间的责任是明确指出可能影响测试工作的任务和交付内容。
- 明确哪些需要测试，哪些不需要测试。
- 测试的阶段，要计划测试的阶段，并决定在项目期间是采用一个测试阶段还是分阶段测试。测试的计划过程应该明确每一个预定的测试阶段，并告知项目小组。
与测试阶段相关联的两个重要概念是进入和退出规则。每一个阶段都必须有客观定义的规则，明确声明本阶段结束，下一阶段开始。 - 测试策略，描述测试小组用于测试整体和每个阶段的方法。
- 资源需求，计划资源需求是确定实现测试策略必备条件的过程，需要考虑到人员，设备，办公室和实验室空间，软件，外包测试公司等等。
- 测试进度。测试进度需要以上所述的全部信息，并将其映射到整个项目进度中。
测试任务摆脱进度破坏的一个方法是测试进度避免定死启动和停止的日期。
如果测试进度根据测试阶段定义的进入和退出规则采用相对日期，那么明显测试任务依赖于其他先完成的可交付内容。 - 测试用例。测试计划过程将决定用什么方法编写测试用例，在哪里保存测试用例，如何使用和维护测试用例。
- 软件缺陷报告。报告可以有多种方法，使用哪些方法需要进行计划，以便每个软件缺陷从发现到修复过程中都被跟踪。
- 度量和统计。度量和统计是跟踪项目发展、成效和测试的手段。
实用的测试度量的例子如下
在项目期间每天发现的软件缺陷总数
仍然需要修复的软件缺陷清单
根据严重程度对当前软件缺陷评级
每个测试员找出的软件缺陷总数
从每个特性或者区域发现的软件缺陷数目 - 风险和问题。测试计划中常用并且非常实用的部分是明确指出项目的潜在问题或者风险区域。
编写和跟踪测试用例
- 测试用例计划的目标
- 组织。正确的计划会组织好用例，以便全体测试员与其他项目小组成员有效地审查和使用。
- 重复性。在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。
- 跟踪。在整个项目期间需要回答这些问题：计划执行多少个测试用例？在软件最终发行版本上执行多少个测试用例？多少个通过，多少个失败？有被忽略的测试用例吗？
- 测试（或者不测试）证实。在少数高风险行业中，软件测试小组必须证明确实执行了计划执行的测试。正确的测试用例计划和跟踪提供了一种证明测试内容的手段。
- 测试用例计划综述
- 测试设计说明的目的是组织和描述针对具体特性需要进行的测试。
- 测试设计的内容
标识符，用于引用和标记测试设计说明的唯一标识符。
要测试的特性，测试设计说明包含的软件特性描述。该部分还将明确指出作为主要特性的辅助特性需要间接测试的特性。还要列出不被测试的特性。
方法，描述测试软件特性的通用方法。
测试用例确认，对用于检查特性的具体测试用例的高级描述和引用。重要的是，这部分不定义实际测试用例值。
通过/失败规则，描述测试特性的通过和失败由什么构成。 - 测试用例
包含信息：
标识符，由测试设计过程说明和测试程序说明引用的唯一标识符
测试项，描述被测试的详细特性，代码模块。应该比测试设计说明中所列的特性更加具体。
输入说明，该说明列举送到软件执行测试用例的所有输入内容和条件。
输出说明，描述进行测试用例预期结果。
环境要求，执行测试用例必要的硬件、软件、测试工具、实用工具、人员等。
特殊过程要求，描述执行测试必须做到的特殊过程要求。
用例之间的依赖性.
表达测试用例的其他选择有简单列表、大纲甚至诸如状态表或数据流程图之类的图表。 - 测试程序
标识符，把测试程序与相关测试用例和测试设计捆绑在一起的唯一标识符。
目的，程序的目的以及将要执行的测试用例的引用信息。
特殊要求，执行程序所需的其他程序、特殊测试技术或者特殊设备。
程序步骤，关于执行测试的详细描述
日志，指出用什么方式方法记录结果和现象
设置，说明如何准备测试
启动，说明启动测试的步骤
程序，描述用于运行测试的步骤
度量，描述如何判断结果
关闭，说明由于意外原因挂起测试的步骤
重启，告诉测试人员如果出现故障或者关闭以后如何在恰当的时候重启测试
终止，描述测试正常停止的步骤
重置，说明如何把环境恢复到测试前的状态
偶然事件，说明如何处理计划之外的情况。
- 测试用例组织和跟踪
- 管理和跟踪系统的方法：
书面文档，对于小项目可以用纸笔来管理测试用例。
电子表格，这种方法容易使用，容易建立，可以为测试提供很好的跟踪和证明。
自定义数据库，测试用例管理工具，一种为处理测试用例而专门编程设计的数据库。
- 管理和跟踪系统的方法：