我们不时会遇到可以通过更改配置,禁用逻辑的某些部分等来修复的生产错误.
我和我的经理争论过,我们应该在本地重现这些错误以确保修复工作,更重要的是,开发人员和QA可以将这些案例的检查作为常规版本的一部分.
我的经理认为是浪费时间,因为解决方案有效,因此无需在本地重现.
那么:我们应该尝试在本地重现以验证修复吗？如果你同意我的话,有关如何向我的经理出售这一点的任何指示？
Lim*_*tem 46
如果你还没有复制这个bug,你的"修复"就好比猜测更好.
Uri*_*Uri 11
如果它在经济上可行(例如,不是为了重现环境而将一些用户的整个硬盘驱动器复制到本地机器上),我非常相信再现错误.
错误的不幸之处在于,通常只有一种方法可以修复错误,但是有许多方法可以修复错误,许多修复方法实际上是掩盖而不是修复.您可能永远找不到根本原因,因此错误会再次出现,或者稍后会出现另一个看似不同的错误.
如果你能找到一个已经发生的例子(例如,来自同一根本原因的两个不相关的错误),你可能会赢得你的老板.
这个bug的性质也有问题:
可以通过单元测试快速复制缺陷吗？如果是这样,开发修复程序的开发人员应编写所述单元测试,并将其集成到更完整的回归套件中.这确保了未来的工作不会重新引入缺陷.
可以以编程方式再现缺陷(例如,使用Perl或Python脚本)吗？如果是这样,QA团队应该有一个覆盖它的自动化测试用例,并且可以快速用于验证.
可以通过一系列逐步说明来复制缺陷吗？如果是这样,QA团队(或最初标记该bug的人)应该提供绝对最少的再现步骤.
这三个原则极大地有助于推动我的测试团队的QA流程.
开发人员最好自己重现缺陷.如果这是不可能的(例如硬件资源的稀缺性),直接与QA(或最初标记该错误的人)合作将是下一个最好的事情.虽然有些缺陷是显而易见的(例如菜单选项中的拼写错误),但其他缺陷可能会产生更大的后果,而这些后果可能会由了解应用程序基础状态的开发人员捕获.
让开发人员重现缺陷以确认它们确实是缺陷也是有帮助的.测试人员虽然不可或缺(作为软件测试人员说话)),但他们往往缺乏对应用程序代码的深入了解,并且可能无法深入理解为什么行为不符合他们的期望(或规范).
你不应该在本地重现它的唯一情况是,这是不可行的.也许它需要一个LOT数据,专有数据,硬件的,也许它需要比你有更复杂的设置.
我不得不这样做几次,因为我们无法在内部复制设置.(有些开发工作甚至已经在客户端的系统上完成.)客户从一开始就知道他们超出了我们可以重现的范围,并且这个问题很难解决.
测试驱动开发背后的基本原则是您有一个演示某些功能的测试.
在这种情况下,您将创建一个演示该错误的测试.测试失败.
你修复了这个bug.测试通过.和所有其他测试一样.你实际上修复了bug而没有产生其他问题.
| 归档时间： |
|
| 查看次数： |
4423 次 |
| 最近记录： |