多年来,我已经管理和/或参与了人类已知应用程序的各个级别的测试 J ,对于我们大多数的SAP项目,我们通常采用客户指定的内部测试策略,因此’简单地说,每个项目都是不同的。在许多情况下,我们向客户,同行提供有关如何使测试对项目,开发团队,公司更有效的意见,并认为我会分享一些想法,希望其他人也能从中受益。这些已为我们证明了提供成本和质量收益的能力,当然也对我个人而言可以提高我管理的项目成功的机会。为了使我们在这里立足,是系统项目通常处理的不同类型的测试类型。检查链接以获得正式的定义和理解。

单元测试

整合测试

压力测试

用户验收测试

最常见的测试方法

我在典型的SAP软件开发中看到的主要问题来源是测试不是预先考虑的,典型的开发项目通常会发生以下情况:

  1. 制定了蓝图(SRS),
  2. 使用蓝图可以开发功能规范(我希望无论如何都可以)
  3. 功能规范已移交给开发
  4. 进行开发,完成后移交给职能团队进行测试
  5. 职能团队开发测试方案并执行测试,直到没有发现错误为止
  6. 最终用户经过培训(也许)
  7. 开发投入生产

当然,这是对整个过程的过于简化的看法,但是对于我们的讨论是可以的。此典型过程中出现的一些问题是:

  • 错过的要求 –通常,如果实际开发的测试方案是在开发完成或几乎完成之后的某个时间放在一起的。蓝图的目的是记录用户’的要求(确实如此),但蓝图与开发过程之间往往存在脱节。这往往会使开发团队感到孤立,而不是过程的一部分。在这种典型场景中,由于需求的验证未与测试场景相关联,因此存在一定程度的需求遗漏,在大型软件开发项目中,这种情况往往更常见,其中有10个’s or 100’要求与带有几个要求的软件应用程序/报告。
  • 重工 交付之前和之后–在上述情况下,返工很常见。这可能被认为是正常的工作方式。我们进行开发,然后进行测试,将变更退还给开发人员,然后再次进行测试。但这不应该是正常的过程。发生这种情况是由于缺少需求(上述)。如果可用性或集成因素在交付之前就被捕获,或者一旦用户开始使用他们提供反馈的应用程序后可能在交付之后发生,则不可避免地需要进行更改。
  • 错过的项目日期或质量不佳–关于开发估算过程,有很多博客,书面文章和口述,认为对于给定的软件开发项目,开发估算需要复杂的计算,也许但我也认为,在许多情况下,对软件的影响发展是以上过程的错。在我们参与的项目的非正式分析中,我们发现经验丰富的团队的开发估算的准确性在原始估算交付时间的约85-90%之间。因此,这似乎意味着我们可以预测一个典型项目的开发需要花费多长时间,但是如果由于上述要点而增加返工,您会发现按时交付项目会变得多么困难。必须决定是交付质量低于预期还是延迟交付,这从来都不是一件容易的事。

因此,我认为您可能已经知道我将如何处理这个问题,并且希望这可以验证其他人的想法。那么我们如何使测试更有效呢?

如何使测试真正有效

  • 使测试方案成为功能规范的一部分 –在将单元和集成测试方案移交给开发之前,应将其作为功能规范的一部分进行开发。这提供了2个好处
    • 开发测试场景是为了确保所有要求都得到满足,这还向业务分析人员提供了验证,表明他们已经解决了所有未解决的问题,功能要求,业务规则等。应该使用测试矩阵的要求来记录进行哪种测试涵盖了哪些要求。
    • 测试场景被传达给开发人员,开发人员非正式地总是测试他们的工作是否实现(有时被认为是单元测试),并列出测试用例,开发人员可以验证该功能将成功提供预期的功能。结果并允许在交付之前传达意外结果,从而节省了时间和返工。
  • 纳入用户验收测试 应该合并到每个软件开发项目中。用户接受测试是许多咨询公司(例如我们)将用来接受应用程序正式接受的关键步骤。用户接受度可以是集成测试方案的子集,也可以是最终用户自行开发的方案的列表,但这提供了以下好处:
    • 最终用户买进后,您将他们视为客户,并要求他们接受最终产品的交付,他们将测试他们认为将如何使用最终产品(这里可能会有一些惊喜,但希望不会)
    • 培训,有时培训是非常非正式的(不是说这是对的,而是现实的),用户接受度测试为代表最终用户的最终用户或超级用户提供了玩应用程序,提问和一般了解的机会。交付之前的应用程序。请注意,用户验收测试并不需要很正式,但要减少交付后的返工,还有很长的路要走。
  • 自动化测试 –有人可能会说自动化测试是大公司的境界,但是对于SAP而言,由于没有额外的测试工具成本(SAP eCATT是系统的一部分),因此没有任何借口。我听说过这样的论点,即使用测试工具也不会省力,尽管我赢了’我要特别指出的是,结合使用测试工具可以提供进行更全面,更彻底的测试的能力,而如果没有这种工具,这将是切实可行的。例如,在最近的一个项目中,如果我们测试了所有可能的订单类型,我们的清单将扩展到150多个场景,那么一周内我们将测试50多个测试场景,几乎没有动力去测试所有场景对于所有订单类型,但由于我们能够自动化部分测试步骤,因此实际上我们在同一时间范围内测试了200多个场景,此外,客户还能够执行负面影响测试,并且没有最初的额外费用预算。另一个好处是,在需要修改的情况下,可以执行同一组测试,以确保几乎不费吹灰之力就不会影响结果。

这些非常简单,对我来说有趣的是,最困难的事情之一是作为功能规范的一部分开发测试方案。我希望这能给您一些思考。

后来…

固定在Pinterest上

分享
分享这个