读书笔记-软件测试-1-3章

读书时间：2011-7-2  周六 2小时

阅读书名：《软件测试》第二版  Ron Patton著 张小松等译

阅读章节—第一部分 软件测试综述（第1-3章）

凡是原书内容，均以引号标注，其余均为本人个人观点。

“软件测试并不是不停地敲击键盘，希望最终能使计算机崩溃这样一回事，在后面包含了大量的科学和工程、规则和计划，也有很多的乐趣”

这是一本较为基础的关于软件测试的书，主要包含了测试的基础知识和必要技能，本书10年前第一版，虽然IT行业发展迅速，从软件到互联网变化日益加速，但本书并未过时，相反，作者以过去经典的桌面软件的软件测试为蓝本，高屋建瓴地、系统讲述了软件测试的理论基础，很多观点令人耳目一新，深以为然。

本书包含了七部分内容：

1. 软件测试综述  - 基础内容，偏抽象，让人对软件测试有个基本的认识；
2. 测试基础- 软件测试工作的最基础的四个方面：MRD评审、黑盒功能测试、静态代码测试（Codereview）、白盒测试
3. 运用测试技术 – 将第二部分的内容应用到实战中，例如：配置测试、易用性测试、兼容性测试等；
4. 软件测试的进一步深入 – 有效的测试，提高测试覆盖率和深入程度，如自动化测试、测试工具、缺陷轰炸等概念的介绍，这些都在我现在的工作能找到影子；
5. 使用测试文档 – 软件测试文档化，是测试成果可见、可理解；
6. 软件测试的未来 – QA与测试的区别、职业规划等

今天读了前三章（第一部分 软件测试综述），读完的总体感觉是既豁然开朗，又朦朦胧胧，很多概念得到澄清，尤其是结合自己工作一年多来的实际测试经验；但是，又感觉越发模糊和迷惑，需要更多的思考和实践。到了“感觉懂了，实际还是不懂”的阶段！

第一章       软件测试的背景

人类计算机的第一个BUG：哈佛大学MARK II 计算机中飞进去的一个飞蛾，导致了它突然停止工作，这是“BUG”的来源。

1. 从“臭名昭著的软件错误用例研究”开始，最经典的莫过于千年虫问题，一个关于年份的存储问题（将1973年纪录为73），到了2000年，解决这个问题的费用达数千亿美元。

1. 软件缺陷是什么---官方定义一个软件缺陷（software bug）的“5个规则”

1. 软件缺陷出现和修复—“导致软件缺陷最大的原因是说明书（即需求），而不是编程错误，第二大来源是设计”，这个是测试人员需要注意的，我们的敌人不仅仅是RD提交的代码。

关于BUG修复，有意思的是，“随着时间的推移，修复软件缺陷的费用会惊人地增长”；从项目立项一开始，所有的人（包括PM、RD、QA）就会面临一个质量风险，从始至终都是为了生产更高质量的产品而奋斗，所以，从这个角度，质量是核心。而质量（反着说叫缺陷）代表着成本、金钱、人力、资源，那么何时介入测试就是一个软件开发过程（流程）必须考虑的一个问题，详情参考各种开发模型、各个公司和项目的测试人员的地位、如何参与项目等。

1. 软件测试员究竟做什么

“软件测试员得目标是尽可能早地找出软件缺陷，并确保其得以修复”

看到这句话，我恍然大悟、拍案叫绝、深以为然，这不正是我一直做的工作的最好解释吗？等到我在后面看到关于质量保证（QA）的说明时，才发现并不全是如此。但是，目前来看，一个纯粹的测试工作中测试人员，这就是我们在做的。

“编写软件的目的是为了解决现实中的问题”，所以，如果你是非计算机专业的，那么你窃喜吧，因为你的专业知识或许有一天会派上用场。

1. 软件测试员得素质

列了一堆，我最喜欢那么“软件测试很有趣”，“这就是平凡生活中的乐趣”。是啊，平凡生活中的乐趣……

第二章       软件开发的过程

“若想成为好的软件测试员，至少要对软件开发的全过程有个总体了解。”这话说得很有道理，如果只把眼光关注在测试上，我们很快就会遭遇瓶颈；毕竟，软件开发的主体不是测试，而是产品，那么必须得了解产品是如何开发出来的。

“作为学生或爱好者编写小程序的方法与作为大公司开发软件的方法大相径庭”---这句话对我的感触很大，我一直没有重视这很有意思的区别。很精妙。

1. 软件产品有哪些部分组成 – “不仅仅是代码，或是一张软件光盘”，理论上讲，所有提交给用户的东西都是需要测试的，很遗憾，我们往往忽略一些东西。

1. 参与到一个真正有效的、重要的、大的项目中去这很重要！回想平时的测试项目，其规模和正式程度远不够。

1. 软件项目成员—一个软件产品需要多个小组协作，很多的人共同协作完成（请注意，这很重要，不是单兵作战了）

1. 四种软件开发生命周期模型

“大爆炸模型” 这是测试需要避免的模型，因为质量不可控；

“边写边改模型” “没有时间做好，但总有时间完成”—看完我有个疑问，这个和CI是一回事吗，后来发现不是！

“瀑布模型”  经典的模型，不赘述；对测试而言好处是测试明确容易开展，缺点是缺陷修复成本高，尤其是需求变更无法适应。

“螺旋模型”，可以说是目前业界除去瀑布模型外的所有模型的“原型”，关于这个模型我的一个疑问是“敏捷测试和螺旋模型的区别是什么”；

以上两章内容“从较高的层面和分析推论的角度描述了软件项目如何运行”，到底是专家写的书，概括得很专业，不服不行。

第三章       软件测试的实质

前两章描述的都是理想天国的生活，本章回归软件测试的“现实”，如没有明确的开发模式、看不到完全符合客户需求的说明书、没有足够的时间做测试等。

一个合格的、卓有成效的软件测试员，需要以追求理想过程为目标。

“了解软件测试的作用、影响和责任，从而喜欢上制作软件产品所必需的幕后决策工作”

1. 关于测试的原则 – 软件测试与开发的“交通规则”或者“生活常识”，所以这些原则非常重要，对于我们平时的工作有方法论的指导意义。

原则1：完全测试程序是不可能的。这个很好理解，QA也不可能穷尽所有的测试用例。

原则2：软件测试是有风险的行为。参考原则1。

（“软件测试员要学会的一个关键思想是，如何把数量巨大的可能测试减少到可以控制的范围，以及如何针对风险做出明智的抉择，哪些测试重要，哪些不重要”）

原则3：测试无法显示潜伏的软件缺陷

原则4：找到的软件缺陷越多，就说明软件缺陷越多

原则5：杀虫剂怪事。缺陷是会不断增强免疫的，因此用新的方法和角度去测试，很重要。

原则6：并非所有的软件缺陷都要修复。但是你不能做出错误的决策。

原则7：什么时候叫缺陷难以说清。“谁都没有发现的BUG还能叫BUG吗”

原则8：产品说明书从没有最终版本。

原则9：“软件测试人员在小组中不受欢迎”。我不太赞同作者的观点。

原则10：软件测试是一件讲究条理的技术专业。是啊，必须好好学习。

1. 软件测试的一些术语。“精确和准确”、“确认和验证”、“质量和可靠性”
2. 测试和质量保证（QA）

“质量保证人员的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法”

从这个角度来看，我大部分时间都是做的软件测试员得工作。而一个合格的QA，还需要关注标准和方法。

“许多参与项目的软件测试员不清楚周围发生的事情、不清楚如何做出决定，或者不清楚应该遵照什么过程，这样是不可能有太多成效的。”

最后这句话，需要好好反思。

       我究竟知不知道周围发生了什么事情？

       我究竟清不清楚如何做出决定？

       我究竟清不清楚遵照什么过程？

       我究竟是否有成效？