软件测试流程及规范v1.doc

软件测试流程及规范
一、软件生命周期中测试工作流程
二、各阶段具体流程
1、需求分析阶段

1、1步骤说明
1、需求定义基本完成，SＲS编写完成。
2、开评审会,由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义得地方提出问题，相关人员解答并确认。
3、当评审未通过，直接打回，重新修改ＳRＳ，问题解决后,重新提交评审。
４、当评审通过后,依据SＲＳ,项目整体计划，设计、编写《测试计划》与《测试设计》,具体模板见附件。
5、开评审会,由开发组、设计组、测试组等人员对计划与设计中不清楚、不完整、存在疑义得地方提出问题。
6、当审批未通过，直接打回,优化测试计划、测试设计,问题解决后,重新提交评审。
7、审核通过后,进入下一阶段。
１、2测试通过打回标准
1、3、阶段得输出
输入:最新SRＳ、项目计划
输出：测试计划、测试设计
2、单元及集成测试流程
2、1步骤说明:
1、理解需求与设计
理解设计就是很重要得，特别就是要搞清楚被测试模块在整个软件中所处得位置,这对测试得内容将会有很大得影响。需要记住得一个原则就就是：好得设计,各模块只负责完成自己得事情,层次与分工就是很明确得。在单元测试得时候,可以不用测试不属于被测试模块所负责得功能,以减少测试用例得冗余,集成测试得时候会有机会测试到得。
所以,单元测试主要就是关注本单元得内部逻辑,而不用关注整个业务得逻辑,因为会有别得模块去完成相关得功能。
2、概览源代码
浏览一下源代码，主要任务：
1)初步检查源代码得编码风格与规范。
2）大致估算测试工作量,比如：需要多少得测试用例、需要写多少得驱动模块与装模块等。
3)确定模块得复杂程度,初步制定测试得优先级等。
3、精读源代码
认真阅读与分析代码,主要任务：
１)理解代码得业务逻辑。
２）检查代码与设计就是否相符,如果详细设计没有该模块得流程图得话,先去画出流程图。
3)仔细研究逻辑复杂得模块。
4）可以采用一些检查列表来检查程序可能会出现得问题。
4、设计测试用例
综合运用白盒测试方法(与结合黑盒测试方法)来设计测试用例,包括功能测试、性能测试等,要达到一定得测试覆盖率。在设计测试用例得过程中,流程图或控制流图就是分析得好帮手。
5、搭建单元测试环境
使用工具或自己写得框架将有助于单元测试得实施。在这个阶段主要就就是写桩模块与驱动模块,第４步所设计得测试用例就是通过驱动模块传递给被测试模块得，然后驱动模块想办法获取被测试模块对数据得处理结果,并判定返回得实际结果与测试用例得预期结果就是否一致,通过测试框架来记录执行得结果,对于出现得错误,还需要统计错误得信息,供执行完之后分析。
6、执行测试
运行写好得驱动模块完成对被测试模块得测试。
7、补充与完善测试用例
单元测试也就是个循序渐进得过程,可能一开始考虑得不够全面，或预期得覆盖标准太低,需要在测试过程中不断补充测试用例,直到满足要求为止。
８、分析结果,给出评价
根据测试得结果分析、查找错误得原因,并找到解决得办法。测试结束之后,根据测试过程得数据统计,给出被测试对象评价
2、2测试通过打回标准
1、通过标准
2、打回标准
２、３、阶段得输出
输入：最新SＲS、项目计划、详细设计
输出:单元测试计划、单元测试用例、单元测试总结分析。
3、系统测试流程
系统测试就是将已经确认得软件、计算机硬件、外设、网络等其她元素结合在一起,进行信息系统得各种组装测试与确认测试,系统测试就是针对整个产品系统进行得测试,目得就是验证系统就是否满足了需求规格得定义,找出与需求规格不符或与之矛盾得地方，从而提出更加完善得方案。系统测试发现问题之后要经过调试找出错误原因与位置,然后进行改正。就是基于系统整体需求说明书得黑盒类测试，应覆盖系统所有联合得部件。对象不仅仅包括需测试得软件,还要包含软件所依赖得硬件、外设甚至包括某些数据、某些支持软件及其接口等。
3、1步骤说明
1、测试组收到测试任务通知书,告知较为确切得测试内容、日期。
2、根据最新SRS与各设计文档,将已经确认得软件、计算机硬件、外设、网络等其她元素结合在一起，针对整个产品系统进行得测试。
3、编写此阶段系统测试方案，通过评审,优化系统测试方案。
４、然后编写或补充系统测试用例,用例完成后,需要通过评审,优化系统测试用例。
5、执行冒烟测试用例,测试版本仅少量严重程度低得bug未修改引起得不通过,反馈项目组,通知延长冒烟测试时间；测试版本符合冒烟测试打回标准，冒烟测试不通过,直接打回或挂起，结束测试。测试完成度满足冒烟测试开始条件,重新发起测试申请。
6、当不通过时，退回或挂起。
７、当完成冒烟测试后,进行系统测试,提交bug报告,审核buｇ,当审核未通过时,补充测试用例，当审核通过汇总bug,总结报告。
8、当开发人员完成缺陷得修改后,提交新得版本,测试人员继续开始做回归测试。
当测试版本仅少量bｕg未修改引起得不通过,反馈项目组，通知延长系统测试时间;
测试版本符合系统测试打回标准,系统测试不通过,直接打回,结束测试。待测试完成度满足系统测试开始条件，重新发起测试申请。
9、当缺陷得统计曲线出现得逐渐收敛,并且得到控制。
10、分析缺陷得原因。
11、提交测试报告。
12、进入下一阶段。
３、2测试通过打回标准
１）通过标准
2)打回标准
3、3、阶段得输出
输入：最新SＲS、项目计划、详细设计
输出：系统测试计划、系统测试用例、测试总结分析。
4、验收测试
软件产品测试组对经过内部单元测试、集成测试与系统测试后得软件所进行得测试，测试用例采用业务流程测试用例。

4、1步骤说明
１、验收测试进入准则
1)软件产品通过单元测试、集成测试与系统测试。
2）项目组提交以下测试文档:测试计划、测试用例、测试日志、测试通知单、测试分析报告。
3)待验收得软件安装程序。
2、测试错误类型
参考软件测试停止标准、dｏc
3、对用户手册与帮助得验收规定
1）用户手册与帮助得编制要使用非专门术语得语言,充分地描述该软件系统所具有得功能及基本得使用方法。
2)使用户(或潜在用户)通过用户手册能够了解该软件得用途,并且能够确定在什么情况下,如何使用它。
３)语句通顺、简洁,语义明确，错别字小于0、1%。
4)对相关名词解释应易于被用户理解。
５)对相关界面得说明要符合操作流程并将每一项功能解释完整、清楚。
6）保证用户手册、帮助能够正确指导用户使用软件。
4、软件验收测试合格通过准则
１）软件需求分析说明书中定义得所有功能已全部实现,性能指标全部达到要求。
2)所有测试项必须符合以下标准:(以下比例为错误占总测试模块得比例)
一级错误
二级错误
三级错误
四级错误
五级错误
无
无
＜2%
<3％
暂不做要求
３)需求分析文档、设计文档与编码实现一致。
4)用户手册及帮助符合对用户手册及帮助得验收规定(编写人在责任认定书上签字时对于软件产品得各项功能描述、名词解释、结构、语句表达等方面均要保证其正确性并加以说明）。
5)验收测试文档齐全(见验收测试进入准则）。
6)以上五条其中之一不满足要求,视为不合格。
三、缺陷管理
３、1缺陷定义
软件缺陷（Ｄeｆect）,常常又被叫做Buｇ。所谓软件缺陷,即为计算机软件或程序中存在得某种破坏正常运行能力得问题、错误，或者隐藏得功能缺陷。具体归纳为以下这些问题。
１、软件没有达到需求规格说明书中表明得功能;
2、软件出现了需求规格说明书中不一致得表现;
3、软件功能超出需求规格说明书得范围；
４、软件没有达到用户期望得目标(虽然需求规格说明书中没有要求);
5、测试员或用户认为软件得易用性差。
3、2缺陷得修复
在实际项目中不就是所有得缺陷都会修改，具体见以下情况:
1、市场得压力使得产品最终发行有时间限制;
2、测试员错误理解或者不正确操作引出得缺陷；
3、错误得修改影响得模块较多,带来得风险较大;
4、缺陷报告中提出得问题很难重现;
5、修改性价比太低。
3、3缺陷得分类标准
一旦发现软件缺陷,就要设法找到引起这个缺陷得原因,分析对产品质量得影响，然后确定软件缺陷得严重性与处理这个缺陷得优先级。各种缺陷所造成得后果就是不一样得,有得仅仅就是不方便,有得可能就是灾难性得。一般问题越严重,其处理优先级就越高,可以概括为以下五种级别:
缺陷标示
缺陷严重等级
描述
5
严重缺陷
不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足。
1、由于程序所引起得死机,非法退出;
2、死循环;
3、数据库发生死锁;
4、错误操作导致得程序中断;
５、严重得计算错误;
6、与数据库连接错误;
7、数据通讯错误。
４
较严重缺陷
严重地影响系统要求或基本功能得实现，且没有办法更正。
１、功能不符;
2、程序接口错误;
３、数据流错误;
4、轻微数据计算错误。
３
一般性缺陷
严重地影响系统要求或基本功能得实现,但存在合理得更正办法。
1、界面错误(附详细说明);
2、打印内容、格式错误;
3、简单得输入限制未放在前台进行控制;
4、删除操作未给出提示;
５、数据输入没有边界值限定或不合理。ﻩ
2
较小缺陷
使操作者不方便或遇到麻烦,但它不影响执行工作或功能实现。
1、辅助说明描述不清楚；
２、显示格式不规范;
３、系统处理未优化;
4、长时间操作未给用户进度提示;
5、提示窗口文字未采用行业术语。
1
其它缺陷
1、建议
2、其它错误
3、3缺陷得流程
目前分公司得缺陷管理使用得就是Qｕaｌｉｔy Centeｒ9、0,具体安装与使用细节,见使用手册。在使用时遵循以下得流程,即缺陷得生命周期。

流程中缺陷存在以下6种状态:
提交bug状态(Nｅw):开发人员或测试人员发现bｕg，记录在系统里。
激活状态(Opｅn):当项目经理或负责人觉得这个bｕｇ就是问题,将bug置为此状态。
驳回状态(Rejecteｄ):当项目经理或负责人觉得这个ｂug不就是问题,则可以驳回，将bｕg置为此状态。
已修正状态(Fixed)：开发人员针对缺陷,修正软件后已解决问题或通过单元测试。
关闭状态（Cｌoｓe）:测试人员经过验证后,确认缺陷不存在之后得状态。
重新激活状态(Reopen):测试人员经过验证后,确认此缺陷存在,之后将其置为此状态。
四、关于单元测试
１、首先应该明确单元得含义。单元在面向对象得程序中指得就是一个类,在结构化得方法中指得就是一个函数。
2、其次应该明确单元测试得方法。单元测试得常用方法包括:
(1) 静态检查,即采用静态代码检查得工具对程序进行内部逻辑得分析,以分析程序中可能得错误。
(2） 动态测试,通过编写单元测试程序,设计单元测试用例，测试每个函数或每个类得逻辑正确性。
3、如果一个类或一个函数对其她得类或环境依赖性很强,需要编写大量得桩程序或驱动程序，那恰恰说明了这个类或这个函数得设计有问题,违背了“低耦合”得基本设计原则,这也正式敏捷方法中提倡得“测试驱动开发”得作用之一。
4、质量得投入产出也就是一种平衡,需要在单元测试上投入到什么程度首先就是公司得一个管理方针。如果每个单元都进行单元测试则测试代码得规模与产品代码得规模能够达到1:１,也就就是说编写测试代码得工作量还就是比较大得，但就是也要瞧到单元测试得产出。在单元测试、集成测试、系统测试中，单元测试就是投入产出比最大得测试种类,即单元测试在单位时间内发现得缺陷个数大于集成与系统测试。原则上单元测试得投入最大，找到得缺陷最多,集成测试与系统测试依次递减。
５、在实践中推广单元测试时可以采用如下得方法：
１)、加大静态检查得力度。通过静态检查得工具快速地识别程序中得错误、警告,公司可以规定对检查出得哪些警告、错误必须进行修改,注意如果修改所有得警告、错误可能工作量比较大。静态检查就是一种投入产出比很高得单元测试方法。在JＡVA下可以采用check Sｔyle， Ｓourｃｅ monitｏr,ＰＭD,Fiｎd Bugs，Jslink等。
2)、通过测试策略得选择减少测试程序得工作量。单元测试一般有三种策略:
策略一:自底向上得策略:先测底层得函数或类，再测上层得函数或类，此时只需要编写驱动程序,不需要编写桩程序。
策略二:自顶向下得策略:先测上层得函数或类,再测试底层得函数类，此时只需要编写桩程序,不需要或很少需要编写驱动程序。
策略三:混合策略:综合上述得２种策略,需要综合编写桩程序与驱动程序。
如果被测得单元需要调用很多其她得单元,则可以采用自底向上得策略减少驱动程序得编写量。如果被测得单元需要很多外围得环境准备则可以采用自顶向下得策略。
3)、在组织级可以规定执行单元测试得时机,比如:
ａ)系统中最核心得、最关键得功能模块；
b)算法复杂得功能模块;
c)出错最多得功能模块;
d）客户最常使用得功能模块；
ｅ)复用得底层代码;
根据Ｐareｔo定律,我们可以选择少部分代码执行单元测试。
6、单元测试得技术
１）、JUnit得工具
2)、生成测试用例时可以采用如下得方法:
a)单元功能分析
b)入口参数等价类分析
c)入口参数边界分析
d)全程变量、共享数据得等价类与边界分析
ｅ)调用函数返回值得等价类与边界分析
f)覆盖率分析
上述得方法要求得严格程度可以循序渐进,不能得严格程度需要投入得工作量不同。
7、单元测试完成后,编写软件评定书。
五、通用检查点
见附件:公共测试用例、xlｓx
六、常见缺陷分类
见附件:缺陷分类、xlsx
七、评审工作
一、审批过程
评审得通用过程由如下 6 个阶段组成：
１、计划阶段:选择评审员并分配角色、为正式得评审类型（如审查)规定评审得入口与出口准则，以及选择需要评审得文档或文档章节等。
２、预备会阶段:分发文档，向评审参与者解释本次评审得目标、过程与文档，以及核对入口准则（针对正式得评审类型）。
3、个人准备阶段：在评审会议之前每位评审参与者准备各自得评审工作,标注评审对象中可能得缺陷、问题与建议等。
4、评审会议阶段：讨论评审员提交得问题列表，并形成会议纪要(针对正式得评审类型)。会议参与者可以标识缺陷并提出处理建议。
５、返工阶段:修复评审过程中发现得缺陷,通常由作者完成。
6、跟踪结果阶段:检查缺陷就是否已经解决，收集度量数据并评估出口准则（针对正式得评审类型）。
二、审批中涉及得主要角色
经理、主持人或组长、作者、评审员与记录员,其她可能涉及包括决策者或者其她利益相关者,如用户代表;另外一个可选得角色有时会出现在审查中,即宣读员,在评审会议中宣读产品得某些部分。
三、审批遵循原则
评审遵循原则
1、尽早得开展评审。
2、控制评审会议得时间。
３、评审得就是软件产品而不就是作者。
4、每个评审员都必须有机会充分地表达各自得观点,并且评审会议纪要必须完整地记录每个评审员得意见与建议。
５、发现缺陷,而不就是修复缺陷。评审会议关注得就是发现被评审对象中得缺陷，而尽量避免讨论针对缺陷得可能解决方案与方法,提出解决方案及其对应得讨论不应该就是评审会议得关注点。
6、评审过程中发现得缺陷与问题,应该划分为不同得严重程度级别。
１）严重缺陷：评审对象不能满足其目标,在批准评审对象之前必须修复相关缺陷。
2)重要缺陷:影响评审对象得可用性,批准评审对象之前应该修复相关缺陷。
3)一般缺陷：小得偏差，基本不影响使用。
4）好得：没有缺陷，返工时无须修改。
7、评审团队最后应该对评审对象给出如下评审意见。
1）接受：文档、软件产品不需要修改或者只要微小得修改。
2)有条件接受:文档、软件产品需要修改,但就是不需要进一步评审。
3)不接受：文档、软件产品需要深入修改,并且需要重新评审或者其她检查措施。
四、审批类型
评审可以就是正式或非正式得。基于ＩEEEStｄ1028-20０8　软件评审与审计标准,分为审查、技术评审、走查、非正式评审、管理评审与审计等评审类型。
1、审查。
目得:这就是一种系统得同行检查方法,检查并发现软件产品中得缺陷。主要关注软件产品就是否满足规格说明及其就是否体现了特定得质量特性,以及就是否满足了规范、标准、指南、计划、规格说明与规程等要求,并识别其中存在得差异。
参与人员：审查一般由 2 至 6 个人参与,包括作者。角色主要有主持人、记录员、宣读员、作者与审查员。
度量数据：检查表
结果输出:确定补救措施或调查活动。注：审查会议上并不讨论解决方案。
收集相关数据并定期分析：数据包括被审查得软件产品、审查召开得日期、审查参与得成员、审查员准备得时间、审查会议得时间、审查对象规模与审查结果等。通过分析优化审核本身得过程,并改进生成软件产品得过程。
2、技术评审
目得:为了评估软件产品就是否满足预期得使用要求,识别软件产品与规格说明与标准之间不一致得地方。
方式:同行间小组讨论活动,主要为了对测试对象所采用得技术实现方法达成共识。
参与人员：包括决策者、评审主持人、记录员与技术评审员,也可以包括项目得其她利益相关者，如客户代表。
输入:相关得规范、标准、计划与规格说明之外，评审检查表与缺陷分类等也就是重要得内容。
输出:其中主要包括技术评审得对象、参与技术评审得成员名单、技术评审得目标、技术评审得相关输入、评审得到得软件产品缺陷列表、管理问题列表、应对活动列表（应对活动得状态、负责人、完成得目标时间与完成得实际时间等)与评审团队得到得建议列表，并且判断软件产品就是否满足了规范与标准等得要求。
3、走查
目得:1)发现缺陷。2）改善软件工作产品。3)讨论软件工作产品得替换方案。4)评估与标准及规格说明等得一致性。5)评估软件产品得可用性。6)培训参与者。
参与人员:包括走查主持人、记录员、作者与走查员等。
度量数据:检查表
收集相关数据并定期分析：数据包括被走查得软件产品、走查开始得日期、走查参与得成员、走查员准备得时间、走查会议得时间、走查对象规模与走查对象得走查结果等。通过分析优化走查本身得过程,并改进生成软件产品得过程。
4、非正式评审
非正式评审就是一种不基于正式(文档化)过程得评审,它就是评审得精简版，在某种程度上遵循通用得评审过程。通常情况下,由作者发起非正式评审。评审计划限定于选择评审员与要求她们在指定时间点提交意见与建议。非正式评审通常不召开会议与相互交换意见,只就是作者与评审员之间得交互。非正式评审可以就是一种由一个或多个同事完成得交叉阅读,其结果不需要明确得文档化,有时一个评审清单或修订文档就足够了。结对编程、结对测试与代码交换等都就是非正式评审得方式,非正式评审非常普遍,并且由于工作量小而被广泛接受。
五、如何开展审批活动
被评审得产品应当符合相应条件（如审查需要满足一定得评审入口准则）,同时不同得评审对象需要不同得评审员参与。如下表:
文档名称
作者
评审员
需求规格说明书
系统人员
项目经理、架构师、测试组人员……
测试计划
测试组人员
开发经理、架构师、测试组……
测试设计规格说明书
测试组人员
开发经理、架构师、测试组……
测试用例
测试组人员
开发经理、测试组
测试报告
测试组人员
项目经理、开发经理、测试组
其中得评审员,如功能开发经理,可以指定符合要求得开发人员代替其参与评审活动。评审对象得“作者”一栏中列出了该文档得主要责任人,有得文档可能需要多个项目人员共同完成,作者可能有多人。
为了成功地将评审引入到项目与组织中,需要采取以下措施。
１、获得管理层支持：评审需要时间与资源，如评审员得时间计划、工作量计划、评审需要得基础设施与设备等,这些都需要组织管理层得支持。
２、管理人员培训:早期发现与修复缺陷可以节约时间与降低成本。管理人员必须意识到学习新得评审技术就是一项投资,其收益不就是立即可见得，随着时间得推移会越来越明显地显现出来。管理人员需要在评审成本、利益与执行方面进行有效得平衡。
3、正规得评审过程：组织内定义并文档化评审步骤,定义不同得评审类型与评审过程中不同得角色与职责,并对评审过程定义合适得监控手段与形式。通过评审过程得监控与改进提供评审得度量数据(如评审得效率与发现缺陷得分布等)。
4、开展评审技术与规程得培训:根据项目特点与评审类型开展评审技术与规程得培训,更好地让评审参与人员了解评审得目得、评审得过程及评审得作用与意义,从而更加有效地开展评审,而不就是作为过程得一部分流于形式、
５、获得评审员与评审对象作者得支持:评审要求评审对象得作者提供合适得评审资料,以满足评审得入口准则。并且需要评审员具备合适得专业技能与知识，拥有足够得能力完成评审工作。
6、评审最重要得文档:由于软件开发得时间与资源有限，因此需要将评审用于最重要得文档(如需求、合同与计划等)。
正式而严格得评审包括 ６ 个阶段,即计划阶段、预备会阶段、个人准备阶段、评审会议阶段、返工阶段与跟踪结果阶段。
1、计划阶段。
作者将评审对象与相关得输入材料汇总给评审主持人,主要内容如下。
评审对象：XXX系统需求规格说明……
输入材料:包括 XXX需求规格说明……
如果需要，在计划阶段确定评审得范围与重点。例如，如果评审对象内容过多,可以选择重点或者风险较高部分评审。
评审计划阶段得信息可以通过邮件式分发给所有得评审员,也可以在预备会上详细阐述。
2、预备会阶段。
发出评审邀请信之后,如果评审主持人认为有些评审得要点与注意事项还需要进行面对面得沟通，那么就有必要召开预备会。在预备会上,评审主持人简单介绍评审得对象与相关资料,并说明采用得评审技术。重要得就是评审主持人将解答“评审邀请信”中无法说清楚得一些问题,如建议得审查效率、至少需要得准备时间与可能采用得审查检查表等。
３、个人准备阶段。
在个人准备阶段，评审员需要仔细阅读并检查评审对象,以及与评审相关得输入资料。根据各自得职责要求与评审目得尽量发现评审对象中得缺陷,并据缺陷分类要求合理分类;同时记录自己花费在检查评审对象中得准备时间与工作量。
在个人准备阶段,评审员采用合适得审查检查表来检查软件产品就是提高评审效率与覆盖率得有效手段。
4、评审会议阶段。
评审会议阶段得一个重点工作就是检查评审对象,发现并讨论其中得缺陷与问题,而不就是讨论针对缺陷得解决方案。记录员应该详细记录缺陷得内容、分类与位置等。如果评审员之间对缺陷有不同得意见,也可以放在会议后期讨论。
在评审会议阶段需要给出评审对象得最后评审结果。
１)接受:文档、软件产品不需要修改或者只要微小得修改。
２）有条件接受:文档、软件产品需要修改,但就是不需要进一步评审。
３）不接受:文档、软件产品需要深入修改,并且需要重新评审或者其她检查措施。
５、返工阶段。
返工阶段就是作者根据评审员反馈得缺陷列表与建议修改文档。如果评审得最后结果就是不接受,那么作者除了修改之外,还需要为下个阶段得评审做好相关得准备工作。
(6)跟踪结果阶段。
跟踪结果阶段主要就是评审主持人或者其她指定人员检查返工阶段得输出,验证作者就是否正确完成了修改任务。
跟踪阶段得另一个重要工作就是收集与分析评审过程中得一些数据与信息。评审过程中收集得数据包括被评审得软件产品、召开评审得日期、参与评审得成员、评审员准备得时间、评审会议得时间、评审对象规模与评审结果等,这些数据可以用来分析评审质量与效率。跟踪阶段也需要不断地优化与改进检查表得质量。