今天我们注意到他的所有大多数测试程序都产生了虚假结果。他所做的是产生随机测试结果或
assert true == true。 这听起来很愚蠢，但是如何防止测试自动程序创建虚假结果呢？
具体来说：业界推荐的审计测试自动化代码的方法是什么？测试自动程序生成的代码不会测试应该测试的内容？
#1 楼
代码审查会做到这一点。管理层，高级经理需要意识到进行审查的价值。他们必须积极地投入精力和时间进行审核。这通常是最难的部分。一些高级管理人员认为审核是浪费时间。
团队负责人，他们需要监督审核的进行。
团队成员需要进行技术审核，同行评审，演练和检查。
评论
是的，高级管理层希望立即取得短期结果。真是痛苦。
–奥斯卡
17 Mar 7 '17 at 14:20
#2 楼
正如其他人所说：代码审查。在测试自动化开发过程中，像
assert true == true这样的代码被用作占位符并不罕见（我个人会使用assert true == false或assert fail或类似的占位符，所以我的代码在我准备好编写正确的断言之前无法通过，因此我没有机会忘记占位符）。代码审查将捕获占位符代码以及完全错误的代码。您需要做的关键是将自动化代码视为生产代码。这包括组织中的编码标准，代码审查以及所有其他代码质量标准。
评论
我同意“代码审查”。我不同意“处理自动化代码和生产代码”。测试自动化是一种工具，不是生产工具。
–乔·斯特拉泽（Joe Strazzere）
17年7月7日14:02
我100％同意“将处理自动化作为生产代码”。例如，当使用连续部署时，您的测试代码与其他代码一样，是生产的一部分。它应该是相同的质量水平。您还需要定期对其进行重构，并保持其高质量。测试代码是代码，它需要像其他任何代码一样进行维护和扩展。欢迎来到下个世纪。 :)
– Niels van Reijmersdal
17 Mar 7 '17 at 14:42
@JoeStrazzere-足够公平。我发现如果测试自动化代码不符合与应用程序代码相同的标准，它很快就会成为表亲，并且会导致质量问题-也许有更好的措辞方式？
–凯特·保罗（Kate Paulk）
17 Mar 7 '17 at 15:32
@KatePaulk-我理解您的意思，但实际上，测试自动化代码绝不会像生产代码那样经过严格的过程。否则，您将有一个质量检查小组，使用测试自动化...测试测试自动化代码，并且需要不断循环。以我的经验，为了提高效率和成本效益，测试自动化需要轻得多的过程。
–乔·斯特拉泽（Joe Strazzere）
17 Mar 7 '17 at 15:38
除了代码审查外，还可以投资突变测试。使用MT，机器将以使“正确”测试失败的方式更改SUT代码。如果您的测试不测试功能，则测试将继续通过；否则，测试将继续通过。因此，在测试代码中发现错误。 MT仍然受到限制，但是可以成为完成代码审查的强大工具-特别是在自动化代码获得更多抽象时。
–JoãoFarias
17年3月9日在14:16
#3 楼
查看测试自动化代码。
在编写将测试的代码之前，请至少运行一次自动化测试。 （当然，这意味着您必须先编写测试代码，然后再编写将要测试的代码。）
评论
是的，这将有效防止错误的自动化测试。
–奥斯卡
17年7月7日在14:19
#4 楼
我没有看到这个，因此我想将其添加为“管理问题”。让一个愿意离开而又没有做过真正工作的人是一个管理问题。他们应该因为不做工作而被管理层开除。管理层应消除孤岛，并采取不良做法，同时创造成功的环境，从而从一开始就避免这种情况。正如几乎所有提到的答案一样，代码审查和问责制应该是任何团队（和雇用）的自然组成部分，但管理层和团队负责人应该对此进行设置。成为笨拙的texteld，负责浪费预算且无法成功实现自动化。我的猜测是，这个职位的经理将自动化团队的不良工作归咎于自动化团队，而不是对自己的工作和在过程中的角色负责。他们也可能不了解实际执行该操作所需的时间。我会严重质疑一个经理的能力，该经理让一个无所事事甚至不知道这件事的员工成为可能。我也想知道有一个经理会雇用显然不诚实且对团队没有帮助的人。
如果您想获得技术性的答案，请与Kate Paulk共同撰写的Code Review，但是这里的根本问题是管理/领导能力不强。
#5 楼
尽管代码审查似乎是最明显的。我想为测试优先和配对测试投票。以测试为先：
确保首先编写失败的测试对防止不相关的测试有很大帮助。
XP'ers保持诚实的一种方式是，坚持要求他们编写
失败的单元测试（表明对复杂性的需求），然后再为系统增加额外的复杂性。 br />添加不必要的测试也是如此。证明需要编写额外的测试。在开始新代码之前，我还倾向于编写一两个或两个端到端和/或集成测试。
配对测试：
您总是可以练习配对测试。让开发人员和测试人员联合起来进行测试！ :)
其他内容：
http://www.extremeprogramming.org/rules/testfirst.html
http：// lisacrispin。 com / 2016/09/22 / pair-testing /
#6 楼
除了正在进行的代码审查之外，我还会考虑：现有代码审计（代码审查）
代码审查通常是针对新功能和更改功能进行的。根据您已经发现的内容，我将退后一步，并检查所有现有的测试代码，就像它是新的一样。您经常需要制定一项策略来与现有功能开发一起对它们进行大块回顾。
冠军的良好做法
如果您记录，促进和鼓励良好的做法，则很可能会遵循它们。
红色，绿色，重构
学习和实践这种技术。
教育
从午餐到学到半天的研讨会，为做正确的事提供了大量学习材料。
为绩效付费
在个人绩效审核中包括代码质量项。奖励做正确事情的底线（$）。
技术债务周
现在，尽管我尝试做正确的事情，但我也要平衡这与提供功能的业务需求。我的出路是，有时我会创建债务技术票据。我们每6周要承担1或2星期的技术债务，因此这些票券并不是从未完成过的“一厢情愿”票，而是实际上排队等待即将完成的实际工作。
配对
来自dev- dev to dev-qa to qa-qa有助于保持人们更加诚实，开放和质疑的假设。小组思考可能是一个问题，但是总的来说，我认为这样做的好处是肯定的。
代码质量工具
从代码环境到codecov，这里有很多代码分析工具。它们通过分析代码库和测试覆盖率来帮助您管理拥有高质量代码的过程。它们可以为您显示随时间的改进，并且可以让您设置和管理代码质量级别。
测试您的测试
考虑添加代码以查看测试本身的结构，并查找类似的内容：重复的页面对象，未使用的页面对象，不使用页面对象，使用
true == true语句等。将它们变为实际测试，以便您可以进行测试帮助执行标准，而不是通过代码审查中不断的说服力来帮助您实现。btw“行业标准”在这里对我不起作用。软件质量行业仍然过于多样化和不确定。
评论
这是一个很有价值的问题：我已经进行了编辑，以删除基于意见的方面。@KatePaulk，谢谢。当前标题很清楚。
代码审查是显而易见的答案。另外...相关的xkcd：xkcd.com/221