测试基础知识-软件测试 原书第二版 总结

介绍

软件组成：计算机程序+说明文档

计算机程序：源程序、目标程序(机器码/二进制码)

源程序：按照一定的程序设计语言规范编写的文本文件

目标程序：源程序经编译或解释后可以由计算机直接执行的程序

确认：保证软件符合产品说明书的过程

验证：保证软件满足用户要求的过程

质量：功能、性能、可靠性、稳定性等

软件质量保证人员：改进软件开发过程、防止软件缺陷发生

调试：开发人员在开发阶段定位并解决程序中的问题

产品说明书、product specification

• PRD：Product Requirement Document、产品需求文档
• 测试以PRD文档为准，让产品随时更新PRD（会变化）
• 作用：对产品进行定义，如何做、做什么、不能做什么等

什么是软件缺陷？

• 软件未实现产品说明书【要求的功能】。
• 软件未实现产品说明书【未明确提及但应该实现的功能】。
• 软件实现了产品说明书【未提到的功能】。
• 软件出现了产品说明书指明【不应该出现的错误】。
• 软件难以理解、不易使用、运行慢或者从测试员的角度看用户会认为不好的（客观）

出现缺陷的原因？

• 设计编码：需求复杂、时间短任务重
• 沟通不足
• 说明书：没有、经常修改

测试的目的

• 尽可能早的找出软件缺陷，并确保其得以修复
• 修复缺陷的成本：随着时间的推移，修复软件缺陷的费用惊人地增长（产品说明书、设计、编码、测试、发布）
• 软件测试员把提高软件质量作为最终目标。
• 修复并非一定要改正软件，可以是在用户手册中增加注释、或者给客户提供特殊培训
• 软件测试员是客户的眼睛，是第一次看到软件的人，代表客户说话，应力求完美

优秀软件测试员具备特点

• 不放过蛛丝马迹：不停尝试复现难以重现的缺陷
• 准确的判断：确定测试内容、测试时间，以及出现的问题是不是缺陷
• 注重外交：知道和不够冷静的程序员如何合作
• 善于说服：清晰的说明软件缺陷为什么需要修复，以及推荐缺陷的修复

软件开发过程

全过程：客户需求-->产品说明书-->进度表-->软件设计文档-->测试文档

• 软件设计文档：规划软件如何编写，结构文档、流程图、代码注释等
• 测试文档
  • 测试计划：用于验证软件是否符合产品说明书和客户需求的整体方案
  • 测试用例：验证软件的详细步骤
  • 缺陷报告：描述执行测试用例找出的问题
  • 自动测试：确定自动测试范围、需要实现的脚本等
  • 统计和总结：汇总测试过程

项目成员

• 项目经理、产品经理：编写产品说明书、管理进度、进行重大决策
• 架构师：设计整个系统的体系架构
• 程序员：编写软件并修复软件中的缺陷
• 测试员：找出并报告软件产品的缺陷
• 实施、用户培训专员：编写软件产品附带的文档
• 配置管理员：负责把代码和文档组合在一起，合成一个软件

开发生命周期、模式

• 大爆炸模式：所有精力都花在编写代码上，计划和进度安排基本没有，最大优点是简单
• 边写边改模式：简易说明书->编码、测试、修改->最终产品
• 瀑布模式：先计划-》需求分析-》设计-》开发-》构建-》测试-》发布-》最终产品
  • 优点：所有细节都有文档记录，并且实现在软件中
  • 缺点：无法适应快速变化的需求，问题在最后才能被发现
• 螺旋模式：开始不必定义所有细节，先定义重要功能，实现重要功能，接受客户反馈，计划下一阶段，重复这个过程，直到得到最终产品
• 敏捷软件开发：把大项目变成小项目，循序渐进的开发方式
  • 很短时间内完成小项目的开发，频繁交付不断完善的产品，能适应快速变化需求
  • 在很短的周期内开发出产品的核心功能，尽早发布可用版本
  • 后续在按照新需求不断迭代升级，完善产品
  • 要求团队成员之间紧密协作、面对面沟通

软件测试实质

• 完全测试程序是不可能的（输入量太大、输出结果太多、软件执行路径太多）
  • 关键思想：找到最优测试量，使测试费用、漏掉的缺陷在正常范围
• 在任何情况下都不能保证软件没有缺陷
• 一个软件缺陷附近可能有其它软件缺陷
• 杀虫剂现象：反复执行同样的测试、不会出现新的软件缺陷
• 并非所有软件缺陷都要修复（时间不够、修复风险大、不算真正缺陷、不值得修复-对客户影响小）
• 不受欢迎：早点找出缺陷、不要总报告坏消息（报告缺陷给充足的信息、赞美没有缺陷、找程序员聊天）

 

 测试基础

• 静态测试：不运行软件、只是检查
• 动态测试：运行软件进行测试
• 功能测试：对软件的功能进行测试
• 黑盒测试：从用户角度出发测试软件的功能，不需要了解程序内部的代码及实现
• 测试流程：看产品说明书->评审产品说明书->设计用例->评审用例->执行测试->分析测试结果
• 注意：带着为什么和怎么做去看说明书，描述是否准确，测试难点等
• 静态黑盒：检查产品说明书
• 动态黑盒：运行软件测试功能
• 优点：从用户角度出发，更容易发现用户会遇到的问题
• 缺点：代码覆盖率较低，无法保证代码质量

• 白盒测试：了解程序内部结构和处理过程，检查程序中的每条执行路径是否正确的工作
  • 测试流程：分析程序内部逻辑结构-->流程图-->制定测试用例-->执行路径-->分析覆盖情况
    • 根据说明书先编写黑盒测试用例、研究代码看是如何实现的、根据白盒知识增减测试用例
  • 静态白盒：检查软件设计、结构及代码
  • 动态白盒：代码覆盖测试（单元测试、语句覆盖、分支/判定覆盖、条件覆盖、路径覆盖）
    • 单元测试：对软件中的最小可测试单元（程序模块）进行测试，比如函数、类等
    • 集成测试：将多个单元组合进行测试，测试其功能及单元间的接口

    • 系统测试：对整个产品或者产品的主要部分执行测试

    • 语句覆盖：每条语句最少执行1次（单if语句：覆盖正确或错误即可，存在执行路径未被覆盖）

    • 分支、判定覆盖：每个分支最少执行1次（多if语句：只考虑正确、错误分支，存在执行路径没有覆盖）

    • 条件覆盖：每个条件至少取一次真值和假值

  • 优点：增加代码覆盖率、提高代码的质量
  • 缺点：遗漏用户的实际体验

• α测试：一个用户在开发环境下对软件进行测试

• β测试：多个用户在生产环境下对软件进行测试

• 冒烟测试：测试软件基本功能是否满足要求（通过性测试）

• 回归测试：软件修改后重新测试之前的内容
• 压力测试、负载测试：在系统上不断加压，发现系统处理能力的极限
• 性能测试：在特定的运行条件下验证系统的处理能力（之前就了解系统性能，有明确目标）

 

黑盒用例设计

等价类划分法

核心思想：将程序的输入域划分为若干个等价类，只需从每个等价类中选取一个代表性数据进行测试即可。（每个等价类中，各个输入数据对发现缺陷的作用是相同的）

• 有效等价类：符合需求说明的、合理的输入数据集合。用于验证程序是否实现了预期功能。
• 无效等价类：不符合需求说明的、不合理或无意义的输入数据集合。用于验证程序的异常处理能力。

举例：测试一个“用户名”输入框，要求是1-10个字符。

• 有效等价类：[1-10个字符]（如 “Tom”）
• 无效等价类：[0个字符]（空），[>10个字符]（如 “ThisIsALongName”），[包含特殊字符]（如 “User@#”）

边界值分析法

核心思想：针对输入域的边界设计测试用例。

• 方法：选取正好等于、刚刚大于和刚刚小于边界的值作为测试数据。

举例：同样测试“1-10个字符的用户名”，

• 边界点是1和10。
• 测试用例应包括：0个字符（刚好小于min）、1个字符（刚好等于min）、2个字符（min+1）、9个字符（max-1）、10个字符（刚好等于max）、11个字符（刚好大于max）。

判定表法

核心思想：分析多个输入条件在不同组合下，分别会是什么输出结果。

因果图法：利用图解法来分析输入的各种组合情况，最终将因果图转换为判定表，从而设计测试用例（适合输入条件很多）

• 条件桩：列出了问题的所有输入条件，通常位于表格左上部分。

• 条件项：针对条件桩列出的条件，给出其所有可能的取值（真/假、是/否、0/1等）。

• 动作桩：列出了问题可能采取的所有操作，位于表格左下部分。

• 动作项：指出在条件项的各种取值组合下，应该采取什么动作（得到什么样的结果）。

举例：电商平台的“订单审核”规则：“如果用户是VIP，并且订单金额大于500元，则免运费；否则，收取10元运费。”

规则编号	1	2	3	...
条件桩\条件项
条件1：用户已登录？	Y	N	Y
条件2：用户是VIP？	Y	-	N
条件3：金额大于500元？	Y	-	-
动作桩\动作项
动作1：提示请先登录		Y
动作2：免运费	Y
动作3：10元运费			Y

 

场景法 - 流程图法

核心思想：基于用户使用软件的特定场景（业务流程）来设计测试用例。（用户平时使用的不是单个功能，而是多个功能组合成完整流程来使用）

• 基本流：按照正确的业务流程操作的一种路径

• 备选流：出现错误的操作流程

举例：测试“ATM取款”功能。

• 基本流：插卡 -> 输入正确密码 -> 选择取款 -> 输入合法金额 -> 取钞 -> 退卡。

• 备选流1：输入错误密码。

• 备选流2：卡内余额不足。

• 备选流3：ATM机内现金不足。

 

状态图法

核心思想：画出状态转移图（进入、退出条件等），设计测试用例来覆盖所有可能的状态和它们之间的转换。（模拟在不同状态下触发不同事件，检查是否正确地迁移到了目标状态）

举例：测试音乐播放器。

• 状态包括：关闭， 待机， 播放， 暂停。
• 事件包括：按电源键， 按播放键， 按暂停键。

 

错误猜测法

核心思想：依靠测试人员的经验、知识和直觉，推测程序中可能存在的各种错误，从而有针对性地设计测试用例。

举例：测试文件上传功能时，有经验的测试员会下意识地测试：上传超大文件、上传0字节文件、上传病毒文件（后缀名伪装）、上传文件名包含特殊字符的文件等。

 

白盒测试用例设计方法：语句覆盖、判定覆盖、条件覆盖、路径覆盖

 

测试的补充

配置测试：使用不同硬件配置来测试软件的运行情况

兼容性测试：检查软件之间是否能够正确地交互和共享信息

外语测试：测试为其它语言编写的软件是否正确

易用性测试：测试软件是否易于使用

文档测试：验证文档的正确性

安全性测试：检验产品是否符合安全需求定义，发现软件安全漏洞的过程

自动化测试：使用专门的软件工具和脚本来自动执行测试用例、管理测试数据、比较实际结果与预期结果，并生成测试报告的过程。

• 自动化最大用处：重复执行测试（回归测试），保证前面测试中发现的软件缺陷修复了，同时又没有引入新的软件缺陷
• 自动化的优点：速度、效率（并行）、准确、节省资源（模拟用户、硬件等）、一直运行
• 测试工具不能代替软件测试员，它们只能帮助软件测试员更好地工作
• 清楚何时使用工具和使用哪一种工具是软件测试员的重要技能

随机测试、猴子测试：随机模拟用户可能的操作

测试共享：你执行我的测试，我执行你的测试（不同的人对事物关注点不同、测试方法也有所不同）

缺陷轰炸：一段时间内整个测试小组集中测试某个区域

beta测试：让客户在实际环境中测试软件（通常只能发现明显的大问题）

 

测试文档

 

利用精心组织的测试计划、测试用例和测试报告，对测试工作进行正确的记录以及交流，可以使达到目标变得更有可能。

测试计划：规定测试的范围、方法、资源和进度；明确测试的项目、具体测试任务、每个任务的负责人，以及相关的风险。

• 重要的是计划测试过程，而不是产生的结果文档（交流期望、任务理解等）
• 计划测试是一项全体测试员和整个产品小组中的主要人员参与的工作；

高级期望

• 产品开发早期，对为什么要测试，怎样去测试形成全面的理解和一致的同意
• 明确产品的质量和可靠性目标
• 所有相关人同意和支持这个测试计划过程（如何测试软件的过程）
• 完全了解产品是什么，以及其数量和适用范围

重点内容：

• 明确时间：产品说明书完成时间、开发文档完成时间、特性开发完成时间、缺陷会议时间
• 明确责任：明确可能影响测试工作和交付内容的责任人（产品负责人、开发负责人）
• 测试内容：需要测试的内容
• 测试的阶段：明确每一个测试阶段的进入和退出条件（产品说明书评审、冒烟测试）
• 测试策略：描述测试小组用于测试每个阶段和整体的方法（黑盒、白盒、手动、自动化、测试工具等）
• 测试资源需求：明确测试期间需要用到的任何资源（人员、设备、工具、外包测试等）
• 测试任务分配：明确测试员负责软件的哪些部分、哪些可测特性
• 测试进度：完成测试进度安排，计划每个测试模块需要花费的时间（开始时间和使用时间采用相对日期、相当于开发提交代码的时间）
• 测试用例：决定用什么方法编写测试用例，在哪里保存测试用例，如何使用和维护测试用例
• 测试缺陷记录：决定记录和跟踪所发现的软件缺陷的工具
• 测试统计：明确收集哪些信息，要做什么决定，谁来负责收集（每天BUG修复情况）
• 风险和问题：明确指出项目的潜在问题或者风险区域

 

测试用例：验证软件的详细操作步骤和结果判断（有条不紊地仔细计划测试用例，是达成目标的必由之路（考虑如何测试每个功能））

测试设计：为单个软件特性功能定义测试方法（包含具体特性、用例、通过\失败规则）

流程：需求分析->说明书评审（带着疑问）->提取测试点->编写测试用例->评审用例

评审用例：讲解测试思路、覆盖所有功能点、尽可能覆盖异常测试点

• 测试人员介绍本次设计用例的主要思路
• 测试人员介绍主要测试的业务场景，在测试过程使用的测试方法
• 评审用例设计是否合理，功能覆盖、异常流程（合法、不合法、边界条件等）
• 记录评审结果与问题，并以邮件等形式通知参与人员

用例内容：用例编号、名称（测试项）、测试背景、优先级、重要级、预置条件、测试数据、执行步骤、预期结果、实际结果

测试用例组织和跟踪：执行用例数量、花费时间、通过百分比等等

报告发现的问题：BUG（缺陷）管理