• 功能用例的命名规范 • 集成用例的命名规范
用例命名规范
为什么要评审？ 评审的概念 各阶段的评审内容 主要文档的评审 评审的形式 评审活动的分工
评审
为什么要评审？
• 更快的了解需求与设计。 • 尽早发现潜在的问题和纠正缺陷。 • 通过讨论澄清一些模糊的认识。 • 为软件开发寻找最佳的解决方案。
计内容的条文要进行评审； • 8、评审软件质量保证工作和软件配置管理工作的执行情况。这属于管理评审，
但在概要设计评审时要进行此项工作。 • 9、评审软件高层设计是否实现了软件需求规格说明的要求； • 10、评审设计方案与主要算法的可行性和先进性； • 11、评审接口设计方案的性能和运行环境的恰当性。
详细设计阶段的评审
• 1、软件单元功能与概要设计要求之间的可追溯性，集成的单元 之间的信息流和控制流的可追踪性；
• 2、数据加工处理与数据结构的一致性； • 3、并发性信息处理的正确性； • 4、数据库设计中，数据存取权限控制技术应用的合理性，数据
保密技术设计的适当性，数据安全性技术设计的完善性，数据 字典和数据编码规则与规定格式的一致性； • 5、评审可靠性和安全性技术应用的程度及正确性； • 6、管理评审，主要评审软件质量保证和软件配置管理工作的执 行情况。
概要设计阶段的评审
• 1、总体结构层次设计的合适性，模块的独立性； • 2、软件概要设计说明、软件需求规格说明和软件接口说明要求的一致性； • 3、控制流描述的正确性； • 4、主要算法的合适性和先进性； • 5、数据库设计说明的完备性、一致性和易理解性； • 6、可靠性、安全性设计的恰当性； • 7、对软件需求评审以后修改的软件需求规格说明和接口说明中涉及到概要设
划和风险计划。 • 需求：业务、系统和软件。 • 设计：概念、架构、概要和详细设计。 • 代码走查、单元、功能和系统测试用例。 • 验收报告和总结报告。
• 1．人 • 2．对象
各种评审的形式
• 人：
– 同行评审（Peer Review）：也称作 “同级评审”或“对等审查”等。由 软件开发文档的编写者的同事对软件文档进行系统的检查，以发现 错误和检查修改过的区域，并提供改进的建议。
结束

则应多途径审查从被修改阶段开始到软件实现阶段为止所 有改动部分的正确性。
集成测试阶段的评审
• 1、软件集成测试的恰当性； • 2、测试用例集的完整性和恰当性； • 3、测试结果和测试用例集的一致性； • 4、测试环境和正式运行环境的相容性； • 5、测试分析过程和结论的正确性； • 6、管理评审：主要评审软件质量保证工作和配置管理工
• 评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材 料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和 记录问题。
• 文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进 行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
• 记录人员：评审会议中记录评审人员提出的问题及相关讨论。
用例编写原则
① 功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个 功能点或一个流程。
② 测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。 ③ 测试用例的步骤描述要简单、清晰，一步就是一步。 ④ 测试用例的数据要明确，特别是输入数据和期望结果。 ⑤ 测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例
编码阶段的评审
• 1、程序代码与详细设计的一致性； • 2、代码格式与规定要求的一致性； • 3、程序代码调试结果的正确性； • 4、静态分析过程的正确性和合理性； • 5、单元测试用例的充分性和合理性； • 6、单元测试数据的产生和测试过程的正确性、合理性和
完整性； • 7、软件实现过程中若修改了软件详细设计或概要设计，
评审的概念
广义的评审概念包括： 走查（Walkthrough） 检查（Inspection） 评审（Review） 评估（Estimate）
以及结对编程、同级桌查、轮查及临时评审等等，有时会出 现同一个英语词汇翻译的不同。
主要文档评审
• 需求报告、可行性报告、立项报告和解决方案。 • 解决方案。 • 计划：项目计划、质量管理计划、配置管理计划、测试计
评审中常见的问题
• 准备问题
• 被评审人员准备不足 • 评审人员准备不足 • 时间估计不足
人员问题
• 人员搭配不合理 • 人员能力不达标 • 评审人员对必要性认识不足
会议效果问题
• 完全靠会议讨论来解决问题 • 没有深入考察要评审的文档发现潜在的问题 • 对文档中某些术语概念的争执 评审内容遗漏
• 软件工程人员：掌握软件工程、需求和设计建模方法，能够对文档中 表达方法的正确性进行判断。
• 相关系统开发人员：在后面提到的前后左右相关的项目成员。
基本角色职责
• 评审组长：制定评审计划、确定或制定各项评审准则、组织必要的资 源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要 时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错 误的改正。
– 迭代评审：迭代开发模式中分阶段对部分内容进行评审，每 一部分评审通过后即可作为下一阶段相关部分工作的基础， 每一次迭代都包括需求、分析、设计、实现和测试活动。同 时每次迭代都建立在前一次迭代工作的基础上，每次迭代都 会生成更加接近最终产品的可执行版本。
– 回归评审：原来的评审发现问题需要整改并再次进行的评审， 以检查问题是否已经得到修改，同时检查是否出现新的问题。
作的执行情况
确认测试的评审
• 1、确认测试计划安排的合理性； • 2、确认测试环境选择的合适性； • 3、确认测试计划中功能测试的合理性、齐全性； • 4、确认测试计划中性能测试的合理性、齐全性； • 5、确认测试用例、测试数据、测试方案的合理性、正确性和全面性； • 6、确认测试结果分析的合适性； • 7、确认测试用例集和确认测试结果的一致性； • 8、确认测试环境和运行环境的相容性； • 9、确认测试分析过程和结论的正确性。
• 对象:
– 整体评审：在文档整体完成后，对需求或设计文档的整体进 行评审。当文档比较大而难以进行整体评审时，可分而治之， 分多次进行“部分评审”。
– 物理部分评审：不同评审人员对某一成果的某些物理部分内 容进行评审，如按照文档章节、功能划分或模块划分等。
– 逻辑部分评审：分阶段检查某一成果是否具有某个所期望的 特性，或不同评审人员对某一成果的某些特性（如可读性或 可维护性）要求进行评审。
– 独立评审：安排一些人对成果进行个别检查，以单独完成对成果的 评审，评审人员相互之间暂时不进行讨论。
– 组内评审：项目团队内部组织的对成果的评审。
– 相关项目成员评审：相关项目成员可以分为横向和纵向两类，所谓 横向，指与本项目同时进行的项目的成员；所谓纵向，指历史上已 经开发与这个系统有关的软件系统项目的成员。在必要时，也可以 请规划中即将建设的软件项目的成员参加。主要是在软件的技术和 设计风格上进行统一的规划。以充分利用软件复用技术来提高效率 和易维护性，充分考虑各系统之间的接口、兼容性和界面一致性。
需求分析阶段的评审
• 1)任务和需求分析：根据软件任务书的要求，对项目开发计划、 软件需求规格说明进行评审，其内容包括项目组人员、进度、 软件功能、环境需求等；
• 2)可行性分析：其内容包括技术、人员要求、风险分析等； • 3)质量保证：根据软件质量保证工作的计划，检查是否已把质
量保证列为软件需求分析阶段的一项重要内容，分析有关计划 的恰当性； • 4)配置管理：分析软件配置项基线规定的恰当性及软件配置项 基线设置和管理计划的恰当性和完整性； • 5)管理：评审软件质量保证工作和配置管理工作的合适性。
不存在包含关系。 ⑥ 描述要清晰、包括特定的场合、对象和术语，没有含糊的概念和一
般性的描述。 ⑦ 测试用例中需要有充分的异常测试数据，考虑大数据量测试时的数
据准备。 ⑧ 测试用例应确保覆盖详细设计中的所有功能。 ⑨ 对于无输入的操作,应该详细描述其具体的操作步骤和结果.。 ⑩ 测试用例需要保障数据的正确性和操作的正确性。
测试用例的编写和评审
• 测试用例的编写要点 • 评审过程中的评审点
概要
什么是测试用例 测试用例
测试用例的设计方法 编写测试用例
什么是测试用例？
• 测试用例是执行测试工作的依据； • 确保测试的系统性和全面性。
测试用例的设计方法
• 黑盒测试的测试用例设计的5种方法：
– 等价类划分 – 边界值分析 – 错误推测法 – 因果图 – 功能图
编写测试用例
用例分类 用例编写原则 用例命名规范
• 业务流程用例 • 单功能用例 • 集成测试用例
用例分类
是为了测试软件是 否的及的善单某能测数集为发之能业对控而功一编试据成了组间完务异制设能个写功、测测提模成处常处计用单，能异试试交块用理业理的例独是对常用不接户 流 务 是 用 针 的 为 正 数 例 同 程 口正 程 流 否 例 对 功 了 常 据 是 开 序 及常 ， 程 完 。 、数空据数传据输的处处 理理 是 控否制正存确储而是设否 计正 的 确测而试设用计例的。用例 。
• 角色分类与原则 • 基本角色职责
评审活动的角色分工
角色分类与原则
• 项目管理人员：具备项目管理知识与经验，主要是为了检查需求或设 计对项目管理的可能影响，现行项目管理工作与这些文档中所提要求 的符合性。
• 质量管理人员：掌握过程与文档相关规范，这些规范可以是行业内部 通用的，也可以是企业内部制定的。