软件测试基本流程

《软件测试基本流程》由会员分享，可在线阅读，更多相关《软件测试基本流程（21页珍藏版）》请在装配图网上搜索。

1、单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件测试流程培训,SUN,什么是软件测试,软件测试概念,使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果于实际结果

2、之间的差别,软件测试原则,1.,应及早进行测试并把测试贯穿于整个软件生命周期,2.,软件测试应追溯需求,3.,测试应由第三方构造,4.,穷举测试是不可能的,5.,必须确定预期输出结果,6.,必须彻底检查每个测试结果,7.,充分注意测试中的群集现象,软件生命周期,V,模型,通过,V,模型我们可以看出：,软件测试按阶段可分为,单元测试,集成测试,系统测试,验收测试,我们一般进行的测试为系统测试，即将所有系统元素结合在一起，在实际运行环境下对系统进行全面的功能覆盖。,软件测试流程,软件测试一般流程：,1.,制定测试计划,2.,设计测试方案,/,用例,3.,实施测试,4.,测试总结,需求阶段：,根据需

3、求规格说明书输出系统测试计划,详细设计,/,编码阶段：,评审开发输出的,SRS,（详细设计说明书）,根据最终,SRS,输出测试方案,/,测试用例,-,评审,/,修改测试方案,/,用例,测试阶段（,SDV1,、,SDV2,、,SDV3,）：,1.,每轮测试前需要做冒烟测试，执行功能,Chicklist,，确认系统主要功能正确，,如果,Chicklist,达不到要求，可以要求开发版本打回（最好的办法是提供开发人员一份,Chicklist,，要求开发出版本转测前进行自测，保证,Chicklist,全部通过才转测试），每轮测试结束后进行测试用例的修改,/,补充工作。,2.SDV1,阶段时间最长，要求在

4、此阶段时间内尽量将问题发现，避免以后阶段再出现低级,BUG,。每轮以用例全部执行完，功能全部覆盖作为结束标准（迭代开发除外）。,3.SDV2,或,SDV3,阶段，在冒烟测试后，系统测试展开前，需要进行上一轮的问题回归测试，以验证开发问题修改情况，并将回归情况进行反馈,系统测试后期一般根据需要会展开交叉测试以及发散性测试等测试策略,*系统测试完成标准以是否满足缺陷率为判定标准,测试结束需要输出测试报告,测试报告以代码量、测试用例数、缺陷数、投入人力,/,天数为数据依据,测试总结、问题回溯,/,漏测分析,测试方案,/,测试用例编写,测试方案设计：,测试方案就是对系统模块的功能进行分析后，设计测试点

5、（正常、异常情况），要求达到对模块功能的的覆盖，指导测试用例的设计,注：,测试方案阶段要求对模块功能实现逻辑进行全面的掌握，包括功能限定，异常情况处理、后台数据处理，涉及到的数据表,/,字段等,建议和开发多进行沟通，让开发人员对实现逻辑等进行全面说明，并做记录,测试方案设计样式根据各个公司要求进行，一般是写在各个功能的,SRS,后,测试用例设计：,测试用例设计使用的的测试方法,1.,等价类划分,2.,边界值法,3.,因果图,判定表,4.,通过测试,5.,失败测试,6.,错误猜测,7.,随机测试,等,测试用例设计的注意点,1.,一种情况一条用例，用例设计尽可能细化,2.,用例名称要求能简单明了的

6、描述该用例的测试点,3.,用例级别要明确，一般主功能正常用例的级别为,1,级，复杂及异常情况用例可为,2,、,3,级,4.,预置条件要清楚，对该用例执行所需要满足的条件描述清楚，特别是异常情况用例时。,5.,测试步骤尽量详细，要做到让用例设计者以外的人能根据测试步骤顺利执行用例，格式不做强制要求,6.,预期结果要明确，对于页面跳转，数据入库等结果要细化，异常操作要有相应提示等。例如用户注册成功后，页面跳转到注册成功页面，出现相应提示信息，哪些表中会有相应用户注册数据，或哪些表中哪个字段值会有何样改变等。,要做到能让用例设计者以外的人执行用例后对于执行的结果有明确清楚的判定标准,测试策略简介,功

7、能测试,性能测试,负载测试,压力测试,容量测试,易用性测试,安装测试,界面测试,配置测试,文档测试,兼容性测试,安全性测试,恢复测试,如何有效的跟踪问题,测试时往往会遇到很多问题阻塞测试进度，或者问题单迟迟得不到解决的情况，此时要求测试人员能发现问题，尽量通过日志进行定位，如无法定位问题所在，应及时找相关开发人员进行问题定位及解决。但是也不能将问题丢给开发作为跟踪的结束，要定时跟踪问题解决情况，并尽量让开发给出解决问题时间点，进行其他方面工作，以避免时间浪费。平时需要和开发保持良好沟通，解决问题会快一点，开发主动性也会相对较高。,对于测试人员来说，要学会定位问题，学会通过日志发现问题，平时在开

8、发人员帮助解决问题时可进行学习，知道问题所在,测试驱动开发,虽然说在项目开发过程中开发人员处于主导地位，但是测试人员是站在用户的角度去评价系统的，测试人员如过发现流程或者设计不合理的地方应及时提出，和开发进行讨论，驱动开发人员修改设计不当的地方。,当开发人员对测试人员提出的意见比较排斥时，不能开发人员说什么，测试人员听什么，要根据情况坚持自己的观点，必要时可找有决策权的人决定是否修改,问题单编写规范,1.,问题单标题规则,【,模块名,】+,问题描述,问题描述尽量用简介的语言将问题描述清楚，不宜过长,2.,需要有详细的重现步骤，对于概率性出现的问题要尽量重现操作步骤；,3.,实际结果或存在问题,

9、4.,预期结果或建议,5.,最好每个问题能附上图片,注：对于一些突发的问题，尽量截图保留问题页面，再分析是否 为系统问题,问题单级别,致命：系呕吐那个任何一个主要功能完全丧失，数据受到破坏、系统崩 溃、死机等,严重：系统的主要功能部分丧失，数据不能保存，所提供的功能或服务受到明显影响,一般：系统次要功能没有完全实现，但不影响用户使用,建议：不影响功能的，提示信息，易用性方面等,关于,Chicklist,作为每次转测试前的冒烟测试（预测试），修要保证转测的系统主要功能完全实现，满足此条件才可进入测试阶段，否则根据,Chicklist,执行情况，可将包打回给开发。,最好要求开发人员打包后先自行验证,Chicklist,一遍再转测试，以保证转包质量,Chicklist,内容一般包含,模块,模块主功能,对应开发人员,开发人员验证结果,对应测试人员,测试人员验证结果,备注等,使用,Chicklist,的目的也是为了保证转测试的包的质量，避免不必要的时间浪费，规范流程,谢谢！,