实验室开放平台测试报告.docx
《实验室开放平台测试报告.docx》由会员分享，可在线阅读，更多相关《实验室开放平台测试报告.docx（10页珍藏版）》请在冰点文库上搜索。
实验室开放平台测试报告
实验室开放平台测试报告
（v1.3）
版本号
修改详情
时间
备注
1.0
完成了文档草稿的撰写
2015-4-8
1.1
添加了组件库方面的用例
2015-4-9
1.11
修改了查看用户信息等用例的细节
2015-4-10
1.2
填写了用户信息等用例的测试结果
2015-4-10
1.3
填写了用户动态等用例的测试结果
2015-4-11
1.31
填写了组件库等用例的测试结果
2015-4-12
1.4
填写了功能测试的测试结果
2015-4-13
概述
本次测试的目标系统是实验室开放平台，本系统的主要功能包括：
登陆、个人中心、任务管理、项目管理、风险管理、注销等。
相关文档
与本测试文档相关的文档有：
《实验室开放平台设计文档》v1.3
《功能测试用例设计文档》v1.4
功能测试：
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
本项目的功能测试采用等价类划分，人工输入验证的方法开展测试。
（测试用例的设计参看文档《功能测试设计文档》）
本项目的功能测试自2015年4月10日开始，截至4月13日，根4-据设计的测试用例，发现和修复defect/bug情况如下：
既包括上述的测试用例，也包括一些显而易见或其他情况下未涵盖的用例。
截至到2015年4月15日，修复的defect/bug情况如下：
其中：
在过去的大致统计中，将近一半被修复的defect/bug在经过两次以上的修复过程才得以修复，大部分出现的defect/bug源于设计工作力度的不够，以及编程人员的粗枝大叶和逻辑不严谨造成的。
可用性测试（用户体验测试）
可用性测试旨在帮助开发团队了解来自用户的反馈，并依此改善现有设计，修复之前没有发现的问题，其具体实现方法是让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
针对本项目，我们把平台部署后，邀请实验室其他成员登录该平台进行体验，并请大家提出改进意见同时，在事先不告知该平台具体细节的情况下，观察他们的上手情况。
下面是截至到4月15日上午，用户的反馈情况（按人次统计）：
反馈类型：
统计数量
举例备注
平台易用性/友好性
37
操作会新建太多选项卡
功能性缺陷
16
注册什么都不填并直接关闭
可重现BUG
5
更改个人信息并提交有时没有响应二次提交后崩溃
待重现BUG
7
上传PDF文件后黑屏（？
）
越权操作
3
可查看并操作别人的阅读收藏动态
平台效率/反馈时间
23
登录响应时间太长
其他未分类
9
统计信息指代模糊不清
从上表的反馈统计中可以看到，用户反映最多的问题是平台的易用性和平台的效率问题，其中平台的易用性是被吐槽最多的。
平台效率上线之前已经有所预估，但是稍许意外的是登录动作的响应时间也达到了令用户不舒服的程度。
另外，根据用户的反馈，在编辑长心得的时候，系统经常出现停止响应或假死的情况，甚至在用户数很低的条件下，这种情况依然存在，所以系统在经受大数据检验的能力上很欠缺。
性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
在本次测试中，将针对上述的功能进行性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在大量虚拟用户情况下，系统的吞吐能力和响应能力，，以及在预计的数据容量中，系统能够容忍的最大用户数。
本次测试是针对实验室开放平台的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。
1、系统的响应能力：
即在各种负载压力情况下，系统的响应时间，也就是从用户端发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。
2、应用系统的吞吐率：
即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。
3、应用系统的负载能力：
即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
目前实验室的情况为，常驻实验室的人员有30人左右，在上线对外开放之前，平台通过局域网对内开放。
关键点描述（KP）
本次性能测试的关键点，就是查看平台在并发压力下的表现，即：
支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的事务处理能力，并找出系统的性能瓶颈。
性能测试环境
其中具体的硬件和网络环境如下：
服务器设备：
操作系统：
Windows7
网络环境：
WLAN（10M）
数据库：
MySQLcommunity5.6.23
测试场景：
模拟实际使用过程中的场景，实验室的人员的日常访问主要会进行下面几种操作：
站内随便浏览；
读心得；
读文献；
按60%、20%、20%分配上述4个事务，起始分配两个用户，之后每15秒增加两个用户，一直到40个用户并持续10分钟，之后每30秒减少两个用户，直至为零。
另外，设定录制的思考时间是1-5秒之间的任意值。
设定在用户数目小于10的情况下为轻度负载，10~25为中度负载，25人以上为重度负载。
为了考虑用户的体验程度，结合用户体验测试中的反馈，设定轻度负载下响应时间的阈值为2s，中度负载下的响应时间为4.5s，重度负载下的事务响应时间是7s。
测试结果分析：
每秒点击数与吞吐量，用户数与吞吐量
每秒点击数反映了客户端每秒向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的吞吐量也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。
如图显示的是每秒点击数与吞吐量的复合图。
从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能较为及时的接受客户端的请求，并能够返回结果。
对于用户数和吞吐量的关系，初始用户数比较少，相应的吞吐量也会比较低，当用户数增加时，吞吐量会也会相应增加。
当用户数继续增加，但吞吐量却保持平稳时，说明带宽够用。
如下图所示：
如图可以看到，随着用户数的增加，吞吐量基本保持稳步上升的趋势，说明服务器在现有网络带宽条件下基本能处理来自用户的请求。
上述考虑到以后该平台需要对外开放，
针对事务的响应时间的分析
在这里对上述各事务的响应时间进行分析，如下图：
其中，阅读心得的响应时间随用户数量的增加显著增加，而随意浏览和阅读文献的响应时间变化相比较而言却不显著，结合心得的存储分析其原因，是心得的存储结构和对图片等资源的优化程度不够造成的，另外，对心得的显示没有采用“懒加载”等技术也大大增加了响应时间，特别是对于长心得的响应时间。
在另一方面，查看URL各自的响应时间和数据传输量，发现除了心得显示之外，首页的资源的请求数据量是最多的。
查看其页面资源，发现图片、CSS和JS的体积都比较大。
之前用户体验测试中有用户反馈登录等待的时间过长，虽然心得显示的响应时间在所有URL中是最长的，但考虑到其大量的时间在处理文档结构，所以除了改善文档存取速度，精简css、js等资源也是降低用户等待时间的一种方式。
查找系统瓶颈
通常查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈→网络瓶颈→服务器操作系统瓶颈（参数配置）→中间件瓶颈（参数配置，数据库，web服务器等）→应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）。
瓶颈通常是由服务器配置不当和资源不足造成的。
例如，有问题的代码可能会使用几乎所有的计算机处理时间（CPU）并且会在服务器上造成性能瓶颈。
同样，物理内存容量限制和服务器内存管理不当很容易导致服务器瓶颈。
因此，在调查Web或Web应用程序服务性能较低的其他原因前，应先检查服务器的CPU和物理内存。
CPU：
度量ProcessorQueueLength会反映出出处理器瓶颈。
一般而言，队列长度持续大于4，则表示可能出现处理器拥塞。
如图所示，队列的长度最高为53，平均值为4.458，说明队列出现拥塞，处理器是系统的瓶颈。
另外同查看度量%ProcessTime（如图所示），发现随着Vuser的增加，CPU使用率急剧增加，从第5分钟开始，持续维持在100%，甚至在用户数量下降后，也维持了几分钟时间，又证明了CPU是系统性能的瓶颈。
硬盘：
由于服务器使用的是SSD，在这里不考虑硬盘的瓶颈。
内存：
通过查看度量%AvailableMbytes，可以查看可用内存，进而推断内存是否是性能的瓶颈。
系统的可用内存的情况如下图粗线所示：
可以看到，可用内存一直维持在4400M的水平，已知服务器内存容量为819M，所以整个过程中物理内存使用率大约为（8192-4400）/8192×100%=46.29%，如果按物理内存使用率不超过70%来要求，系统的内存使用率是在可接受的范围内的。
安全性测试：
因为本项目在设计初期并没有做这方面考虑，所以相应的问题比较多。
其中比较明显和重要的问题是传送敏感隐私信息的动作如登录使用的是明文传输的HTTP协议。
通过中间人可以轻易获取用户的用户名及密码。
8
另外，在用户体验测试中反映出的越权操作问题也被归于该类。
升级会员 