对敏捷开发中的测试工程师和软件工程师的一些感受？

Question

• 我是软件开发人员，多年来一直为敏捷开发工作。理论上，团队成员应该共同支持。但现实是不同的，我总是与测试工程师就我们之间的范围进行斗争。
  • 测试工程师通常强迫开发人员编写单元测试，必须有80%-90%的测试覆盖率。我不知道为什么80%-90%？为什么他们不写单元测试？
  • 它们是否应该在编码中提供解决方案，以提高可测试性或提高质量？怎么做呢？
  • 他们总是很开心然后抱怨虫子？但是，如果这个软件没有错误，我觉得他们很不高兴。

• 请随意分享你的经验。

Answer 1

测试工程师通常强迫开发人员编写单元测试，必须有80%-90%的测试覆盖率。我不知道为什么80%-90%？

这些数字是这个行业的经验法则。如果你问“为什么要进行单元测试？”一个简单的答案是，单元测试迫使作者深入考虑他将要编写的生产代码的目标，主要是深入考虑架构:如果您在单元测试中以大量的嘲弄结束，这是一个信号，您有大量的依赖项--这意味着您的代码将脆弱于许多其他地方的更改。单元测试将允许编写高度可靠的生产代码，然后重构它以删除依赖项。更高级别的检查不能很好地提供这一点，因为它们并不接近代码，而是接近抽象/集成。

为什么他们不写单元测试？

我猜可能至少会有这样的情况：

• 他们在一本书上读到，这是开发者的工作；
• 他们没有技术技能；
• 他们百分之百地完成了其他任务；

前两个案例表明，他们需要改变他们的观点--如果他们的帮助在你的项目中是有意义的，你应该在回顾过程中与他们和经理交谈。

最后一种情况将需要更好地理解他们正在处理的问题，并将自己重组为一个团队。

我喜欢回顾前端和后端测试，在各个层次，以发现失踪的案件。在前面和后面的迁移脚本和边界用例对于缺少的测试用例特别脆弱。有时我在最后两种情况中的任何一种--我和团队一起努力去改变它，因为我知道我可以为更低水平的测试带来价值--有些测试人员没有.

它们是否应该在编码中提供解决方案，以提高可测试性或提高质量？怎么做呢？

我不会说“提供解决方案”，但它们肯定会帮助开发人员和设计人员提高可测试性。代码评审是一个很好的反馈工具。在编写代码或模型之前，编写可测试的文档在一起也有帮助。

他们总是很开心然后抱怨虫子？但是，如果这个软件没有错误，我觉得他们很不高兴。

发现bug是测试中最有趣的部分之一:D

更严重的是，在探索性会话之后没有发现bug(或者没有观察)是可能会话执行得不好的迹象。软件是复杂的，理解因人而异，而测试是通过探索和实验了解它的过程。因此，当测试会话结束时，没有发现任何新发现，这表明我们在会话中没有学到任何新知识--这是令人沮丧的。

为了集成更好的开发人员和测试人员，我已经很好地完成了一个仪式，那就是使用计划时间来规划以下工作项的测试。它可能会帮助您更多地谈论测试，在这段时间，重点是了解如何执行工作。查看我的博客文章"Scrum团队的测试计划仪式“，了解更多细节。

Answer 2

为什么测试工程师不编写单元测试？

开发人员通常负责创建单元测试有几个原因：

• 开发人员非常熟悉他们正在编写的代码。他们了解代码的意图，更重要的是，为什么选择特定的实现。理想情况下，他们在编写代码时或之前编写单元测试。
• 测试专家(无论他们被称为测试人员、QAs、测试工程师还是其他什么)对整个应用程序都非常熟悉。他们在代码方面的经验可能不如开发人员那么多，他们也不一定知道所需的底层逻辑。
• 虽然测试人员可以编写单元测试，但它通常不太有效地使用他们的时间，因为创建单元测试的理想时间是在应用程序开发之前或期间--在这个时候，测试人员通常不参与构建系统的任何部分。
• 运行单元测试的适当时间是在何时何地编译应用程序。测试人员通常没有将代码签入主应用程序的权限，而且他们通常没有能力添加到正在使用的连续集成系统中运行的测试中。
• 开发人员通常多于测试人员，导致功能测试常常成为瓶颈。

测试人员应该提供代码来提高可测试性和质量吗？

理想情况下，测试人员应该提供改进可测试性和质量的建议。这些建议可能不是提高可测试性或质量的最佳方法，因为正如我前面所说，测试人员对应用程序代码和体系结构的熟悉程度不如开发人员。

测试人员当然可以与开发人员一起工作：

• 建议开发人员可能没有考虑过的测试
• 在应用程序中显示特定的请求信息，以便更容易地进行集成和功能自动化测试(例如，如果应用程序架构动态生成HTML Ids，测试人员可以请求开发人员使用不同的属性对网页上的每个元素提供唯一的引用)
• 使用单元测试的信息，通过最小化重叠有效地提高覆盖率(例如，当业务逻辑被彻底单元测试时，集成测试不需要覆盖所有可能的业务逻辑路径，而是可以集中精力确保正确的信息从一个模块传递到另一个模块)。

如果

没有发现bug，测试人员应该感到不高兴吗？

是

所有非平凡的软件都有错误。软件是复杂的，通过一段非平凡软件的路径数如果不是无限的话，那么就太大了，以至于不可能测试每一条可能的路径。即使使用一些非常简单的内容，比如一个基本的文本编辑器，用户也可以随心所欲地添加文本和删除他们添加的文本。这是可行的，可以发生一些事情，513次文本被删除后，最后一次文本被保存，因为内部限制-但有多少人会发现这一点？

每一个有经验的测试人员都知道，如果他们没有发现任何bug，他们就会错过一些东西。如果他们错过了什么，他们不知道有多糟糕。

测试通常侧重于这些领域(或多或少按此顺序排列)：

• 软件能做它应该做的事情吗？
• 软件是否阻止自己做它不应该做的事情？
• 软件可以不做它应该做的事情吗？
• 软件可以做一些它不应该做的事情吗？
• 软件能够优雅地处理意外事件吗？(例如，如果您拉动网络连接中间操作，您会得到一个通用错误消息，并且没有部分事务，或者您会得到堆栈转储和坏数据吗？)
• 软件能够在不产生坏数据的情况下处理灾难性事件吗？

一个快乐的测试人员经历了这些类型的最后一次测试，有理由相信他们已经发现了大多数严重的问题，并且有理由相信他们错过的任何错误都不会导致客户丢失有价值的数据。

根据我的经验，我想补充的是，测试人员不会抱怨bug，除非他们担心自己发现的错误，并认为这会给应用程序带来严重的风险。