![]() |
1
2
引入测试永远不会太早,而且越早进行测试,就越早发现bug。 我将从两个不同的角度开始测试。首先,如果您有一些相当独立的java类用于业务逻辑和数据处理,我将开始为它们创建JUnit测试,以解决内部代码问题。 其次,我希望为业务指定的用例创建测试。这些很可能是在类似Selenium的东西中完成的,因为您希望测试遵循用例指定的与web站点的交互。把细节留给幕后的JUnit测试。这些是对功能的高级确认。 所有这些都需要时间,而且管理层不太可能允许您在几周或更长时间内除了测试什么都不做。相反,最有可能的处理方法是边走边做。为修复和新特性填充时间引号,以便编写测试。记住,写作测试可能需要50%或更多的时间,尤其是当你开始填写的时候。一旦有了广泛的套件,时间会有点倒退,但即使这样,有些测试也比代码更难编写。但他们是值得的。 |
![]() |
2
0
我同意德里克的观点。永远不会太迟。为测试创建框架。可能一个项目用于集成测试,一个项目用于单元测试。由于您的工作已经很晚了,请集中精力进行集成测试,以便在部署之前对解决方案进行健全性测试。你会很快从中受益。随着bug的出现,这也将为您提供基础设施,以便更轻松地复制它们并更快地创建修复。 |
![]() |
Tim Kirkwood · 比较空数据帧 10 月前 |
![]() |
nerrood · 为什么在笑话测试中不调用save 1 年前 |
![]() |
eof · Chrome块文件下载-selenium 1 年前 |
![]() |
Display name · Ember.js辛烷值验收试验 1 年前 |
![]() |
Vitto · 理智和回归测试是如何在一个简单的场景中协同工作的? 1 年前 |
![]() |
mattsmith5 · 使用特征文件并行计算空手道跑场景 1 年前 |
![]() |
Norronas · 采用裸机编程的寄存器单元测试 1 年前 |