修订历史记录

目  录

1     概述... 4错误!未定义书签。

1.1         项目概述.... 4

1.2         术语与缩略语... 4

1.3         参考与引用文档.... 4

2     测试情况.... 5

2.1 测试机构和人员... 5

2.2 测试结果.... 5

3     测试统计.... 5

3.1 测试统计表.... 5

3.2 测试统计图.... 6

4     测试评价.... 7

4.1 测试改进建议.... 8

4.2 系统存在的风险.... 8

4.3 测试总结.... 8

1        概述

1.1      项目概述

  项目  名称：Channel项目

  任务提出者：XX科技有限公司

  开  发  者：XX科技有限公司开发部

  用      户：广告渠道商

  项目  背景：Channel项目为Yaphon广告渠道商管理系统，包括前台广告的展示、渠道商的申请、审核、管理以及渠道商对所属客户的管理等一套完善的渠道商管理系统。使用Channel项目，可以实现对广告、渠道商、订单等业务的在线管理。

1.2  术语与缩略语

无

1.2      参考与引用文档

测试参考文档包括：

《Channel项目测试计划》

《Channel项目测试用例》

《渠道代理后台需求（测试版）》

《渠道代理中心需求（测试版）》

《新增渠道流程》

《资源查询流程》

《财务管理流程》

《订单管理流程》

《渠道&渠道申请状态说明》

《订单状态说明》

           其他

2 测试情况

2.1测试机构和人员

   测试机构：北京XX项目部

   负责人：

   测试人员：等12人

2.2测试结果

3. 测试统计

3.1 测试统计表

  表1—测试统计表

3.2 模块统计图

图1—测试结果

图2—问题严重性

    

图3—问题类型

图4—问题状态

4. 测试评价

测试时间：

测试人员：12

实际测试环境：windows2000.

测试活动简述：根据测试用例对内部发布环境进行系统的功能测试，并在TD上提交相应的缺陷，并进行返测和回归测试。对上线的系统进行功能测试，安全性测试，兼容性测试和性能测试。

4.1测试改进建议

1、如果时间允许，在进行用户权限验证时进行细分，在测试中出不少关于权限的问题 ，尤其在对“禁用”、“启用”、“终止合同”等操作上，需要严格按照需求说明，以及操作步骤来实现。

2、邮件系统最好有个发送成功反馈信息，如果是无效邮箱也要有馈信息。

3、用低权限登录后，使用高权限操作，界面显示无此权限。但是不能返回，只有关闭界面。建议应该返回登录界面。

4、排期查询中搜索排名，公司排名，关键词排名都有前三名说法，只要下了三个订单，其排期查询中剩余数就会变为0，建议在查询时与日期结合起来，避免误会。

5、浏览器兼容性测试时发现管理中心系统的日期控件在Opera，NetScape，FireFox浏览器上显示时出现日期错误的问题，建议公司关注此问题。

4.2系统存在的风险

1、 密码的安全级别没有限制

2、   没有强制用户每隔几月或多长时间改变一次密码

3、   没有强制用户不同级别使用不同的密码

4、   验证方法的错误拒绝率有点不可接受，后台用户用正确的用户名和密码登录时，很多时候都登录不上，需要关掉所有IE，然后清除Cookie或重新启动计算机才可以登录正确。

5、   对输入错误密码的次数没有限制。

6、   性能测试是在外网进行测试的。没有对服务器进行测试，因此测试结果与实际存在一些的差距，建议公司对内部服务器进行性能测试，以确认性能方面是否符合实际的标准。

7、   在线测试从20##-4-12日开始到20##-4-27日结束，时间较短。对广告发布流程测试不充分，没有对跨月，跨年的排期进行测试，建议公司对此问题进行测试

4.3测试总结

系统通过功能测试，功能符合需求规格说明书的规定，可以进入后期测试阶段，且测试重点应该放在安全性测试方面。

 

第二篇：项目测试风险总结

随着项目规模的扩大，项目的复杂性也逐渐增加，在项目中做好风险控制也变得更加重要，以下是一些个人感觉会对测试产生较大影响的风险总结,希望对大家有所帮助：

* 测试执行前：

1、明确项目测试涉及哪些应用以及是否可测。有些应用项目本身未做改动可能未部署项目环境，但是测试中可能需要这些应用才能测试相关功能。应尽早提醒部署类此应用，以免影响项目环境测试执行。

2、明确外部资源是否到位。项目中可能涉及一些第三方资源，比如搜索引擎，UI，测试前需要明确对应的开发接口人，以免测试过程中发现问题无法及时解决。

3、涉及数据迁移及时间程序同步等，需要明确时间程序或数据导入的时间。部分项目可能会较大的依赖于数据或者时间程序，前期需要沟通明确此类问题，为测试执行做好充分的准备。 * 测试执行中：

1、需求变更要做好充分的影响分析。测试过程中发生的需求变更往往容易被忽略，明确变更的影响范围以及提交时间，必要的情况下，需要调整测试计划。

2、注意项目环境打分支的日期是否过早。部分项目可能开发介入较早，分支也较早，这样可能会导致项目环境代码与主干的差异性太大，合并主干后，问题可能很多。这种情况下，最好能再合并一次代码，以便尽早发现问题。

3、注意当前存在的其他项目及日常的相互影响。项目测试过程中，其他项目对底层应用或数据进行改动，可能会造成本项目测试无法进行。最好能提前判断当前并行的其他项目是否会对本项目产生影响，做好预防工作。

4、新需求的项目，提前通知需求提出人员进行试用。存在一些项目，到临近发布的时期，需求方发现与预期不符需要改动。这种情况下对测试会产生重大影响。所以对于新需求的项目，在功能稳定后，尽量通知需求人员对功能进行试用。

* 预发布阶段：

1、制定预发布测试方案。预发布时间通常较短，部分功能可能无法进行预发布测试，或需要提前准备数据，尽早制定预发布测试方案以保证预发布测试顺利进行。

2、注意预发布环境与线上环境的一致性。一些项目依赖搜索，或hfs等重要应用，需要判断这些应用是否也在升级。如果正好同时在对这些应用进行升级，可能会在发布阶段引入一些问题。

* 发布阶段：

发布后，第一时间验证淘宝主流程。对于涉及应用较多的项目，需要验证相关产品线主要流程。并注意是否存在部分机器访问不成功，并记录机器名。以保证发布过程引入的问题能及时得到解决。

以上是个人项目过程中遇到过的一些问题。风险控制还有很多很多，希望这些能对后面的项目起到参考作用，随着我们经验总结越来越多，我们的项目相信也会越做越好～