如何启动自动化测试?
我最初在我现在所在的公司担任软件工程师。随着时间的推移,我要么是唯一愿意或有能力负责各种系统的人,所以我被“提升”为IT经理。现在,在我担任软件工程师期间,我会为我要构建的各种软件模块创建功能测试,因此,即使在今天,我也能够快速测试我所开发的系统的各个部分。然而,这里有一个庞大的代码库,但在这里工作的其他各种开发人员几乎没有覆盖。
现在,作为 IT 经理,我希望能够测试系统的所有部分是否正常工作,但存在:
A) 没有专门用于创建代码测试覆盖率的预算时间
,
B) “首席软件工程师”不希望这样做开始创建测试套件来帮助我监控软件是否正常运行。
我不希望软件团队放弃他们正在做的一切并花两周时间创建测试套件,但如果他们开始扩展测试套件那就太好了 随着时间的推移,我可以确认系统的各个部分都在工作。
归根结底,我如何让软件团队开始构建测试套件?
其他注意事项:
A) 除了管理我们的 IT 部门(一名 UNIX 工程师、桌面支持人员以及相关的办公和生产设备)之外,我仍然被要求做软件项目
B) 我的 UNIX 管理员很难获得生产系统运行完整的代码库,但我们没有从软件团队得到很好的帮助。他无法运行任何类型的诊断来查看网络应用程序在新安装时出现故障的位置。公司的副总裁一直告诉我进去并在代码中执行 print_r 看看发生了什么。这太糟糕了!!!
I started as a software engineer at the company I'm currently at. Over time, I was either the only one willing to or capable of taking responsibility for various systems, and so I was "promoted" to being IT Manager. Now, during my time as software engineer, I would create functional tests for the various software modules I would build, and as a result, even today I am able to quickly test various parts of the system that I have worked on. However, there is a large large code base with little to no coverage from the other various developers who have been working here.
Now, as IT Manager, I want to be able to test that all the parts of the system are working, but there is:
A) no budgeted time dedicated to creating code test coverage
and
B) No desire from the "chief software engineer" to start creating testing suites to help me monitor that the software is functioning.
I don't expect the software team to drop everything they are doing and spend 2 weeks creating test suites, but it would be nice if they started expanding the test suite
coverage over time so I can confirm that the various parts of the system are working.
So boiling it down, how do I get the software team to start building test suites?
Other caveats:
A) I'm still asked to do software projects in addition to managing our IT dept (a unix engineer, desktop support guy, and related office and production equipment)
B) My unix admin has a really hard time getting production systems up running the full code base, and we aren't getting good help from the software team. He can't run any kind of diagnostic to see where the web app is failing on the new installs. The VP of the company keeps telling me to go in and do print_r's in the code to see what is happening. This sucks!!!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
首先,您需要研究测试驱动开发,以便您能够轻松地用开发人员以及管理层能够理解的术语来解释它。由于您似乎正在开发 Web 应用程序,并且您拥有技术技能,因此我建议您尝试一下,选择一个用于测试 Web 应用程序的开源工具,安装它,然后开始为您自己开发的任何内容构建测试。
Twill 是您需要的测试工具类型的示例。
然后,作为经理,您需要吸引开发人员效仿您的榜样,并奖励他们这样做。当他们不使用测试框架并导致可预防的问题时,惩罚他们。一旦发生这样的事件,你应该能够让你的老板参与进来,并获得一些动力。
总的来说,请记住,目标是减少工作量以获得良好的结果。偷工减料是减少工作量的一种方法,但会导致不良或极其不良结果的风险。让管理层了解风险级别和潜在风险成本。
不要只是强迫人们为了测试而进行测试。它必须帮助他们提高生产力,因此请仔细选择第一个项目。
First, you need to investigate Test Driven Development so that you are comfortable explaining it in terms that your developers will understand, as well as your management. Since you seem to be developing web applications, and you have technical skills, I suggest that you take the plunge and choose an open source tool for testing web applications, get it installed, and start building tests for anything that you develop yourself.
Twill is an example of the kind of testing tool that you would need.
Then, as manager, you need to entice developers to follow your example, and reward them for doing so. And punish them, when they don't use the testing framework and it leads to preventable problems. As soon as you get one such incident, you should be able to get your boss on board, and pick up some momentum.
Overall, remember that the objective is to do less work to get a good result. Cutting corners is a way of doing less work, but leads to the risk of bad, or spectacularly bad results. Keep management informed of the risk levels and potential costs at risk.
Don't just force people to do testing for testing's sake. It has to help them be more productive so choose the first projects for it carefully.
这是个好问题。如果有一个正确的答案,更多的软件项目将会成功并交付高质量的产品。
我认为自上而下进行这样的改变不是一个好主意。它必须由开发人员自己驱动。所以TDD方向的培训会很好,但这是一个很长的投资,需要时间。
如果您想要更快的解决方案,您应该考虑功能测试、验收测试和系统测试。通过这些测试,您几乎可以通过所有层测试整个应用程序。如果您正在开发 Web 应用程序,您应该考虑使用 Selenium 来自动化测试。使用它(Selenium IDE)创建测试很容易。
但是仅使用此类测试(而不是单元测试)并不能给您带来 TDD 的优势。
自动化测试至关重要。
That's a good question. And if there was one correct answer to it, much more software projects would be successful and deliver high quality.
I don't think, that it is a good idea to make such a change top-down. It has to be driven from the developers themselves. So trainings in TDD direction would be good, but that is a long time invest, which takes time.
If you want a faster solution you should consider functional-, acceptance-, and systemtests. With these test you test pretty much the whole application through all layers. If you are developing web applications you should consinder using Selenium to automate your test. It is easy to create test with it (Selenium IDE).
But using only such tests (not Unit-tests) don't give you the advantages coming from TDD.
Automating your tests is crucial.
您有测试或质量检查团队吗?
我首先会开始查看他们是否有用于验证构建资格的测试用例。如果没有,您将必须开发这些测试用例来测试产品的核心功能。
下一步将是自动化测试用例。
如果应用程序开发得不好,没有任何故障排除工具或调试功能,那么在将这些工具作为下一个版本的要求添加之前,这将是很困难的。
我的2分钱。
Do you have a Test or QA team?
I would first start to see if they have Test Cases that they use to qualify the build. If not you will have to develop these test cases to test the core functionality of your product.
The next step would be automating the test cases.
If the application is poorly developed without any troubleshooting tools or debugging features it would be tough until these are added as requirements for next release.
My 2 cents.
我不得不不同意 michaelkebe 的观点——除了一些关键开发人员之外,这些变革还需要来自执行层的支持,才能取得完全成功。
如果没有这种支持,您将只是一些看起来“浪费时间为已经可用的东西编写测试”的开发人员。
需要有一个清晰的愿景,并且需要经常大声重复。
我在这里不一定提倡敏捷,但很多时候它很适合企业主。
如果你能以此为卖点,那么你所兴奋的事情(快速交付软件、易于维护、自动化测试等)就会水到渠成。
I'll have to disagree with michaelkebe- these changes need support from the executive level, in addition to a few key developers, in order to fully succeed.
Without that support, you'll just be some developers who look like they are 'wasting time on writing tests for stuff that already works.'
There needs to be a clear vision, and it needs to be repeated loudly and often.
I'm not necessarily advocating for Agile here, but often times it clicks for business owners.
If you can sell them on that, the things that you're excited about (delivering software fast, easy maintenance, automated testing, etc.) will fall into place.