软件测试经验与教训 (2008 年度畅销榜NO.827 )

本书汇总了293条来自软件测试界顶尖专家的经验与建议，阐述了如何做好测试工作、如何管理测试，以及如何澄清有关软件测试的常见误解，读者可直接将这些建议用于自己的测试项目工作中。这些经验中的第一条都是与软件测试有关的一个观点，观点后面是针对运用该测试经验的方法、时机和原因的解释或例子。
本书还提供了有关如何将本书提供的经验有选择性地运用到读者实际项目环境中的建议，在所有关键问题上所积累的经验，以及基于多年的测试经验总结出的有用实践和问题评估方法。

译者序
序
前言
致谢

第1章 测试员的角色
经验1：测试员是项目的前灯
经验2：测试员的使命决定要做的一切
经验3：测试员为很多客户服务
经验4：测试员发现的信息会“打扰”客户
经验5：迅速找出重要程序问题
经验6：跟着程序员走
经验7：询问一切，但不一定外露
经验8：测试员关注失效，客户才能关注成功
经验9：不会发现所有程序问题
经验lo：当心“完备的”测试
经验11：通过测试不能保证质量
经验12：永远别做看门人
经验13：当心测试中的不关我事理论
经验14：当心成为过程改进小组
经验15：别指望任何人会理解测试或理解测试员需要什么条件才能搞好测试

第2章 按测试员的方式思考
经验16：测试运用的是认识论
经验17：研究认识论有助于更好测试
经验18：认知心理学是测试的基础
经验19：测试在测试员的头脑中
经验20：测试需要推断，并不只是做输出与预期结果的比较
经验2l：优秀测试员会进行技术性、创造性、批判性和实用性地思考
经验22：黑盒测试并不是基于无知的测试
经验23：测试员不只是游客
经验24：所有测试都试图回答某些问题
经验25：所有测试都基于模型
经验26：直觉是不错的开始，但又是糟糕的结束
经验27：为了测试，必须探索
经验28：探索要求大量思索
经验29：使用诱导推断逻辑发现推测
经验30：使用猜想与反驳逻辑评估产品
经验31：需求是重要人物所关心的质量或条件
经验32：通过会议、推导和参照发现需求
经验33：既要使用显式规格说明，也要使用隐式规格说明
经验34：“它没有问题”真正的含义是，它看起来在一定程度上满足部分需求
经验35：最后，测试员所能得到的只是对产品的印象
经验36：不要将试验与测试混淆起来
经验37：当测试复杂产品时：陷入与退出
经验38：运用试探法快速产生测试思路
经验39：测试员不能避免偏向，但是可以管理偏向
经验40：如果自己知道自己不聪明，就更难被愚弄
经验41：如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果
经验42：困惑是一种测试：工具
经验43：清新的眼光会发现失效
经验44：测试员要避免遵循过程，除非过程先跟随自己
经验45：在创建测试过程时，避免“1287”
经验46：测试过程的一个重要成果，是更好、更聪明的测试员
经验47：除非重新发明测试，否则不能精通测试

第3章 测试手段

第4章 程序错误分析

第5章 测试自动化

第6章 测试文档

第7章 与程序员交互

第8章 管理测试项目

第9章 测试小组的管理

第10章 软件测试职业发展

第11章 计划测试策略

附录：软件测试的语境驱动方法

参考文献

提出软件工程知识体系(SoftwareEngineeringBodyOfKnowledge，SWEBOK)的目标是为颁发政府执照、规范软件工程师以及开设软件工程大学课程提供一种恰当的基础。SWEBOK文件声称以大部分人的意见为基础，希望这样的文件能够包容这个领域已经积累的知识和智慧(已经积累的经验教训)。 有关探索式测试，SWEBOK只有如下的叙述： 也许，最广泛采用的手段还仍然是专门定制的测试，即依靠测试员的技能和直觉(“探索”测试)，依靠测试员在类似工程上积累的经验所导出的测试。虽然人们建议采用更系统化的方法，但是专门定制测试方法对于确定形式化手段不能轻易“捕获”的特殊测试用例还是很有用的(但是只有当这些测试员都是真正专家的时候)。此外还必须指出，这种手段的有效性会有大幅度的变动(SWEBOK0.95,2001,第5~9页)。 SWEBOK怎样看待这种在测试领域中被最广泛地采用的手段呢?它丝毫没有涉及这种手段的使用方法，只是说应该由真正专家进行探索，建议使用其他方法，认为其他形式化的手段会使有效性更加稳定。 哈! 我们并不打算向读者正式描述反映测试领域大多数人观点的所谓知识体系，但是我们确实要大量谈论这个领域中最常见的实践。本书不是要排斥探索式测试， 而是要站在使用探索法(以及很多其他方法)在现实条件下达到最佳测试效果的人员立场上，来描述测试应该是怎样的。 本书包含的内容 多年以来，我们学会了很多有用的实践和很有帮助的问题评估方法。我们得出结论的基础是经验。本书归纳了我们的很多经验，将这些经验组织为接近300个短小、可读性好的经验系列描述。 选择这些经验时，我们遵循了以下一些准则： ·经验应该是有用的，或有自己的观点。 ·经验应该通过90分钟独立思考的考验。如果是什么人漫不经心地花90分钟就可以提出观点的话，那么这样的经验不值得收入本书。 ·经验必须基于我们的实际经历。我们中至少有一人(最好是三人)曾经成功地运用过我们给出的建议；我们中至少有两人在尝试我们所批判的实践时，遭受过挫折。(请注意：有时我们会根据自己不同的经历，分别得出不同的结论。偶尔读者会发现我们决定提供两种观点，而不是一种。即使只提供一种观点，读者也不能就认为我们三人都完全赞同这种观点。 当出现不同意见时，我们三人很可能会服从对该问题有最多经验的一两个人。) ·经验应，该根据我们同事的经历进行调整。通过“测试自动化Los Altos研讨会”、“软件测试经理圆桌协会”、“启发式与探索测试技术研讨会”、“测试自动化Austin研讨会”、“软件测试模式研讨会”、“基于模型的自动化测试研讨会”、“系统有效性管理集团”等几十个软件测试会议， 以及不太正式的同级相互培训(例如在Crested Butte举行的一年一度的顾问营)，我们收集了详细的经验报告。 ·经验应该简短，切中有害，但又易于理解。 ·经验可以长一些，但是只限于解释如何做，或提供有用的工具。很长的解释和详细背景信息不适合本书。 ·经验应该是自完备的，读者可以从书中任何地方开始阅读。 ·经验合在一起，应该使读者对我们怎样做测试以及考虑测试，能有一定的认识。