问题描述
我负责管理一个非常大的金融定价系统的测试.最近，我们的总部坚持要求我们验证项目的每个部分都进行了有意义的测试.至少他们想要一个系统，保证当我们更改某些东西时，我们可以发现其他子系统的无意更改.最好他们想要一些东西来验证我们系统中每个组件的正确性.
I manage the testing for a very large financial pricing system. Recently our HQ have insisted that we verify that every single part of our project has a meaningful test in place. At the very least they want a system which guarantees that when we change something we can spot unintentional changes to other sub-systems. Preferably they want something which validates the correctness of every component in our system.
这显然需要大量的工作！这可能需要数年时间，但对于这种项目来说，这是值得的.
That's obviously going to be quite a lot of work! It could take years, but for this kind of project it's worth it.
我需要找出我们的代码的哪些部分没有被我们的任何单元测试覆盖.如果我知道我的系统的哪些部分未经测试，那么我就可以着手开发新的测试，这些测试最终会接近我的完整测试覆盖目标.
I need to find out which parts of our code are not covered by any of our unit-tests. If I knew which parts of my system were untested then I could set about developing new tests which would eventually approach towards my goal of complete test-coverage.
那么我该如何进行这种分析.我可以使用哪些工具?
So how can I go about running this kind of analysis. What tools are available to me?
我在 Windows 32 位 XP 上使用 Python 2.4
I use Python 2.4 on Windows 32bit XP
更新0:
澄清一下:我们有一个非常全面的单元测试套件(另外还有一个独立的、非常全面的 regtest 套件，这超出了本练习的范围).我们还有一个非常稳定的持续集成平台(由 Hudson 构建)，该平台旨在在我们的测试设施中拆分和运行标准的 Python 单元测试:大约 20 台按照公司规范构建的 PC.
Just to clarify: We have a very comprehensive unit-test suite (plus a seperate and very comprehensive regtest suite which is outside the scope of this exercise). We also have a very stable continuous integration platform (built with Hudson) which is designed to split-up and run standard python unit-tests across our test facility: Approx 20 PCs built to the company spec.
这个练习的目的是填补我们的python单元测试套件(仅)套件中的任何空白，以便每个组件都有一定程度的单元测试覆盖率.其他开发人员将负责项目的非 Python 组件(也在范围之外).
The object of this exercise is to plug any gaps in our python unittest suite (only) suite so that every component has some degree of unittest coverage. Other developers will be taking responsibility for non Python components of the project (which are also outside of scope).
组件"故意含糊其辞:有时它是一个类，有时则是整个模块或模块的集合.它甚至可能指一个单一的金融概念(例如，单一类型的金融期权或被多种期权使用的金融模型).这个蛋糕可以用多种方式切割.
"Component" is intentionally vague: Sometime it will be a class, other time an entire module or assembly of modules. It might even refer to a single financial concept (e.g. a single type of financial option or a financial model used by many types of option). This cake can be cut in many ways.
有意义的"测试(对我而言)是验证功能是否符合开发人员最初预期的测试.我们不想简单地在纯 python 中重现 regtests.开发人员的意图通常不是很明显，因此需要研究和澄清任何看起来模糊的东西，然后将这些知识纳入单元测试，使原始意图非常明确.
"Meaningful" tests (to me) are ones which validate that the function does what the developer originally intended. We do not want to simply reproduce the regtests in pure python. Often the developer's intent is not immediatly obvious, hence the need to research and clarify anything which looks vague and then enshrine this knowledge in a unit-test which makes the original intent quite explicit.
推荐答案
对于单独的代码覆盖率，您可以使用 coverage.py.
For the code coverage alone, you could use coverage.py.
至于coverage.py vs figleaf:
As for coverage.py vs figleaf:
figleaf 不同于黄金标准Python覆盖工具('coverage.py') 以多种方式.首先，figleaf 使用有趣"线条的相同标准代码作为 sys.settrace 函数，这消除了一些复杂性在coverage.py中(但确实意味着您的loc"计数下降).第二，Figleaf 不记录执行的代码在 Python 标准库中，导致显着的加速.和三、格式覆盖格式保存非常好简单易用.
如果你想使用figleaf你正在录制的报道来自多种类型的测试，需要聚合有趣的报道方式和/或控制何时覆盖记录.coverage.py 是一个更好的命令行执行的选择，以及它的报告要好一些.
You might want to use figleaf if you're recording coverage from multiple types of tests and need to aggregate the coverage in interesting ways, and/or control when coverage is recorded. coverage.py is a better choice for command-line execution, and its reporting is a fair bit nicer.
我猜两者各有优缺点.
这篇关于如何对我的单元测试进行有意义的代码覆盖分析?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！