测试用例和评审.pptVIP

测试用例的编写和评审;概要;测试用例;什么是测试用例？;测试用例的设计方法;用例分类

用例编写原那么

用例命名标准;用例分类;用例编写原那么;用例命名标准;评审;为什么要评审？;评审的概念;主要文档评审;各种评审的形式;人：

同行评审〔PeerReview〕：也称作“同级评审”或“对等审查”等。由软件开发文档的编写者的同事对软件文档进行系统的检查，以发现错误和检查修改正的区域，并提供改进的建议。

独立评审：安排一些人对成果进行个别检查，以单独完成对成果的评审，评审人员相互之间暂时不进行讨论。

组内评审：工程团队内部组织的对成果的评审。

相关工程成员评审：相关工程成员可以分为横向和纵向两类，所谓横向，指与本工程同时进行的工程的成员；所谓纵向，指历史上已经开发与这个系统有关的软件系统工程的成员。在必要时，也可以请规划中即将建设的软件工程的成员参加。主要是在软件的技术和设计风格上进行统一的规划。以充分利用软件复用技术来提高效率和易维护性，充分考虑各系统之间的接口、兼容性和界面一致性。;对象:

整体评审：在文档整体完成后，对需求或设计文档的整体进行评审。当文档比较大而难以进行整体评审时，可分而治之，分屡次进行“局部评审”。

物理局部评审：不同评审人员对某一成果的某些物理局部内容进行评审，如按照文档章节、功能划分或模块划分等。

逻辑局部评审：分阶段检查某一成果是否具有某个所期望的特性，或不同评审人员对某一成果的某些特性〔如可读性或可维护性〕要求进行评审。

迭代评审：迭代开发模式中分阶段对局部内容进行评审，每一局部评审通过后即可作为下一阶段相关局部工作的根底，每一次迭代都包括需求、分析、设计、实现和测试活动。同时每次迭代都建立在前一次迭代工作的根底上，每次迭代都会生成更加接近最终产品的可执行版本。

回归评审：原来的评审发现问题需要整改并再次进行的评审，以检查问题是否已经得到修改，同时检查是否出现新的问题。;评审活动的角色分工;角色分类与原那么;根本角色职责;需求分析阶段的评审;概要设计阶段的评审;详细设计阶段的评审;编码阶段的评审;集成测试阶段的评审;确认测试的评审;评审中常见的问题;结束