您可以提供什么建议来鼓励项目经理和开发人员将测试因素考虑在内,以便在单元测试阶段进行的测试之外证明应用程序系统的性能、弹性、容量、可扩展性等。更多地强调/依赖引用设计概念(和单元测试)的有效性作为满足此类要求的唯一保险。简而言之,还假设系统将在受控较少的情况下按设计运行,即像在单元测试中所做的那样,PROD。因此,我们可能看不到对 UAT 期间进行的功能测试的性能结果的监控/评估。我们需要使用 UAT 来衡量底层系统的性能,看看在第一次集成所有处理链时,在更多类似生产的情况下是否存在性能限制。但是,我们发现该项目只关注业务成果。另请参阅文章 为什么分离功能测试和非功能测试很重要(或不重要)?
促进非功能测试
首先,您必须了解与您合作的项目经理和开发人员。不了解他们,很难理解什么样的论点可以说服他们。回想一下你和他们的争论,他们用什么样的争论来说服你。他们很可能会采用类似形式的论证。例如,如果他们总是指向客户数据,您需要以某种方式使用客户数据来形成您的论点。用他们自己的声音与他们交谈。
您也可以通过某种方式吸引公司文化。如果您的公司以节俭、彻底、精心设计或用户友好而自豪,那么这些就是您形成论点时要使用的术语。
最后,我认为您需要在自己的脑海中澄清您要完成的工作。不要在真空中测试。例如,更好的性能测试如何帮助您实现公司的业务目标?你能用清晰的一句话向自己或队友解释你的理由吗?花一些时间分解你自己的想法,确保它们是可辩护的。
你需要把这些点连接起来。至少要传达三个信息: 您的生产系统存在值得担心的问题;这些问题是由于您在组织当前实践中的缺陷造成的;解决这些缺点的最佳方法是引入新的测试,即使用您的术语,额外的 UAT 级测试,重点关注应用程序系统的性能、弹性、容量和可扩展性。
你没有描述你的生产问题的性质。你也没有说项目经理和开发人员是否意识到这些问题或分享你对它们的担忧。您的第一条消息可能需要有关这些问题的频率/严重性/影响的证据。细节比一般的不安感更引人注目。
有时生产问题是由开发团队下游的因素引起的。您的第二条消息需要证据证明这些问题可以追溯到开发团队,而不是,例如,生产团队的草率做法或您的 ISP 的基础设施问题。
最后,您需要一个有说服力的论点,即在新的 UAT 级别测试上投入时间比其他事情更重要,因为总会有其他事情发生。添加测试可能会减慢您的交付时间,需要在员工人数和/或硬件上花费更多资金,和/或延迟重要新功能的引入。
建议将专用的非功能 (NF) 测试管理实践与功能实践(UAT 等)分开。此外,NF 需要更紧密地与 (i) 基础架构架构和 (ii) 生产系统管理保持一致。还将 NF 测试作为具有单独治理的单独测试阶段。已经在许多客户中成功使用了这种方法,它比结合功能性和非功能性的效果要好得多。为功能测试管理想要治理 NF 做好准备——他们总是无法理解它并错过治理。分离确实需要在 CIO 级别。
我在这个问题的某个地方迷失了你......无论如何,高层管理人员通常会通过向他们展示投资回报率来说服他们,例如,如果你可以展示在非功能测试阶段可能已经检测和解决的问题。