读书笔记-软件测试的艺术
这本书是三年前毕业时读的, 毕业时的职位是"测试开发工程师".
好吧, 这本书年龄比我还大:), 毕业那会绝版了, 读的是电子版的. 前阵子看到有在卖就买了一本珍藏, 最近重读了一遍.
可以作为测试入门读本.(测试界的经典书籍), 摘录一些, 一些关键字感兴趣可以自己google.
好吧, 在很多人眼里, 测试只是点点鼠标等没技术含量的工作, 干开发干不了才干测试. But, 这个观点是错误的, 测试还是非常博大精深的, 要求还是非常高的(需要懂各类语言, 需要写各种代码, 需要懂各种业务, 需要懂各类场景, 需要项目管理, 需要……).
- 什么是软件测试
所谓软件测试, 就是一个过程或一系列过程, 用来确认计算机代码完成了其应该完成的功能, 不执行其不该有的操作.
注意后半段.
- 测试的心理学
测试是为了发现错误而执行的过程
人的行为总是倾向于具有高度目的性. 所以需要将目标定为: 证明程序中存在错误(某些情况下, 测试人员的态度可能比实际的测试过程本身还重要)
所以, 要假设测试的程序是存在错误的.
- 软件测试的原则 (直接摘录了, 很多观点值得借鉴)
| 编号 | 原则 |
|---|---|
| 1 | 测试用例中一个必需部分是对预期输出或结果进行定义 |
| 2 | 程序员应当避免测试自己编写的程序 |
| 3 | 编写软件的组织不应当测试自己编写的软件 |
| 4 | 应当彻底检查每个测试的执行结果 |
| 5 | 测试用例的编写不仅应当根据有限和预料到的输入情况, 而且也应当根据无效和未预料到的输入情况 |
| 6 | 检查程序是否"未做其应该做的"仅是测试的一半, 测试的另一半是检查程序是否"做了其不应该做的" |
| 7 | 应该避免测试用例用后即弃, 除非软件本身就是一个一次性的软件 |
| 8 | 计划测试工作时不应默许假定不会发生错误 |
| 9 | 程序某部分存在更多错误的可能性, 与该部分已发生错误的数量成正比 |
| 10 | 软件测试是一项极富创造性, 极具智力挑战性的工作 |
- 错误发现的越早, 改正错误的成本越低
so, 单元测试很重要, 代码走查很重要,
- 黑盒白盒
黑盒测试(数据驱动测试), 将程序视为一个黑盒, 不用去理解程序的内部结构(测试目标与程序内部机制和结构完全无关), 构造测试数据(来源于软件规范), 检查输出是否符合预期.
白盒测试(逻辑驱动测试), 对程序的逻辑结构进行检查, 从中获取测试数据.
- 具体分类
单元测试
功能测试
系统测试: 能力, 容量, 强度, 可用性, 安全性, 性能, 存储, 配置, 兼容性, 安装, 可靠性, 可恢复性, 服务/可维护性, 文档, 过程
验收测试
安装测试
- 测试用例的设计
白盒测试:
逻辑覆盖测试, 从弱到强依次是
语句覆盖,每个语句至少执行一次
判定覆盖(也称分支覆盖) 每个判断都至少有一个为真和为假的输出结果
条件覆盖, 确保将一个判断中的每个条件的所有可能结果都至少执行一次
黑盒测试:
等价划分, 穷举输入是不可能的, 但是可以将其划分成有限数量等价类, 获取一个子集输入.
边界值分析, 输入和输出等价类中那些恰好处于/大于/小于边界的状态
因果图, 需求规格 -> 因果关系分析 -> 因果图 -> 测试用例
错误猜测, 基于直觉和经验的猜测
- 做测试还是做开发?
我做了一年又三个月测试开发, 后来转职Python后端开发了.
原因? 兴趣, 仅此而已.
如果更在乎创造一些东西，做开发.
如果更喜欢发现一些东西，做测试开发(现在似乎没有单纯的测试了吧?)
(开发就像工匠, 测试就如寻宝的)
开发主动权在手中，测试需要更多的博弈.
(这么看来测试要求更高一些, 哈哈)
- 每个开发都应该懂些测试的基本思想和原则
写出的代码会更健壮. 多注意测试, 可以给后续维护以及重构节省一大笔时间.
可以拿这本书作为入门.
- 其他
不管有没有专职测试, 单元测试都是必须的.(最好要有, 重构复杂项目的时候会发现感动的哭了)
如果有专职测试, 开发测试比应该蛮高的, 好钢用在刀刃上, 对重要项目进行测试, 另外留出时间研究自动化测试/回归测试/测试工具等, 以及对项目流程进行优化, 最大化提高生产力.
没有专职测试, 需要开发人员足够靠谱, 并且需要建立一套完善的生产部署流程, 监控机制, 以及用户反馈机制, 以小步快跑, 频繁发布的方式处理需求, 同时关注反馈.