软件测试流程及规范V11.docx
《软件测试流程及规范V11.docx》由会员分享，可在线阅读，更多相关《软件测试流程及规范V11.docx（14页珍藏版）》请在冰豆网上搜索。
软件测试流程及规范V11
软件测试流程及规范
一、软件生命周期中测试工作流程
二、各阶段具体流程
1.需求分析阶段
1.1步骤说明
1、需求定义基本完成，SRS编写完成。
2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题,相关人员解答并确认。
3、当评审未通过，直接打回,重新修改SRS，问题解决后，重新提交评审。
4、当评审通过后，依据SRS,项目整体计划,设计、编写《测试计划》和《测试设计》，具体模板见附件。
5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。
6、当审批未通过,直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。
7、审核通过后，进入下一阶段。
1.2测试通过打回标准
1。
3、阶段的输出
输入：
最新SRS、项目计划
输出：
测试计划、测试设计
2、单元及集成测试流程
2.1步骤说明：
1、理解需求和设计
理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置,这对测试的内容将会有很大的影响。
需要记住的一个原则就是：
好的设计,各模块只负责完成自己的事情，层次与分工是很明确的。
在单元测试的时候,可以不用测试不属于被测试模块所负责的功能,以减少测试用例的冗余,集成测试的时候会有机会测试到的。
所以，单元测试主要是关注本单元的内部逻辑,而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能.
2、概览源代码
浏览一下源代码,主要任务:
1）初步检查源代码的编码风格与规范。
2）大致估算测试工作量，比如：
需要多少的测试用例、需要写多少的驱动模块和装模块等。
3）确定模块的复杂程度，初步制定测试的优先级等。
3、精读源代码
认真阅读和分析代码,主要任务:
1）理解代码的业务逻辑。
2）检查代码与设计是否相符，如果详细设计没有该模块的流程图的话，先去画出流程图。
3）仔细研究逻辑复杂的模块。
4）可以采用一些检查列表来检查程序可能会出现的问题。
4、设计测试用例
综合运用白盒测试方法（和结合黑盒测试方法）来设计测试用例，包括功能测试、性能测试等,要达到一定的测试覆盖率.在设计测试用例的过程中，流程图或控制流图是分析的好帮手。
5、搭建单元测试环境
使用工具或自己写的框架将有助于单元测试的实施.在这个阶段主要就是写桩模块和驱动模块，第4步所设计的测试用例是通过驱动模块传递给被测试模块的,然后驱动模块想办法获取被测试模块对数据的处理结果，并判定返回的实际结果与测试用例的预期结果是否一致，通过测试框架来记录执行的结果，对于出现的错误，还需要统计错误的信息,供执行完之后分析.
6、执行测试
运行写好的驱动模块完成对被测试模块的测试.
7、补充和完善测试用例
单元测试也是个循序渐进的过程，可能一开始考虑的不够全面，或预期的覆盖标准太低，需要在测试过程中不断补充测试用例,直到满足要求为止。
8、分析结果，给出评价
根据测试的结果分析、查找错误的原因，并找到解决的办法。
测试结束之后，根据测试过程的数据统计,给出被测试对象评价
2。
2测试通过打回标准
1、通过标准
2、打回标准
2.3、阶段的输出
输入：
最新SRS、项目计划、详细设计
输出：
单元测试计划、单元测试用例、单元测试总结分析。
3、系统测试流程
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试,系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。
系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。
是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。
对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等.
3.1步骤说明
1、测试组收到测试任务通知书，告知较为确切的测试内容、日期.
2、根据最新SRS和各设计文档，将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，针对整个产品系统进行的测试。
3、编写此阶段系统测试方案，通过评审，优化系统测试方案.
4、然后编写或补充系统测试用例，用例完成后，需要通过评审,优化系统测试用例。
5、执行冒烟测试用例，测试版本仅少量严重程度低的bug未修改引起的不通过,反馈项目组，通知延长冒烟测试时间；测试版本符合冒烟测试打回标准，冒烟测试不通过，直接打回或挂起,结束测试。
测试完成度满足冒烟测试开始条件，重新发起测试申请。
6、当不通过时，退回或挂起。
7、当完成冒烟测试后，进行系统测试，提交bug报告，审核bug,当审核未通过时，补充测试用例，当审核通过汇总bug，总结报告.
8、当开发人员完成缺陷的修改后，提交新的版本，测试人员继续开始做回归测试。
当测试版本仅少量bug未修改引起的不通过，反馈项目组,通知延长系统测试时间;
测试版本符合系统测试打回标准，系统测试不通过，直接打回，结束测试.待测试完成度满足系统测试开始条件，重新发起测试申请.
9、当缺陷的统计曲线出现的逐渐收敛,并且得到控制。
10、分析缺陷的原因.
11、提交测试报告。
12、进入下一阶段。
3。
2测试通过打回标准
1）通过标准
2）打回标准
3.3、阶段的输出
输入:
最新SRS、项目计划、详细设计
输出：
系统测试计划、系统测试用例、测试总结分析.
4、验收测试
软件产品测试组对经过内部单元测试、集成测试和系统测试后的软件所进行的测试,测试用例采用业务流程测试用例。
4.1步骤说明
1、验收测试进入准则
1）软件产品通过单元测试、集成测试和系统测试.
2）项目组提交以下测试文档：
测试计划、测试用例、测试日志、测试通知单、测试分析报告.
3）待验收的软件安装程序。
2、测试错误类型
参考软件测试停止标准.doc
3、对用户手册和帮助的验收规定
1）用户手册和帮助的编制要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。
2）使用户（或潜在用户）通过用户手册能够了解该软件的用途,并且能够确定在什么情况下,如何使用它.
3）语句通顺、简洁，语义明确,错别字小于0.1％.
4）对相关名词解释应易于被用户理解.
5）对相关界面的说明要符合操作流程并将每一项功能解释完整、清楚.
6）保证用户手册、帮助能够正确指导用户使用软件。
4、软件验收测试合格通过准则
1）软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求.
2）所有测试项必须符合以下标准：
（以下比例为错误占总测试模块的比例）
一级错误
二级错误
三级错误
四级错误
五级错误
无
无
<2％
〈3％
暂不做要求
3）需求分析文档、设计文档和编码实现一致。
4）用户手册及帮助符合对用户手册及帮助的验收规定（编写人在责任认定书上签字时对于软件产品的各项功能描述、名词解释、结构、语句表达等方面均要保证其正确性并加以说明）。
5）验收测试文档齐全（见验收测试进入准则）.
6）以上五条其中之一不满足要求,视为不合格。
三、缺陷管理
3。
1缺陷定义
软件缺陷（Defect）,常常又被叫做Bug。
所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
具体归纳为以下这些问题。
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、轻微数据计算错误。
3
一般性缺陷
严重地影响系统要求或基本功能的实现，但存在合理的更正办法.
1、界面错误（附详细说明）；
2、打印内容、格式错误；
3、简单的输入限制未放在前台进行控制;
4、删除操作未给出提示；
5、数据输入没有边界值限定或不合理.
2
较小缺陷
使操作者不方便或遇到麻烦，但它不影响执行工作或功能实现.
1、辅助说明描述不清楚;
2、显示格式不规范；
3、系统处理未优化；
4、长时间操作未给用户进度提示；
5、提示窗口文字未采用行业术语.
1
其它缺陷
1、建议
2、其它错误
3。
3缺陷的流程
目前分公司的缺陷管理使用的是QualityCenter9.0,具体安装和使用细节，见使用手册。
在使用时遵循以下的流程，即缺陷的生命周期。
流程中缺陷存在以下6种状态：
提交bug状态（New）:
开发人员或测试人员发现bug,记录在系统里。
激活状态（Open）：
当项目经理或负责人觉得这个bug是问题,将bug置为此状态。
驳回状态（Rejected）：
当项目经理或负责人觉得这个bug不是问题，则可以驳回，将bug置为此状态.
已修正状态（Fixed）：
开发人员针对缺陷,修正软件后已解决问题或通过单元测试.
关闭状态（Close）：
测试人员经过验证后,确认缺陷不存在之后的状态.
重新激活状态（Reopen）:
测试人员经过验证后,确认此缺陷存在，之后将其置为此状态。
四、关于单元测试
1、首先应该明确单元的含义。
单元在面向对象的程序中指的是一个类,在结构化的方法中指的是一个函数。
2、其次应该明确单元测试的方法。
单元测试的常用方法包括：
（1）静态检查，即采用静态代码检查的工具对程序进行内部逻辑的分析，以分析程序中可能的错误.
（2）动态测试，通过编写单元测试程序，设计单元测试用例，测试每个函数或每个类的逻辑正确性。
3、如果一个类或一个函数对其他的类或环境依赖性很强，需要编写大量的桩程序或驱动程序,那恰恰说明了这个类或这个函数的设计有问题,违背了“低耦合"的基本设计原则，这也正式敏捷方法中提倡的“测试驱动开发”的作用之一。
4、质量的投入产出也是一种平衡，需要在单元测试上投入到什么程度首先是公司的一个管理方针。
如果每个单元都进行单元测试则测试代码的规模和产品代码的规模能够达到1:
1，也就是说编写测试代码的工作量还是比较大的，但是也要看到单元测试的产出.在单元测试、集成测试、系统测试中，单元测试是投入产出比最大的测试种类，即单元测试在单位时间内发现的缺陷个数大于集成与系统测试.原则上单元测试的投入最大，找到的缺陷最多,集成测试与系统测试依次递减.
5、在实践中推广单元测试时可以采用如下的方法:
1）、加大静态检查的力度。
通过静态检查的工具快速地识别程序中的错误、警告，公司可以规定对检查出的哪些警告、错误必须进行修改,注意如果修改所有的警告、错误可能工作量比较大。
静态检查是一种投入产出比很高的单元测试方法.在JAVA下可以采用checkStyle,Sourcemonitor,PMD，FindBugs，Jslink等.
2）、通过测试策略的选择减少测试程序的工作量.单元测试一般有三种策略：
策略一：
自底向上的策略:
先测底层的函数或类，再测上层的函数或类，此时只需要编写驱动程序，不需要编写桩程序。
策略二：
自顶向下的策略:
先测上层的函数或类,再测试底层的函数类,此时只需要编写桩程序，不需要或很少需要编写驱动程序。
策略三：
混合策略：
综合上述的2种策略，需要综合编写桩程序与驱动程序.
如果被测的单元需要调用很多其他的单元，则可以采用自底向上的策略减少驱动程序的编写量。
如果被测的单元需要很多外围的环境准备则可以采用自顶向下的策略。
3）、在组织级可以规定执行单元测试的时机,比如:
a）系统中最核心的、最关键的功能模块；
b）算法复杂的功能模块;
c）出错最多的功能模块；
d）客户最常使用的功能模块;
e）复用的底层代码；
根据Pareto定律,我们可以选择少部分代码执行单元测试。
6、单元测试的技术
1）、JUnit的工具
2）、生成测试用例时可以采用如下的方法:
a）单元功能分析
b）入口参数等价类分析
c）入口参数边界分析
d）全程变量、共享数据的等价类与边界分析
e）调用函数返回值的等价类与边界分析
f）覆盖率分析
上述的方法要求的严格程度可以循序渐进，不能的严格程度需要投入的工作量不同。
7、单元测试完成后，编写软件评定书。
五、通用检查点
见附件:
公共测试用例。
xlsx
六、常见缺陷分类
见附件：
缺陷分类。
xlsx
七、评审工作
一、审批过程
评审的通用过程由如下6个阶段组成:
1、计划阶段：
选择评审员并分配角色、为正式的评审类型（如审查）规定评审的入口和出口准则,以及选择需要评审的文档或文档章节等.
2、预备会阶段:
分发文档，向评审参与者解释本次评审的目标、过程和文档，以及核对入口准则（针对正式的评审类型）。
3、个人准备阶段：
在评审会议之前每位评审参与者准备各自的评审工作,标注评审对象中可能的缺陷、问题和建议等.
4、评审会议阶段：
讨论评审员提交的问题列表，并形成会议纪要（针对正式的评审类型）。
会议参与者可以标识缺陷并提出处理建议。
5、返工阶段：
修复评审过程中发现的缺陷，通常由作者完成。
6、跟踪结果阶段：
检查缺陷是否已经解决,收集度量数据并评估出口准则（针对正式的评审类型）.
二、审批中涉及的主要角色
经理、主持人或组长、作者、评审员和记录员，其他可能涉及包括决策者或者其他利益相关者，如用户代表；另外一个可选的角色有时会出现在审查中，即宣读员，在评审会议中宣读产品的某些部分。
三、审批遵循原则
评审遵循原则
1、尽早的开展评审.
2、控制评审会议的时间。
3、评审的是软件产品而不是作者。
4、每个评审员都必须有机会充分地表达各自的观点，并且评审会议纪要必须完整地记录每个评审员的意见和建议。
5、发现缺陷，而不是修复缺陷。
评审会议关注的是发现被评审对象中的缺陷，而尽量避免讨论针对缺陷的可能解决方案和方法,提出解决方案及其对应的讨论不应该是评审会议的关注点。
6、评审过程中发现的缺陷和问题，应该划分为不同的严重程度级别。
1）严重缺陷：
评审对象不能满足其目标,在批准评审对象之前必须修复相关缺陷。
2）重要缺陷：
影响评审对象的可用性,批准评审对象之前应该修复相关缺陷。
3）一般缺陷：
小的偏差,基本不影响使用.
4）好的：
没有缺陷，返工时无须修改.
7、评审团队最后应该对评审对象给出如下评审意见。
1）接受：
文档、软件产品不需要修改或者只要微小的修改。
2）有条件接受:
文档、软件产品需要修改，但是不需要进一步评审.
3）不接受:
文档、软件产品需要深入修改,并且需要重新评审或者其他检查措施。
四、审批类型
评审可以是正式或非正式的。
基于IEEEStd1028-2008软件评审和审计标准,分为审查、技术评审、走查、非正式评审、管理评审和审计等评审类型。
1、审查。
目的：
这是一种系统的同行检查方法,检查并发现软件产品中的缺陷。
主要关注软件产品是否满足规格说明及其是否体现了特定的质量特性，以及是否满足了规范、标准、指南、计划、规格说明和规程等要求，并识别其中存在的差异。
参与人员：
审查一般由2至6个人参与,包括作者。
角色主要有主持人、记录员、宣读员、作者和审查员。
度量数据：
检查表
结果输出：
确定补救措施或调查活动。
注:
审查会议上并不讨论解决方案。
收集相关数据并定期分析：
数据包括被审查的软件产品、审查召开的日期、审查参与的成员、审查员准备的时间、审查会议的时间、审查对象规模和审查结果等。
通过分析优化审核本身的过程,并改进生成软件产品的过程.
2、技术评审
目的:
为了评估软件产品是否满足预期的使用要求，识别软件产品和规格说明与标准之间不一致的地方.
方式：
同行间小组讨论活动，主要为了对测试对象所采用的技术实现方法达成共识。
参与人员：
包括决策者、评审主持人、记录员和技术评审员，也可以包括项目的其他利益相关者,如客户代表.
输入：
相关的规范、标准、计划和规格说明之外，评审检查表与缺陷分类等也是重要的内容。
输出:
其中主要包括技术评审的对象、参与技术评审的成员名单、技术评审的目标、技术评审的相关输入、评审得到的软件产品缺陷列表、管理问题列表、应对活动列表（应对活动的状态、负责人、完成的目标时间与完成的实际时间等）和评审团队得到的建议列表,并且判断软件产品是否满足了规范和标准等的要求.
3、走查
目的：
1）发现缺陷。
2）改善软件工作产品。
3）讨论软件工作产品的替换方案.4）评估和标准及规格说明等的一致性。
5）评估软件产品的可用性.6）培训参与者.
参与人员：
包括走查主持人、记录员、作者与走查员等。
度量数据:
检查表
收集相关数据并定期分析：
数据包括被走查的软件产品、走查开始的日期、走查参与的成员、走查员准备的时间、走查会议的时间、走查对象规模和走查对象的走查结果等。
通过分析优化走查本身的过程，并改进生成软件产品的过程。
4、非正式评审
非正式评审是一种不基于正式（文档化）过程的评审，它是评审的精简版，在某种程度上遵循通用的评审过程。
通常情况下，由作者发起非正式评审。
评审计划限定于选择评审员和要求他们在指定时间点提交意见和建议.非正式评审通常不召开会议和相互交换意见，只是作者和评审员之间的交互。
非正式评审可以是一种由一个或多个同事完成的交叉阅读,其结果不需要明确的文档化，有时一个评审清单或修订文档就足够了。
结对编程、结对测试和代码交换等都是非正式评审的方式,非正式评审非常普遍，并且由于工作量小而被广泛接受.
五、如何开展审批活动
被评审的产品应当符合相应条件（如审查需要满足一定的评审入口准则），同时不同的评审对象需要不同的评审员参与。
如下表:
文档名称
作者
评审员
需求规格说明书
系统人员
项目经理、架构师、测试组人员……
测试计划
测试组人员
开发经理、架构师、测试组……
测试设计规格说明书
测试组人员
开发经理、架构师、测试组……
测试用例
测试组人员
开发经理、测试组
测试报告
测试组人员
项目经理、开发经理、测试组
其中的评审员，如功能开发经理，可以指定符合要求的开发人员代替其参与评审活动。
评审对象的“作者"一栏中列出了该文档的主要责任人，有的文档可能需要多个项目人员共同完成,作者可能有多人.
为了成功地将评审引入到项目和组织中，需要采取以下措施.
1、获得管理层支持：
评审需要时间和资源，如评审员的时间计划、工作量计划、评审需要的基础设施和设备等,这些都需要组织管理层的支持。
2、管理人员培训：
早期发现和修复缺陷可以节约时间和降低成本.管理人员必须意识到学习新的评审技术是一项投资,其收益不是立即可见的，随着时间的推移会越来越明显地显现出来。
管理人员需要在评审成本、利益和执行方面进行有效的平衡.
3、正规的评审过程：
组织内定义并文档化评审步骤，定义不同的评审类型和评审过程中不同的角色和职责，并对评审过程定义合适的监控手段和形式.通过评审过程的监控和改进提供评审的度量数据（如评审的效率和发现缺陷的分布等）。
4、开展评审技术和规程的培训:
根据项目特点和评审类型开展评审技术和规程的培训，更好地让评审参与人员了解评审的目的、评审的过程及评审的作用和意义,从而更加有效地开展评审，而不是作为过程的一部分流于形式.
5、获得评审员和评审对象作者的支持：
评审要求评审对象的作者提供合适的评审资料,以满足评审的入口准则。
并且需要评审员具备合适的专业技能和知识，拥有足够的能力完成评审工作.
6、评审最重要的文档:
由于软件开发的时间和资源有限，因此需要将评审用于最重要的文档（如需求、合同和计划等）。
正式而严格的评审包括6个阶段，即计划阶段、预备会阶段、个人准备阶段、评审会议阶段、返工阶段和跟踪结果阶段。
1、计划阶段。
作者将评审对象和相关的输入材料汇总给评审主持人,主要内容如下。
评审对象：
XXX系统需求规格说明……
输入材料：
包括XXX需求规格说明……
如果需要,在计划阶段确定评审的范围和重点。
例如,如果评审对象内容过多，可以选择重点或者风险较高部分评审。
评审计划阶段的信息可以通过邮件式分发给所有的评审员,也可以在预备会上详细阐述。
2、预备会阶段。
发出评审邀请信之后，如果评审主持人认为有些评审的要点和注意事项还需要进行面对面的沟通，那么就有必要召开预备会。
在预备会上，评审主持人简单介绍评审的对象和相关资料，并说明采用的评审技术.重要的是评审主持人将解答“评审邀请信”中无法说清楚的一些问题，如建议的审查效率、至少需要的准备时间和可能采用的审查检查表等.
3、个人准备阶段。
在个人准备阶段,评审员需要仔细阅读并检查评审对象，以及与评审相关的输入资料。
根据各自的职责要求和评审目的尽量发现评审对象中的缺陷,并据缺陷分类要求合理分类；同时记录自己花费在检查评审对象中的准备时间和工作量。
在个人准备阶段,评审员采用合适的审查检查表来检查软件产品是提高评审效率和覆盖率的有效手段。
4、评审会议阶段。
评审会议阶段的一个重点工作是检查评审对象，发现并讨论其中的缺陷和问题，而不是讨论针对缺陷的解决方案。
记录员应该详细记录缺陷的内容、分类和位置等.如果评审员之间对缺陷有不同的意见,也可以放在会议后期讨论。
在评审会议阶段需要给出评审对象的最后评审结果。
1）接受：
文档、软件产品不需要修改或者只要微小的修改。
2）有条件接受：
文档、软件产品需要修改，但是不需要进一步评审.
3）不接受：
文档、软件产品需要深入修改，并且需要重新评审或者其他检查措施。
5、返工阶段。
返工阶段是作者根据评审员反馈的缺陷列表和建议修改文档。
如果评审的最后结果是不接受,那么作者除了修改之外,还需要为下个阶段的评审做好相关的准备工作。
（6）跟踪结果阶段。
跟踪结果阶段主要是评审主持人或者其他指定人员检查返工阶段的输出，验证作者是否正确完成了修改任务.
跟踪阶段的另一个重要工作是收集和分析评审过程中的一些数据和信息。
评审过程中收集的数据包括被评审的软件产品、召开评审的日期、参与评审的成员、评审员准备的时间、评审会议的时间、评审对象规模和评审结果等，这些数据可以用来分析评审质量和效率.跟踪阶段也需要不断地优化和改进检查表的质量。
升级会员 