软件测试总体框架讲解.ppt

用例评审完了，是不是接着马上进入测试？ 在测试执行过程上，有一套业界较为通用的流程，以一个CMMI3级的公司流程为例，给大家介绍一下在测试执行过程上，涉及到哪些角色和活动 先来看角色 测试其实是一个执行用例的过程 在每轮测试结束后，需要不断地去修正、补充我们的用例，以达到降低漏测的风险 在测试过程中，我们会需要及时把缺陷反馈给开发团队，通常会借用一些缺陷管理工具，例如QC、JIRA、禅道等， * 缺陷要素： 缺陷主题（简要描述缺陷表象） 缺陷严重等级：通常有高、中、低、建议四类，根据各公司的规范有所不同 缺陷提交人、缺陷处理人，提交缺陷时间，处理时间，缺陷状态、提交版本、修复版本等 缺陷分类：例如页面、功能、数据等分类 缺陷细详描述：具体描述缺陷出现的操作步骤 附件：缺陷也需要讲证据，以防开发抵赖^_^ 测试人员在什么时候对开发已修复的缺陷进行验证，正常情况下，是不允许开发边修复边更新测试环境，所以需要等到下一次开发提交回归测试时再进行验证 * 测试执行完一轮后，接下来要做的工作是什么呢，测试完一轮当然是要广而告知，让开发的同事和领导知道，我们已经按计划完成，你们可能要加班改缺陷了，我们等着回归测试 一个测试结果反馈（指一轮测试完成后）包括什么：因为有用缺陷管理工具，所以在测试报告里不需要详细列出这个版本有哪些缺陷，需要告诉他们：这个版本根据状态有多少缺陷，根据严重等级有多少，缺陷密度等，在测试过程中与开发的交互有哪些困难，测试时间，参与的测试人员等 特别是在最后一个发布版本的报告中，还剩余多少缺陷 回归测试不单独拎出来写了，回归测试其实是重复P5的流程，需要注意的是，在什么情况下可以完成这个版本的测试：达到发布标准，发布标准是由各公司根据实际情况制定的符合产品情况的准则 在回归测试过程中，除了验证已复修的缺陷外，不要漏了与这个缺陷关联的功能，因为修复后最可能引起新缺陷就是关联功能。 * 详细内容可对打开文档讲解（有分析内容） * 举例： 业务需求：建一幢够三世同堂住的房子，房子要明亮，宽敞 用户需求：要有一个厨房，要在家里煮饭、要有饭厅，一家三代可以坐在一起用餐、要有会客的地方，所以需要客厅，起居的房间 功能需求：厨房和饭厅要连在一起，祖辈的房间要在一楼，方便其出入，二楼是父辈及孙辈，方便照顾小孩，各个房子的朝向，窗要开的位置，规格，房间的位置，大小等。 * 。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等。 测试需求力求详细明确，以避免测试遗漏与误解。 为什么要进行测试需求分析，先来看用户需求与测试需求的区别 * 系统功能复杂，需求不明确，我们有没有把握对系统执行完整的测试？接收一个测试任务时，我们需要去了解哪些内容？ 需求存在的一些风险?：??? 无足够用户参与 用户需求的不断增加 模棱两可的需求 过于精简的规格说明 我们自己团队行业业务、项目经验的不足 * 目的目确了，简单来说就是要转化需求，需求从哪里获取呢，接下来了解下测试人员或以通过哪些手段去了解需求 * 与软件相关的文档——需求、界面原型、业务规范、需求调研会的会议纪要 与相关人员的沟通 ——分析实计人员、开发人员、实施人员 相关的业务培训、评审 ——参与到相关的业务培训或需求、分析、设计等的评审会 其他。如果以旧系统为原型，重新开发的软件，旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。 ?? 首先，分析用户提供的所有文档，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。 其次根据不同的测试类型，分析测试需求。测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同。??????? 其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。 * * 确认模块所包含的功能 将每一个功能点（特征项）形成对应的用例 对每个用例分析其对应的输入、处理、和输出 明确用例之间的关系 分析业务场景 明确每个业务场景中的功能点 分析对应的功能所隐藏的隐式需求 确认模块所包含的功能： 业务功能：与用户实际业务直接相关的功能 或细节。 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷健就是典型的易用性需求。 编辑