软件测试人员面临的挑战与机遇课件

上传人:我*** 文档编号:142468450 上传时间:2020-08-19 格式:PPT 页数:41 大小:208KB
返回 下载 相关 举报
软件测试人员面临的挑战与机遇课件_第1页
第1页 / 共41页
软件测试人员面临的挑战与机遇课件_第2页
第2页 / 共41页
软件测试人员面临的挑战与机遇课件_第3页
第3页 / 共41页
软件测试人员面临的挑战与机遇课件_第4页
第4页 / 共41页
软件测试人员面临的挑战与机遇课件_第5页
第5页 / 共41页
点击查看更多>>
资源描述

《软件测试人员面临的挑战与机遇课件》由会员分享,可在线阅读,更多相关《软件测试人员面临的挑战与机遇课件(41页珍藏版)》请在金锄头文库上搜索。

1、软件测试人员面临的挑战与机遇,张奭(Kelly Zhang) KellyZM 软件开发测试主管 Microsoft Office国际服务测试部 美国微软总部,张奭(Zhang Shi),英文名是Kelly Zhang.软件开发测试主管。美国微软总部,Microsoft Office 国际服务部。 教育背景:北京师范大学获得学士和硕士学位。美国纽约州立大学获得博士学位 工作经验: 近九年软件测试,测试项目主管,和发布协调总管工作经验,自我简介,3,内容目录,项目管理、开发和测试的三方合作 测试人员常面临的十大挑战和应对策略 我们的机遇 问题解答,4,一 项目管理、开发和测试的三方合作,产品项目管

2、理、开发与测试同等重要、缺一不可:三足鼎立 三方需要互相理解、支持、协作与帮助,5,二 测试人员常面临的十大挑战和应对策略,测试人员被认为低人一等 测试时间永远不够 缺乏简单易用的测试辅助工具 缺乏具体通用的测试技术 很难清楚了解用户需求和期望 缺乏可明确衡量测试质量达标的度量 很难确定一个测试实例是否执行完毕 很难找时间作自动化测试 测试所需文档经常不全 很多任务在身,很难保质保量,6,1 测试人员被认为低人一等,很严重的错误理解*:在软件企业的工作选择中,软件测试人员只不过是初学者(entry level)的职位* 对软件测试的偏见: 是测试人员在耽误和阻挠软件产品的按时发布 如果发布的产

3、品有缺陷,那测试人员应该负责 开发人员须经过特殊训练,测试人员就用不着 测试工作比开发工作容易多了,*资料来源:Ron Patton (2001) Software Testingby Sams Publishing,7,挑战之一:原因和后果,原因: 不了解软件测试做什么和它包括什么。 开发软件的公司没有标准化的开发和管理程序 没有想到要开发高水平的软件,须有高水平的测试人员 后果: 造成测试人员心理负担,影响工作热情 造成测试人员短缺和人员流失 直接影响产品质量,8,十大挑战之一:应对策略,树立信心!大趋势:软件测试工作已越来越多地得到重视 理解原因,端正心态,正确对待 注重技术水平提高,让

4、实践证明我们的价值 公司里建立良好的工作关系 勇于提出建设性的意见,9,2 测试时间永远不够,测试工作总是不能按时完成 要测试的总是比有时间测试的工作量多得多 测试人员很难决定最佳有效测试范围 没有时间按部就班发挥测试最好水平,10,挑战之二:原因和后果,原因: 任务繁重 过于紧凑的时间表 压力大的工作环境 测试和开发规程管理不当 个人原因 后果: 疲劳过度、精神负担 仓促交付工作,质量差 开发项目编码进度延误,11,十大挑战之二:应对策略,个人:自我调节为主,请求帮助为辅 随时分析自己的测试任务,分清优先顺序 事先作多种准备(几套方案、不同测试范围) 风险分析和管理 及时沟通.提早向上级反映

5、 提出建设性改进措施,12,3 缺乏简单易用的测试辅助工具,没任何选择 知道测试辅助工具的重要性,但没到位 不知道所需辅助工具应有何种功能,13,挑战之三:原因和后果,原因: 外部购买的太贵 外部购买的多数不直接适用 公司内部没有技术资源开发 公司内部没有时间开发 技术上不直接支持 后果: 只能依赖手动测试 容易疲劳、精神负担 仓促交付工作,质量差 开发项目编码进度延误,14,十大挑战之三:应对策略,在产品设计阶段,就应考虑到测试所需的辅助工具支持 研究最佳可用辅助工具,效益分析 分析产品特点,确定辅助工具以应有的功能 自己设计和研发 微软实践: 设专人开发、维护 不断改进自己开发的自动化测试

6、辅助工具 各产品团队鼓励自己开发测试辅助工具 奖励和推广发明创造,15,4 缺乏具体通用的测试技术,黑箱、白箱、灰箱测试 安全性测试 性能测试 自动化测试,16,挑战之四:原因和后果,原因: 软件产品的多样性 软件总是有缺陷 没有可适用于所有软件的测试方法 测试技术没有固定的规则 测试是一项连续不断进行的实践 后果: 影响测试质量和效率 增加测试难度 需要时间尝试和确定测试方法,17,软件产品的多样性,办公室和商业用软件 (Office and Business Applications) 游戏类软件 (Games) 数据库软件 (Database) 互联网/网站用软件 (Internet/w

7、ebsites) 操作系统软件 (Operation system) 多媒体和动画软件 (Multimedia & Animation ) 图像处理和文字出版编辑软件 (Graphics and Publishing) 语音识别( Speech) 手写体识别以及拼音输入法 (Handwriting, OCR and User Input Editor:IME),18,软件总是有缺陷,软件本身功能的复杂性 (Software complexity ) 源代码编译过程的系统错误(Compiling and integration error ) 编码时的人为程序错误( Coding/program

8、ming errors ) 设计规范文档本身的问题 (Poorly documented spec and design ) 人为的的信息交流失误( Poor communication among testers, PM and programmers) 过于紧凑的时间表和压力大的工作环境 (Tight schedule and high pressure working environment) 改变设计要求 (Changed design requirement ) 在软件开发辅助工具中的缺陷( Flaws in the software development tools ),19,十

9、大挑战之四:应对策略,研究和比较可用技术 提高灵活使用现有技术的能力 学习、应用和推广最佳实践 自我改进、团队互助 经常交流、研讨适合自己产品的最佳测试技术,我们有空间发展和改进!,20,5 很难清楚了解用户需求和期望,希望做到想用户所想,但做不到 希望产品发行后用户满意度高,但不知怎样才能做到,21,挑战之五:原因和后果,原因: 没发行的新功能设计保密 缺少和用户直接接触的时间和机会 缺乏用户使用研究(Usability study)专家 后果: 有时对用户期望行为判断错误 遗漏重要用户使用场景测试 影响用户满意度,22,十大挑战之五:应对策略,用户访问 市场调查 积极参加用户试用产品研究(

10、usability study) 研究用户发现的缺陷(OFFBUG) 收集用户文档 帮助产品售后服务支持 访问用户答疑网站,23,6 缺乏可明确衡量测试质量达标的度量,什么条件下可认为测试的产品和功能达到质量标准? 多是经验积累,并非科学可靠 很多数量化的度量并非全面和准确 比如: 缺陷数量变化趋势、自动化脚本代码覆盖率 测试案例100%通过也不意味着测试完毕 测试脚本运行100%通过也不等于该功能测试完毕,24,挑战之六:原因和后果,原因: 不定性:产品质量涉及很多不定因素,很难准确度量 难定量化性:测试功能的质量本身就难定量化 复杂性:产品本身太多功能有互动作用 后果: 缺少质量管理和决策

11、的依据 已有的度量,如分析或使用不当,会导致错误结论和判断 测试人员必须靠经验和理解判断何时何条件下认为测试完成,25,十大挑战之六:应对策略,找出可用质量度量,对比分析 研究适用于自己产品质量的度量 明确使用数量化度量时的注意事项 数量化度量和经验判断并用 Good enough 注意:测试完成与否有很大程度上的经验判断因素,所以单一依赖定量化的度量是不正确的 建议:参考另一讲座:“软件产品质量度量”,26,7 很难确定一个测试案例是否执行完毕,理解内容,但测试的深度和广度相差太多,很难确定测试范围和所需时间 举例:验证不同地区语言设定条件下,Microsoft Excel的日期函数=TOD

12、AY()随之变化 有些包括很多子案例 注意: 写出的测试案例覆盖的测试可能只是应该测试范围的一小部分!,27,挑战之七:原因和后果,原因: 测试案例格式不同 内容覆盖的测试范围差异很大 有些太笼统 有些包括很多子案例 测试人员理解能力不同 时间不允许测试很细 后果: 很难估计所需测试时间和所需资源 对执行完测试案例的解释可能造成误解 不同测试人员所需时间和测试范围相差甚远,28,十大挑战之七:应对策略,事先明确执行测试案例的目的和可用时间 对外包测试项目更是要了解客户期望 原则:对产品对用户负责! 沟通!不清楚就问 充分发挥测试水平:即最大可能全面地测试 实现测试的自动化,29,8 很难找最佳

13、时间作自动化测试,自动化测试运行结果是非常重要的产品质量度量(指标)之一,没有合理的自动化测试覆盖率,很可能造成重要缺陷的遗漏,进而造成产品质量差 功能不够稳定时,没有可能,功能稳定是其他测试任务也需要执行 设立编写自动化脚本的环境很费时间和精力 编写自动化脚本、调试和纠错似乎比手动测试时间多,30,挑战之八:原因和后果,原因: 功能稳定程度不够 自动化辅助工具没能到位 自动化辅助工具需很长时间安装和调试 手动测试都来不及 编写自动化脚本太花时间 没有认识到实现自动化测试的必要性和重要性 后果: 没有自动化脚本持续运行,很难保证已测过的功能保持正常工作,因此很难保证总体测试质量和产品的稳定性,

14、31,十大挑战之八:应对策略,原则:一定要想办法实现自动化测试!越多越好! 明确自动化测试的好处和重要性 提出你的要求! 提早计划 借用现有资源 合并有关联的测试 多选择多问 形成日常测试任务 每周一两天,32,9 测试所需文档经常不全,缺少功能设计文档 功能设计文档不够详细或有遗漏部分 缺少测试计划 缺少测试规范和案例 现有测试文档不够详细或有遗漏部分,33,挑战之九:原因和后果,原因: 没有时间写详细的文档 接外包测试项目时就没有 测试的是旧功能(legacy features) 后果: 没有参照可循、等于没有标准 依赖测试人员专业水平和对产品的理解 很难判断和估计测试范围、所需时间 很难

15、保证测试质量 对测试人员造成更大的压力,34,十大挑战之九:应对策略,事先设立有关开发规程使测试所需文档按时到位 和项目管理、开发人员等有关人员沟通,使他们了解开发和测试所需文档的重要性 想方设法收集有关功能设计信息,存档 管理部门计划设立文档所需资源,并监督执行 测试人员尽最大努力学习和理解所测功能,列出测试计划/规范,邀请有关人员评审 测试人员事先与测试领导沟通潜在的测试质量风险,35,10 很多任务在身,很难保质保量,每个测试人员同时负责几个甚至几十个功能测试 每项测试都要花很多时间 每项测试都应该有测试的自动化覆盖 有时若干测试任务要同时进行,36,挑战之十:原因和后果,原因: 测试人

16、手不够 测试管理考虑不周 测试计划不当 测试人员经验和技术水平欠缺 后果: 管理混乱 测试质量差 没测完就匆忙交付 耽误交付日期 测试人员精神心理压力大,37,十大挑战之十:应对策略,测试管理负责人应事先考虑优化分配功能 有明确的责任范围,全盘考虑、权衡 测试的自动化 测试任务清单,计划、记录、追踪进度。(演示roadmap) 按照里程碑或其他产品进度考虑,分清优先次序 根据功能本身稳定状况确定优先次序 尽量考虑结合几项任务一起进行 及时汇报、沟通情况 保证重点,38,软件产品生命周期测试任务路程计划图,39,三 我们的机遇,软件产业蒸蒸日上 亲身参加我国赶超世界先进水平的竞争 就业机会多 锻炼提高个人素质 挑战性的环境更锻炼人 需要研发适合我国实际状况的最佳测试技术、方法、管理 武装起来,迎接挑战!,40,我们的使命和重担,我们测试人员应怎样武装自己,迎接新时代软件测试的需求和挑战? 使命:为我国软件测试领域赶超世界先进水平贡献我们的最大力量! 从现在做起:培养优秀测试技术和管理人才 行业 公司/企业 部门/团队 自己!,41,问题解答? 谢谢大家!欢迎交流!,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > PPT模板库 > PPT素材/模板

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号