用例的组织还是以目标系统可能出现瓶颈的关键测试点为准，展开用例的设计。这些很多时候需要经验。自动化个人认为更多的用处应该是体现在回归测试，而非性能测试，两者应该分开。当然想把性能测试自动化也可以，windows计划任务，linux下的crontab，甚至自己写脚本，写个简单的C/S程序来控制都可以，至于数据的收集么，脚本和程序都可以做到的。
2、最大用户并发数/集合点（Rendezvous Point）的测算是否有合理的公式 （网上那些老的公式不是太合理，就不要重复列举了）
不同的系统，不一样。举游戏中的不同游戏类型为例，休闲类游戏数据交互少，单个进程甚至可以支持2W人在线；而大型游戏只有5，6千。因此这个用户数我认为还是以目标系统设定的容量上下浮动来测算，没有固定的公式。
3、自动化用例如何维护和运行？比如回归测试用例以及产品新功能的用例如何添加和管理？
写尽可能简单的用例脚本或者描述，而通过程序生成不同的用例。举例，假如一个自动化的用例是通过配excel表来实现的，你需要通过脚本发送file1.sheet1.A列中所有的数据，每次发一个，到服务器验证，那么尽量只通过 send file1.sheet1.A这样的一句脚本来完成用例的编写，而是让你的测试工具自动去send file1.sheet1.A1~An的数据，这样可以有效降低维护成本。
我一直觉得自动化就是用来做回归测试，它的价值在回归测试中体现得最充分。因此，每一个新系统的用例，都应该是新编写的，而这些编写好的用例，就是下次回归用，在本次新功能测试中，用处有限。
4、自动化用例的运行方式和日志如何管理？ 是每日晚上跑一遍还是每周末跑一遍？生成的报告如何归档和阅读？
运行方式与自动化工具有关吧，如果linux平台的，可以写crontab，脚本定时；win平台的，计划任务都可以。日志管理方式多了吧，简单点可以直接在脚本里调用svn up什么的，提交到svn服务器，或者架设个webserver，写点简单的逻辑，直接将log拷到固定目录，按日期分类。然后web写一些简单的逻辑，在web页面显示这样log目录和文件列表，甚至可以做一些解析，绘制图表等。对于报告的处理，我个人认为也可以采用这样的方式。至于执行频率，个人觉得没必要天天执行吧，一周执行一次或者一个里程碑版本执行一次就可以了。
5、对于服务器端->客户端的“响应时间”可以测算，但是如何测算客户端的实际运行/执行某个任务时间？比方webgame 实际loading某个场景的时间或者说是“实际加载时间”？
可以和程序沟通，加log，比如在接到这个包的时候写个时间点，微秒级的，在处理完以后再写个时间点，两者减一下就可以了。
如果得不到程序的支持，那就自己想办法，一般可以使用hook技术来挂钩子，把上面说的功能自己加上。
6、一般C/S性能测试的瓶颈除了硬件问题还有哪些？通过自动化测试如何进行排查，请给出实际真实案例？
其实硬件真算不上什么问题。如果真的程序没问题，也没有优化空间，硬件不行就换好的呗，4G内存不够换8G，四核心CPU不够换八核呗。
性能上的问题，最怕的其实是程序上的。除了硬件，一般有如下几个地方需要关注：
涉及网络IO的，涉及DB存储的，涉及大量磁盘IO的，涉及大量运算的，涉及内存分配的。
分别举例，网络IO体现在大量用户并发连接及高频率上报/请求数据；涉及DB存储的一般是数据的更新，比如游戏中的登录，游戏中玩家数据更新，玩家退出游戏等；涉及大量磁盘IO的典型就是需要写大量的log来做为一些数据记录永久保存，比如关键交易数据等；涉及大量运算包括程序里面需要在大量的数据中查找特定记录、排序等等；涉及内存分配一般有大量对象创建与销毁，还有分配策略，是预分配还是即时向OS请求等。
自动化测试排查性能测试的缺陷目前我这边没有经典的有必然联系的案例，原因是我认为性能测试不需要自动化，自动化应该是针对逻辑进行的测试，性能方面还是边测试边调整更可靠。
7、window客户端指定进程的资源占用是怎么监控的？有没有好用的工具？
windows性能计数器，系统自带，很不错了。还有就是spotlight，开源但强大的工具。
