培训教材4-软件系统测试.ppt

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