软件测试复习题
Joker2Yue判断题
语句 | 答案 |
---|---|
软件测试的目的是尽可能多的找出软件的缺陷。 | ✔️ |
Beta测试是验收测试的一种。 | ✔️ |
验收测试是由最终用户来实施的。 | ❌ |
项目立项前测试人员不需要提交任何工件。 | ✔️ |
单元测试能发现约80%的软件缺陷。 | ✔️ |
代码评审是检查源代码是否达到模块设计的要求。 | ❌ |
自底向上集成需要测试员编写驱动程序。 | ✔️ |
负载测试是验证要检验的系统的能力最高能达到什么程度。 | ❌ |
选择题
-
软件验收测试的合格通过准则是:
- 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。
- 所有测试项没有残余一级、二级和三级错误。立项审批表、需求分析文档、设计文档和编码实现一致。
- 验收测试工件齐全。
-
软件测试计划评审会需要哪些人员参加?
- 项目经理、SQA负责人、配置负责人、测试组。
-
下列关于alpha测试的描述中正确的是:
- alpha测试需要用户代表参加,alpha测试是验收测试的一种。
-
测试设计员的职责包括:
- 设计测试用例、过程、脚本。
填空题
-
软件验收测试包括正式验收测试、alpha测试、beta测试。
-
系统测试的策略有功能测试、性能测试、可靠性测试、负载测试、易用性测试、强度测试、安全测试、配置测试、安装测试、卸载测试、文档测试、故障恢复测试、界面测试、容量测试、兼容性测试、分布测试、可用性测试。
-
设计系统测试计划需要参考的项目文档有软件测试计划、软件需求文档和迭代计划。
-
面向过程的系统采用的集成策略有自顶向下和自底向上两种。
问答题
区别阶段评审的与同行评审
同行评审 | 阶段评审 | |
---|---|---|
目的 | 发现小规模工作产品的错误,主要是找错误 | 评审模块阶段作品的正确性、可行性及完整性 |
人数 | 3-7人,人员必须经过同行评审会议的培训,由SQA指导 | 5人左右,评审人必须是专家具有系统评审资格 |
内容 | 内容小,一般文档<40页,代码<500行 | 内容多,主要看重点 |
时间 | 一小部分工作产品完成 | 通常设置在关键路径的时间点上 |
简述系统集成测试过程
-
构建的确认过程。
-
补丁的确认过程。
-
系统集成测试组提交过程。
-
测试用例设计过程。
-
测试代码编写过程。
-
Bug的报告过程。
-
每周/每两周的构建过程。
-
点对点的测试过程。
-
组内培训过程。
软件测试的八个基本原则
-
所有的软件测试都应追溯到用户需求。
-
尽早和不断地进行软件测试。
-
在设计测试用例时,应该包括合理的输入与不合理的输入以及相应的预期输出结果。
-
充分注意测试中的群集现象。
-
程序员应避免检查自己的程序。
-
尽量避免测试的随意性。
-
应当对每个测试结果做全面的检查。
-
保留测试文档,包括测试计划、用例、出错统计和最终分析报告。
怎么做好文档测试
-
检查文档的编写是否满足文档编写的目的。
-
内容是否齐全、正确。
-
内容是否完善。
-
标记是否正确。
白盒测试有几种方法
方法 | 描述 |
---|---|
静态方法 | 关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。 |
动态方法 | 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。 |
Alpha测试与Beta的区别
测试类型 | 描述 |
---|---|
Alpha测试 | 在系统开发接近完成时对应用系统的测试,测试后仍然会有少量的设计变更。一般由最终用户或其他人员完成,不能由程序或测试员完成。 |
Beta测试 | 当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。一般由最终用户或其他人员完成,不能由程序员或测试员完成。 |
比较负载测试、容量测试和强度测试的区别
测试类型 | 描述 |
---|---|
负载测试 | 测试在一定的工作负荷下,系统的负载和响应时间。 |
强度测试 | 在一定的负荷条件下,系统在较长时间跨度内连续运行,检测系统性能的影响。 |
容量测试 | 容量测试旨在确定系统在给定条件下的极限性能,并识别系统在特定数据容量下的极限值。容量测试不仅关注系统的承受能力,还考虑系统在处理大量数据时的表现和稳定性,以确保系统在特定负载条件下能够正常运行而不发生故障。 |
描述软件测试活动的生命周期
-
计划:对整个测试周期中所有活动进行规划,包括估计工作量、风险评估、安排人力物力资源、安排进度等。
-
设计:完成测试方案,从技术层面上对测试进行规划,包括测试用例和测试规程的设计。
-
实现:编写测试用例和测试规程。
-
执行:根据前期完成的计划、方案、用例、规程等文档执行测试用例。
-
总结:记录测试结果,进行测试分析,并完成测试报告。
软件的缺陷等级应如何划分
缺陷等级 | 描述 |
---|---|
A类 | 严重错误,包括:由于程序引起的死机、非法退出;死循环;数据库发生死锁;因错误操作导致的程序中断;功能错误;与数据库连接错误;数据通讯错误。 |
B类 | 较严重错误,包括:程序错误;程序接口错误;数据库的表、业务规则、缺省值未加完整性等约束条件。 |
C类 | 一般性错误,包括:操作界面错误(包括数据窗口内列名定义、含义是否一致);打印内容、格式错误;简单的输入限制未放在前台进行控制;删除操作未给出提示;数据库表中有过多的空字段。 |
D类 | 较小错误,包括:界面不规范;辅助说明描述不清楚;输入输出不规范;长操作未给用户提示;提示窗口文字未采用行业术语;可输入区域和只读区域没有明显的区分标志。 |
E类 | 测试建议 |
您认为做好测试用例设计工作的关键是什么
-
白盒测试用例设计:以较少的测试用例覆盖尽可能多的内部程序逻辑结果。
-
黑盒测试用例设计:以较少的测试用例覆盖模块的输出和输入接口。不能完全测试,但要在合理的时间内发现尽可能多的问题。
黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点
方法 | 优点 | 缺点 |
---|---|---|
黑盒测试 | 1. 比较简单,不需要了解程序内部的代码及实现; | 1. 不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的30%; |
2. 与软件的内部实现无关; | 2. 自动化测试的复用性较低。 | |
3. 从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题; | ||
4. 基于软件开发文档,所以也能知道软件实现了文档中的哪些功能; | ||
5. 在做软件自动化测试时较为方便。 | ||
白盒测试 | 帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。 | 1. 程序运行会有很多不同的路径,不可能测试所有的运行路径; |
2. 测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求; | ||
3. 系统庞大时,测试开销会非常大。 |
针对以下问题采用等价类划分的方法设计测试用例。
问题: 某一种8位计算机,其十六进制常数的定义是以0x或0X开头的十六进制整数,其取值范围为-7f~7f(不区分大小写字母),如0x13、0x6A、0x3c。
等价类表:
-
有效等价类由 0x 或 0X 开头;
-
以字母开头;
-
以非 0 数字开头;
-
数值字符为数字或 A-F;
-
字符为 A-F 以外的字母;
-
字母或数值字符个数大于等于 1 个;
-
字母或数值字符个数为 0 个;
-
数值大于等于 -7F 且小于等于 7F;
-
数值小于 7F;
-
数值大于 7F。
用例 | 值 | 覆盖的等价类 |
---|---|---|
用例1 | 0x7F | 1, 4, 6, 8 |
用例2 | -0Xb | 1, 4, 6, 8 |
用例3 | 0X0 | 1, 4, 6, 8 |
用例4 | 0x | 1, 7 |
用例5 | A7 | 2 |
用例6 | -1A | 3 |
用例7 | 0X8h | 1, 5 |
用例8 | 0x80 | 1, 4, 10 |
用例9 | -0XaB | 1, 4, 9 |
请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
测试类型 | 关注点 | 执行者 | 目的 |
---|---|---|---|
黑盒测试 | 软件外部功能和接口 | 发现功能缺陷、接口问题等 | |
白盒测试 | 软件内部逻辑结构和代码实现 | 发现代码缺陷、算法错误等 | |
单元测试 | 最小可测试单元(如函数或模块) | 开发人员 | 确保单元功能正确 |
集成测试 | 模块集成 | 开发或测试人员 | 发现集成缺陷 |
系统测试 | 整个系统 | 独立测试人员 | 评估系统质量 |
验收测试 | 最终用户 | 最终用户 | 确认系统可交付使用 |
联系:
-
这些测试方法相互关联、循序渐进,测试范围和层次逐步扩大。
-
单元测试、集成测试、系统测试、验收测试反映了软件测试由小到大、由内到外的层次关系。
-
它们的目的不同但相辅相成,共同确保软件整体质量。
-
测试方法有所区别,单元测试多采用白盒,其他结合白盒和黑盒。
-
构成完整的软件测试过程,相互衔接,确保软件符合需求、设计和质量要求。
概括测试用例的基本要素
软件测试用例的基本要素包括测试用例编号、测试标题、测试模块、重要级别、测试环境、测试输入、操作步骤、预期结果。
概要 | 描述 |
---|---|
用例编号 | 测试用例的编号有一定的规则。 |
测试标题 | 对测试用例的描述,清晰表达测试用例的用途。 |
测试模块 | 指明并简单描述本测试用例是用来测试哪些项目、子项目或软件特性的。 |
重要级别 | 定义测试用例的优先级别,可分为“高”和“低”。 |
测试环境 | 描述执行测试用例所需的具体测试环境,包括硬件和软件环境。 |
测试输入 | 提供测试执行中的各种输入条件。 |
操作步骤 | 提供测试执行过程的步骤。 |
预期结果 | 提供测试执行的预期结果,根据软件需求中的输出得出。 |
测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
目的:是指导测试过程,确保测试任务的顺利实施。
内容:包括产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流和风险分析等。
重要:其中,最重要的是测试策略和测试方法。测试计划在宏观上规划测试活动的范围、方法和资源配置;而测试详细规格和测试用例则是具体的战术执行。
如何通过评审和更新机制来确保测试计划满足实际需求?
通过评审和更新机制,可以确保测试计划满足实际需求。如果测试计划未经过评审直接发送给测试团队,可能导致测试内容的不准确或遗漏,或者在软件需求变更后未及时更新测试计划内容,误导测试执行人员。
因此,应该分别创建测试计划、测试详细规格和测试用例。测试计划主要是宏观规划测试活动的范围、方法和资源配置,而测试详细规格和测试用例则是具体执行测试任务的战术。详细的测试技术指标应包含在独立创建的测试详细规格文档中,而用于指导测试执行的测试用例则应放在独立创建的测试用例文档或测试用例管理数据库中。
您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
测试用例设计方法 | 说明 |
---|---|
等价类划分 | 将输入数据划分为有效等价类和无效等价类,选取每个等价类的代表值作为测试数据。例如,对于一个要求输入年龄的系统,可以将年龄划分为青少年、成年人和老年人等等,然后选择每个等价类的典型年龄作为测试数据。 |
边界值分析法 | 着重考虑输入或输出范围的边界情况,选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。例如,对于一个要求输入1到100的数字的系统,边界值分析法会选取1、100、2、99等作为测试数据。 |
错误推测法 | 基于经验和直觉推测可能存在的各种错误,设计有针对性的测试用例。例如,列举程序中可能存在的常见错误和特殊情况,选择这些情况下的例子作为测试数据。 |
因果图方法 | 考虑输入条件之间的相互组合,利用因果图生成判定表来描述多种条件的组合情况。例如,对于一个需要考虑多个条件组合的系统,利用因果图方法可以生成判定表,以检查各种组合情况。 |