一、引言
1.1 编写目的
本文是描述****集成测试的大纲文章,主要描述如何进行集成测试活动?如何控制集成测试活动?集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人,集成部门经理,集成测试设计师。
1.2 背景
项目名称:***集成测试
项目相关对象:******************
1.3 定义
**********:********************
1.4 参考资料
《*********》
二、测试项目
本测试主要为***系统的集成测试,目前***的版本为2.0,测试是***的最终集成测试,是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上
三、被测特性
3.1 操作性测试
主要测试操作是否正确,有无误差?分为两部分:
3.1.1 返回测试
由主界面逐级进入最终界面,按EXIT键逐级返回,检查返回时候屏幕聚焦是否正确
比如:
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按EXIT键返回,检查当前聚焦是否为“频道搜索”
5. 按EXIT键返回,检查当前聚焦是否为“系统设置”
3.1.2 进入测试
由主界面逐级进入最终界面,按MENU键返回主界面,再次进入,检查是否聚焦正确
比如:
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按MENU键返回主界面
5. 当前聚焦是否为“系统设置”
6. 进入“系统设置”,当前聚焦是否为“频道搜索”
3.2 功能测试
测试机顶盒中每个应用的功能是否正确
3.3 性能测试
3.3.1 疲劳性测试
测试连续开机1个月不关机器,每3天去运行一次应用。看系统的稳定性
3.3.2 大容量数据测试
前段***数据库表中含有大量数据,测试***功能
四、不被测特性
五、测试方法
1. 书写测试计划
2. 审核测试计划,未通过返回第一步
3. 书写测试用例;
4. 审核测试用例,未通过返回第三步
5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上;(测试报告必须覆盖所有测试用例)
6. 测试过程中发现bug,将bug填写在bugzilla上发给集成部经理;(bug状态NEW)
7. 集成部经理接到bugzilla发过来的bug
7.1 对于明显的并且可以立刻解决的bug,将bug发给开发人员;(bug状态ASSIGNED);
7.2 对于不是bug的提交,集成部经理通知测试设计人员和测试人员,对相应文档进行修改; (bug状态RESOLVED,决定设置为INVALID);
7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改;(bug状态RESOLVED,决定设置为REMIND)
8. 开发人员接到发过来的bug立刻修改;(bug状态RESOLVED,决定设置为FIXED)
9. 测试人员接到bugzilla发过来的错误更改信息,应该逐项复测,填写新的测试报告(测试报告必须覆盖上一次中所有REOPENED的测试用例);
10. 如果复测有问题返回第六步(bug状态REOPENED)
11. 否则关闭这项BUG(bug状态CLOSED)
12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务;
13. 本轮测试中发现的错误有98%经过修改并且通过再次测试(即bug状态CLOSED),返回第五步进行新的一轮测试;
14. 测试任务结束后书写测试总结报告;
15. 正规测试结束进入非正规测试,首先是ALPHA测试,请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员,测试人员以正规流程处理bug事件;
16. 然后是BETA测试,请用户代表进行测试。发现bug通知测试人员,测试人员以正规流程处理bug事件。
几点说明:
* 测试回归计划为三次;
* 测试用例应该写得比较详尽,步骤一定要标明清楚(应该包括:编号,测试描述,前置条件,测试步骤以及测试希望结果);
* 对于测试人员觉得应该进行的测试项目,测试人员应该报告测试设计人员,完善和健全测试用例;
* 测试报告与测试用例分开,测试报告标明测试用例序号以及是否通过Y/N;
* 对于集成部经理无法决定的上交项目负责人决定;
* 性能测试中的疲劳性测试可以结合在功能测试部分,即测试期间不关闭机器;
* 性能测试中的大容量数据测试放在测试后部分轮次(第二步,只需要进行一次)