今天完成的事情：
看了并发测试 和压力测试，负载测试
明天计划的事情：任务七
遇到的问题：

没有
收获：

想确定用户并发数；必须知道系统所承载的在线用户数；例如关注：用户的总量、用户平均在线数值、用户最高峰在线数值。
例如：公司OA系统账号或者总用户有2000人；最高峰在线500人；但是这500人并不是作为并发用户存在的概念。即并不表示服务器实际承载的压力；有可能40%关注的是首页新闻公告板之类（注意看新闻这个阶段是不能造成服务器的压力）；20%用户在查询资料或者操作表格；20%用户在发呆；20%在页面之间跳转；在这种情况下，只有真正20%用户在对服务器造成实质的影响。
我们将这个查询、操作表格作为一个业务范畴来说；直接将这部分业务并发用户称为并发用户数：
1.计算平均并发用户数：C=NL/T
2.并发用户峰值数：C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，（可以看注册信息）平均每天大约有400个用户要访问该系统，（日志文件查看）对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值，2或者3.
假如说用户要求系统每秒最大可以处理100个登陆请求，10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候，响应时间还在允许范围呢，就要加大用户数，例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

压力测试
要求
首先是对脚本的要求：
1、录制脚本(注意所有的脚本都应录制到Action中)，自定义事务，事务从提交用户名和口令的脚本之前开始;
2、在定义事务开始的脚本前加入集合点;
3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可;
4、参数化登录用户的身份;
其次是对场景设置的要求：
1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定;
2、建议修改运行时设置，优化对服务器的访问; [Page]
3、计划的设置，每x时间后加载10用户(根据总用户数设置)，完全加载后持续运行不超过5分钟(根据需要设置);
4、集合策略，当运行中的用户数100%达到集合点时释放;
5、注意事项，需要注意几个时间：1)服务器响应超时时间;2)登录事务迭代一次所使用的时间;3)集合点等待超时时间;4)计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。
这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。
通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。
以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。
使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。
实例
利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。
本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的软件压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管)，中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的软件压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。