- 软件测试的目的：保障软件产品的质量。
- 软件测试人员：521，信心，责任心，耐心，细心，专心；沟通和表达能力，团队协作精神。
- 软件质量模型：功能，性能效率，安全，易用，兼容，可靠性，可移植性，可维护性
- 软件生命周期模型： 瀑布模型：可研与计划——需求文档——概要设计——详细设计——编码——软件测试——软件维护 敏捷开发模型：小步快跑
- 测试过程模型：
V模型：用户需求——需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试——验收测试
W模型：用户需求——需求分析——概要设计——详细设计——编码——集成——实施——交付
验收测试设计——系统测试设计——集成测设计——单元测试设计——单元测试——集成测试——系统测试——验收测试 测试用例：用例编号，用例标题，优先级，测试模块，前置条件，测试数据，测试步骤，预期结果
等价类划分法： ●针对需要有大量数据测试输入，但是没法穷举测试的地方。 (如:有输入框、下拉列表、单选复选 框等，需要同时提交，对于每种输入都需要大量测试输入验证) ●典型代表:页面级的输入框类测试
为什么不是所有的 bug 都需要被修复？
- 只有运行程序，会引起软件或系统失效的bug 需要修复。
- 严重性。
- 频繁性。
哪些属于bug？
- 软件未实现产品说明书要求的功能; （未做）
- 软件出现了产品说明书指明不应该出现的错误;（做错）
- 软件实现了产品说明书未提到的功能;（多做）
- 软件未实现产品说明书虽未明确提及但应该实现的目标;（默认）
软件难以理解、不易使用、运行速度慢，或者软件测试员认为最终用户会认为不好。（体验） 注意:尚未发现或未观察到的软件缺陷只能说是潜在缺陷。
bug 的严重程度是从客户的角度出发
- bug 的优先级是从开发工程师内部判断的，对它的紧急需求度（影响下个阶段的进展）。
如何更好的发现更多的bug？
除了根据软件需求说明书来发现软件缺陷外，可以尝试使用如下建议: 1.查找时间依赖和竞争条件的问题;配置国标时间 2.查找边界条件软件缺陷、内存泄露和数据溢出缺陷;. 3.查找状态转换时出现的缺陷; 4.查找资源依赖性:内存、网络、硬件等方面的缺陷;. 5.查找和硬件相关方面的缺陷，比如硬件兼容性方面的缺陷。
误报&漏报-该如何避免?
- 假阳性结果(误报) :由于测试执行方式的错误，或测试数据、测试环.境或其他测试件中的缺陷，可能会出现误报。 假阳性结果记录为缺陷，但实际上并不是缺陷。——换个环境，换个机器
- 假阴性结果( 缺陷的漏报) :相似的错误或缺陷会导致漏报。 假阴性结果指的是没有发现测试应该要发现的缺陷。——交叉测试
在实际测试中如果出现不可复现的bug怎么办?
●经过多次复现后，还是没有出现，此时在本地记录当前的问题 ●回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起 ●请开发协助(自己)查找当前测试模块是否有对应的日志信息(日志的应置可以问开发) ●再考虑更换一套环境查看是否能够复现上述问题 ●在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题 ●在后续版本还出现过，需要开发协助打印日志进行分析定位，同时测试需要提交bug
缺陷生命周期（bug产生的原因）：
需求设计阶段——开发设计阶段——编码阶段——开发修复bug阶段——软硬件系统本身运行阶段
缺陷核心要素： 缺陷标题，预置条件，复现步骤，预期结果，实际结果，必要附件
缺陷其它要素： 编号，状态，优先级，严重程度，所属模块，问题分类 缺陷跟踪流程：new——closed——reopen，rejected——inprogress——delay/postpone——fixed 编写bug的规范：可复现，唯一性，规范性，准确，具体
缺陷类型
1.功能错误 2.UI页面错误：布局，文字，图片，风格 3.兼容性：浏览器，操作系统 4.数据(數据厍) 5.易用性 6.建议 7.架构缺陪
编写测试用例的原则
1.能看懂---确保每个用例通俗易懂; 2.能执行--测试用例清晰准确，用例中每个步骤都是可执行的;
测试结果的几种状态说明
- pass-----通过:
- fail----失败;
- block----阻塞;
- NA----忽略;
执行测试用例原则
1.严格按照测试用例书写的步骤执行; 2.失败的用例，及时提交缺陷报告;
测试报告：
测试工作的经过与结果 风险评估 缺陷汇总与分析 测试工作总结与改进