chapter3-0测试软件需求.ppt

2019/6/5,1,软件测试技术,测试需求分析,回顾,软件测试的目的是？ 软件测试的对象是？ 软件产生缺陷的原因？ 软件测试的分类？ 软件测试的过程模型？ 集成测试的方法 为什么要测试需求分析？,3,测试过程与管理 测试需求分析（产品业务理解） 测试计划（项目管理、软件过程） 测试设计与测试用例编制 测试执行（工具软件应用） 测试记录与跟踪 测试总结与报告,测试需求分析,4,思考,1、为什么要测试软件需求？ 2、什么是需求分析？ 3、需求规格说明书的测试要点有哪些？ 4、需求规格说明书的测试步骤是怎样的呢？ 5、测试需求的其他方式有哪些？,5,开发生命周期,需求分析,设计定义,程序编制,维护,建立,建立,建立,修改,测试生命周期,测试计划,缺陷跟踪,越早测试越好,软件测试生命周期,6,软件测试阶段组成,测试计划,测试开发,测试执行,7,什么是需求分析？,准确的定义系统“做什么”： 深入描述软件的功能和性能； 确定软件设计的限制和软件同其他系统元素的接口细节； 定义软件的其他有效性需求。,8,为什么要测试需求分析？,数据表明，50%65%的缺陷是在软件需求阶段被引入的，这其中的50%是由于需求文档的编写存在问题、不明确、不清晰、不正确导致，剩下50%是由于需求的遗漏所致。 越早发现错误，付出的代价越低。,图 来源于错误的需求导致的缺陷所占的比例,9,测试软件需求,需求分析过程 在进行需求分析时，需要经历下列几个步骤： 收集用户需求 编写需求定义文档 编写软件功能说明 编写软件需求跟踪矩阵 审核软件需求文档,10,需求分析中测试人员工作 理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源,11,软件需求文档 需求文档是进行设计、编码、测试的基础文件，软件需求文档中，需要描述下列内容： 说明 一般描述 各种限制条件、假定和由来 功能需求 非功能需求 参考,12,需求跟踪矩阵P30表2-1 对于需求文档中的每项需求，要确保以下问题： 是否完成了相应的设计？ 是否编写完成了相应的代码？在哪里可以找到这些代码？ 是否编写完成了相应的单元测试用例？是否进行了单元测试？ 是否完成了相应的集成测试用例？是否进行了集成测试？ 需求跟踪矩阵即描述上述问题。,13,从以下几个方面来评价需求文档： 需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否兼容？需求有可能是矛盾的。 需求是否可实现？ 需求是否合理？ 需求是否可测？,如何进行需求测试？,14,需求来源,用户需求调研 所收集的用户需求原始资料 需求规格说明书 以往系统应用经验,一般系统的应用经验 系统启动 基本功能界面操作 初始数据准备 用户组及用户 基本数据 主要业务功能,15,16,复查 (Review) 复查一般是让工作中的合作者检查产品并提出意见。同级互查可以面对面进行，也可以通过E-Mail实现，并没有统一标准。发现文档缺陷同级互查的能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查被证明是非常有效的发现缺陷的方法。,需求测试的方法,分组对学生信息管理系统的需求规格说明书进行评审，每组派代表上台讲解。,18,定义测试需求,定义,测 试 需 求,根据用户需求定义并完善测试 需求，以作为整个测试的标准,19,具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先等级进行定义 描述明确，无歧义、二义，上下文一致 可证实和可测试性 可修改性 可追踪 需求文档被及时更新,什么是好的需求文档？,20,需求说明书的检查要点,正确性 必要性 优先级 明确性 可测性 完整性 一致性 可修改性,21,需求规格说明书的测试步骤,22,需求规格说明书的测试步骤,第1步 获取最新版本的软件需求规格说明书，同时尽量取得用户原始需求文档 第2步 阅读和尝试理解需求规格说明书中描述的所有需求项 第3步 对照需求规格说明书检查列表进行测试并记录 第4步 针对测试结果进行讨论、修订需求规格说明书后回到第一步，直到检查列表的所有项通过,23,需求规格说明书的检查列表,24,测试需求的其他方式,通过编写测试用例来测试需求 通过用户调查来测试需求 利用现存的产品对需求进行测试,25,编写测试用例来测试需求,通过编写用例来检查需求,26,编写测试用例来测试需求,开发人员通过尝试设计，可以反过来验证需求规格说明书能否很好地指导设计和开发 测试人员也可以通过设计测试用例来检查需求 测试人员通过想象产品已生产出来，构建一系列的测试用例，并问一些“假设”的问题，尝试回答这些测试用例并且与设计人员讨论答案。 试图认同答案通常会导致其他更多的“假设”问题，引发的“假设”问题都必须得到很好的回答，否则可认为需求还不够清晰、完善，或者可测性不够强。,27,案例分析,如何理解测试对象？ 试图理解你所熟悉的软件。 应该理解测试对象的哪些特性？ 界面 功能组 操作过程 数据项 输出结果分析 通过哪些途径理解测试对象？ 平常的使用 操作手册 特殊功能和特性：网络,28,案例分析,如何理解测试对象？ 试图理解你不熟悉的软件。 应该理解测试对象的哪些特性？ 界面 功能组 操作过程 数据项 输出结果分析 通过哪些途径理解测试对象？ 需求规格说明书、操作手