在我们每天的工作中,我们可能时时都在面对着对测试的批评和指责中。开发人员或管理人员试着用这种或那种的理由要求我们在测试过程中更负责,更仔细些。但是你认为他们对你的要求或指责都是正确抑或合理的吗?作为一个测试人员,你是否在工作中固执己见?作为一个管理者,你是否一味地追求高深的技术或测试自动化呢?本文参照了国外一些资深的测试专家的观点,并结合本人多年的经验而成。希望我们能够更理性的把测试工作做的更好。
测试的角色
◆认为测试小组应负责保证产品的质量
-这是经常被开发人员和管理人员滥用的一句话。经常出现在出现问题时,对测试小组的指责中。就是由于这个观念的存在,导致很多问题在开发晚期或测试后期才发现,可能需要大量的返工甚至拖延了产品的发布时间。其实在开发过程中的每一人都有可能影响产品的质量。这就像建房子一样,房子出现问题了,只是检查人员的问题吗?我想如果每一个人都心怀以“质量为中心”,小心谨慎的做好自己的工作,产品的质量会上一个很多的台阶。
◆认为测试就是为了发现错误
-在很多“软件测试”的定义中,都提到类似“软件测试是为了发现错误”的话。其实这个观点是提醒人们在测试过程要以查找错误为中心,而不是证明软件的正确功能。但是很多人仅凭着字面的意思就认为发现错误是测试的唯一目的,那些找不出任何错误或很少错误的测试都不是成功的测试,这是错误的。
其实测试不仅仅只是为了发现错误,还需要分析错误产生的原因和其分布情况,为开发人员,管理层提供参考,指出产品或开发过程中存在的主要问题。而且随着人们对产品质量的要求的提高,出现了多样的测试类型。象易用性测试,性能测试,覆盖率测试,恢复性测试,完整性测试等,这些测试都不是完全为了发现错误,而是找出和预期标准不同的问题。
所以个人认为还是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”比较权威。
◆认为测试不能发现重要的错误
-有些开发人员认为单纯的手工测试只是发现系统的一些皮毛问题,因此从心里看低测试人员。但有过经验的开发人员知道,测试人员也发现了很多重要的问题。我曾经看过一些在开发小组中特别有权威的测试人员,他们虽然也只作黑盒测试,但他们发现的错误都是重量级的。
◆认为测试小组没有提交可用性方面的问题
◆没有集中精力评估产品的质量
◆交错误数据的同时,但没有把数据放入错误发生的背景里。
-有些测试人员认为我发现错误了,就成功了。在错误报告中,只是提及错误的情况和数据,但却没有提及错误发生的背景或是步骤。造成开发人员很难重现并修改错误。
◆很晚才开始测试(只是发现错误,而不是减少错误)
-这个很显而易见。但不幸的是,我参与过的很多项目测试小组都是在很晚才开始测试的。由于公司在成本上的考虑,导致了在开发后期或系统测试时才开始测试。出现了开发人员在项目晚期还在加班改bug的情况,甚至由于错误太多拖延了交付时间。在其中,还有可能发现整体设计和构架上的缺陷,导致明知会有很严重的后果都不敢改动代码的事情。
计划完成的测试工作量
◆测试的工作量和功能测试有偏离
◆低估了配置测试
◆把压力和负载测试放在最后进行
◆不测试文档
◆不测试安装过程
◆过分依赖beta测试
◆在转移到下一个任务之前必须完成现在的测试任务
◆未能正确地识别风险区域
◆固执地遵从测试计划 人员问题
◆利用测试作为新开发人员的过渡工作
◆从不合格的程序员中招募测试人员
◆测试人员不需要是领域专家
◆不从客户服务人员或技术文档人员中挑选测试人员
◆坚持测试人员必须能够编程
◆缺乏多样性的测试小组
◆认为测试和开发人员有本质的区别
◆相信开发人员不能够测试他们自己的代码
◆开发人员既没有受过培训,也没有激情测试
工作中的测试人员
◆比设计测试更注重运行测试
◆不审核测试设计
◆非常详细地描述测试的输入和过程
◆没有注意并探测到“不相关的”怪事
◆检查产品应该执行的和期望的一样,但没有检查它不应该执行的是期望不应该执行的一样
◆测试套件只有他们的作者才可以理解
◆只通过用户可见的界面测试
◆拙劣的错误报告
◆当发现错误后,只是增加了回归测试
◆没有为下一此测试工作量做笔记
测试自动化
◆尝试自动化所有的测试
◆可以立即减少工作量或人力
◆期望重新运行手工测试
◆使用GUI捕获/回放工具以减少创建测试的成本
◆期望回归测试可以发现更多的新错误
测试覆盖
◆只是追求一个简单的关于测试覆盖率的数据
◆只是因为有些测试不能增加覆盖率,就把它们从回归测试包中移除掉
◆把覆盖率作为测试人员的绩效目标
◆彻底地放弃覆盖率
分享到:
相关推荐
在C#测试试题中,我们通常会遇到一系列旨在评估开发者对语言理解深度和广度的问题。C#.Net测试试题则更侧重于.NET框架下的知识,这包括但不限于类库、框架组件、ASP.NET、Windows Forms等。 以下是一些可能出现在C#...
测试函数通常由一系列精心设计的输入数据(边界条件、异常情况和典型用例)组成,它们会调用待测试的函数并检查输出结果是否符合预期。这样,开发人员可以确保他们的代码在各种情况下都能正常工作。 MATLAB提供的...
作为全书的总结部分,朱少民呈现了软件测试成熟度模型,讨论了软件测试的现实问题、应恪守的原则,并引导读者去理解测试方法的应用之道和品味测试的最佳实践。通过这样的总结和反思,读者可以更深刻地领会到软件测试...
### 软件测试黑盒测试方法大全 #### 黑盒测试的概念 黑盒测试,也被称作功能测试、数据驱动测试或者...尽管穷举测试在实际应用中不可行,但合理的测试策略可以帮助我们尽可能多地发现潜在问题,从而提高软件的质量。
软件测试是软件开发过程中的关键环节,其主要目的是确保...这些知识点涵盖了软件测试的多个方面,包括基础概念、特定类型的测试、测试工具的使用以及测试过程的管理,对于理解和实践软件测试工作有着重要的指导价值。
通过遵循这些规范,测试人员能够构建出一套完整且有效的测试用例集合,确保软件在各种情况下都能表现出预期的行为,从而降低缺陷风险,提升产品质量。在实际工作中,应根据项目需求和具体情况进行适当调整,以达到...
这些测试类型之间存在一定的联系,例如性能测试往往需要在特定的功能场景下进行,而安全测试则涉及到软件的各个方面。每种类型的测试都有其独特的目的和方法,但在实际项目中通常需要综合运用多种测试类型来全面评估...
1. **需求理解**:深入理解需求文档,确保测试用例覆盖所有需求。 2. **用例设计**:遵循测试用例设计原则,设计有效且高效的测试用例。 3. **评审机制**:建立测试用例评审机制,确保测试用例的准确性和完整性。 4....
- **数据池的概念:** 数据池是用来存储测试数据的数据集合。 - **数据池格式:** 通常以表格形式呈现,每一行代表一组测试数据。 - **兼容性:** 数据池可以与CSV、Excel等文件格式兼容。 3. **创建数据池** -...
- **常见性能瓶颈征兆**:列举了一些典型的性能问题表现,帮助快速定位问题。 - **性能数据解读建议**:提供解读性能测试数据的方法,以更好地理解测试结果。 - **如何定位性能问题**:介绍了一套系统的方法论来...
错误推测方法是一种基于经验和直觉的测试用例设计方法,它依赖于测试者对程序的理解和可能存在的错误类型进行推测,并设计出可能暴露这些错误的测试用例。 因果图方法是一种图形化的测试用例设计方法,它通过因果图...
文档标题“软件测试(2)(1)(1).docx”虽然未提供具体信息,但从描述来看,文档内容围绕软件测试的重要性展开,并探讨了软件中存在的错误、缺陷及其导致的问题。 #### 错误、缺陷与失败 - **错误(Error)**:指的是在...
《C#开发典型模块大全》是一份全面涵盖C#编程语言在实际开发中的各种模块应用的资源集合。这个光盘包含了大量的示例代码、项目模板和详细的教程,旨在帮助开发者深入理解和掌握C#语言在不同场景下的应用技巧。C#是...
5. **使用边界值分析**:这种方法强调选择边界值而非等价类的典型值,因为边界往往是问题最可能出现的地方。通过这种方法设计的测试用例可以更有效地暴露潜在的软件缺陷。 6. **提高程序健壮性**:边界条件测试执行...