3XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />
I. 测试的目标
暴露团队必须解决的所有错误
针对规格说明验证验证方案的元素
暴露设计错误
从未料到的用户操作中暴露失败
测试所有的方案元素
测试：访问项目的质量情况
测试是生成的一部分，而不是单独的活动
II. 测试的类型
所有的测试都会暴露方案的错误
测试的类型覆盖方案特点的很大范围
测试应该是在要验证的特点的基础上选择的
III. 进行覆盖测试
覆盖测试
l 试图完全测试方案的每个特性
l 试图完全测试方案的代码库
l 主要用于开发阶段
覆盖测试的类型
l 单元
l 功能
l 检入
l 构建验证
l 回归测试
IV. 执行使用测试
使用测试：
l 试图成功的完成使用情节
l 试图在期待的环境中测试产品
l 主要用于稳定阶段
使用测试的类型
l 配置测试
l 兼容测试
l 压力测试
l 性能测试
l 文档和帮助文件测试
l 可用性测试
V. 错误的性质
不是所有的bug都是错误，但所有的错误都是bug
在发布之前所有的bug都要被复查和解决
bug:在方案的使用过程中引发的所有问题
VI. 有效的管理错误
跟踪结果以认识到测试价值
程序化你的错误跟踪过程
努力为错误分类并排优先级
用错误分析来促进做决定
VII.跟踪错误
报告->排优先级并指派->解决->关闭
VIII. 错误分类
将bug分类使它们可控告
通过以下方式分类：
l 严重性
l 优先级
通过提供bug分类重新估计生成和发布的质量标准
IX. 纠正错误
通过以一致性的方式表达它们来纠正错误
通过为错误系标签来指定如何纠正错误
纠正错误是在关闭它们前的中间步骤
开发阶段的目标是创建方案的多种特性和可提交的物品
日常构建形成的内部的发布周期帮助将复杂项目分解成可管理的任务
测试的目标是访问方案的质量情况
不同类型的测试被用来表达方案的广泛特点
发布之前所有的错误必须被复查和解决
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/10752019/viewspace-963703/ ，如需转载，请注明出处，否则将追究法律责任。
