书籍详情
![《软件测试：经验与教训软件工程技术丛书含条软件测试经验》[43M]百度网盘|亲测有效|pdf下载](/uploads/s0309/c40d87ae6f5c1f08.jpg)
软件测试：经验与教训软件工程技术丛书含条软件测试经验
- 出版社:互动创新图书专营店
- 出版时间:2004-01
- 热度:7103
- 上架时间:2024-06-30 09:08:33
- 价格:0.0
书籍下载
书籍预览
免责声明
本站支持尊重有效期内的版权/著作权,所有的资源均来自于互联网网友分享或网盘资源，一旦发现资源涉及侵权，将立即删除。希望所有用户一同监督并反馈问题，如有侵权请联系站长或发送邮件到ebook666@outlook.com,本站将立马改正
内容介绍
![]()
| 书名： | 软件测试：经验与教训[图书]|14718 |
| 图书定价： | 35元 |
| 图书作者： | （美）Cem Kaner,James Bach,Bret Pettichord |
| 出版社： | 机械工业出版社 |
| 出版日期： | 2004/1/1 0:00:00 |
| ISBN号： | 9787111129752 |
| 开本： | 16开 |
| 页数： | 234 |
| 版次： | 1-1 |
| 作者简介 |
| Cem Kaner是美国佛罗里达技术学院的教授，同时为软件开发界提供技术和管理等方面的咨询工作。他是*的测试技术权威，《Testing Computer Software》(中文版即将由机械工业出版社出版)和《BadSoftware》这两本书的*作者。 James Bach是Satisfice公司创始人和首席顾问，这是一家软件测试和质量保证公司。他具有在*硅谷公司(例如苹果和Borland公司)从事软件开发的经验，这使他在“足够好的”质量、基于风险的测试、探索测试和其他对技能和判断能力要求很高的技术等方面拥有丰富经验。他还是软件测试实验室的首席科学家。 Bret Pettichord是独立顾问，并为www．testinghotlist．com编辑很流行的“软件测试活动表”。他经常演讲并发表文章，并且还是测试自动化Austin研讨会的创始人。 |
| 内容简介 |
| 本书汇总了293条来自软件测试界**专家的经验与建议，阐述了如何做好测试工作、如何管理测试，以及如何澄清有关软件测试的常见误解，读者可直接将这些建议用于自己的测试项目工作中。这些经验中的每一条都是与软件测试有关的一个观点，观点后面是针对运用该测试经验的方法、时机和原因的解释或例子。本书还提供了有关如何将本书提供的经验有选择性地运用到读者实际项目环境中的建议，在所有关键问题上所积累的经验，以及基于多年的测试经验总结出的有用实践和问题评估方法。 优秀的软件测试团队不是天生的，而是造就的，是通过大量艰苦工作和有效沟通造就的。在这个过程中，有很多陷阱，这些陷阱会使精心制订的计划出现偏差，使项目不能按进度完成。 本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是对运用这条经验的方法、时机和原因的解释或例子。 为了满足不同层次的软件测试员、开发人员和管理人员的需要，本书还提供以下内容： ◆ 根据世界*软件测试专家多年的测试经验总结出的有用实践和问题评估方法。 ◆ 在所有关键问题上积累的经验，包括测试设计、测试自动化、测试管理、测试策略和错误报告。 ◆ 如何将本书提供的经验有选择性地运用到实际项目环境中的建议。 |
| 目录 |
译者序 序 前言 致谢 第1章 测试员的角色1 经验1：测试员是项目的前灯1 经验2：测试员的使命决定要做 的一切2 经验3：测试员为很多客户服务3 经验4：测试员发现的信息会 “打扰”客户4 经验5：迅速找出重要程序问题4 经验6：跟着程序员走5 经验7：询问一切，但不一定外露5 经验8：测试员关注失效，客户才能 关注成功5 经验9：不会发现所有程序问题6 经验10：当心“完备的”测试6 经验11：通过测试不能保证质量7 经验12：永远别做看门人7 经验13：当心测试中的不关我事理论8 经验14：当心成为过程改进小组8 经验15：别指望任何人会理解测试， 或理解测试员需要什么条件 才能搞好测试9 第2章 按测试员的方式思考11 经验16：测试运用的是认识论11 经验17：研究认识论有助于更好测试12 经验18：认知心理学是测试的基础12 经验19：测试在测试员的头脑中13 经验20：测试需要推断，并不只是 做输出与预期结果的比较14 经验21：优秀测试员会进行技术性、创造 性、批判性和实用性地思考14 经验22：黑盒测试并不是基于 无知的测试15 经验23：测试员不只是游客15 经验24：所有测试都试图回答某些问题16 经验25：所有测试都基于模型16 经验26：直觉是不错的开始，但又是 糟糕的结束16 经验27：为了测试，必须探索17 经验28：探索要求大量思索17 经验29：使用诱导推断逻辑发现推测18 经验30：使用猜想与反驳逻辑评估产品19 经验31：需求是重要人物所关心的质量 或条件19 经验32：通过会议、推导和参照发现 需求20 经验33：既要使用显式规格说明，也要 使用隐式规格说明20 经验34：“它没有问题”真正的含义是， 它看起来在一定程度上满足 部分需求21 经验35：*后，测试员所能得到的只是 对产品的印象22 经验36：不要将试验与测试混淆起来22 经验37：当测试复杂产品时：陷入 与退出22 经验38：运用试探法快速产生测试思路23 经验39：测试员不能避免偏向，但是可以 管理偏向23 经验40：如果自己知道自己不聪明，就更 难被愚弄24 经验41：如果遗漏一个问题，检查这种遗漏 是意外还是策略的必然结果25 经验42：困惑是一种测试工具25 经验43：清新的眼光会发现失效26 经验44：测试员要避免遵循过程， 除非过程先跟随自己26 经验45：在创建测试过程时，避免 “1287”26 经验46：测试过程的一个重要成果， 是更好、更聪明的测试员27 经验47：除非重新发明测试，否则 不能精通测试27 第3章 测试手段29 经验48：关注测试员、覆盖率、潜在问题、 活动和评估的组合测试手段30 经验49：关注测试员的基于人员的 测试手段31 经验50：关注测试内容的基于覆盖率的 测试手段32 经验51：关注测试原因（针对风险测试） 的基于问题的测试手段36 经验52：关注测试方法的基于活动的 测试手段37 经验53：关注测试是否通过的基于评估 的测试手段38 经验54：根据自己的看法对测试 手段分类39 第4章 程序错误分析57 经验55：文如其人57 经验56：测试员的程序错误分析会推动 改正所报告的错误57 经验57：使自己的错误报告成为一种 有效的销售工具58 经验58：错误报告代表的是测试员59 经验59：努力使错误报告有更高的 价值59 经验60：产品的任何项目相关人员都 应该能够报告程序错误60 经验61：引用别人的错误报告时要小心60 经验62：将质量问题作为错误报告60 经验63：有些产品的项目相关人员不能 报告程序错误，测试员就是 他们的代理61 经验64：将受到影响的项目相关人员的 注意力转移到有争议的 程序错误上61 经验65：决不要利用程序错误跟踪系统 监视程序员的表现61 经验66：决不要利用程序错误跟踪系统 监视测试员的表现62 经验67：及时报告缺陷62 经验68：永远不要假设明显的程序错误 已经写入报告62 经验69：报告设计错误63 经验70：看似极端的缺陷是潜在的 安全漏洞64 经验71：使冷僻用例不冷僻64 经验72：小缺陷也值得报告和修改65 经验73：时刻明确严重等级和优先等级 之间的差别66 经验74：失效是错误征兆，不是错误本身66 经验75：针对看起来很小的代码错误 执行后续测试67 经验76：永远都要报告不可重现的错误， 这样的错误可能是时间炸弹68 经验77：不可重现程序错误是可重现的68 经验78：注意错误报告的处理成本69 经验79：特别处理与工具或环境有关的 程序错误70 经验80：在报告原型或早期个人版本的 程序错误之前，要先征得同意71 经验81：重复错误报告是能够自我解决 的问题71 经验82：每个程序错误都需要单独 的报告72 经验83：归纳行是错误报告中*重要 的部分72 经验84：不要夸大程序错误73 经验85：清楚地报告问题，但不要试图 解决问题73 经验86：注意自己的语气。所批评的每个人 都会看到报告74 经验87：使自己的报告具有可读性，即使 对象是劳累和暴躁的人75 经验88：提高报告撰写技能75 经验89：如果合适，使用市场开发或技术 支持数据76 经验90：相互评审错误报告76 经验91：与将阅读错误报告的 程序员见面76 经验92：*好的方法可能是向程序员演示 所发现的程序错误77 经验93：当程序员说问题已经解决时， 要检查是否真的没有问题了77 经验94：尽快检验程序错误修改77 经验95：如果修改出现问题，应与 程序员沟通78 经验96：错误报告应该由测试员封存78 经验97：不要坚持要求修改所有程序 错误，要量力而行78 经验98：不要让延迟修改的程序 错误消失79 经验99：测试惰性不能成为程序错误 修改推迟的原因79 经验100：立即对程序错误延迟 决定上诉80 经验101：如果决定据理力争，就一定 要赢！80 第5章 测试自动化81 经验102：加快开发过程，而不是试图在 测试上省钱82 经验103：拓展测试领域，不要不断重复 相同的测试83 经验104：根据自己的背景选择自动化 测试策略84 经验105：不要强求100%的自动化84 经验106：测试工具并不是策略85 经验107：不要通过自动化使无序情况 更严重85 经验108：不要把手工测试与自动化测试 等同起来86 经验109：不要根据测试运行的频率来估 计测试的价值87 经验110：自动化的回归测试发现少部分 程序错误87 经验111：在自动化测试时考虑什么样的 程序错误没有发现88 经验112：差的自动化测试的问题是没有 人注意88 经验113：捕获回放失败90 经验114：测试工具也有程序错误91 经验115：用户界面变更92 经验116：根据兼容性、熟悉程度和服务 选择GUI测试工具92 经验117：自动回归测试消亡93 经验118：测试自动化是一种软件 开发过程94 经验119：测试自动化是一种重要投资95 经验120：测试自动化项目需要程序设计、 测试和项目管理方面的技能95 经验121：通过试点验证可行性96 经验122：请测试员和程序员参与测试 自动化项目96 经验123：设计自动化测试以推动评审97 经验124：在自动化测试设计上不要 吝啬97 经验125：避免在测试脚本中使用 复杂逻辑98 经验126：不要只是为了避免重复编码而 构建代码库98 经验127：数据驱动的自动化测试更便于 运行大量测试变种98 经验128：关键词驱动的自动化测试更便于 非程序员创建测试99 经验129：利用自动化手段生成测试输入100 经验130：将测试生成与测试执行分开101 经验131：使用标准脚本语言101 经验132：利用编程接口自动化测试102 经验133：鼓励开发单元测试包104 经验134：小心使用不理解测试的测试 自动化设计人员104 经验135：避免使用不尊重测试的测试 自动化设计人员105 经验136：可测试性往往是比测试自动化 更好的投资106 经验137：可测试性是可视性和控制106 经验138：尽早启动测试自动化107 经验139：为集中式测试自动化小组 明确章程108 经验140：测试自动化要立即见效108 经验141：测试员拥有的测试工具会比所 意识到的多109 第6章 测试文档111 经验142：为了有效地应用解决方案， 需要清楚地理解问题112 经验143：不要使用测试文档模板：除非 可以脱离模板，否则模板 就没有用112 经验144：使用测试文档模板：模板能够 促进一致的沟通113 经验145：使用IEEE标准829作为测试 文档113 经验146：不要使用IEEE标准829114 经验147：在决定要构建的产品之前先分析 需求，这一点既适用于软件也同 样适用于文档116 经验148：为了分析测试文档需求，可采 用类似以下给出的问题清单 进行调查117 经验149：用简短的语句归纳出核心 文档需求120 第7章 与程序员交互121 经验150：理解程序员怎样思考121 经验151：获得程序员的信任122 经验152：提供服务123 经验153：测试员的正直和能力需要尊重123 经验154：将关注点放在产品上， 而不是人上124 经验155：程序员喜欢谈论自己的工作。 应该问他们问题125 经验156：程序员乐于通过可测试性 提供帮助126 第8章 管理测试项目129 经验157：建设一种服务文化129 经验158：不要尝试建立一种控制文化130 经验159：要发挥耳目作用130 经验160：测试经理管理的是提供测试服务 的子项目，不是开发项目131 经验161：所有项目都会演变。管理良好的 项目能够很好地演变131 经验162：总会有很晚的变更132 经验163：项目涉及功能、可靠性、时间和 资金之间的折衷132 经验164：让项目经理选择项目生命周期133 经验165：瀑布生命周期把可靠性与时间 对立起来134 经验166：进化生命周期把功能与时间 对立起来135 经验167：愿意在开发初期将资源分配 给项目团队135 经验168：合同驱动的开发不同于寻求 市场的开发136 经验169：要求可测试性功能137 经验170：协商版本开发进度计划137 经验171：了解程序员在交付版本之前会 做什么（以及不会做什么）138 经验172：为被测版本做好准备138 经验173：有时测试员应该拒绝测试 某个版本138 经验174：使用冒烟测试检验版本139 经验175：有时正确的决策是停止测试， 暂停改错，并重新设计软件139 经验176：根据实际使用的开发实践调整 自己的测试过程140 经验177：“项目文档是一种有趣的幻想： 有用，但永远不足”141 经验178：测试员除非要用，否则 不要索要141 经验179：充分利用其他信息源141 经验180：向项目经理指出配置管理问题142 经验181：程序员就像龙卷风143 经验182：好的测试计划便于后期变更144 经验183：只要交付工作制品，就会 出现测试机会145 经验184：做多少测试才算够？这方面还 没有通用的计算公式145 经验185：“足够测试”意味着“有足够的 信息可供客户做出好决策”145 经验186：不要只为两轮测试做出预算146 经验187：为一组任务确定进度计划，估计 每个任务所需的时间146 经验188：承担工作的人应该告诉测试经理 完成该任务需要多长时间147 经验189：在测试员与开发人员之间没有 正确的比例148 经验190：调整任务和不能胜任的人员148 经验191：轮换测试员的测试对象149 经验192：尽量成对测试149 经验193：为项目指派一位问题查找高手150 经验194：确定测试的阶段计划，特别是 探索式测试的阶段计划150 经验195：分阶段测试151 经验196：通过活动日志来反映对测试员 工作的干扰151 经验197：定期状态报告是一种强 有力的工具152 经验198：再也没有比副总裁掌握统计 数据更危险的了153 经验199：要小心通过程序错误数度量 项目进展154 经验200：使用的覆盖率度量越独立， 了解的信息越多154 经验201：利用综合计分牌产生考虑 多个因素的状态报告155 经验202：以下是周状态报告的推荐 结构156 经验203：项目进展表是另一种展示 状态的有用方法157 经验204：如果里程碑定义得很好， 里程碑报告很有用158 经验205：不要签署批准产品的发布159 经验206：不要签字承认产品经过测试 达到测试经理的满意程度159 经验207：如果测试经理要编写产品发布 报告，应描述测试工作和结果， 而不是自己对该产品的看法159 经验208：在产品*终发布报告中列出 没有排除的程序错误159 经验209：有用的发布报告应列出批评者 可能指出的10个*糟糕的问题160 第9章 测试小组的管理161 经验210：平庸是一种保守期望161 经验211：要把自己的员工当作执行经理162 经验212：阅读自己员工完成的错误报告163 经验213：像评估执行经理那样评估 测试员163 经验214：如果测试经理确实想知道实际 情况，可与员工一起测试164 经验215：不要指望别人能够高效处理 多个项目165 经验216：积累自己员工的专业领域知识165 经验217：积累自己员工相关技术方面的 专门知识166 经验218：积极提高技能166 经验219：浏览技术支持日志166 经验220：帮助新测试员获得成功167 经验221：让新测试员对照软件核对文档167 经验222：通过正面测试使新测试员 熟悉产品167 经验223：让测试新手在编写新错误报告 之前，先改写老的错误报告168 经验224：让新测试员在测试新程序错误 之前，先重新测试老程序错误168 经验225：不要派测试新手参加几乎完成 的项目169 经验226：员工的士气是一种重要资产169 经验227：测试经理不要让自己被滥用170 经验228：不要随意让员工加班171 经验229：不要让员工被滥用172 经验230：创造培训机会172 经验231：录用决策是*重要的决策173 经验232：在招募期间利用承包人争 取回旋余地173 经验233：谨慎把其他小组拒绝的人 吸收到测试小组中173 经验234：对测试小组需要承担的任务， 以及完成这些任务所需的技能 做出规划174 经验235：测试团队成员要有不同背景174 经验236：录用其他渠道的应聘者175 经验237：根据大家意见决定录用175 经验238：录用热爱自己工作的人175 经验239：录用正直的人176 经验240：在面谈时，让应聘者展示期望 有的技能176 经验241：在面谈时，请应聘者通过非正 式能力测验展示其在工作中 能够运用的技能176 经验242：在录用时，要求应聘者提供 工作样本177 经验243：一旦拿定主意就迅速录用177 经验244：要将录用承诺形成文字， 并遵守诺言177 第10章 软件测试职业发展179 经验245：确定职业发展方向并不懈努力179 经验246：测试员的收入可以超过程序员 的收入181 经验247：可大胆改变职业发展方向 并追求其他目标181 经验248：不管选择走哪条路，都要 积极追求182 经验249：超出软件测试拓展自己的 职业发展方向182 经验250：超出公司拓展自己的 职业发展方向183 经验251：参加会议是为了讨论183 经验252：很多公司的问题并不比本公司 的问题少184 经验253：如果不喜欢自己的公司，就再 找一份不同的工作184 经验254：为寻找新工作做好准备184 经验255：积累并维护希望加入的公司 的名单185 经验256：积累材料185 经验257：把简历当作推销工具186 经验258：找一位内部推荐人187 经验259：搜集薪金数据187 经验260：如果是根据招聘广告应聘， 应根据广告要求调整自己 的申请187 经验261：充分利用面谈机会187 经验262：了解准备应聘的招聘公司188 经验263：在应聘时询问问题188 经验264：就自己的工作岗位进行谈判190 经验265：留意人力资源部191 经验266：学习Perl语言191 经验267：学习Java或C++192 经验268：下载测试工具的演示版 并试运行192 经验269：提高自己的写作技巧192 经验270：提高自己的公众讲话技巧193 经验271：考虑通过认证193 经验272：不要幻想只需两个星期就能够 得到黑带柔道段位194 经验273：有关软件工程师认可制度的 警告194 第11章 计划测试策略199 经验274：有关测试策略要问的三个基本问题 是“为什么担心？”、“谁关心？”、 “测试多少？”199 经验275：有很多种可能的测试策略199 经验276：实际测试计划是指导测试过程 的一套想法200 经验277：所设计的测试计划要符合 自己的具体情况201 经验278：利用测试计划描述在测试策略、 保障条件和工作产品上所做的 选择202 经验279：不要让保障条件和工作产品 影响实现测试策略202 经验280：如何利用测试用例202 经验281：测试策略要比测试用例重要203 经验282：测试策略要解释测试203 经验283：运用多样化的折衷手段204 经验284：充分利用强有力测试策略的 原始材料204 经验285：项目的初始测试策略总是错的205 经验286：在项目的每个阶段，可自问 “我现在可以测试什么，能够 怎样测试”？205 经验287：根据产品的成熟度确定 测试策略206 经验288：利用测试分级简化测试 复杂性的讨论207 经验289：测试灰盒208 经验290：在重新利用测试材料时， 不要迷信以前的东西208 经验291：两个测试员测试同样的内容 也许并不是重复劳动209 经验292：设计测试策略时既要考虑产品 风险，也要考虑产品要素209 经验293：把测试周期看作是测试 过程的韵律210 附录：软件测试的语境驱动方法221 参考文献225 |
| 编辑推荐 |
| 作者结合自己丰富的软件测试实验经验，大胆地对软件测试界很多人多年来鼓吹的所谓实践、关键活动、甚至国际标准进行了深刻的反思，令人信服地提出了自己的观点，对一些关键问题做了哲学思考，内容涉及与软件测试有关的各个方面，很适合有一定实际经验的软件测试、项目管理、软件开发、软件工程等方面的工程技术人员阅读。 |