软件测试基础教材.docx
《软件测试基础教材.docx》由会员分享，可在线阅读，更多相关《软件测试基础教材.docx（228页珍藏版）》请在冰豆网上搜索。
软件测试基础教材
软
件
测
试
基
础
教
材
第一章软件测试的概述
1.1软件的相关知识概述
1.1.1软件的含义
软件（英语：
Software）是一系列按照特定顺序组织的电脑数据和指令的集合。
一般来说软件被划分为编程语言、系统软件、应用软件和介于这两者之间的中间件。
其中系统软件为计算机使用提供最基本的功能，但是并不针对某一特定应用领域。
而应用软件则恰好相反，不同的应用软件根据用户和所服务的领域提供不同的功能。
软件并不只是包括可以在计算机上运行的电脑程序，与这些电脑程序相关的文档，一般也被认为是软件的一部分。
简单的说，软件就是程序加文档的集合体。
软件被应用于世界的各个领域，对人们的生活和工作都产生了深远的影响。
其中：
●程序是按事先设计的功能和性能要求执行的指令序列。
●文档是与程序开发、维护和使用有关的图文材料。
1.1.2软件的生存周期
软件生命周期（SDLC，SystemsDevelopmentLifeCycle，SDLC）是软件的产生直到报废或停止使用的生命周期。
周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分层的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。
但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
●瀑布模型
瀑布模型是将软件生命周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水（如下图所示），最终得到软件产品。
在每一个阶段结束时，项目小组进行审查，并决定是否进入下一步。
●螺旋模型
1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
●迭代模型
迭代式模型是RUP（RationalUnifiedProcess，统一软件开发过程，统一软件过程）推荐的周期模型。
在RUP中，迭代被定义为：
迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和使用该发布必需的所有其他外围元素。
所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：
（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上，它类似小型的瀑布式项目。
RUP认为，所有的阶段（需求及其它）都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
1.1.3软件测试的生命周期
通过学习软件生命周期的瀑布模型、螺旋模型以及迭代模型，可以了解软件产品开发的基本过程。
那么，软件测试的生命周期又是什么样子？
如下图所示，展示了软件测试的生命周期。
实践证明，尽管人们在开发软件的过程中使用了许多保证软件质量的方法和技术，但开发出的软件中还会隐藏许多错误和缺陷。
规模大、复杂性高的软件更是如此。
所以。
严格的软件测试对于保证软件质量具有重要作用。
1.2软件质量保证
1.2.1软件质量保证（SQA）的定义
软件质量保证（SQA-SoftwareQualityAssurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
软件质量保证的目的是使软件过程对于管理人员来说是可见的。
它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。
软件质量保证组在项目开始时就一起参与建立计划、标准和过程。
这些将使软件项目满足机构方针的要求。
1.2.2SQA的目标
●遵循《软件质量保证计划》进行软件质量保证活动；
●客观地验证软件开发过程和软件产品是否遵守可用的标准、规程和要求；
●确保将软件质量保证的活动和结果通知受影响的项目组和人员；
●高层管理者关注在软件项目中不能解决的偏差事件和不合格项。
1.2.3SQA的任务
●SQA参与制定计划
SQA参与制定计划包括SDP和阶段计划，在SDP活动中，SQA主要是参与到软件过程的剪裁、复审估算、参与评估风险等。
然后，SQA参与复审SDP，其目的，除了熟悉项目的计划外，还需要复审查看是否SDP与纳入项目的客户的需求一致，计划能否满足客户的需求的，在SDP修正中，涉及到上述内容的，也需要SQA参与。
然后，SQA也会参与阶段计划的制定，主要是复审阶段计划是否满足阶段的目标。
●SQA参与复审纳入项目的需求
此时SQA主要是作为复审者的角色，复审纳入的需求描述是否清晰、一致、需求的可行性等。
●SQA制定SQA审计计划
在制定计划的同时，SQA也需要制定SQA审计计划，在制定SDP的时候，SQA制高层的审计计划，主要是计划有那些内容需要SQA审计的。
然后，在制定阶段计划的时候，SQA需要制定具体的审计计划，包括每次审计的时间，审计的对象等。
●SQA参与进度复审或里程碑复审活动
SQA在参与进度复审或里程碑复审活动中，主要是一方面了解项目的进度，另一方面，复审项目在进度复审中采取的一些修正行动的时候，是否满足客户的需求，是否可行等，而在里程碑复审中，则复审项目当前的状态是否满足里程碑的标准（Criteria of Milestone），是否达到里程碑的目标。
●SQA审计
另外，SQA的主要活动是按照制定的SQA审计计划对项目进行审计，审计的内容包括过程审计和工作产品审计。
过程审计主要是审计项目开展的软件活动是否和计划、与OSSP一致，工作产品审计主要是审计工作产品是否满足标准和约束条件。
●SQA阶段总结
由于公司很多项目都是采用迭代模式的开发，项目开发周期较长，所以有必要在项目某个阶段结束的时候，对SQA在这个阶段的活动进行一个总结，主要是对一些经验教训进行分析，找出这些问题背后的原因，提出一些可行性的解决方案，目的是为了提高质量保证的水平。
●跟踪问题处理
SQA应跟踪问题处理过程，直到问题解决。
跟踪的问题包括日常发现的产品问题、过程问题、项目风险、评审发现的问题、测试发现的问题等。
如果不能和项目组就解决方案达成一致，可向公司高层反映。
●度量和报告
SQA应善于根据过程规范和经验发现项目运行中的问题，并做到紧急问题、重要问题随时汇报，其它问题周期性汇报。
SQA需要随时收集数据并保障数据的有效性、真实性。
定期汇总数据、统计分析并产生度量报告。
SQA应协助项目组和SEPG针对不良趋势和问题采取纠正或预防措施。
●质量推进
质量推进主要包括提高全员的质量意识和推进、解释过程的执行两个方面。
这项工作需要在日常工作中循序渐进地、坚持不懈地实施，这样做的目的是为了营造公司的一种质量文化氛围，理解和支持SQA的工作。
●过程制定
如果项目或组织需要制定过程规范，SQA应组织相关人员来完成过程制定工作。
一般情况下，过程制定应由遵守和执行该过程的人员负责。
所有制定的过程都必须经过评审，并由SQA检查执行情况。
●过程改进
过程改进是一项长期的任务。
SQA应注意随时发现、听取过程执行中问题和改进工作的方法，并进行阶段性的总结（比如质量报告等），以不断改进过程，提高过程能力。
●学习和研究
SQA要不断学习和研究，尽量保持与领域最新的知识、方法同步，找出提高产品质量和工作效率的方法与过程。
学习的内容主要包括管理领域和开发领域。
管理领域包括质量管理（TQM、ISO9000、CMM、RUP、MSF、XP等）、软件度量（PSM、GQM、SPC、SixSigma）、项目管理、配置管理等。
开发领域包括需求工程、设计、编码、测试等各阶段的开发和管理方法。
●质量培训
项目或组织需要时，SQA需要向相关人员进行质量管理方面的培训或咨询。
1.2.4SQA与软件测试的关系
软件测试和软件质量保证是软件质量工程的两个不同层面的工作。
软件测试只是软件质量保证工作的一个重要环节。
软件测试（SQC）是为使产品满足质量要求所采取的作业技术和活动，它包括检验、纠正和反馈。
比如SQC进行检验发现不良品后将其剔除，然后将不良信息反馈给相关部门采取改善措施。
因此SQC的控制范围主要是在工厂内部，其目的是防止不合格品投入、转序、出厂。
确保产品满足质量要求及只有合格品才能交付给客户。
软件质量保证（SQA）是为满足顾客要求提供信任，即使顾客确信你提供的产品能满足他的要求。
因此需从市场调查开始及以后的评审客户要求、产品开发、接单及物料采购、进料检验、生产过程控制及出货、售后服务等各阶段留下证据，证实工厂每一步活动都是按客户要求进行的。
1.3为什么需要测试
1.3.1软件系统的重要性
计算机是由硬件和软件组成，而操作系统就是基础的软件，它控制和管理计算机的软硬件资源，如果没有它，硬件将是一堆废铁，除非你会用01代码。
其他的应用软件就是所有工作与生活中的主要或辅助工具，那么，计算机软件的重要性包括哪些呢？
操作系统的作用主要体现在两个方面：
管理系统中的各种资源，包括硬件资源和软件资源。
在计算机系统中，所有硬件部件（如CPU、存储器、输入/输出设备等）称为硬件资源；而程序和数据等信息称为软件资源。
操作系统对每一种资源的管理都必须进行以下几项工作：
●决定分配资源策略
包括选择某种资源分配策略，决定谁有权限可以获得这种资源，何时可以获得，可以获得多少，如何退回资源等等。
●监视资源
监视资源包括需要知道该资源有多少，资源的状态如何，它们都在哪里，谁在使用，可供分配的又有多少，资源的使用历史等等。
●回收资源
回收资源是指在使用者放弃某种资源之后，对该种资源进行善后处理，如果是可重复使用的资源，则进行回收、整理，以备再次使用。
●分配资源
分配资源是指按照已决定的资源分配策略，对符合条件的申请者分配某种资源，并进行相应的管理事务处理。
1.3.2测试和质量
软件测试和软件质量保证是软件质量工程的两个不同层面的工作。
软件测试只是软件质量保证工作的一个重要环节。
软件测试是为使产品满足质量要求所采取的作业技术和活动，它包括检验、纠正和反馈。
比如软件测试进行检验发现不良品后将其剔除，然后将不良信息反馈给相关部门采取改善措施。
因此软件测试的控制范围主要是在工厂内部，其目的是防止不合格品投入、转序、出厂。
确保产品满足质量要求及只有合格品才能交付给客户。
软件质量保证是为满足顾客要求提供信任，即使顾客确信你提供的产品能满足他的要求。
软件质量保证的目的不是为了保证产品质量，保证产品质量是软件测试的任务。
软件质量保证主要是提供确信。
因此需对了解客户要求开始至售后服务的全过程进行管理。
这就要求企业建立品管体系，制订相应的文件规范各过程的活动并留下活动实施的证据，以便提供信任。
软件测试和软件质量保证的主要区别前者是保证产品质量符合规定，后者是建立体系并确保体系按要求运作，以提供内外部的信任。
同时软件测试和软件质量保证又有相同点：
即软件测试和软件质量保证都要进行验证，如软件测试按标准检测产品就是验证产品是否符合规定要求，软件质量保证的内审，就是验证体系运作是否符合标准要求。
测试并非像大家平时认知的那样，不动脑，天天对着屏幕点鼠标，虽然做测试门槛不高，但真正能做好做精，更需要正确的方法和勤奋的学习。
1.3.3测试是否充分
一个成功的测试包括两个主要方面：
一是软件在所有的（或足够多的）测试用例上是正确的；二是测试用例是充分的，即软件在测试用例上的表现能够充分地反应软件的总体表现。
软件测试的充分性是从软件在有限多个测试用例上的行为判断软件在所有输入数据上的行为的逻辑基础。
良好的软件测试充分性准则应该具有如下基本性质：
●空测试对任何软件都是不充分的。
空测试用例集意味着软件未被测试。
●对任何软件都存在有限的充分测试集合。
因为测试必须在有限的时间内完成，所以充分的测试集合必须是有限的。
这一性质成为有限性。
●如果一个软件系统在一个测试用例集合上的测试是充分的，那么再多测一些数据也应该是充分的。
这一性质成为单调性。
●及时对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。
这一性质称为反复合性。
●即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。
这一性质称为反分解性。
●软件测试的充分性应该与软件的需求和软件的实现都相关。
●软件越复杂，需要测试的数据也越多。
这一性质成为复杂性。
●测试得越多，进一步测试所能得到的充分性增长就越少。
1.3.4测试在软件生命周期中所担当的角色
在任何生命周期模型中，一个好的测试都应该具有下面几个特点：
●每个开发活动都有相对应的测试活动；（开发需要测试来验证）
●每个测试级别都有其特有的测试目标；
●对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计；
●在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审。
1.4软件缺陷与软件故障
1.4.1软件缺陷的定义和类型
软件缺陷（Defect），常常又被叫做Bug。
所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
IEEE729-1983对缺陷有一个标准的定义：
从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。
主要类型：
●软件没有实现产品规格说明所要求的功能模块；
●软件中出现了产品规格说明指明不应该出现的错误；
●软件实现了产品规格说明没有提到的功能模块；
●软件没有实现虽然产品规格说明没有明确提及但应该实现的目；
●软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
1.4.2软件缺陷产生的原因
在软件开发的过程中，软件缺陷的产生是不可避免的。
那么造成软件缺陷的主要原因有哪些？
从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
主要有以下几个方面：
从软件本身角度考虑：
●需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。
●系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
●对程序逻辑路径数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。
●对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。
●没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。
●系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。
从而会引起强度或负载问题。
●由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。
●新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。
从团队工作角度考虑：
●系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。
●不同阶段的开发人员相互理解不一致。
例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。
●对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
●项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。
从技术方面考虑：
●算法错误：
在给定条件下没能给出正确或准确的结果。
●语法错误：
对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。
●计算和精度问题：
计算的结果没有满足所需要的精度。
●系统结构不合理、算法选择不科学，造成系统性能低下。
●接口参数传递不匹配，导致模块集成出现问题。
●从项目管理问题角度考虑：
●缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试等时间，遗留的缺陷会比较多。
●由于技术欠佳，系统分析时，对客户的需求了解不透彻，或者和用户的沟通存在一些困难。
●开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整。
不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。
●开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。
●文档不完善，风险评估不足等。
1.4.3软件缺陷的构成
软件缺陷是由：
属性名称、描述、缺陷标识（Identifier）构成的。
缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识缺陷类型（Type），缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度（Severity）缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级（Priority）缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态（Status）缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源（Origin）缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源（Source）缺陷来源指引起缺陷的起因。
缺陷根源（RootCause）缺陷根源指发生错误的根本因素。
1.5软件测试的定义
1.5.1软件测试的概念
在1979年出版的一本经典著作《软件测试艺术》中，对软件测试进行了这样的定义：
软件测试就是“为了发现错误而执行程序或者系统的过程”。
这一定义明确了软件测试的根本目的是为了发现程序中的错误。
Myers撰写该著作的时期，软件测试通常在软件产品开发的后期开始，主要目的就是寻找产品运行过程中的缺陷。
因此，他对软件测试所下的这一定义被人们广泛接受，反映了人们在当时对软件测试所持的观点。
随着这一定义被广泛使用，人们发现了定义中存在的不足。
于是，1983年在IEEE提出的软件工程标准术语中，调整了对软件测试的定义，即“使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。
更新后的定义除吸收了从前人们对软件测试定义中的精华外，还明确指出，软件测试作为保证软件质量的一个重要手段，其主要任务是在已设计测试用例的基础上检验软件各个部分，以及整个系统是否正确、完整地实现了预定的功能，以确保软件质量。
今天，人们对软件测试有了更进一步的认识，从广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。
例如。
设计评审、单元测试、系统测试。
从狭义上讲，测试是对软件产品质量的检验和评价。
它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。
现代软件开发领域的大多数工作者都对测试有直观的认识，最常见的看法如下：
●保证程序和相应的规范说明一致。
●发现软件中的缺陷。
●确保软件不做不必要的事情。
●确保系统合理地执行。
●明确在系统失败之前可以让系统正常运行到何种程度。
●明确发布给用户的系统中有哪些风险。
1.5.2软件测试的目的
基于不同的立场，存在着两种完全不同的测试目的。
从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。
从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。
Grenford J.Myers曾对软件测试的目的提出过以下观点：
●测试是为了发现程序中的错误而执行程序的过程；
●好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
●成功的测试是发现了至今为止尚未发现的错误的测试。
换言之，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。
如果我们成功地实施了测试，我们就能够发现软件中的错误。
测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。
实施测试收集到的测试结果数据为可靠性分析提供了依据。
测试不能表明软件中不存在错误，它只能说明软件中存在错误。
然而，这种观点指出测试是以查找错误为中心，而不是为了演示软件的正确功能。
但是只从字面意思理解，可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的测试，实际上并非如此！
●测试并不仅仅是为了找出错误。
通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进；
●这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；
●没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
1.5.3软件测试的原则
●应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭；
●测试用例应由测试输入数据和对应的预期输出结果这两部分组成；
●程序员应避免检查自己的程序；
●在设计测试用例时，应包括合理的输入条件和不合理的输入条件；
●充分注意测试中的群集现象。
经验表明测试后程序中残存错误数目与该程序中已发现的错误数目成正比；
●严格执行测试计划，排除测试的随意性；
●应当对每一个测试结果做全面检查；
●妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
1.5.4软件测试的任务
●根据软件测试各个阶段会有如下几方面的任务：
●制定测试大纲；
●制作测试数据；
●单元测试（程序测试）；
●功能测试；
●性能测试；
●集成测试（子系统测试）；
●系统测试；
●验收测试；
●写出测试报告书；
●提交下一阶段工作所需的系统运行、维护手册的草案。
1.5.5软件测试的职责
●根据软件设计需求制定测试计划，设计测试数据和测试用例；
●有效地执行测试用例，提交测试报告；
●准确地定位并跟踪问题，推动问题及时合理地解决；
●完成对产品的集成测试与系统测试，对产品的软件功能、性能及其它方面的测试。
1.6软件测试用例设计
1.6.1软件测试用例的基本概念和用途
学员在学习过程中会遇到以下类似问题：
不知道是否较全面地测试了所有内容，测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率等。
接下来将采用编写测试用例的方法解决以上提及的问题。
测试用例是指为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试用例控制软件测试的执行过程，它是对每个测试项目的进一步实例化。
换句话说，测试用例就是记下要进行什么测试，进行测试的具体步骤，以及测试执行是否正确的标准。
测试用例来自于测试需求，它是对测试需求的一个细化，它是整个测试的基础，测试用例覆盖系统的程度决定了测试的覆盖程度。
如果没有测试用例，就只能按照测试人员的心情进行测试了。
测试用例的编写是个费时费力的事情，通常编写测试用例的时间比实际执行测试的时间还要长。
许多人对编写测试用例的原因很不理解，他们认为功能测试只要对应着的需求或者程序的菜单一项项地去测试就可以了，这样写来写去很浪费时间，而且有没有什么实际意义，不如多花时间去执行测试。
其实编写测试用例的好处主要表现在以下几个方面：
●组织性：
编写测试用例有利于测试的组织。
在开始实施测试之前设计好测试用例。
可以避免盲目测试，并可以提高测试效率。
●功能覆盖：
测试用例可以确保功能不被遗漏。
要确保所开发的软件能让最终用户满意，最好的办法
升级会员 