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

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.3 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 螺旋-决定对象-识别风险-评估-开发测试-准备下一迭代
  • 风险驱动的开发过程
  • 瀑布模型和快速原型迭代模型的组合
  • 以设计目标开始，以客户审查进度结束。

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

测试驱动开发 （TDD） 是一种软件设计方法，它植根于对生产代码的挑战，以在婴儿步骤中继续构建功能。
对于刚开始学习的人来说，这可能会违反直觉，但它提供了一些优势，包括更清洁的开发。
人们习惯了这种方法，使用这种方法也可以更快，具体取决于项目的性质。
程序员可以在测试驱动开发中使用各种编程语言，并可能将其应用于新软件、版本改进或现有程序的修复。

Software Testing Model 软件测试模型

V模型

V 模型是经典瀑布模型的增强版本，其中开发生命周期的每个级别在进入下一个级别之前都经过验证。
使用这种模型，软件测试明确地从一开始开始，即在编写需求后立即开始。

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

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）软件测试是一个有纪律的技术专业

SQA与软件测试的关系

SQA 是管理工作、审查对象是流程、强调以预防为主
测试是技术工作、测试对象是产品、主要是事后检查
SQA指导测试、监控测试
测试为SQA提供依据

Static and Dynamic Verification

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

Black and White Box Testing

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

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

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

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

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

软件测试的原则？？

黑盒测试

黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。

等价性划分、边值分析、组合测试、随机测试和误差猜测、场景测试

黑盒测试主要测试的错误类型有：
①不正确或遗漏的功能；
②接口、界面错误；
③性能错误；
④数据结构或外部数据访问错误；
⑤初始化或终止条件错误等等。

优点

（1）有针对性地寻找问题，并且定位问题更准确。
（2）黑盒测试可以证明产品是否达到用户要求的功能，符合用户的工作要求。
（3）黑盒测试与软件如何实现无关，如果实现发生变化，黑盒测试用例仍然可用（可重用性，面向回归测试）
（4）测试用例开发可以与软件开发同时进行，可节省软件开发时间，通过软件的用例就可以设计出大部分黑盒测试用例。
（5）能重复执行相同的动作，测试工作中最枯燥的部分可交由机器完成。

缺点：
（1）需要充分了解待测试软件产品所用到的各项技术，测试人员需要具有较多经验。
（2）测试用例数量较大
（3）测试用例可能产生很多冗余
（4）功能性测试的覆盖范围不可能达到100%
（5）在测试过程中很多是手工测试操作。
（6）测试人员要负责大量文档、报表的编制和整理工作。

黑盒测试的实施过程
（1）测试计划阶段
（2）测试设计阶段
　　 依据程序需求规格说明书或用户手册，按照一定规范化的方法进行软件功能划分和设计测试用例。
（3）测试执行阶段
　　按照设计的测试用例执行测试;
　　自由测试(作为测试用例测试的补充)。
（4）测试总结阶段

测试用例：
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

等价类划分法

等价类是指某个输入域的子集合。 在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。
并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。

有效等价类
是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。
利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类
与有效等价类的定义恰巧相反。
无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。
对于具体的问题，无效等价类至少应有一个，也可能有多个。

并是整个集合：完备性
子集互不相交：保证一种形式的无冗余性
同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到“相同的执行路径”

示例：
设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的“日期检查功能”。
1）划分等价类并编号

2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

3）为每一个无效等价类设计一个测试用例，设计结果如下：

边界值分析法

是对等价类划分的补充
边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况

边界值分析法用例设计原则：
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

3）将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
例如，某程序的规格说明要求计算出“每月保险金扣除额为0至1165.25元”，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。
再如一程序属于情报检索系统，要求每次”最少显示1条、最多显示4条情报摘要”，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
7）分析规格说明,找出其它可能的边界条件。

例题：
程序的输入文件由一些有80个字符的记录组成,如右图所示，所有记录分为3组：

① 标题：
这一组只有一个记录，其内容为输出成绩报告的名字。
②试卷各题标准答案记录：
每个记录均在第80个字符处标以数字“2”。该组的第一个记录的第1至第3个字符为题目编号（取值为1一999）。第10至第59个字符给出第1至第50题的答案（每个合法字符表示一个答案）。该组的第2，第3……个记录相应为第51至第100，第101至第150，…题的答案。
③每个学生的答卷描述：
该组中每个记录的第80个字符均为数字“3”。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号，第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50，则第2，第3……记录分别给出他的第51至第100，第101至第150……题的解答。然后是学生乙的答卷记录
学生人数不超过200，试题数不超过999
程序的输出有4个报告：
a)按学号排列的成绩单，列出每个学生的成绩、名次。
b)按学生成绩排序的成绩单。
c)平均分数及标准偏差的报告。
d)试题分析报告。按试题号排序，列出各题学生答对的百分比。
解答：分别考虑输入条件和输出条件，以及边界条件。给出下表所示的输入条件及相应的测试用例。

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。比如输入数据为0

例如，针对例3，采用错误推测法还可补充设计一些测试用例：
1、 程序是否把空格作为回答
2、 在回答记录中混有标准答案记录
3、 除了标题记录外，还有一些的记录最后一个字符即不是2也不是3
4、 有两个学生的学号相同
5、试题数是负数。

再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：
1）输入的线性表为空表；
2）表中只含有一个元素；
3）输入表中所有元素已排好序；
4）输入表已按逆序排好；
5）输入表中部分或全部元素相同。

因果图

• 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等。
• 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（ Cause一Effect Graphics ）方法。
• 采用因果图方法能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。

左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
Ci表示原因，通常置于图的左部； ei表示结果，通常在图的右部。 ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现

关系
①恒等：若ci是1，则ei也是1；否则ei为0。
②非：若ci是1，则ei是0；否则ei是1。
③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。
④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

例子：
原因：
1.售货机有零钱找 2.投入1元硬币
3.投入5角硬币 4.押下橙汁按钮
5.押下啤酒按钮
结果：
21. 售货机〖零钱找完〗灯亮
22. 退还1元硬币
23. 退还5角硬币
24. 送出橙汁饮料
25. 送出啤酒饮料

因果图方法是一个非常有效的黑盒测试方法，它能够生成没有重复性的且发现错误能力强的测试用例，而且对输入、输出同时进行了分析。
从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加。
如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图，而是可以直接利用判定表设计测试用例了。

判定表

判定表通常由四个部分组成：
条件桩（Condition Stub）:列出了问题的所有条件，通常认为列出得条件的次序无关紧要。
动作桩（Action Stub）:列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
条件项（Condition Entry）:列出针对它左列条件的取值，在所有可能情况下的真假值。
动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作。

例子：
问题要求：”…… 对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……” 。 这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。 请建立判定表。
①确定规则的个数：这里有3个条件，每个条件有两个取值，故应有222=8种规则。
②列出所有的条件茬和动作茬：
③填入条件项。可从最后1行条件项开始，逐行向上填满。如第三行是： Y N Y N Y N Y N第二行是： Y Y N N Y Y N N等等。
④填人动作桩和动作顶。这样便得到形如图的初始判定表。

⑤化简。合并相似规则后得到图

白盒测试

白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。
白盒测试使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序进行测试。

基本要求：
保证一个模块中的所有独立路径至少被执行一次；
对所有的逻辑值均需要测试真、假两个分支；
在上下边界及可操作范围内运行所有循环；
检查内部数据结构以确保其有效性。

应用白盒法时，手头必须有程序的规格说明以及程序清单。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。
最彻底的白盒法是覆盖程序中的每一条路径，但是由于程序中一般含有循环，所以路径的数目极大，要执行每一条路径是不可能的，只能希望覆盖的程度尽可能高些。

覆盖程度从低到高：

语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。
判定覆盖（也称为分支覆盖）：执行足够的测试用例，使得程序中的每一个分支至少都通过一次（仅要求取到每一个结果）。
条件覆盖：执行足够的测试用例，使程序中每个判断的每个条件的每个可能取值至少执行一次；
判定/条件覆盖：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果（所有结果被取过）。
条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。
基本路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。

例子：

语句覆盖：x=4、y=5、z=5 程序执行的路径是：abd
分支覆盖：①x=4，z=0，y=6 (沿路径acd执行)；
② x=5，z=5，y=2(沿路径abe执行)
条件覆盖：
对于第一个判断：
条件x>3 取真值为T1，取假值为-T1
条件z<10 取真值为T2，取假值为-T2
对于第二个判断：
条件x=4 取真值为T3，取假值为-T3
条件y>5 取真值为T4，取假值为-T4

注意“条件覆盖”并不包含“分支覆盖”，

而“分支 ／条件覆盖”，它的含义是：执行足够的测试用例，使得分支中每个条件取到各种可能的值，并使每个分支取到各种可能的结果。它才是包含前两者的覆盖

条件组合覆盖：
1、x>3,z<10 记做T1 T2，第一个判断的取真分支
2、x>3,z>=10 记做T1 -T2，第一个判断的取假分支
3、x<=3,z<10 记做-T1 T2，第一个判断的取假分支
4、x<=3,z>=10 记做-T1 -T2，第一个判断的取假分支
5、x=4,y>5 记做T3 T4，第二个判断的取真分支
6、x=4,y<=5 记做T3 -T4，第二个判断的取真分支
7、x!=4,y>5 记做-T3 T4，第二个判断的取真分支
8、x!=4,y<=5 记做-T3 -T4，第二个判断的取假分支

根据定义取4个测试用例，就可以覆盖上面8种条件取值的组合。上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe（路径组合可能丢失）

基本路径覆盖

步骤：
程序的控制流图：描述程序控制流的一种图示方法
程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数。
导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
准备测试用例：确保基本路径集中的每一条路径的执行

程序流程图简化成控制流图

在将程序流程图简化成控制流图时，应注意：
在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。
边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目。

有以下三种方法计算圈复杂度：

• 流图中区域的数量对应于环型的复杂性；
• 给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；
• 给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。

对应上面图中的圈复杂度，计算如下：
流图中有四个区域；
V(G)=10条边-8结点+2=4;
V(G)=3个判定结点+1=4。

导出测试用例

第三步：导出测试用例
根据上面的计算方法，可得出四个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。)
路径1：4-14
路径2：4-6-7-14
路径3：4-6-8-10-13-4-14
路径4：4-6-8-11-13-4-14
根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。

准备测试用例

路径1：4-14
输入数据：iRecordNum＝0，或者
取iRecordNum<0的某一个值
预期结果：x＝0
路径2：4-6-7-14
输入数据：iRecordNum＝1,iType＝0
预期结果：x＝2
路径3：4-6-8-10-13-4-14
输入数据：iRecordNum＝1,iType＝1
预期结果：x＝10
路径4：4-6-8-11-13-4-14
输入数据：iRecordNum＝1,iType＝2
预期结果：x＝20

void  Sort(int iRecordNum,int iType)
 {  
   int x=0;
   int y=0;
   while (iRecordNum-- > 0)
   {
	   if(0==iType)
              {x=y+2; break;}
        else
	     if(1= =iType)
  		x=y+10;
           else
        	x=y+20;
    }
 }

黑白盒测试结合的例子（待补充）

静态测试

静态测试：通过检查和评审软件而不是运行软件对软件进行测试的方法。
静态测试可以手工进行，也可以借助软件工具自动进行

静态测试技术

代码审查

代码审查的四个步骤：

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

代码走查

代码走查与代码审查相似，它也是由一组程序和错误检查技术组成，只是程序和错误检查技术不完全相同。

代码走查组

组长、秘书、测试人员

代码走查会

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

桌面检查

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

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

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

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

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

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

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

⭐技术评审

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

静态测试的内容

需求定义的静态测试

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

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

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

设计文档的静态测试

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

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

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

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

4.需求是否都被满足了

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

源代码的静态测试

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

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