在我们每天的工作中，我们可能时时都在面对着对
测试
的批评和指责中。开发人员或
管理
人员试着用这种或那种的理由要求我们在
测试
过程中更负责，更仔细些。但是你认为他们对你的要求或指责都是正确抑或合理的吗?作为一个
测试
人员，你是否在工作中固执己见?作为一个
管理
者，你是否一味地追求高深的技术或
测试自动化
呢?本文参照了国外一些资深的测试专家的观点，并结合本人多年的经验而成。希望我们能够更理性的把
测试
工作做的更好。
测试的角色
认为 测试 小组应负责保证产品的质量
-这是经常被开发人员和 管理 人员滥用的一句话。经常出现在出现问题时，对 测试 小组的指责中。就是由于这个观念的存在，导致很多问题在开发晚期或 测试 后期才发现，可能需要大量的返工甚至拖延了产品的发布时间。其实在开发过程中的每一人都有可能影响产品的质量。这就像建房子一样，房子出现问题了，只是检查人员的问题吗?我想如果每一个人都心怀以“质量为中心”，小心谨慎的做好自己的工作，产品的质量会上一个很多的台阶。
认为测试就是为了发现错误
-在很多“ 软件测试 ”的定义中，都提到类似“ 软件测试 是为了发现错误”的话。其实这个观点是提醒人们在测试过程要以查找错误为中心，而不是证明软件的正确 功能 。但是很多人仅凭着字面的意思就认为发现错误是 测试 的唯一目的，那些找不出任何错误或很少错误的 测试 都不是成功的 测试 ，这是错误的。
其实 测试 不仅仅只是为了发现错误，还需要分析错误产生的原因和其分布情况，为开发人员， 管理 层提供参考，指出产品或开发过程中存在的主要问题。而且随着人们对产品质量的要求的提高，出现了多样的 测试 类型。象易用性 测试 ， 性能测试 ，覆盖率测试，恢复性测试，完整性测试等，这些 测试 都不是完全为了发现错误，而是找出和预期标准不同的问题。
所以个人认为还是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”比较权威。
认为测试不能发现重要的错误
-有些开发人员认为单纯的手工 测试 只是发现系统的一些皮毛问题，因此从心里看低 测试 人员。但有过经验的开发人员知道， 测试 人员也发现了很多重要的问题。我曾经看过一些在开发小组中特别有权威的 测试 人员，他们虽然也只作黑盒 测试 ，但他们发现的错误都是重量级的。
认为 测试 小组没有提交可用性方面的问题
没有集中精力评估产品的质量
提交错误数据的同时，但没有把数据放入错误发生的背景里
-有些 测试 人员认为我发现错误了，就成功了。在错误报告中，只是提及错误的情况和数据，但却没有提及错误发生的背景或是步骤。造成开发人员很难重现并修改错误。
很晚才开始 测试 (只是发现错误，而不是减少错误)
-这个很显而易见。但不幸的是，我参与过的很多 项目测试 小组都是在很晚才开始测试的。由于公司在成本上的考虑，导致了在开发后期或系统 测试 时才开始 测试 。出现了开发人员在 项目 晚期还在加班改bug的情况，甚至由于错误太多拖延了交付时间。在其中，还有可能发现整体设计和构架上的缺陷，导致明知会有很严重的后果都不敢改动 代码 的事情。
计划完成的 测试 工作量
测试 的工作量和 功能测试 有偏离
低估了配置 测试
把压力和负载 测试 放在最后进行
不 测试 文档
不 测试 安装过程
过分依赖beta 测试
在转移到下一个任务之前必须完成现在的 测试 任务
未能正确地识别风险区域
固执地遵从 测试 计划
人员问题
利用 测试 作为新开发人员的过渡工作
从不合格的程序员中招募 测试 人员
测试 人员不需要是领域专家
不从客户服务人员或技术文档人员中挑选 测试 人员
坚持 测试 人员必须能够编程
缺乏多样性的 测试 小组
认为 测试 和开发人员有本质的区别
相信开发人员不能够 测试 他们自己的代码
开发人员既没有受过培训，也没有激情 测试
工作中的 测试 人员
比设计 测试 更注重运行 测试
不审核 测试 设计
非常详细地描述 测试 的输入和过程
没有注意并探测到“不相关的”怪事
检查产品应该执行的和期望的一样，但没有检查它不应该执行的是期望不应该执行的一样
测试 套件只有他们的作者才可以理解
只通过用户可见的界面 测试
拙劣的错误报告
当发现错误后，只是增加了回归 测试
没有为下一此 测试 工作量做笔记
测试自动化
尝试 自动化 所有的 测试
可以立即减少工作量或人力
期望重新运行手工 测试
使用GUI捕获/回放工具以减少创建 测试 的成本
期望回归 测试 可以发现更多的新错误
测试 覆盖
只是追求一个简单的关于 测试 覆盖率的数据
只是因为有些 测试 不能增加覆盖率，就把它们从回归 测试 包中移除掉
把覆盖率作为 测试 人员的绩效目标
彻底地放弃覆盖率
测试的角色
认为 测试 小组应负责保证产品的质量
-这是经常被开发人员和 管理 人员滥用的一句话。经常出现在出现问题时，对 测试 小组的指责中。就是由于这个观念的存在，导致很多问题在开发晚期或 测试 后期才发现，可能需要大量的返工甚至拖延了产品的发布时间。其实在开发过程中的每一人都有可能影响产品的质量。这就像建房子一样，房子出现问题了，只是检查人员的问题吗?我想如果每一个人都心怀以“质量为中心”，小心谨慎的做好自己的工作，产品的质量会上一个很多的台阶。
认为测试就是为了发现错误
-在很多“ 软件测试 ”的定义中，都提到类似“ 软件测试 是为了发现错误”的话。其实这个观点是提醒人们在测试过程要以查找错误为中心，而不是证明软件的正确 功能 。但是很多人仅凭着字面的意思就认为发现错误是 测试 的唯一目的，那些找不出任何错误或很少错误的 测试 都不是成功的 测试 ，这是错误的。
其实 测试 不仅仅只是为了发现错误，还需要分析错误产生的原因和其分布情况，为开发人员， 管理 层提供参考，指出产品或开发过程中存在的主要问题。而且随着人们对产品质量的要求的提高，出现了多样的 测试 类型。象易用性 测试 ， 性能测试 ，覆盖率测试，恢复性测试，完整性测试等，这些 测试 都不是完全为了发现错误，而是找出和预期标准不同的问题。
所以个人认为还是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”比较权威。
认为测试不能发现重要的错误
-有些开发人员认为单纯的手工 测试 只是发现系统的一些皮毛问题，因此从心里看低 测试 人员。但有过经验的开发人员知道， 测试 人员也发现了很多重要的问题。我曾经看过一些在开发小组中特别有权威的 测试 人员，他们虽然也只作黑盒 测试 ，但他们发现的错误都是重量级的。
认为 测试 小组没有提交可用性方面的问题
没有集中精力评估产品的质量
提交错误数据的同时，但没有把数据放入错误发生的背景里
-有些 测试 人员认为我发现错误了，就成功了。在错误报告中，只是提及错误的情况和数据，但却没有提及错误发生的背景或是步骤。造成开发人员很难重现并修改错误。
很晚才开始 测试 (只是发现错误，而不是减少错误)
-这个很显而易见。但不幸的是，我参与过的很多 项目测试 小组都是在很晚才开始测试的。由于公司在成本上的考虑，导致了在开发后期或系统 测试 时才开始 测试 。出现了开发人员在 项目 晚期还在加班改bug的情况，甚至由于错误太多拖延了交付时间。在其中，还有可能发现整体设计和构架上的缺陷，导致明知会有很严重的后果都不敢改动 代码 的事情。
计划完成的 测试 工作量
测试 的工作量和 功能测试 有偏离
低估了配置 测试
把压力和负载 测试 放在最后进行
不 测试 文档
不 测试 安装过程
过分依赖beta 测试
在转移到下一个任务之前必须完成现在的 测试 任务
未能正确地识别风险区域
固执地遵从 测试 计划
人员问题
利用 测试 作为新开发人员的过渡工作
从不合格的程序员中招募 测试 人员
测试 人员不需要是领域专家
不从客户服务人员或技术文档人员中挑选 测试 人员
坚持 测试 人员必须能够编程
缺乏多样性的 测试 小组
认为 测试 和开发人员有本质的区别
相信开发人员不能够 测试 他们自己的代码
开发人员既没有受过培训，也没有激情 测试
工作中的 测试 人员
比设计 测试 更注重运行 测试
不审核 测试 设计
非常详细地描述 测试 的输入和过程
没有注意并探测到“不相关的”怪事
检查产品应该执行的和期望的一样，但没有检查它不应该执行的是期望不应该执行的一样
测试 套件只有他们的作者才可以理解
只通过用户可见的界面 测试
拙劣的错误报告
当发现错误后，只是增加了回归 测试
没有为下一此 测试 工作量做笔记
测试自动化
尝试 自动化 所有的 测试
可以立即减少工作量或人力
期望重新运行手工 测试
使用GUI捕获/回放工具以减少创建 测试 的成本
期望回归 测试 可以发现更多的新错误
测试 覆盖
只是追求一个简单的关于 测试 覆盖率的数据
只是因为有些 测试 不能增加覆盖率，就把它们从回归 测试 包中移除掉
把覆盖率作为 测试 人员的绩效目标
彻底地放弃覆盖率
扫一扫
1499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
