山东大学软件质量保证与测试技术复习纲要

Posted 2020-07-31 dkbnull

软件质量保证与测试技术复习提纲

1.3 

1.5

 

2.1

2.3

2.5

2.6

 

3.3（3.3.1    扩展）

3.4

3.7.3  FSM   状态图 状态表

 

5.1

5.7.1

5.7.2

 

8.1.1

8.1.5

 

9.1

9.6

3.3.1    扩展

某研究所重新对其在大学以上学历的职工安排工作。其方针如下："如果年龄不满18岁，文化程度是大学，若是男性，则一律要求考研究生。若是女性，则分配到研究所办公室任行政干部；如果年龄满18岁但不足50岁，文化程度是研究生，不分男女性，均任课题组长。文化程度是大学，则不分男女性均担任中层以上各级领导干部；如果年龄满50岁以上，文化程度是研究生，若是男性，则任课题组长。文化程度是大学，若是男性，则任科研人员。若是女性，则任资料员"。 

⑴ 判定表的绘制。 

① 提取问题中的条件："性别"、"年龄"和"文化程度"三个条件。 

② 标出每个条件的取值（为了便于绘制判定表，用符号来代替条件的取值）： 见下表一：

 

⑥ 检查判定表的完善性：如果任意绘制的判定表很可能是不完善的，也可能存在以下问题： 

Ⅰ 遗失判定列：即判定表中缺少判定条件组合列。在表二中就缺少了两个判定列。所谓判定列是指判定表右部的各列（包括上下两部分构成的列）。 

完善的判定表要满足以下条件： 

A.判定列计数之和必须等于诸条件取值数之积。 

也就是在判定表中右下部分选定的动作列中目标动作的数量应等于所有条件的组合数。 B.每个判定列必须是独立的，即任何两个判定列的诸条件中至少有一个条件的取值是不同。

 

 

假设某程序有三个输入变量year 、month、day（month、day和year均为整数值，并且满足：1≤month≤12、1≤day≤31和1981≤year≤2050），分别作为输入日期的年份、月份、日，通过程序可以输出该输入日期在日历上隔一天的日期。试用判定表法设计该程序正确输入条件下的测试用例。

　　设计:

　　一、确定规则，建立条件桩和动作桩

M1＝{月份：每月有30天}

M2＝{月份：每月有31天， 12月除外}

M3＝{月份：12月}

M4＝{月份：2月}

D1＝{日期：1<=日期<=26}

D2＝{日期：27}

D3＝{日期：28}

D4＝{日期：29}

D5＝{日期：30}

D6＝{日期：31}

Y1 ＝{年：年是闰年}

Y2 ＝{年：年不是闰年}

二、判定表

三、测试用例：

用例ID	用例标题	前置条件	输入	输出
1	Day+2(30)		1.月输入1 2.日输入26 3.年输入2010	2010.1.28
2	Day=1&month+1(30)		1.月输入3 2.日输入29 3.年输入2010	2010.4.1
3	Day=2&month+1(30)		1.月输入5 2.日输入30 3.年输入2010	2010.6.2
4	Day+2(31)		1.月输入4 2.日输入25 3.年输入2010	2010.4.27
5	Day=1&month+1(31)		1.月输入11 2.日输入30 3.年输入2010	2010.12.1
6	Day=2&month+1(31)		1.月输入11 2.日输入31 3.年输入2010	2010.12.2
7	Day+2（12月）		1.月输入12 2.日输入23 3.年输入2010	2010.12.25
8	Day=1&month+1&year+1（12月）		1.月输入12 2.日输入30 3.年输入2010	2011.1.1
9	Day=2&month+1&year+1（12月）		1.月输入12 2.日输入31 3.年输入2010	2010.1.2
10	Day+2（2月）		1.月输入2 2.日输入19 3.年输入2010	2010.2.21
11	Day+2（闰年2月）		1.月输入2 2.日输入27 3.年输入2000	2000.2.29
12	Day=1&month+1（闰年2月）		1.月输入2 2.日输入28 3.年输入2000	2000.3.1
13	Day=2&month+1（闰年2月）		1.月输入2 2.日输入29 3.年输入2000	2000.3.2
14	Day=2&month+1（平年2月）		1.月输入2 2.日输入27 3.年输入2001	2001.3.2
15	Day=1&month+1（平年2月）		1.月输入2 2.日输入26 3.年输入2001	2001.3.1

 

 

 

 3．假设某程序有三个输入变量year、month、day（month、day和year均为整数值，并且满足：1≤month≤12、1≤day≤31和1981≤year≤2050），分别作为输入日期的年份、月份、日，通过程序可以输出该输入日期在日历中下一天（明天）的日期。试用判定表法设计该程序正确输入条件下的测试用例。

第一章      引论

1.3 什么是软件测试

（正向思维）

□软件测试就是为程序能够按预期设想那样运行而建立足够的信心。

□软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果”

□测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作。

（反向思维）

□测试是为了证明程序有错，而不是证明程序无错误

□一个好的测试用例是在于它能发现至今未发现的错误

□一个成功的测试是发现了至今未发现的错误的测试

软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体

◎“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性

◎“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。

1.5测试和质量保证的关系

软件质量保证（Software Quality Assurance，SQA）是软件工程领域中的一部分，为了确保软件开发过程和结果符合预期的要求，而建立的一系列规程和计划，以及依照规程和计划采取的一系列活动及其结果评价

·软件开发过程是按照计划和规范实施的

·软件开发结果包括完整的软件和文档，并且符合可预期的目标和检验标准

SQA与软件测试之间相辅相成，既存有包含又存有交叉的关系。SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。而软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。

他们的相同点在于二者都是贯穿整个软件开发生命周期的流程。他们的不同之处在于，SQA是一项管理工作，侧重于对流程的评审和监控，而测试是一项技术性的工作，侧重于对产品进行评估和验证。

 

2.1软件缺陷

  2.1.1 软件质量的内涵

      IEEE： 质量是系统、部件或过程满足　

1、明确需求

2、客户或用户需要或期望的不同程度

软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492)　

软件质量：软件产品满足使用要求的程度

2.1.2 软件缺陷的定义

软件缺陷一个标准的定义：

 ◎从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；

 ◎从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

2.1.3 软件缺陷的产生

①技术问题

算法错误，语法错误，计算和精度问题，接口参数传递不匹配

②团队工作

沟通不充分，误解

③软件本身

◎文档错误、用户使用场合(user scenario)，

◎时间上不协调、或不一致性所带来的问题

◎系统的自我恢复或数据的异地备份、灾难性恢复等问题

2.1.4 软件缺陷的构成

2.1.5 修复软件缺陷的代价

平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3~6倍，在编程阶段是它的10倍，在内部测试阶段是它的20~40倍，在外部测试阶段是它的30~70倍，到了产品发布出去时，这个数字就是40~100倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。

 

2.3 静态测试和动态测试

p将需求和设计的评审纳入测试的范畴，可看作是广义测试

p静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等

p静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析

p动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。

2.3.1产品评审

p评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。

p通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。

评审的形式/方法：互为评审、轮查、走查、会议评审。

评审分类：管理评审、技术评审、文档评审、流程评审

2.3.2静态分析

p人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。

p计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

 

2.3.3验证和确认

Verification：Are we building the product right？

p是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性

Validation： Are we buildingthe right product?

p是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求

 

2.5 黑盒测试方法和白盒测试

2.6 软件测试级别

1.单元测试：

p 单元测试针对程序系统中的最小单元---模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。通常要编写驱动模块和桩模块

p 单元测试一般由编程人员和测试人员共同完成，而以开发人员为主

p 单元测试包括代码评审，代码评审可以发现程序50%～70%代码的缺陷。

2.集成测试：

集成测试，也称组装测试、联合测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题。两种集成方式：一次性集成方式和增殖式集成方式

3.系统测试

功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。

系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括：恢复测试、安全测试、强度测试、性能测试……

4.验收测试：

p 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样

p 安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试

 

3.3  3.3.1 判定表方法

扩展

某研究所重新对其在大学以上学历的职工安排工作。其方针如下："如果年龄不满18岁，文化程度是大学，若是男性，则一律要求考研究生。若是女性，则分配到研究所办公室任行政干部；如果年龄满18岁但不足50岁，文化程度是研究生，不分男女性，均任课题组长。文化程度是大学，则不分男女性均担任中层以上各级领导干部；如果年龄满50岁以上，文化程度是研究生，若是男性，则任课题组长。文化程度是大学，若是男性，则任科研人员。若是女性，则任资料员"。 

⑴  判定表的绘制。

①提取问题中的条件："性别"、"年龄"和"文化程度"三个条件。 

② 标出每个条件的取值（为了便于绘制判定表，用符号来代替条件的取值）： 见下表一：

⑥ 检查判定表的完善性：如果任意绘制的判定表很可能是不完善的，也可能存在以下问题： 

Ⅰ 遗失判定列：即判定表中缺少判定条件组合列。在表二中就缺少了两个判定列。所谓判定列是指判定表右部的各列（包括上下两部分构成的列）。 

完善的判定表要满足以下条件： 

A.判定列计数之和必须等于诸条件取值数之积。 

也就是在判定表中右下部分选定的动作列中目标动作的数量应等于所有条件的组合数。

 B.每个判定列必须是独立的，即任何两个判定列的诸条件中至少有一个条件的取值是不同。

 

假设某程序有三个输入变量year 、month、day（month、day和year均为整数值，并且满足：1≤month≤12、1≤day≤31和1981≤year≤2050），分别作为输入日期的年份、月份、日，通过程序可以输出该输入日期在日历上隔一天的日期。试用判定表法设计该程序正确输入条件下的测试用例。

　　设计:

　　一、确定规则，建立条件桩和动作桩

M1＝{月份：每月有30天}M2＝{月份：每月有31天， 12月除外}

M3＝{月份：12月}M4＝{月份：2月}D1＝{日期：1<=日期<=26}

D2＝{日期：27}D3＝{日期：28}D4＝{日期：29}D5＝{日期：30}

D6＝{日期：31}Y1 ＝{年：年是闰年}Y2 ＝{年：年不是闰年}

二、判定表

三、测试用例：

用例ID	用例标题	前置条件	输入	输出
1	Day+2(30)		1.月输入1 2.日输入26 3.年输入2010	2010.1.28
2	Day=1&month+1(30)		1.月输入3 2.日输入29 3.年输入2010	2010.4.1
3	Day=2&month+1(30)		1.月输入5 2.日输入30 3.年输入2010	2010.6.2
4	Day+2(31)		1.月输入4 2.日输入25 3.年输入2010	2010.4.27
5	Day=1&month+1(31)		1.月输入11 2.日输入30 3.年输入2010	2010.12.1
6	Day=2&month+1(31)		1.月输入11 2.日输入31 3.年输入2010	2010.12.2
7	Day+2（12月）		1.月输入12 2.日输入23 3.年输入2010	2010.12.25
8	Day=1&month+1&year+1（12月）		1.月输入12 2.日输入30 3.年输入2010	2011.1.1
9	Day=2&month+1&year+1（12月）		1.月输入12 2.日输入31 3.年输入2010	2010.1.2
10	Day+2（2月）		1.月输入2 2.日输入19 3.年输入2010	2010.2.21
11	Day+2（闰年2月）		1.月输入2 2.日输入27 3.年输入2000	2000.2.29
12	Day=1&month+1（闰年2月）		1.月输入2 2.日输入28 3.年输入2000	2000.3.1
13	Day=2&month+1（闰年2月）		1.月输入2 2.日输入29 3.年输入2000	2000.3.2
14	Day=2&month+1（平年2月）		1.月输入2 2.日输入27 3.年输入2001	2001.3.2
15	Day=1&month+1（平年2月）		1.月输入2 2.日输入26 3.年输入2001	2001.3.1

 

 3.假设某程序有三个输入变量year 、month、day（month、day和year均为整数值，并且满足：1≤month≤12、1≤day≤31和1981≤year≤2050），分别作为输入日期的年份、月份、日，通过程序可以输出该输入日期在日历中下一天（明天）的日期。试用判定表法设计该程序正确输入条件下的测试用例。

 

3.4 基于逻辑覆盖的方法（必考,例子见书P49）

3.4.1判定覆盖

 设计若干用例,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足

3.4.2条件覆盖

设计若干测试用例,执行被测程序后,每个判断中每个条件的可能取值至少满足一次.

3.4.3判定条件覆盖

判断条件中所有条件的取值至少执行一次,同时所有判断的可能结果至少执行一次

3.4.4条件组合覆盖

判断中每个条件所有的组合可能至少出现一次,并且每个判断本身的判定结果也至少出现一次

显然满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。

3.4.5基本路径覆盖

设计所有的测试用例，来覆盖程序中所有可能的、独立的执行路径。

 

5.1单元测试的目标和任务
定义

    单元测试是对软件基本的组成单元进行独立的测试

时机

   单元测试一般由开发人员完成,QA人员辅助.

概念

模块、组件、单元

测试人员：程序人员和开发人员

测试方法：

  检查每一条独立执行路径的测试。保证每条语句被至少执行一次；

  检查局部数据结构完整性

  检查模块接口是否正确

  检查临界数据处理的正确性

  预见、预设的各种出错处理是否正确有效

测试依据：详细