软件测试01_软件测试工作流程

1、软件测试过程需求确认测试设计测试执行测试总结测试计划同行评审里程碑总结SQA测试活动组间协调管理者 编写测试计划 内容： 时间和人员安排 同行评审及同行评审负责人； 里程碑制定； 进度表； 风险计划的制定； 培训的计划； 测试计划需要进行评审；需求确认需求确认测试工作的介入1. 测试开始介入的时间和系统组的建立时间几乎同时进行.2. 用充足的时间去分析用户需求(在NEU-APN事业部的名称为仕样书)中可以测试内容, 同时可以发现其中测试比较困难的内容并及时考虑解决措施3. 根据不同功能考虑进行不同级别的测试,采用不同的测试方法. 需求学习的方法测试人员自己阅读和分析仕样书, 讲解自己负责部分的

2、功能,并回答其他测试人员的提问.要求不遗漏仕样书中的任何功能,在讲解中追加自己对仕样书的理解,以及对测试难点部分考虑的测试方法.需求确认 培训的展开 组内的培训 功能测试方法和操作测试方法； 自动测试； 部门的培训 各模块功能培训； 开发技能培训； 专业知识；需求确认测试设计Test PointFunction SpecTest Case开发人员参与同行评审内部同行评审 编写测试大纲1. 形成通用的功能测试集，包含详细的测试点（以前是日方编写测试点）；2. 要求追加对测试难点的测试方法或者测试用例.3. 对于二期开发的项目,要求包含以前项目的的全部功能；测试设计 测试大纲的同行评审 同行评审的

3、内容：测试点的理解错误，测试用例的遗漏； 同行评审的类型：组内的和开发人员参与的同行评审； 同行评审的过程：制定负责人，收集问题表，组织召开同行评审会议，跟踪关闭已经解决的问题。 测试设计测试实施版本测试New VersionComponentVersion ReportReleaseNoteSystem TeamQ&A 协助再现错误BugbaseComponent Team制定小计划依据系统组的Release计划； 一般测试的周期比较长，大约4-6个月，所以针对于每个版本提交的功能的不同以及每次测试时间长短的不同,调整和制定测试组小计划.这样的计划只要在项目例会中传达或者通过Emai

4、l通知相关测试人员即可测试实施 测试方法在测试过程中,要根据软件产品的质量情况以及功能提交的情况采用不同角度的测试方法.1. 在项目初期,提交的功能比较少,软件产品的质量还达不到性能测试和极限测试的要求时. 我们需要按照测试大纲进行测试,以保证提交的功能达到基本要求,然后再关注每个功能的细节,这样可以尽可能保证开发人员完成的功能达到一个满意的质量目标.测试实施 测试方法2. 当软件产品的功能大部分已经提交时(也许这时软件产品的质量仍没有达到性能测试和极限测试的要求). 我们在按照测试大纲进行测试的过程中,除了要对基本功能进行严格测试外,更要注意不同功能之间的接口以及会受到接口影响的部分功能,因

5、为这个阶段由接口造成的错误比较多.测试实施 测试方法3. 当软件产品的功能全部提交,并且当前的错误发现曲线趋于平缓, 这就说明按照测试大纲进行测试已经很难提高错误的发现率.这时则需要采取其他测试方法包括性能,极限测试和脱离测试大纲的可用性测试.这里的性能和极限测试系统复杂度小于与软件提交前的性能和极限测试时的系统复杂度.测试实施 测试方法4. 二期开发类型的项目测试执行过程中,每个阶段都要注意原来项目的功能的实现情况,特别需要注意的是与新添加以及变更功能相关功能的测试.即新添加的功能不能影响原有的功能注: 对于二期开发项目的性能测试,在没有具体指标前,对它的要求是性能至少不低于原来的项目.测试

6、实施 测试报告 Day_Bug_Report：每个测试人员填写； Bugbase：由登录者负责把每个人的测试结果整理到Bugbase上，进行重复的过滤; BugbaseStatus :对于Bugbase作的一些分析图表； 提交给日方的BugList：包括CheckList和Bugbase的内容; 测试实施错误描述要求错误现象描述清晰准确,操作步骤简单有效.操作步骤简单有效,是要求测试人员在时间允许的情况下,可以把原来需要十几二十步才能再现,根据自己的分析和再现尽量缩短 (这样开发人员根据操作步骤,可能不需要去再现错误,就知道错误发生的原因了)错误现象描述不清晰准确,会造成开发人员的理解上歧义.

7、要求测试人员在填写错误现象时不能写象“某某功能错误”,“某某现象错误”这样的文字,要说明错误现象是什么,最好附加说明正确的现象应该是什么.测试实施 错误描述要求2. 要有充足的错误信息.我们的测试分为导航版和PC版两个测试版本.导航版的错误,一般要保留错误现象发生时的错误图片.有些错误不但要提供错误图片,还要提供当前的调试信息;死机的错误,除了提供错误现象图片和调试信息外还需要提供死机堆栈以及寄存器中的内容.PC版的错误,也与导航版类似.一般错误要保存错误现象图片和调试信息;死机错误还要保存死机时的堆栈.测试实施调试信息mapdsp_ClearOrderOfDisplayRequest Map

8、SetNum=0 mapdsp_ClearOrderOfDisplayRequest MapSetNum=0 DisplayNum=1 DisplayNum=1 MAP_Center_Position MapsetNo( 0) MAP_Center_Position MapsetNo( 0) CenterPos(0 x4c9574f1,0 x13a0949b) DispNo( 0) CenterPos(0 x4c9574f1,0 x13a0949b) DispNo( 0) CurrentNo( 0)CurrentNo( 0) MAP_Clock_End (Y/M/D) 1900/ 1/ 1 W

9、eek( 1) (H:M:S) MAP_Clock_End (Y/M/D) 1900/ 1/ 1 Week( 1) (H:M:S) 12:44:16 SysTime (0 x cd8160) MAP DRAW_Cancle 12:44:16 SysTime (0 x cd8160) MAP DRAW_Cancle CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, 1) 1) MAP DRAW_Cancle CheckClear i

10、n MAPDRW_iFirstFail MAP DRAW_Cancle CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, 3) iMapSetNo,iLayer ( 0, 3) 堆栈信息: _os_breakProgram+2(): _os_breakProgram+2(): _os_checkTaskStackSize+4E() : _os_checkTaskStackSize+4E() : _scrn_GroundInit+50() : _scrn_GroundInit+50() 和SP 0026907C : 0000000C fb

11、mem_AreaSize SP 0026907C : 0000000C fbmem_AreaSize SP+ 400269080 : 0666DD24 _os_checkTaskStackSize SP+ 400269080 : 0666DD24 _os_checkTaskStackSize SP+ 800269084 : FE000616 SP+ 800269084 : FE000616 _os_vAttachToStopRun+26_os_vAttachToStopRun+26 寄存器信息R10 001C6EBC R10 001C6EBC * *001C2AE0 HPR+184 001C2

12、AE0 HPR+184 R11 FFFFFFFF R11 FFFFFFFF * *0000000000000000R12 00000000 R12 00000000 * *00000000 check_find00000000 check_findR13 00005090 R13 00005090 * *00000000 SIT_INT_STACK+488E00000000 SIT_INT_STACK+488ER14 00E80234 R14 00E80234 * *00000000 _ghsbegin_bss+5ACE400000000 _ghsbegin_bss+5ACE4R15 0000

13、0008 R15 00000008 * *FFFFFFFF tsk_countFFFFFFFF tsk_countR16 069D0736 R16 069D0736 * *C542180B _e_entfnc+AEC542180B _e_entfnc+AER17 00E80370 R17 00E80370 * *00005090 _ghsbegin_bss+5AE2000005090 _ghsbegin_bss+5AE20 提高错误的再现率这个问题,很多测试人员不重视,他们认为只要我测试出错误就可以了.其实不然,本来一些错误的再现率就很低,在测试人员这里不容易再现(至少测试人员还知道错误出现的

14、大概步骤),那么在开发人员那里就更难再现,给开发人员分析错误带来很大困难.因此我们要求测试人员发现错误后要尽力寻找再现方法,提高错误的再现率.1/n的描述是最不好的描述。不过,这对测试人员来说的确也是一种挑战测试实施 重视确认测试 确认测试的时机： 建议在测试功能过程中进行一些简单问题的确认，可以节约专门的确认时间； 确认方法：再现率较低的错误, 确认测试要远超过发现错误时的测试次数,比如一个Bug再现率是3/10,那么确认时至少要做到20次.再现率更低的错误,确认测试要在多个版本中进行.确认测试执行,不能只关注Bug本身,要对Bug相关部分的功能都进行测试,以确保Bug的修改不会影响其他部分

15、.测试实施 测试评价 专门的评价组； 评价内容：性能，用户测试，全系统的内容，不针对于功能； 评价结果：除了填写Buglist，对于产品的评价内容体现在测试组的周报中；测试实施 组间协调 在工作的过程中，需要和其他组进行协作或是提供支持的地方。目前的工作中，测试组面临的组间协调对象主要是各个开发组； 协调的内容： 系统组例会上各个工作组之间的安排； 测试过程中，对于问题的请教； 测试现场的保留；测试实施 组间协调 问题的询问测试时出现仕样中没有明确说明的错误现象时,需要测试人员及时与开发人员沟通,由开发人员确认是否是错误.这样不但可以提供错误提交的质量,另一方面也节省开发人员分析错误后,再与测

16、试人员讨论的时间测试实施 组间协调 现场的调试 测试时发现严重错误(多为再现率较低的错误)时,需要测试人员及时找到相关开发人员,根据现场进行分析和调试.这样可以最大程度减少开发人员和测试人员再现错误时间以及开发人员分析错误的时间.矛与盾是互相对立的.现场调试节省了开发人员时间,但是也不同程度的浪费了测试人员的时间.(现在比较好的解决方法是测试人员使用多于一台的机器进行测试)测试实施组间协调经常与开发人员沟通,可以了解开发人员如何去实现某个功能,这些实现方法可能就会有漏洞,根据这些漏洞的测试,常常会有事半功倍的效果.这种方法,在软件开发的中后期很有效.毕竟开发人员设计软件时主要考虑如何完成仕样中

17、说明的功能, 到项目中后期正常的功能基本不会出错,但是一些功能的细节和容错的处理是开发人员容易忽略的地方.测试实施 自动测试工作 工具： SQA,只能进行PC版的自动测试； 操作Log:导航机上进行操作记录的工具； 应用： 静态的，无自车走动的； 重复的，可以大大节省手动测试的内容； 限制： 不适合检验结果；测试实施 里程碑总结及评审 如果测试执行的时间比较长，不同的测试阶段之间的跨越比较明显，通常会作里程碑的总结；测试实施 SPTO 责任者：测试负责人 主要工作： 监督工作进度； 检查工作质量； 进行信息反馈； 及时发现问题，提供解决措施； 风险的跟踪， 调整计划；测试实施 SQA工作 由事

18、业部的SQA人员对于测试的各项活动和输出进行检查，填写不合格问题； 测试组内容设立QA人员，协助测试负责人进行一些工作的检查和监督，并填写SQA周报；测试实施 SCM工作 配置项包括：需求文档，和CheckList; 注意内容： 1. 使用成为基准的内容，开始下一步的工作； 2.对于CheckList标识版本，需要时进行翻译； 测试实施 度量数据的收集 收集形式：测试组个人周报； 收集内容： 时间的分配：包括测试设计时间，使用CheckList测试时间，随机测试时间，确认测试，再现测试的时间等等， 规模：总的和本周的CheckList编写数目； 确认工作的进度； 每个版本测试和确认的Bug数； 测试实施总结经验市场上所有有关测试的书籍都是在讲测试的理论,很少发现有讲测试经验的. 因为经验只有从实际的测试工作中得到.每个项目完成后,我们或多或少都会有一些好的工作经验,积累这些经验才能使我们的测试能力逐步提高.测试工作没有最好测试工作没有最好,