软件测试理论

软件的特点：具有抽象性的逻辑实体运行和使用没有磨损和老化问题，但在修改维护中存在失效率升高，退化开发和运行依赖计算机系统：硬件要求，操作系统要求，可移植性方面的质量需求手工开发，很难依靠新技术利用现成的部件组装成所需软件复杂性：实际问题复杂，程序逻辑结构复杂，涉及相关领域的专业知识，软件技术发展落后于需求成本昂贵，作用在不断提升分类：功能--系统+支持+应用规模：小5人6-12月，中5-10012月大100以上1年以上mistake错误：人为的产生不正确结果的行为defect缺陷：可能会导致组件或者系统无法执行其定义的功能的瑕疵failure失效：组件或系统与期望的交付、服务或结果存在的偏差，是缺陷的外部反映程序员犯了一个错误--在代码或软件中表现为缺陷--运行存在缺陷的代码或软件就可能引起失效动态测试发现的是失效，静态测试可以发现缺陷软件产品的质量特性：功能性，可靠性，易用性，效率，可维护性，可移植性使用质量：有效性，生产率，安全性，满意度（基于用户观点）软件测试的主要阶段：测试计划和控制测试分析和设计测试实现和执行评估出口准则和报告测试结束活动实际项目测试中的出口准则：当计划的测试时间用尽的时候当继续测试没有发现新的缺陷的时候当所有的测试用例执行完毕时当测试的成本大于收益时当达到所要求的测试覆盖率的时候当所有发现的缺陷都已经被清除的时候测试目的：发现缺陷，增加对质量的信心，为决策提供信息和预防缺陷软件测试是对软件开发过程中的所有工作产品包括程序及相关文档进行的测试，而不仅仅是通过运行程序来进行的动态测试动态测试：通过运行被测对象来进行静态测试：不需要运行被测对象，其测试对象是开发过程中生成的各类工作产品，包括需求文档，设计文档，代码等主要由评审和动态分析组成验证verification:通过检查和提供客观证据来证实指定的需求是否满足是否在正确构建产品关注构建过程，针对开发过程中的单个阶段确认validation：通过检查和提供客观证据来证实软件产品的特定目的的功能或应用是否已经实现是否构建了正确的产品关注的已构建的软件产品根据原始需求检查各阶段开发结果的过程测试test：目的是发现缺陷人员：测试人员，开发人员方法：由已知条件开始，有期望的结果可以计划，工作进度可以度量对象包括软件开发过程中的所有产品，各种文档、数据及代码可以发现由于软件存在的缺陷而引起的失效调试debug：目的是定位缺陷并修改人员：开发人员方法：由未知条件开始，结果难以预测过程或者时间相对难以计划用来识别引起失效的原因和采取解决方案来修正缺陷测试基本原则：穷尽测试是不可能的，无法发现被测对象所有的缺陷goodenough测试只能显示缺陷的存在，不能证明软件完全正确，不存在缺陷测试应该尽早的介入提高质量，降低开发成本缺陷具有集群效应，符合帕累托原则，需要重点关注缺陷较多的模块或者程序段杀虫剂效应：重复执行相同的测试用例，其发现缺陷的能力会越来越差因此需要经常进行用例的评审和修改测试活动依赖于上下文不同的软件系统需要选择不同的测试依赖于运行环境和使用中的风险没有失效不代表系统是可用的满足客户真正的需要才是成功的充分了解需求测试的基本过程：测试计划和控制：指导方针出入口准则，决定，监控（识别测试对象，目的，范围）测试分析和设计：识别具体的测试需求，并依据需求设计相应的测试用例，规划环境搭建，需要的基础设施和工具测试实现和执行：创建测试数据，执行用例，确认测试和回归测试评估出口准则和测试报告：数据分析，出口依据提交报告，包括所有数据测试结束活动：经验教训总结，过程改进建议，归档过程中的各项产品测试模型：瀑布模型：能否正确理解客户需求，且需求在开发过程中是否会经常变更测试作为软件开发的一个组成部分V模型：开发任务和测试任务是相互对等的活动且同等重要测试分级：单元测试：系统最小组件，保证能够正常运行，满足详细设计说明的要求黑盒+白盒功能+特定的非功能测试驱动开发集成测试：为暴露接口已经集成单元或集成系统之间交互时存在的缺陷而进行是否能按需求协同工作，接口是否正确组件集成、系统集成--关注集成本身（接口）通信，数据传递--适合动态测试包括功能测试和非功能性测试集成策略：自底向上--驱动模块自顶向下--桩模块核心系统先集成按组件完成时间集成系统测试：检查整个系统是否满足指定的需求功能是否实现，非功能的质量特性是否满足设计要求两者都是顺序模型，使用前提都是软件系统是否具备完善明确的需求增量迭代模型：需求不断变化，持续集成，早期迭代，实现重用，不断改进开发过程，充分利用项目人力资源螺旋模型：多次风险分析风险驱动可以演化为原型开发或者瀑布模型RUP：最佳实践四阶段：初始精化构建产品化敏捷开发：极限编程xp看板scrum功能驱动开发featuredrivendevelopment动态系统开发关注个体和交互可用软件胜过全面文档验收测试:对系统功能、系统某部分或者特定的系统非功能特性进行测试。发现缺陷不是主要目标，评估系统是否可以发布及用户对系统使用的准备情况确认测试：确认缺陷是否已经修改回归测试：变更是否会引入新的缺陷--零回归，部分回归（关联部分，高优先级的用例），全部回归各阶段测试，各类型测试通用功能测试：对系统或组件功能说明的分析而进行的测试系统能做什么?主要通过观察输入输出，考虑系统外部表现行为适用黑盒测试分类：适用性，准确性，互确认性，安全性测试界面测试，业务逻辑测试，兼容测试，易用性测试，安装测试非功能测试：特征，行为表现黑盒测试可靠性，易用性，效率，可维护性，可移植性（性能测试：负载，压力，容量，并发，配置，可靠性，冒烟，随机）结构测试：通过分析组件或系统的内部结构而进行的测试白盒测试覆盖率语句条件判定维护测试：在现有的运行系统上进行，对系统进行修改，移植或者退役处理时需要进行静态测试：通过人工检查-评审，或者自动化分析-静态分析对代码或者其他的项目文档进行检查，而不需要运行代码基本思想是预防缺陷，可以发现缺陷，而不是失效更容易发现：与标准之前的偏差，需求的遗漏和错误，设计的缺陷，软件可维护性差，错误的结构说明发现文档的问题，减少由于错误的文档造成的缺陷避免影响动态测试本身的质量评审：计划-预备会：向评审员介绍相关内容-评审员个人准备-会议管理者：决策主持人：负责文档或文档集的评审工作，收集评审数据和发布评审报告，协调评审员的不同观点作者：使评审对象满足评审出入口准则创建，修改评审员：标示和描述被评审对象存在的缺陷项目测试文档是用来记录，描述，展示测试过程中国的一系列测试细信息的处理过程，通过过过书面或者图示的形式对项目测试活动过程或者结果进行描述、定义及报告。伴随测试的各个阶段逐渐充实完善，记录整个测试的过程和成果。作用：有助于项目测试水平的提高驱动着测试过程软件测试计划：在软件测试工作正式实施之前明确测试的对象，并通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，确保软件测试的有效实施。基本结构：计划的简介项目说明需要测试的项目清单测试手段和策略项目通过或失败的标准暂停或重启测试的标准测试的可交付性—产物测试任务需求：环境人员及培训时间进度安排风险及偶然事故的预测缺陷：不满足用户确定需求再现与优化缺陷有效记录：保证重现缺陷使用最少步骤重现（节约时间，便于准确定位）包含所有必要步骤方便阅读，尽量简单独立，一个缺陷一个报告客观描述，对事不对人缺陷报告的用途：记录分类（分配解决所需资源）跟踪分类方式：功能严重程度-影响进度，死机，功能问题，界面问题，建议修复优先级—应立即处理，发布前必须处理，时间有序才处理，发布版本可以存在处理流程：提交——分配——处理——返测——关闭