实验室开放平台测试报告.doc

实验室开放平台测试报告 (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） 本次性能测试的关键点，就是查看平台在并发压力下的表现，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的事务处理能力，并找出系统的性能瓶颈。 性能测试环境 其中具体的硬件和网络环境如下： 服务器设备： 操作系统： Windows 7 网络环境： WLAN（10M） 数据库：MySQL community 5.6.23 测试场景： 模拟实际使用过程中的场景，实验室的人员的日常访问主要会进行下面几种操作： 站内随便浏览； 读心得； 读文献；