正如许多软件测试专家所说,代码覆盖率是识别未测试代码的好方法。但是目标百分比并不一定对测试质量有贡献。这样的覆盖目标鼓励设计不良的测试,编写的目的仅仅是满足系统需求,而不是正确地测试软件。我们同意单元测试很重要,但是当着眼于质量时,它是有限的。一个有用的替代方案是通过测试自动化的功能测试覆盖,它跟踪测试是否执行了重要的值或者与软件特性相对应的值序列。
作为持续测试的一部分的代码覆盖
你的应用程序是否因为未知的原因在每个sprint中开发未知的bug ?不确定你是否产品市场化?
通过单元测试实现代码覆盖一直是上述问题的答案。这有助于避免未知的bug,但在一定程度上。
随着敏捷方法的出现,团队开始在小的sprint中工作。自动化测试变得流行起来,单元测试最终被推到了次要位置。今天,我们有工具可以从自动化功能测试、回归套件、探索性测试甚至单元测试中执行代码覆盖。
这些工具通过仪表板中的表格和图表提供了对不断发展的代码的良好概述,因此提供了值得赞扬的发布信心。这些工具对应用程序代码执行单元和自动功能测试。从两个垂直领域的比较现在是可能的,让测试人员分析生产版本。
对传统代码覆盖方式的再思考
单元测试最初被认为是代码覆盖率的唯一度量,这通常会导致设计糟糕的测试。这样的测试通常是为了满足系统需求而编写的。单元测试很重要,但只有在质量目标有限的情况下才重要。
在这里,除了单元测试之外,还包括测试自动化和功能测试的代码覆盖是一个更好的选择。它确保源代码满足系统需求,因为使用功能测试和单元测试来生成代码覆盖率。测试质量一定会改进,因为覆盖率比仅仅基于单元测试更全面。
代码覆盖的新趋势
如上所述,单元测试在通过代码覆盖来提高质量时是有限的。因此,必须考虑集成测试、验收测试甚至手工测试作为标准。这现在可以通过SeaLights实现,甚至JaCoCo现在也通过功能测试提供了代码覆盖。
SeaLights
这是一个持续的测试平台。它与测试环境集成,并度量所有类型测试的测试覆盖率。SeaLights提供关于测试范围和未测试代码更改所涉及的风险的见解。
特性
- 通过自动化功能测试和手动测试实现代码覆盖率
- 测试的差距分析
- 发布质量分析
- 质量趋势,图表和仪表板来分析结果
- 与Jenkins和Maven集成
好处
- 清晰的统计数据,描述QA自动化覆盖了哪些应用程序代码
- QA可以专注于未触及的自动化领域
- QA可以看到现有代码覆盖率的结果趋势
- 帮助QA团队计算功能测试覆盖率
- 了解更多
JaCoCo
JaCoCo是一个基于单元测试计算覆盖率的代码覆盖率工具。它是用Java语言开发的,并提供了对Groovy的支持。它提供了良好的代码覆盖率度量报告,并基于方法/分支/行计算代码覆盖率的百分比。JaCoCo在Java类的字节代码中添加了用于覆盖率计算的代码行。在执行时,它用覆盖率信息检测测试中使用的类文件。这就产生了雅可可。Exec文件,然后使用该文件生成代码覆盖率报告。
-
特性
- 开源工具
- 用Java编写,涉及方法、分支和行
- 可以与Ant、Maven、Jenkins和TeamCity执行和集成吗
- 提供上次执行测试的报告
- 了解更多
对QA团队的好处 采用代码覆盖工具使我们能够按照以下条款进行决策 |
---|
从这些工具生成的报告告诉开发人员代码(分支/行/条件/方法)或输入,这些输入大多数情况下不会被测试自动化场景使用。这些报告帮助团队确定关键领域的优先级。这样可以确保:
|
QA团队能够为未发现的代码区域创建新的测试用例 |
死代码检测可以在以下方面帮助我们:
|
实现代码覆盖的技巧
- 从一个目标开始;不要一开始就追求100%的覆盖率
- 目标是一个考虑功能测试以计算覆盖率的工具
- 关注在每个发布周期中增加代码覆盖率
- 使用以前的分析报告对每个sprint进行评估
- 选择一个支持您的代码覆盖工具
- 应用程序的编程语言
- 像Maven, Jenkins这样的工具,bug跟踪和项目管理工具
有建议吗?
我们很乐意听取您的反馈、问题、意见和建议。这将帮助我们使我们更好,更有用的下一次。
分享你的想法和想法knowledgecenter@qasource.com