测试部分:
1.在测试过程中总共发现了多少Bug?每个类别的Bug分别为多少个?
a.修复的bug
b.不能重现的bug
c.这个产品就是这样设计的,不是bug;
d.没有能力修复,将来也不打算修复;
e.这个bug的确应该修复,但是没有时间在这个版本修复,延迟到下一个版本修复。
在功能性测试中
看板任务消失:点击一个任务,在出现特定情况时(任务大小超过看板宽度,并再次点击其他),任务消失。不可重现,属于E类;
看板排序:点击一个任务,任务自动排序到本栏中最下方。可重现,属于C类。
BUG类别 | A | B | C | D | E |
---|---|---|---|---|---|
BUG数/个 | 0 | 0 | 1 | 0 | 1 |
2.场景测试(scenario testing),包括以下内容:
a.你预期不同的用户会怎样使用你的软件?
b.他们有什么需求和目标?
c.你的软件提供的功能怎么组合起来满足他们的需要?
在《Gugua需求文档中》2.3章用户类和特征中指出
我们的软件实现了任务事项的优先级分类,在繁杂的事务中能及时提醒用户当前最重要的事项;完善事务的划分以及提醒功能;将完成的事务保存以供日后翻查审计;在能够满足大多数人群管理事务、提升效率需求下,增加了其他功能的实现,如轻量级的团队合作模块,能够实现用户更多的目标。
3.你们在什么样的平台、硬件配置、浏览器类型等条件上对你们的软件进行测试?——测试矩阵(test matrix)
操作系统 | 处理器 | 主板 | 内存 | 硬盘 | 浏览器 | 数据库 | Windows | Linux | |
---|---|---|---|---|---|---|---|---|---|
客户端 | Windows 10 专业版 64位 | 英特尔 第四代酷睿 i5-4258U 双核 | 联想 Lancer 4A2 | 三星 DDR3L 1600MHz / 金士顿 DDR3L 1600MHz | 浦科特 PX-128M7VC(128G固态硬盘) | MySQL5.5.53 | √ | √ |
4.非功能测试
a.性能指标(响应时间和吞吐量,需要给出截图和测试实例以及结果)
b.系统资源监控(CPU、内存占用情况,需要给出截图和测试实例以及结果)
c.压力测试(不同并发用户数,需要给出截图和测试实例以及结果)
d.疲劳度测试(测试服务器持续运行的能力,需要给出截图和测试实例以及结果)
e.安全测试(从三个角度来看,即保密性、可用性、完整性。需要给出截图和测试实例以及结果)
序号 | 所完成的测试 | 系统所期望的性能指标 | 实际测试结果 | 差别分析 | 性能问题及其改进建议 |
---|---|---|---|---|---|
1 | 性能测试 | 服务器响应时间不大于3s | 平均响应时间不大于3s | 多用户同时并发,单个的响应时间无法准确反映真实情况,使用平均响应时间为准 | 由于测试工具的局限性,目前只能并发50个用户。服务器性能的话还是要用钱说话¥_¥ |
2 | 系统资源监控 | CPU占用少,内存占用少 | CPU占用仅为2.4%,内存仅为20M左右 | 目前项目处于Alpha阶段,功能实现较少,其他设计还不完全,自然体积小。 | 软件本身的体积取决于设计和代码的质量 |
3 | 压力测试 | 多用户并发 | 50以内用户并发效果良好 | 功能实现较为良好,服务器性能良好 | 压力测试本是性能测试一部分,同理 |
4 | 疲劳度测试 | 服务器长时间运行并且状态良好 | 该服务器已经处于长期的工作当中,且性能良好 | 无差别 | 啊又是服务器的问题,一是产品本身的质量,再是维护方面 |
5 | 安全测试 | 用户数据以及安全漏洞 | 数据保密、可用以及完整不被篡改 | 基本实现安全性 | 通过数据传输中的加密算法,保证保密性;用户数据同步在服务器数据库中,以保证可用性;数据库同样需要加密保护,以防用户数据被盗取、篡改。 |
性能测试
响应时间
吞吐量
系统资源监控
压力测试
分别设置单个用户、30个用户和50个用户并发(由于测试软件的原因,无法使用50个以上并发用户)。
疲劳度测试
针对需求中的性能测试,进行了疲劳度测试,使用LoadRunner设置持续访问服务器24小时,用以测试服务器持续运行能力,结果基本满足要求。
安全性测试
用户登录和注册时输入的密码在服务器端经过加密算法存入数据库中或者进行匹配,较为安全。
5.你认为你们团队的软件在什么条件下,就可以认定其已经足够好,可以发布Alpha版本?——出口条件(exit criteria)
我们团队的项目的出口条件当然是在实现基本功能,无明显且严重的BUG情况下,可以发布Alpha版本。