三、测试手段
48，关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段：这是测试的五个要素
49，关注测试员的基于人员的测试手段
· 用户测试
· 阿伐测试
· 贝它测试
· 设计贝它
· 市场开发贝它
· 兼容性贝它
· 强力测试
· 有关领域的专家测试
· 成对测试
· 自用测试
50，关注测试内容的基于覆盖率的测试手段
· 功能测试
· 特性和功能集成测试
· 菜单浏览
· 域测试
· 等价类分折
· 边界值分析
· 最佳代表分析
· 输入字段测试大纲或矩阵
· 用各种方式映射和测试编辑字段
· 逻辑测试：因果图
· 基于状态的测试
· 路径测试
· 语句和分支覆盖率
· 配置覆盖率
· 基于规格说明的测试
· 基于需求的测试
· 组合测试
51，关注测试原因（针对风险测试）的基于问题的测试手段
· 输入约束
· 输出约束
· 计算约束
· 存储（或数据）约束
52，关注测试方法的具有活动的测试手段
· 回归测试
· 程序错误更正回归
· 老程序错误回归
· 副作用回归（稳定性回归)
· 脚本测试
· 冒烟测试
· 探索式测试
· 游击式测试（这是一种探索式测试)
· 场景测试
· 用例流测试
· 安装测试
· 负债测试
· 长序列测试
· 性能测试
53，关注测试是否通过的基于评估的测试手段
· 自校验测试
· 与已保存的结果进行比较（常用于回归测试)
· 与规格说明或其他权威文档进行比较
· 启发式一致性
· 与历史一致
· 与我们的想象一致
· 与可比较的产品一致
· 与所声明的内容一致
· 与用户的预期一致
· 产品内部一致
· 与用途一致
· 基于理念的测试
54，根据自己的看法对测试手段分类
· 谁来测试?
· 要测试程序的哪些方面？
· 要寻找什么类型的问题？
· 具体要完成什么任务？
· 如何确定测试是否通过？
四、程序错误分折
55，文如其人
56，测试员的程序错误分析会推动改正所报告的错误
57，使自己的错误报告成为一种有效的销售工具
· 陈述种种好处，使得潜在的客户想要它
· 向销售人员说明预期存在的问题，并反驳他们
58，错误报告代表的是测试员
59，努力使错误报告更高的价值
60，产品的任何项目相关人员都应该能够报告程序错误
61，引用别人的错误报告时要小心
62，将质量问题作为错误报告
· 质量对于个人来说就是价值(Weinberg，1992）
63，有些产品的项目相关人员不能报告程序错误，测试研究是他们的代理
64，将受到影响的项目相关人员的注意力转移到有争议的程序错误上
65，绝不要利用程序错误跟踪系统监视程序员的表现
66，绝不要利用程序错误跟踪系统监视测试员的表现
67，及时报告缺陷
68，永远不要假设明显的错误已经写入报告
69，报告设计错误
70，看似极端的缺陷是潜在的安全漏洞
71，使冷僻用例不冷僻
72，小缺陷也值得报告和修改
73，时刻明确严重等级和优先等级之间的差别
74，失效是错误征兆，不是错误本身
75，对看起来很小的代码错误咨询后续测试
· 变化自己的行为(通过改变操作方式改变条件)
· 变化程序选项和设置
· 变换软件和硬件环境
76，永远都要报告不可重建的错误，这样的错误可能是时间的炸弹
77，不可重现程序错误是可重现的
78，注意错误报告的处理成本
79，特别处理工具或环境有关的程序错误
80，在报告原型或早期个人版本的程序走之前，要先征得同意
81，重复错误报告是能够自我解决的问题
82，每个程序错误都需要单独的报告
83，主题或标题是错误报告中最重要的部分。
· 简要描述，足够具体
· 简要指出程序错误的局限性或依赖关系
· 简要指出程序错误的影响或后果
84，不要夸大程序错误
85，清晰地报告问题，但不要试图解决问题
· 比如：按键应该在屏幕的左上方显示
86，注意自己的语气，所批评的每个人都会看到报告
87，使自己的报告具有可读性，即使对象是劳累或暴躁的人
· 一次只走查程序错误一步
· 为每一步编号
· 不要跳过重现问题所去的任何步骤
· 列出使读者能够呈现失效的最少步骤集
· 通过空行使报告浏览
· 使用简单的句子
· 说明实际发生了什么，自己预期会发生什么
· 如果后果很严重，但是测试员有理由怀疑程序员不理解为什么很严重，可以解释为什么自己认为很严重
· 如果可以便于程序员意思的问题，或便于自己在修改之后重新测试，可补充注释
· 对于复杂产品或问题，考虑使用描述的头三行专门小结该问题，然后给出问题细节
· 要始终保持中立语气
· 不要开玩笑，别人会产生误解
88，提高报告撰写技能
89，如果合适，使用市场开发或技术支持数据
90，相互评审错误报告
· 第二测试员要做:
· 检查是否清楚的提供了关键信息
· 检查室我可以重现该程序错误
· 研究该报告是否能够简化、概括或加强
· 测试员可以评审：
· 所有缺陷
· 自己发现的所有缺陷
· 同事发现的所有缺陷
91，与将阅读错误报告的程序员见面
92，最好的方法可能是向程序员演示所发现的程序错误
93，当程序员说问题已经解决时，要检查是否真的没问题了
94，尽快检验程序错误修改
95，如果修改出现问题，应与程序语言沟通
96，错误报告应该测试员封存
97，不要坚持要求修改所有程序错误，要量力而行
98，不要让延迟修改的程序错误消失
99，测试惰性不能成为程序错误修改推迟的原因
100，立即对程序错误延迟决定上诉
101，如果决定据理力争，就一定要赢
五、测试自动化
102，加快开发过程，而不是试图在测试上省钱
· 迅速检测出新版本中不稳定的变更
· 尽可能迅速暴露回归程序错误
· 快速报告问题，因为这次程序错误说改更容易
· 自动化冒烟测试
· 自动化单元测试
· 时间、精力、技能和资金
103，拓展测试领域，不要不断地重复相同的测试
· 负载测试
· 性能基准测试
· 配置测试
· 耐力测试
· 竞争测试
· 复合错误
104，根据自己的背景选择自动化测试策略
· 测试需求
· 软件产品体系结构
· 测试人员技能
105，不要强求百分之百的自动化
106，测试工具并服饰策略
107，不要通过自动化是无序情况更严重
108，不要把手自动化测试与自动化测试等同起来
109，不要根据测试运行的频率来估计测试的价值
· 测试本身是不可比较
· 比较自动化测试运行成本是没有价值的
110，自动化的回归测试发现少部分程序错误
· 自动化测试发现的缺陷是很少的
· 老功能的新测试也与老测试一样可以发现回归程序错误，并且增加了发现以前没有发现过的程序错误的优势
111，在自动化测试时考虑什么样的程序错误没有发现
· 自动化测试的时间可以用来做什么？
· 现在没有运行什么？
· 测试现在没有发现什么程序错误？
112，差的自动化测试的问题是没有人注意的
· 测试可能并不完成所想象的工作
· 测试已经可能不再重要
· 覆盖率可能很差
· 虚警可能很常见
· 测试结果可能有错
· 好的测试包应该是活的，要补充新的测试，要修复或删除了老的测试
113，捕获回放失败
114，测试工具也有程序错误
115，用户界面变更
· 窗口映射
· 数据驱动自动化
· 任务库
· 关键词驱动的自动化测试
· 基于API的自动化测试
116，根据兼容性、熟悉程度和服务选择GUI
· 测试工具
117，自动回归测试消亡
· 用户界面或输出格式的变更
· 有关测试环境的设计假设
· 维护中的错误
· 变更操作员
118，测试自动化是一种软件开发过程
119，测试自动化是一种重要投资
120，测试自动化项目需要程序设计、测试和项目管理方面的技能
· 测试、编程、项目管理
121，通过试点验证可行性
122，除了测试员与程序员参与测试自动化项目
· 产品测试员
· 产品程序员
· 可评审性、可维护性、完整性
123，设计自动化测试以推动评审
124，在自动化测试设计上不要吝啬
· 保证测试已经被正确地设置
· 描述预期结果
· 发现潜在错误和副作用
· 从潜在测试失效中恢复
· 防止测试相互干扰
125，防止测试脚本中使用复杂逻辑
126，不要只是为了避免重复编码而构建代码库
127，数据驱动的自动化测试更便于进行大量测试变种
128，关键词驱动的自动化测试更便于非程序员创建测试（表中包含指令（关键词)而不是数据)
· 首先，这种方法要求支持运行测试，有支持设置库、结果分析和报告的一般框架
· 第二，必须创建一个任务库，封装由被测产品支持的用户库
· 第三，增加对读取电子表格数据的支持，每次读入一行
129，利用自动化手段生成测试输入
· 创建大文件
· 创建大量测试输入
· 创建测试床
· 创建随机数据
· 覆盖所有输入组合
· 覆盖等价类的所有代表对偶
· 覆盖逻辑条件中的交互
· 通过状态模型创建测试场景
130，将测试生成与测试执行分开
· 测试易于理解和评审
· 可以使用不同的测试工具或程序设置环境和执行测试
· 独立的测试用例生成器比较容易测试
· 如果预先生成数据，则更容易重复测试
· 报告所发现的程序错误更容易
· 不同的测试专业人员为各自关注自动化测试的不同方面
131，使用标准脚本语言
· 提供商脚本使编码更困难
· 提供商脚本难以掌握
· 提供商脚本影响测试员与程序员之间的协作
· 很难在别人工作的基础上构建基本库
132，利用编程接口自动化测试
· 编程接口包括API接口，命令行接口，COM接口，http接口等
133，鼓励开发单元测试包
134，小心使用不理解测试的测试自动化设计人员
135，避免使用不尊重测试的测试自动化设计人员
136，可测试性往往是比测试自动化更好的投资
137，可测试性是可视性和控制
· 访问源代码
· 日志
· 诊断
· 错误模拟
· 测试点
· 事件触发器
· 读入老的数据格式
· 测试接口
· 定制控件支持
· 允许多实例
138，尽早启动测试自动化
· 当测试已经成型后，很难把资源转为自动化
· 当测试人员和过程都集中于手工测试之后，他们会触变更
· 设计完成之后，程序员在可测试性要求方面会变得不那么合作
· 不要一开始所有的东西都自动化
139，为集中式自动化小组明确章程
140，测试自动化要立竿见影
· 系统设置与准备
· 辅助诊断
· 会话记录
· 这是生成
· 不必从头到尾多自动化，先实行一部分自动化，这样有助于如果实现更广泛的解决方案
141，测试员拥有的测试工具会比所意识到得多
· 磁盘影像工具
· 依赖关系检查器
· 文件扫描器
· 内存监测器
· 宏工具
· 小语言：Sda，Awk, Grep，Diff
六、测试文档
142，为了有效应用解决方案，需要清楚的理解问题
· 正反两方
143，不要使用测试文档模版：除非可以脱离模版，否则模板就没有用
144，使用测试模板：模板能够促进一致的沟通
145，使用IEEE-829作为测试文档
146，不要使用IEEE标准829
147，在决定要构建的产品之前，先分折需求，这一点既适用于软件也适用于文档
148，为了分析测试文档需求，可采用类似以下给出的问题清单进行调查
· 测试小组的使命是什么，测试这个产品的目标是什么？
· 自己的测试文档是产品还是工具？(工具是别人使用的，文档是自己使用的，如果是文档则不需要太标准)
· 软件质量是受法律问题驱动还是受市场驱动？
· 设计变更有多频繁？
· 反映设计变更的规格说明变更有多频繁？
· 在测试时，是希望证明与规格说明一致，还是希望与客户信息预期不一致？
· 是采用的测试风格更依赖于预先定义的测试，还是探索式测试？
· 测试文档应该关注要测试什么（目标），还是怎么测试（过程)？作者倾向目标
· 文档应该控制测试项目吗？
· 如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？
· 谁是这些测试文档的主要作者？这些读者有多重要？
· 需要多强调的可跟踪性，要反向更正这些文档（规格说明或需求）？谁来看控制跟踪？
· 测试能在多大程度上支持项目状态与测试进展的跟踪和报告？
· 文档要在多大程度上支持向新测试员指派工作
· 对新测试员的技能和知识做哪些假设？
· 要使用测试的记录项目的过程，以提供别人做测试的可依据的产品模型或描述，或给出发现程序错误的结构吗？
· 测试包应该提供预防，检测和预测收益。这一段项目收益最重要
· 测试文档（及测试用例)的可维护性有多高？这些测试文档在多大程度上能够保证测试变更能够跟上代码变更
· 测试文档会有助于标识（并修改或重新组织）程序风险模式的永久转移吗？
149，用简短的语言去归纳出核心文档需求
· 测试文档及主要支持我们自己找出这个产品版本中的程序错误，指派工作和跟踪工作状态
· 测试文档及将支持当前产品开发和至少10年的测试维护，为新测试小组成员提供培训材料并创建适合管理者或法庭检查使用档案
版权声明：51Testing软件测试网及内容提供者拥有本文全部版权，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
