质量意识
质量重要性：
质量 时间 成本 三要素缺一不可? 相互制约 达到平衡
质量保证和测试的关系
测试发现可能存在代码缺陷 bug 性能差 安全问题 产品缺陷 用户体验差 服务不稳 可兼容性差问题
大致分为功能性测试类问题和用户体验评估类问题
Bug的基本认识
bug修复流程：
- 测试人员或用户发现bug 将其置为激活状态
- 开发人员收到激活bug，进行修复，此时bug状态为处理中
- 修复完成后，将bug置为解决状态
- 测试人员再次验证，若通过 将其关闭 否则重新激活bug提交直至验证通过
bug状态：
- open激活状态
- in process处理中状态
- resolved解决状态
- closed关闭状态
- reopen重启状态
bug提交格式要求：
- 标题
- 问题描述
- 复现步骤
- 能否复现
- 问题来源
- 问题影响
- 补充描述
测试流程：
- 测试人员撰写测试方案并提交开发人员评审
- 开发人员编写单元测试用例并提交测试人员评审
- 测试人员设计和编写用例进行功能性测试
- 测试人员根据项目情况决定是否进行性能/压力测试
- 测试自动化并把流程加入持续集成
- 测试人员在大版本是撰写测试报告
单元测试
常见的单元测试问题：
- 使用system.out输出测试结果，依赖人工判断
- 不使用assert断言对测试结果判断
- 缺少边界检查
- 多个测试分支放入一个单元测试方法中
- 测试case环境相关
- 测试方法执行有先后顺序
单元测试原则：
- 独立性：独立于其他测试及运行环境
- 可重复：具备多次运行的能力
- 可自动化：工具自动化? 自动进行判断
- 彻底性：需要覆盖全部分支
python测试框架：
- unittest? 好处：无兼容性问题，python标准库，是其他框架基础? ? 不足：编码略显繁琐?
- pytest：好处：编码简洁 生态好 插件丰富? ?不足：属于第三方库需提前安装
- nose2：好处：能够兼容unittest 属于第三方库 但与pytest相比 迭代缓慢
单元测试规范：
- 必须使用assert断言判断结果，禁止无断言的测试用例
- 测试用例需要自表述能力，见名知意
- 测试用例之间相互独立，不应相互依赖相互调用
- 一个测试用例只测一个函数 （可以包含该函数多个场景 但不能包含多个参数的函数）
测试替身：
- 桩stub：一般什么都不做 实现空的方法调用或简单的硬编码返回即可
- 伪造对象fake：真实数据的简单版本，伪造真实对象行为，但是没有副作用或没有其他后果 eg：替换数据库对象而得到虚假的伪造对象
- 测试间谋spy：是一个测试替身? 用于记录过去发生情况 事后知道所发生一切
- 模拟对象mock：特殊的测试间谋 在特定情况下可以配置行为的对象，规定了在什么情况下返回什么样的值
|