软件测试
2016-05-20 14:43:36 0 举报AI智能生成
中心主题是故事、文章或讨论的核心思想或主要观点。它是整个作品的骨架，所有的情节、角色和细节都围绕它展开。例如，如果中心主题是“爱情能够战胜一切”，那么故事可能会讲述两个人如何克服重重困难，最终证明他们的爱情的力量。中心主题可以是明确的，也可以是隐含的，但它必须贯穿整个作品，为读者提供理解和解读作品的框架。无论是在写作还是在阅读时，理解中心主题都是非常重要的，因为它可以帮助我们更好地理解和欣赏作品的意义和价值。
作者其他创作
大纲/内容
分类
按开发阶段
单元测试（模块测试）
辅助测试模块模型
驱动模块（主程序）
桩模块（存根模块）
考虑方面
模块接口测试
检查进出程序单元的数据流是否正确
主要关注单元中的输入和输出
局部数据结构
常见错误
不正确或不一致的类型说明
错误的初始化或默认值
错误的变量名，如拼写或书写错误
下溢，上溢或者地址错误
主要关注与被测单元内部的相关数据的类型
独立路径测试
重点关注由于计算错误、不正确的判定或不正常的控制流而产生的错误
主要关注程序的逻辑分支问题
出错处理测试
重点关注模块在工作中发生错误时，出错处理设施是否有效
主要针对程序中的错误提示
边界条件测试
采用边界值分析方法设计测试用例，重点关注程序边界处
原则
测试工具
C++ test
JUnit
NUnit
适合于所有.net语言
主要进行单元测试
集成测试
渐增式
自顶向下
自底向上
非渐增式
系统测试
主要内容
功能测试
健壮性测试
性能-效率测试
用户界面测试
安全性测试
压力测试
可靠性测试
验收测试
α测试
β测试
按测试实施单元
开发方测试
用户测试
第三方测试
按测试技术
黑盒测试（功能/性能测试）
用例设计方法
等价类划分
边界值分析
因果图法
测试方面
功能测试
性能测试
灰盒测试
白盒测试（结构测试）
方法
静态分析
动态测试
按是否执行程序
静态测试
代码检查
分类
代码走查
代码审查
优点
更有效率，发现30%-70%的逻辑设计和编码缺陷
看到的是问题本身而非征兆
缺点
非常耗费时间，且代码检查需要知识和经验的积累
静态结构分析
主要以图形的方式表现程序的内部结构
代码质量度量
可维护性
功能性
可靠性
易用性
效率
可移植性
可以人工，也可以借助软件工具自动进行
动态测试
功能确认和接口测试
覆盖率测试
性能分析
内存分析
其他
回归测试
冒烟测试
随机测试
定义
软件=程序+文档+数据（扩展）
目的
发现/修改缺陷
满足需求，提高用户的满意程度
优化软件品质
测试流程
参加需求评审会议，阅读需求设计
编写测试计划
对需求规格说明书仔细研究
将要测试的产品分解成可独立测试的单元
为每个测试但愿确定采用的测试技术
为测试的下一个阶段及其活动制定计划
设计和编写用例
要素
测试输入
执行条件
预期结果
好处
保证测试功能不被遗漏和重复测试
可以合理安排测试人员
使得软件测试不依赖与个人
搭建测试环境，执行测试
提交缺陷报告
记录问题发生的环境
记录问题的再现步骤
记录问题性质的说明
记录问题的处理进程
测试评审，回归测试
测试过程
产品
总结，编写系统测试报告
模型
软件开发模型
大棒开发法
优点
思路简单，通常可能是开发者的突发奇想
缺点
开发过程是非工程化的，随意性大，结果不可预知
测试
开发任务完成后，修复较为困难
边写边改法
优点
简单考虑到了软件的需求，产品周期短
缺点
没有计划和文档的编制
测试
由于新的版本不断产生，测试工作长期循环
瀑布模型
优点
易于理解
调研开发的阶段性
强调早期计划及需求调查
确定何时能够交付产品及何时进行评审与测试
缺点
不适用需求变化
各步骤分立，没有交叉
反复、迭代不可显示，无法后退
缺少风险评估
后期暴露问题
快速原型法
优点
根据客户需求在短时间内解决用户最迫切解决的问题，完成可演示的产品
缺点
只实现最重要的功能，在得到用户更加明确的需求后，原型将丢弃
螺旋式开发
优点
严格的全过程风险管理
强调各个开发阶段的质量
提供机会评估项目是否有价值继续下去
步骤（五个）
确定目标，选择方案
评估方案，解决风险
本阶段的开发和测试
计划下一阶段
确定下阶段的方法
软件测试模型
V模型（瀑布模型的变种）
局限性
测试过程编码之后的一个阶段
需求分析阶段的隐藏的问题一直到后期的验收测试才被发现
特点
反映了测试活动与需求分析和设计的关系
W模型
原则
尽早地和不断地进行软件测试
优点
V模型自然的发展，是对其的改进
测试伴随整个软件开发周期，测试对象包括程序、需求、功能和设计
H模型
特点
软件测试应该尽早准备尽早执行
软件测试是一个独立的流程，贯穿于整个产品周期，与开发并行
软件测试不仅仅指测试的执行，还包括很多其他的活动
软件测试是根据被测物的不同而分层次进行的，不同层次的测试活动可以是按照某个次序先后进行的，但也可以是反复的
X模型
测试工具
停止依据
测试超过了预定时间
执行了所有的测试用例，但并没有发现故障
使用特定的测试用例设计方案作为判断测试停止的基础
正面指出停止测试的具体要求，即停止测试的标准
根据单位时间内查出故障的数量和严重程度决定是否停止测试
原则（八个）
尽早地和及时地测试
测试前应当准备好测试数据和与之对应的预期结果这两部分
测试输入数据应包括合理的输入条件和不合理输入条件
程序提交测试后，应当由专门的测试人员进行测试
严格执行测试计划，排除测试的随意性
测试用例的所有相关预期结果做全面的检查
充分注意测试当中的群体现象
保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料
误区（六个）
误区一：软件测试技术要求不高，至少比编程容易多了
误区二：若发布的软件有质量问题，那是软件测试人员的错
误区三：软件测试是测试人员的事，与开发人员无关
误区四：根据软件开发瀑布模型，软件测试是开发后期的一个阶段
误区五：有时间就多测试一些，来不及就少测试一些
误区六：软件测试是非建设性的工作，甚至是破坏性的，测试中发现错误是对责任人工作的一种否定
测试环境
原则
真实
干净
无毒
分类
开发环境
软件
硬件
网络
生产运行环境（最终用户环境）
文档
参考文档
客户调研报告（需求）
产品说明书
设计文档
架构
数据流示意图
状态变化示意图
流程图
注释代码
进度计划
开发进度表
需求分析说明书
概要设计说明书
详细设计说明书
测试文档
测试计划（测试计划评审报告）
尽早制定，需求说明书确定之后进行
在测试活动中处于中心位置
测试计划要经过评审
该文档的最终用户是研发团队
测试用例
测试缺陷报告
测试总结报告
统计总结
用户使用手册
软件质量
范围
可说明性
有效性
易用性
标准
产品质量
McCall模型
ISO 9126
Boehm
过程质量
CMM（能力成熟度模型）
核心
把开发视为一个过程
进行过程监控和研究
更科学化和标准化，更好实现商业目标
五级模型
初始级
可重复级
定义级
管理级
优化级
ISO 9000
SQA（软件质量保证）
QA
着眼于过程整体
预防问题，参与评审，确保文档有效
监督软件开发过程
建立体系，确保执行，保证产品和过程符合相应标准和规程
QC
着眼于软件
保证质量符合规定
发现问题
受控
0 条评论
下一页
