软件测试流程及规范V1.1.docx

《软件测试流程及规范V1.1.docx》由会员分享，可在线阅读，更多相关《软件测试流程及规范V1.1.docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试流程及规范V1.1二、各阶段详细流程1.需求分析阶段立项需求调研编写/修改SRS提交SRSSRS审核审核能否通过到达要求提交最终版SRS审核能否通过审核通过根据SRS，项目整体计划，设计、编写（测试计划）和（测试设计）（测试计划）根据SRS定义相应的测试需求报告，即制订测试的标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适中选择测试内容，合理安排测试人员、测试时间及测试资源等。（测试设计）将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试经过，并为每个测试经过选择适当的测试用例。进入概要设计阶段评审测试计划和测试

2、设计优化测试计划、测试设计1.1步骤讲明1、需求定义基本完成，SRS编写完成。2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完好、存在疑义的地方提出问题，相关人员解答并确认。3、当评审未通过，直接打回，重新修改SRS，问题解决后，重新提交评审。4、当评审通过后，根据SRS，项目整体计划，设计、编写（测试计划）和（测试设计），详细模板见附件。5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完好、存在疑义的地方提出问题。6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。7、审核通过后，进入下一阶段。1.2测试通过打回标准

3、1.3、阶段的输出输入：最新SRS、项目计划输出：测试计划、测试设计2、单元及集成测试流程测试设计文档编写/修改测试用例测试用例审核审核能否通过编写/修改单元测试方案单元测试方案评审审核能否通过编写/修改测试代码编码审核审核能否通过执行单元测试提交BUG报告修改代码回归测试，能否到达要求提交单元测试报告进入下一阶段根据需求和设计描绘作为指南，对重要的控制途径进行测试以发现模块内的错误。测试经过中优先考虑耦合度比拟高的模块功能，重点测试。使用缺陷管理工具如QC，对软件的缺陷进行管理。在BUG出现的曲线图逐步收敛并且得到控制的情况下进入下一阶段。假如是集成测试，根据需求和设计描绘作为指南，在单元测

4、试的基础上，将所有模块根据设计要求组装成为子系统或系统,检查其接口能否存在问题,以及组装后的整体功能、性能表现，进行测试。2.1步骤讲明：1、理解需求和设计理解设计是很重要的，十分是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成本人的事情，层次与分工是很明确的。在单元测试的时候，能够不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有时机测试到的。所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，由于会有别的模块去完成相关的功能。2、概览源代码阅读一下源代码，主要任务：1初

5、步检查源代码的编码风格与规范。2大致估算测试工作量，比方：需要多少的测试用例、需要写多少的驱动模块和装模块等。3确定模块的复杂程度，初步制定测试的优先级等。3、精读源代码认真阅读和分析代码，主要任务：1理解代码的业务逻辑。2检查代码与设计能否相符，假如具体设计没有该模块的流程图的话，先去画出流程图。3仔细研究逻辑复杂的模块。4能够采用一些检查列表来检查程序可能会出现的问题。4、设计测试用例综合运用白盒测试方法和结合黑盒测试方法来设计测试用例，包括功能测试、性能测试等，要到达一定的测试覆盖率。在设计测试用例的经过中，流程图或控制流图是分析的好帮手。5、搭建单元测试环境使用工具或本人写的框架将有助

6、于单元测试的施行。在这个阶段主要就是写桩模块和驱动模块，第4步所设计的测试用例是通过驱动模块传递给被测试模块的，然后驱动模块想办法获取被测试模块对数据的处理结果，并断定返回的实际结果与测试用例的预期结果能否一致，通过测试框架来记录执行的结果，对于出现的错误，还需要统计错误的信息，供执行完之后分析。6、执行测试运行写好的驱动模块完成对被测试模块的测试。7、补充和完善测试用例单元测试也是个循序渐进的经过，可能一开场考虑的不够全面，或预期的覆盖标准太低，需要在测试经过中不断补充测试用例，直到知足要求为止。8、分析结果，给出评价根据测试的结果分析、查找错误的原因，并找到解决的办法。测试结束之后，根据测

7、试经过的数据统计，给出被测试对象评价2.2测试通过打回标准1、通过标准2、打回标准2.3、阶段的输出输入：最新SRS、项目计划、具体设计输出：单元测试计划、单元测试用例、单元测试总结分析。3、系统测试流程系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统能否知足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，进而提出愈加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求讲明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试

8、的软件，还要包含软件所依靠的硬件、外设甚至包括某些数据、某些支持软件及其接口等。接上一阶段发测试任务书通知编写/修改系统测试方案测试方案评审评审能否通过编写/补充测试用例用例评审能否通过执行系统测试提交BUG报告修改代码回归测试，能否到达需求标准提交系统测试报告进入下一阶段使用缺陷管理工具如QC，对软件的缺陷进行管理。在BUG出现的曲线图逐步收敛并且得到控制的情况下进入下一阶段。将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，针对整个产品系统进行的测试，目的是验证系统能否知足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，进而提出愈加完善的方案。冒烟测试能否通过退回或挂起系

9、统测试审核汇总bug，总结测试报告3.1步骤讲明1、测试组收到测试任务通知书，告知较为确切的测试内容、日期。2、根据最新SRS和各设计文档，将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，针对整个产品系统进行的测试。3、编写此阶段系统测试方案，通过评审，优化系统测试方案。4、然后编写或补充系统测试用例，用例完成后，需要通过评审，优化系统测试用例。5、执行冒烟测试用例，测试版本仅少量严重程度低的bug未修改引起的不通过，反应项目组，通知延长冒烟测试时间；测试版本符合冒烟测试打回标准，冒烟测试不通过，直接打回或挂起，结束测试。测试完成度知足冒烟测试开场条件，重新发起测试申请。6、当不通过时，退回或挂起。7、当完成冒烟测试后，进行系统测试，提交bug报告，审核bug，当审核未通过时，补充测试用例，当审核通过汇总bug，总结报告。8、当开发人员完成缺陷的修改后，提交新的版本，测试人员继续开场做回归测试。当测试版本仅少量bug未修改引起的不通过，反应项目组，通知延长系统测试时间；测试版本符合系统测试打回标准，系统测试不通过，直接打回，结束测试。待测试完成度知足系统测试开场条件，重新发起测试申请。9、当缺陷的统计曲线出现的逐步收敛，并且得到控制。10、分析缺陷的原因。11、提交测试报告。12、进入下一阶段。3.2测试通过打回标准1通过标准2打回标准