自动化测试:帮助和教育开发人员的方法?[关闭]

如果你有某些人在测试方面往往很弱,那么你可以和他们坐下来,结对编程,某种程度上,当他们处理他们的代码时,你可以帮助他们了解如何测试它。

过一段时间后,这些人应该在单元测试方面做得更好,并且您在这方面的工作负载应该减少。

另一件事是每个人都应该看测试。如果我触摸一个函数,做任何更改,那么我应该检查测试以确保它们是完整的。如果有问题,我可以和开发人员讨论。

您还应该争取团队领导的工作,因为这是他职责的一部分,或者应该是,以确保每个人都理解如何编写好测试。

我会做一些事情:

1. 让他们运行覆盖范围并找出任何遗漏的代码区域,并强调尽管他们认为已经覆盖了所有的案例,但他们可能没有。我和一些人做过这个,他们总是对他们认为他们写了水密测试而错过的领域感到非常惊讶。
2. 在当地的wiki上创建一个“食谱”页面。每当有人想出一个他们无法理解或需要你帮助的测试方案,就把它放在wiki上,让它很容易找到。让其他人也参与其中
3. 听起来你已经这样做了,但是要确保当任何人有与测试相关的问题时, 让自己有空 即使这会损害你正常的工作量。如果你对它充满热情,它也应该激励那些有兴趣做正确事情的人。

当我向某人介绍测试(或者一种新的测试技术)时,我经常会花大量的时间随机地闲逛到他们的工作站,看看他们是如何发展的,并将他们推向正确的方向。当你去喝茶或抽烟的时候,或者当你在做一个建筑的时候,这可以很好地适应。我对此有很好的反馈,但是YMMV。

根据团队的规模,我想知道在对代码进行初步审查后,是否有必要将其他人吸引到另一组眼睛中去,这样可以查看您提出的更改,并作为一种方式来表明这不仅仅是您对它的意见。这可以作为一种方式来强调在什么变化方面可能会有一些紧张,你希望看到开发人员可能会回答,“哦,这需要几周时间,而且很可能不值得……”或者类似的事情,如果你想改变的不是那么简单的话。

在类似的情况下,大多数团队如何看待测试?有没有领导或那些高度尊敬的人对它有积极的看法,并有助于培养一种积极的态度?是否有关于测试指南的一般文档可以帮助团队中的新成员快速跟上速度?这些只是我要检查的其他几个方面,因为有时候测试是一件很好的事情,有时候测试是一件痛苦的事情。很像半空或半满的玻璃杯,这取决于你想看到它的样子。

不是说我有相同的职位,而是作为一个开发人员已经有一段时间了,这正是我希望看到的帮助使测试成为一件好事,正如玛莎·斯图尔特所说。

让团队轻松开始测试的一个方法是在修复错误时启动编写测试的实践。所以当一个bug出现时,首先要做的是编写一个测试,因为这个bug而失败,修复这个bug,然后让测试通过。

这种方法也可以在内部修改代码(没有公共API更改)时完成——编写测试来覆盖正在修改的区域,以确保代码更改不会破坏它。以这种方式编写测试的工作量要少得多,而且一旦开发人员发现了他们的第一个回归错误,就可以清楚地展示其好处。