小苏子
小苏子PDF在线图书

软件测试实战 微软技术专家经验总结 内容简介

软件测试实战 微软技术专家经验总结 内容简介

软件测试实战 微软技术专家经验总结 目录

软件测试实战 微软技术专家经验总结 精彩文摘

《软件测试实战:微软技术专家经验总结》从多个角度讨论了测试人员的实际工作,包括缺陷报告、测试文档、测试建模、测试设计、测试自动化、研究产品、研究项目环境、测试管理、个人管理、实践案例等。书中崭新的观念与技术将有助于读者更好地提交缺陷报告,在项目末期的缺陷压力下更好地做回归测试。《软件测试实战:微软技术专家经验总结》适用于测试新手以及初级测试人员。第1章 软件测试基础1.1 软件的复杂度已经超越了人的理解能力1.2 软件测试是获取信息的技术调查1.3 测试是迭代过程1.4 测试人员的工作效率取决于他对软件和项目的理解,而不是他掌握的测试技术1.5 小结第2章 缺陷报告2.1 报告缺陷是为了让缺陷得到修复2.2 高质量的缺陷报告来自于高质量的测试2.2.1 分配测试时间2.2.2 通过技术调查发现更多的信息2.2.3 处理难以重现的缺陷2.3 编写高质量的缺陷报告2.3.1 为每一个缺陷单独提交一份缺陷报告,小缺陷也是如此2.3.2 仔细编写缺陷报告的标题2.3.3 像编写详细测试用例那样编写重现步骤2.3.4 使用缺陷模板来提交缺陷2.3.5 在编写缺陷报告时,要考虑缺陷查询2.3.6 链接相关的缺陷2.3.7 注意缺陷报告的可读性2.3.8 客观中立地书写缺陷报告2.4 对不予修复的缺陷进行上诉2.5 周密地测试缺陷修复2.6 坚持阅读缺陷报告2.7 小结第3章 测试文档3.1 测试文档是持续演化的工具3.1.1 测试文档是提供测试信息的一组文档3.1.2 在测试中演化测试文档3.1.3 注重实效的测试文档3.2 形形色色的测试文档3.2.1 测试计划3.2.2 Google ACC3.2.3 测试设计规约3.2.4 功能列表3.2.5 大纲与思维导图3.2.6 表格(矩阵)3.2.7 测试指南3.2.8 测试想法列表3.2.9 质量特性列表3.2.10 操作文档3.2.11 检查列表3.2.12 缺陷目录3.2.13 测程表3.2.14 移交文档3.3 在测试中发展测试文档3.3.1 初始测试文档3.3.2 发展测试文档3.4 小结第4章 测试建模4.1 从组合测试看建模的重要性4.1.1 组合测试简介4.1.2 根据语境来完善组合测试的模型4.1.3 测试建模的基本点4.2 常用测试建模方法4.2.1 启发式测试策略模型4.2.2 输入与输出模型4.2.3 系统生态图4.2.4 实体关系模型4.2.5 状态机模型4.2.6 多种多样的模型4.3 小结第5章 测试技术5.1 测试技术分类系统5.2 启发式方法5.3 测试先知5.3.1 测试先知的定义5.3.2 FEW HICCUPPS5.3.3 约束检查5.4 漫游测试5.4.1 基本漫游方法5.4.2 基于旅行者隐喻的漫游方法5.4.3 移动测试漫游方法5.4.4 实施漫游测试5.5 快速测试5.5.1 James Bach的方法5.5.2 Cem Kaner的方法5.5.3 James Whittaker的方法5.6 情景测试5.6.1 基本方法5.6.2 设计用户角色5.6.3 情景测试与漫游测试5.6.4 肥皂剧测试5.6.5 虚拟业务5.7 多样地选择测试技术5.8 小结第6章 测试开发6.1 测试开发分类6.2 注重实效的自动化测试6.2.1 自动化测试的基本策略6.2.2 将测试开发视作软件开发6.2.3 利用自动化测试金字塔来指导测试开发6.2.4 面向调试的测试代码6.2.5 系统测试的测试开发6.2.6 让自动化测试服务于项目6.3 计算机辅助测试6.3.1 “交通工具”的隐喻6.3.2 选择合适的开发技术6.4 大规模自动化测试6.4.1 基本概念6.4.2 测试设计6.5 小结第7章 研究产品7.1 静态分析7.1.1 浏览源代码来理解产品实现7.1.2 分析源代码来帮助测试设计7.1.3 黑盒测试并不是基于无知的测试7.2 动态分析7.2.1 用工具分析产品的行为7.2.2 在调试器中观察软件行为7.3 业务研究7.3.1 理解关系人7.3.2 评审需求文档7.3.3 通过测试来研究7.3.4 利用互联网资源7.3.5 领域研究7.4 研究策略7.5 小结第8章 研究项目8.1 项目团队8.1.1 了解团队组织8.1.2 语境独立的启发式问题8.1.3 了解团队成员8.2 面向测试的项目分析8.2.1 软件缺陷8.2.2 源代码8.2.3 构建8.2.4 自动化测试8.3 基于风险的测试8.3.1 通过测试调查风险8.3.2 失败模式8.3.3 项目级别的风险8.4 小结第9章 团队工作9.1 工作风格9.1.1 测试人员通过服务团队来体现自己的价值9.1.2 测试人员应该正直9.1.3 测试人员的影响力来自于出色的工作9.1.4 信任程序员的努力,并用技术调查检验其工作9.2 测试管理9.2.1 个人测试计划应该是项目测试计划的延伸9.2.2 制订个人测试计划时应该综合考虑各种项目元素9.2.3 测试需要动态管理9.3 软件估算9.3.1 测试人员应该估算自己的任务9.3.2 用计数和计算作为估算手段9.3.3 历史数据是估算的重要参考9.3.4 同时估算最差情况和最好情况9.4 度量9.4.1 理解度量方法的基本元素9.4.2 明确度量的目标9.4.3 掌握属性和算法的联系9.4.4 理解度量方法的优点和缺点9.4.5 密切关注度量的副作用9.4.6 注重实效的计算9.5 测试小组9.5.1 价值观9.5.2 团队建设9.6 小结第10章 个人管理10.1 时间管理10.1.1 利用任务清单记录所有工作项10.1.2 坚持周计划和每日回顾10.1.3 专注是高效工作的前提10.1.4 恰到好处的文档化和自动化10.2 持续学习10.2.1 在工作中学习10.2.2 持续阅读10.3 且行且思10.4 成为专家10.5 小结参考文献在许多项目环境中,缺陷报告是测试人员最主要的工作产出,是将测试人员和项目团队广泛联系在一起的纽带。程序员会阅读缺陷报告,以了解缺陷的症状和重现步骤。好的缺陷报告能帮助他快速地定位问题;差的缺陷报告会浪费他的调试时间。产品经理会阅读缺陷报告,以了解缺陷的症状和严重性。好的缺陷报告准确地传递了用户质量的信息,帮助他设定修复优先级;差的缺陷报告会误导他作出错误决定,甚至将一些严重的缺陷标记为“不予修复”。在一些团队,产品经理、开发经理和测试经理会举行缺陷评审会议,对缺陷是否修复进行“最终判决”。好的缺陷报告会提高会议效率;差的缺陷报告会降低会议效率,甚至让评审小组作出错误的决策。

赞(0)
未经允许不得转载:小苏子图书 » 软件测试实战 微软技术专家经验总结 内容简介