* 分析： SkuDB#deleteSkuByItemId()方法实现的不好，我们都是逻辑删除（status = -1），当初写的时候为了省事，查询出所有sku再遍历调用update（因为先实现query, update 再实现delete，图省事少写几行代码@\_@），而update为了通用性会先查一把数据是否存在，也就是调用一次queryCountBySkuId()。由于这个设计的存在，所有的操作（删、改、查）最终都会调用一次queryCountBySkuId()，造成了query方法调用次数膨胀。
执行时间20ms也超出预期，review queryCountBySkuId()方法，发现拼出的sql里没有带上item_id，没用到索引。
* 解决方案：调整deleteSkuByItemId()方法的实现，直接拼sql更新status字段，缩短调用链；
修改sku、auction\_image这2张大表的所有sql，利用索引提升性能；
* 收益： CSellerChangeItemPropertyTest 执行时间从340s降到10s，提升约6min；
3．增加日志打点，提取更多数据
从现有日志数据中发现的问题已经解决，添加更丰富的日志，输出@Before-->@Test-->@After的时间，@Test的时间，由于我一直怀疑数据清理耗时太多，顺带也打出了数据清理的时间，见下
……………………
maven surfire输出了每个类执行的总时间，日志输出了Junit所有注解的执行时间，因此可以计算出@ITestxx各种注解的执行时间，分析一次30min的日志（实际test时间为27min），Junit时间为10min，ITest时间为17min。
数据清理时间总共才1min（含在Junit时间内），日志提取的数据告诉我，数据清理速度很快，不需要再继续优化了。
>（ps：这里的运行时间指的是一次构建所用的全部时间，从调度开始到运行日志回写结束，调度开始、启动脚本、更新代码、回写日志时间约1min，由于sell-test测试的是web工程，还有一个打包过程，约2min，因此有约3min的时间差）
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
