测试用例和评审..ppt

* 业务流程用例:此类用例要求覆盖到用户所有可能的业务流程，并且需要尽可能多的设计一些实际中因为误操作或不熟悉业务而出现的异常的业务流程。梳理出流程后，为每个流程编写一个测试用例。一个业务的所有流程构成该业务的流程测试用例文档。 单功能用例：根据等价类划分法、边界值分析法、错误推测法等方法确认出测试数据，进而设计出相对完备的测试用例的过程。此类用例的测试数据要求覆盖正常数据范围、异常数据范围、及空数据；每个单独的功能都要编写一个测试用例。一个页面所有功能构成一个单独的功能测试用例文档。 集成测试用例：主要用来测试维护数据的模块对被主功能模块使用的数据的维护控制是否正确，同时测试主功能模块对基础模块准备的数据的调用处理是否正确。此类用例要求覆盖所有的调用接口，及所有的基础数据状态。每个需要集成测试的功能单独构成一个集成测试用例文档。 * 否则我们的测试用例会比较混乱，降低了可读性。 比如：第一步，用户登陆；第二步，用户点击“用户信息”；第三步，用户修改姓名为“张三”；第四步，用户点击保存。这有利于提高用例的可操作性。 比如，测试准备数据：用户：张三，李四，王二。在排序后用例的预期结果为：李四，王二，张三。这样，用例在执行时，很清晰，有很高的可操作性，执行者对于执行结果是否正确也非常清楚。 应尽量避免不确定的用词，如：如果、若、否则、大概、可能等。 单功能用例要覆盖所有数据操作处理的功能点；流程用例要尽可能的覆盖程序的各种路径,考虑存在跨年、跨月的数据，兼顾各种业务变化的可能。 首先保证测试用例的数据正确,其次预期的输出结果应该与测试数据发生的业务吻合。操作的预期结果应该与程序发生的结果吻合。 * * Most scientists regarded the new streamlined peer-review process as ‘quite an improvement’ * 在团队开发中，充分的沟通是非常有必要的，沟通的方式之一就是通过文档。不论评审的效果如何，发现多少问题都可以让相关人员了解需求与设计。而通过相互之间的讨论，澄清一些模糊的认识，进一步理解文档的含义。评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以充分利用团队成员的智慧，为软件开发寻找最佳的解决方案。 评审的过程不仅是为了发现问题，而且为了便于跟踪及改正，还应当对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。 * 走查（Walkthrough）：快速扫读。 检查（Inspection）：按照CheckList检查错误，也称为“正规检视”。 评审（Review）：正式的研讨会。 评估（Estimate）：提早发现可能存在的问题或风险并作出规避的动作。 评审是由项目阶段成果的作者以外的其他人来检查工作成果，发现问题，提出意见和建议，以达到改进质量的目的。本文以下所说的评审为“广义评审”指软件项目中评审的总体活动，而不具体考虑如何进行这些评审。 * * 企业内评审：也可以称为“项目组外评审”，是企业内部抽调必要的力量进行组织的，有条件时也可请用户参与。相关项目成员评审是企业内评审的一种特例。 邀请专家评审：在特殊情况下或为了特殊的目的，管理层或用户邀请专家对阶段成果进行评审。这些专家可以是软件技术方面的专家，也可以是与客户业务密切相关的行业业务专家，如国家某个行业信息规划人员和行业标准制定人员等。 用户评审：以用户为主的评审，一般是把文档交给用户检查，或以用户为首组织的评审会议。一般情况下，每份需求文档都要经过数次的用户评审，尽可能地得到最终的确认。而设计文档则视情况而定，一般较少进行用户评审。 第三方评审：用户委托第三方机构进行评审，如监理机构、检测机构和专家验收组等对需求设计文档或其他工作成果进行评审。 * 对象完整性而论，有以下几类评审形式。 * * 不是每种角色都有一个人，而是一个人可以兼多个角色。评审组成员的构成也不是一定都需要里面的所有角色，具体项目要具体考虑，选择其中必要的角色进行搭配。 * 需求与设计评审需要的角色首先要有评审组长，即这个项目的整个评审工作的组织者，需要有管理、评审及会议主持等工作经验。其他除了文档的作者及记录人员之外，主要的角色就是评审人员，这一角色可以由具有以下不同角度知识技能经验的人员构成。 * 评审的问题很大一部分出现在准备上，这不仅仅是说某个项目的评审准备，甚至可能是整个组织内部对评审工作没有制定相关的标准和规范，没有建立组织级过程。评审资源没有得到保证，资深评审人员其他工作比较多，没有投入足够的时间。评审计划草率、不合实际，或没有及时调整，或实施不力。项目经理没有为评审或改正保证足够的时间。 * 测试用例的编