软件测试作业流程及标准规范V.docx

软件测试步骤及规范
一、软件生命周期中测试工作步骤
二、各阶段具体步骤
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缺点步骤
现在分企业缺点管理使用是Quality Center9.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下能够采取check Style, Source monitor，PMD，Find Bugs，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- 软件评审和审计标准，分为审查、技术评审、走查、非正式评审、管理评审和审计等评审类型。
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）跟踪结果阶段。
跟踪结果阶段关键是评审主持人或其它指定人员检验返工阶段输出，验证作者是否正确完成了修改任务。
跟踪阶段另一个关键工作是搜集和分析评审过程中部分数据和信息。评审过程中搜集数据包含被评审软件产品、召开评审日期、参与评审组员、评审员准备时间、评审会议时间、评审对象规模和评审结果等，这些数据能够用来分析评审质量和效率。跟踪阶段也需要不停地优化和改善检验表质量。