four软件测试流程.pptVIP

软件测试流程 详细的测试步骤 详细测试步骤： 1. 书写测试计划 2. 审核测试计划，未通过返回第一步 3. 书写测试用例； 4. 审核测试用例，未通过返回第三步 5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例） 6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW）  7. 集成部经理接到bugzilla发过来的bug 7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）; 7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RESOLVED，决定设置为INVALID）; 7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND） 8. 开发人员接到发过来的bug立刻修改;（bug状态RESOLVED，决定设置为FIXED） 9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）； 10. 如果复测有问题返回第六步（bug状态REOPENED） 11. 否则关闭这项BUG（bug状态CLOSED）  12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务； 13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试； 14. 测试任务结束后书写测试总结报告； 15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件； 16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。 测试工作总体流程图 华为的测试流程 测试部的前期工作 需求阶段: 测试部会在开发人员写需求分析的时候就派人跟踪此项目,在这个阶段完成系统测试用例的设计,通过此工作来验证需求的可测试性和合理性. 概要设计阶段: 此阶段测试部会完成集成测试用例的设计和用例的写作 系统测试介绍 测试策略 定义测试哪些用例. 定义重点测试的模块. 定义预测试通过的条件. 测试风险,以及规避措施等. 测试计划 定义测试时间 测试人员,测试环境,测试仪表,测试版本等 测试报告 对整个系统做出一个评价. 分模块进行评价. 给出下一轮测试的测试建议和测试重点. 值得借鉴的地方(1)——特点 测试用例库 测试简单,方便,提高测试效率. 方便制定测试策略. 完成测试经验的积累和共享. 自动测试 能够完成大部分机械性的操作, 节省人力,提高开发效率. 测试人员可以设计出更加优秀的测试用例. 值得借鉴的地方(2)——特点 测试策略和计划 在测试之前根据实际情况,制定测试内容,测试计划,对测试有着很强的指导意义. 为以后测试的改进做好准备. 带分析的测试报告 值得借鉴的地方(3) 测试方法: 为了保证测试的质量和投入,测试部一般会对版本进行预测试,预测试通过之后会按测试计划来进行测试,如果预测试不通过会打回到开发,此种情况会影响开发团队的考核. 一旦通过预测试,则需要完成整个测试计划,这样可以减少测试版本,缩短开发周期. 系统测试过程 一般测试三轮,第一轮为全局测试, 第二轮为重点模块测试, 第三轮为回归测试, 主要针对第二轮的问题单进行测试和开局的模拟验证,如果不能达到发布条件则需要进行下一轮测试. 系统测试的依据 任何事情都要有个评判的依据,比如目前我们的手机项目来说,测试的依据就是开发人员提供的“规格书”,凡是和规格书不一致的地方都可以认为是问题. 当然也不排除规格书有误的地方,这些也需要提出来要求开发人员改正,以保证资料的正确性和权威性. 对测试人员的要求 需要了解代码. 需要经常和开发人员进行交流, 提升自己对系统的理解能力。 能够大致评估开发人员修改带来的影响. 能够清晰的描述问题,并进行初步定位,给出参考意见. 多从用户的实际使用角度来设计用例. 能够考虑各种异常情况. 软件部对测试部的一些建议 问题单描述不清楚，不规范，不容易看懂. 重现条件需要写清楚. 极限操作要在合理的范围之内 测试部对软件部的一些建议 。。。。。 2. 测试规范2.1 测试流程 第一步：制定测试计划。该计划被批准后转向第二步。 第二步：设计测试用例。该用例被批准后转向第三步。 第三步：如果满足“启动准则” ，那么执行测试。 第四步：撰写测试报告。 第五步：消除软件