太原理工大学软件测试大题

软测大题

从最不正式到最正式评审方法各有那些，并且简述每个方法

软件测试按照不同的划分方法，有不同的分类，请描述3种

（1）按照软件测试用例的设计方法而论,软件测试可以分为白盒测试法和_黑盒测试法

（2）从是否执行程序的角度，软件测试可以分为静态测试和动态测试

（3）按照软件测试的策略和过程来分类，软件测试可分为单元测试、集成测试、系统测试，验收测试

自动化测试对于手工测试的优点？自动化测试工具

• 自动运行速度快是手工无法相比的

• 显著降低重复手工测试的时间

• 建立可靠、重复的测试，减少人为错误

• 增强测试质量和覆盖率

• 测试结果准确

• 高复用性

• 永不疲劳

• 可靠

Selenium，Appium，JMeter，Postman

软件缺陷严重性划分几个等级，缺陷优先级划分几个等级，两者之间的关系

0级：致命         立即解决 P1级

1级：严重         高优先级  P2级

2级：一般        正常排队 P3级

3级：较小        低优先级 P4级

严重性：缺陷对软件产品使用的影响程度

优先级：缺陷必须被修复的紧急程度

缺陷严重等级和缺陷优先级相关性很强，缺陷越严重，越要优先得到修正。

什么是软件缺陷

对于软件缺陷的精确定义，通常有下列5条描述：

软件未达到（实现）产品说明书（要求）的功能。

软件出现了产品说明书指明不会出现的错误。

软件功能超出产品说明书指明范围。

软件未达到产品说明书虽未指出但应达到的目标。

软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

软件缺陷的定义

软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求

软件缺陷的主要类型/现象：

 功能、特性没有实现或部分实现

 设计不合理，存在缺陷

 实际结果和预期结果不一致

 运行出错，包括运行中断、系统崩溃、界面混乱

 数据结果不正确、精度不够

 用户不能接受的其他问题，如存取时间过长、界面不美观

验证和确认（V & V）

V（验证）

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

V（有效性确认）

确认所开发的软件能满足用户真正需求的活动

软件测试可以分为静态测试和动态测试，静态测试分为需求评审，代码评审，设计评审

需求评审：检查软件产品的需求定义和用户实际需求是否一致，即需求文档（包括use case，use story）是否客观、准确、清晰低描述了业务需求、用户需求等。

设计评审：检查软件系统的设计（如设计文档）与实现定义的需求是否一致，检查系统是否满足系统功能和非功能性需求，检查系统设计是否合理。

代码评审：检查代码的逻辑运算、算法和其他处理是否正确，还要检查代码是否符合编程规范，包括变量命名、格式、注释等。

瀑布模型

软件开发的基本过程可以分为需求分析、设计、编码、测试和维护阶段，即通常所说的“传统生命周期”，也就是“瀑布模型

优点：

为项目提供了按阶段划分的检查点

当前一阶段完成后，只需要去关注后续阶段

存在的问题：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量

线性开发，用户、测试人员等到整个过程的末期才能看到开发成果，从而增大了开发风险

瀑布模型不适应用户的需求变化

V模型

揭示了开发过程与测试过程中各个阶段的对应关系

单元测试对于详细设计

概要设计对应集成测试

需求分析与系统对应系统测试

用户需求对应验收测试

特点：

1.明确地定义了测试的不同级别

2.描述了测试阶段和开发阶段的对应关系

3.测试包含了底层测试到高层测试

缺点：

1.容易使人理解为测试是软件开发的最后一个阶段

2.不能体现“测试应尽早地和不断地进行软件测试”原则

3.测试倒置，需求问题后移

W模型

由两个V模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系

优点：

测试伴随着整个开发周期，同步进行；

更早的介入测试，可以发现初期的缺陷，修复成本低；

测试对象不仅仅是程序，需求和设计同样要测试。

缺点：

开发和测试依然是线性的关系，需求的变更和调整，依然不方便，无法支持灵活的迭代

如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高

敏捷开发模型

在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试依赖于自动化测试。

Product Backlog(需求定义阶段)

Sprint 迭代

SPringl Backlog 阶段性任务安排

设计审查

软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量

体系结构。将软件需求转化为数据结构和软件的系统结构，并定义子系统（组件）和他们之间的通信或接口

详细设计。进一步分为功能详细设计、组件设计、数据库设计、用户界面（UI）设计等

什么是软件评审

软件评审是对软件元素或者项目状态进行评估的一种手段，以确定其是否与计划的结果保持一致，并使其得到改进

技术评审是对产品以及各阶段的输出内容（阶段性成果、半成品）进行技术性评估，焦点在技术实现上。

文档评审是对软件过程中所存在的各类文档的格式、内容等进行评审

什么是测试用例

测试用例（test case）是为了特定测试目的而设计的测试条件、测试数据及与之相关的操作过程序列的一个特定的使用实例或场景。测试用例是可以被独立执行的一个过程，是一个最小的测试实体，不能再被分解

测试用例的三要素

操作步骤、测试数据和预期结果

为什么需要测试用例

• 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，是软件公司探索和追求的目标。

• 测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。

• 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例

• 根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪

测试用例的作用

整体测试用例的质量要求

覆盖率，易用性，易维护性，粒度适中

测试集

测试集是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来

按程序功能模块组织

按测试用例的类型组织

按测试用例的优先级组织

自动化测试的优点

1. 自动运行的速度快，是手工无法相比的。

1. 测试结果准确。

1. 高复用性。

1. 永不疲劳。

1. 可靠。

1. 独特的能力。

测试自动化能：

• 显著降低重复手工测试的时间

• 建立可靠、重复的测试，减少人为错误

• 增强测试质量和覆盖率

 测试自动化不能：

• 完全代替手工测试和手工测试工程师

• 保证100%的测试覆盖率

• 弥补测试实践的不足

测试自动化存在 问题

不正确的观念或不现实的期望

 缺乏具有良好素质、经验的测试人才

 测试工具本身的问题影响测试的质量

 测试脚本的质量低劣

 没有进行有效的、充分的培训

 没有考虑到公司的实际情况，盲目引入测试工具

 没有形成一个良好的使用测试工具的环境

 其它问题

集成测试

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，也常被称为大棒模式。

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

非功能性测试

Java