2014第一章软件测试基本概念资料

1、软件测试基础 主讲：章瑾测试第一章软件测试基本概念什么是软件测试软件测试与CMMI测试用例测试环境软件测试人员的需求 1.1 什么是软件测试 测试：以检验产品是否满足需求为目标软件测试：在规定条件下对程序进行操 作，以发现错误，对软件质 量进行评估。安全测试2007 12 19 HP发布了补丁程序,主要是修复笔记本电脑预装的“惠普信息中心”软件存在的一个漏洞。黑客可以在惠普笔记本电脑上，远程执行代码，修改注册表进行恶意攻击，包含安装恶意软件，修改注册表信息以便对受害电脑进行复杂的攻击，先发布了这个补丁程序进行救急，但补丁程序禁用了信息中心一键启动的快捷功能，只能是一种临时的解决方案，是通过牺牲

2、用户的一个功能来控制黑客的攻击，但本身给用户的日常使用带来不便，接下来解决方案及补丁程序的升级，是消耗大量的开支最重要给用户带来的损失和声誉是不可估量的，压力负载 2008年北京奥运会售票系统在2007年10月30号上午九点正式启动，第二阶段销售工作系统启动，系统启动大概一个小时以后由于访问流量太大，超过正常负荷，三个门票销售渠道到无法正常进行处理，经过抢修五点才恢复正常仍然不稳定，当天下午六点开始关闭售票系统。各主要是因为访问量过大，在九点到十点之间官方票务网站的访问量高达八百万次，是预设一百万次的八倍，从三个渠道提交的票据统的门票订单高达20万张，远远超过预设的票务系统造成了网络拥堵售票系

3、统慢和无法登录系统的情况。而每小时15万张的处理能力的票务系统正常运行了不到一个小时彻底瘫痪造成票务系统主要的原因是系统后台的数据库处理能力不足，无法承受大量的大流量的访问，采取的方法是进行大规模的扩容升级，直到12月10号重新开放，这个时候，销售售票政策，将先到先得，调整为抽签得票系统功能缺陷2008年4月14日，美国空军十二架“猛禽”从夏威夷飞往日本的任务途中当途经国际日期变更线的时候，飞机上的全球定位系统纷纷失灵，多个电脑系统发生崩溃，多次重启均无效。飞行员无法正确辨识战机的位置飞行高度和速度，随时有可能折戟沉沙的厄运，不得不调头返航，幸好当天的天气好能见度高，加油机也可以引导他们安全着

4、陆顺利返回夏威夷的空军基地。错误原因主要是因为电脑系统编码中的一个错误引起的， 1.1 什么是软件测试软件=文档+数据+程序软件测试的对象：对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。本节概述从保证软件质量的角度来说，软件测试是软件质量保证工程的一个重要组成部分，也是最重要的质量保证手段。然而，随着软件开发技术的不断发展，以及软件系统的规模和复杂性的不断增加，传统的软件测试理论和技术已经不能够很好地满足开发组织在产品质量、开发成本、研制周期等方面的需求。 1.2 软件测试与CMMI1.2.1 传统的软件测试技术和测试过程模型 传统的软件测试只 是作为软件开发过程中

5、的一个特定阶段，并且只针对软件 成品进行测试。软件测试在软件开发过程的瀑布模型描述中所处的地位传统软件测试软件测试的发展扩充后的软件测试包括软件需求分析、软件概要设计、软件详细设计、编码、集成、验收等各个工程阶段CMMI模型是从软件过程改进和评估的角度出发，对软件开发中的测试技术给出了充分的支持和扩充1.2.2 CMMI模型对软件测试的支持和扩充CMMI模型主张在开发过程中注重对过程和产品的度量，以量化的形式提供对管理过程的支持，以及对过程进行相应的评估和改进。这实际上就是对软件测试技术的一种应用和扩充。测量和分析过程域的三个目标协调测量和分析活动提供度量结果将测量和分析活动制度化为可管理的过

6、程第一个目标 协调测量和分析活动模型中给出4个方面的特定实践：确定测量对象，建立测量目标详细说明度量值，以处理测量目标规定数据收集和存储规程，说明如何获得并存储测量 数据规定分析规程，说明如何对度量数据进行分析和报 告，并且安排优先顺序第一个目标 协调测量和分析活动测量对象：组织所开发出的软件产品、半成品以及过 程产品对开发过程本身的度量 第二个目标 提供度量结果，以便处理信息需要和目标模型中给出4个方面的特定实践：收集度量数据，即获得制定的度量数据分析并解释度量数据管理并存储度量数据、度量规范和分析结果通报分析结果，向所有的干系人报告测量和分 析活动的结果第三个目标将测量和分析活动制度化为可

7、管理的过程第三个目标是共性目标，这一目标主要关注的是对软件测试和过程度量活动的管理以及制度化。针对这一共性目标，CMMI模型从四个不同方面给出了10个共性实践。第三个目标将测量和分析活动制度化为可管理的过程首先，要求组织建立方针，为策划和执行“测量和分析”过程提供组织级的支持其次，组织应该制定测量和分析过程计划，提供必要的资源，分配相应的责任，并且对相关人员进行培训第三，组织应该将测量和分析过程指定的工作产品置于配置管理的适当层次，确定与过程相关的干系人并使之介入，同时还要对测量和分析过程进行监督和控制最后，组织应该客观评价测量和分析过程以及过程的工作产品和服务的遵循情况；同时，由高层管理者审

8、查测量和分析过程的活动、状态和分析结果，并解决相应的问题。CMMI模型对传统软件测试技术的扩充从对软件产品的测试到软件产品的测试开发过程的度量从事后测试到全过程测试和分析软件测试与开发的其他阶段不再串行工作，而是并行进行软件缺陷 1963年，由于用FORTRAN程序设计语言编写的飞行控制软件中的循环语句DO 5 I=1，3误写为DO 5 I=1.3，DO语句少了一个逗号，结果导致美国首次金星探测飞行失败，造成价值约1000多万美元的损失。 临近2000年时，计算机业界一片恐慌，这就是著名的“千年虫”问题。 符合下面4个规则之一就是软件缺陷。软件未达到软件规格说明书中规定的功能软件出现了产品说明

9、书中指明不会出现的错误；软件功能超出了产品说明书中指明的范围软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好软件缺陷类型列表缺陷类型描述功能影响了各种系统功能、逻辑的缺陷用户界面影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷文档影响发布和维护，包括注释，用户手册，设计文档软件包由于软件配置库、变更管理或版本控制引起的错误性能不满足系统可测量的属性值，如执行时间，事务处理速率等。系统/模块接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。软件缺陷严重等级列表缺陷严重等级描述致命 系统任何一个主要

10、功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全严重 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响一般系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。较小使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。缺陷产生可能性列表缺陷产生可能性描述总是总是产生这个软件缺陷，其产生的概率是100%通常通常情况下会产生这个软件缺陷，其产生的概率大概是80-90%有时 有的时候产生这个软件缺陷，其产生的概率

11、大概是30-50%很少很少产生这个软件缺陷，其产生的概率大概是1-5%软件缺陷优先级列表缺陷优先级描述立即解决缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级缺陷严重，影响测试，需要优先考虑正常排队缺陷需要正常排队等待修复低优先级缺陷可以在开发人员有时间的时候被纠正。软件缺陷状态列表缺陷状态描述激活或打开问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。 已修正或修复已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 关闭或非激活测试人员验证后，确认缺陷不存在之后的状态。重新打开测试人员验证后，还依然存在的缺陷，等待开发人员进一步修

12、复推迟这个软件缺陷可以在下一个版本中解决保留由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷不能重现开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。软件缺陷来源列表缺陷来源描述需求说明书需求说明书的错误、或不清楚引起的问题设计文档设计文档描述不准确、和需求说明书不一致的问题系统集成接口系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷数据流(库)由于数据字典、数据库中的错误引起的缺陷程序代码纯粹在编码中的问题所引起的缺陷软件缺陷根源列表缺陷根源描述测试策略错误的测试范围，误解了测试目标，超越测试能力等过程，工具和方法无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，

13、没有估算规程，无效的变更控制过程等。团队项目团队职责交叉，缺乏培训，没有经验等。组织和通讯缺乏用户参与，职责不明确，管理失败等。硬件硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等软件软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000 千年虫问题等。工作环境组织机构调整，预算改变，工作环境恶劣，如噪音过大。 和软件生命周期一样，一个缺陷从它产生到终结的过程，称之为缺陷生命周期。每个缺陷都具有8种生命状态，即缺陷初始状态、缺陷分配状态、缺陷重新分配状态、缺陷修复状态，缺陷验证状态、缺陷重新打开状态、缺陷关闭状态。1.3.1 什么是测试用例 1.

14、3 测 试 用 例测试用例的三种定义测试用例（Test Case，TC）简单来讲是指执行条件和预期结果的集合，完整来讲是针对要测试的内容所确定的一组输入信息，是为达到最佳的测试效果或高效地揭露隐藏的错误而精心设计的少量测试数据。RUP（Rational Unified Process，统一软件开发过程）中认为测试用例是我们用来验证系统实际做了什么的方式，因此，测试用例必须可以按照要求来跟踪和维护。IEEE标准610（1990）给出的定义为：测试用例是一组测试输入、执行条件和预期结果的集合，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求测试用例核心一、测试内容

15、二、输入信息1.3.2 测试用例的评价标准 以满足某一个测试目标或测试任 务来整体看测试用例，衡量一组 测试用例的结构、设计思路和覆 盖率等指标 从单个测试用例看，衡量其描述 的规范性、可理解性和可维护性 等指标高层次低层次七标准九标准（1）测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。（2）设计思路正确、清晰。例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。（3）在组织和分类上，测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致

16、，并具有合理的优先级或执行顺序。（4）测试用例覆盖所有测试点、覆盖所有已知的用户使用场景（User scenario），也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。（5）测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。（6）有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。（7）没有重复、冗余的测试用例，满足相应的行业标准等。七标准（1）测试

17、用例的出发点是发现缺陷，即单个测试用例在“暴露缺陷”上具有较高的可能性。（2）测试用例的单一性。一个测试用例面向一个测试点，不要将许多测试点揉在一起。例如，通过一个测试用例发现12个缺陷，而不能发现510个缺陷甚至更多的缺陷。（3）符合测试用例设计规范或测试用例模板。（4）描述清楚。包括特定的场合、特定的对象和特定的术语，没有含糊的概念和一般性的描述。例如，测试用例名称为“登录功能使用正常”，就是一个描述不清楚的例子，而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户账号被锁定后再进行登录操作”等就比较好。九标准（5）操作步骤的准确性。按照步骤的操作得到

18、唯一的测试结果。（6）操作步骤的简单性。操作步骤不应该太复杂，过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。（7）所期望的测试结果是可验证的，即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如，在测试用例中描述期望结果为“登录成功”，这实际是不可验证的。要使这个期望结果具有可验证性，我们就应该这样描述所期望的结果“退出（log out）按钮出现”。（8）测试环境的正确性、测试数据的充分性。（9）前提条件、依赖性被完全识别出来1.3.3 测试用例设计的基本原则测试用例的代表性测试结果的可判定性测试结果的可再现性核心输入条件正常数据边界数据

19、错误数据测试数据1.3.4 测试用例模板（1）软件或项目的名称。（2）软件或项目的版本（内部版本号）。（3）功能模块名。（4）测试用例的简单描述，即该用例执行的目的或方法。（5）测试用例的参考信息（便于跟踪和参考）。（6）本测试用例与其他测试用例间的依赖关系。1.3.4 测试用例模板（7）本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限。（8）用例的编号（ID），如可以是“软件名称简写功能块简写NO.”。（9）步骤号、操作步骤描述、测试数据描述。（10）预期结果（这是最重要的）和实际结果（如果有缺陷管理工具，这条可以省略）。（11）开发人员（必须有）和测试人员（可有可无）。

20、（12）测试执行日期。项目/软件技术出口合同网络申领系统程序版本1.0.25功能模块名Login编制人xxx用例编号TC-TEP_Login_1编制时间2010.10.12相关的用例无功能特性用户身份验证测试目的验证是否输入合法的信息，允许合法登录，阻止非法登录预置条件无特殊规程说明如数据库访问权限参考信息需求说明中关于“登录”的说明测试用例模板测试数据用户名 =yiyh 密码 =1操作步骤操作描述数据期望结果实际结果测试状态1输入用户名称，按“登录”按钮用户名=yiyh，密码为空显示警告信息“请输入用户名和密码！”2输入密码，按“登录”按钮用户名为空，密码 =1显示警告信息“请输入用户名和密

21、码！”测试人员开发人员项目负责人1.4.1 什么是测试环境软件测试环境就是软件运行的平台，即软件、硬件和网络的集合测试环境 = 软件 + 硬件 + 网络+ 历史数据 1.4 测 试 环 境测试环境 = 软件 + 硬件 + 网络+ 历史数据主要指软件运行的操作系统主要针对C/S结和B/S结构的软件指测试用例执行所需初始化的各项数据包括PC、笔记本电脑、服务器、各种PDA终端测试环境的规划步骤明确八大问题确定条件特性（可满足，需协调）将上述问题整理为检查表，为每个问题制定负责人1.4.2 测试环境的规划1.4.2 测试环境的规划规划测试环境的第一步明确如下问题（1）执行测试所需的计算机数量和对每台

22、计算机的硬件配置要求，包括CPU速度、硬盘和内存容量、网卡支持的速度等。 （2）部署服务器所需的操作系统、数据库管理系统（DBMS）、中间件、Web服务器等（以下统称支撑软件环境）的名称、版本，必要时还需明确相关补丁的版本。 （3）用于保存文档和数据（这里主要是指测试过程中生成的文档，而非测试参考文档或存放测试结果的最终文档）的服务器必需的支撑软件环境中各软件的名称、版本，必要时也应明确相关补丁的版本。1.4.2 测试环境的规划规划测试环境的第一步明确如下问题（4）测试机所需支撑软件环境中各软件的名称、版本，必要时应明确相关补丁的版本。（5）用于对被测软件系统的服务器环境和测试管理服务器环境进

23、行备份的专用计算机（该环节是可选的）。（6）测试所需的网络环境。（7）执行测试工作所需的一些辅助软件。例如文档编写工具、测试管理系统、性能测试工具、缺陷管理系统等，应明确这些软件的名称、版本、License（授权证书）数量和可能需要的相关补丁的版本。对于性能测试工具，还需要重点留意是否支持被测软件系统所用的协议。（8）为执行测试用例所需初始化的各项数据。对性能测试而言，还需重点留意执行测试用例之前应满足的历史数据量，以及在测试过程中受到影响的数据的恢复问题。手机通讯列表，显示界面上，有通讯录显示用户的通讯信息包含姓名电话号码，界面图标上有三处按钮，于是三用于删除记录就删除记录的功能下选择一条记

24、录以后单击删除按钮记录就可删除，曾经遇到过这样的一个错误，列表只有一条记录，删除记录以后再单击删除以后手机，屏幕突然黑屏，程序崩溃。后来查明原因是按钮的状态不对当列表中没有记录的时候按键在激活状态，记录删除了，为什么还要单击按钮删除了，没有呢！测试人员没有没事干嘛？这恰恰是测试用例当中的，一个，特殊的逆向思维体现。案例：某公司在招聘测试工程师时有这样的一个笔试题，某嵌入式软件有用U盘导出数据的功能，请写出测试该功能点的思路。 测试思路的形成考虑方向检查点测试思路备注正向功能导出数据的正确性用U盘导出某软件的数据，包括某软件产生的各种类型的数据，采用可行的方法验证其导出数据的正确性。正向功能导出

25、功能的有效性处理某软件导出数据不存在时导出功能是否正确逆向功能导出数据的配置软件安装后导出功能的配置是否正确，此点与软件的实现有关，边界容量U盘空间不足的处理当前U盘空间只能容纳导出的部分数据时，执行数据导出边界容量U盘空间满处理，U盘空间满时执行数据导出，容错U盘写保护处理，u盘写保护是执行数据导出，考虑方向检查点测试思路备注容错坏U盘的处理用一个坏U盘进行数据导出(坏U盘的准入条件可以WINDOWS能否正常写入数据为准）容错人为非法操作容错处理，导出数据过程当中，拔出U盘，软件的后续处理是否有异常容错软件工作时遇到特殊情况的处理。数据导出过程中突然停电，再开机检查U盘中的数据，及软件导出功能是否符合预期，性能压力测试连续找出n次后，数据的正确性，脚本自动执行连续导出N次（N1000)数据检查数据的正确性性能优盘导出速度，同一U盘从软件中导出批量数据的速度，与同样大小的数据在WINDOWS下写速度相比，性能不同USB驱动协议对导出速度的影响，分别用USB1.0USB2.0的U盘进行批量