测试过程

测试过程

测试过程： 

                   vb ghv

专用术语·
HLD High Level Design 概要设计
LLD Low Level Design 详细设计
UT Unit Testing 单元测试
IT Integration Testing 集成测试
ST System Testing 系统测试
UAT User Acceptance Testing 用户验收测试
CMM Capability Maturity Model 能力成熟度模型
CCB Change Control Board 项目变更控制委员会
QA Quality Assurance 质量保证

 

 

软件开发阶段，软件测试的阶段划分
单元 集成 系统 均在公司内部完成 验收 用户完成

单元测试--LLD --模块--白盒--逻辑覆盖率

集成测试--HLD--接口+整体功能--灰盒--接口覆盖率

系统测试--SRS--功能+性能--黑盒--测试用例覆盖率

验收测试：用户测试，SRS，验收测试分为a测试（开发人员在场，内侧）和B测试（公测）

回归测试：可以发生在以上任意一个阶段，分为完全重复和部分重复（覆盖修改，周边影响，指标达成）

覆盖修改：仅测试有BUG的部分

周边影响：不仅测试有BUG的部分，而且测试周边扩散的部分

指标达成：修改有BUG的部分100%以及周边影响的百分比

1.单元测试阶段Unit Testing
单元测试是对软件基本组成单位进行的测试。单元具有特有的名称、输入输出和功能。
一个菜单、一个显示界面或者某个具体功能都可以是一个单元。
目的：检验代码和详细设计是否一致。
测试的依据：详细设计（LLD）
测试关注重点：l逻辑覆盖率
数据结构
逻辑控制
异常处理(错误处理)
测试方法：
采用白盒测试方法
评估基准：
逻辑覆盖率

时序图：

	计划阶段	设计阶段	实施阶段	执行阶段
输入	《软件开发计划》《软件测试计划》《需求规格说明书》	《需求规格说明书》《单元测试计划》	《需求规格说明书》《单元测试计划》《单元测试方案》	《单元测试用例》《单元测试规程》《单元测试预测事项》《需求规格说明书》《单元测试计划》《单元测试方案》
输出	《单元测试计划》	《单元测试方案》	《单元测试用例》《单元测试规程》《单元测试预测事项》	《单元预测报告》《单元测试报告》《软件缺陷报告》

2.集成测试阶段Integration Testing
经过单元测试后，将若干个单元组装在一起构成一个小产品，对这个小产品的功能和内部各单元
之间的接口进行的测试活动，叫集成测试。可能会涉及到抓包。
目的：1.检验各单元之间的接口
2.检验单元组装后的整体功能
测试的依据：概要设计（HLD）
测试关注重点：接口覆盖率
1.单元之间的接口（灰盒测试）
2.小产品的功能（功能测试）
测试方法：
采用灰盒测试方法
评估基准：
接口覆盖率

时序图：

	计划阶段	设计阶段	实施阶段	执行阶段
输入	《软件开发计划》《软件测试计划》《需求规格说明书》	《需求规格说明书》《集成测试计划》	《需求规格说明书》《集成测试计划》《集成测试方案》	《集成测试用例》《集成测试规程》《集成测试预测事项》《需求规格说明书》《集成测试计划》《集成测试方案》
输出	《集成测试计划》	《集成测试方案》	《集成测试用例》《集成测试规程》《集成测试预测事项》	《集成预测报告》《集成测试报告》《软件缺陷报告》

3.系统测试阶段System Testing
经过集成测试后，将软件与硬件、网络、某些支持软件、数据结合在一起，放在实际的运行环境中，
检验产品是否满足用户的需求。
目的：检验产品是否满足用户需求
测试依据：需求说明书（SRS，Software Requirement Specification）
测试关注重点：
需求说明书（功能、性能、兼容性操作系统，浏览器（IE,火狐。谷歌），屏幕分辨率兼容性，、安全性等）
测试方法：
采用黑盒测试方法
评估基准：
需求覆盖率

时序图：

	计划阶段	设计阶段	实施阶段	执行阶段
输入	《软件开发计划》《软件测试计划》《需求规格说明书》	《需求规格说明书》《系统测试计划》	《需求规格说明书》《系统测试计划》《系统测试方案》	《系统测试用例》《系统测试规程》《系统测试预测事项》《需求规格说明书》《系统测试计划》《系统测试方案》
输出	《系统测试计划》	《系统测试方案》	《系统测试用例》《系统测试规程》《系统测试预测事项》	《系统预测报告》《系统测试报告》《软件缺陷报告》

 

4.验收测试阶段Acceptance Testing
验收测试是以用户为主的测试。
按软件特点不同，分为项目型软件(定制化，面向用户)和产品型软件。
项目型软件的验收，通常叫用户验收测试 User Acceptance Testing
产品型软件的验收，通常叫alpha测试(内测)，beta测试（公测），gama测试

Alpha测试:
在开发环境下进行测试，测试结果可控的，开发者坐在用户旁边，有问题可以及时反馈修改，内部测试版本（）

FLURPS:
F: Functionality 功能性（是否满足需求）
L: Localization 本地化（语言翻译：英文-》本国语言）可能会出现的问题：错位与截断（字符显示不全）
U: Usability 易用性（考虑用户体验感受）
R: Reliability 可靠性 (系统的持续稳定使用)
P: Performance 性能
S: Support 支持

Beta测试：
在实际使用环境下进行测试，测试结果不可控，网上的测试版本（公测版本）

Smoke Testing 冒烟测试(版本预测试)
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，对其重要部分进行大概的测试，
目的是确认软件基本功能正常，可以进行后续的正式测试工作。

软件开发阶段，每个测试活动分为以下4个阶段
1.测试计划阶段：编写测试计划。时间，资源（人力，物力），测试对象和范围。从管理角度设计
2.测试设计阶段：编写测试方案。怎么测试？测试方法，测试工具，测试环境，测试数据等。从技术角度设计
3.测试实现阶段：编写测试用例（测试数据，测试步骤，预期结果），测试规程设计。
4.测试执行阶段：执行预测试，编写预测试报告，执行测试，提交缺陷报告，编写测试报告（包括模块、人员、用例、缺陷的统计信息）。

实际结果： Actual Result
期望结果： Expected Result（需求说明，概要设计，详细设计）

Testcase Pass
Testcase Fail----Bug 跟踪----修改---重新测试（回归测试： Regression Testing）

回归测试，Regression Testing，发现缺陷经开发者修复后，再次进行的测试活动。
目的：1.确认缺陷是否得到了正确的修复
2.确认修复没有影响到其他模块

回归测试可以发生在单元测试、集成测试、系统测试阶段。

回归测试流程：
在测试策略制定阶段，制定回归测试策略
确定需要回归测试的版本
回归测试版本发布，按照回归测试策略执行回归测试
回归测试通过，关闭缺陷跟踪单
回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

回归测试的策略：
1.完全重复测试

2.选择性重复测试：
覆盖修改，周边影响，指标达成法

验证Verification和确认Validation
验证Verification，检验产品是否满足之前的要求。
确认Validation，检验产品是否满足最初的要求。
测试活动，就是验证和确认的活动。

 

测试模型
1.瀑布模型
开发结束后才进行测试，主要针对程序进行测试。测试介入比较晚，如果发现需求遗漏，修改成本比较高。
适用容易理解，需求稳定的项目。

2.V模型
V模型体现软件测试分层的特点，相应的测试活动是针对需求、设计和编码的测试，测试执行
的顺序与开发活动相反。每个测试阶段又分为前期准备阶段和后期执行阶段，在开发的同时，
完成前期准备（测试计划、设计、实现）工作。

3.W模型
W模型是V模型的发展，将测试从开发中分离出来。强调测试伴随整个软件开发周期，
测试的对象不仅仅是程序，需求和设计同样需要测试。

4.H模型
H模型中测试是一个独立的流程，和开发并行进行；测试阶段又分为前期准备阶段和后期执行阶段，
满足测试条件（可以是设计流程和编码流程，或者其他流程）时就可以从准备阶段转入执行阶段。
测试可以先于开发进行（比如，敏捷开发中测试驱动开发Test-Driven Development）。

 5.双V模型(V&V)

Verifiction &&validation