<% if session("name")<>"" then response.write("当前用户:"&session("name")) response.write("  注销") response.write("  修改资料") else if request.cookies("name")<>"" then response.write("当前用户:"&request.cookies("name")) response.write("  注销") response.write("  修改资料") end if end if %>
首页 > 经验与观点>产品使用经验 >JProbe >单元测试性能分析报告

应用性能管理

 
  • 在服务器端进行数据库审计的优势
  • 服务器端审计工具与所谓非侵入性审计工具的比较
  • 如何提升运维管理
  • ITIL提升中国电信运维管理系统建设
  • 提高Java性能的几个高效用法
  • 提高J2SE性能的代码技巧(上)
  • 提高J2SE性能的代码技巧(下)
  • 应用管理的概念和流程
  • 应用管理的运营和优化
  • 开源时代:Navicat实现从MS SQL到MySQL的数据迁移
  • 使用Navicat导入数据到MySQL
  • 单元测试中贯彻持续性能管理
  • 单元测试性能分析报告
  • 利用Hyperic HQ管理WebLogic
  • Hyperic HQ监测Linux系统10条最佳成功经验
  • 什么是服务等级管理
  • 服务等级管理的步骤
  • 服务等级管理中的关键控制要素
  • 服务等级管理中需要注意的几个问题
  • 什么是容量管理
  • 容量管理的几个重要环节
  • 容量管理中的关键控制要素
  • 容量管理中需要注意的几个问题
  • 持续性能管理的先决条件
  • SQL Server调优的五个步骤(上)
  • SQL Server调优的五个步骤(下)
  • J2EE性能问题的分析
  • J2EE性能问题的诊断
  • J2EE性能问题的诊断示例
  • 应用性能管理-从操作系统做起
  • SQL Server常见性能问题的优化
  • 应用性能管理(APM)的价值分析
  • Bea WebLogic Portal的性能监测和诊断
  • 数据库性能基准的五个问题
  • Portal的性能挑战
  • 在多种数据库环境下管理业务需求(下)
  • Oracle DBA如何管理DB2(下)
  • 在多种数据库环境下管理业务需求(上)
  • Oracle DBA如何管理DB2(上)
  • SQLServerSQL调优技巧
  • 诊断应用数据库的性能瓶颈
  • Oracle优化的五个方面
  • Microsoft的优化SQL方法
  • 理解SQL Server的SQL查询计划
  • 自动化性能测试
  • 优化应用质量和性能,支持和推动业务发展
  • 从PMO到CIO办公室—PMO的发展趋势
  • 实施自动化功能测试的解决方案
  • 软件自动化测试流程
  • 测试自动化的成功经验
  • 无计划的变化导致的IT风险
  • 降低无计划的变化导致的IT风险
  • 应用性能管理中的价值链分析
  • 应用系统"亚健康"的严重性
  • 应用系统"亚健康"现象和原因
  • 性能测试的准备
  • 性能测试的六个阶段
  • 性能测试的容量评估
  • 优化DB2数据库的十个最佳实践
  • 优化DB2数据库的十个最佳实践(续)
  • 在生产中监测和优化J2EE应用性能
  • 改善J2EE性能和用户体验的管理变革
  • 跟踪数据库性能变化
  • 优化ERP应用
  • 在生产中测量J2EE应用性能
  • Oracle SQL性能优化技巧1
  • Oracle9i查询优化工具初探
  • APM的方法和技术实现
  • J2EE性能问题的症状和优化
  • 构造高性能J2EE应用10个技巧
  • 软件工程与知识管理

     
  • 采用CASE工具管理多个并行应用软件开发项目
  • "软件工程"中的分工有效吗?
  • 实施知识管理软件的几个细节
  • 拯救知识管理
  • 知识管理与知识管理软件
  • IT培训师指要
  • 推荐产品的使用

     
  • Toad快速入门
  • PerformaSure J2EE性能诊断
  • PerformaSure J2EE健康检查示例
  • Spotlight实时诊断WebSphere Server实践
  • Spotlight实时诊断WebLogic Server实践
  • JProbe实践之"性能瓶颈"
  • JProbe实践之"短期对象循环"
  • JProbe实践之"内存泄露"
  • JProbe实践之"代码覆盖"
  • Quest Jprobe最佳实践(上)
  • Quest Jprobe最佳实践(下)
  • Foglight-APM与SLA的有力武器





  • 单元测试性能分析报告

            www.InnovateDigital.com 整理

           单元测试分析报告应提供整个测试的执行情况,应包括多种度量值,具体如下:

    • 单元测试数量
    • 汇总的代码覆盖情况 (可分析到类,方法,行以及忽略的条件)
    • 内存改变的总数
    • 对象改变的总数
    • 测试总时间

           报告的详细代码覆盖部分按覆盖率深入到单个包,类和方法。.如果你找到一个感兴趣的类或者方法,查找附加的覆盖信息时,根据记录的快照,可启动JProbe交互控制台,你可以根据每行代码的覆盖提示直接浏览代码。不需要向开发人员提供所有的测试结果,只将有问题的转给开发人员做深入诊断即可。

           报告的内存详情和性能部分按照单个测试用例分开。内存报告显示了测试用例(按完成后在堆中留下的内存字节数排序)并包含了前几个对象的类型,数量和单个对象类型的字节数。和覆盖报告相似,所有的内存结果都被保存,以便通过JProbe console交互性浏览。在本例中,每个测试用例都有一组前、后的堆快照,它让你可以跟踪到在堆里每个已创建对象的代码行。

           最后,报告的性能详情部分按总的测试用例时间排序,显示了每个测试用例,并包含了每个方法在测试用例里所占的响应时间。还包含了单个方法的时间,方法的累积时间,和因异常而结束的执行数量。

           如图显示了一个单元测试性能分析报告执行概要部分的截屏。

    单元测试性能分析报告执行概要部分

    单元测试性能分析报告执行概要部分

           这份报告的用途是给开发经理,团队领导,CIO,或者其它感兴趣的人员呈现一份快速的性能参考。它提供了一个以业务为中心的应用性能概览,让用户可以下钻到单个应用组件作更深入的诊断。最理想的是,开发经理或者团队领导会审核这份报告,把性能问题归因于相应的开发者身上。开发人员会收到(有问题的组件)的详情,然后获得相应的JProbe快照诊断这个问题。

           将这些报告集中维护,开发经理和团队领导们可以快速确定应用性能的趋势。然后,他们可以快速优先修复有问题的组件,在性能问题还没有出现以前控制它们。可以更进一步,每个报告都可以保存为XML格式,与HTML等同,允许在构建之间自动趋势和影响分析。


    (北京铸锐数码科技有限公司 www.InnovateDigital.com)

     
    北京铸锐数码科技有限公司 版权所有 © 2008
    中国·北京市海淀区大钟寺13号华杰大厦8A9-2室
    邮编 100098 电话 010-62139280 传真 010-62135268    京ICP备05019494