测试基础总结

1、测试基础总结第1章 软件测试基础1、软件测试概论1)测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。2)软件标准有：IEEE：（电气和电子工程师协会）是一个国际性的电子技术与信息科学工程师的协会，是目前全球最大的非营利性专业技术学会； ANSI：美国国家标准学会，是非赢利性质的民间标准化团体； ISO：国际标准化组织，是国际标准化领域中一个十分重要全球性的非政府组织。3)软件测试与软件项目的关系：软件测试是为软件项目服务的，是为了发现软件中存在的错误，其根本目的是提高软件质量，降低软件项目的风险（QA人员是保证软件质量）；软件的质量风险表现为内部风险、

2、外部风险（风险更大）。软件测试只能证明软件存在错误，而不能证明软件没有错误，（软件公司对软件项目的期望是在预计的时间、合理的预算下，提交一个可以交付的产品），测试目的是把软件的错误控制在一个可以进行产品交付/发布的程度上，可以交付/发布的产品并不是没有错误的产品，而是将错误控制在一个合理的范围内4)第三方测试是指独立于软件公司自身测试的测试，第三方测试机构是通过自己专业化的测试手段为客户提供有价值的服务。（一般进行的是系统测试）2、软件测试的定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。是对软件形成过程中的文档、数据

3、和程序进行的测试。3、软件测试的目的：一个成功的测试是(发现了至今未发现的错误)的测试。1）以最小的代价找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷来提高软件质量，回避商业风险；2）度量与评估软件的质量，为用户选择提供依据；3）测试是以评价一个程序或者系统属性为目标的活动。通过分析错误，发现开发过程中的缺陷，以便进行改进，并为软件可靠性分析提供依据；4）通过验收测试（主要由用户组织），证明软件满足了用户的需求，树立用户的信心。4、软件测试的主要工作：检视代码、评审开发文档测试设计、写作测试文档（测试计划、测试方案、测试用例等）执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷得到了修正通过

4、测试度量软件的质量5、软件生命周期1）计划：确定软件开发总目标，相关设想（功能、性能、可靠性、接口）、方案（项目的可行性，问题的解决方案）、预估（资源、成本，效益，开发进度），制定实施计划。2）需求分析：对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定，哪些是可以满足的，并给予确切描述，写出软件需求说明书SRS。3）设计：设计是软件工程的技术核心。概要设计（HLD，High level design），在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；详细设计（LLD，Low level design）,对每个模块要完成的工作进行具体的描述。设计流程：SRS HL

5、D LLD 测试流程：UT IT ST 。4）编码：写源程序清单，建立数据库。5）测试：检验软件是否符合客户需求，达到质量要求，一般由独立小组执行，分为单元测试（UT，参照LLD，对象是每一个函数）；集成测试（IT,参照HLD，函数与函数的集成，模块与模块的集成）；系统测试（ST，参照SRS，整个系统）。 6）运行和维护。（软件修改原因：软件错误、系统软件升级、增强软件功能、提高性能等）6、项目组架构7、常见的软件研发流程：1）瀑布模型：应用最广泛的一种模型，也是最易理解和掌握的。 2）螺旋模型：瀑布模型与快速原型模型结合起来，突出了风险分析。 3）RUP流程：统一软件开发过程，利用商业的可靠

6、方法开发和部署软件，是一种重量级过程，特别适用于大型软件团队开发大型项目。 4）敏捷模型：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，目标是提高开发效率和响应能力。提交新版本（敏捷）1、缺陷验证只针对缺陷现象2、冒烟测试 3、新功能测试 4、回归测试（非第一次），有无缺陷都叫回归。迭代：把一个复杂且开发周期很长的开发任务，分解为很多小周期可完的任务，这样一个周期就是一次迭代的过程。（用户提出需求，开发人员开发出样品，供用户体验与提出改进意见，再由开发人员改进，如此往复，直到开发出用户满意的软件产品。） 8、软件缺陷和bug软件缺陷：既指静态存在于软件工作产品（文档、代码）中的错误，也指

7、软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。Bug：代码中的缺陷。所有缺陷可分为四类： 遗漏：规定的或预期的需求未体现在产品中 错误：未将规格说明正确实现 （设计错误、编码错误） 额外的实现：规格说明并未规定的需求被纳入产品，得到实现 改进：软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看最终用户会认为不好9、其他 60%以上的软件错误是分析和设计错误，而不是程序错误。性能测试：（同时在线的）用户数，响应时间，稳定性。测试是公司内部（邀请用户到公司）进行的测试，测试是将软件试用版本给用户试用，一般测试先于测试执行。调试：开发阶段对代码的调试（已知错误范围，找出错

8、误并改正）。第2章 需求分析与管理1、软件需求的定义：1）用户解决某一问题或达到某一目标所需的软件功能；2）系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。测试需求：明确项目中要测什么，要达到的目标是什么；力求详细明确，避免测试遗漏与误解 ；细化测试范围与内容，明确拟采用的测试技术。（见第6章 测试计划与方案）2、需求的分类：功能需求：描述系统预期提供的功能或服务； 描述方式为文字描述、图表表示； 功能需求描述应该完整、一致、准确。非功能需求：对实际使用环境所做的要求，主要与系统的总体特征有关（关心的是系统整体特征而不是个别特征）。是一些限制性要求：性能要

9、求，可靠性要求，安全性要求，可用性要求，移植性要求。3、软件需求规格说明书（SRS，software requirement specification）：是需求定义任务的最终“产品”，描述了系统的数据、功能、行为、性能需求、设计约束、验收标准，以及其他与需求相关的信息。软件需求分为：用户需求，开发需求，测试需求。4、软件需求变更·合理范围内的变化：用户不了解自己的需求，需求本身易变。·不合理的变化：需求文档质量不高，分析技能、技术和管理上的缺陷。·需求变化的原因：未受控制的需求变更，遗漏需求，用户交流不够，需求规约质量差，低效的需求分析。5、需求变更管理的原则：

10、1）认识到变更是不可避免的，为变更指定计划；2）确定需求基线；3）建立控制变更的唯一渠道；4)使用变更控制系统来控制变更过程；5）分层次的管理变更。6、软件需求变更流程7、软件需求跟踪：跟踪过程的主要活动是对RTM的维护，维护中建立以下四种跟踪关系：1）分配给项目的需求项目的软件需求规格概要设计详细设计代码2）项目的软件需求规格系统测试项系统测试子项系统测试用例3）概要设计集成测试项集成测试子项集成测试用例4） 详细设计单元测试项单元测试子项单元测试用例8、软件需求规则定义1） 需求项 把任务分解为可以实现的符合要求的具体需求项，需求项落实到SRS。2） 概要设计项 将SRS中的需求项分解为多

11、个模块，模块间有明确接口，模块的功能独立（符合高内聚低耦合原则），标识每一个模块的项目即概要设计项，最终落实到概要设计说明书中。高内聚：模块内部各个元素彼此结合的紧密程度；低耦合：软件结构内不同模块之间互连程度，模块之间尽可能使其独立存在。3） 详细设计项 把概要设计模块细化到函数或函数组，函数或函数组即详细设计项，最终落实到详细设计说明书中。9、需求评审的重要性需求调研是最开始、最重要的工作。如何保证需求调研过程内容的正确、准确性，成了决定软件项目成败的关键因素。软件需求分析说明书的正确性必须得到彻底的验证，利益相关方必须彻底理解需求，并达成一致；要达成这一目标、降低需求风险，需求评审是一个

12、行之有效的方法。10、如何有效进行需求评审：1）充分准备评审2）分层次评审 目标性需求（整个系统要达到的目标，企业高管关注），功能性需求（清楚需求边界，中层管理人员关注），操作性需求（定义具体的人机交互，具体操作人员关注）。3）评审要控制时限4)跟踪评审中问题的结果5）评审的结果基线11、内部评审中评审文档的目的：1）及时检测出软件需求文档中具有不可测试性的需求点（如淘宝中第三方提供的物流信息）。2）及时发现需求文档的不完整性，找出用户提出的但未被完整描述的需求点，提醒需求分析人员描述完整。3）熟悉业务需求，与需求人员保持理解一致，及时发现文档中有歧义、二义性、模糊的描述，从而提醒需求分析人员

13、以精确的文字来描述需求点。12、需求分析1）功能点梳理 根据SRS和产品界面原型梳理功能点，整理成功能矩阵列表。以功能点为基本采用等价类、边界值等法设计用例。 功能分解法：业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求。2）业务流程 根据SRS，梳理并整理出系统所有业务流程(流程的完整性，数据传递的正确性，状态)。步骤如下： a. 在对整个软件功能较熟悉的基础上梳理业务流程（分析并了解软件的业务流、数据流） b.画出业务流程图（工具有visio、word）13、其它1） SOW：工作说明书，AR：验收要求，RTM：需求跟踪矩阵。2）越早发现错误，修复错误所花代价越小。第

14、3章 测试过程与方法1、软件测试阶段分类测试阶段 简称测试方法考察范围测试目的评估基准单元测试UT白盒测试单元内部的数据结构、逻辑控制、异常处理检验软件模块对详细设计说明书的符合程度逻辑覆盖率集成测试IT灰盒测试模块之间的接口和接口数据传递，以及模块组合后的整体功能对概要设计说明书的符合程度接口覆盖率系统测试ST黑盒测试整个系统相对于需求的符合度对SRS的符合程度测试用例对 需求规格的覆盖率2、回归测试发现缺陷经过修改后，应进行回归测试，目的是验证缺陷得到了修复，同时对系统的变更没有影响以前的功能（未发现缺陷的模块也应进行回归测试）。可发生在任何阶段。软件配置：软件需求规格、设计文档、代码、配

15、置数据等；测试配置：测试计划、测试方案、测试用例、测试驱动；测试工具：自动化测试工具、相关自动化脚本、驱动测试的测试数据。回归测试策略：·完全重复测试（执行所有的测试用例，缺点是耗时长，易枯燥） ·选择性重复测试：覆盖修改法，周边影响法，指标达成法。3、验收测试（软件正式发布前）1）（ALPPHA）测试 由用户在开发环境下（或开发机构内部用户模拟实际操作环境下）进行的测试，目的是评价软件产品的功能、局域化、可用性、可靠性、性能和技术支持。2）（BETA）测试 多个用户在实际使用环境下进行的测试（开发者通常不在测试现场）。用户试用。3）验收测试 以用户为主，原则上在用户所在地

16、进行，测试依据为合同、SRS、验收测试计划。有时也包含、。客户验收，第三方代验收。4、测试过程阶段 测试计划阶段测试计划（做什么） 测试设计阶段测试方案（怎么做） 测试实现阶段测试用例、测试规程 测试执行阶段测试报告5、常见测试模型1）瀑布模型：应用最广，最易理解和掌握的模型；缺点是遗漏或不断变更的需求会使得该模型无所适从。2）V模型：反映测试活动与分析和设计的关系，需求分析等前期产生的错误直到后期的验收测试才能发现。3）W模型：开发与测试同步，能较早发现软件中的缺陷；局限是串行实施，前后依赖性较强，不利于变更。4）V&V模型：测试设计与测试执行相分离。验证 保证软件正确实现特定功能，

17、检测每一阶段的产品是否与前一阶段定义的规格相一致。确认 保证软件可追溯到用户需求，检测每一阶段的产品是否与最初定义的软件需求规格相一致。6、测试方法1）白盒测试：依据是软件分析程序内部构造；对内部控制流程进行测试；是基于程序结构的逻辑驱动测试。可发现80%的缺陷。静态分析：控制流分析、数据流分析、信息流分析；动态分析：逻辑覆盖（语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、路径覆盖）、程序插装。2）黑盒测试：把对象看成一个黑盒，只考虑整体性，不考虑其内部具体实现；基于规格的测试。软件质量特性：功能性、可靠性、易用性、效率（性能）、维护性、可移植性。功能测试是验证产品能否实现客户需求的功能；性能测

18、试中产品性能主要受以下因素影响：同时在线用户数、响应时间、稳定性。常用黑盒测试方法：等价类、边界值、因果图等方法（详见第7章 测试用例与设计）。方法优点缺点白盒测试可检测代码中每条分支、路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；优化代码结构。投入大、成本高；不验证规格的正确性。黑盒测试比白盒测试效率高；不需要了解实现的细节，包括编程语言；从用户视角测试，易被理解和接受；有助于暴露不一致或有歧义的问题；不能控制内部执行路径，使很多路径没有被测试到；不能直接针对特定（很复杂）的程序段（可能隐藏更多问题）。3)静态测试：不运行被测软件。（如代码走读、文档评审、程序分析）4)动态测试：按预先

19、设计的数据和步骤去运行被测软件系统。（路径测试、分支测试、性能测试）5)人工测试：测试活动由人来完成，这是最基本的测试形式。手工测试是自动化测试的基础。6)自动化测试：通过计算机模拟人的行为，替代人的测试活动（重复性高、枯燥的工作）。不能取代手工测试，只能提高测试效率，不具有智能，不能发现更多缺陷。7、其它 1）测试规程：测试活动序列的文档。 2）灰盒测试：既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，就可采用此法。第4章 系统测试与分类1、系统测试的定义与目的定义：将集成好的软件系统，与计算机硬件、外设、支持软件等结合起来进行的测试。目的：与SRS比较，发现软件与其不相符的

20、地方。测试对象：软硬件结合起来的系统。验证时尽可能模拟实际运行环境。2、系统测试常用类型1) 功能测试 验证产品功能是否符合SRS。2) 性能测试 测试软件在集成系统中的运行性能，在功能测试后等功能稳定后再进行。目标是度量系统相对于预定义目标的差距。 包括负载测试、压力测试、容量测试（又称大数据量测试）。3) 安全性测试 验证系统内的保护机制是否能够保护系统不受非法侵入，保证系统数据的完整性和保密性。4) GUI测试 用户界面测试 验证界面实现是否吻合界面设计，确认界面处理的正确性。测试对象包括界面整体和界面中的元素5) 可用性测试 检测用户是否容易理解和使用系统。6) 可安装性测试 检测安装

21、过程简单程度，安装时长的长短。主要进行安装前、中、后的测试。7) 配置测试 测试系统在各种软硬件、不同参数配置下系统的功能和性能。验证配置的可操作性和有效性，特别需要对最大、最小、或特殊配置进行测试。8) 可靠性测试 软件在规定条件下、规定时间内完成规定功能的能力。指标有系统平均失效时间间隔MTBF、系统平均恢复时间MTTR。9) 备份测试 恢复性测试的补充。备份后验证一下。10) 异常测试又叫系统容错和可恢复性测试。通过人工干预使软硬件产生异常，验证异常前后的功能和状态，达到检验系统容错、排错和恢复的能力。有计划、可设计。11) 健壮性测试测试系统自动运行时出现故障，能否自动恢复或继续运行。

22、如浏览器非正常关闭后可恢复。12) 文档测试用户文档包括用户手册、操作手册、维护手册。保证用户文档的正确性、完整性、一致性、易用性。13) 在线帮助测试 保证在线帮助的准确性、完整性、易用性。14) 网络测试 网络环境下和其他设备对接，进行功能、性能、指标测试，保证设备对接正常。15) 稳定性测试 评价系统在一定负荷下、长时间的运行情况。16) 兼容性测试 程序与软、硬件之间兼容性的测试，包括硬件兼容、软件兼容、数据库兼容、数据兼容。Web兼容考虑三方面：操作系统平台兼容、浏览器兼容、分辨率兼容。3、系统测试过程计划阶段：完成系统测试计划（需要做什么）设计阶段：完成测试方案（具体怎么做）实现阶

23、段：测试用例、测试规程、预测试项执行阶段：执行预测事项、测试用例，修改问题、回归测试，提交（预测试、系统、缺陷）报告预测试的目的：验证软件系统基本功能或预测主要的系统功能。通常比冒烟测试时间长。冒烟测试只在系统测试中（因其需要运行环境，而单元测试和集成测试没有运行环境）用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。冒烟测试是确定和修复软件缺陷的最经济有效的方法。4、系统测试环境要素1）硬件环境：服务器、客户端、网络设备、测试仪器等；2）软件环境（主、辅测试环境）：操作系统、数据库、共存软件、测试工具、相关手册等。5、系统测试数据以消息、事务、记录、文件等形式存在。数据来源有：产

24、品数据、手工构造、生成、捕获、随机。6、其它痛点：对用户有用，让用户离不开；痒点：抓人眼球，让人从心里喜欢。第5章 软件质量与管理1、软件质量质量的定义：实体基于实体特性满足需求的程度。软件质量的三个层次：符合需求规格（开发者明确定义的目标），符合用户显式需求（用户明确说明的目标），符合用户实际需求（用户明确说明的和隐含的需求）。软件质量的影响因素：2、软件质量管理体系ISO9000（最宽泛，最易通过），CMMCMMI（最难通过），六西格玛（适合服务行业）。（1）ISO9000：2000版主要由ISO9000（理论基础）、ISO9001（明确规定）、ISO9004（改进）三个核心标准组成。20

25、00版八项质量管理原则： 以顾客为中心 领导作用 全员参与 过程方法 管理的系统方法 持续改进 基于事实的决策方法 互利的供方关系（2）软件能力成熟度模型CMM（只有阶段式表示）初始级，可重复级，已定义级，已管理级，优化级。CMM的用途：1）评估组用来识别强处、弱点；2）评价组用来识别风险和监督合同；3）管理者用来了解其组织的能力；4）技术人员和过程改进组用来指导定义和改进软件过程。（3）软件能力成熟度集成模型CMMI 完成级，已管理级，已定义级，量化管理级，优化管理级。连续式表述可达到能力度等级（03），描绘特定流程领域中的状态（如开发能力、测试能力、过程管理）。阶段式表述可达到成熟度等级（

26、15），描绘整体状态。（4）六西格玛管理法以质量为主线，以客户需求为中心，利用对事实和数据的分析，改进提升一个组织的业务流程能力，从而增强企业竞争力的管理方法体系。六西格玛要求企业完全从外部客户角度（而不是从自己角度）来看待企业内部的各种流程。 原则：注重客户，注重流程，全员参与，预防为主。3、软件质量模型 6大特性，27个子特性。4、质量管理PDCA循环：Plan计划，Do执行，Check检查，Action改进。5、软件度量度量是对事物属性的量化表示。 规模：软件产品的大小； 工作量：完成各软件产品和活动 所用人时； 进度：各软件产品和活动 开始、结束的时间； 质量缺陷：在各软件产品和活动中

27、产生的缺陷数。 缺陷密度、生产率、测试执行效率、用例密度等度量指标可由以上四项基本度量项分析、计算得到。第6章 测试计划与方案1、测试计划测试计划是从宏观上反映项目的测试任务、阶段等，不一定要太过详细，但一定要切合实际，且不是一成不变（软件需求、开发、人员流动等）的，需根据实际情况不断调整。避免测试的“事件驱动”（消防式应对，哪里出现问题，就奔向哪里去解决）。测试计划编写6要素：why为什么要进行这些测试；what测试哪些方面，各阶段的工作内容；who项目组成人员有哪些，安排哪些测试人员测试；when测试中各阶段的起止时间；where相应文档，缺陷存放位置，测试环境等；how如何去做，使用哪些

28、测试工具及方法进行测试。测试计划的内容：测试目标，测试概要，测试范围，重点事项，测试策略，资源需求，人员组织，测试进度安排，测试开始/完成/延迟/继续的标准，质量目标，成果物，风险分析。2、测试需求和任务测试需求就是明确项目中要测什么，要达到的目标是什么；力求详细明确，避免测试遗漏与误解 ；细化测试范围与内容，明确拟采用的测试技术。需求分析三方面：质量模型，系统交互，用户使用场景。测试需求分为软件功能测试需求和非功能性的系统测试需求（性能要求、容错处理、兼容性要求、安全性要求）测试需求通常以软件需求转变而来，但测试需求不等同于软件需求。3、测试工作量估算工作分解结构表法（WBS）：以可交付成果

29、为导向对项目要素进行的分组，归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。工作量估算因素：效率（人员效率、自动化水平），测试动作（动作数、用例时间），阶段（设计、开发、执行等不同阶段），复杂度（维数越高越复杂），风险（工作量的10%-20%），测试工作量的估计（W=W0+W0*R1+W0*R2+ W0*R3）。4、测试资源需求5、测试里程碑：项目中完成阶段性工作的标志，定义当前阶段完成的标准和新阶段启动的条件或前提。甘特图（Gantt chart）：以图示的方式通过活动列表和时间刻度表示出任何特定项目的活动顺序与持续时间。6、测试风险分析 第7章 测试用例与设计1、黑盒测

30、试用例设计方法等价类划分法边值分析法因果图法判定表法状态迁移法流程分析法正交实验法异常分析法错误猜测法2、等价类划分法等价类：某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不能导致问题发生，那么集合中其他输入条件进行测试也不可能发现错误。有效等价类：程序规格说明有意义，合理的输入数据，（设计一个测试用例使其尽可能多的覆盖所有尚未覆盖的有效等价类）。无效等价类：程序规格说明无意义，合理的输入数据，（设计一个测试用例使其只覆盖一个无效等价类）。设计用例步骤：为输入划分等价类，为每个等价类规定一个唯一编号。设计一个测试用例使其尽可能多的覆盖所有尚未覆盖的有效等价类，重复步骤

31、使所有有效等价类均被覆盖。设计一个测试用例使其只覆盖一个无效等价类，重复步骤使所有无效等价类均被覆盖。3、边值分析法上点：边界上的点，封闭域的范围内，开放域的范围外离点：离上点最近的一点。内点：范围内的任意一点。设计用例步骤：分析输入参数的类型等价类划分确定边界相关性分析形成测试项4、因果图法因果图提供了把规格转化为判定表的系统化方法。适合于检查输入条件的各种组合情况。因果图基本符号输入条件的约束： E约束（异）： a、b中至多有一个可能为1。 I约束（或）： a、b、c至少有一个必须是1。 O约束（唯一）：a、b有且只有一个是1。 R约束（要求）：a是1时，b必须是1。输出条件的约束： M约

32、束（强制）：a是1时，b强制为0。设计用例的步骤： 把大的系统规格分解成可测的规格片段 分析分解后的系统规格，找出原因、结果 画出因果图 把因果图转化成判定表 简化判定表 将判定表中的每一项生成测试用例5、判定表法（最完善的）条件桩：列出了问题的所有条件（条件的次序无关紧要）。动作桩：列出了问题规定可能采取的操作（操作的排列顺序没有约束）。条件项：列出针对它左列条件的取值（所有可能下的真假值）。动作项：在条件项的各种取值下应该采取的动作。设计用例的步骤： 确定规则的个数填入条件项填入动作桩和动作项化简，合并相似规则将每条规则转化为用例判定表的优缺点优点：能把复杂的问题按各种可能的情况一一列举出

33、来。缺点：合并存在漏测的风险。6、状态迁移法 需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。通过测试状态机验证其在给定的条件内是否能够产生需要的状态变化，常用于协议测试，可设计逆向的测试用例。设计用例的步骤： 画出状态迁移图 列出状态事件表 从状态转换树推导出测试路径 根据测试路径编写合法的测试用例 编写非法的测试用例7、流程分析法把流程看成路径，用路径分析的方法来设计用例。设计用例的步骤：画出业务流程图确定测试路径选取测试数据构造测试用例 8、测试用例综合设计策略1）任何情况下都必须使用边界值分析法2）必要时用等价类划分法补充一些用例3) 用错误推测法追加一些用例

34、4）对照程序逻辑，检查逻辑覆盖程度5）程序功能说明中有输入条件的组合情况，一开始就可选用因果图法。设计用例的步骤：1） 构造基本功能测试用例2） 边界值测试用例3） 状态转换测试用例4） 错误猜测测试用例5） 异常测试用例6） 性能测试用例7） 压力测试用例9、 测试用例的写法（注意质量，不要盲目追求效率）（1）测试用例编号 具有唯一性（不能重复）、易识别性。举例：项目名称_ST_FUN_功能模块_TC001，Ecshop_ST_FUN_login_TC001 （2）测试项目 软件需求项（ST）/集成后的模块名或接口名（IT）/被测函数名（UT） （3）测试用例标题 用概括的语言描述该用例的出

35、发点和关注点。测试用例编号和标题不能重复。（4）测试用例优先级：高：保证系统基本功能、核心业务、重要特性、使用频率高的用例；中：介于高和低之间的用例；低：实际使用频率不高、对系统业务功能影响不大的模块或功能的用例。（5）测试用例预置条件 执行当前测试用例需要的前提条件。（6）测试用例输入 手工输入、文件、数据库记录等。（7）测试用例操作步骤 明确给出每一个步骤的描述，测试用例执行人员可以根据该操作步骤完成测试用例执行。（8）测试用例预期结果 包括返回值内容、界面相应结果、输出结果的规则符合度等。第8章 配置管理与工具1、配置管理相关概念配置管理：对软件生命周期不同时间点上的软件配置进行标识，对

36、这些软件配置项的更改进行系统控制，以达到保证软件产品的完整性、可塑性的过程。配置：在技术文档中明确说明并最终组成软件产品的功能或物理属性。包括产品特性、内容与相关文档，软件版本，变更文档，支持数据，保证软件一致性的组成要素。 配置项：一组软件功能或者物理属性的组合，在配置管理中被作为一个单一的实体对待。（一台电脑或服务器的配置参数等（关于硬件的）不叫配置项）2、基线配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”。基线属性： 通过正式的评审过程建立； 存在于配置库中，基线的变更由CCB控制； 基线是进一步开发和修改的基准。3、软件版本与配置项版本 （

37、1）软件版本 表示一个配置项具有一组定义的功能的一种标识（版本号）。以xx.yy.zz.pp（主、次、维护、补丁版本号）的形式标识。一般项目只有主、次版本号；维护版本的产品可带着不重要的缺陷上线，但这些缺陷最终还是要修复；补丁版本：一般的软件是谁提出问题就把补丁版本发给谁，而操作系统一般因为使用人员多而统一更新补丁。（2）配置项版本 单个配置项在每次修改后都会发生变化，为了标识配置项在两次修改之间的不同，需要对配置项的版本进行标识。 每个配置项（xx.yy，发生重大修改，xx从1递增；只有小修改，yy从0递增）都必须被唯一地标识。4、配置计划与标识 PM制定配置管理计划，是开展所有配置管理活动的基础。 配置标识是对软件配置进行管理的前提和基础。5、基线变更请求：生在任何阶段。6、配置管理工具SVN：服务器端与客户端。服务器端主要熟悉以下操作：import（导入）,checkout（导出）,commit（提交）, update（更新）,add（新增）。7、配置库的备份 务器与备份库服务器最好放在不同的位置。 热备份：一边工作一边备份； 冷备份：工作结束后再备份。第9章 缺陷管理1、缺陷相关术语Bug：电脑系统或程序中存在的破坏正常运转