软件计划评审的目的 技术评审的评审目的

正规技术评审目的

（1）发现软件在功能、逻辑、实现上的错误；

（2）验证软件符合它的需求规格；

（3）确认软件符合预先定义的开发规范和标准；

（4）保证软件在统一的模式下进行开发；

（5）便于项目管理。

此外，正规技术评审为新手提供软件分析、设计和实现的培训途经，后备、后续开发人员也可以通过正规技术评审熟悉他人开发的软件。

ISO中，管理评审主要目的是什么？

标准原文：最高管理者应按计划的时间间隔评审组织的质量管理体系，以确保其持续的适宜性、充分性和有效性。评审应包括评价质量管理体系改进的机会和变更的需要，包括质量方针和质量目标。

说白了，就是看看现在运行的整个质量管理体系是不是符合公司的实际情况，是不是有地方需要改进等等。

为什么要在做测试计划前对软件需求进行评审和测试?

需求是不断更新的，当客户加上某点或是删去某点功能，需求变更随时都可能发生。需求的开发是贯穿整个开发过程的，不是做测试计划前就完成。这是一个不断循环迭代的过程。

需求验证活动可以确保需求符合优秀需求称述的特征，并且符合好的需求规格说明的特征。

因此，在部分需求确定下来时，就对这些已经发现的需求进行评审和测试，尽快开发测试用例，就能够及早发现需求方面的缺陷和问题，这样就可以只用较低的费用解决这些问题。

若是在测试结束后，才发现遗漏了某个重要需求；对于某个不是很重要的需求，开发过程中却将其作为重点等等这些问题，那么这个损失就巨大了，需要开发人员重新开发，甚至于重新回到原点，这样将耗费巨大的人力物力。

做好软件测试计划工作的关键是什么?

p 为什么要编写测试计划？

– 领导能够根据测试计划做宏观调控，进行相应资源配置等；

– 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进

行的工作等；

– 便于其他人员了解测试人员的工作内容，进行有关配合工作

p 什么时间开始编写测试计划？

需求分析后，在整个测试工作过程中，不断修改

p 由谁来编写测试计划？

具有丰富经验的项目测试负责人

测试计划的内容

p项目概述

p术语&参考资料

p角色

p环境（软件、硬件、网络）

p测试工具

p甘特图

p里程碑

p交付件

p风险

p三大标准

p测试策略

测试计划的内容－概述

n主要编写系统背景、目的、各种系统概述图

n需求规格说明书中一般都有，复制过来即可

n系统概述图主要是架构图和拓扑图

测试计划的内容－三大标准

n 开始标准

1. 测试环境搭建完成且达到可测要求。

2. 测试相关人员准备就绪。

n 完成标准

1. 测试用例执行覆盖率达到100%

2. 测试需求覆盖率达到100%

3. 系统死锁、系统崩溃、严重错误不能 多于1 个

4. 次要错误不能多于2个

5. 不合理或者别扭，文字错误，微不足道错误不能多于2个

6. 以上错误均不能出现影响用户使用的bug

n 停止标准

1. 测试中出现一级缺陷较多。

2. 测试环境不稳定。

3. 客户需求变更。

测试计划的内容－三大标准(补充)

n 软件系统在进行单元、集成、确认、系统、安装、验

收测试时，发现一级错误（大于等于1）、二级错误

（大于等于2）暂停测试返回开发。

n 软件项目需暂停以进行调整时，测试应随之暂停，并

备份暂停点数据。

n 软件项目在其开发生命周期内出现重大估算，进度偏

差，需暂停或终止时，测试应随之暂停或终止，并备

份暂停或终止点数据。

n 如有新的项目需求，则在原测试计划下做相应的调整。

n 若开发暂停，则相应测试也暂停，并备份暂停点数据。

n 若项目中止，则对已完成的测试工作做测试活动总结。

n 项目再启动时，测试进度重新安排或顺延。

转载请注明出处51数据库 » 软件计划评审的目的 技术评审的评审目的