这本书是三年前毕业时读的, 毕业时的职位是"测试开发工程师".

好吧, 这本书年龄比我还大:), 毕业那会绝版了, 读的是电子版的. 前阵子看到有在卖就买了一本珍藏, 最近重读了一遍.

可以作为测试入门读本.(测试界的经典书籍), 摘录一些, 一些关键字感兴趣可以自己google.

好吧, 在很多人眼里, 测试只是点点鼠标等没技术含量的工作, 干开发干不了才干测试. But, 这个观点是错误的, 测试还是非常博大精深的, 要求还是非常高的(需要懂各类语言, 需要写各种代码, 需要懂各种业务, 需要懂各类场景, 需要项目管理, 需要……).

---

• 什么是软件测试

所谓软件测试, 就是一个过程或一系列过程, 用来确认计算机代码完成了其应该完成的功能, 不执行其不该有的操作.

注意后半段.

• 测试的心理学

测试是为了发现错误而执行的过程

人的行为总是倾向于具有高度目的性. 所以需要将目标定为: 证明程序中存在错误(某些情况下, 测试人员的态度可能比实际的测试过程本身还重要)

所以, 要假设测试的程序是存在错误的.

• 软件测试的原则 (直接摘录了, 很多观点值得借鉴)

编号	原则
1	测试用例中一个必需部分是对预期输出或结果进行定义
2	程序员应当避免测试自己编写的程序
3	编写软件的组织不应当测试自己编写的软件
4	应当彻底检查每个测试的执行结果
5	测试用例的编写不仅应当根据有限和预料到的输入情况, 而且也应当根据无效和未预料到的输入情况
6	检查程序是否"未做其应该做的"仅是测试的一半, 测试的另一半是检查程序是否"做了其不应该做的"
7	应该避免测试用例用后即弃, 除非软件本身就是一个一次性的软件
8	计划测试工作时不应默许假定不会发生错误
9	程序某部分存在更多错误的可能性, 与该部分已发生错误的数量成正比
10	软件测试是一项极富创造性, 极具智力挑战性的工作

• 错误发现的越早, 改正错误的成本越低

so, 单元测试很重要, 代码走查很重要,

• 黑盒白盒

黑盒测试(数据驱动测试), 将程序视为一个黑盒, 不用去理解程序的内部结构(测试目标与程序内部机制和结构完全无关), 构造测试数据(来源于软件规范), 检查输出是否符合预期.

白盒测试(逻辑驱动测试), 对程序的逻辑结构进行检查, 从中获取测试数据.

• 具体分类

单元测试

功能测试

系统测试: 能力, 容量, 强度, 可用性, 安全性, 性能, 存储, 配置, 兼容性, 安装, 可靠性, 可恢复性, 服务/可维护性, 文档, 过程

验收测试

安装测试

• 测试用例的设计

白盒测试:

逻辑覆盖测试, 从弱到强依次是

语句覆盖,每个语句至少执行一次
判定覆盖(也称分支覆盖) 每个判断都至少有一个为真和为假的输出结果
条件覆盖, 确保将一个判断中的每个条件的所有可能结果都至少执行一次

黑盒测试:

等价划分, 穷举输入是不可能的, 但是可以将其划分成有限数量等价类, 获取一个子集输入.
边界值分析, 输入和输出等价类中那些恰好处于/大于/小于边界的状态
因果图, 需求规格 -> 因果关系分析 -> 因果图 -> 测试用例
错误猜测, 基于直觉和经验的猜测

---

• 做测试还是做开发?

我做了一年又三个月测试开发, 后来转职Python后端开发了.

原因? 兴趣, 仅此而已.

如果更在乎创造一些东西，做开发.

如果更喜欢发现一些东西，做测试开发(现在似乎没有单纯的测试了吧?)

(开发就像工匠, 测试就如寻宝的)

开发主动权在手中，测试需要更多的博弈.

(这么看来测试要求更高一些, 哈哈)

• 每个开发都应该懂些测试的基本思想和原则

写出的代码会更健壮. 多注意测试, 可以给后续维护以及重构节省一大笔时间.

可以拿这本书作为入门.

• 其他

不管有没有专职测试, 单元测试都是必须的.(最好要有, 重构复杂项目的时候会发现感动的哭了)

如果有专职测试, 开发测试比应该蛮高的, 好钢用在刀刃上, 对重要项目进行测试, 另外留出时间研究自动化测试/回归测试/测试工具等, 以及对项目流程进行优化, 最大化提高生产力.

没有专职测试, 需要开发人员足够靠谱, 并且需要建立一套完善的生产部署流程, 监控机制, 以及用户反馈机制, 以小步快跑, 频繁发布的方式处理需求, 同时关注反馈.