(转载)软件测试人员面临的挑战与机遇

来源:互联网 发布:数据挖掘预测算法 编辑:程序博客网 时间:2024/04/29 10:25
2006年01月18日 13:17:00

作者介绍:
张奭(Zhang Shi),英文名是Kelly Zhang
KellyZ@Microsoft.com
软件开发测试主管
Microsoft Office国际服务测试部 美国微软总部
教育背景:北京师范大学获得学士和硕士学
位。美国纽约州立大学获得博士学位
工作经验:近九年软件测试,测试项目主管,和发布协调总管工作经验


内容目录
一.项目管理、开发和测试的三方合作
二.测试人员常面临的十大挑战和应对策略
三.我们的机遇

一、项目管理、开发和测试的三方合作
产品项目管理、开发与测试同等重要、缺一不可:三足鼎立
三方需要互相理解、支持、协作与帮助

二测试人员常面临的十大挑战和应对策略
1.测试人员被认为低人一等
2.测试时间永远不够
3.缺乏简单易用的测试辅助工具
4.缺乏具体通用的测试技术
5.很难清楚了解用户需求和期望
6.缺乏可明确衡量测试质量达标的度量
7.很难确定一个测试实例是否执行完毕
8.很难找时间作自动化测试
9.测试所需文档经常不全
10.很多任务在身,很难保质保量

1 测试人员被认为低人一等
很严重的错误理解*:在软件企业的工作选择中,软件测试人员只不过是初学者(entry level)的职位*
对软件测试的偏见:
1.是测试人员在耽误和阻挠软件产品的按时发布
2.如果发布的产品有缺陷,那测试人员应该负责
3.开发人员须经过特殊训练,测试人员就用不着
4.测试工作比开发工作容易多了
*资料来源:Ron Patton (2001) 《Software Testing》bySamsPublishing

挑战之一:原因和后果
原因:
不了解软件测试做什么和它包括什么。
开发软件的公司没有标准化的开发和管理程序
没有想到要开发高水平的软件,须有高水平的测试人员
后果:
造成测试人员心理负担,影响工作热情
造成测试人员短缺和人员流失
直接影响产品质量

十大挑战之一:应对策略
树立信心!大趋势:软件测试工作已越来越多地得到重视
理解原因,端正心态,正确对待
注重技术水平提高,让实践证明我们的价值
公司里建立良好的工作关系
勇于提出建设性的意见

2 测试时间永远不够
测试工作总是不能按时完成
要测试的总是比有时间测试的工作量多得多
测试人员很难决定最佳有效测试范围
没有时间按部就班发挥测试最好水平

挑战之二:原因和后果
原因:
任务繁重
过于紧凑的时间表
压力大的工作环境
测试和开发规程管理不当


个人原因
后果:
疲劳过度、精神负担
仓促交付工作,质量差
开发项目编码进度延误

十大挑战之二:应对策略
个人:自我调节为主,请求帮助为辅
随时分析自己的测试任务,分清优先顺序
事先作多种准备(几套方案、不同测试范围)
风险分析和管理
及时沟通.提早向上级反映
提出建设性改进措施

3 缺乏简单易用的测试辅助工具
没任何选择
知道测试辅助工具的重要性,但没到位
不知道所需辅助工具应有何种功能

挑战之三:原因和后果
原因:
外部购买的太贵
外部购买的多数不直接适用
公司内部没有技术资源开发
公司内部没有时间开发
技术上不直接支持
后果:
只能依赖手动测试
容易疲劳、精神负担
仓促交付工作,质量差
开发项目编码进度延误

十大挑战之三:应对策略
在产品设计阶段,就应考虑到测试所需的辅助工具支持
研究最佳可用辅助工具,效益分析
分析产品特点,确定辅助工具以应有的功能
自己设计和研发
微软实践:
1.设专人开发、维护
2.不断改进自己开发的自动化测试辅助工具
3.各产品团队鼓励自己开发测试辅助工具
4.奖励和推广发明创造

4 缺乏具体通用的测试技术
1.黑箱、白箱、灰箱测试
2.安全性测试
3.性能测试
4.自动化测试

挑战之四:原因和后果
原因:
软件产品的多样性
软件总是有缺陷
没有可适用于所有软件的测试方法
测试技术没有固定的规则
测试是一项连续不断进行的实践
后果:
影响测试质量和效率
增加测试难度
需要时间尝试和确定测试方法

软件产品的多样性
办公室和商业用软件(Office and Business Applications)
游戏类软件(Games)
数据库软件(Database)
互联网/网站用软件(Internet/websites)
操作系统软件(Operation system)
多媒体和动画软件(Multimedia & Animation )
图像处理和文字出版编辑软件(Graphics and Publishing)
语音识别(Speech)
手写体识别以及拼音输入法(Handwriting, OCR and User Input
Editor:IME)

软件总是有缺陷
1.软件本身功能的复杂性(Software complexity )
2.源代码编译过程的系统错误(Compiling and integration
error )
3.编码时的人为程序错误(Coding/programming errors )
4.设计规范文档本身的问题(Poorly documented spec and
design )
5.人为的的信息交流失误(Poor communication among testers, PM
and programmers)
6.过于紧凑的时间表和压力大的工作环境(Tight schedule and
high pressure working environment)
7.改变设计要求(Changed design requirement )
8.在软件开发辅助工具中的缺陷(Flaws in the software
development tools )

十大挑战之四:应对策略
研究和比较可用技术
提高灵活使用现有技术的能力
学习、应用和推广最佳实践
自我改进、团队互助
经常交流、研讨适合自己产品的最佳测试技术
Explosion 1: .ò..óD.....¢.1oí....£.
5 很难清楚了解用户需求和期望
希望做到想用户所想,但做不到
希望产品发行后用户满意度高,但不知怎样才能做到

挑战之五:原因和后果
原因:
没发行的新功能设计保密
缺少和用户直接接触的时间和机会
缺乏用户使用研究(Usability study)专家
后果:
有时对用户期望行为判断错误
遗漏重要用户使用场景测试
影响用户满意度

十大挑战之五:应对策略
用户访问
市场调查
积极参加用户试用产品研究(usability
study)
研究用户发现的缺陷(OFFBUG)
收集用户文档
帮助产品售后服务支持
访问用户答疑网站

6 缺乏可明确衡量测试质量达标的度量
什么条件下可认为测试的产品和功能达到质量标准?
多是经验积累,并非科学可靠
很多数量化的度量并非全面和准确
比如:
缺陷数量变化趋势、自动化脚本代码覆盖率
测试案例100%通过也不意味着测试完毕
测试脚本运行100%通过也不等于该功能测试完毕

挑战之六:原因和后果
原因:
不定性:产品质量涉及很多不定因素,很难准确度量
难定量化性:测试功能的质量本身就难定量化
复杂性:产品本身太多功能有互动作用
后果:
缺少质量管理和决策的依据
已有的度量,如分析或使用不当,会导致错误结论和判断
测试人员必须靠经验和理解判断何时何条件下认为测试完

十大挑战之六:应对策略
找出可用质量度量,对比分析
研究适用于自己产品质量的度量
明确使用数量化度量时的注意事项
数量化度量和经验判断并用
‘Good enough'
注意:测试完成与否有很大程度上的经验判断因素,所以单
一依赖定量化的度量是不正确的
建议:参考另一讲座:"软件产品质量度量"

7 很难确定一个测试案例是否执行完毕
理解内容,但测试的深度和广度相差太多,很难确
定测试范围和所需时间
举例:验证不同地区语言设定条件下,Microsoft
Excel的日期函数=TODAY()随之变化
有些包括很多子案例
注意:
写出的测试案例覆盖的测试可能只是应该测试范围的一小部分!

挑战之七:原因和后果
原因:
测试案例格式不同
内容覆盖的测试范围差异很大
有些太笼统
有些包括很多子案例
测试人员理解能力不同
时间不允许测试很细
后果:
很难估计所需测试时间和所需资源
对执行完测试案例的解释可能造成误解
不同测试人员所需时间和测试范围相差甚远

十大挑战之七:应对策略
事先明确执行测试案例的目的和可用时间
对外包测试项目更是要了解客户期望
原则:对产品对用户负责!
沟通!不清楚就问
充分发挥测试水平:即最大可能全面地测试
实现测试的自动化

8 很难找最佳时间作自动化测试
自动化测试运行结果是非常重要的产品质
量度量(指标)之一,没有合理的自动化测
试覆盖率,很可能造成重要缺陷的遗漏,
进而造成产品质量差
功能不够稳定时,没有可能,功能稳定是其他测
试任务也需要执行
设立编写自动化脚本的环境很费时间和精力
编写自动化脚本、调试和纠错似乎比手动测试时
间多

挑战之八:原因和后果
原因:
功能稳定程度不够
自动化辅助工具没能到位
自动化辅助工具需很长时间安装和调试
手动测试都来不及
编写自动化脚本太花时间
没有认识到实现自动化测试的必要性和重要性
后果:
没有自动化脚本持续运行,很难保证已测过的功
能保持正常工作,因此很难保证总体测试质量和
产品的稳定性

十大挑战之八:应对策略
原则:一定要想办法实现自动化测试!越多越好!
明确自动化测试的好处和重要性
提出你的要求!
提早计划
借用现有资源
合并有关联的测试
多选择多问
形成日常测试任务
每周一两天

9 测试所需文档经常不全
缺少功能设计文档
功能设计文档不够详细或有遗漏部分
缺少测试计划
缺少测试规范和案例
现有测试文档不够详细或有遗漏部分

挑战之九:原因和后果
原因:
没有时间写详细的文档
接外包测试项目时就没有
测试的是旧功能(legacy features)
后果:
没有参照可循、等于没有标准
依赖测试人员专业水平和对产品的理解
很难判断和估计测试范围、所需时间
很难保证测试质量
对测试人员造成更大的压力

十大挑战之九:应对策略
事先设立有关开发规程使测试所需文档按时到位
和项目管理、开发人员等有关人员沟通,使他们了解开
发和测试所需文档的重要性
想方设法收集有关功能设计信息,存档
管理部门计划设立文档所需资源,并监督执行
测试人员尽最大努力学习和理解所测功能,列出测试计
划/规范,邀请有关人员评审
测试人员事先与测试领导沟通潜在的测试质量风险

10 很多任务在身,很难保质保量
每个测试人员同时负责几个甚至几十个功能测试
每项测试都要花很多时间
每项测试都应该有测试的自动化覆盖
有时若干测试任务要同时进行

挑战之十:原因和后果
原因:
测试人手不够
测试管理考虑不周
测试计划不当
测试人员经验和技术水平欠缺
后果:
管理混乱
测试质量差
没测完就匆忙交付
耽误交付日期
测试人员精神心理压力大

十大挑战之十:应对策略
测试管理负责人应事先考虑优化分配功能
有明确的责任范围,全盘考虑、权衡
测试的自动化
测试任务清单,计划、记录、追踪进度。(演示roadmap)
按照里程碑或其他产品进度考虑,分清优先次序
根据功能本身稳定状况确定优先次序
尽量考虑结合几项任务一起进行
及时汇报、沟通情况
保证重点

软件产品生命周期测试任务路程计划图

三我们的机遇
软件产业蒸蒸日上
亲身参加我国赶超世界先进水平的竞争
就业机会多
锻炼提高个人素质
挑战性的环境更锻炼人
需要研发适合我国实际状况的最佳测试技术、方法、管理
武装起来,迎接挑战!

我们的使命和重担
我们测试人员应怎样武装自己,迎接新时代软件
测试的需求和挑战??
使命:为我国软件测试领域赶超世界先进水平贡
献我们的最大力量!
从现在做起:培养优秀测试技术和管理人才
行业
公司/企业
部门/团队
自己!

问题解答?
谢谢大家!欢迎交流!



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=582908


原创粉丝点击