软件测试基础

软件

软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档

需求

• 满足用户期望或正式规定文档所具有的条件和权能

  • 用户需求
  • 软件/功能需求

软件生命周期

• 需求-设计-编码-测试-维护（持续时间最长）-弃用

软件开发模型

• 瀑布模型

  • 线性顺序进行的软件开发模式 需求分析-概要设计-详细设计-编码-测试-维护
  • 优点：线性模型，文档驱动，只用关注当期阶段
  • 缺点：不响应需求变化，测试人员没有尽早介入

• 螺旋模型

  • 开发前期需求不明确，采用渐进式开发模式，回归测试十分重要
  • 适用于规模庞大，复杂度高，风险大的项目

• 增量模型：逐块构建，降低项目风险

• 迭代模型：反复求精

• 敏捷开发模型

  • 在计划的执行中做出对变更的响应，强调测试在其中的重要作用。
  • 以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。

软件测试

定义

• 使用人工或自动手段来对程序进行操作，以发现程序错误，衡量软件质量，评估它是否满足规定的需求。关键在如何选择测试用例

目的

• 软件测试为了发现程序中存在的代码或业务逻辑错误，检验产品是否符合用户的需求，提高软件质量与用户体验。

测试与调试

• 测试由测试和开发执行，目的是发现软件的缺陷，贯穿整个软件开发周期
• 调试由开发执行，目的是定位解决程序中的问题，一般在开发阶段

策略

• 在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

测试用例与测试脚本

• 用例：未实施测试而编制的一组测试输入、执行条件、各种环境设置以及预期结果以及期望结果的一个特定的集合。
• 脚本：测试脚本是为了进行自动化测试而编写的脚本。测试脚本的编写必须对应相应的测试用例。

原则

• 所有的测试都应追溯到用户需求

  • 测试需求分析及需求评审要做好

• 尽早启动测试工作

  • 测试应该是与软件开发或维护工作并行进行的一个过程，早做测试计划。

• 无法穷尽测试

  • 确定测试的重点和优先级

• 缺陷具有群集效应，一般情况下80％的缺陷聚集在20％的关键核心业务模块中。

• 软件测试可以报告软件缺陷存在，却不能报告软件缺陷不存在；

• 为了保证测试的有效性和高效性，测试必须是破坏性、系统化的

• 杀虫剂怪事

  • 为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序。

• 前进两步，后退一步

  • 确认测试

    • 测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，验证之前的提交的缺陷是否真正修复。

  • 回归测试

    • 测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，确保对程序修改改没有给软件其他未改变部分带来新的缺陷。软件修改或者环境变更后，必须进行回归测试。

软件质量模型

• 功能性：能够满足明确和隐含要求的功能
• 可靠性：能够处理异常情况，在错误中很快恢复
• 可使用性：易懂、易学、易用、漂亮好看
• 效率：占用的资源，提供适当的性能。通常，效率就是我们常说的产品性能
• 可维护性：是指产品可被修改的能力
• 可移植性：是指软件产品从一种环境迁移到另外一种环境的能力

软件测试模型

• V模型

  • 需求分析-概要设计-详细设计-编码-单元测试（对应详细设计）-集成测试-系统测试-验收测试

  • 优点

    • 模型明确地将测试分为不同的级别或阶段。

      • 每个阶段都与开发的各阶段相对应。

    • 模型的测试策略包括低层测试和高层测试，

      • 低层测试是为了源代码的正确
      • 高层测试是为了整个系统满足用户的需求。

  • 缺点

    • 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现；过程是线性的

• W模型

  • 开发V

    • 需求分析-概要设计-详细设计-编码-集成 -实施-交付

  • 测试V

    • 需求测试-概要设计测试-详细设计测试-单元测试设计-集成测试设计-系统测试设计-验收测试设计

  • 测试伴随整个软件开发周期。测试的对象不仅仅是程序，需求、设计等同样要测试。

软件测试分类

按阶段分类

• 单元测试

  • 各独立单元模块在与系统的其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。

  • 单元：单元是程序里最小的，可单独执行编码的单位

    • 源代码

      • 如JAVA中的一个类/C语言中的一个函数，用白盒测试

    • 功能模块

      • 如web产品的一个页面，用黑盒测试

• 集成测试

  • 集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

  • 将所有程序模块进行有序的、递增的测试，测试关注点是接口的传递参数与返回数据，用灰盒测试

    • 自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
    • 自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

• 系统测试

  • 将通过确认测试的软件，把整个计算机系统作为一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖
  • 根据需求说明书，测试整个系统功能与非功能是否满足需求。

• 验收测试

  • 由用户验证是否可以接受整个系统，目的是识别未知应用环境对系统的影响。

    • α测试：内测版本

      • 是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

    • β测试：公测版本

      • 由软件的一个或多个用户在实际使用环境下进行的测试，开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

按是否看源代码

• 黑盒测试

  • 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用

    • 等价类划分、边界值分析法、错误猜测法、因果图法、随机测试、场景法

• 白盒测试

  • 白盒测试也称结构测试或逻辑驱动测试，白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。 覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖

    • 语句覆盖

      • 程序中每条语句至少被执行一次。

    • 判定覆盖

      • 程序中的每个判断真假至少执行一次。

    • 条件覆盖

      • 每个判定的每个条件至少有一次为真值，有一次为假值。

    • 判定/条件覆盖

      • 判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。

    • 条件组合覆盖

      • 每个判定中条件结果的所有可能组合至少出现一次。

    • 路径覆盖

      • 覆盖程序中所有可能的路径。

• 灰盒测试

  • 灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。 通常，灰盒方法中使用自动化软件测试工具来执行测试过程。提供给测试人员的模块驱动程序可以减轻手动代码生成的负担。

是否运行

• 静态测试

  • 静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性

    • 需求说明书各种设计文档，比如数据库设计文档
    • 代码（代码走查->白盒测试）
    • sql脚本

• 动态测试

  • 动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。

是否自动化

• 手工测试

• 自动化测试

  • 功能自动化，性能自动化

其他策略

• 正交阵列测试

  • 此测试的目的是用最少的测试用例覆盖最大代码

• 随机测试：对被测软件的重要功能进行复测

• 探索性测试：同时设计测试用例与执行测试，边测试边学习被测系统

• 冒烟测试：对系统进行最基本功能的测试

  • 服务器的网络连通，数据库连通性，最基本功能，最核心的业务流程

• 回归测试：修复一个bug后，把之前测试用例在新代码下重新测试，用于验证软件的修改是否对软件的任何其他部分造成缺陷

  • bug回归 旧功能回归

软件测试流程

需求分析

• 前期准备：

  • 明确自己负责的需求模块，提前熟悉需求文档，针对需求描述，思考如何进行测试设计，只要需求的描述不能够完全支持写用例，就要提出来（二义性、模糊、描述不清楚）

• 评审过程中：

  • 产品、开发、测试开会来评审需求内容，评审需求说明书是否有遗漏，确保项目组的成员对于需求说明书的理解达成一致

编写测试计划与测试方案

• 测试计划：

  • 测试的目的和范围 执行计划的角色和用户 任务的进度安排 风险估计与应急预案 测试的准入及准出标准

• 测试方案：

  • 测试策略 测试环境 测试工具

设计测试用例

执行测试用例与缺陷管理跟踪

• 如何准备测试数据

  • 手工录入、导入生产环境数据、在数据库创建账号

编写测试报告

• 概述、测试时间、地点、人员、环境描述、总结和评价、测试过程质量统计评估、软件产品质量统计评估、系统测试综合评价、系统测试遗留问题报告

缺陷及缺陷管理

缺陷

• 缺陷的定义

  • 产品实现不满足用户需求
  • 测试执行时，实际结果和预期结果不一致

• 缺陷的判定标准

  • 未达到需求说明书指明的功能
  • 出现了需求说明书指明不应该出现的错误
  • 实现了需求说明书之外的功能
  • 未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）
  • 用户角度发现的各种问题与错误

• 缺陷产生的原因

  • 需求文档存在错误

    • 需求变更

  • 代码错误

    • 软件复杂

      • 进度压力

  • 沟通不畅、信息不同步

缺陷管理

• ID 模块 优先级 标题 严重程度 前置条件 执行步骤 预期结果 实际结果 附件

bug生命周期

• 新建-指派-修复/拒绝/延后-验证-关闭

禅道

禅道使用流程

• 1.产品经理创建产品

• 2.产品经理创建需求

• 3.项目经理创建项目

• 4.项目经理确定项目要做的需求

• 5.项目经理分解任务，指派到人

• 6.开发人员实现需求

• 7.测试人员测试，提交bug

禅道用户角色

• 超级管理员

• 产品经理

• 项目经理

• 开发

• 测试

  • 创建用例

    • 【测试账号】登录
    • 【测试】--【用例】--【建用例】
    • 【测试】---【用例】-- 点击右上角“建用例”的下拉菜单，选择【批量添加】

  • 导入用例

    • 第一步：导出测试用例模板

      • 【测试】---【用例】，右上角按钮【导出】--【导出模板】，选择【GBK】字符，点击保存

    • 第二步：按照模板编写测试用例

    • 第三步：导入编写好的用例文件

      • 【测试】--【用例】，右上角【导入】--【导入CSV】，选择测试用例文件，选择“GBK”，点击保存

  • 评审用例

    • 测试人员登录，进入【测试】--【用例】，新建一个需要评审的用例（不勾选“不需要评审”）

    • 在【测试】--【用例】，对需要评审的用例，点击操作栏“评审”按钮，进行评审。

      • “确认通过”：用例从【待评审】状态改为【正常】状态
      • “继续完善”：用例保持【待评审】状态

  • 版本关联用例

    • 测试人员登录系统，进入【测试】---【版本】，查看提交测试的版本
    • 点击操作栏中的“关联用例”按钮，勾选用例（正常状态），点击保存。

  • 执行用例

    • 测试登录系统，进入【测试】---【版本】---【用例】，点击操作栏中的执行按钮
    • 用例执行的结果：【通过】，【失败】，【阻塞】，【忽略】
    • 失败的用例，可以点击“转BUG”，填写BUG信息，点击保存。
    • 可以直接提BUG：进入测试--BUG，点击“提BUG”，填写信息，点击保存

  • BUG跟踪

    • 测试提交缺陷

    • 开发解决缺陷

    • 测试回归验证

      • 确认修复，关闭缺陷
      • 并未修复，激活缺陷，重新指派给开发解决

    • 关闭后的缺陷再次出现，测试激活该缺陷

测试用例

测试用例8大要素

• ID 模块 优先级 标题 执行条件 测试数据 执行步骤 预期结果

评价测试用例的好坏

• 表达清楚无二义性，可操作性强，输入输出明确
• 一条用例一条预期结果，可维护性好，覆盖率高，bug暴露能力强

测试用例设计方法

• 等价类划分法

  • 概念

    • 等价类：一类具有共同特性的测试输入的一部分（测试子集）
    • 在等价类中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。

  • 分类

    • 有效等价类

    • 无效等价类

      • 长度，类型，操作，空异常

  • 设计测试用例的步骤

    • 需求分析-划分等价类-设计测试用例

      • 见等价类模板Excel

  • 典型应用场景

    • 具有输入功能，但输入之间没有组合关系

• 边界值分析法

  • 是对等价类划分方法的补充。大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况。

  • 边界确定

    • 上点：边界上的点（正好等于），必选 离点：距离上点最近的点（刚好大于、刚好小于），开内闭外 内点：范围内的点（区间范围内的数据），必选

  • 设计测试用例的步骤

    • 1.明确需求 2.确定有效和无效等价类 3.确定边界范围值 4.提取数据编写测试用例

  • 典型应用场景

    • 在等价类的基础上针对有边界范围的测试数据输入的地方 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语 典型代表：有边界范围的输入框类测试

• 场景法

  • 概念

    • 用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例

  • 设计测试用例的步骤

    • 需求分析

    • 绘制流程图

      • 第1步：确认场景中关键业务步骤
      • 第2步：确定业务之间的先后顺序
      • 第3步：用箭头连接即可

    • 设计测试用例（一条流程路径就是一条测试用例）

  • 典型应用场景

    • 对于多个功能之间的组合逻辑测试，可以使用场景法

• 判定表法

  • 概念

    • 一种以表格形式表达多条件逻辑判断的工具
    • 条件桩：列出问题中的所有条件。列出条件的次序无关紧要。 动作桩：列出问题中可能采取的操作。操作的排列顺序没有约束。 条件项：列出条件对应的取值。所有可能情况下的Y/N值或0/1值。 动作项：列出条件项的各种取值情况下应该采取的动作结果。

  • 设计测试用例的步骤

    • 明确条件桩（找到所有的输入条件）-生成测试用例-对条件桩进行全组合-明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合下的输出结果）-设计测试用例，每行数据对应一条测试用例

  • 典型应用场景

    • 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

• 因果图

  • 概念

    • 用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法

  • 基本符号

    • 恒等（-）：条件成立，结果成立。
    • 非（~）NOT：条件成立，结果不成立；条件不成立，结果成立。
    • 或（V）OR：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
    • 与/且（^）AND：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。

  • 设计测试用例的步骤

    • 需求分析-画出因果图-将因果图转换为判定表-生成测试用例

• 正交法

  • 概念

    • 大量的参数的组合引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围。

  • k因素m水平Ln(mk)

    • k代表因素（输入参数）
    • m叫水平（输入参数的取值）
    • n代表测试用例数

  • 设计测试用例的步骤

    • 需求分析-确定因素与水平（因素：控件名称；水平：每个控件对应的取值）-确定要采用的正交表-将正交表中的字母用文字代替-设计测试用例（一行就是一条测试用例）

  • 基于allpairs设计测试用例

    • 将确定的因素与水平复制到txt文件中
    • 打开DOS窗口，进入allpairs目录，运行命令：allpairs.exe test.txt > result.txt
    • 根据生成的新文件编写测试用例（一行就是一条测试用例）

• 错误推测法

  • 概念

    • 利用经验或智慧发现程序中可能犯错的地方

  • 使用场景

    • 重要功能，使用同类型产品，任务急、时间紧、资源少