软件测试流程及规范V1

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）软件需求分析说明书中定义的所有功能 已全部实现，性能指标全部达到要求

12、。2）所有测试项必须符合以下标准：（以下比例为错误占总测试模块的比例）级错误级错误级错误四级错误五 级错误无无<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缺陷的分类标准一旦发现软件缺陷，就要设法找到引起这个

14、缺陷的原因，分析对产品质量的影响，然后确定 软件缺陷的严重性和处理这个缺陷的优先级。各 种缺陷所造成的后果是不一样的，有的仅仅是不 方便，有的可能是灾难性的。一般问题越严重， 其处理优先级就越高，可以概括为以下五种级 别：缺陷严重等级描述5严重缺 陷不能执行正常工作功能或重要 功能。使系统崩溃或资源严重不 足。1、由于程序所引起的死机，非法 退出；2、死循环；3、数据库发生死锁；4、错误操作导致的程序中断；5、严重的计算错误；6、与数据库连接错误；7、数据通讯错误。4较严重 缺陷严重地影响系统要求或基本功 能的实现，且没有办法更正。1、功能不符；2、程序接口错误；3、数据流错误；4、轻微数据计

15、算错误。,3一般性 缺陷严重地影响系统要求或基本功 能的实现，但存在合理的更正办 法。1、界面错误（附详细说明）；2、打印内容、格式错误；3、简单的输入限制未放在前台 进行控制；4、删除操作未给出提示；5、数据输入没有边界值限定或 不合理。2较小缺 陷使操作者不方便或遇到麻烦，但 它不影响执行工作或功能实现。1、辅助说明描述不清楚；2、显示格式不规范；3、系统处理未优化；4、长时间操作未给用户进度提 示；5、提示窗口文字未采用行业术 语。1其它缺 陷1、建议2、其它错误3.3缺陷的流程目前分公司的缺陷管理使用的是QualityCenter9.0，具体安装和使用细节，见使用手册。 在使用时遵循以

16、下的流程，即缺陷的生命周期。发人为贡现augEew）H占一丢押煎匚盂警莓确认哑A-是+45bugS 肉 t oper 疔戛g盘为RepcWd流程中缺陷存在以下6种状态： 提交bug状态（NeW：开发人员或测试人员发现bug,记录在系统里。激活状态（Open>:当项目经理或负责人觉 得这个bug是问题，将bug置为此状态。驳回状态（Rejected ：:当项目经理或负责 人觉得这个bug不是问题，则可以驳回，将bug 置为此状态。已修正状态（Fixed ）:开发人员针对缺陷，修正软件后已解决问题或通过单元测试关闭状态(Close):测试人员经过验证后， 确认缺陷不存在之后的状态。重新激活状

17、态(Reopen):测试人员经过验 证后，确认此缺陷存在，之后将其置为此状态。四、关于单元测试1、首先应该明确单元的含义。单元在面向 对象的程序中指的是一个类，在结构化的方法中 指的是一个函数。2、其次应该明确单元测试的方法。单元测 试的常用方法包括：(1) 静态检查，即采用静态代码检查的工具 对程序进行内部逻辑的分析，以分析程序中可能 的错误。(2) 动态测试，通过编写单元测试程序，设 计单元测试用例，测试每个函数或每个类的逻辑 正确性。3、如果一个类或一个函数对其他的类或环 境依赖性很强，需要编写大量的桩程序或驱动程 序，那恰恰说明了这个类或这个函数的设计有问 题，违背了“低耦合”的基本设

18、计原则，这也正 式敏捷方法中提倡的“测试驱动开发"的作用之O4、质量的投入产出也是一种平衡，需要在单元测试上投入到什么程度首先是公司的一个 管理方针。如果每个单元都进行单元测试则测试 代码的规模和产品代码的规模能够达到1:1，也就是说编写测试代码的工作量还是比较大的， 但是也要看到单元测试的产出。在单元测试、集 成测试、系统测试中，单元测试是投入产出比最 大的测试种类，即单元测试在单位时间内发现的 缺陷个数大于集成与系统测试。原则上单元测试 的投入最大，找到的缺陷最多，集成测试与系统 测试依次递减。5、在实践中推广单元测试时可以采用如下 的方法：1）、加大静态检查的力度。通过静态检查

19、的 工具快速地识别程序中的错误、 警告，公司可以 规定对检查出的哪些警告、错误必须进行修改， 注意如果修改所有的警告、错误可能工作量比较 大。静态检查是一种投入产出比很高的单元测试 方法。在JAVA下可以采用check Style, Source monitor， PMD Find Bugs，Jslink 等。2）、通过测试策略的选择减少测试程序的工 作量。单元测试一般有三种策略：策略一：自底向上的策略：先测底层的函数 或类，再测上层的函数或类，此时只需要编写驱 动程序，不需要编写桩程序。策略二：自顶向下的策略：先测上层的函数 或类，再测试底层的函数类，此时只需要编写桩 程序，不需要或很少需要

20、编写驱动程序。策略三：混合策略：综合上述的 2种策略, 需要综合编写桩程序与驱动程序。如果被测的单元需要调用很多其他的单元， 则可以采用自底向上的策略减少驱动程序的编 写量。如果被测的单元需要很多外围的环境准备 则可以采用自顶向下的策略。3）、在组织级可以规定执行单元测试的时机 比如：a）系统中最核心的、最关键的功能模块；b）算法复杂的功能模块；c）出错最多的功能模块；d）客户最常使用的功能模块；e）复用的底层代码；根据Pareto定律，我们可以选择少部分代 码执行单元测试。6、单元测试的技术1）、JUnit的工具2）、生成测试用例时可以采用如下的方法：a）单元功能分析b）入口参数等价类分析c

21、）入口参数边界分析d）全程变量、共享数据的等价类与边界分 析e）调用函数返回值的等价类与边界分析f）覆盖率分析上述的方法要求的严格程度可以循序渐进 不能的严格程度需要投入的工作量不同。7、单元测试完成后，编写软件评定书。五、通用检查点见附件：公共测试用例.xlsx六、常见缺陷分类见附件：缺陷分类.xlsx七、评审工作一、审批过程评审的通用过程由如下6个阶段组成：1、计划阶段：选择评审员并分配角色、为正式 的评审类型（如审查）规定评审的入口和出口准 则，以及选择需要评审的文档或文档章节等。2、预备会阶段：分发文档，向评审参与者解释 本次评审的目标、过程和文档，以及核对入口准 则（针对正式的评审类

22、型）。3、个人准备阶段：在评审会议之前每位评审参 与者准备各自的评审工作，标注评审对象中可能 的缺陷、冋题和建议等。4、评审会议阶段：讨论评审员提交的问题列表， 并形成会议纪要（针对正式的评审类型）。会议 参与者可以标识缺陷并提出处理建议。5、返工阶段：修复评审过程中发现的缺陷，通 常由作者完成。6、跟踪结果阶段：检查缺陷是否已经解决，收 集度量数据并评估出口准则（针对正式的评审类 型）。二、审批中涉及的主要角色经理、主持人或组长、作者、评审员和记录 员，其他可能涉及包括决策者或者其他利益相关 者，如用户代表；另外一个可选的角色有时会出 现在审查中，即宣读员，在评审会议中宣读产品 的某些部分。

23、三、审批遵循原则评审遵循原则1、尽早的开展评审。2、控制评审会议的时间。3、评审的是软件产品而不是作者。4、每个评审员都必须有机会充分地表达各 自的观点，并且评审会议纪要必须完整地记录每 个评审员的意见和建议。5、发现缺陷，而不是修复缺陷。评审会议 关注的是发现被评审对象中的缺陷，而尽量避免 讨论针对缺陷的可能解决方案和方法， 提出解决 方案及其对应的讨论不应该是评审会议的关注点。6、评审过程中发现的缺陷和问题，应该划 分为不同的严重程度级别。1）严重缺陷：评审对象不能满足其目标， 在批准评审对象之前必须修复相关缺陷。2）重要缺陷：影响评审对象的可用性，批 准评审对象之前应该修复相关缺陷。3）

24、一般缺陷：小的偏差，基本不影响使用。4）好的：没有缺陷，返工时无须修改。7、评审团队最后应该对评审对象给出如下 评审意见。1）接受：文档、软件产品不需要修改或者只要微小的修改2）有条件接受：文档、软件产品需要修改， 但是不需要进一步评审。3）不接受：文档、软件产品需要深入修改， 并且需要重新评审或者其他检查措施。四、审批类型评审可以是正式或非正式的。基于IEEEStd1028-2008软件评审和审计标准，分为 审查、技术评审、走查、非正式评审、管理评审 和审计等评审类型。1、审查。目的：这是一种系统的同行检查方法， 检查 并发现软件产品中的缺陷。主要关注软件产品是 否满足规格说明及其是否体现了

25、特定的质量特 性，以及是否满足了规范、标准、指南、计划、 规格说明和规程等要求，并识别其中存在的差 异。参与人员：审查一般由2至6个人参与， 包括作者。角色主要有主持人、记录员、宣读员、 作者和审查员。度量数据：检查表结果输出：确定补救措施或调查活动。注：审查会议上并不讨论解决方案。收集相关数据并定期分析：数据包括被审查 的软件产品、审查召开的日期、审查参与的成员、 审查员准备的时间、审查会议的时间、审查对象 规模和审查结果等。通过分析优化审核本身的过 程，并改进生成软件产品的过程。2、技术评审目的：为了评估软件产品是否满足预期的使 用要求，识别软件产品和规格说明与标准之间不 一致的地方。方式

26、：同行间小组讨论活动，主要为了对测 试对象所采用的技术实现方法达成共识。参与人员：包括决策者、评审主持人、记录 员和技术评审员，也可以包括项目的其他利益相 关者，如客户代表。输入：相关的规范、标准、计划和规格说明 之外，评审检查表与缺陷分类等也是重要的内 容。输出：其中主要包括技术评审的对象、 参与 技术评审的成员名单、技术评审的目标、技术评 审的相关输入、评审得到的软件产品缺陷列表、 管理问题列表、应对活动列表（应对活动的状态、 负责人、完成的目标时间与完成的实际时间等） 和评审团队得到的建议列表，并且判断软件产品 是否满足了规范和标准等的要求。3、走查目的：1）发现缺陷。2）改善软件工作产

27、品。3）讨论软件工作产品的替换方案。4）评估和标 准及规格说明等的一致性。5）评估软件产品的 可用性。6）培训参与者。参与人员：包括走查主持人、记录员、作者 与走查员等。度量数据：检查表收集相关数据并定期分析：数据包括被走查 的软件产品、走查开始的日期、走查参与的成员、 走查员准备的时间、走查会议的时间、走查对象 规模和走查对象的走查结果等。通过分析优化走 查本身的过程，并改进生成软件产品的过程。4、非正式评审非正式评审是一种不基于正式（文档化）过 程的评审，它是评审的精简版，在某种程度上遵 循通用的评审过程。通常情况下，由作者发起非 正式评审。评审计划限定于选择评审员和要求他 们在指定时间点

28、提交意见和建议。非正式评审通 常不召开会议和相互交换意见，只是作者和评审 员之间的交互。非正式评审可以是一种由一个或 多个同事完成的交叉阅读，其结果不需要明确的 文档化，有时一个评审清单或修订文档就足够 了。结对编程、结对测试和代码交换等都是非正 式评审的方式，非正式评审非常普遍，并且由于 工作量小而被广泛接受。五、如何开展审批活动被评审的产品应当符合相应条件（如审查需 要满足一定的评审入口准则），同时不同的评审 对象需要不同的评审员参与。如下表：文档名称作者评审员需求规格说 明书系统人员项目经理、架构师、测试 组人员测试计划测试组人 员开发经理、架构师、测试 组测试设计规 格说明书测试组人

29、员开发经理、架构师、测试 组测试用例测试组人 员开发经理、测试组测试报告测试组人 员项目经理、开发经理、测 试组其中的评审员，如功能开发经理，可以指定 符合要求的开发人员代替其参与评审活动。评审 对象的“作者” 一栏中列出了该文档的主要责任 人，有的文档可能需要多个项目人员共同完成， 作者可能有多人。为了成功地将评审引入到项目和组织中， 需 要采取以下措施。1、获得管理层支持：评审需要时间和资源， 如评审员的时间计划、工作量计划、评审需要的 基础设施和设备等，这些都需要组织管理层的支 持。2、管理人员培训：早期发现和修复缺陷可 以节约时间和降低成本。管理人员必须意识到学 习新的评审技术是一项投

30、资，其收益不是立即可 见的，随着时间的推移会越来越明显地显现出 来。管理人员需要在评审成本、利益和执行方面 进行有效的平衡。3、正规的评审过程：组织内定义并文档化 评审步骤，定义不同的评审类型和评审过程中不 同的角色和职责，并对评审过程定义合适的监控 手段和形式。通过评审过程的监控和改进提供评 审的度量数据（如评审的效率和发现缺陷的分布等）。4、开展评审技术和规程的培训：根据项目 特点和评审类型开展评审技术和规程的培训，更 好地让评审参与人员了解评审的目的、 评审的过 程及评审的作用和意义，从而更加有效地开展评 审，而不是作为过程的一部分流于形式.5、获得评审员和评审对象作者的支持：评 审要求评审对象的作者提供合适的评审资料，以 满足评审的入口准则。并且需要评审员具备合适 的专业技能和知识，拥有足够的能力完成评审工 作。6、评审最重要的文档：由于软件开发的时 间和资源有限，因此需要将评审用于最重要的文 档（如需求、合同和计划等）。正式而严格的评审包括6个阶段，即计划 阶段、预备会阶段、个人准备阶段、评审会议阶 段、返工阶段和跟踪结果阶段。1、计划阶段