关键词：鞍山达内软件测试培训学校,达内软件测试 达内软件测试 鞍山达内软件测试培训学校,达内软件测试
鞍山达内软件测试培训学校,达内软件测试
专业软件测试培训座右铭：要脚踏实地的从小做起，团队重于个人作用。——史玉柱.
如何找出系统能承受的最大在线用户数
一、背景原因
我们在性能测试工作中，有时需要对业务系统所能支持的最大在线用户数目进行评估。和平时的性能测试有区别的是，用户在线时只是与服务器保持连接，并不一定对服务器有业务请求，从而对服务器不一定会产生压力。
但是因为在线用户数目并非可以无限增长，当在线用户数目达到应用服务器(或者WebLogic等中间件，或者数据库连接池等)的连接数设置的极限时，业务系统同样可能会发生异常，出现新用户无法登录，或者老用户被挤出系统，甚至业务系统宕机的情况。
因此，对业务系统的最大在线用户数指标进行测试是极其必要的。
现有一OA系统，需要测试其支持的最大在线用户数目。已知当使用浏览器登录该系统后，登录用户可持续地保持登录状态，即使长时间不做任何操作也不会自动退出系统;通过该OA系统的在线用户数统计模块可以详细地查看到当前在线的用户。
二、测试思路
测试被测系统所能支持的最大在线用户数，需要不断地使用新用户帐号进行登录操作，在此同时查看被测系统的在线用户数目以及系统的响应情况。在新增登录用户时需要注意，由于考察的是系统在正常情况下所能支持的在线用户数目，而不是系统在并发压力下的性能响应情况，因此登录用户时最好采用单个用户或少量并发用户(如两个或三个)逐步登录的形式，不同登录批次之间最好能有一定时间间隔，务必使新增登录用户的操作对服务器产生尽可能小的业务压力。
在新增登录用户的过程中，需要对被测系统的在线用户数目进行查看，并着重关注以下几个方面：
持续新增登录用户的同时，业务系统中的在线用户数目是否相应地进行增长
持续新增登录用户的过程中，系统登录操作是否产生连接超时的情况，事务的响应时间是否出现大幅度上升的情况，系统登录事务是否出现失败的情况(这需要在脚本中对登录事务做检查点设置)
持续新增登录用户的过程中，定期地在浏览器中手动刷新业务系统界面，查看业务系统是否出现不可访问的情况(如内部服务器错误、宕机等)
需要注意的是：使用测试工具测试时，并不能像浏览器一样定期地与服务器进行通讯交互。我们需要用脚本模拟浏览器的定期交互行为。
三、测试结果分析
通过以上方法可以测试得到业务系统所能承受的“初略的”最大在线用户数目。为什么说是“初略的”呢？因为该方法仍存在缺陷，主要体现在如下两个方面：
该方法只适用于测试期间无他人使用系统的情况。如果测试期间同时有其他用户登录系统，或者系统中本身已存在在线用户，则会造成测试得到的结果不准确。
该方法忽略了系统稳定性对在线用户数的影响。举例来说，也许逐步增加在线用户数至500时，系统并没有发生异常，但这并不意味着500个用户长时间处于在线状态时系统不会出现异常。
针对以上两方面缺陷，可以做出如下改进：
在逐步增加在线用户数的时候，定期(比如间隔3秒)查看业务系统自身统计的在线用户数目，并以该数据为测试结果。
利用之前的方法测试得到业务系统“初略的”最大在线用户数后，使系统长时间保持该数量的在线用户数目，观察系统在长时间运行期间是否会出现异常;若出现异常后，适当减少在线用户数目后重复地进行测试，直到系统可以保持长时间地稳定运行为止，此时对应的在线用户数目即为业务系统所能承受的最大在线用户数目。
达内软件测试培训广州客村中心地址：广州市海珠区新港中路354号珠影大院珠影、蓝谷2栋1、2.
鞍山达内软件测试培训学校,达内软件测试
软件测试培训机构达内经典语录：再冷的石头，坐上三年也会暖。.
软件测试之业务测试如何做？
“前言：万事万物都有规律可循”
互联网是一个知识的更新迭代非常迅速的行业。每天都会有新的业务兴起，不知道新业务的优缺点，不知道测试重点，无法快速有效找出产品的可能性bug?
这些部分，是什么能力?如何快速掌握一款未接触的能力?如何快速定位一款未接触产产品的可能bug。 这些，自动化测试?性能测试?牛x的脚本能搞定?显然不行
从大的方向归纳，其实，还是属于最基本的功能测试，探索性测试。 需要具备的能力，是见多识广，与经验息息相关。
这也是很大大牛的核心竞争力，你通过各种看起来高大上的技术手段，折腾个一天，没发现几个问题，有经验者，随便使用下，就能发现一大堆显而易见的Bug，以及各种明显不合理的使用习惯，无法满足用户场景的臆测需求。
业务测试 是我们所有测试的核心基础
虽然业务千变万化，但是万事万物都有规律可循。以下就是业务测试的一些通用思路，希望对大家有帮助
一、整体的角度，项目类型划分
1.全新项目
2.已有项目新增业务
3.已有项目改造
二、测试模块
1.新增
2.删除
3.修改
4.查看
未完待续
三、测试端
web测试
1、浏览器兼容性
2、直接输入地址是否跳过权限判断
3、自带键：返回键、回车键、刷新键的使用
4、缓存过期
app端
1、app多系统测试
2、app多分辨率测试
3、使用习惯不同(安卓自带返回键等)
4、网络类型
5、安装/卸载测试(区分安装新包和更新包的验证)
6、升级测试(重点关注增量升级)
7、并发测试(尤其是有push弹框)
8、消息推送(锁屏、应用后台运行、应用打开)
9、分享(多平台分享实现)
软件测试培训网格言：合理安排时间，就等于节约时间。——培根。
鞍山达内软件测试培训学校,达内软件测试
达内软件测试培训青岛中心地址：青岛市市北区金坛路17号服务外包基地A座5~7楼。软件测试常见性能问题
性能测试大致分以下几个步骤：
需求分析
脚本准备
测试执行
结果整理
问题分析
今天要说的是最后一个步骤——“问题分析”;
需求描述
有一个服务，启动时会加载一个1G的词表文件到内存，请求来了之后，会把请求词去词表里做模糊匹配，如果匹配到了就向一个后端服务发送一条http请求，拿回数据之后，返回给客户端的同时，向mysql记录请求的唯一标识和一个请求次数的标记;
其中有几个关键函数
模糊匹配(fuzzyMatching)
后端请求函数(sendingRequest)
拼装请求函数(buildResponse)
记录mysql请求次数标记(signNum)
问题及分析
第一组：完全随机请求词，qps达到1k时，服务器未见异常，cpu、内存、带宽均未满，qps无法继续提升;
分析：由于此服务后端连接了其它服务，所以在压测之前，要确认后端服务不会成为瓶颈点，目前的状态很可能是后端服务限制了被测服务的性能;此时可以检查后端服务所在机器的各项指标，或者查看本机的连接状况，一般后端服务无法处理，而被测服务又会一直向后面请求的话，timewait状态的连接会变得比较多;
第二组：解决后端服务的问题后，第二组使用平均30个字的请求词，来打压，qps到400时，cpu load已满;
分析：这种情况明显是由于fuzzyMatching函数计算效率的问题导致cpu满载，从而无法提升qps，使响应时间不断增大，此时可以通过perf+火焰图来确定整个处理请求过程中响应时间长的函数;此时需要评估压测数据是否合理，如果线上平均请求词只有2个的时候，此组测试明显不合理，此时要开发进行性能优化就是浪费时间的;如果评估测试数据合理，可以再次更换短词数据进行压测验证猜测;
第三组：解决了上述两个问题之后，使用完全随机请求词，qps到达3k后降低至1k，然后再次提升到3k，如此反复;
分析：此时关注一下各项指标，排除了以上的问题的话，操作mysql慢的问题可能性大一些，对这种需要高并发的系统来说，直接读写mysql不是个聪明的解决方案，一般会用redis做一层缓存，这里说道的另一个问题就是开发设计不合理，导致的性能问题;
第四组：将后端换做真实的服务来做整体压测，发现qps最高只能到300，此时检查各项指标，发现入口带宽占满了;
分析：这次问题比较明显，后端服务返回内容过大，导致带宽被占满，此时依然需要评估需求：1、是否需要后端返回的所有数据内容;2、评估更换万兆网卡的性价比;3、是否可以通过技术手段优化带宽占用，比如把一次请求分散到多组服务的多个请求;
perf+火焰图定位函数问题
这里简单说一下如何使用perf+火焰图来直观的定位性能问题：
perf
Perf 拥有了众多的性能分析能力，举例来说，使用 Perf 可以计算每个时钟周期内的指令数，称为 IPC，IPC 偏低表明代码没有很好地利用 CPU。Perf 还可以对程序进行函数级别的采样，从而了解程序的性能瓶颈究竟在哪里等等。Perf 还可以替代 strace，可以添加动态内核 probe 点，还可以做 benchmark 衡量调度器的好坏。
使用举例：perf record -e cpu-clock -g -p 11110 -o data/perf.data sleep 30
-g 选项是告诉perf record额外记录函数的调用关系
-e cpu-clock 指perf record监控的指标为cpu周期
-p 指定需要record的进程pid
生成火焰图
1、第一步
使用压力测试工具对程序进行打压，压到程序拐点;
$sudo perf record -e cpu-clock -g -p 11110
Ctrl+c结束执行后，在当前目录下会生成采样数据perf.data.
2、第二步
用perf script工具对perf.data进行解析
perf script -i perf.data &> perf.unfold
3、第三步
将perf.unfold中的符号进行折叠：
./stackcollapse-perf.pl perf.unfold &> perf.folded
4、最后生成svg图：
./flamegraph.pl perf.folded > perf.svg
原生的perf可以直接定位C/C++的程序，通常编译debug版本的程序能看到更多的信息，java、go等语言可以通过各自定制的工具来生成，原理类似;通过火焰图可以轻松定位到哪个函数的处理时间最长，从而找到问题所在。
软件测试培训机构达内经典语录：环境不会改变，解决之道在于改变自己。。
鞍山达内软件测试培训学校,达内软件测试
软件测试培训达内荣誉：2013年12月，荣膺新浪网“2013年度最具品牌知名度职业培训机构“.
