软件测试基础

第一课时

软件测试基础

目录软件测试的定义软件测试的目的软件测试的原则软件测试的对象软件测试的分类软件的生命周期软件测试的流程软件测试的定义软件？软件测试的定义软件是计算机系统中与硬件相互依存的一部分，包括程序、数据、与其相关文档的完整结合。

软件=程序+数据+文档。软件测试的定义软件测试就是为了证明程序有错，而不是证明程序无错误(辨证观点)。测试被定义为“对软件系统中潜在的各种风险进行评估的活动”。(风险观点)软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试V&V。(标准观点)软件测试的定义软件测试就是为了发现错误而执行程序的过程(狭义观点)。使用人工或自动的手段，来运行或测试软件系统的过程，目的是检验软件系统是否满足规定的需求，并找出与预期结果之间的差异。(标准定义IEEE)软件测试的定义验证：是为确定某一开发阶段的产品是否满足在该阶段开始时提出的要求而对系统或部件进行评估的过程。

确认：是在开发过程中或结束时，对系统或部件进行评估，以确定其是否满足需求规格的过程。综上所述，要完整理解软件测试，就要从不同方面去审视软件测试，概括起来，软件测试就是贯穿整个软件开发生命周期，对软件产品（包括阶段性产品）进行验证和确认的活动过程。软件测试的目的用户角度：通过软件测试发现隐藏的错误和缺陷，考虑是否可以接受该产品。软件开发者：表明软件产品不存在错误，验证软件实现了所有用户的需求。测试人员：发现软件中的缺陷、降低软件出错风险、保证产品质量。测试的最终目的：尽快尽早地发现在软件中的缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。软件测试的原则所有的测试都应追溯到用户需求。程序员应当避免测试自己编写的程序应当彻底检查每个测试的执行结果。避免测试的随意性，有严格的测试计划。穷举测试是不可能的，应终止测试。软件测试的原则设计测试用例时，应该考虑各种情况。充分注意群集现象（二八定理）。对测试出的错误结果一定要有一个确认的过程。程序修改后要回归测试。应避免测试用例用后即弃，妥善保存一切测试过程文档。软件测试的原则

小结软件测试是为发现错误而执行程序的过程。尽量避免编码人员测试自己的程序。好的测试用例能够对未发现的错误高度敏感。成功的测试用例能够发现未知的错误。成功的测试需要仔细定义输入输出的期望值。成功的测试需要仔细研究分析测试结果。软件测试的对象相符吗？用户要求用户：我要什么？运行结果计算机：程序运行得到的结果源程序程序员：我要让计算机怎么做设计说明书设计员：我要让软件做什么？

需求说明书分析员：我可以提供什么？

⑤运行正确性输入正确性

④理解正确性编码正确性

③

②

①理解正确性设计正确性表达正确性理解正确性表达正确性软件测试的分类单元测试集成测试系统测试验收测试概念又称模块测试，就是对软件中的最小可测试单元进行检查和验证在单元测试基础上的，将所有模块按照概要设计要求组装成子系统或系统后的测试，重点测试不同模块的接口部分将整个软件系统看做一个整体进行测试，包括对功能、性能以及软件所运行的软硬件环境进行测试旨在向未来的用户展示该软件系统已能满足其需求要求测试对象最小模块，如函数类等模块间的接口，如参数传递整个系统，包括软硬件整个系统，包括软硬件测试时机编码之后，代码已经通过编译之后在单元测试之后集成测试之后系统测试后期，软件正式交付用户使用之前测试人员白盒测试工程师或开发人员白盒测试工程师或开发人员黑盒测试工程师用户和黑盒测试工程师测试依据1、源程序本身，包括代码和注释2、详细设计文档1、单元测试的模块2、概要设计文档需求规格说明书需求规格说明书测试通过标准1、单元测试用例的执行率为100%，通过率为95%2、语句的覆盖率达100%3、分支的覆盖率达85%1、各个单元模块结合到一起能够协同配合，正常运行2、测试用例的执行率为100%，通过率为95%1、系统功能、性能等满足需求规格说明书中的要求2、测试用例的执行率为100%，通过率为95%1、系统功能、性能等满足需求规格说明书中的要求2、测试用例的执行率为100%，通过率为95%主要方法控制流测试、数据流测试、排错测试、分域测试等自顶向下测试、自底向上测试功能测试、性能测试、随机测试等Alpha测试、Beta测试静态测试：不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。静态测试具有的发现缺陷早、降低返工成本、覆盖重点和发现缺陷的概率高的优点以及耗时长、不能测试依赖和技术能力要求高的缺点。

动态测试：实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。测试阶段静态测试动态测试可行性评审√需求评审√设计评审√单元测试√集成测试√系统测试√验收测试√黑盒测试白盒测试概念又称为功能测试或数据驱动测试。它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。又称结构测试或逻辑驱动测试。它是知道产品内部工作过程，可通过测试来检测产品内部工作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。测试人员黑盒测试工程师或用户白盒测试工程师或开发人员测试依据需求规格说明书1、源程序本身，包括代码和注释2、详细设计文档主要方法等价类划分、边界值分析、因果图、错误推测等逻辑覆盖、循环覆盖和基本路径测试应用软件确认测试软件验证测试功能测试：主要检查实际软件的功能是否符合用户

的需求。功能测试又可细分为：逻辑功能测试：假设一个软件的业务流程是，如果

输入1就走A流程，输入2，走B流程，

输入3，退出。那对于测试人员来

说，输入1到3就是不同的逻辑，你

也可以输入0，4，来检验程序是否

有做保护处理。

界面测试：验证软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息等方面的测试。易用性测试：从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。安装测试：是验证软件能否正常进行安装和卸载的测试。兼容性测试：是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。包括向上兼容、向下兼容，软件兼容和硬件兼容。性能测试：主要是验证系统的性能指标是否满足需求要求。性能测试又可细分为：一般性测试：指的是让被测系统在正常的软硬件条件下运行，不向其施加任何压力。稳定性测试：也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。负载测试：指让被测系统在其能忍受的压力的极限范围内连续运行，检查系统运行时的稳定性。压力测试：通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。回归测试：是在软件维护阶段，重复执行上一个版本测试时的测试用例，对修改后的新版本进行的测试。其目的是检验对软件所做的修改是否正确。冒烟测试：是指在对一个新版本进行系统的大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。软件的生命周期软件生命周期：即一个软件从功能确定、设计、开

发成功、投入使用，并在使用中不断的修改、增补和完善，直至被新的替代而停止使用的全过程。软件生命周期包括软件开发的生命周期和软件测试的生命周期。软件测试的流程立项需求评审测试计划测试设计测试前期准备测试执行测试记录缺陷管理软件评估Passed测试项目总结维护测试NY需求评审需求评审的注意事项：一、注意对需求规格说明的正确性进行评审

1、是否冲突或者重复

2、是否清晰、简洁、无二义性

3、是否有内容和语法错误

4、是否合理地确定了性能指标

5、是否合理地确定了安全性指标需求评审二、注意对需求规格说明的完整性进行评审

1、是否包含了所有已知的客户需求或系统需求

2、所有需求的详细程度是否合适，是否能为设计提供足够的基础

3、是否定义了每个需求的实现优先级

4、是否把不确定的需求标记为待确定的问题，而不是直接遗弃

5、是否对所有预期的错误条件所产生的系统行为都进行了描述需求评审三、注意对需求的可实施性进行评审

1、是否每个需求都有惟一标识

2、是否每个需求都易修改，可跟踪

3、是否每个需求都是实际的、量化的、逻辑清晰的

4、在现有的资源下,是否能实现所有的需求

5、每个需求在特定的输入条件下是否给出已知的输出结果需求评审测试人员参加“需求评审”活动需要达到的目标：

1、充分理解用户需求

2、确保需求的可测试性测试计划为什么要编写测试计划

1）领导能够根据测试计划做宏观调控，进行相应资源配置等

2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等

3）便于其他人员了解测试人员的工作内容，进行有关配合工作

测试计划什么时间开始编写测试计划尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写由谁编写测试计划具有丰富经验的测试负责人测试计划测试计划编写策略

1.明确测试的目标，增强测试计划的实用性

2.坚持“5W1H”规则，明确内容与过程

1)why—为什么要进行这些测试

2)what—测试哪些方面，不同阶段的工作内容

3)who—安排哪些测试人员进行测试

4)when—测试不同阶段的起止时间

5)where—给出测试文档和软件的存放位置，测试环境等

6)how—指出测试的方法和工具

3.采用评审和更新机制，保证测试计划满足实际需求

4.分别创建测试计划与测试详细规格、测试用例

测试设计测试设计测试用例

是为某个特殊目标而编制的一组测试输入、执行条件、测试步骤以及预期结果。为什么要写测试用例1）便于团队交流2）便于重复测试3）便于跟踪统计