Lessons Learned in Software Testing
美 Cem kaner、James Bach、Bret Pettichord著
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是运用这条经验的方法、时机和原因的解释或例子。
第10章 软件测试职业发展
经验245-确定职业发展方向并不懈努力
自动化测试程序员；自动化测试结构分析员；性能和可伸缩性测试员；系统分析员；用户界面和人员因素分析员；鉴定员；测试计划设计员；专题测试专家；黑盒测试员；
测试管理工作：1、测试小组组长；2、测试经理；3、测试主任或质量主任；4、内部顾问；5、外部顾问；
测试调岗：1、程序设计经理或项目经理；2、技术支持经理；3、产品经理；4、文档编写小组经理5、销售支持经理
过程管理人员：1、软件指标专门人员；2、软件过程改进专门人员
经验246-测试员的收入可以超过程序员的收入
经验247-大胆改变职业发展方向并追求其它目标
经验248-不管选择走哪条路，都要积极追求
经验249-超出软件测试拓展自己的职业发展方向
转换职业也许有更多的收获
经验250-超出公司拓展自己的职业发展方向
出席会议、参加协会、论坛等；相互学习、相互忠告、相互帮助；
经验251-参加会议是为了讨论
经验252-很多公司的问题并不比本公司的问题少
经验253-如果不喜欢自己的公司，就再找一份不同的工作
经验254-为寻找新工作做好准备
经验255-积累并维护希望加入的公司的名单
经验256-积累材料
掌握能够证明自己能力的一些代码、文档和其它工作样本
经验257-把简历当做推销工具
经验266-学习perl语言
经验267-学习java或c++
经验268-下载测试工具的演示版并试运行
经验269-提高自己的写作技巧
经验270-提高自己的公众讲话技巧
经验271-考虑通过认证
第11章 测试计划策略
测试计划是指导自己测试过程的一套想法，我们使用测试策略这个词表示指导整个项目的测试设计。测试策略是好的测试计划的重要组成部分，是将测试与任务联系起来的桥梁。
经验274-有关测试策略要问的三个
基本问题是“为什么担心？”“谁关心？”“测试多少？”
经验275-有很
多种可能的测试策略
1、简单评审，交由又好用户使用，反馈问题；2、用户与产品交互动作序列表示的测试用例，代表预期一般用户使用产品的各种方法；补充压力测试和异常使用测试；还需要考虑可靠性；3、执行并行探索性测试，开发和执行自动化回归测试。都是测试策略。策略是不同的，实际项目，会根据产品的具体知识，设计出针对性更强的测试策略；
经验276-实际测试计划是指导测试过程的一套
想法
测试计划是指导将要做什么的所有想法，是否需要创建文档，需要思考；最好的情况是测试计划内容与沟通和管理该计划的方式结合；测试计划可以是正式的书面计划，也可以是口头计划、列在白板上的计划、一页纸的计划、一系列电子邮件，一组大纲或问题清单，最主要的是做能够完成任务的事，方式可以有很多种。
经验277-所设计的测试计划要符合自己的
具体情况
五种资源和约束：开发、需求、测试团队、测试实验室、任务；测试经理不要指望在所有上述问题上有很大的控制能力，测试小组的控制能力在于如何应对这些资源和约束：自己要有什么样的测试策略、保障条件和工作产品？
经验278-利用测试计划描述在测试策略、保障条件和工作产品上所做的
选择
测试策略：快速找出问题？特殊测试？什么手段创建测试？等等；保障条件：实现策略如何实现？谁来测试？测试时间？测试需要什么条件？工作产品：怎样向客户提供工作产品？如何跟踪程序错误？测试文档？测试报告？
经验279-不要让保障条件和工作产品
影响实现测试策略
测试策略常常被测试计划其它部分掩盖。一定要明确如何测试改产品，并告诉测试员怎么样测试；
经验280-如何
利用测试用例
只统计测试用例的个数而不管其中的内容是没有意义的。讨论测试用例的通过率时，一定要考虑风险及覆盖率，并讨论测试用例的内容。
经验281-测试策略比测试用例
重要
经验282-测试策略要
解释测试
好的测试策略是：与具体的产品有关；关注风险；多样化；实用；
经验283-运用
多样化的折中手段
执行达到相当水平的多种不同测试，要优于完美地执行一两种测试；这种原则叫做多样化的折中测试；从问题发现率角度看，采用每种测试手段在发现率开始降低时，就转而使用一种新的手段；有公司运行数以十万计的测试用例，仍然会遗漏显而易见的问题，因为他们的测试缺乏多样性；
经验284-充分利用强有力测试策略的
原始材料
充分利用这些资源，以使策略选择达到最大化部分资源：测试员测试手段的技能、产品内部技术的知识、特殊测试或工艺技能的朋友；原始测试数据库；多种测试平台；各种测试工具；实际用户数据；植入产品的可测试性功能（例如日志文件、判断和测试菜单）；
经验285-项目的初始测试策略总是
错的
建议根据风险确定测试策略。随着被测产品的任务加深，随着了解产品的弱点，随着想出测试该产品的新方法，测试策略也应该进化。
经验286-在项目的每个阶段，可
自问“我现在可以测试什么，能够怎样测试？”
测试策略要考虑进行测试的项目开发阶段以及测试结构层次，但是并不是决定性的考虑因素，建议测试经理可以在任何开发阶段自问“我们在此时可以测试什么？怎么样才能测试好？”
经验287-根据产品的成熟度
确定测试策略
项目初期，同情地测试；项目中期，积极的测试；项目末期，多样地测试；项目最后，谨慎地测试；
经验288-利用测试
分级简化测试复杂性的讨论
在测试策略中简化测试的复杂性，区分测试级别会有帮助0级：冒烟测试，独立的简单测试，失败，则直接打回；1级：能力测试，检验产品每个函数能力的测试。保证每个函数都能够执行其任务，避免曲折的场景、富有挑战性的数据和功能交互。2级：函数测试，各个个体函数和子函数的能力和基本可靠性。数据覆盖和符合测试结果评估方法是有意义的，使用边界、压力和错误处理测试，避免采用曲折的场景和功能交互。3、复合测试，多组函数之间的交互和控制流，以构成复杂场景的测试，重点已经扩张为性能评估、兼容性、资源紧张程度、内存泄露、可靠性或其它质量评判准则；首先宽泛、同情地测试，随着测试不断成熟，逐步进行深度和边缘测试。
经验289-测试
灰盒
部分给予内部结构的测试策略也是很好的想法 。如果了解一些产品的内部工作情况，就能够从外部进行更好的测试。像黑盒一样，但是所选择的测试反映出测试员对内部组件操作和交互的了解。灰盒测试对web和因特网应用程序尤其重要。
经验290-在
重新利用测试材料时，不要迷信以前的东西
在重用测试用例或者任何测试材料时，不要将其当做黑盒使用。需要做一些了解。
经验291-两个测试员测试同样的内容也许
并不是重复劳动
重复测试劳动几乎都不会是浪费，真正的问题不是浪费，而是产品的某一部分是否值得进行重复测试。
经验292-设计测试策略时既要考虑产品
风险，也要考虑产品
要素
好的测试策略不仅要根据产品风险制定，还要考虑产品内部要素，不要在测试员之间的缝隙中遗漏错误；经常测试客户要求测试的内容；偶尔测试客户不要测试的内容；测试不够清晰和矛盾的内容；不要痛打落水狗；更多变更意味着更多测试；
经验293-把测试周期看做是测试过程的
韵律
测试策略要根据测试周期来具体化。接收产品；对测试系统进行配置；检测可测试性；确定哪些部分是新增加的或者是经过修改的；确定修改了哪些程序错误；测试程序错误修改；测试新的或者经过变更的部分；测试其他部分（首先测试风险较大的部分）；报告测试结果；