软件测试的目的
-
软件测试的目的是为了发现错误而执行程序的过程
-
测试是为了证明程序有错，而不是证明程序无错
-
好的测试用例在于发现至今未发现的错误
-
一个成功的测试时发现了至今未发现的错误的测试
- 注意：测试不仅仅是为了找出错误，通过错误产生的原因和错误分布的特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时通过分析也可以帮助我们设计有针对性的检测方法，改善测试的有效性。
- 没有发现错误的测试也是有价值的，完整的测试时评测质量的方法，详细而严谨的可靠性增长模型可以证明这一点，例如Bev Littlewood发现，一个经过测试正常运行n小时的系统有继续运行n小时的概率。
验收测试
-
分为α、β、正式验收测试
-
α测试时内侧版本，即现在所说的cb，此版本仅仅是一个初步完成品，通常只在开发者内部交流，α测试的目的是评价软件产品的FLURPS （即功能、局域化、可用性、可靠性、性能、支持）尤其注重产品的界面和特色。α测试即为非正式验收测试
-
Beta是公测版本，是对所有用户开放的测试版本。该版本相对于α 版已有了很大的改进,消除了严重的错误, 但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布, 用户可从相关的站点下载。通过一些专业爱好者的测试, 将结果反馈给开发者, 开发者们再进行有针对性的修改。
-
Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无几, 成为正式发布的候选版本。
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。
缺陷的属性
- 缺陷标识：缺陷标识是标记缺陷的一组符号，每个缺陷必须有一个唯一的标识。
- 缺陷类型：缺陷类型是根据缺陷自然属性划分的缺陷种类，
- 缺陷严重程度：是指缺陷的引起的故障对软件产品的影响程度。
- 缺陷优先级：指缺陷被修复的紧急程度
- 缺陷状态：指缺陷通过跟踪修复过程的进展情况
- 缺陷起源：指缺陷引起的故障或第一次被检测到的阶段。
- 缺陷来源：指引起缺陷的起因
- 缺陷根源：指发生错误的根本原因。
软件测试分类
-
从是否关心内部结构和具体现实分
-
从是否执行被测软件：
-
从软件开发各阶段分
确认测试
- 在完后集成测试后，验证软件功能和性能及其他特性是否满足用户要求，目的是保证系统按照用户预期要求工作，通常采用黑盒测试。
软件测试的生命周期
- 1、新建（new）
- 2、打开（open）在测试者提交一个缺陷后，测试组长确认其确实为缺陷会把它置为打开阶段
- 3、指派、分配（ assign）一旦缺陷被置为打开，会把缺陷交给相应的开发人员或开发组，这时状态变为“分配”
- 4、测试（text）当开发人员修复缺陷后，会把缺陷提交给测试组进行新一轮测试
- 5、延迟（deferred）缺陷状态被置为“延迟的”意味着缺陷将在下一个版本进行修复，将缺陷置为延迟原因有很多，有些由于缺陷有现金不高，或时间紧。
- 6.不接受的（rejected）如果开发不认为是一个缺陷，他会不接受，并将状态置为“不接受的”
- 7、重复提交（duplicate）如果一个缺陷被重复提交两次，或两个缺陷表明意思相同，那么缺陷状态将被置为“重复提交”
- 8、已核实（verified）缺陷一旦被修复就会置为“测试”，测试人员会执行测试，如果缺陷不再出现就说明缺陷被修复，同时状态被置为已核实。
- 9、再次打开（reopened）若缺陷被修复后仍然存在，测试人员会将状态置为再次打开。
- 10、关闭（close）缺陷一旦被修复，测试人员会进行测试，如果缺陷不存在了，会把缺陷状态置为关闭。
测试用例
什么是测试用例？
- 测试用例是指为特定目的设置的一组测试条件、预期条件、预期结果，测试用例是执行测试的最小实体,他是测试工作的核心，是一组在测试时输入、输出的标准、是软件需求的具体对照。
测试用例的主要元素
- 标识符：唯一标识每一个测试用例
- 测试项：准确描述需要测试的项目及其特征
- 测试环境要求：表示执行测试用例的测试环境
- 输入标准：执行测试用例的输入要求（这些输入可能包括数据文件、或者操作）
- 输出标准：按照输入环境和输入标准得到的期望预期结果。
- 测试用例之间的联系：标识该测试用例与其他测试用例之间的关系
设计测试用例的设计过程
- 分析系统工作的流程
- 确定并制定测试用例
- 确定测试用例的数据
- 测试用例的修改和更新
- 测试用例修改的原因：
- 在测试过程中发现测试用例考虑不周
- 在软件交付后反馈的软件缺陷，而缺陷又是由测试用例存在漏洞引起的
- 软件自身功能更新以及软件版本更新，测试用例也要配套更新
黑盒测试
黑盒测试又称功能测试，他通过检测软件功能是否能正常使用，在测试中，把软件当做打不开的盒子，在完全不考虑程序内部结构和内部特征的情况下，在程序接口进行测试，他只能检测程序是否按照程序规格说明书运行，程序能否适当接收输入数据产生正确的输出信息。
黑盒测试主要着眼于程序外部结构，不考虑程序内部逻辑。主要针对软件界面，软件功能进行测试。
别名：功能测试、数据驱动测试、基于规格说明书测试。
优点：
- 从产品功能进行测试
- 适用于测试各个阶段
- 容易上手生成测试数据
缺点：
- 如果规格说明有误无法发现
- 某些代码得不到测试
- 不易进行充分测试
黑盒测试的主要方法
- 概述：从理论山讲，黑盒测试只有采用穷举输入测试，把所有输入条件都作为测试情况考虑，才能查出程序的所有错误，实际上测试数据有无数多个，不仅要进行所有合法输入，而且要对不合法但可能输入的条件进行输入，这样看来完全测试时不可能的，所以我们要进行有针对的测试。通过测试案例指导测试的实施 保证测试有组织、按步骤有计划的实施。黑盒测试的行为必须加以量化，才能保证软件的质量。而测试用例就是将测试方法量化的方法之一。
- 具体黑盒测试方法包括
- 等价类划分法
- 边界值法
- 错误推导法
- 因果图法
- 决策表法
- 场景法
- 正交测试法
白盒测试
静态测试
动态测试
未完——
软件的生命周期
一个软件的生命周期包含：
- 制定计划
- 需求分析
- 软件设计
- 程序编码
- 软件测试
- 软件运行
- 软件维护
- 软件停用 8个阶段
软件测试的生命周期
软件测试的5w1h
- what 测试什么
- why/which 为什么做/输入什么数据
- where 在哪做
- who 谁来做
- when 什么时候测试
- how 怎样进行测试
测试5c原则
- correct（准确）每个组成部分描述准确不会产生误解
- clear（清晰）每个组成部分清晰，易于理解
- concise（简洁）只包含必不可少的信息 不包含多余的信息
- complete（完整）包含该复现的完整步骤和其他本质信息
- consistent（一致）按照一致的格式书写全部缺陷报告
制定测试计划的目的
- 为测试各项活动制定一个现实可行、综合的计划，包括每项测试
活动的对象、范围方法、进度、预期结果。
- 为项目建立一个组织模型，并定义项目中每个角色的责任和工作内容
- 开发有效的测试模型，能正确的检验正在开发的软件系统
- 确定测试需要的时间和资源，以保证其可获得性有效性
- 确定每个测试阶段的标准、要完成的标准
- 是被测试活动的风险，并消除存在的风险，降低不可能消除风险所带来的损失。
测试计划包含的元素、内容要素
- 测试的范围
- 测试的策略
- 测试的需求
- 测试的资源要求
- 测试的人员要求
- 测试的进度
- 停止测试的标准
- 测试用例设计方法
- 测试中潜在的风险和问题区域
- 角色职责
为什么要进行软件测试？软件测试的目的是什么？
- 因为软件也是一种产品，是产品就应该经过测试菜可以流通上市，所以软件产品也需要测试是无可厚非的，在项目生命周期中，测试是给软件把关的重要环节。
- 软件测试的目的是为了发现错误而执行程序的过程
- 测试是为了证明程序有错，而不是证明程序无错
- 好的测试用例在于发现至今未发现的错误
- 一个成功的测试时发现了至今未发现的错误的测试
