|
后来的事情呢,我的团队在自动化测试方向做得还好,有过一个比较关键的突破,受到高层管理团队的肯定,用大boss的话来说“这个方案解决了公司自xx领域产生20年以来的空白”。实际上,为此我们也付出了相当的努力,持续几年的投入,将近10万行代码的开发量,终于在最后一刻灿烂了,那种感觉真的很棒。
再后来,一个机会,我的测试团队直接转为开发团队,负责云平台上的服务开发,经过测试转型和新聘开发人员,磨合碰撞中,终于上了正轨,花了一年多的时间,团队内建立了敏捷开发的流程,开发规范,还有一套自动化测试验证框架,使bug尽量在最早的开发阶段被发现。因为做过测试,所以我对测试更加重视。
下面从开发的角度来看看bug是怎样产生的
1)性能bug
软件性能在本质上是一个空间和时间转换的问题。
1. cache的使用
应该考虑为重复使用的数据设计cache机制。cache中常规的有配置数据,用户信息,resourcebundle等等,这些读概率非常高的数据一般都在app启动时就加载到内存的cache里。我还遇到一个有趣的现象,发现java的反射机制是十分消耗时间的,在10ms级别。因此,在第一次反射后就将annotation放在cache中会大大提高效率。实际上, cache里什么都可以放,对象,甚至interface和class的定义也可以放进cache。cache在提高效率的同时,也会带来新的问题,比较头疼的就是cache同步。在多节点的环境里,测试人员可以设计多节点同步,restart app server,shutdown db等测试案例,发现可能的cache的问题。
2. log的级别
之所以把它放在第二位,是因为它不起眼,但是却能制造大麻烦。在一般情况下,log可以设置error级别,但开发人员在开发过程中,容易把一些不重要的信息都塞进log里以便调试,如果不注意调整,log就成为潜伏最深的性能问题,我遇到过访问一个页面,后台写了45次error log, 每次log都要占用20多ms, 对性能影响非常大。
3. DB server的问题
对于Oracle DB, 最好用的性能监控报告是awr了。awr最初级的指标就是top sql。可以发现哪些sql耗费时间,能够发现不合理的table设计,索引问题。对db性能有杀伤力的是trigger,trigger可以方便解决一些场景,但性能上比较耗时间,慎用,有的公司DB设计规范就不建议用trigger。我看过一个大型的电信系统数据库竟然使用了几百个trigger,真是开了眼界。
4. java 线程同步
在java里,经常使用synchronized关键字定义同步的代码块。但对于synchronized的高昂代价java开发者一直非常谨慎。在stackoverflow里有讨论。
http://stackoverflow.com/questions/1671... ve-in-java
多个线程并发情况下,synchronized只会允许一个线程进入代码块。
5. java对象复用
在javadoc里,有一些object是建议复用的。比如simpleJdbcCall,httpclient等,因为它们在初始化的时候,要使用非常多的资源,为了提高效率,需要复用。采用单点实例是一个不错的办法。性能测试中,通过监控java的heap,可以观察到对象的数量和创建频率。 |
|