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

不了解软件测试做什么和它包括什么。
开发软件的公司没有标准化的开发和管理程序
没有想到要开发高水平的软件，须有高水平的测试人员

造成测试人员心理负担，影响工作热情
造成测试人员短缺和人员流失
直接影响产品质量

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

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

任务繁重
过于紧凑的时间表
压力大的工作环境
测试和开发规程管理不当

疲劳过度、精神负担
仓促交付工作，质量差
开发项目编码进度延误

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

没任何选择
知道测试辅助工具的重要性，但没到位
不知道所需辅助工具应有何种功能

外部购买的太贵
外部购买的多数不直接适用
公司内部没有技术资源开发
公司内部没有时间开发
技术上不直接支持

只能依赖手动测试
容易疲劳、精神负担
仓促交付工作，质量差
开发项目编码进度延误

在产品设计阶段，就应考虑到测试所需的辅助工具支持
研究最佳可用辅助工具，效益分析
分析产品特点，确定辅助工具以应有的功能
自己设计和研发
微软实践：
1.设专人开发、维护
2.不断改进自己开发的自动化测试辅助工具
3.各产品团队鼓励自己开发测试辅助工具
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í....￡.

希望做到想用户所想，但做不到
希望产品发行后用户满意度高，但不知怎样才能做到

没发行的新功能设计保密
缺少和用户直接接触的时间和机会
缺乏用户使用研究（Usability study）专家

有时对用户期望行为判断错误
遗漏重要用户使用场景测试
影响用户满意度

用户访问
市场调查
积极参加用户试用产品研究（usability
study）
研究用户发现的缺陷(OFFBUG)
收集用户文档
帮助产品售后服务支持
访问用户答疑网站

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

不定性：产品质量涉及很多不定因素，很难准确度量
难定量化性：测试功能的质量本身就难定量化
复杂性：产品本身太多功能有互动作用

缺少质量管理和决策的依据
已有的度量，如分析或使用不当，会导致错误结论和判断
测试人员必须靠经验和理解判断何时何条件下认为测试完成

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

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

测试案例格式不同
内容覆盖的测试范围差异很大
有些太笼统
有些包括很多子案例
测试人员理解能力不同
时间不允许测试很细

很难估计所需测试时间和所需资源
对执行完测试案例的解释可能造成误解
不同测试人员所需时间和测试范围相差甚远

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

功能稳定程度不够
自动化辅助工具没能到位
自动化辅助工具需很长时间安装和调试
手动测试都来不及
编写自动化脚本太花时间
没有认识到实现自动化测试的必要性和重要性

没有自动化脚本持续运行，很难保证已测过的功
能保持正常工作，因此很难保证总体测试质量和
产品的稳定性

原则：一定要想办法实现自动化测试！越多越好！
明确自动化测试的好处和重要性
提出你的要求！
提早计划
借用现有资源
合并有关联的测试
多选择多问
形成日常测试任务
每周一两天

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

没有时间写详细的文档
接外包测试项目时就没有
测试的是旧功能(legacy features)

没有参照可循、等于没有标准
依赖测试人员专业水平和对产品的理解
很难判断和估计测试范围、所需时间
很难保证测试质量
对测试人员造成更大的压力

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

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

测试人手不够
测试管理考虑不周
测试计划不当
测试人员经验和技术水平欠缺

管理混乱
测试质量差
没测完就匆忙交付
耽误交付日期
测试人员精神心理压力大

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

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

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