软件测试流程及规范V1

《软件测试流程及规范V1》由会员分享，可在线阅读，更多相关《软件测试流程及规范V1（37页珍藏版）》请在金锄头文库上搜索。

1、软件测试流程及规范V1.1软件测试流程及规范一、软件生命周期中测试工作流程则试工作流程业务部软件部测试组段阶析分求需提交最终版SRS段阶计设要概段阶计设细详写测试计划、测试方案1F设计测试田例 编写测试田例段阶码编段阶试测统系段阶试测收验编辑单元测试方案、用例分析、修改缺陷回归测试提交系统测试报告扁辑单元测试方案、用例4冒烟测试提交系统测试报告根据SRS评审验收测试方案、用例T分析缺陷回归测试提交验收测试报告编写验收相关文档执行单元测试记录缺陷单元测试方案、用例评审系统测试方案、用例评审分析缺陷执行系统测试修改缺陷记录缺陷I执行验收测试修改缺陷记录缺陷、各阶段具体流程1.需求分析阶段立项需求调

2、研达到要求审核是否通过评审测试计划 和测试设计优化测试计划、 测试设计提交SRS测试计划根据SRS定义相应的测试需求报 告，即制订测试的标准，以后所 有的测试工作都将围绕着测试需 求来进行，符合测试需求的应用 程序即是合格的，反之即是不合 格的；同时，还要适当选择测试 内容，合理安排测试人员、测试 时间及测试资源等。测试设计将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程，并为每个测试过程选择 适当的测试用例。依据SRS，项目整体计划, 设计、编写测试计划 和测试设计提交最终版 SRS编写/修改SRSJL审核是否通过SRS审核审核通过*进入概要设计阶段1.1步骤说明1、需求定

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

4、：测试计划、测试设计2、单元及集成测试流程测试设计文档使用缺陷管理工具（如QC）,对软件的 *缺陷进行管理。*编写/修改测试代码提交BUG报告修改代码回归测试， 是否达到要求审核是否通过提交单元测试报告进入下一阶段执行单元测试+在BUG出现的曲线图逐 渐收敛并且得到控制的 情况下进入下一阶段。2.1步骤说明:1、理解需求和设计 理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内 容将会有很大的影响。需要记住的一个原则就 是：好的设计，各模块只负责完成自己的事情， 层次与分工是很明确的。在单元测试的时候，可 以不用测试不属于被测试模块所负责的功能，以 减少测试用例的

5、冗余，集成测试的时候会有机会测试到的。所以，单元测试主要是关注本单元的内部逻 辑，而不用关注整个业务的逻辑，因为会有别的 模块去完成相关的功能。2、概览源代码浏览一下源代码，主要任务：1）初步检查源代码的编码风格与规范。2）大致估算测试工作量，比如：需要多少 的测试用例、需要写多少的驱动模块和装模块 等。3）确定模块的复杂程度，初步制定测试的 优先级等。3、精读源代码认真阅读和分析代码，主要任务：1）理解代码的业务逻辑。2）检查代码与设计是否相符，如果详细设 计没有该模块的流程图的话，先去画出流程图。3）仔细研究逻辑复杂的模块。4）可以采用一些检查列表来检查程序可能 会出现的问题。4、设计测试

6、用例综合运用白盒测试方法（和结合黑盒测试方 法）来设计测试用例，包括功能测试、性能测试 等，要达到一定的测试覆盖率。在设计测试用例 的过程中，流程图或控制流图是分析的好帮手。5、搭建单元测试环境使用工具或自己写的框架将有助于单元测 试的实施。在这个阶段主要就是写桩模块和驱动 模块，第4步所设计的测试用例是通过驱动模块 传递给被测试模块的，然后驱动模块想办法获取 被测试模块对数据的处理结果，并判定返回的实 际结果与测试用例的预期结果是否一致， 通过测 试框架来记录执行的结果，对于出现的错误，还 需要统计错误的信息，供执行完之后分析。6、执行测试运行写好的驱动模块完成对被测试模块的 测试。7、补充

7、和完善测试用例单元测试也是个循序渐进的过程，可能一开 始考虑的不够全面，或预期的覆盖标准太低，需 要在测试过程中不断补充测试用例，直到满足要 求为止。8分析结果，给出评价根据测试的结果分析、查找错误的原因，并 找到解决的办法。测试结束之后，根据测试过程 的数据统计，给出被测试对象评价22测试通过打回标准1、通过标准2、打回标准2.3、阶段的输出输入：最新SRS项目计划、详细设计 输出：单元测试计划、单元测试用例、单元 测试总结分析。3、系统测试流程系统测试是将已经确认的软件、计算机硬 件、外设、网络等其他元素结合在一起，进行信 息系统的各种组装测试和确认测试，系统测试是 针对整个产品系统进行的

8、测试，目的是验证系统 是否满足了需求规格的定义，找出与需求规格不 符或与之矛盾的地方，从而提出更加完善的方 案。系统测试发现问题之后要经过调试找出错误 原因和位置，然后进行改正。是基于系统整体需 求说明书的黑盒类测试，应覆盖系统所有联合的 部件。对象不仅仅包括需测试的软件， 还要包含 软件所依赖的硬件、外设甚至包括某些数据、某 些支持软件及其接口等。3.1步骤说明1、测试组收到测试任务通知书，告知较为 确切的测试内容、日期。2、根据最新SRS和各设计文档，将已经确 认的软件、计算机硬件、外设、网络等其他元素 结合在一起，针对整个产品系统进行的测试。3、编写此阶段系统测试方案，通过评审， 优化系

9、统测试方案。4、然后编写或补充系统测试用例，用例完 成后，需要通过评审，优化系统测试用例。5、执行冒烟测试用例，测试版本仅少量严重程度低的bug未修改引起的不通过，反馈项目 组，通知延长冒烟测试时间；测试版本符合冒烟 测试打回标准，冒烟测试不通过，直接打回或挂 起，结束测试。测试完成度满足冒烟测试开始条 件，重新发起测试申请。6、当不通过时，退回或挂起。7、当完成冒烟测试后，进行系统测试，提 交bug报告，审核bug，当审核未通过时，补充 测试用例，当审核通过汇总 bug，总结报告。8当开发人员完成缺陷的修改后，提交新 的版本，测试人员继续开始做回归测试。当测试版本仅少量bug未修改引起的不通

10、 过，反馈项目组，通知延长系统测试时间；测试版本符合系统测试打回标准，系统测试 不通过，直接打回，结束测试。待测试完成度满 足系统测试开始条件，重新发起测试申请。9、当缺陷的统计曲线出现的逐渐收敛，并 且得到控制。10、分析缺陷的原因。11、提交测试报告。12、进入下一阶段。3.2测试通过打回标准 1）通过标准 2）打回标准3.3、阶段的输出输入：最新SRS项目计划、详细设计 输出：系统测试计划、系统测试用例、测试4.1步骤说明1、验收测试进入准则1）软件产品通过单元测试、集成测试和系 统测试。2）项目组提交以下测试文档：测试计划、 测试用例、测试日志、测试通知单、测试分析报 告。3）待验收的

11、软件安装程序。2、测试错误类型参考软件测试停止标准.doc3、对用户手册和帮助的验收规定1）用户手册和帮助的编制要使用非专门术 语的语言，充分地描述该软件系统所具有的功能 及基本的使用方法。2）使用户（或潜在用户）通过用户手册能 够了解该软件的用途，并且能够确定在什么情况 下，如何使用它。3）语句通顺、简洁，语义明确，错别字小 于 0.1%。4）对相关名词解释应易于被用户理解。5）对相关界面的说明要符合操作流程并将 每一项功能解释完整、清楚。6）保证用户手册、帮助能够正确指导用户使用软件4、软件验收测试合格通过准则1）软件需求分析说明书中定义的所有功能 已全部实现，性能指标全部达到要求。2）所

12、有测试项必须符合以下标准：（以下比例为错误占总测试模块的比例）级错误级错误级错误四级错误五 级错误无无2%3%暂不做要求3）需求分析文档、设计文档和编码实现一致。4）用户手册及帮助符合对用户手册及帮助 的验收规定（编写人在责任认定书上签字时对于 软件产品的各项功能描述、名词解释、结构、语 句表达等方面均要保证其正确性并加以说明）5）验收测试文档齐全（见验收测试进入准 则）。6）以上五条其中之一不满足要求，视为不 合格。三、缺陷管理3.1缺陷定义软件缺陷（Defect），常常又被叫做Bugc 所谓软件缺陷，即为计算机软件或程序中存在的 某种破坏正常运行能力的问题、 错误，或者隐藏 的功能缺陷。具

13、体归纳为以下这些问题。1、软件没有达到需求规格说明书中表明的 功能；2、软件出现了需求规格说明书中不一致的 表现；3、软件功能超出需求规格说明书的范围；4、软件没有达到用户期望的目标（虽然需求 规格说明书中没有要求）；5、测试员或用户认为软件的易用性差。3.2缺陷的修复在实际项目中不是所有的缺陷都会修改，具 体见以下情况：1、市场的压力使得产品最终发行有时间限 制；2、测试员错误理解或者不正确操作引出的 缺陷；3、错误的修改影响的模块较多，带来的风 险较大；4、缺陷报告中提出的问题很难重现；5、修改性价比太低。3.3缺陷的分类标准一旦发现软件缺陷，就要设法找到引起这个 缺陷的原因，分析对产品质量的影响，然后确定 软件缺陷的严重性和处理这个缺陷的优先级。各 种缺陷所造成的后果是不一样的，有的仅仅是不 方便，有的可能是灾难性的。一般问题越严重， 其处理优先级就越高，可以概括为以下五种级 别：缺陷严重等级描述5严重缺 陷不能执行正常工作功能或重要 功能。使系统崩溃或资源严重不 足。1、由于程序所引起的死机，非法 退出；2、死循环；3、数据库发生死锁；4、错误操作导致的程序中断；5、严重的计算错误；6、与数据库连接错误；7、数据通讯错误。4较严重 缺陷严重地影响系统要求或基本功 能的实现，且没有办法更正。1、功能不符；2、程序接口错误；3、数据流错误；4、轻微