快易需求文档编辑系统——测试心得
一、项目背景
软件需求文档是软件开发与维护的重要基础,本项目希望通过建立一个专业的需求文档编辑系统,为软件开发人员提供一个便捷的协作文档编写工具,推动需求文档编写的规范与文档重用工作。同时,也为广大软件公司提供一个随时可以访问的平台,推广快易文档编写系统。
二、测试对象
快易需求文档编辑系统致力于帮助需求分析工程师快速编写需求文档,提高工作效率和文档质量。类比代码重用将需求文档中可重用,模式化的部分提取封装起来,形成“构件”,也是该子系统的核心。
三、测试过程
与需求文档中的功能点覆盖率
编号 | 需求点 | 通过率 |
1 | 创建文档 | 通过 |
2 | 创建构件 | 通过 |
3 | 编辑构件 | 通过 |
4 | 发布&审核构件 | 通过 |
5 | 撤回发布 | 通过 |
6 | 下架构件 | 通过 |
7 | 更新共享构件 | 通过 |
8 | 收藏构件 | 通过 |
9 | 引用构件 | 通过 |
10 | 删除构件 | 通过 |
11 | 构件评分 | 通过 |
12 | 新建二期新增构件类型 | 通过 |
13 | 编辑新增构件 | 通过 |
14 | 封装构件 | 通过 |
测试中遇到的bug
bug列表 | 描述 |
部署至服务器后收藏功能没有反应 | 重新修改收藏功能 |
在收藏之后对积分的处理没有提示语 | 开发人员整合项目时误删除提示信息 |
保存按键在新增的构件没有添加 | 考虑不周导致该功能部分遗漏 |
对于重复评价问题没有解决 | 用户个人可以重复评价某构件 |
四、心得总结
由于我们项目组在前期开发的时候每完成一部分功能之后就会将其整合起来,并对已实现的功能进行简单初步的测试,保证功能可以执行,流程可以实现;到中期项目验收之后我们集中对Alpha版本的数据进行了一次测试,确保一期版本的功能用各类数据完整实现。
因此,到了开发全部完成之后整体测试系统的性能的时候遇到的bug不算很多,就是一些简单的问题,例如在开发过程中考虑不周出现的保存按钮部分构件遗漏,或者在开发完成之后整合代码的时候导致功能丢失。整体而言测试过程及修复bug的过程都很顺利,对我最大的感受就是在开发完成一部分功能之后如果有一定的休息空余时间就可以对其进行测试,尤其是一些和后期开发功能依赖性不强的功能点,因为这样可以节省后期整体项目的测试时间,同时也可以减少一些bug,不然最后bug太多对开发人员是一种极大的折磨。