看到了一篇讨论测试和AI的文章，有些观点确实是非常正确的，顺手翻译了一下，供大家参考。

我自己读了两遍，发现翻译的版本措辞不够通顺，还是直接给个省流版本好了。

省流

• AI生成的代码开发可能不理解其中的原理，这就为代码变更埋下了隐患，毕竟代码等于是抄的，改抄过来的东西往往不容易
• AI每次生成的代码可能风格都不一样，这样用的越多，代码风格百花齐放的可能性就越大，这样在团队协同的时候会带来麻烦
• AI生成的代码不好维护，集成进现有代码的难度其实很大
• AI写用例很菜，一些异常情况可能考虑不到
• AI生成的测试用例是没有测试模型指导的，所以随机性很大，这就导致了用例对功能的覆盖率可能不会很高
• AI生成的代码可能引入过时的依赖库和解决方案，从而让团队背上了技术债
• 泛化型的AI在代码和测试用例生成时可能不会给出最正确的决策，这很好理解，毕竟有些训练数据本身可能质量不高，这就造成了生成的内容质量低下
• 招聘问题。是招会写代码的人还是招会用ai的人？

随着生成式AI及其对各行各业的影响成为热门话题,我想探讨一下它将如何影响软件测试,主要基于使用这类AI可能带来的风险。了解这些新工具的潜在风险,有助于我们获得相关信息,并思考将其融入团队时需要采取的测试策略。

代码质量不如亲自编写

生成式AI通过分析互联网上的内容来根据提示创建代码,这意味着你会继承其他开发者的编码风格和特点。这可能导致我们难以理解为我们生成的代码,从而增加维护和继承的难度。另一个风险是我们可能会想当然地认为AI按照我们的要求执行,而不去验证(因为代码难以理解)。

这不仅影响产品代码,也会影响测试代码的生成。为应对这个问题,我们可以对代码进行全面的静态分析和重构,以提高其可读性。

编码习惯和风格不一致

与上述情况类似,AI会采用各种程序员的风格和习惯。这意味着每次要求生成代码时,可能会得到不同的实现方式或编码风格。这同样会影响代码的可维护性和可继承性,缺乏一致性也使问题更难被发现。代码所有权也可能成为问题,因为难以确定是团队中谁的代码。在代码集成方面,不同的编码风格可能难以协调,函数行为可能相互矛盾。

解决方案仍然是进行更多的静态分析和代码重构,以及对函数行为进行基于代码的测试,以确保代码的可理解性和正确性。

更高的维护成本

生成的代码可能难以与现有代码很好地融合,因此我们可能不得不替换而非添加代码。这可能导致现有的代码测试失效,增加代码行为偏离预期的风险。替换现有代码还意味着必须重新测试现有功能,特别是如果我们失去了贴近代码的测试,这将增加测试所需的时间。

对代码(或生成的测试)缺乏理解意味着每次修改代码库时都需要花更多时间进行静态分析。一种应对方法是为测试建立独立的代码库,这样对代码的修改就不会影响测试。测试人员还必须人工审查生成的测试,确保它们与当前的代码库相符。

生成的代码质量如同实习生水平

生成式AI创建的软件代码或自动化测试可能只达到实习生的水平。它会完成你明确要求的内容,但可能忽视细节或异常情况。这存在测试覆盖不全的风险,也可能无法发现更深层次的问题。任何不确定性都可能导致AI做出与你意图不符的假设,从而影响功能表现。

应对这种情况的方法是确保继续进行探索性测试和人工测试。测试人员不仅要审查生成的测试,还要继续测试AI已涉及功能的准确性。我们还必须善于减少不确定性,并以不留任何假设空间的方式记录所有要求,以便输入到AI中(不要认为它会有常识并知道失败应该导致错误)。

缺乏测试模型

由于你可能使用简短的提示而非详细的测试用例,你可能对测试覆盖率缺乏心理预期。如果过度依赖低代码或无代码测试工具,我们可能对代码/软件的行为缺乏深入理解。这可能影响软件的可维护性,并可能导致遗漏或错误测试边缘情况和功能。

为应对这些风险,我们需要制定计划来探索代码和功能,以了解其工作原理。这种理解可以用于改进生成的自动化测试,并指导我们知道应该测试什么以及如何测试。

引入不良依赖项导致技术债务

生成式AI可能会引入过时的库,这可能导致代码不受支持或无法正常工作。尝试更新生成的代码可能会失败,或者如果AI引入了我们不知道会发生变化的库,就存在代码突然停止工作而我们不知原因的风险。AI使用的库可能存在安全漏洞,如后门或恶意代码,我们必须诊断和修复这些问题。

我们必须确保团队分析所使用的库,并在生成的代码中记录这些库,以便检查其有效性。还需要对所有生成的代码进行静态分析,以测试是否存在漏洞和安全缺陷(包括对AI创建的功能进行渗透测试)。

AI可能做出不直观的决策

所使用的AI可能会在创建代码、测试内容或测试方法上做出糟糕的决定。如果代码不直观,我们可能无法从代码中推断AI所做的假设。这带来了无法理解或维护代码和测试的风险,以及得到无用的测试或遗漏关键内容的风险。

除了对生成的代码进行静态分析和重构,使其更有意义并找出糟糕的决策外,我们还需要为代码添加更详细和有意义的注释。我们需要训练AI记录它创建的代码,方法是为它提供更好的示例,每个函数和测试都需要真正有意义的注释。这将训练AI做同样的事情,并让我们能够更好地诊断错误。

招聘偏向AI提示编写技能?

团队可能开始过度重视招聘能够编写AI提示的人,而不是注重测试或编码技能。这可能导致工程团队对软件开发了解不足,无法诊断和纠正低代码开发带来的问题。这意味着我们可能面临无法修复的技术债务,或者团队无法处理重大的底层架构问题。

测试人员需要挑战假设或帮助消除团队的不确定性,以创建有效的AI提示。他们还将在审查生成代码的含义、可维护性和潜在工程缺陷方面发挥重要作用。这可能意味着高级工程师更有可能成为测试人员,因为他们可以制定处理生成代码的策略,或者可能需要准备(并倡导)从头重建系统。

我们可能还需要帮助教育行业了解过度重视AI技能而忽视工程和测试技能所带来的风险。组织可能想要专注于雇用能使用低代码解决方案的更便宜的工程师,而没有意识到其中固有的风险。

来源