当前位置：文档之家 › 测试流程

测试流程

  • 格式：doc
  • 大小：344.50 KB
  • 文档页数：3

测试流程：

项目立项时确定测试人员，在项目计划书中加入由测试人员编写的测试计划书

需求分析完成，测试人员就应该参加需求分析阶段的评审，了解需求，此后开始写测试方案

1、 测试人员参与讨论需求，分析需求点

2、 根据最后确定的需求，测试组出测试计划、测试方案、测试用例（中间如果有需求变更，测试计划、测试方案、测试用例同时进行更新）

3、 测试组提交测试计划、测试方案、测试用例，并评审通过

4、 研发填写测试申请单，提交测试申请给测试组，并抄送运维部署步骤。提交测试申请后，最好研发人员同测试人员沟通相关功能的流程

5、 测试组根据运维提供的测试地址进行测试（只接受运维提供的测试地址）。测试环境尽量同线上环境同步

6、 测试组开始第一轮测试，提交BUG，一轮测试完毕提交测试报告。

第一轮测试阶段，如果出现不能继续进行测试的致命BUG，退回该版本不予测试；WEB类的测试如果非阻碍性BUG超过50个，退回不予测试

7、 等研发人员把上一版本BUG全部修改后，开始回归测试。如果只是部分修改，除非有合理的理由，否则不接受测试

8、 回归测试完毕，提交测试报告。

回归测试阶段，如果重新打开的BUG超过10个，或者引发的新BUG超过20个，退回该版本不予测试。

9、 回归测试轮换最多不能超过5个版本，每个版本测试完都要提交测试报告

10、 功能测试通过后，开始压力测试。

11、 压力测试通过，并经过评审后确定上线时间

1、 必须让测试人员参与讨论需求，分析需求点

2、 根据最后确定的需求，测试组出测试计划、测试方案、测试用例（中间如果有需求变更，测试计划、测试方案、测试用例同时进行更新）

3、 测试组提交测试计划、测试方案、测试用例，并评审通过

4、 研发填写详细测试申请单，提交测试申请给测试组，并抄送运维部署步骤。提交测试申请后，研发人员须同测试人员沟通相关功能的流程

5、 测试组根据运维提供的测试地址进行测试（只接受运维提供的测试地址）。测试环境尽量同线上环境同步，如果因测试环境无法模拟真实环境而产生的问题，质量监控部门不负责任

6、 测试组开始第一轮的版本测试，提交BUG，测试完毕后提交测试报告。每个版本测试完毕都需要提交测试报告（以邮件形式发送到项目组各成员），测试报告内容须包含：测试版本号、BUG数量、BUG严重程度。

第一轮测试阶段，如果主要测试模块，出现不能继续进行测试的致命BUG，退回该版本不予测试；如果非主要测试模块，出现严重BUG，可以保留退回的权利；WEB类的测试如果非阻碍性BUG超过50个，退回不予测试；非WEB类的测试，如超过20个，退回不予测试 7、 等研发人员把上一版本BUG全部修改后（每个版本修改后提交回归测试时，BUG状态不能有新的或重新打开的状态），开始回归测试。每个版本的修改如果只是部分修改，除非有合理的理由，并由部门会议通过，否则不接受测试

8、 回归测试最好不超过5个版本，每个版本测试完测试组都要提交测试报告

9、 功能测试通过后，开始压力测试，并提交测试报告

10、 压力测试通过，当测试产品达到测试质量目标，并经过评审后确定上线时间

看看还有漏的吗 立项需求讨论并确认测试计划、测试方案、测试用例的设计及更新提交测试计划、测试方案、测试用例提交开发退回评审是否通过提交测试申请单开始测试第一轮测试（web类bug>50、阻碍性bug1-2个;非Web类bug>20）回归测试（部分修改的bug、重新打开的bug>10、引新的bug>20）功能测试通过压力测试压力测试通过评审通过后确定上线时间

合集下载

App测试流程及测试点

App测试流程及测试点

APP测试基本流程

1.1流程图

不符

符合

仍然为测试环境

进入正式环境

Fail

Pass

1.2测试周期

测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。

1.3测试资源

测试任务开始前，检查各项测试资源。

--产品功能需求文档；

--产品原型图；

--产品效果图； 发送上线报告 尽快申请到正式后台订单统计测兼容性测试、性能App测试版本送接收版本

UI测试：核对rp/功能测试：核对需回归用户行为统计测--行为统计分析定义文档；

--测试设备（；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）；

--其他。

1.4日报及产品上线报告

1）测试人员每天需对所测项目发送测试日报。

2）测试日报所包含的内容为：

--对当前测试版本质量进行分级；

--对较严重的问题进行例举，提示开发人员优先修改；

--对版本的整体情况进行评估。

3）产品上线前，测试人员发送产品上线报告。

4）上线报告所包含的内容为：

---对当前版本质量进行分级；

---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）；

--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。

2 App测试点

2.1安全测试

2.1.1软件权限

1）扣费风险：包括发送短信、拨打电话、连接网络等 2）隐私泄露风险：包括访问手机信息、访问联系人信息等

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测

4）限制/允许使用手机功能接入互联网

5）限制/允许使用手机发送接受信息功能

6）限制/允许应用程序来注册自动启动应用程序

7）限制或使用本地连接

GSM测试流程

GSM测试流程

测试流程

通过前期测试自己总结的经验和近期测试中出现的问题，在此我对测试流程和测试中需注意的问题在这里做个总结。测试是一个很重要的环节，是最直接了解当前网络情况和客户的感受度。

一、测试前准备工作

1. 测试路线规划：测试前一天晚上应该把第二天即将测试的站点，进行路线规划，也就相当于对明天的一个工作安排和计划，在路线预定好后，第二天早上可以和开车师傅商量（参考意见），最后定一个行车路线。这里测试的基本原则由远到近，先测一天规划站点中远的站点。对于室内站还需要核查是否有室内设计方案。是否激活。

2. 核查设备：在前一天晚上应该核查设备是否完好，齐全，可以连接试一下，是否能连接上。检查手机电池是否都已充电。若发现设备有问题应及时向上级接口人反映，及时进行解决。现在的测试设备有USB接口GPS，蓝牙，测试手机，电脑，车载电源。测试CEL和测试map保持更新。

3. 如果是对于处理问题站点，需在前一天晚上联系好站点涉及到厂家，并提醒厂家带上相关设备，这里可以把要处理的问题站点情况说的严重一点，让厂家引起重视。

二、测试中工作

1. 室内站测试：

（1） 对于室内站测试，首先根据经纬度在MAPINFO软件里打点的位置和设计方案里的站点位置找到测试站点后，用GPS打点，这里需要注意应该多等一会，让GPS稳定后再读取经纬度；另外现在用的GPS读出来的经纬度，格式与工参里面的经纬度不一致，需要进行转换。例如：GPS读出的经纬度为 10401.9314，3039.1629。转换方法为：104+01.9314/60,30+39.1629/60。得出与工参里格式一样的经纬度后，再将转换后的经纬度与工参里面的经纬度进行经纬度误差计算，看是否在经纬度偏差允许范围内。若经纬度偏差不在允许范围内，可以在测试中进行验证，经纬度误差过大导致邻区关系错误，导致无法正常发生切换等一系列的问题。

（2） 连上设备后，因为TEMS软件不是自动默认保存LOG数据，所以一定要记得保存LOG数据，LOG数据命名以该站点的全称命名。根据该站点的室内设计方案里要求覆盖区域进行测试，对于一个闭环的站点要求是：覆盖良好，即室内设计方案里要求覆盖的区域；切换正常，该站点能正常进行出入切换；通话质量良好，该站点无连续的高误码块；能满足正常的通话要求。若在测试中遇见需工程优化的问题应该及时与后台联系，将问题准确的反映给后台，好让后台对问题进行更准确的定位，处理。当通过与后台配合将问题解决之后，应向后台配合人员该问题在后台进行了那些参数的调整，自己可以做个记录。

测试流程的规范

测试流程的规范

测试流程的规范

一个项目启动，测试就要介入进来，和开发一起评估功能的可行性；

根据总体开发进度制定测试进度；

搭建开发测试环境；

测试前期的输入条件（需求文档之类的），测试准备输出内容（测试用例测试报告之类）；

测试用例（要考虑详细，评审时各位开发产品都要参加，把一些不确定情况扼杀在摇篮里）；

根据相关测试计划、测试进度、和实际测试情况确定测试阶段—单元测试，接口测试，冒烟测试，系统测试。（目前我们项目已经接近稳定，请各位开发自己开发完各自的功能后，主动做单元测试，再移交给测试）；

系统测试通过后，开发不要再修改代码；

产品进行验收测试（验收各功能是否符合产品要求，验收通过的，修改就不是提bug了，要建版本来优化了）；

基本要达到开发不要再做修改，回归测试(若有修改报备项目经理,测试经理,写明修改原因,放到SVN作备录并QQ通知本项目所有人员)；

输出文档报告；

只有收到系统测试报告和验收测试报告才可以上线生产。

针对我们项目需要APP、后台及我们运营平台 三方合作，我们与APP接口需要测试，我们与后台接口需要测试，对方修改任何与接口相关东西我们都要评估风险并做对应测试。（对方提供接口文档，暂时手工测试， 以后做自动化）

项目进度：测试要控制进度，对应产品提出的修改，项目经理要先评审并通知到测试，对于修改量大又必须要修改的点，可以去掉其他优先级低的功能或延长版本时间。

生产问题处理过程

生产问题处理流程：有生产问题，先发给产品过滤，优化的提到看板，剩下的问题发给测试，测试验证确实是问题，再发给开发修改验证。紧急的生产问题直接发给测试立即找开发尽量当天解决。

生产问题回顾

每1-2个月进行一次生产问题回顾会议，生产问题要定位到具体的开发测试并由各位写明出现问题的原因。

App测试流程及测试点 2

App测试流程及测试点 2

APP测试基本流程

1.1流程图

不符

符合

仍然为测试环境

进入正式环境

Fail

Pass

1.2测试周期

测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。

1.3测试资源

测试任务开始前，检查各项测试资源。

--产品功能需求文档；

--产品原型图；

--产品效果图；

--行为统计分析定义文档；

--测试设备（；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）；

--其他。

1.4日报及产品上线报告

1）测试人员每天需对所测项目发送测试日报。

2）测试日报所包含的内容为：

--对当前测试版本质量进行分级；

--对较严重的问题进行例举，提示开发人员优先修改；

--对版本的整体情况进行评估。

3）产品上线前，测试人员发送产品上线报告。

4）上线报告所包含的内容为：

---对当前版本质量进行分级；

---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）；

--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。

2 App测试点

2.1安全测试

2.1.1软件权限

1）扣费风险：包括发送短信、拨打电话、连接网络等

2）隐私泄露风险：包括访问手机信息、访问联系人信息等

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测

4）限制/允许使用手机功能接入互联网

5）限制/允许使用手机发送接受信息功能

6）限制/允许应用程序来注册自动启动应用程序

7）限制或使用本地连接

8）限制/允许使用手机拍照或录音

9）限制/允许使用手机读取用户数据

10) 限制/允许使用手机写人用户数据

11) 检测App的用户授权级别、数据泄漏、非法授权访问等