1、软件测试经验与教训读书笔记 测试员的角色 1）测试给项目产品做关键决策时提供信息依据。 2）测试员要明确自己的在项目中的使命，使命决定要做的一切。 3）测试员要服务于多类客户，针对不同客户，提供不同信息。（例如：技术支持、管理者、市场人员） 4）测试员需通知客户有关威胁产品价值的任何信息。 5）测试员要迅速找出重要的程序问题。（变更的、核心的、常用的、可用性、影响大的、最需要的部分） 6）为程序员提供支持。尽量建立最短、最快的反馈环路。 7）询问项目相关一切问题，最好结合其他沟通形式提问。 8）测试员关注失效，客户才能关注成功。注：确认程序正常是不可能的，除非运行所有可能的测试，所以确认成本是
2、很高的。 9）测试员不会发现所有程序问题。所以应自知不能完成所有事，合理有效安排自己的时间。 10）测试员当心向客户传递隐藏的已“完备的”测试。应让客户详细了解测试过程，总结自己已实施和未实施测试点及如此 安排的原因。 11）通过测试不能保证质量。测试员既不会提高质量，也不会降低质量，质量来源于构建产品的人。注：测试员能促进项目质量保证的信息，但质量保证是来自整个项目团队的。 12）永远别做看门人，即测试员永远不要把控产品发布的权力。因为这样团队其他成员可能会放松质量。建议：由控制项目、条件好的人承担发布产品责任或由集体决定是否发布产品。 13）当心测试中的“不关我事”理论。测试员的使命应该是
3、尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。 -14）当心成为过程改进小组。因不管过程改进要干什么， 它永远都会涉及感情。 15）别指望任何人都能理解测试，或理解测试员需要什么条件才能搞好测试。所以测试需向客户解释测试，且需一遍又遍地解释。因为疫苗的作用会逐渐衰退。 测试员的思考方式： 测试员不喜欢抱怨，他们喜欢提供证据；测试员不喜欢征服，他们喜欢打破产品没问题的幻觉；测试员不喜欢发布坏消息，他们喜欢把客户从虚假信念中解放出来。 16）测试运用的是认识论。认识论研究如何认识所了解的东西：研究证据和推理。（如：怎么知道软件足够好？如果软件不是足够好，怎么才能知道？怎么知道已完成了
4、足够的测试？） 17）研究认识论有助于更好测试。（例如：如何收集和评估证据？如何进行有效的推论？如何使用不同逻辑形式？如何做出好的决策？） 18）认知心理学是测试的基础。如果说认识论告诉我们应该怎样思考，那么认知心理学告诉我们的是我们是怎样思考的。（例如：人的感觉和记忆可靠性。信念从哪里来。在压力下如何思考。） 19）测试能力差别在于测试员如何思考。（如：测试员的测试设计选择；解释所观察到的现象的能力；分析描述这些现象的能力。） 20）测试需要探索式推断，而不只是输出与预期结果对比。 21）优秀测试员会进行技术性、创造性、 批判性、实用性地思考。 技术性思考：对技术建模并理解因果关系的能力。（
5、如：相关技术事实的知识和使用工具并预测系统行为的能力。） 创造性思考：产生思想并看到可能性的能力。（如：寻找猜想可能存在的问题。） 批判性思考：评估思想并进行推断的能力。（如：消除错误的能力并构建好的测试用例的能力。） 实用性思考：把想法付诸实施的能力。（如：运用测试工具，并使测试手段和力量与项目范围适应的技能。） 22）黑盒测试并不是基于无知的测试。因为测试员对产品及产品的方式了解得越多，越能更好地测试它。而黑盒测试的优势在于测试员可能 与程序员的思考不同，因此有可能预测出程序员所遗漏的风险。 23）测试员不只是游客。两者差别：测试员把精力放在评估产品上而不只是见证产品。注意：测试员对产品做
6、大量的非测试的事（例如：看看产品由什么组成；怎么工作的。），有助于对产品的了解，为了更好地测试。 24）所有测试都试图回答关于已 BUILD 产品和用户所需产品间关系的某个问题。 -25）所有测试都是基于产品模型（例如：谁是用户，用户关心什么等一些概念），而不是实际产品。 26）直觉是不错的开始，但又是糟糕的结束。建议：把直觉用作指南，但不能用作合理性证明 。 27）为了测试，必须探索。所有测试都是采样，且样本永远不可能完备探索式思考要在整个测试项目过程中，在寻求最大化测试价值时起作用。这里所谓的探索，是指有目的的漫游：带着一般使命在某个空间中漫游，但没预先确定的路线。探索包括不断学习和实践。
7、 28）探索要求大量思索。探索就是侦查，是没有边界的搜索，需要前向、后向、侧向思索。 前向思索：根据已知探索未知，从所看到的探索还没看到的。注意支流和副作用。 后向思索：从怀疑或想像的东西返回到已知，尝试证实或否定自己的推测。 侧向思索：让自己的工作由于新冒出的想法而转移，然后再探索主题返回到主线索上。 -29）使用诱导推断逻辑发现推测。诱导推断又叫做假设归纳，是一种测试员每天都要使用的关键推理形式：最佳解释的推理。主要内容是： 第 1：收集一些数据并要找出其中的意义。 第 2：构造可能说明这些数据的各种解释。 第 3：收集更多的数据，以确定或否定每种解释。 第 4：从候选解释中，选择能够最一
8、致地说明所有重要数据的解释，如果没有足够证据证实任何结论，刚继续搜索。 30）使用猜想与反驳逻辑评估产品。 20 世纪初，哲学家 Karl Popper 引入了猜想与反驳方法，用于如何区分宗教和科学问题。这种方法基于科学家永远也不能绝对肯定任何具体事实，或关于自然的理论这个前提。这个方法，以如下三种重要方式应用于测试： 第 1：测试的目的是显示产品失效，要比显示产品正常更有力。 第 2：有关软件（软件有怎样的行为、如何好等）已经牢固形成的信念应该受到质疑。 第 3：警惕声称以超过测试员所运行的具体测试的试，检验或确认了产品的测试。任何量的测试都不能提供产品质量的确认性。 31）需求是重要人物所
9、关心的质量或条件。作为测试员，必须认识到谁的关于质量的观点最重要；不同 客户通过产品要得到不同的东西，他们不一定知道要什么，而且所要的东西会随时发生变化，这使得测试员的工作更有意义。 32）通过会议、推导和参照发现需求。需求信息到达测试员主要有三种途径： 第 1：会议：找出其关于质量意见最具影响力的人，与他们交流，了解他们最关心什么。 第 2：推导：通过外推已知的项目和产品其他信息，确定什么需求最重要。 第 3：既发现显式，也发现隐式规格说明，并以此作为测试的基础。 33）既要使用显示规格说明，也要使用隐式规格说明。 -显式规格说明是一个有用的需求信息源，经过客户的权威确认。（如： “是的，这
10、就是规格说明，是产品描述。”） -隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。（如：“这不是规格说明，但是有意义。”）隐式规格说明的威信来自其内容的说服力和可信性，而不是客户的批准。在大多数情况下，只有部分隐式规格说明与当前产品有关。其存在形式： 竞争对手的产品、相关产品、同一产品的老版本、项目团队之间的电子邮件讨论、顾客意见、图形用户界面风格指南、操作系统兼容性需求、测试员自己的丰富经验等。 34）“它没有问题”真正的含义是，它看起来在一定程度上满足部分需求。注意：测试员所认为的 “它没有问题”的意义，可能与别人的定义不同。 35）任何时候报告产品质量状态时，都应该用有关测试方
11、法和测试过程等已知局限性的信息对报告限定。因为不管测试员对产品的质量有什么看法，都只是猜想。 -36）不要将试验与测试混淆。测试需包括四个活动：配置、运行、观察、评估。 37）当测试复杂产品时，使用“陷入与退出”法（ plunge in and quit）。即，试着先研究复杂产品30 分钟或 1 小时，然后停下来干点别的。这个方法的优点是，除了选择产品的一部分进行研究外，绝对不需要计划。这个几个轮次的陷入与退出后，就能开始明白产品的模式和轮廓。 38）运用试探法快速产生测试思路。（试探法测试，如：测试边界、错误消息、与程序员不同的配置环境、比较难设置的测试、避免冗余测试等） 请注意：试探法中并
12、没有智慧，智慧来自测试员，试探法所能够做的，只不过就是为测试员的思考提出建议。在收集测试方法时，要了解每个方法背后的原理，以及适用和不适用的条件。 39）测试员不能 避免偏见，但可以管理偏见。多样化可抵御过强的偏向，测试员集体谈论测试问题，可将一个测试员的偏向降低到最低限度。 注意：试探法也是一种偏向，使用试探法，是因为其偏向可以以较好的方式引导测试员。 常见偏向： 同化偏向、证实偏向、可用性偏向（以头脑中已有的一种用户操作场景作为最常见的场景）、最初印象偏见、最新印象偏见、框架效应、知名偏向、表达偏向。 40）如果知道自己不聪明，就更难被愚弄。做到这一点并不难，只需仔细看看自己在测试中犯的错
13、误，且在考虑自己的测试策略细节时就会更认真一点。任何时候都要注意其它测试员发现 了本应自己也能发现但未发现的问题。 41）回溯漏测问题产生原因，是意外还是测试策略所致。 42）测试员的困惑，可能是某种重要的预示。（困惑内容，如：规格说明书不清楚；产品不清楚；用户文档不清楚？内部问题难以理解。） 43）新眼光或角度会发现失效。防止固化测试思路的三点提示： 第 1：第一次接触产品或功能时，要特别注意使自己困惑和烦恼的地方，因为用户也会有类似反应。 第 2：当与团队新成员一起测试时，观察他们在了解产品时的反应。 第 3：警惕陷入测试惯例。在任何可能的地方引入多样性，或改由其它测试员负责。 44）测
14、试员不能盲目遵循过程，除非过程先跟随自己。注意：其一：如果要遵循测试过程，最好采用自己设计、自己拥有或已经完全了解的过程。其二：为了得到最好结果，测试员必须掌握自己的测试，而不是自己的文档，即要使过程跟随自己。 45）在创建测试过程时，避免“ 1287”。即，编写测试过程时要避免与测试概念无关的细化，只需包含所有必要的信息和设计与解释测试所需的细节，但要让未来的测试有创造性和判断力地执行。 46）更好、更聪明的测试员是测试过程的一个重要成果。好的测试员永远都在学习。注意：在评估测试过程时，首先要看项目测试员的 素质，要看他们怎么思考，以及这种思考怎样对其行为产生影响，只有掌握了这些信息才能评估
15、他们的工作产品。 47）除非重新发明测试，否则不能精通测试。我们应该把东西分解，琢磨其工作原理，再以新的方式组装以适应新的条件。在学习过程初期，要重新发明不是非常好的测试、想法、手段和文档。这是正常的，要永远使头脑运转，观察其它测试员，研究和不断评估如何筛选自己的思想，要善于做到这一点，就必须实践。 测试手段： 48）关注测试员、覆盖率、潜在问题、活动、评估的组合测试手段。即“五要素测试系统”。建议：测试时要时刻想都会所有五 个要素， 可能做出更好的组合选择，而不是采用只关注一种要素的手段。 测试员：进行测试的人。 覆盖率：测试了哪些内容。 潜在问题：测试的原因（要测试什么风险）。如：测试不满
16、足这个需求的各种方式。 活动：如何测试。 评估：怎么判定测试通过还是不通过。 49）关注测试员的基于人员的测试手段。（如：强力测试、有关领域的专家测试、结对测试、自用测试） 50）关注测试内容的基于覆盖率的测试手段。（如：域测试、最佳代表测试、组合测试） 51）关注测试原因（针对风险测试）的基于问题的测试手段。（涉及约束冲突的错误例子：输入约束、输出约束、计算约束、存储（或数据）约束。） 基于风险测试设计建议： 第一：如果进行基于风险的测试，还需做相当量的非基于风险的测试，以针对了解还不够，还不能做出正确决策的风险进行测试。 第二：针对时序测试，如：竞争条件或其他事件意外发生顺序。 第三：在创
17、建测试时，需创建测试过程，以强制程序使用测试员输入的测试数据，从而能够确定程序是否不正确地使用了这些数据。 52）关注测试方法的基于活动的测试手段。（如：冒烟测试、探索 式测试、游击式测试、场景测试。） 53）关注测试是否通过的基于评估的测试手段。（如：与规格说明或其他权威文档比较、基于理念的测试） 启发式一致性。一致性是评估程序的重要评判准则。七种主要的一致性：与历史一致、与我们的想像一致、与可比较的产品一致、与所声明的内容一致、与用户的预期一致、产品内部一致、与用途一致。 54）根据自己的看法对测试手段分类。注意：进行实际测试时，仍需在五个要素方面进行决策，包括：谁来测试？要测试程序的哪些
18、方面？要寻找什么类型的问题？具体要完成的任务？如何确定测试是否通过？ 基于规格说明 的测试的可跟踪性矩阵：（优点：显示永远不会测试的功能及经常测试的功能点；当某个规格说明变更后，显示对测试影响范围。） 如何分析与程序的某个部分或方面关联的风险：分析可从两方面入手，其一：被测对象不能通过产品质量的某种重要度量（质量属性）；其二：考虑被测试对象可能出错的因素（问题起因）。 质量属性：例如：并发性（ concurrency）、标准符合性（ conformance to standards）、可伸缩性（ scalability）、可维护性（ maintainability）、效率（ efficienc
19、y）等 。 问题起因：例如：新功能、新技术、新市场、学习曲线、变更后的功能、后期变更、贸然的工作、差的设计或没有可维护性的实现、疲倦的程序员、其他的人员问题（例如：互不沟通）、意外溜入、外部组件、预算外、模糊、矛盾的需求、未知需求（开发过程中，新需求不断浮现）、需求变化、复杂性、问题过多、依赖性（失效可能触发其他失效）、不可测试性（缓慢低效的测试风险）、没经过单元测试的、未进行过系统测试、依赖狭窄的测试策略、弱的测试工具、不可修改性（不能修改错误的风险）、程序设计语言类型错误。 缺陷表的使用方法： a 在缺陷表中找到 一个缺陷。 b 研究被测量软件是否会有这种缺陷。 c 如果在理论上有这种缺陷
20、的可能，研究如果存在，应如何发现。 d 研究在程序中出现这种错误的可能性，如果存在会产生怎样严重的失效。 e 如果可以，针对这类错误设计一个或一系列测试。 程序错误分析（编写表达 BUG 报告） 55）错误报告，文如其人。 56）好的错误报告，能推动错误的改正。测试员的责任不是保证所有错误都得到改正，而准确报告问题，使读者能够理解问题的影响。 57）使自己的错误报告成为一种有效的“销售工具”。因为错误报告劝导人们付出宝贵资源来换取测试员所建议的好处。对于程序错误，资源就是时间和资金，好处就是通过改正这个错误而带来质量改进。销售策略一般有两个目标：其一：陈述种种好处，使得潜在客户想要它。 二：向
21、销售人员说明预期存在的问题，并反驳他们 。 58）错误报告代表的是测试员。 59）努力使错误报告有更高的价值。例如： 报告缺陷，并帮助程序员定位内部问题。 报告规格说明、测试文档、用户文档或开发工具中的问题。 为技术文档编写员提供背景信息，编写员要编写手册或公司网站中的问题定位部分。 报告提示需要通过客户培训解决的问题。 报告为客户售后支持人员提供关键信息，如他们会遇到哪些没被解决或不完全解决的问题。 报告和管理员提供正在开发的产品状态和质量信息。 报告在开始计划产品下一个版本时，提供初始改进建议。 60）任何产品 /项目的相关人员都应该能够报告程序错误。 61）引用别人的错误报告时要小心。注
22、意：一方面：如果没得到允许，可以补充评论，但不能编辑别人的材料，即使错误报告很糟糕也不要擅自修改因为很可能会遗漏重要信息的风 险；另一方面，任何时候要在（特别是其他人的）错误报告做补充，都要注明自己的姓名和日期。 62）将质量作为错误报告。（质量对于个人来说就是价值。）测试员的任务就是帮助项目相关人员写出清晰的其对产品感到没价值的意见。 63）有些产品 /项目相关人员不能报告程序错误，测试员就是他们的代理，所以应站在他们的立场理解要报告的内容。例如：测试员必须研究用户使用产品的方式，以及他们喜欢这种产品的什么，不喜欢什么。 64）将受到影响的项目相关人员的注意力转移到有争议的程序错误上。例如：
23、如果测试员认为很难说服程序员改正错误，但 是测试员希望改正，可以考虑公司中如果这个错误被改正能够受益的其他人。 65）决不要利用 BUG 管理系统监视程序员的表现。例如：使用该系统估算修改代码的时间，这样会使程序员感到为难外，其他程序员也就防备这个系统，最有可能的结果是，程序员争辩设计问题并不是程序错误，类似的错误是重复的等。 66）决不要利用 BUG 管理系统监视测试员的表现。例如：如果测试经理用 BUG 数作为考核依据，测试员也许会报告容易发现、更肤浅的 BUG，也许更愿意报告同个 BUG 多个实例；他们会不愿意花时间指导其他测试员；程序员更有可能认为测试员是为 了 BUG 数而不质量。
24、67）及时报告 BUG。因为 BUG 报告拖延的时间越长， BUG 被修复的可能性就越小；另一个风险是：项目其它相关人员就错误地以为已测功能点没 BUG 很稳定。 68）永远不要假设明显的 BUG 别人已提过。 69）测试员应报告设计错误。 70）极端的缺陷是潜在的安全漏洞。 71）使冷僻用例不冷僻。例如：极值测试思想：如果程序能够在这种条件下存活，那么在不那么极端的情况下也可以存活。因些可以通过少量极端测试了解很多东西。 72）小缺陷也值得报告和修改。 Kaner 和 David Pels 研究发现小缺陷（指修改 BUG 在 4 小时以内的 BUG）修改可避免该产品一半以上的技术支持成本。
25、注意：任何产品都会残留一些小缺陷。但随着小缺陷数量增加，客户信心会下降，更糟糕的是容忍这些缺陷的腐蚀作用。当连报告小缺陷的行为都停止后，测试员和公司就会容忍越来越多的严重缺陷，长此以往，最终会使产品失败。 73）时刻明确严重等级和优先等级间的区别。严重等级：指 BUG 的影响或后果；优先等级：指什么时候要求修复。 74）失效是错误征兆，而不是错误本身。因此，任何时候看起来很小的错误，都要：执行后续测试，以发现更严 重的征兆或以发现更一般的场景。当问题很难重现时，可执行后续测试，以确定使该问题重现的关键条件，然后执行后续测试，以充分暴露现在已可重现的问题。 75）针对看起来很小的代码错误执行后续
26、测试。如果看到的是小失效，不要只是重现该失效并写入报告。程序处于脆弱状态，尝试利用这一点，继续测试，并可能发现内部缺陷的实际影响是糟糕得多的失效，例如系统崩溃或数据损坏。 对于每个认为反映了编码错误的失效至少要做几分钟的后续测试，要相信自己的判断。建议尝试如下三种后续测试： a 变化自己的行为。（通过改变操作方式改变条件） b 变化程序选项和设置。（通过改变被测试对象的条件）例如：使用不同的数据库，改变持久变量的取值等。 c 变化软件和硬件环境。注意：这不是配置测试，不是要检查标准配置上的缺陷，而是要调查怎样变更配置才会使这个失效暴露充分。 76）永远都要报告不可重现的错误，这样的错误可能是时
27、间炸弹。注意：不要报告还没尽力重现的程序错误，但如果尽力之后仍不能重现该程序错误，仍值得报告，不过要明确说明自己不能重现这个程序错误。 77）不可重现的程序错误是可重现的。如下是无法重现时需注意的关注点： a 程序错误可能有延迟效应，例如内存泄 漏、指针越界。 b 程序错误可能只是在安装、使用产品或使用产品的特定功能时出现一次。恢复干净系统，重新装载该程序，检查现在是否能够重现该问题。 c 程序错误可能依赖于特定的数据取值或被破坏了的数据库。 d 程序错误可能只在特定的时间或日期内发生。检查日末、周末、季度末、年末。 e 缺陷可能依赖于以特定顺序执行一系列相关的任务。在执行这个失效任务前做了什
28、么？ f 程序错误可能是前面失效的残余。例如：上一次出现 GPF 后重新启动计算机了吗？ g 程序错误可能是由被应用程序与后台运行的其他软件，或与被测试应用程序竞争设备访问软 件的交互引起的。 78）注意缺陷报告的处理成本。 79）特别处理与工具或环境相关的程序错误。 80）在报告原型或早期个人版本的程序错误之前，要先征得同意。注意：在正式测试时，要把以前发现但仍没被修复的问题录入 BUG 管理系统。 81）重复错误报告是能够自我解决的问题。注意： a 不要让搜索时间失控。如果 BUG 数据库大，可能需花大量非生产时间搜索重复程序错误。 b 编写良好的相同 BUG 的所有报告都包含新信息，有助
29、于更容易修复 BUG。 c 两个报告是否重复还需再统一确认。两个失效可能是由同一个缺陷引起的，多个缺陷可能涉及到一个失效。要保留所收藏到的所有信息，直到确认统一并修复了该 BUG。 82）每个程序错误都需要单独的报告。 Pettichord 另一种建议： 有时为了提高效率，可以在一份报告中包含多个相似的小 BUG，假设这些 BUG 可以一次全解决。如果这个问题单状态标记为已修复后，仍有没修复的残余 BUG，可以为这些没修复的 BUG 写一份新报告，并引用已修复的老问题单号。 83） BUG 标题是错误报告中最重要的部分。建议包含的内容： a 简要描述，要足 够具体，使读者能够想像出该失效。 b
30、 简要指出程序错误的局限性或依赖关系。例如： BUG 产生的环境局限。 c 简要指出程序错误的影响或后果。 84）不要夸大程序错误。记住，测试员的可信性是影响力的基础。 85）清楚地报告问题，但不要试图解决问题。 86）注意自己的语气及报告的格式。例如：全部采用大写字母，则读起来像是编写报告者在尖叫。 87）使自己的报告具有可读性，即使阅读对象是劳累和暴躁的人。要使重现步骤的描述简洁： a 一次只走查该程序错误一步。 b 为每一步编号。 c 不要跳过重现问题所需的任何步骤。 d 尽量写出 能重现的最少步骤。 e 通过空行使报告更容易浏览。 f 使用简短句子。 g 说明实际发生了什么，自己预期会
31、发生什么。 h 如果后果很严重，可解释为什么自己认为很严重。 i 便于程序员意识到问题或便于自己回归测试，可补充注释。 j 对于复杂产品或问题，考虑使用描述的头三行专门小结问题，然后给出问题细节。 k 要始终保持中立语气。 l 不要开玩笑，别人会产生误解。 88）提高报告编写技能。研究 BUG 管理系统的 BUG，找出提高报告编写技能的思路。例如： a 比较已修复的 BUG 和未修复的 BUG，研究两都报告方式的差别。 b 研究程序员对错误报告的反映。例如：什么使他们困惑不解、不能接受、能够接受？ 89）如果合适，可使用市场开发或技术支持数据。例如： a 可与同行产品进行比较，有助于描述用户预期及有助于市场开发经理评估问题的严重等级。 b 调查市场与客户接触时都遇到什么问题，他们如何说明产品，演示什么，怎么演示，在报告中使用调查结果。 c 如果可能，将报告的 BUG 与相关的技术支持记录联系起来。可估计延迟修复 BUG 的技术支持成本或如果 BUG 留在产品中将会面临客户或技术支持人员的不满。
