软件测试外包培训 II

1Copyright©2004LiJian.Allrightsreserved.2004年7月软件外包培训系列软件测试外包独立高级咨询师李健李健提纲•软件测试外包•软件测试基础)软件测试的有效性•软件测试工具技术•软件测试过程•软件测试实施要点李健常见软件测试“失败”ƒ产品或系统不满足质量目标（？）ƒ使用出现简单错误；ƒ每千行源程序发现的缺陷不超过10个；ƒ产品或系统质量：0.04-0.09/defects/FP(平均:0.06/defects/FP)ƒ测试不发现问题太晚，造成返工。（？）ƒ测试不全面。（？）ƒ测试发现的问题定位不准，太表面，发现的多是不重要的问题。（？）2李健测试失效单元测试技术功能测试技术性能测试技术问题管理缺少工具支持问题分析能力差人员不足测试“全才”回归测试技术与开发“敌对”测试经验不足测试职责不清测试团队协作与开发交流不畅开发经验不足同开发接口不清测试范围不清质量目标不清测试需求不明测试对象模糊缺少测试标准与用户缺少沟通缺少测试规划项目组习惯开发Build后测试介入公司测试人力资源紧张项目规划不合适公司资源紧张测试开发共用用户使用环境缺乏了解测试资源不能按时到位与QA交流不畅测试阶段不清测试与开发进度不协调开发测试缺乏统一支持平台复用测试用例少开发环境缺乏了解测试时间太少人员变更李健软件测试现状缺乏责权明确的交流界面、交流氛围；缺乏有效的测试分析；测试效果差测试效率低沟通：开发与测试相互对立，信息不畅；缺乏层次化的测试内容；缺乏对用户使用场景的分析；测试效果差测试内容：对软件系统实施初级功能覆盖测试；有项目成本和测试成本的压力；认为测试不需要过多的技术；测试效果差测试效率低人员：由开发人员承担测试工作；多由低层次人员承担测试工作；成本压力；测试专业化技术缺乏；测试效果差项目的效率低环境资源：开发环境等同测试环境；没有专门的测试资源；缺乏有效的测试规划和策略；缺乏测试过程的改善；测试效果差测试效果：没有明确的测试标准；测试后“演示”定律仍存在，客户实际的简单使用仍能发现普通问题。测试专业化技术缺乏；测试需求简单、单一；测试效果差测试效率低技术：对功能测试手工“使用”测试居多；对性能测试单纯依赖某个工具；缺少测试规划；只有测试阶段，没有测试过程；测试效果差测试时机：软件编码结束后测试工作才开始；测试结束取决于项目的昀后期限；原因问题现象李健改善和提高测试成功率过程技术人质量目标•参与测试的人员需要什么测试技能？•怎样提高测试与其他人员的交流能力？•提升测试的团队协作能力？•合理整合测试的资源、技术、流程、工具等•合理规划软件测试•怎样改善过程？•过程的实施指南等•各类型软件测试特点•质量特性测试技术•测试工具•问题分析技术3李健测试成功因素优先级？测试人员？测试环境（测试软硬件环境）？测试过程（测试规划与测试过程跟踪）？5测试工具技术（怎样实施？）？3测试策略（怎样测？）？2测试需求（测些什么？）？1质量目标（测试要达到什么指标？）优先级影响测试因素李健成功的测试&成功的测试={有效的测试，高效的测试}有效的测试：能够发现大量有效的问题，并能准确定位问题高效的测试：在一定的时间和资源下，发现有效问题多&决定测试成功的因素（质量目标，测试需求，测试策略，测试技术，测试人员，测试过程，测试环境）（1）质量目标：项目产品的达到的质量要求；（2）测试需求：明确测试对象，测试内容；（3）测试策略：明确测试阶段，测试类型；（4）测试技术：测试用例生成、执行的方法，测试问题的跟踪、管理方法；（5）测试人员：负责规划、设计、分析测试的人员，负责执行测试的人员；（6）测试过程：测试从开始到结束的过程；（7）测试环境：测试的硬件、软件环境。李健软件测试的有效性（续）角色职责清楚角色技能要求清楚有效的人员变更管理9测试人员技术的成熟度测试人员的掌握程度工具支持程度对测试类型的覆盖程度9测试技术是否与开发环境一致是否与用户环境一致是否与开发环境隔离9测试环境测试内容对需求的覆盖测试内容的优先等级划分测试内容重要程度的确定测试类型的确定测试阶段的确定9有效的测试策略李健开发“测试需求”ƒ测试需求测试需求体现为软件测试大纲，是一切测试工作的基础。ƒ测试需求与项目需求项目需求通常描述系统能做什么；测试需求描述系统能做什么，而且描述系统不能做什么。获取不同层次的“测试需求”UML中的系统行为模型（UseCase图、活动图、交互图），用户交互点；客户现场跟踪；客户应用历史数据分析。项目需求与测试需求李健“测试需求”的不同层次产品或系统的质量要求：功能、性能、可靠性、安全性、操作性和维护。产品或系统的用户使用场景：验证软件是正确的。（？）产品或系统的系统使用场景：综合负载的系统表现。5李健的测试需求层次系统的质量要求：链接正确、用户个性化管理、并发用户访问数超过500万、数据信息安全、多机备份等；用户使用场景：直接进入新闻频道、科技频道和体育频道系统使用场景：1.每天早上8:30–9:00首页访问量超过300万人次2.重大事件新闻专题首日访问量超过1000万人次李健获取测试层次需求–获取用户场景systemadministrator:...collection:Collectionuser:Userlog:LogcollectData:CollectData1.CreategetUserInfo()ConformData()RecordLog()getDataFromLogFile()InsertData()确定采集项缺省采集项选择日志文件读取数据信息信息整理合并插入信息记录用户交互点李健制订测试计划™估计内容•规模、工作量、进度、成本™估计的技术途径•参数模型估计方式（自顶向下：FP/KLOC/UseCases）•工程估计（自底向上）•类似项目估计（经验值/DELPHI)•应用简单估计关系模型（历史统计数据）•后推法估计方法李健测试工作量估计（基于任务）以产品为中心（WBS）：子系统1-组件1测试组件2测试子系统2-组件1测试组件2测试集成和测试计划测试准备测试执行测试报告测试结果以过程为中心（WBS）：项目初期阶段计划测试项目细化阶段设计测试项目构造阶段集成测试系统测试项目提交阶段验收测试李健测试工作量估计（应用历史数据）其他12%执行50%计划8%设计30%7李健后推法ƒ基于项目产品提交的昀后期限ƒ基于项目可用测试资源ƒ结合测试工作量分布ƒ剪裁测试需求李健测试计划常见“误区”ƒ测试工作量太倾向于功能测试；ƒ不太重视配置测试；ƒ把压力测试和负载测试总是放在“昀后一分钟”（？用例复用）ƒ通常不进行文档测试；ƒ通常不测试安装过程；ƒ过度依赖于Beta测试；ƒ测试任务串行进行；ƒ没有有效识别出项目的风险区域。测试计划李健测试用例ƒ测试用例设计的基本原则测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的，以及极限的输入数据、操作和环境设置等。测试结果的可判定性：即测试执行结果的正确性是可判定的。测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。ƒ测试用例设计的难点测试用例的粒度（影响测试用例的复用）；ƒ测试用例设计的不足过于文档化未掌握测试用例的生命周期（测试用例对应于测试对象）8李健测试用例的可复用设计ƒ影响测试用例复用性的因素测试复用的时机：将在什么时候复用测试用例；测试类型：功能测试---性能测试（细分）测试用例管理：分类/组织，变更管理ƒ测试用例的复用特性同种测试类型的复用（测试用例粒度很重要，不同测试用例的组合）；异种测试类型的复用（测试用例的变更管理很重要)；测试用例李健测试用例管理（误区）ƒ测试重执行轻设计。（软件过程性能衡量质量之一：设计的时间大于编码的时间？？？）（效率低，成本高，质量差）ƒ测试设计未进行评审；ƒ测试输入和规程过于详细、过于精确；ƒ严格按照过程或脚本执行，不关心和探索“不相关”的现象；ƒ检查产品或系统应该做什么，不检查其不应该做什么；ƒ测试用例设计只有作者清楚；ƒ缺陷报告机制贫乏ƒ客户发现问题，仅增加回归测试就可以ƒ客户问题处理缺少可跟踪的记录测试用例粒度9李健测试覆盖ƒ测试覆盖用于测试进度管理ƒ测试覆盖用于衡量测试的完整性ƒ测试覆盖类型功能覆盖：单项功能覆盖、组合功能覆盖场景覆盖：用户使用场景覆盖、系统场景覆盖结构覆盖：语句覆盖、分支覆盖、判定覆盖、路径覆盖状态覆盖：程序对象状态覆盖、系统行为状态覆盖李健结构覆盖误区ƒ过于依赖于单一的代码覆盖指标ƒ因为不贡献语句覆盖率，就减少回归测试内容ƒ把结构覆盖率作为考核测试人员工作业绩的指标ƒ完全抛弃覆盖率10李健提纲•软件测试外包•软件测试基础•软件测试的有效性)软件测试工具技术)软件测试技术•软件测试过程•软件测试实施要点李健软件测试高级技术测试问题引起的变更；需求引起的测试变更；变更管理分析测试过程数据，改善测试过程能力，更有效、高效测试。测试数据分析软件问题全生命周期管理。测试问题管理结构复杂度；圈复杂度；算法复杂度。程序复杂度度量用于覆盖测试（结构覆盖和状态覆盖）和性能测试。插装、模拟技术回归测试阶段用于功能测试、各种性能测试及安装测试等。记录/回放技术用于确定测试目标、获取测试需求和应用场景、设计测试用例和测试脚本，以及测试问题的分析与定位。走查/审查技术应用说明测试高级技术李健正式评审和非正式评审非正式评审（走查）正式评审（审查）一小组人通过开会、电话、电子邮件等对方式工作产品进行评审。•要进行计划•要跟踪•定义过程•定义角色•应用度量•需要进行培训