本文主要涉及
第一部分 软件测试基本概念
第二部分 软件测试技术（方法）

1.Introduction

软件测试指对软件产品进行充分测试，尽早找出其中的缺陷(Bug),并督促相关人员进行修复(Fix)。

1.1 What is Software Bug

Doesn’t do something it should do.
Does something it shouldn’t do.
Does something it doesn’t mention.
Doesn‘t do something it doesn’t mention but should.
It’s difficult to understand, hard to use, slow, or——in the software tester’s eyes——will be viewed by the end user as just plain not right.
不做它应该做的事情。
做一些它不应该做的事情。
做一些它没有提到的事情。
不做它没有提到但应该做的事情。
它很难理解，很难使用，速度慢，或者 - 在软件测试人员眼中 - 将被最终用户视为完全不对。

•Defect缺陷
•Fault错误
•Problem问题
•Error错误
•Incident事变
•Anomaly异常
•Variance偏差
•Failure失败
•Inconsistency矛盾
•Product Anomaly产品异常
•Product Incidence产品事变
•Feature

1.2 Tester的职责和目标

To find bugs
To find them as early as possible
To make sure they get fixed

The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.
软件测试人员的目标是发现错误，尽早找到它们，并确保它们得到修复

其他概念

Fault、Faliure和Error
Software Fault : A static defect in the software
Software Failure : External, incorrect behavior with respect to the requirements
or other description of the expected behavior
Software Error : An incorrect internal state that is the manifestation of some fault

软件测试的分类

按方法：黑盒测试、白盒测试
按目标/特性：功能测试、健壮性测试、性能测试、适用性测试、安全性测试、可靠性测试
静态测试：需求评审、概要设计评审、详细设计评审、代码检查
动态测试：单元测试、集成测试、系统测试、验收测试

2.软件开发生命周期Software Development Process

Software Development Lifecycle Models

• Big-Bang
• Code-and-Fix 反复编码和修复
• Waterfall 瀑布模型-分析-设计-开发-测试-产品
  • 一旦创建，就不会改变
  • 随后的任何阶段之间都没有重叠
• Spiral 螺旋-决定对象-识别风险-评估-开发测试-准备下一迭代
  • 风险驱动的开发过程
  • 瀑布模型和快速原型迭代模型的组合
  • 以设计目标开始，以客户审查进度结束。

TDD - Test-Driven Development测试驱动开发（一种敏捷开发）

测试驱动开发 （TDD） 是一种软件设计方法。

先编写测试代码，再进行开发
先编写产品的框架，是指先编写类、方法空的实现
编译通过然后编写测试类，针对产品类的功能编写测试用例
然后编写产品类的代码，每写一个功能点都运行测试，随时补充测试用例
编写的测试代码以后需要修改的可能性比较小

Software Testing Model 软件测试模型

⭐V模型

• V 模型是经典瀑布模型的增强版本，其中开发生命周期的每个级别在进入下一个级别之前都经过验证。
• 通过标记生命周期的每个阶段与测试活动之间的关系，强调验证与确认
• 从代码编写完成开始测试
• 从单元测试开始，一次提升一个测试级别，直到验收测试阶段完成

生成的每个文档都与模型中的阶段对相关联
（a） 用户需求书。URS
（b）系统需求规范，SRS
（c）系统设计规范，SDS
（d）详细设计规范，DDS

优点

• 由于模型的严格性（rigidity），它既简单又易于管理。
• 它鼓励在所有阶段进行验证和确认。
• 它在开发的同时对测试给予同等的重视，而不是将其视为事后的想法。

缺点

• 与瀑布模型一样，直到生命周期的后期才生产出可工作的软件。
• 它不适用于需求具有中高变化风险的情况。每个阶段都有具体的可交付成果和审查流程。
• 对于长期、复杂和面向对象的项目来说，它是一个糟糕的模型。

⭐W模型

每个阶段必须完全完成，然后才能开始下一个阶段。
在开发过程的同时，进行测试过程。
开发和测试之间的合作
软件测试伴随整个软件开发周期
测试对象不仅是程序，还有需求、设计和功能

• 根据W模型的要求，一旦提供了文件，应及时确定测试条件和测试用例
• 使用这种模型，软件测试明确地从一开始开始，即在编写需求后立即开始。

H模型

测试不仅指测试执行，还包括许多其他活动。
软件测试是一个独立的过程，贯穿产品的整个生命周期，并与其他过程同时进行。
应尽快准备和执行软件测试。
软件测试根据被测对象的不同分层进行。
不同级别的测试活动可以按一定的顺序进行，但也可以重复进行。

X模型

X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。
多根并行的曲线表示变更可以在各个部分发生。

其他概念

Software Design Documents
● Architecture
● Data Flow Diagram
● State Transition Diagram
● Flowchart
● Commented Code

Test Documents
● test plan
● Test cases
● Bug reports
● Test tools and automation
● Metrics, statistics, and summaries
测试文档
● 测试计划
● 测试用例
● 错误报告
● 测试工具和自动化
● 指标、统计数据和摘要

3. The Realities of Software Testing

♦ (1) It’s Impossible to Test a Program Completely
♦ (2) Software Testing Is a Risk-Based Exercise
♦ (3) Testing Can’t Show That Bugs Don’t Exist
♦ (4) The More Bugs You Find, the More Bugs There Are
♦ (5) The Pesticide Paradox
♦ (6) Not All the Bugs You Find Will Be Fixed
♦ (7) When a Bug’s a Bug Is Difficult to Say
♦ (8) Product Specifications Are Never Final
♦ (9) Software Testers Aren’t the Most Popular Members of a Project Team
♦ (10) Software Testing Is a Disciplined Technical Profession

♦ （1）不可能完全测试一个程序
♦ （2）软件测试是基于风险的练习
♦ （3）测试不能证明错误不存在
♦ （4）发现的虫子越多，虫子越多
♦ （5）农药悖论
♦ （6）并非所有您发现的错误都会得到修复
♦ （7）当一个bug是bug很难说
♦ （8） 产品规格从来都不是最终的
♦ （9）软件测试人员不是项目团队中最受欢迎的成员
♦ （10）软件测试是一个有纪律的技术专业

Static and Dynamic Verification 静态和动态验证

• 静态验证不需要执行软件代码，而动态验证则需要。
• 静态验证（或静态分析）可以像让受过培训并有经验的人通读代码来搜索故障一样简单。
  • 它可以是一种形式化的方法，包括对规范和源代码之间的翻译进行符号验证
  • 它也可以采用一种数学方法，包括程序的符号执行
• 动态验证（或软件测试）通过执行程序来确认程序的运行
  • 创建测试用例，指导选择合适的测试数据（包括输入值和预期输出值）
  • 输入值在执行过程中作为程序的输入提供。从程序中收集实际输出，然后将其与预期输出进行比较

Black and White Box Testing

黑盒测试完全基于程序specification（规约，规约是对软件的组织或其组成部分的内部结构的描述，满足系统需求规约所指定的全部功能及性能要求）旨在验证程序是否符合规定要求。

白盒测试使用软件的实现来派生derive测试。这些测试旨在练习程序代码的某些方面

覆盖范围解释
黑盒测试提供了规范specification的覆盖范围，但不是实现的全部覆盖范围。也就是说，实现中可能存在生成规范中未说明的结果的代码。
白盒测试提供了实现implementation的覆盖范围，但没有提供规范的覆盖范围。也就是说，可能存在规范中所述的行为，而实现中没有针对这些行为的代码

黑盒测试的基本原理可以用多种不同的方式表达：
1。根据规范进行测试。
2.使用基于规范的测试覆盖范围标准
3.根据规范开发测试用例。
4.“实践”规范

白盒测试的基本原理可以表示为：
1。针对实现进行测试。
2、使用基于实施的测试覆盖率标准。
3、开发源自实现的测试用例。
4、“演习”实施

软件测试的原则

1.将程序测试完全很重要；
2.测试是基于风险的实践；
3.测试无法显示缺省的bug
4.bug越找越多；
5.不是所有bug被找到后都会被修复；
6.很难说bug什么时候是真的bug
7.规格说明书永远不是最终版
8测试工程师不是项目中最受欢迎的
9.软件测试是需要训练和技术的一个职业

测试与调试的区别

测试发展的初期，测试就是调试；而现在测试是一个系统化工程化的概念，有自己的生命周期，调试的
范畴更小一些
调试不属于测试，是编码阶段的工作，由程序员完成；而测试由测试员或程序员完成

测试管理体系

测试规划（确定目标和策略）_{>测试设计（确定测试方案及用例)·>测试实施（执行用例）}>配置管
理（测试配置管理）->资源管理（资源综合调配与管理）·>测试管理（对以上过程综合管理）

SQA（SoftwareQualityAssurance）

软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活
动

SQA与软件测试的关系

SQA是管理工作，审查对象是流程，强调以预防为主
测试是技术实施工作，测试对象是产品，主要是以事后检查（文档、程序）为主
SQA指导测试、监控测试，测试为SQA提供依据，是SQA的一个环节、一个手段

组建测试队伍

任务与责任
任务：测试计划、测试用例设计、执行测试、评估测试结果、递交测试报告
责任：尽早发现问题，督促尽早解决，帮助制定合理的开发计划，分析、总结、跟踪问题，提高程
序、文档的规范性、易读性、可维护性等
基本构成
测试组长：负责项目的管理、测试计划、任务安排等
环境配置人员：设置、配置和维护实验室的测试环境
测试设计人员/资深测试工程师：规格说明书、设计的审查，测试用例的设计，技术难题的解决，培训
和指导，实际测试任务的执行
一般（初级）测试工程师：执行测试用例和相关的测试任务

测试策略

测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成
测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等）和方法，以
确定合理的测试方案使得测试更有效

静态测试

静态测试：通过检查和评审软件而不是运行软件对软件进行测试的方法。
动态：在受控环境中对测试数据直接执行代码。
静态测试可以手工进行，也可以借助软件工具自动进行

静态测试技术（静态白盒测试）

因为这里都涉及代码，所以算静态白盒测试

静态白盒测试是在不执行的情况下仔细而有条理地审查软件设计、架构或代码是否存在错误的过程。

三步曲：

• 走查（Walk Through）
• 审查（ Review ）
• 评审（ Inspection ）

代码审查 Review

代码审查的四个步骤：

1.准备
组长提前把程序目录表和设计说明书等材料分配给小组成员
小组成员熟悉这些材料
由被测程序的设计和编码人员向审查组详细说明所准备的材料，特别是代码的主要功能与功能间的关系
2.程序阅读
审查组人员仔细阅读代码和相关材料
对照代码审查单标出明显缺陷及错误
3.审查会
审查会议由组长主持
首先由程序员逐句阐明程序的逻辑，在此过程中可由程序员或其他小组成员提出问题，追踪错误是否存在
经验证明在上述阐述过程中，有很多错误由讲述程序者而不是其他小组成员发现
大声地朗读程序给听众，这样简单的工作是有效的错误检测技术
然后利用代码审查单来分析讨论
组长负责讨论沿着建设性的方向前进，而其他人则集中注意力发现错误，但不去纠正错误
4.跟踪及报告
会后把发现的错误登记造表并交给程序开发人员
如果发现错误较多或发现重大错误，那么在改正之后，组长要再次组织审查会议
为了改进以后的审查工作，对错误登记表也要分析，归类和精炼

正式审查（formal review）有4个基本要素：
（1）确定问题：审查的目的是找出软件的问题——不仅是出错的项目，还包括遗漏的项目。
（2）遵守规则。该规则的重要性在于参与者了解自己的目标是什么。
（3）准备，根据审查的类型，参与者可能扮演不同的角色，他们需要了解自己的责任和义务，并积极参与审查。
（4）编写报告。审查小组必须做出审查结果的书面总结报告，并报告便于开发小组的成员使用。

代码走查 Walk Through

采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

代码走查组

组长、秘书、测试人员

代码走查会

⭐与代码审查不同，不是读程序和使用代码审查单，而是由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）

桌面检查

⭐程序员阅读自己所编的程序。这种方法效率不高，但可作为个人自我检查程序中明显的疏漏或笔误。

⭐代码审查和代码走查的优点

A.不仅比桌面检查优越得多，而且与动态测试的方法相比也有很多优点

a）使用这种方法测试，一旦发现错误，就知道错误的性质和位置，因而调试所花费的代价低

b）使用这种方法一次能揭示一批错误，而不是一次只揭示一个错误

B.如果使用动态测试，通常仅揭示错误的征兆

a）程序不终止运行，而对错误的性质和位置还得逐个查找

⭐技术评审 Inspection

综合运用走查和审查技术，逐页、逐节地检查软件开发前期需求分析和设计的文档，对软件的需求，设计结构等方面提出问题。技术评审属于广义的测试范畴，也是一种质量保证手段。

采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。

静态测试的内容（不考察）

需求定义的静态测试

对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确。
1.高级审查：测试需求定义的第一步是站在一个高度上进行审查，找出根本性的问题、疏忽或遗漏之处。
2.低层测试：高级审查之后可以很好地了解产品以及影响其设计的外部因素，然后就可以在更低的层次测试需求定义了。

🍎对照条例：完备性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、兼容性

评审案例：保险金问题（略）

设计文档的静态测试

对设计文档的静态测试着重于：

1.分析设计是否与需求定义一致

2.所采用的数值方法和算法是否适用于待解问题

3.程序的设计中对程序的划分是否与待解问题相适应

4.需求是否都被满足了

🍎对照条例：完备性、一致性、正确性、可行性、易修改性、模块性、可预测性、健壮性、结构化、易追溯性、易理解性、可验证性/易测试性

源代码的静态测试

对源代码的静态测试着重于分析实现是否正确、完备

🍎对照条例：完备性、一致性、正确性、易修改性、可预测性、健壮性、结构化、易追溯性、易理解性、可验证性