《软件测试理论基础资料》由会员分享，可在线阅读，更多相关《软件测试理论基础资料（60页珍藏版）》请在金锄头文库上搜索。
1、2018,软件测试理论基础,汇报人： 汇报时间：2018年1月,(一)绪论,(1) 测试用例及测试用例的设计,(3) 软件质量的保证和软件测试,(2) 软件测试的方法,(4) 大量软件的测试策略,回顾,什么是软件测试 软件测试的正反两面性 验证软件 发现缺陷 V&V 软件测试和开发的关系 TDD,1.测试用例的引进及其测试用例的使用,2.1测试用例及测试用例的设计,2.测试用例的规范要求,3.测试用例的模板,第2章 软件测试的基本概念,软件测试计划试用例的引进,软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。 测试工作的实施：编制符合标
2、准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动,测试工作流程,测试计划内容,目标和范围 项目估算 风险计划 进度安排 资源配置 跟踪和控制机制,测试用例的引进,测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例（Test Case）是将软件测试的行为活动做一科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。,
3、测试用例的规范要求,一个好的用例的表述要点，即用例中应当包含的信息 一个优秀的测试用例，应该包含以下信息： 1） 软件或项目的名称 2） 软件或项目的版本（内部版本号） 3） 功能模块名 4） 测试用例的简单描述，即该用例执行的目的或方法 5） 测试用例的参考信息（便于跟踪和参考） 6） 本测试用例与其他测试用例间的依赖关系 7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限 8） 用例的编号（ID），如可以是软件名称简写-功能块简写-NO.。 9） 步骤号、操作步骤描述、测试数据描述 10) 预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略） 1
4、1）开发人员（必须有）和测试人员（可有可无） 12）测试执行日期,测试用例的模板,测试用例的优点,测试用例是测试人员在测试过程中的重要参考依据 测试用例将有助于节约测试时间，提高测试效率。 良好的测试用例不断地被重复使用，使得测试过程事半功倍 测试用例是一个知识积累的过程,软件测试的方法,不同的分类,按测试的对象或范围分类，如单元测试、文档测试、系统测试等） 按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等 根据测试过程中被测软件是否被执行，分为静态测试和动态测试 根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试,静态测试和动态测
5、试,静态测试和动态测试,将需求和设计的评审纳入测试的范畴，可看作是广义测试 静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等 静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析 动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。,产品评审,通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。 评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一
6、致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。,评审的形式和方法,互为评审 (Peer review) 轮查 (Pass-round) 走查 (walk-through) 会议评审 (Inspection),评审分类,管理评审 技术评审 文档评审 流程评审,需求和设计审查,测试人员参与产品需求分析和系统设计，认真阅读有关文档，真正理解客户的需求和技术上的设计，检查需求说明书对产品描述的准确性、一致性等，检查系统设计的合理性和可测试性等,静态分析,人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。 计算机辅助静态分析：利
7、用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。,验证和确认,Verification：Are we building the product right？ 是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性 Validation： Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求,主动测试和被动测试,主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱
8、动被测试对象的行为，从而验证被测试对象的反应或输出结果 被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据.,黑盒测试方法和白盒测试,功能测试 数据驱动测试,结构测试 逻辑驱动测试,黑盒测试方法和白盒测试,一个微软测试工程师的一天,产品编译必须在此之前完成 每日凌晨3时，测试编译自动开始 如果测试编译成功，BVT测试自动开始 测试工程师每早来上班，先检查Test Build与BVT结果的email 如果有BVT错误，在第一时间里分析原因，隔离错误代码并汇报Pri 0 Bug (0级缺陷) 开发团队对于Pri 0
9、 Bug应当于当日之内修改完毕 测试工程师接着用Product Studio检查Bug情况，验证分配给自己的Bug已修改合格,一个微软测试工程师的一天(续),关闭Bug并增加针对此Bug的Regression Test 验证最近的Lab Run结果 如果其中有新的错误，隔离并汇报新Bug 开发新的测试Spec与新的测试代码 使用个人Private Run来验证新开发的测试程序 使用个人Private Run来验证开发伙伴新开发的产品程序没有重大错误 改进与提高自动化测试系统的功能 参与Spec, Test Spec Review会议，做测试同伴测试代码Review, UE帮助文件Review,
10、 回答内外Newsgroup的问题,软件缺陷的定义,Any problem/disfigurement/limitation in product design & development Feature or function cant work Unreasonable design Partly realization in function Data error Run error Limitation in features Difference between actual results and expected results Unfriendly UI, Low perfor
11、mance Others,任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求,软件缺陷的定义,缺点（defect） 偏差 （variance） 谬误（fault） 失败 （failure） 问题（problem） 矛盾（inconsistency） 错误（error ） 毛病 （incident ） 异常（anomy）,软件缺陷,IEEE (1983) 729 软件缺陷一个标准的定义： 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。,ISO 29119 (1) a flaw in a c
12、omponent or system that can cause it to fail to perform its required function. (2) any condition that deviates from expectation based on requirements specifications, design documents, NOTE Defects may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software
13、products or applicable documentation,软件缺陷,功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观,软件缺陷的产生,技术问题 算法错误，语法错误，计算和精度问题，接口参数传递不匹配 团队工作 沟通不充分，误解 软件本身 文档错误、用户使用场合(user scenario)， 时间上不协调、或不一致性所带来的问题 系统的自我恢复或数据的异地备份、灾难性恢复等问题,软件缺陷的构成,在真正的程序测试之前，通过审查、评审
14、会可以发现更多的缺陷。 规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现,缺陷成本,什么是质量?,软件质量的内涵,IEEE： 质量是系统、部件或过程满足 明确需求 客户或用户需要或期望的程度不同 软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492) 软件质量：软件产品满足 使用要求的程度,软件质量的内涵,为了能够在产品发布前，对产品质量能够做出比较准确的判断，需要清楚质量的属性，这就需要建立质量模型产品质量 质量模型: McCall 模型, Boehm 模型, ISO 9126 模型 过程质量: 软件能力成
15、熟度模型 CMM ( Capability Maturity Model). 国际标准过程模型 ISO 9000 软件过程改进和能力决断 SPICE ( Software Process Improvement and Capability dEtermination) 在商业过程中有关的质量内容: 培训、成品制作、宣传、发布日起、客户、风险、成本、业务等 (,产品质量的标准,- 功能性 Functionality - 可用性 Usability - 可靠性 Reliability - 性能 Performance - 容量 Capacity - 可伸缩性 Scalability - 可维护性
16、 Service manageability - 兼容性 Compatibility - 可扩展性 Extensibility,非功能特性,软件质量特征 (ISO 9126),功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。 效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 可维护：与进行指定的修改所需的努力有关的一组属性。 可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。,ISO 9126软件质量三层模型,Boehm软件质量模型,产品操作,产品修改,产品维护,ISO/IEC 9126-1991 被分为两个标
