测试计划编写

测试计划的生命周期：

计划初期：收集信息，理解需求，了解技术与难点，人员交流，达成一致。

计划起草：确定测试策略，选择测试方法，完成测试计划框架。

内部审查：测试小组/部门审查　　

计划讨论与修改：召开有需求分析、设计、开发等人员的计划讨论会议，测试计划作者详细介绍设计思想、策略并听取大家意见讨论交流。

测试计划的多方审查：项目中的每个人都应该参与审查，每个审查者根据其经验及专长发现计划的问题或针对测试策略或方法提出建议。

测试计划的定稿和批准：在讨论审查的基础上综合各方意见完成计划书，上报经理得到批准方可执行。

计划执行跟踪和修改：在实际执行过程中由于需求环境等因素发生变化，计划需进行调整，满足测试需要。

测试目标：测试需求转换为总体测试目标。最低目标，基本目标，最高目标。

需求分析：1、明确测试范围，了解那些功能点要测试哪些不需要。2、优先级的判断。3、要完成哪些测试任务才能确保目标实现。

 

1.测试范围：产品的具体需求，功能的具有属性（web，移动端）

2.测试策略：对不同的业务需求所需要使用的测试方法，测试类型，测试场景，测试方法，测试环境，测试工具

3.资源安排：人力资源，时间资源

4.进度安排：测试开始时间，整个项目的测试时间，到达一个里程碑所需要的时间，结束各种测试类型分别需要多长时间，与上线时间，开发时间想呼应

5.发布标准：质量达到什么程度可发布上线，测试怎么才算结束

6.风险预防：使用测试策略可能出现的风险，测试过程中可能出现的风险（人员的变动，新需求的加入，技术的难度等）需要提前进行考虑与准备，并在测试计划中体现出来

 

 

1引言

1.1、编写目的

根据更多大厅新迭代版本（1.0.3）项目需求文档，提炼测试功能点、制定测试计划、评估测试风险，预估编写测试用例、执行功能测试和回归测试的工作量，进行工作安排。

 

1.2、阅读人员

敏捷教练、产品、开发、测试

 

1.3、参考资料

更多大厅聊天系统设计文档

聊天系统功能分析uml图

 

2测试范围

功能模块：

入口、聊天界面，聊天规则，玩家交流

数据：后台数据记录，日志显示

各个应用接入聊天系统的兼容性

聊天系统的性能

 

3测试策略

对需求的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和性能测试方案。

 

3.1功能测试策略

具体见聊天系统测试用例

 

3.2系统兼容性测试

聊天系统为接入功能，分别接入各个应用大厅，也同时分布在ios系统与android，兼容性测试需要做以下方面：

1、在捕鱼大厅，升级大厅，打地鼠应用大厅进行兼容性测试

2、在ios与android系统应用中进行兼容性测试

3、市场主流的机型屏幕适配，分辨率覆盖800*480、1280*720、960*540、1920*1080

 

3.3性能测试

1、聊天模块，大量用户同时在线聊天，服务器负载情况，页面响应速度

2、聊天记录存储，大量聊天记录后台存储，数据传输压力，系统压力

 

4测试资源

4.1人力资源

由于开发模式为敏捷开发，项目组是阿米巴模式，一人负责一版本，测试人员xxx。

 

4.2测试环境

1、服务器环境：内网服务器、线上服务器预发布环境、线上服务器

2、终端环境：pc端w10系统，手机型号vivo x20，内存4g-64g，android8.1.0

3、网络环境：公司办公网络环境，可用fiddler模拟弱网环境测试

4.3测试工具

弱网测试工具：fiddler

Bug管理工具：测试过程中发现缺陷、优化点使用jiar进行管理

测试人员提交缺陷记录时应清晰、准确地描述缺陷发生的条件和步骤，并进行优先级的设置，导致奔溃的缺陷设为critical级别，严重影响程序运行或验证阻碍用户使用的缺陷设为major级别，对用户使用造成一定影响的缺陷设为normal级别，可用性问题或改进意见设为minor级别

critical:极严重      major:重要     normal:一般    minor:轻微   

 

5进度安排

 

任务	时间	执行人员	预期工作量/天
编写测试计划	2020.7.1	xxx	0.4
测试计划review及修改	2020.7.2		0.2
编写测试用例	2020.7.3		1
第一轮功能测试（包含兼容性测试）			2
性能测试			1
第二轮功能测试			2
回归测试			1
预发布测试	内网测试通过		1
线上测试	预发布测试通过		1
测试报告总结	发布后		0.5

 

5.2输出文档

聊天系统测试计划

聊天系统测试报告

 

6发布标准

6.1测试完成标准：

1、没有critical级别的bug，没有影响用户正常使用的bug

2、完成“测试内容”中所述的功能测试、兼容性测试，性能测试，弱网测试

3、未修改的bug不超过3个

 

6.2产品发布标准

1、已按交互文档、需求文档实现内容95%以上（具体产品决定）

2、符合交互稿的交互设计规范、符合视觉要求，已经通过产品评审

3、允许遗留可能会对用户正常使用造成一定影响的normal级缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布

 

7风险说明

1、上述工作量预估中对需求变更进行了一定的风险覆盖，但如果需求变更超出目前预计，则可能导致编写测试用例和执行测试相关工作量增加、测试进度延迟。

2、开发提交测试版本比该计划延迟的风险，发生此种情况时，执行测试的时间应该合理顺延。

3、提交测试版本质量较低的风险，可能导致比该计划更多轮次的回归测试。

4、代码版本管理执行不力的风险，发生版本管理混乱的情况，将只选取一个稳定版本进行测试，不考虑中间版本管理混乱的情况时，将只选取一个稳定版本进行测试，不考虑中间版本的反复测试。一轮测试完成后，在进行下一稳定版本的回归测试。

5、测试依赖的测试服环境，如果服务器端测试环境不稳定，会影响开发提交测试版本和测试进度。