软件评测师 精简讲义

 

一、考试说明

 

1.考试要求

（1）熟悉计算机基础知识；

（2）熟悉操作系统、数据库、中间件、程序设计语言基础知识；

（3）熟悉计算机网络基础知识；

（4）熟悉软件工程知识，理解软件开发方法及过程；

（5）熟悉软件质量及软件质量管理基础知识；

（6）熟悉软件测试标准；

（7）掌握软件测试技术及方法；

（8）掌握软件测试项目管理知识；

（9）掌握C语言及C++或Java语言程序设计技术；

（10）了解信息化及信息安全基础知识；

（11）熟悉知识产权相关法律、法规；

（12）正确阅读并理解相关领域的英文资料。

 

2.通过本考试的合格人员能在掌握软件工程与软件测试知识基础上，运用软件测试管理办法、软件测试策略、软件测试技术，独立承担软件测试项目；具有工程师的实际工作能力和业务水平。

 

3.本考试设置的科目包括：

（1）软件工程与软件测试基础知识，考试时间为150分钟，笔试，选择题；

（2）软件测试应用技术，考试时间为150分钟，笔试，问答题。

 

 

 

 

 

 

 

 

二、考试范围

考试科目1：软件工程与软件测试基础知识

 

1.计算机系统基础知识

1.1 计算机系统构成及硬件基础知识

 

·计算机系统的构成

 

·处理机

 

·基本输入输出设备

 

·存储系统

 

1.2 操作系统基础知识

 

·操作系统的中断控制、进程管理、线程管理

 

·处理机管理、存储管理、设备管理、文件管理、作业管理

 

·网络操作系统和嵌入式操作系统基础知识

 

·操作系统的配置

 

1.3 数据库基础知识

 

·数据库基本原理

 

·数据库管理系统的功能和特征

 

·数据库语言与编程

 

1.4 中间件基础知识

 

1.5 计算机网络基础知识

 

·网络分类、体系结构与网络协议

 

·常用网络设备

 

·Internet基础知识及其应用

 

·网络管理

 

1.6 程序设计语言知识

 

·汇编、编译、解释系统的基础知识

 

·程序设计语言的基本成分（数据、运算、控制和传输、过程（函数）调用）

 

·面向对象程序设计

 

·各类程序设计语言的主要特点和适用情况

 

·C语言以及C++（或Java）语言程序设计基础知识

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.标准化基础知识

 

·标准化的概念（标准化的意义、标准化的发展、标准化机构）

 

·标准的层次（国际标准、国家标准、行业标准、企业标准）

 

·标准的类别及生命周期

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.信息安全知识

 

·信息安全基本概念

 

·计算机病毒及防范

 

·网络入侵手段及防范

 

·加密与解密机制

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.信息化基础知识

 

·信息化相关概念

 

·与知识产权相关的法律、法规

 

·信息网络系统、信息应用系统、信息资源系统基础知识

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.软件工程知识

 

5.1 软件工程基础

 

·软件工程概念

 

·需求分析

 

·软件系统设计

 

·软件组件设计

 

·软件编码

 

·软件测试

 

·软件维护

 

5.2 软件开发方法及过程

 

·结构化开发方法

 

·面向对象开发方法

 

·瀑布模型

 

·快速原型模型

 

·螺旋模型

 

5.3 软件质量管理

 

·软件质量及软件质量管理概念

 

·软件质量管理体系

 

·软件质量管理的目标、内容、方法和技术

 

5.4 软件过程管理

 

·软件过程管理概念

 

·软件过程改进

 

·软件能力成熟度模型

 

5.5 软件配置管理

 

·软件配置管理的意义

 

·软件配置管理的过程、方法和技术

 

5.6软件开发风险基础知识

 

·风险管理

 

·风险防范及应对

 

5.7 软件工程有关的标准

 

·软件工程术语

 

·计算机软件开发规范

 

·计算机软件产品开发文件编制指南

 

·计算机软件需求规范说明编制指南

 

·计算机软件测试文件编制规范

 

·计算机软件配置管理计划规范

 

·计算机软件质量保证计划规范

 

·数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6.软件评测师职业素质要求

 

·软件评测师职业特点与岗位职责

 

·软件评测师行为准则与职业道德要求

 

·软件评测师的能力要求

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.软件评测知识

²        7.1 软件测试基本概念

²        软件质量与软件测试

Ø         质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量。

Ø         软件测试：测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程产物以及开发出的软件进行剖析。

²        软件测试定义

Ø         软件测试：在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。

²        软件测试目的

Ø         软件测试目的：测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。

²        软件测试原则

Ø         所有的软件测试都应追溯到用户需求。

Ø         应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

Ø         完全测试是不可能的，测试需要终止。

Ø         测试无法显示软件潜在的缺陷。

Ø         充分注意测试中的群集现象。

Ø         程序员应避免检查自己的程序。

Ø         尽量避免测试的随意性。

²        软件测试对象

Ø         软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。

Ø        

²        7.2 软件测试过程模型

²        ·V模型

Ø         V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从坐到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

²        ·W模型

Ø         W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样需要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于进早的发现问题。这样做，使测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。

²        ·H模型

Ø         H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型揭示了：软件测试不仅仅指测试的执行，还包括很多其他的活动；软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行；软件测试要尽早准备，尽早执行；软件测试是根据被测物的不同而分层次进行的，不同层次的测试活动可以按照某个次序先后进行的，但也肯可能是反复的。

 

²        ·测试模型的使用

Ø         V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门针对软件测试的流程予以说明。H模型表现为测试是独立的，只要测试前提具备了，就可以开始进行测试，软件测试逐步发展成为一个独立于软件开发部的组织，就每一个软件城市的细节而言，它都有一个独立的操作流程。

²        7.3 软件测试类型

²        单元测试、集成测试、系统测试

Ø         单元测试：单元测试又称模块测试，是针对软件设计的最小单元——程序模块进行正确性检验的测试工作。主要检查模块功能、性能、接口和设计约束等要求，需要从内部结构出发设计测试用例。

Ø         集成测试：集成测试也叫做组装测试。通常在单元才而是的基础上，将所有的程序模块进行有序的、递增的测试。检验程序单元的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

Ø         系统测试：系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。是在真实或模拟系统运行环境下检查完整的程序系统能否和系统正确配置连接，满足需求。

²        确认测试、验收测试

Ø         确认测试：确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检验与证实软件是否满足软件需求说明书中规定的要求。

Ø         验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审。

²        开发方测试、用户测试、第三方测试

Ø         开发方测试：通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。是开发完成后，开发方对要提交的软件进行全面的自我检查与验证。

Ø         用户测试：在用户的应用环境下，用户通过运行和使用软件，检测与核实软件是否符合自己预期的要求。“β测试”通常被看成是一种“用户测试”，把产品有计划的免费发放的目标市场，让用户大量使用，并评价、检查软件且把软件存在的问题与错误信息反馈给开发者修改。

Ø         第三方测试：介于软件开发方和用户之件的测试组织的测试。第三方测试也称为独立测试。也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行软件测试。

²        动态测试、静态测试

Ø         动态测试：是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

Ø         静态测试：是指不运行程序，通过人工对程序和文档进行分析和检查。包括走查、符号执行等。

²        白盒测试、黑盒测试、灰盒测试

Ø         白盒测试：通过对程序内部结构的分析、检测来寻找问题。检查是够所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

Ø         黑盒测试：通过软件的外部表现来发现其缺陷和错误。不考虑程序内部结构和处理过程。在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。

Ø         灰盒测试：介于白盒测试与黑盒测试之间的测试。它关注输出对于输入的正确性；也关注内部表，但这种关注不像白盒测试那样详细、完整，只是通过表征性的现象、事件、标志来判断内部状态。

²        7.4 软件问题分类

²        软件错误

Ø         在预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿真人的直接或间接的干预。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。软件错误是一种人为过程，相对于软件本身，是一种外部行为。

²        软件缺陷

Ø         软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

²        软件故障

Ø         软件故障是指软件运行中出现的一种不希望或不可接受的内部状态。它是一种动态行为。

²        软件失效

Ø         软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

 

²        7.5 测试标准

 

 

²        7.5.1 GB/T 16260.1 – 2003 软件工程 产品质量 第1部分：质量模型

 

 

²        7.5.2 GB/T 18905.1 – 2002 软件工程 产品评价 第1部分：概述

 

 

²        7.5.3 GB/T 18905.5 – 2002 软件工程 产品评价 第5部分：评价者用的过程

 

 

²        8.软件评测现状与发展

 

 

²        国内外现状

 

 

²        软件评测发展趋势

 

 

²        9.专业英语

 

 

²        正确阅读并理解相关领域的英文资料

 

 

 

 

 

 

 

 

 

 

 

 

²      考试科目2：软件测试应用技术

²        1.软件生命周期测试策略

²        1.1设计阶段的评审

Ø        

²        需求评审

Ø         在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调主单位完成需求说明书的评审确认。

Ø         编制良好的需求说明书8条原则：1）功能与实现分离，即描述要“做什么”而不是“怎样实现”；2）要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明；3）如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中，并描述该目标软件与系统的其他元素交互的方式；4）规格说明必须包括系统运行的环境；5）系统规格说明必须是一个认识的模型，而不是设计或实现的模型；6）规格说明必须是可操作，且必须是充分完全和形式的，以便能够利用它决定对于任意给顶的测试用例；7）规格说明必须容许不完备性并允许扩充；8）规格说明必须局部化和松散的耦合。

Ø         评测范围：清晰性、完整性、依从性、一致性、可行性和可管理性。

²        设计评审

Ø         概要设计的评测范围：清晰性、完整性、依从性、一致性、可行性、数据使用、接口、可维护性、可靠性、易测性、可追溯性。

Ø         详细设计的评测范围：清晰性、完整性、依从性、一致性、正确性、数据使用、接口、可维护性、性能、可靠性、易测性、可追溯性。

 

²        ·测试计划与设计

 

 

²        1.2开发与运行阶段的测试

²        单元测试

Ø         单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

Ø         进行单元测试需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。要求对所有局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

Ø         单元测试需要在五个方面对所有模块进行检查：模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试。

Ø         驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测试模块，最后再输出实测结果。

Ø         桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。

²        集成测试

Ø         集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

Ø         组装时需要考虑的问题：1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2）一个模块的功能是否会对另一个模块的功能产生不利的影响；3）各个子功能组合起来，能否达到预期要求的父功能；4）全局数据结构是否有问题；5）单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

Ø         一次性组装方式：它是一种非增殖式组装方式，也叫整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。

Ø         增殖性组装方式：这种方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。一共有自顶向下的增殖方式、自顶向上的增殖方式和混合增殖式测试。

²        系统（确认）测试

Ø         确认测试的任务是验证软件的功能和性能及其他性能是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。

Ø         进行有效性测试是在模拟环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。

Ø         软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。

Ø         系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或则模拟运行（使用）环境下，对计算机进行一系列测试。系统测试的目的在于通过与系统的需求定义作比较，发现不符合的地方。

²        验收测试

Ø         验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。

Ø         验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

²        2.测试用例设计方法

²        2.1白盒测试设计

²        白盒测试基本技术

Ø         词法分析与语法分析：通过词法分析可以获取软件组成的重要基本因数。

u       如变量标识符、过程标识符、常量等，组合这些基本因数可以得到软件的基本信息：标号交叉引用表、变量交叉引用表（变量定义与应用表）、子程序与宏和函数表、等价表、常数表。

u       按功能分类，引用表的作用有：直接从表中查出说明/使用错误；为用户提供辅助信息；用来做错误预测和程序复杂度计算。

Ø         静态错误分析：静态错误分析用于确定在源程序中是否有某类错误或“危险”结构。

u       类型和单位分析：为了强化对源程序中数据类型的检查，在程序设计语言中扩充一些新的数据类型。

u       引用分析：沿着程序的控制路径，变量在赋值以前被引用，或变量在赋值以后未被引用，这时就发生了引用异常，通常采用类似深度有限的方法遍历程序流图的每一条路径。

u       表达式分析：

u       接口分析：是程序的静态错误分析和设计分析，接口的一致性的设计可以分析检查模块之间接口的一致性和模块与外部数据库之间接口的一致性。

Ø         程序插桩技术：程序插桩是一种基本的测试手段，有着广泛的应用。是借助往被测程序中插入操作，来实现测试目的的方法。

²        白盒测试方法

Ø         代码检查法

u       代码检查方式：桌面检查、代码审查、走查。

u       代码检查项目：检查变量的交叉引用表，检查标号的交叉引用表，检查子程序、宏、函数，等价性检查，常量检查，标准检查，风格检查，比较控制流，选择、激活路径，对照程序的规格说明，补充文档。

u       编码规范：排版，注释，标识符命名，可读性，变量，函数、过程，可测性，程序效率，质量保证，代码编辑、编译、审查，代码测试、维护，宏。

u       代码检查规则：根据编程语言以及被测程序的特点，挑选适当的规则进行检查。

u       缺陷检查表：格式部分，入口和出口的连接，程序语言的使用，存储器使用，判断和转移，性能，可维护性，逻辑，可靠性。

Ø         静态结构分析法：

u       程序的结构形式是白盒测试的主要依据。模块控制流图可以直观地反映出一个函数的内部逻辑结构，通过检查这些模块控制流图，能够很快发现软件的错误与缺陷。

Ø         静态质量度量法

u       软件的质量包括：功能性，可靠性，可用性，有效性，可维护性，轻便性。

u       度量规则：质量规则使用了代码行数、注释频度等参数度量软件的各种行为属性。

u       分类标准：软件的可维护性评估，可分析性、可修改性、稳定性、可测性。

Ø         逻辑覆盖法：是通过对程序逻辑结构的遍历实现程序的覆盖。

u       白盒测试的动态测试要根据程序的控制结构设计测试用例：保证一个模块中的所有独立路径至少被使用一次，对所有逻辑值均需测试true和false，在上下边界及可操作范围内运行所有循环，检查内部数据结构以确保其有效性。

u       语句覆盖：选择足够多的测试数据，使被测程序中每条语句至少执行一次。

u       判定覆盖：设计足够的测试用例，使得程序中的每个判定至少获得一次“真值”或“假值”。

u       条件覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。

u       条件判定组合覆盖：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。

u       多条件覆盖：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。

u       修正条件判定覆盖：每个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值至少转换一次；程序的判定被分解为通过逻辑操作符连接的bool条件，每个条件对于判定的结果值是独立的。

Ø         基本路径测试法

u       程序的控制流图

u       程序环路复杂性

u       基本路径测试法步骤：适用于模块的详细设计及源程序。以详细设计或源代码作为基础，导出程序的控制流图；计算得到的控制流图G的环路复杂性V（G）；确定线性无关的路径的基本集；生成测试用例，确保基本路径集中每条路径的执行。

Ø         其他白盒测试方法

u       域测试：“域”是指程序的输入空间。域测试方法基于对输入空间的分析。域测试的问题为对程序提出的限制过多，且当前程序存在路径很多时，所需测试点也就很多。

u       符号测试：语序程序的输入不仅仅是具体的数值数据，而且包括符号值。符号测试存在分支问题、二义性问题、大程序问题。

u       Z路径覆盖：检验程序从入口开始，执行过程中经历的各个语句，直到出口。

u       程序变异：它是一种错误驱动测试，是指该方法是针对某类特定程序错误的。

²        2.2黑盒测试用例设计

²        测试用例设计方法

Ø         等价类划分法：设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分选取少数代表性数据作为测试用例。这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。等价分配的目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。

u       有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。

u       无效等价类：与有效等价类的定义恰巧相反。

Ø         边界值分析法

u       边界条件

u       次边界条件

Ø         错误推测法：例举出程序中国有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

Ø         因果图法：是从自然语言书写的程序规格说明的描述中找出因和果，通过因果图转换为判定表。

Ø         判定表驱动法

u       判定表：条件桩，动作桩，条件项，动作项。

Ø         正交试验法：就是使用已经造好的表格“——”正交表来安排试验并进行数据分析的一种方法。

Ø         功能图法：是用功能图形形象地表示程序的功能说明，并机械地生成功能图的测试用例。一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入与输出条件之间的对应关系。功能图模型由状态迁移图和逻辑功能模型构成。

u       状态迁移图用于表示输入数据序列以及相应的输出数据。

u       功能图由状态迁移图和布尔函数组成。

Ø         场景法：一般软件都是事件触发来控制流程，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。经过用例的每条路径都用基本流和备选流来表示。

²        测试用例的编写

Ø         测试用例计划的目的：以回答整个项目的重要问题，提供了一种正式测试的手段。

Ø         ANSI/IEEE 829测试设计说明：

u       标识符：用于引用和定位测试设计说明的唯一标识符。应包含任何其他测试计划或说明的引用。

u       要测试的特性：对测试设计说明所包含的软件特性的描述。

u       方法：描述测试的通用方法。如果方法在测试计划中列出，就应该在此详细描述要使用的技术，并给出如何验证测试结果的方法。

u       测试用例信息：用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用信息以及用于执行测试用例的测试程序说明。

u       通过/失败规则：描述用什么规则来判定某特性的测试结果是通过还是失败。

Ø         ANSI/IEEE 829测试用例说明：

u       标识符：用于引用和定位测试设计说明的唯一标识符。

u       测试项：描述被测试的详细特征、代码模块等，应该比测试设计说明中所列的特性更加具体。

u       输入说明：该说明列举执行测试用例的所有输入内容或者条件。

u       输出说明：描述进行测试用例预期的结果。

u       环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。

u       特殊要求：描述执行测试必须的特殊要求。

u       用例之间的依赖性：一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。

Ø         ANSI/IEEE 829测试程序说明：

u       标识符：用来把测试程序与相关测试用例和测试设计相联系的唯一标识。

u       目的：本程序描述的目的以及将要执行的测试用例的引用信息。

u       特殊要求：执行测试所需的其他程序、特殊测试技术或者特殊设备。

u       程序步骤：1）日志；2）设置；3）启动；4）程序；5）衡量标准；6）关闭；7）终止；8）重置；9）偶然事件。

 

²        2.3面向对象测试用例设计

Ø         传统测试用例设计是由软件的输入-加工-输出视图或个体模块的算法细节驱动的，而面向对象测试关注于设计合适的操作序列以测试类的状态。

Ø         测试用例的设计方法：对每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系；测试目的应该明确；应当为每个测试用例开发一个测试步骤列表。

Ø         基于故障的测试：系统以满足用户的需求为目的，因此，基于故障的测试要从分析模型开始，考察可能发生的故障。基于故障的测试也可用于集成测试，集成测试可以发现消息联系中“可能的故障”。

Ø         基于场景的测试：主要关注用户需要做什么，而不是产品能做什么，即从用户任务中找出用户要做什么以及如何去执行。

 

 

²        2.4测试方法选择的策略

²        黑盒测试方法选择策略

Ø         首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变为有限测试。

Ø         在任何情况下都必须使用边界值分析方法。

Ø         可以用错误推测法追加一些测试用例。

Ø         对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。

Ø         如果程序的功能说明中喊有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。

Ø         对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

Ø         功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

Ø         对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

²        白盒测试方法选择策略

Ø         在测试中，应尽量先用工具进行静态结构分析。

Ø         测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查和静态质量度量，再进行覆盖率测试。

Ø         利用静态分析的结果作为引导，通过代码检查和动态测试的方式对静态分析结果进行进一步的确认，使城市工作更为有效。

Ø         覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准；对软件的重点模块，应使用覆盖率标准衡量代码的覆盖率。

Ø         在不同的测试阶段，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析、静态质量度量；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。

²        面向对象软件的测试策略

Ø         面向对象分析（OOA）的测试

u       对认定的对象的测试：认定的对象是否全面，是否问题空间中所有涉及到的实例都反映在认定的抽象对象中了；认定的对象市斗具有多个属性，只有一个属性的对象通常应看成其他对象的属性，而不是抽象为独立的对象；对认定为同一对象的实例是否有共同的、区别于其他实例的共同属性；对认定为同一对象的实例是否提供或需要相同的服务，如果服务随着实例的不同而变化，认定的对象就需要分解或利用继承性来分类表示；如果系统没有必要始终保持对象代表的实例信息，提供或者得到关于它的服务、认定的对象也无必要；认定的对象名称应该尽量准确、适用。

u       对认定的结构的测试：认定结构分为两种，分类结构和组装结构。分类结构体现了问题空间中实例的一般与特殊的关系，组装结构体现了问题空间中实例整体与局部的关系。

u       对认定的主题的测试：如果主题超过了7个，就要求对有较密切属性和服务的主题进行归并；主题所反映的一组对象和结构是否具有相同和相近的属性和服务；认定的主题是否是对象和结构更高层的抽象，是否便于理解OOA结果的概貌；主题间的消息联系是否代表了主题所反映的对象和结果之间的所有关联。

u       对定义的属性和实例关联的测试：定义的属性是否对相应的对象和分类结构的每个现实实例都适用；定义的属性在现实世界是够与这种实例关系密切；定义的属性在问题空间是否与这种实例关系密切；定义的属性是否能够不依赖于其他属性被独立理解；定义的属性在分类结构中的位置是否恰当，低层对象的共有属性是否在上层对象属性体现；在问题空间中每个对象的属性是否定义完整；定义的实例关联是否符合现实；在问题空间中实例关联是否定义完整，特别需要注意“一对多”和“多对多”的实例关联。

u       对定义的服务和消息的关联的测试：对象和结构在问题空间的不同状态是否定义了相应的服务；对象或结构所需要的服务是否都定义了相应的消息关联；定义的消息关联所指引的服务提供是否正确；沿着消息关联执行的线程是否合理，是否符合现实过程；定义的服务是否重复，是否定义了能够得到的服务。

Ø         面向对象设计（OOD）的测试：

u       对认定的类的测试：是否函盖了OOA中所认定的对象；是否能体现OOA中定义的属性；是否能实现OOA中定义的服务；是否对应着一个含义明确的数据抽象；是否尽可能少地依赖其他类；类中的方法是否是单用途。

u       对构造的类层次结构的测试：类层次结构是否函盖了所有定义的类；是否能体现OOA中定义的实例关联；是否能实现OOA中所定义的消息关联；子类是否具有父类没有的新特性；子类间的共同特征是否完全在父类中得以体现。

u       对类库支持的测试：一组子类中关于某种含义相同或基于相同的操作，是否有相同的接口；类中方法的功能是否较单纯，相应的代码行是否较少；类的层次结构是否深度大。宽度小的；分析和设计模型表示所使用的符号语法是否正确，语义是否正确，以及类的关联是否正确地反映了真实世界对象间的关联；OOA和OOP（包括分析、设计和编码层次，即类、属性、操作、消息）不仅要正确，而且要一致，用模型内各实体间的关联性来判断，检查每个类及其与其他类的连接。

Ø         面向对象编程（OOP）的测试：

u       数据成员是否满足数据封装的要求：数据封装是数据和数据有关的操作和集合。检查数据成员是否满足数据封装的要求，基本原则是数据成员是否外界直接调用。更直观地说，当改变数据成员的结构时，是否影响了类的对外接口，是否会导致相应的外界必须改动。

u       类是否实现类要求的功能：类所实现的功能都是通过类的成员函数执行的。测试类的功能，不能仅满足于代码能无错的运行或被测试类所提供的功能无错，应该以所做的OOD结果为依据，检测类提供的功能是否满足设计的要求，是否有缺陷。

Ø         面向对象软件的单元测试：一些传统的测试方法在面向对象的单元测试中都可以使用。面向对象编程的特性使得成员函数的测试，不完全等同于传统的函数或过程的测试，尤其是继承特性和多态特性。

Ø         面向对象软件的集成测试：

u       基于线程的测试：集成对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。

u       基于使用的测试：通过测试那些几乎不使用服务器类的类而开始构造系统，在独立类测试完成后，下一层中使用独立类的类被测试。这个依赖类层次的测试序列一直持续到构造完整个系统。

u       设计测试用例：先选定检测的类，参考OOD分析结果，仔细确定出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等；确定覆盖标准；利用结构关系图确定待测类的所有关联；根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态，使用类的服务和期望产生什么行为等。

Ø         面向对象软件的确认和系统测试：测试系统能否满足用户的需要，在真实或模拟环境下进行测试。

 

²        3.软件测试技术与应用

 

 

²        3.1软件自动化测试

 

 

²        ·软件自动化测试基本概念

 

 

²        ·选择自动化测试工具

 

 

²        ·功能自动化测试

 

 

²        ·负载压力自动化测试

 

 

²        3.2面向对象软件的测试

 

 

²        ·面向对象测试模型

 

 

²        ·面向对象分析的测试

 

 

²        ·面向对象设计的测试

 

 

²        ·面向对象编程的测试

 

 

²        ·面向对象的单元测试

 

 

²        ·面向对象的集成测试

 

 

²        ·面向对象的系统测试

 

 

²        3.3负载压力测试

 

 

²        ·负载压力测试基本概念

 

 

²        ·负载压力测试解决方案

 

 

²        ·负载压力测试指标分析

 

 

²        ·负载压力测试实施

 

 

²        3.4Web应用测试

 

 

²        ·Web应用的测试策略

 

 

²        ·Web应用设计测试

 

 

²        ·Web应用开发测试

 

 

²        ·Web应用运行测试

 

 

²        3.5网络测试

 

 

²        ·网络系统全生命周期测试策略

 

 

²        ·网络仿真技术

 

 

²        ·网络性能测试

 

 

²        ·网络应用测试

 

 

²        3.6安全测试

 

 

²        ·测试内容

 

 

²        ·测试策略

 

 

²        ·测试方法

 

 

²        3.7兼容性测试

 

 

²        ·硬件兼容性测试

 

 

²        ·软件兼容性测试

 

 

²        ·数据兼容性测试

 

 

²        ·新旧系统数据迁移测试

 

 

²        ·平台软件测试

 

 

²        3.8易用性测试

 

 

²        ·功能易用性测试

 

 

²        ·用户界面测试

 

 

²        3.9文档测试

 

 

²        ·文档测试的范围

 

 

²        ·用户文档的内容

 

 

²        ·用户文档测试的要点

 

 

²        ·用户手册的测试

 

 

²        ·在线帮助的测试

 

 

²        4.测试项目管理

 

 

²        ·测试过程的特性与要求

 

 

²        ·软件测试与配置管理

 

 

²        ·测试的组织与人员

 

 

²        ·测试文档

 

 

²        ·软件测试风险分析

 

 

²        ·软件测试的成本管理