web前端性能分析工具

1)ibmpagedetailer。注册IBM 帐号后，下载了basic版本的。第一个感觉就是惊艳，能把网页duration（切分服务器时间、下载时间等，与loadrunner page break down类似),item等等.基本上满足我们目前需求.

  在启动page detailer后，再启动IE后的HTTP 请求都被截获。

2) firefox插件firebug。呵呵，这个工具开源的，功能也很强大，而且javascrīpt调试能力好。呵呵，目前 ALIBABA的部分应用支持firefox不如ie好啊。

3)yahooyslow。也是firefox插件。偶还没有试用过:)

   前2个工具切实给页面调优带来较大的想象空间：） 

   看来好工具还是很多的，关键是要有发现的眼光:)

前端性能分析工具分享PPT

和阿里巴巴集团各个公司QA分享的PPT。

平常我们用loadrunner发现缺少页面渲染时间的度量。
在执行压力的同时，结合前端性能分析工具抽样检查页面性能是一个不错的选择。

ppt参考了多个网站的内容以及结合自己的实践。

为了能<2048 byte，偶作了删减

http://www.51testing.com/?uid-13997-action-spacelist-type-blog-itemtypeid-6288

Open API

http://fairyfish.net/2008/07/16/chinese-open-api/

测试计划考虑的几点

测试计划最终结果把WBS有控制完成。测试计划符合SMART原则。

1 选人：
从几个纬度考虑
(1) 尽量发挥技术特长
(2) 结合项目兴趣
(3) 技能高+ 技能低些的结合。涵盖项目所需技能。或者不完全具备，需要有学习能力强的排头兵

2 工时估算

这个是一个很难估算准确的活。因为一个项目充满变数。
学会工作分解，然后再按每个功能点/测试范围乘一个冗余系数
可以采用project, mindmap, excel等

3 风险分析与规避
通常测试项目风险
1) 研发提交代码质量不高，冒烟测试失败
2) 研发更改频繁，送测版本过多
3) 需求文档或者设计书不够明确,QA 和需求/研发细化耗时
4) QA 测试分析不够全面
5) 性能问题分析以及调整影响面过大
6) 测试的覆盖率过低
7) 技术难题或者测试环境资源问题
...

4 确定测试范围

由于项目有外部耦合模块，要非常明确影响范围十分困难。
通常做法: 用工具绘制调用网状图。或者分析正相关的模块结合自动化测试脚本确定测试范围

5 确定测试策略

确认系统是否需要性能测试，安全测试，兼容性测试，本地化测试...

以及是否需要验证系统的高可用方案， 新旧系统平滑过渡方案 ，可扩展容量估算公式...。

6 项目的工作约定

比如采用的模版，沟通方式（IM/周会。。。)，项目出现问题的解决流程

测试工具评估的项目管理一些思路

1        项目特征
1.1        以项目应用推广发挥作用为目标
1.2        工具评估过程存在较大的不确定性，可能遇上某一个技术难题瓶颈，或者需要确认适合的应用场合。有时候一个关键的问题没有突破，后续的工作就必须停止。
1.3        项目任务切分困难，工作边界不够清晰
比如评估watri能否足以成熟到支撑大型电子商务网站自动化。
本质上不仅仅评估watri 能够识别我们网站普通的WEB元素以及比较特殊的元素(如html编辑器、windows/javascript弹出菜单、随机验证码…)；还需要评估现有QTP/vbscript框架能否平滑过渡到watri编写的框架以及过渡的成本。
2        实施思路
大原则是在项目进度透明和给予组员充分自主间找一个平衡，根据产出不断诱导深入了解工具各项特性。

1)        项目一般都以1个月为单位，制定一个周为单位的计划，充分列举可能的风险。每周都定义清晰的进度标准，周五前提交本周测试工具的操作、特性以及产出的脚本。最好主管自己能够抽几点难度大的review下
2)        真正深入之前把项目的最坏情况想透，以及工具的可能应用场景。
3)        对于一个瓶颈问题，如果2天都没有突破，需要第一时间告知主管，让主管决断是增加优势资源突击解决还是整个项目放弃
4)        为了诱导组员深入考虑每一个重要环节，主管最好能够花些时间了解相关的技术细节，抛出一些有深度的问题让组员考虑技术方案

呵呵，这些思路是我自己从广东电信的主任那学习转化到的。个人认为适用的就是最好的