软件测试01_软件测试工作流程题稿.ppt

软件测试工作流程 软件测试过程 编写测试计划 内容： 时间和人员安排 同行评审及同行评审负责人； 里程碑制定； 进度表； 风险计划的制定； 培训的计划； 测试计划需要进行评审； 需求确认 测试工作的介入 1. 测试开始介入的时间和系统组的建立时间几乎同时进行. 2. 用充足的时间去分析用户需求(在NEU-APN事业部的名称为仕样书)中可以测试内容, 同时可以发现其中测试比较困难的内容并及时考虑解决措施 3. 根据不同功能考虑进行不同级别的测试,采用不同的测试方法. 需求学习的方法 测试人员自己阅读和分析仕样书, 讲解自己负责部分的功能,并回答其他测试人员的提问. 要求不遗漏仕样书中的任何功能,在讲解中追加自己对仕样书的理解,以及对测试难点部分考虑的测试方法. 培训的展开 组内的培训 功能测试方法和操作测试方法； 自动测试； 部门的培训 各模块功能培训； 开发技能培训； 专业知识； 测试设计 编写测试大纲 1. 形成通用的功能测试集，包含详细的测试点（以前是日方编写测试点）； 2. 要求追加对测试难点的测试方法或者测试用例. 3. 对于二期开发的项目,要求包含以前项目的的全部功能； 测试大纲的同行评审 同行评审的内容：测试点的理解错误，测试用例的遗漏； 同行评审的类型：组内的和开发人员参与的同行评审； 同行评审的过程：制定负责人，收集问题表，组织召开同行评审会议，跟踪关闭已经解决的问题。 测试实施 制定小计划 依据系统组的Release计划； 一般测试的周期比较长，大约4-6个月，所以针对于每个版本提交的功能的不同以及每次测试时间长短的不同,调整和制定测试组小计划. 这样的计划只要在项目例会中传达或者通过Email通知相关测试人员即可 测试方法 在测试过程中,要根据软件产品的质量情况以及功能提交的情况采用不同角度的测试方法. 1. 在项目初期,提交的功能比较少,软件产品的质量还达不到性能测试和极限测试的要求时. 我们需要按照测试大纲进行测试,以保证提交的功能达到基本要求,然后再关注每个功能的细节,这样可以尽可能保证开发人员完成的功能达到一个满意的质量目标. 测试方法 2. 当软件产品的功能大部分已经提交时(也许这时软件产品的质量仍没有达到性能测试和极限测试的要求). 我们在按照测试大纲进行测试的过程中,除了要对基本功能进行严格测试外,更要注意不同功能之间的接口以及会受到接口影响的部分功能,因为这个阶段由接口造成的错误比较多. 测试方法 3. 当软件产品的功能全部提交,并且当前的错误发现曲线趋于平缓, 这就说明按照测试大纲进行测试已经很难提高错误的发现率.这时则需要采取其他测试方法包括性能,极限测试和脱离测试大纲的可用性测试. 这里的性能和极限测试系统复杂度小于与软件提交前的性能和极限测试时的系统复杂度. 测试方法 4. 二期开发类型的项目测试执行过程中,每个阶段都要注意原来项目的功能的实现情况,特别需要注意的是与新添加以及变更功能相关功能的测试.即新添加的功能不能影响原有的功能 注: 对于二期开发项目的性能测试,在没有具体指标前,对它的要求是性能至少不低于原来的项目. 测试报告 Day_Bug_Report：每个测试人员填写； Bugbase：由登录者负责把每个人的测试结果整理到Bugbase上，进行重复的过滤; BugbaseStatus :对于Bugbase作的一些分析图表； 提交给日方的BugList：包括CheckList和Bugbase的内容; 错误描述要求 错误现象描述清晰准确,操作步骤简单有效. 操作步骤简单有效,是要求测试人员在时间允许的情况下,可以把原来需要十几二十步才能再现,根据自己的分析和再现尽量缩短 (这样开发人员根据操作步骤,可能不需要去再现错误,就知道错误发生的原因了) 错误现象描述不清晰准确,会造成开发人员的理解上歧义.要求测试人员在填写错误现象时不能写象“某某功能错误”,“某某现象错误”这样的文字,要说明错误现象是什么,最好附加说明正确的现象应该是什么. 错误描述要求 2. 要有充足的错误信息. 我们的测试分为导航版和PC版两个测试版本. 导航版的错误,一般要保留错误现象发生时的错误图片.有些错误不但要提供错误图片,还要提供当前的调试信息;死机的错误,除了提供错误现象图片和调试信息外还需要提供死机堆栈以及寄存器中的内容. PC版的错误,也与导航版类似.一般错误要保存错误现象图片和调试信息;死机错误还要保存死机时的堆栈. 调试信息 mapdsp_ClearOrderOfDisplayRequest MapSetN