标签：移植 单元测试 检查 环境 保存 完全 类型 团队 没有
1.软件测试的定义
软件测试是利用测试工具按照测试方案和测试流程对软件产品进行功能和性能测试。
2.软件测试的原则
① 追溯到用户需求
② 将“尽早的和不断地进行软件测试”作为座右铭
③ 完全测试是不可能的，测试是需要终止的
④ 除了检查程序是否做了应该做的之外，还应检查是否做了不该做的
⑤ 严格执行测试计划，避免随意性
⑥ 杀虫剂现象
⑦ 用例包含合理的和不合理的输入条件
⑧ 集群现象
⑨ 程序员避免检查自己的程序
⑩ 妥善保存一切测试过程中产生的文档
3.软件测试的目的
软件测试的最终目的是确保交给用户的产品符合用户的需求
① 软件测试是程序的执行过程，目的在于发现错误
② 测试是为了证明程序有错，而不是证明程序无错
③ 一个好的测试用例是在于它能发现至今未发现的错误
④ 一个成功的测试是发现至今未发现的错误的测试
4.项目组织架构
项目经理，开发经理，分析人员，设计人员，开发人员，测试经理，测试组长，测试人员，运维经理，运维人员，SQA
5.软件测试的风险
进度风险，变更风险，人员风险，成本风险，质量风险
6.缺陷产生的原因
需求变更，缺乏沟通，设计，编码错误，时间压力，软件复杂程度
7.测试人员的职责
配置测试环境，编写测试计划，设计测试用例，执行软件测试，提交软件缺陷，编写缺陷报告，验证修正缺陷，编写测试报告
8.测试的输出文档
测试计划，测试方案，测试用例，测试报告，缺陷报告单
9.软件的生命周期
需求，设计，编码，测试，维护，升级，废弃
10.软件产品构成
需求，设计，界面，代码，功能，说明，文本，按钮
11.软件产品的过程文件
需求规格说明书，版本计划，测试计划，测试方案，测试报告，测试用例，缺陷跟踪单
12.软件开发模型
瀑布模型：先完成开发再测试的开发模型，不能尽早地发现错误，阶段划分明确且固定，会产生大量文档，极大增加工作量，需求变更会极大影响项目质量
增量模型：人员分配灵活，可以短时间交付，但是要求各部分构件之间是相互独立的。很容易退化成边做边改模型
原型模型：关注用户需求，减少由于软件需求不明确带来的开发风险。但是所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
螺旋模型：结合了瀑布和原型模型的优点，但是风险大，过多的迭代次数会增加成本，延迟提交时间
喷泉模型：使用于面向对象的软件开发过程，需要大量的开发人员，不利于项目管理，要求严格管理文档，审核难度大
敏捷开发模型：忽略文档，要求员工经验丰富，容易遇到瓶颈问题
13.软件测试模型
V模型:需求→需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试
从左到右描述了开发过程和测试行为，并且清楚地描述了测试阶段和开发过程的对应关系
W模型：开发和测试同步进行，可以尽早地发现错误，但是不支持迭代
X模型：探索性测试，边设计用例边测试
H模型：完全独立的测试活动，想什么时候测什么时候测
敏捷测试模型：是不断修正质量指标，正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
特点：开发与测试并行，项目周期快，模块提交快，测试时较有压迫感；
2.注重团队沟通，要参加整个项目组的讨论决策会议；
3.测试人员需要在活动中关注产品需求，产品设计，解读源代码；
4.测试人员能独立完成各项测试计划、测试执行工作；
5.测试人员需要具有良好的自动化测试框架支撑进行快速测试；
6.在有限的时间内完成更多的测试准备和执行，富有极强责任心和领导力；
7.测试人员需能够做更多的与测试或许无关，但与团队共同目标直接相关的工作。
14.软件测试流程
需求分析→测试计划→测试用例→测试执行→测试报告
15.测试用例的设计方法
等价类划分法、边界值分析法、因果图法、判定表驱动法、正交试验法、错误推测法、场景法、功能图法
16.测试用例八个要素
用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、操作步骤、预期结果
17.测试用例设计原则
1.测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
2.测试结果的可判定性：即测试执行结果的正确性是可判定的，每个测试用例都应有相应的期望结果。
3.测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
18.软件缺陷的定义：
19.缺陷的几种类型：
（1）设计不合理;?
（2）功能、特性没有实现或部分实现;?
（3）运行出错，包括运行中断、系统崩溃、界面混乱等;?
（4）与需求不一致，在执行用例时实际结果和预期结果不一致;
（5）用户不能接受的其他问题，如存取时间过长、界面不美观;?
（6）软件实现了需求未提到的功能。
20.如何识别软件缺陷
① 通过测试用例中的预期结果进行识别
② 通过需求规格说明书进行识别
③ 通过用户手册及其他文档进行识别
④ 通过同行业相类似成熟的商业软件识别
⑤ 通过与开发人员的沟通进行识别
⑥ 通过与有经验测试人员沟通进行识别
⑦ 通过参照同行业隐式需求进行识别
21.缺陷处理流程
测试人员 提交缺陷报告
测试/开发经理 分配缺陷报告
开发人员 处理缺陷报告
测试人员 返测/回归测试
测试人员关闭
经理/组长审核 关闭缺陷报告
22.管理bug的工具:Excel、Bugzilla、TestDirector（TD）、ClearQuest（CQ）、Bugfree、禅道、JIRA等
23.软件测试策略
黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动测试、功能测试、性能测试、冒烟测试、回归测试、全面测试、随机测试
24.按阶段划分：
单元测试、
集成测试:
a.非增量式集成
b..增量式集成：自顶向下增量式测试 桩程序；
自底向上增量式测试 驱动程序
系统测试：功能测试，性能测试，负载测试，压力测试，稳定测试，兼容测试，容量测试，数据备份测试，失效恢复测试，可用性测试，健壮性测试，安装测试，配置测试，文档测试，在线帮助测试，GUI测试，安全性测试
验收测试:
非正式的验收测试
а测试：软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
?测试：软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。
正式的验收测试
有正规的测试过程，需要制定测试计划、定义测试方案、选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面。
25.按是否查看代码划分：黑盒测试、白盒测试
26.按是否运行代码划分:
静态测试：桌面检查、代码审查、走查
动态测试:实际运行被测试的软件，输入相应的测试数据，检查实际的输出结果是否和预期结果相一致的过程。
27.随机测试的缺点：
1.测试往往不真实；
2.不能达到一定的覆盖率；
3.许多测试都是冗余的；
4.需要使用同样的随机数种子才能重建测试。
28.回归测试：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例。防止出现“以前应用没有的问题现在出问题了” 。
29.冒烟测试：称为版本验证测试，也称为预测试。
主要验证软件的基本功能是否正常，可以进行后续的正式测试工作。
30.全面测试：是基于冒烟测试之后，项目首个版本测试。
主要验证软件的全部功能是否正常，执行最全面的测试用例。
31.软件质量的6大特性和27个子特性
功能性：适合性、准确性、互操作性、保密安全性、功能性的依从性
可靠性；成熟性、容错性、易恢复性、可靠性的依从性
易用性：易学性、易理解性、易操作性、吸引性、易用性的依从性
效率；时间特性、资源利用性、效率的依从性
维护性：易分析性、易改变性、易测试性、稳定性、维护的依从性
可移植性；易安装性、易替换性、共存性、适应性、可移植性的依从性
32.测试报告的组成要素
项目模块、测试人员、测试时间、测试环境、测试工具、测试用例、缺陷条目、遗留缺陷、风险评估、相关文档（用例、计划、方案、操作手册）
标签：移植 单元测试 检查 环境 保存 完全 类型 团队 没有
原文地址：https://www.cnblogs.com/llflifei/p/11989824.html
