软件测试考试题及答案

什么是软件测试

测试是为发现错误而执行的一个程序或者系统的过程。

测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程 测试目的、目标，

软件测试是一个为了寻找故障而运行程序的过程

一个好的测试用例是很可能找到至今为止尚未发现的故障的测试用例 一次成功的测试是揭示了至今为止尚未发现故障的测试

从软件工程的角度，软件测试的目标是设计这样的测试：既能系统的揭示不同类型的故障而且耗费最少的时间和最少的工作量 软件故障哪些状态，

软件未达到产品描述标明的功能/非功能要求 软件出现了产品描述指明不会出现的错误 软件功能超出了产品描述指明的功能 软件未达到产品描述虽未指明但应达到的目标

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

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 白、黑盒，因果图，非功能测试

白盒测试：对于测试对象的内部内容是透明的、可见的，可以设计数据覆盖测试对象的每一条路经。

黑盒测试：黑盒法不关心程序内部的逻辑，而只是根据程序的功能说明来设计测试用例

等价分类法和边界值分析法都没有考虑输入情况的各种组合，也没有考虑各个输入情况之间的相互制约关系

因果图方法的思路：从用自然语言书写的需求规格说明书中找出因（输入条件）和果（输出或者程序状态的改变），通过因果图转换为判定表 非功能测试 以杯子为例：

功能度：用水杯装水看漏不漏；水能不能被喝到 界面测试：查看杯子外观 安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损

震动测试：杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\\公路\\航空运输 说明书测试：检查说明书书写准确性配置/安装测试安装 / 反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船”

目前市面上有非常流行的、专门制作安装/反安装程序的一些工具，如Install Shelled。制作安装/反安装程序不再是件难事，关键是不要麻痹大意。主要测试工作： （1）至少在标准配置和最低配置两种环境下测试；2）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。 兼容性测试

是指几个硬件之间、几个软件之间或是几个软硬件之间的相互配合的程度。 兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。

文档和帮助测试

这种测试是检查用户文档(如用户手册)的清晰性和精确性。 健壮性测试

健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

容错性测试通常构造一些不合理的输入来引诱软件出错，例如： （1）输入错误的数据类型。如“猴”年“马”月。 （2）输入定义域之外的数值。

粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。

恢复测试重点考察一下几项： （1）系统能否重新运行； （2）有无重要的数据丢失；

（3）是否毁坏了其它相关的软件硬件。 性能测试

性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。 既要马儿跑得快，又要马儿吃的少。

有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。

在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。

性能测试

性能优化的关键工作是找出性能的“瓶颈”，不要关注无关痛痒的地方。 程序员可以通过优化数据结构、算法和代码(包括SQL)来提高软件的性能。

算法复杂度分析是很好的方法，可以达到“未卜先知”的功效。 性能测试

性能优化就好像从海绵里挤水一样，你不挤，水就不出来，你越挤海绵越干。 有些程序员认为现在的计算机不仅速度越来越高，而且内存越来越大，因此软件性能优化的必要性下降了。这种看法是不对的，殊不知随着机器的升级，软件系统也越来越庞大了和复杂了，性能优化仍然大有必要。 性能测试的一些注意事项：

不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。

应当测试软件在标准配置和最低配置下的性能。

为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。 不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从100K到1M可以分成若干等级。

由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。 可靠性测试

可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。

比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。 安全性测试

信息安全性（security）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。

信息安全性测试有如下步骤：

（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。 2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。 压力测试

压力测试也叫负荷测试，即获取系统能正常运行的极限状态。了解“极限”是很有价值的，例如潜艇下潜极限深度„。

压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。敏感测试目的是发现什么样的输入可能会引发不稳定现象。 易用性测试

易用性是指用户使用软件的容易程度。

现代人的生活节奏快，干啥事都想图个方便。所以把易用性作为重要的质量属性对待无可非议。

性能测试工具LoadRunner

是一种预测系统行为和性能的工业标准负载测试工具

通过模拟大量用户实时并发负载和实时性能监测的方式来确认和查找问题 创建虚拟用户 创建真实负载 实施监测 结果分析 单元测试覆盖的区域

单元执行的计算/操作的正确性 低级性能问题 低级可靠性问题 窗口的内容及导航，包括窗口的外观的一致性、热键、功能键和快捷键 报告的内容、布局和计算 文件/记录的创建、更新及删除 互操作单元间的通信 单元的定义

单元的定义与被测试系统的设计方法，以及在开发过程中采用的实现技术有关： 使用过程化程序语言开发的应用中的单元可以用一个函数或过程表示 使用面向对象编程语言开发的应用中的单元可以用一个类表示

可视化编程环境下的单元可以是一个窗口，或者是这个窗口中相关元素的集合 基于组件开发环境中的单元可以是一个预先定义的可重用的组件

单元测试方法

确定如何调用某个给定单元以及每次调用该单元的响应 确定单元的状态和状态间转换

确定单元的每个状态的预期结果，以及确认这些结果所必须的内容

考察被测试系统的需求规格说明文档以及被测试的单元，确认以前的步骤已识别出了所有可能的测试条件，如有必要可以增加附件条件 确定测试该单元的先决条件

使用上述信息生成一套测试该单元的测试用例 单元测试的数据需求 不使用真实数据

需要少量数据时可以考虑可以使用边界分析或等价类划分方法，设计模拟数据 需要大量数据时，可以使用真实数据的拷贝（对于敏感数据应适当处理），或者使用真实数据的有代表性的样本 单元测试输入

被测试系统的需求规格文档 被测试系统的设计文档 补充材料（如用户手册） 单元测试计划单元测试规范说明文档 单元测试指南 单元测试用例 空白的测试记录表格

单元测试－测试技术

针对被测单元需求的功能测试 静态测试 白盒测试 状态转换测试 性能测试 单元测试－输出

完整的被测试过的单元 单元测试证书 修正的测试用例 归档的测试数据 完成的测试结果记录表格 单元测试日志 单元测试重用包

单元测试过程

单元测试停止标准

单元测试用例设计已经通过评审

按照单元测试计划完成了所有规定单元的测试

达到了测试计划中关于单元测试所规定的覆盖率的要求 被测试的单元每千行代码必须发现至少3 个错误 软件单元功能与设计一致

在单元测试中发现的错误已经得到修改， 各级缺陷修复率达到标准 集成测试-概述

进行系统测试之前证明组成被测试系统的各个模块以正确、稳定、一致的方式接口和交互。由开发组/测试组完成 黑盒技术 集成测试覆盖的区域

从其它互操作模块调用一个模块 在互操作模块间正确传输数据 兼容性 性能问题

执行集成测试遵循的方法

识别组成一个完整系统的模块间的关系

评审模块间的交互和通信需求，识别出模块间的接口 使用上述信息产生一套测试该模块的测试用例

当依次将模块加入到扩充的系统中 ，并测试新合并的系统时，应采用增量测试 集成测试-数据需求

不使用真实数据 使用测试辅助程序模拟数据访问 集成测试-输入

被测试系统的需求规格文档 被测试系统的设计文档 补充材料（如用户手册） 集成测试计划单元测试规范说明文档 集成测试指南 集成测试用例 空白的测试记录表格 集成测试-输出

完整的被测试过和集成过的模块 集成测试证明 修正的测试用例 归档的测试数据 完成的测试结果记录表格 集成测试日志 集成测试报告 集成测试过程

系统测试停止标准

系统测试用例设计已经通过评审 按照系统测试计划完成了系统测试

达到了测试计划中关于系统测试所规定的覆盖率的要求 被测试的系统每千行代码必须发现1 个错误 系统满足需求规格说明书的要求

在系统测试中发现的错误已经得到修改， 各级缺陷修复率达到标准 系统集成测试－概述

目标：确保被测试系统可以与其他制定的软件系统成功进行互操作（不对其他系统产生不利的影响，也不被其他系统影响）黑盒技术 测试人员进行 系统集成测试－方法

审查系统的互操作性需求，并确认以下要求：

1.被测试系统与其他系统通信的需求和通信的手段2.涉及与其他系统通信的高级业务需求3.真实环境中数据处理和事务率的需求4.系统性能的需求5.备份和恢复的需求6.保密性需求考察将要运行真实系统的计算机环境，找出与其他系统的互操作性和兼容性的问题通过以上信息，产生一套测试该系统的测试用例 系统集成测试－数据需求 使用真实数据

系统集成测试－测试技术

针对高级需求的黑盒测试 针对被测试系统的高级业务需求的线索测试 发现任何未预料到的问题的否定测试和错误测试 考虑自动化测试工具的使用 系统集成测试－输出

完整的被测试系统 系统测试证明 修正的测试用例 归档的测试数据 完成的测试结果记录表格 系统集成测试日志 系统集成测试报告 系统集成测试－过程

用户验收测试－概述

目标：确认被测试系统能够满足业务需求，在将软件正是交付给最终用户之前，确保系统工作正常并可以使用

黑盒测试在测试组的协助下，由用户代表完成 操作验收测试－两种用户测试区别

用户验收测试：验证被测试系统符合其业务需求，并在正式提交给最终用户之前确信系统工作正确并可用

操作验收测试：验证被测试系统在操作和管理方面的情况（例如：更新后被测试系统的安装、对被测试系统及其数据的备份、归档和恢复以及注册新用户并为其分配权限）

操作验收测试－数据需求 测试数据满足下列需求：

1.所用的测试数据能够体现真实数据并具有代表性

2.测试数据为支持那些操纵海量数据的操作验收测试任务提供了数量和复杂性都足够的数据

3.操作验收测试不涉及重要数据的访问和操作 当真实数据包括机密性和保密性信息时，必须保证： 1.用户代表被允许使用这些数据 2.测试组组长被允许使用这些数据 3.测试观察员被允许使用这些数据 测试的分类与比较

问题1：有了“黑盒”测试为什么还要“白盒”测试？

黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。

问题2：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？

要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。

问题3：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?

不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。 问题4：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？ 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。

不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。

问题5：能否将系统测试和验收测试“合二为一”？

系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。

系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。 企业的测试策略 理念：

企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。 用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。 如何合理地减少测试工作量 减少冗余的测试

白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出），这样的测试是冗余的。在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。 第六章的测试管理 测试的组织

角色和职责－测试主管

管理测试过程日常的组织 负责与开发组进行联系 负责向公司的高级主管或领导报告 在验收测试第三方软件时，作为公司的代表 可以由高级主管或质量保证主管兼职

软件测试管理要素

测试计划（Plan）测试人员及组织（People）测试过程（Process）技术过程、支持过程、管理过程 测试工作产品（Product）测试计划、测试用例、缺陷报告、测试报告

软件测试管理的系统方法

以系统的观点看待软件测试管理，测试管理是软件项目管理的一个子系统 关注软件测试中的四要素关注软件测试管理子系统与开发管理子系统的相互关系关注软件测试系统中各过程的相互关联、相互作用 测试计划

测试估计 确定切实可行的测试目标 制定合理的软件测试计划 控制测试计划的执行 人员管理

选择合适的测试人员 是测试人员能够按照计划完成测试任务 与相关方进行沟通、协同工作 建立有效的测试团队 测试过程

定义和定制所需要的测试过程 满足测试过程所需要的资源和条件 实施确定的测试过程 测量和分析测试过程的有效性和效率 进行基于度量的软件测试过程的持续改进 测试产品

检查和评测测试工作产品

测量和分析测试对象-开发的软件产品、收集质量分析和合产品放行决策所需要的数据 测试配置管理 测试人员的选择

计算机技能 测试能力 测试经验 产品经验 开发经验 职业素质 测试人员及组织 选择合适的测试人员

使测试人员能够按测试计划完成测试任务 与相关方进行沟通 建立有效的测试团队

测试人员的选择

测试人员能力及要求

一般能力：表达、交流、协调、管理、质量意识、软件工程等

测试技能及方法：测试基本概念及方法、测试工具及环境、专业测试标准等 测试规划能力：风险分析及防范、软件发行标准、测试目标及计划、测试计划及评审方法 测试执行能力：测试数据/用例、测试比较及分析、缺陷记录及处理、自动化工具测试分析、报告和改进能力：测试统计、测试报告、过程监测及持续改进

需求的层次（Maslow模型）

生存需求－工作职位、工资奖金、休息时间 安全需求－公正待遇、应付工作的能力和信心 社会需求－团队归属感，相互理解、认同和支持 自尊需求－具有受人尊重/赏识的能力和业绩 自我实现需求－成为自己期望的人物 测试人员职业发展计划

初级测试工程师具备必要的计算机知识和技能掌握测试技能和方法，具有测试/实施能力 中级测试工程师初级测试工程师一年以上经验具有测试设计能力，能够指导初级测试工程师工作

12年的测试发展计划 1-2年 技术技能

熟悉整个测试过程及产品业务领域，学习 和掌握自动测试工具，学习测试自动化编程工具开发和执行测试脚本，承担测试实施任务掌握编程语言、操作系统、网络与数据库方面的技能 3-4年 测试过程

深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审 进一步了解产品业务领域，改进测试自动化编程技术

能指导初级测试工程师加强编程语言、操作系统、网络与数据库方面的技能 5-6年 技术管理

管理4-8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划研究测试的技术手段，保持使用项目管理及支持工具技能用大量时间为其他测试工程师提供技术及过程方面指导开始与客户打交道并做演示推介6-12年测试管理

管理8名以上测试工程师，负责一个或多个项目的测试工作与客户打交道并做演示推介保持使用项目管理及支持工具的技能 软件测试培训内容分类

软件测试基础知识和技能培训 软件测试过程培训 软件测试管理培训 软件测试设计培训 软件测试工具培训 软件测试对象－软件产品培训 软件测试人员的培训计划

是测试计划的一个重要组成部分需要管理层的重视，在时间和资源上予以保证 认真调查和分析测试人员的培训需求将培训活动安排在测试任务开始前“边干边学”模式很可能牺牲质量和效率软件测试实习活动在整个培训中占较大比例鼓励合作学习，团队演练对培训效果要及时评价，发现不足进行改进 测试工作产品

检查和评审测试工作产品测量和分析测试对象分析和产品放行决策所需的数据测试配置管理

软件测试常见问题/风险

在软件测试方面培训不足、人员能力不足 发人员与测试人员的对立情绪 测试人员“左右不是人” 测试人员不愿意充当带来坏消息和说“不”的人 过分依赖软件测试 缺乏管理层对测试的理解和支持用户参与不够 测试跟不上软件的快速变化 缺乏软件测试工具 软件测试时间不够 缺乏完整的需求文档、设计文档 测试过程

定义和定制所需的测试过程 满足测试过程所需的资源 实施确定的测试过程 测量和分析测试过程的有效性和效率 进行基于度量的测试过程的持续改进