1、软件测试理论系统测试v 什么是系统测试什么是系统测试v 系统测试的主要内容系统测试的主要内容v 系统测试的过程系统测试的过程v 测试过程改进测试过程改进用户需求用户需求体系结构设计体系结构设计详细设计详细设计编码实现编码实现单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试Prepare planVerifyPrepare planVerifyPrepare planVerify软件需求软件需求v 系统测试系统测试 使用人工或自动手段来运行或测定某个系统的过程，其使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的系统需求或是弄清预期目的在于检验它是否满足
2、规定的系统需求或是弄清预期结果与实际结果之间的差别。结果与实际结果之间的差别。v 验证验证（Verification）v 验证确定工作产品正确反映了它们的规验证确定工作产品正确反映了它们的规定需求。换言之，验证保证定需求。换言之，验证保证“你正确地构建你正确地构建了它了它”。v 确认确认（Validation）v 确认确定提供的产品将满足其预期使确认确定提供的产品将满足其预期使用。换言之，确认保证用。换言之，确认保证“你构建了正确的产你构建了正确的产品品”。v CMMI模型第模型第3章章v 什么是系统测试什么是系统测试v 系统测试的主要内容系统测试的主要内容v 系统测试的过程系统测试的过程v
3、测试过程改进测试过程改进v 功能测试功能测试恢复性测试（灾难测恢复性测试（灾难测 试、容错测试）试、容错测试）敏感性测试敏感性测试安全性测试安全性测试接口测试接口测试用户界面测试用户界面测试安装安装/升级测试升级测试配置测试配置测试/兼容性测试兼容性测试国际化（语言）测试国际化（语言）测试用户文档测试用户文档测试v 性能测试 强度测试 容量测试 可靠性测试 边界测试 v 冒烟测试v 回归测试v 随机测试v 硬件系统专有测试 可靠性试验 可生产性测试 可维护性测试v 常称为常称为强度测试强度测试，通常还包括，通常还包括极限性测试极限性测试和和敏感性测试敏感性测试等，用于测试系统对异常工作强等，用
4、于测试系统对异常工作强度（包括过大的工作量、不充足的内存、不度（包括过大的工作量、不充足的内存、不可用的服务可用的服务/硬件或过低的共享资源等）情硬件或过低的共享资源等）情况下的处理能力。况下的处理能力。 极限测试侧重于测试系统在内部和外部达到最大额定指极限测试侧重于测试系统在内部和外部达到最大额定指标时能否正常工作标时能否正常工作 敏感性测试侧重于测试系统在一些临界点条件下功能结敏感性测试侧重于测试系统在一些临界点条件下功能结果和性能表现是否产生突变。果和性能表现是否产生突变。v 常用工具常用工具 SmartBits等数据流量模拟发生器等数据流量模拟发生器 Rational TestMana
5、ger的的VU(Virtual Users)模拟测试脚模拟测试脚本工具本工具 话音模拟呼叫器，等。话音模拟呼叫器，等。v 常见故障常见故障 在异常资源配置下容易产生系统崩溃或处理能力急剧下在异常资源配置下容易产生系统崩溃或处理能力急剧下降、出错率急剧上升的现象降、出错率急剧上升的现象 达不到需求所要求的最高容量指标达不到需求所要求的最高容量指标 在允许的资源配置范围内存在某些临界点（特定输入或在允许的资源配置范围内存在某些临界点（特定输入或配置），在这些临界点系统的功能性能表现产生突变甚配置），在这些临界点系统的功能性能表现产生突变甚至系统发生崩溃。至系统发生崩溃。v 主要包括组网测试和软硬件
6、平台配置测试主要包括组网测试和软硬件平台配置测试 组网测试的目的是测试系统是否满足其需求中所支持的组网测试的目的是测试系统是否满足其需求中所支持的所有组网类型和组网规模所有组网类型和组网规模 软硬件平台配置测试的目的是测试系统是否满足其需求软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置。中所支持的不同软硬件平台配置。 兼容性测试是指系统的适应能力测试，可分为环境兼容兼容性测试是指系统的适应能力测试，可分为环境兼容测试和版本兼容测试。测试和版本兼容测试。v 常见故障常见故障 系统在采用需求中支持的某些组网方式时的功能或性能系统在采用需求中支持的某些组网方式时的功能或
7、性能出现问题；出现问题； 系统在采用需求中支持的某些平台、软件配置方式时的系统在采用需求中支持的某些平台、软件配置方式时的功能或性能出现问题。功能或性能出现问题。v 安全测试就是检查系统对于外部的非法侵入安全测试就是检查系统对于外部的非法侵入的抵御能力。系统安全测试的准则是，测试的抵御能力。系统安全测试的准则是，测试非法侵入的代价是否超过被保护信息的价值。非法侵入的代价是否超过被保护信息的价值。v 信息安全与保密（信息安全与保密（Security）不同于人身安）不同于人身安全和重大财产损失（全和重大财产损失（Safety）。）。 在公司的产品研发中，需要重点考虑的是信息安全方面在公司的产品研发
8、中，需要重点考虑的是信息安全方面 随着随着ISO 14000/18000的实施，的实施，Safety方面的内容会增多方面的内容会增多v 主要方法：主要方法： 想方设法截取或破译口令；想方设法截取或破译口令； 专门定做软件破坏系统的保护机制；专门定做软件破坏系统的保护机制； 故意导致系统失败，企图趁恢复之机非法进入；故意导致系统失败，企图趁恢复之机非法进入； 试图通过浏览非保密数据，推导所需信息，等。试图通过浏览非保密数据，推导所需信息，等。 主要工具：协议分析仪、系统漏洞扫描软件，黑客工具主要工具：协议分析仪、系统漏洞扫描软件，黑客工具等。等。v 常见故障常见故障 系统缓冲区溢出、堆栈溢出错误
9、。系统缓冲区溢出、堆栈溢出错误。 系统存在密码安全、权限管理、数据安全方面的漏洞，系统存在密码安全、权限管理、数据安全方面的漏洞，可被轻易的进入并进行非法获取和破坏。可被轻易的进入并进行非法获取和破坏。v 检查系统的容错能力，测试系统在遇到系统检查系统的容错能力，测试系统在遇到系统崩溃、硬件损坏或其他灾难性问题后能否很崩溃、硬件损坏或其他灾难性问题后能否很好地恢复，测试的具体内容包括创建各种可好地恢复，测试的具体内容包括创建各种可能的灾难状况，测试系统从异常状态恢复到能的灾难状况，测试系统从异常状态恢复到正常状态所需的时间、花费的代价、对周边正常状态所需的时间、花费的代价、对周边设备和系统造成
10、的影响，系统恢复的完整性设备和系统造成的影响，系统恢复的完整性和一致性等。和一致性等。v 常用工具：常用工具： 主要是制造系统异常，按系统恢复功能进行恢复操作，主要是制造系统异常，按系统恢复功能进行恢复操作，直至系统继续正常运行直至系统继续正常运行 为了测试系统恢复之后是否运行正常，也可以采用一些为了测试系统恢复之后是否运行正常，也可以采用一些自化测试工具进行回归测试，以提高测试的效率。自化测试工具进行回归测试，以提高测试的效率。v 常见故障常见故障 系统发生异常后无法恢复，造成系统数据被破坏，即重系统发生异常后无法恢复，造成系统数据被破坏，即重启系统、恢复备份数据也不可行，严重的可能造成系统
11、启系统、恢复备份数据也不可行，严重的可能造成系统硬件故障；硬件故障； 系统恢复时间过长、代价过高；系统恢复时间过长、代价过高； 系统不能完全恢复到原来的正常状态，造成一定损失；系统不能完全恢复到原来的正常状态，造成一定损失； 系统恢复过程对周边设备和环境造成较大影响，无法消系统恢复过程对周边设备和环境造成较大影响，无法消除，等。除，等。v 以用户的角度来对软件界面的易用性、风格、以用户的角度来对软件界面的易用性、风格、合理性等面进行评估和测试。通常包括软件合理性等面进行评估和测试。通常包括软件的的“界面显示测试界面显示测试”和和“界面功能测试界面功能测试”，而界面功能测试主要结合系统功能进行测
12、试。而界面功能测试主要结合系统功能进行测试。v 常用工具：常用工具：Winrunner、Robot等录制回放工等录制回放工具具v 测试要点和常见故障：测试要点和常见故障： 易用性与合理性：步骤繁琐的操作，比例不协调、摆放易用性与合理性：步骤繁琐的操作，比例不协调、摆放凌乱的窗口和控件，层次过多的子窗口和菜单凌乱的窗口和控件，层次过多的子窗口和菜单 规范性：不符合规范性：不符合Windows规范的控件设计，与常规规范的控件设计，与常规Windows操作不符的流程与操作等操作不符的流程与操作等 容错性：编辑控件对非法字符、超出边界值的输入处理容错性：编辑控件对非法字符、超出边界值的输入处理不当或没
13、有提示，容易造成系统重启、数据删除丢失等不当或没有提示，容易造成系统重启、数据删除丢失等的操作没有提示等的操作没有提示等 帮助：无帮助信息提供，或者不提供获取帮助的快捷操帮助：无帮助信息提供，或者不提供获取帮助的快捷操作作 美观与风格：界面颜色不协调、界面风格与公司相关产美观与风格：界面颜色不协调、界面风格与公司相关产品风格不符、与业界通用风格不符，图片、图标等不符品风格不符、与业界通用风格不符，图片、图标等不符合公司合公司CI规范。规范。 资源：界面长时间运行操作造成系统内存耗尽、界面对资源：界面长时间运行操作造成系统内存耗尽、界面对系统资源独占使用等系统资源独占使用等v 安装升级测试是以最
14、终用户的角度测试系统安装升级测试是以最终用户的角度测试系统的可安装性以及系统是否具有升级或卸载功的可安装性以及系统是否具有升级或卸载功能。安装升级测试，需要重点测试系统的软能。安装升级测试，需要重点测试系统的软硬件平台的兼容性。硬件平台的兼容性。v 主要内容：主要内容： 安装升级基本功能测试安装升级基本功能测试 卸载测试卸载测试(可选可选) 平台兼容性平台兼容性 易用性与合理性测试易用性与合理性测试 健壮性测试健壮性测试v 常用工具：通常手工进行。可借助录制回放常用工具：通常手工进行。可借助录制回放工具进行反复的软件安装测试。工具进行反复的软件安装测试。v 常见故障：常见故障： 系统的软硬件不
15、能兼容。系统的软硬件不能兼容。 系统软件在不同的平台下安装后不能正常工作。系统软件在不同的平台下安装后不能正常工作。 系统版本升级后，无法正常工作，系统无法回退到升级系统版本升级后，无法正常工作，系统无法回退到升级前的版本。前的版本。 系统的硬件安装不符合用户习惯。系统的硬件安装不符合用户习惯。 系统的软硬件安装升级过程和用户文档上的叙述不一致，系统的软硬件安装升级过程和用户文档上的叙述不一致，甚至错误，误导最终用户。甚至错误，误导最终用户。v 各种用户文档和联机帮助系统是软件产品的各种用户文档和联机帮助系统是软件产品的重要组成部分，保证其正确性也是软件测试重要组成部分，保证其正确性也是软件测
16、试工程师的职责。文档工程师的职责。文档/帮助测试的目的在于：帮助测试的目的在于： 提高易用性，使软件用户更容易地学习和使用软件产品。提高易用性，使软件用户更容易地学习和使用软件产品。 提高可靠性，如果用户阅读文档，然后使用软件，最终提高可靠性，如果用户阅读文档，然后使用软件，最终得不到预期结果，这就是可靠性差。得不到预期结果，这就是可靠性差。 降低支持费用，好的文档降低支持费用，好的文档/帮助通过恰当的解释和引导可帮助通过恰当的解释和引导可以在用户有麻烦或者遇到意外情况时减少请求公司帮助。以在用户有麻烦或者遇到意外情况时减少请求公司帮助。v 从用户的角度来测试软件文档是非常有效的从用户的角度来
17、测试软件文档是非常有效的方法。仔细阅读，跟随每个步骤，检查每个方法。仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例。利用这个现实的简单图形，尝试每个示例。利用这个现实的简单方法，可以找出软件和文档中的缺陷。常用方法，可以找出软件和文档中的缺陷。常用的方法有：的方法有： 评审和审查，检查文档的编辑清晰性。评审和审查，检查文档的编辑清晰性。 动态测试，结合实际程序的使用而使用文档。动态测试，结合实际程序的使用而使用文档。 让独立的第三方（如用户）或其他人员让独立的第三方（如用户）或其他人员(如以前没有接触如以前没有接触或使用过本系统的新手或使用过本系统的新手)在程序的使用语境测试文档也是在程序
18、的使用语境测试文档也是十分有效的方法。十分有效的方法。v 文档是否精确描述了各种使用模式？文档是否精确描述了各种使用模式？v 每个交互顺序的描述是否精确？每个交互顺序的描述是否精确？v 例子是否精确？例子是否精确？v 术语、菜单描述和系统响应是否与实际应用术语、菜单描述和系统响应是否与实际应用程序一致？程序一致？v 是否能够很方便地使用文档定位和排除错误？是否能够很方便地使用文档定位和排除错误？v 文档的内容和索引是否精确完整？文档的内容和索引是否精确完整？v 文档的设计（布局、缩入和图形）是否便于文档的设计（布局、缩入和图形）是否便于信息的理解？信息的理解？v 显示给用户的错误信息是否有更详
19、细的文档显示给用户的错误信息是否有更详细的文档解释？解释？v 如果使用超级链接，超级链接是否精确完整？如果使用超级链接，超级链接是否精确完整？v 如果使用超级链接，导航设计是否适合于所如果使用超级链接，导航设计是否适合于所需要的信息？需要的信息？v 也称为构建验证测试（也称为构建验证测试（BVT，Build Verification Test）v 测试被测系统是否具有基本运行功能，如启测试被测系统是否具有基本运行功能，如启动、加载、执行基本操作等。动、加载、执行基本操作等。v 常与每日构建相结合，作为集成测试的一个常与每日构建相结合，作为集成测试的一个重要部分重要部分v 在系统测试中用作入口检
20、查在系统测试中用作入口检查v 通常需要自动化工具通常需要自动化工具v 常见故障常见故障 被测系统无法启动和加载；被测系统无法启动和加载； 基本功能出现故障；基本功能出现故障； 自动化测试无法正确执行。自动化测试无法正确执行。v 对系统的新增功能和以前测试中已经测试过对系统的新增功能和以前测试中已经测试过无故障的相关功能进行验证，以保证新增功无故障的相关功能进行验证，以保证新增功能和能和/或对旧有故障的修改不会在被测系统或对旧有故障的修改不会在被测系统中引入新的故障，其测试范围和规模介于完中引入新的故障，其测试范围和规模介于完整测试和简单的故障验证测试之间。整测试和简单的故障验证测试之间。v 需
21、要根据新增需要根据新增/修改功能的波及范围精心选修改功能的波及范围精心选择和设计测试范围与测试用例择和设计测试范围与测试用例v 尽量采用自动化测试工具尽量采用自动化测试工具v 俗称俗称“猴子猴子”测试测试v 最好由用户代表进行最好由用户代表进行v 公司内部可结合新员工公司内部可结合新员工/工程工程/客服人员培训客服人员培训进行进行v 应该有适当的组织和计划应该有适当的组织和计划v 什么是系统测试什么是系统测试v 系统测试的主要内容系统测试的主要内容v 系统测试的过程系统测试的过程v 测试过程改进测试过程改进v 系统测试计划阶段系统测试计划阶段v 系统测试设计和开发阶段系统测试设计和开发阶段v
22、系统测试执行和评估阶段系统测试执行和评估阶段v 制定系统测试总体计划制定系统测试总体计划 简述项目，明确测试的范围简述项目，明确测试的范围 定义测试策略（阶段、类型、技术、标准等）定义测试策略（阶段、类型、技术、标准等） 编制测试需求编制测试需求 工作分解和估算工作分解和估算 资源分配资源分配 进度表进度表 风险识别与应对风险识别与应对v 系统测试总体计划评审系统测试总体计划评审v 批准系统测试总体计划批准系统测试总体计划v 系统测试总体计划纳入配置管理系统测试总体计划纳入配置管理v 系统测试方案设计系统测试方案设计v 测试方案评审测试方案评审v 系统测试规程设计系统测试规程设计v 建立需求跟
23、踪矩阵建立需求跟踪矩阵v 系统测试规程评审系统测试规程评审v 系统测试用例细化和系统测试用例细化和再开发再开发v 系统测试用例评审系统测试用例评审v 测试工具的设计和研测试工具的设计和研制制v 不做测试设计，或测试过程并未系统测试总不做测试设计，或测试过程并未系统测试总体计划的要求来做。体计划的要求来做。v 测试设计不详细，不是基于可量度的测试策测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需略，例如测试计划覆盖一个集合或者测试需求的一个子集。求的一个子集。v 测试过程没有检验测试需求。测试过程没有检验测试需求。v 测试开发没有依据，测试规程和用例与测试测试开发没有
24、依据，测试规程和用例与测试方案或系统方案或系统v 测试总体计划中测试策略没有对应性。测试总体计划中测试策略没有对应性。v 测试过程不可重复或不可重用。测试过程不可重复或不可重用。v 需求覆盖率（百分比）需求覆盖率（百分比） 测试覆盖的需测试覆盖的需求求/所有的需求所有的需求 100%；v 测试用例的数量（条）；测试用例的数量（条）；v 自动化测试在系统测试中的比例（百分比）自动化测试在系统测试中的比例（百分比） 采用自动化测试的系统测试用例数目采用自动化测试的系统测试用例数目/全全部的测试用例总数部的测试用例总数100%；v 测试用例设计和开发的工作量（人时）；测试用例设计和开发的工作量（人时
25、）；v 测试工具研制的工作量（人时）；测试工具研制的工作量（人时）；v 系统测试文档评审的工作量（人时）；系统测试文档评审的工作量（人时）；v 系统测试申请系统测试申请v 系统测试申请审批系统测试申请审批v 制定系统测试详细计制定系统测试详细计划划v 执行系统测试准备执行系统测试准备v 系统测试执行系统测试执行v 系统测试总结和评估系统测试总结和评估v 没有制定系统测试详细计划，测试开始之前没有制定系统测试详细计划，测试开始之前测试人员不能明确本次系统测试活动应测试测试人员不能明确本次系统测试活动应测试的测试用例。的测试用例。v 测试执行不按照系统测试详细计划的要求来测试执行不按照系统测试详细
26、计划的要求来做，不能确保计划要求的测试用例都能得到做，不能确保计划要求的测试用例都能得到执行。执行。v 未对测试的原始数据进行纪录。未对测试的原始数据进行纪录。v 本次系统测试新的有效测试规程和测试用例本次系统测试新的有效测试规程和测试用例并未及时给予纪录并管理。并未及时给予纪录并管理。v 项目组和产品线的压力有可能导致测试人员项目组和产品线的压力有可能导致测试人员的测试评估不够客观准确。的测试评估不够客观准确。v 没有有效利用各种自动化测试手段，手工测没有有效利用各种自动化测试手段，手工测试太多。试太多。v 测试用例通过率（百分比）测试用例通过率（百分比） 本次测试中本次测试中通过的用例数通
27、过的用例数/实际执行的用例数；实际执行的用例数；v 测试用例覆盖率（百分比）测试用例覆盖率（百分比） 本次测试中本次测试中实际执行的用例数实际执行的用例数/计划执行的用例数；计划执行的用例数；v 本次测试中测试通过的系统测试用例数目本次测试中测试通过的系统测试用例数目（条）；（条）；v 本次测试中测试不通过的系统测试用例数目本次测试中测试不通过的系统测试用例数目（条）；（条）；v 发现的缺陷数目及缺陷等级（个数、级别）；发现的缺陷数目及缺陷等级（个数、级别）；v 已经解决的缺陷数目及缺陷等级（个数、级已经解决的缺陷数目及缺陷等级（个数、级别）；别）；v 遗留的缺陷数目及缺陷等级（个数、级别）；
28、遗留的缺陷数目及缺陷等级（个数、级别）；v 缺陷密度（分布图）；缺陷密度（分布图）；v 测试的工时（人时）；测试的工时（人时）；v 系统测试的需求覆盖率；系统测试的需求覆盖率；v 项目管理项目管理计划协同、风险管理计划协同、风险管理v 需求管理需求管理测试依据、需求跟踪测试依据、需求跟踪v 设计开发设计开发测试依据和参考测试依据和参考v 配置管理配置管理版本控制、变更控制版本控制、变更控制v 质量保证质量保证过程与产品审核过程与产品审核v 度量度量数据提供和结果反馈数据提供和结果反馈v 中试中试/试验局试验局/初终验初终验用例和测试用例和测试结果参考结果参考v v 应尽早地开始系统测试工作。应
29、尽早地开始系统测试工作。v 充分注意测试中的缺陷密集现象，即对缺陷充分注意测试中的缺陷密集现象，即对缺陷比较密集的部分进行重点测试；比较密集的部分进行重点测试；v 严格执行测试计划，排除测试的随意性。严格执行测试计划，排除测试的随意性。v 对测试过程和测试结果应进行评价，确保测对测试过程和测试结果应进行评价，确保测试过程的有效性。试过程的有效性。v 妥善保存测试计划、测试用例、故障统计和妥善保存测试计划、测试用例、故障统计和最终分析报告，为维护提供方便。最终分析报告，为维护提供方便。v 对于被测试系统要进行正常和异常两方面的对于被测试系统要进行正常和异常两方面的测试。测试。v 在系统测试计划中
30、，要按照资源和项目的要在系统测试计划中，要按照资源和项目的要求清晰地定义一个完整的退出准则，这是一求清晰地定义一个完整的退出准则，这是一种权衡投入产出比的原则，测试既不要不种权衡投入产出比的原则，测试既不要不充分，也不要过分。充分，也不要过分。v 什么是系统测试什么是系统测试v 系统测试的主要内容系统测试的主要内容v 系统测试的过程系统测试的过程v 测试过程改进测试过程改进v 和其他过程一样，规程、人员和工具是主要和其他过程一样，规程、人员和工具是主要因素因素 持续改进的测试规程和方法持续改进的测试规程和方法 良好的测试过程良好的测试过程 不断强化的专业化测试队伍不断强化的专业化测试队伍 自研
31、和外购的多种工具和设备自研和外购的多种工具和设备v 建立并完善完整的测试规程、指导书、模板建立并完善完整的测试规程、指导书、模板体系体系v 健全并严格使用各项测试活动的进入退出准健全并严格使用各项测试活动的进入退出准则则v 细化系统测试的总体和详细计划细化系统测试的总体和详细计划v 改善与开发部门的协调改善与开发部门的协调v 建立并维持需求与测试的双向跟踪建立并维持需求与测试的双向跟踪v 积累并定期分析测试度量数据积累并定期分析测试度量数据 改进估算和计划改进估算和计划 改善测试的量化准则改善测试的量化准则 提高对产品质量的评估能力提高对产品质量的评估能力v 测试人员永远都不会是开发人员的敌人
32、！测试人员永远都不会是开发人员的敌人！v 优化测试组织，协调测试组与系统组、开发优化测试组织，协调测试组与系统组、开发组的分工组的分工v 注重培养测试人员的特殊素质，如责任心、注重培养测试人员的特殊素质，如责任心、知识面、沟通能力、怀疑精神、耐心、专业知识面、沟通能力、怀疑精神、耐心、专业技术等技术等v 定期组织公司内部的测试技术专题研讨和经定期组织公司内部的测试技术专题研讨和经验共享验共享v 投资外购软件测试与管理工具投资外购软件测试与管理工具 工具相对成熟，利于快速引入先进思想和方法工具相对成熟，利于快速引入先进思想和方法 价格高，投资大，大面积应用困难价格高，投资大，大面积应用困难 普遍
33、存在一定的特长与不足普遍存在一定的特长与不足 适用于通讯软件的专用工具尤其少而昂贵适用于通讯软件的专用工具尤其少而昂贵 难以进行适应性改造难以进行适应性改造v 投入人力时间自行开发测试工具投入人力时间自行开发测试工具 有针对性地解决特定问题有针对性地解决特定问题 易于普遍使用和持续改进易于普遍使用和持续改进 研发周期长，见效较慢研发周期长，见效较慢 要求极高的专业素养要求极高的专业素养v 测试工具的普遍问题：多种研发工具协同困测试工具的普遍问题：多种研发工具协同困难难v ISO9000、TL9000、GJB9000v CMM/CMMIv TPI（Test Process Improvement
34、）v TMM（Test Maturity Model）vv 对现有过程水平的测量和评估；对现有过程水平的测量和评估；v 对测量、评估结果的分析，确定改进目标；对测量、评估结果的分析，确定改进目标；v 结合过程改进模型制定相应改进措施；结合过程改进模型制定相应改进措施；v 实施改进措施；实施改进措施；v 验证改进结果，度量新的过程数据；验证改进结果，度量新的过程数据；v 调整措施及制定新的改进目标。调整措施及制定新的改进目标。小插曲需求经常变更怎么办o 需求变更可能会让项目所有成员遭殃，如何需求变更可能会让项目所有成员遭殃，如何“预防变更预防变更”o以及以及“降低变更的代价降低变更的代价”是软件
35、工程的经典问题。本节仅论述是软件工程的经典问题。本节仅论述o需求变更对测试的影响。需求变更对测试的影响。o需求变更将导致软件设计和实现的变更，也导致了测试变更。需求变更将导致软件设计和实现的变更，也导致了测试变更。o最让人难过的是上一次测试有可能白做了，如果软件变更比最让人难过的是上一次测试有可能白做了，如果软件变更比o较大的话。较大的话。小插曲需求经常变更怎么办o测试人员不要只是自认倒霉，应当主动作些应变：测试人员不要只是自认倒霉，应当主动作些应变：o（1 1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按o原计划测试。原计
36、划测试。o（2 2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者o后测试。后测试。o（3 3）向领导反映需求变更对测试造成的影响，为自己争取余地。）向领导反映需求变更对测试造成的影响，为自己争取余地。o（4 4）设计一些比较灵活的测试用例，能适应某些变更（不过技术）设计一些比较灵活的测试用例，能适应某些变更（不过技术o难度比较高）。难度比较高）。小插曲需求经常变更怎么办o引申问题：引申问题：o如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，o该怎么办？该怎么办？o如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。o如果发现软件多了功能，测试人员不可认为这些功能反正是如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上锦上o添花添花”，便自作主张地测试了事。两种情况都要报告给项目经理，便自作主张地测试了事。两种情况都要报告给项目经理，o有可能导致一系列的变更。有可能导致一系列的变更。 欢迎提问和讨论谢谢谢谢
