《软件测试经验与教训》读书笔记---第五章

《软件测试经验与教训》读书笔记--目录

第一章 测试员的角色
第二章 按测试员的方式思考
第三章 测试手段
第四章 程序错误分析
第五章 测试自动化
第六章 测试文档
第七章 与程序员交互
第八章 管理测试项目
第九章 测试小组的管理
第十章 软件测试职业发展
第十一章 计划测试策略

第五章  测试自动化

为什么不让软件测试软件？

经验102. 加快开发过程，而不是试图在测试上省钱
支持开发节奏的手段：自动化冒烟测试、自动化单元测试

经验103. 拓展测试领域，不要不断重复相同的测试

• 负载测试，多人使用被测软件
• 性能基准测试，系统的性能是越来越好还是越来越差---自动化测试，捕获时间度量参数
• 配置测试，不同平台、不同配置上运行
• 耐力测试，系统长时间运行一系列测试用例
• 竞争测试，竞争同一资源的两个线程或进程的时序重叠，可能会产生叫做竞争条件的错误

经验104. 根据自己的背景选择自动化测试策略

经验105. 不强求100%的自动化

经验106. 测试工具并不是策略

经验107. 不要太过自动化使无序情况更严重
如果测试设计得很差，则自动化会使差的测试执行得更快。如果测试组织得很差，则自动化计划会使情况更糟

经验108. 不要把手工测试与自动化测试等同起来

经验109. 不要根据测试运行的频率来估计测试的价值
测试本身是不可比较的；比较自动化测试的运行成本，比方说50次，与手工50次运行同样测试的成本是没有意义的

经验110. 自动化的回归测试发现少部分程序错误

经验111. 在自动化测试时考虑什么样的程序错误没有发现

经验112. 差的自动化测试的问题是没有人注意
好的测试包是活的。要补充新测试，要修复或删除老测试。如果没有出现这种情况，测试包就会开始僵化。

经验113. 捕获回访失败

经验114. 测试工具也有程序错误

经验115. 用户界面变更
提供产品GUI抽象的一些手段：
窗口映射、数据驱动自动化测试、任务库、关键词驱动的自动化测试、基于API的自动化测试

经验116. 根据兼容性、熟悉程度和服务选择GUI测试工具

经验117. 自动回归测试消亡

经验118. 测试自动化是一种软件开发过程

经验119. 测试自动化是一种重要投资

经验120. 测试自动化项目需要程序设计、测试和项目管理方面的技能

经验121. 通过试点验证可行性
自动化的测试会改变开发和测试过程。越早自动化部分测试，越可以更早进行变更。测试小组使用手工测试过程的时间越长，越难最大限度利用自动化测试包

经验122. 请测试员和程序员参与测试自动化项目

经验123. 设计自动化测试以推动评审

经验124. 在自动化测试设计上不要吝啬

经验125. 避免在测试脚本中使用复杂逻辑

经验126. 不要只是为了避免重复编码而构建代码库

经验127. 数据驱动的自动化测试更便于运行大量测试变种

经验128. 关键词驱动的自动化测试更便于非程序员创建测试

经验129. 利用自动化手段生成测试输入

经验130. 将测试生成与测试执行分开

经验131. 使用标准脚本语言

经验132. 利用编程接口自动化测试

经验133. 鼓励开发单元测试包

经验134. 小心使用不理解测试的测试自动化设计人员

经验135. 避免使用不尊重测试的测试自动化设计人员

经验136. 可测试性往往是比测试自动化更好的投资

经验137. 可测试性是可视性和控制

经验138. 尽早启动测试自动化
测试自动化是一件艰苦工作，需要计划、研究和设计。如果计划实施大量自动化的测试，要在产品还在设计时就要开始。

经验139. 为集中式测试自动化小组明确章程

经验140. 测试自动化要立即见效

经验141. 测试员拥有的测试工具会比所意识到的多

参考《软件测试经验与教训》