软件测试的经验和教训

1. 认知心理学是测试的基础。

>>>对事物的认知程度，才能对事物做出评价。对事物没有任何认知和了解，就不会有判断<<<

2. 与测试有关的一些问题：

a.人的感觉和记忆可靠性

b.信念从哪里来

c.信念如何影响人的行为

d.做出决策所使用的偏见和捷径

e.如何考虑复杂事情

f.在压力下如何思考

g.如何识别模式

h.如何把想法和事物分类

i.如何注意事物之间的差别

j.记忆事件中的失真

k.如何重新构建部分记忆的事件（例如不可再现的程序错误）

3.优秀测试和平庸测试之间的差别在于测试员如何思考：测试员的测试设计选择，解释所观察到的现象的能力，以及非常令人信服地分析描述这些现象的能力

4.测试需要推断，并不只是做输出与预期结果的比较

5.优秀测试员会进行技术性、创造性、批判性和实用性的思考

*技术性思考。对技术建模并理解因果关系的能力。这包括诸如相关技术事实的知识和使用工具并预测系统行为的能力

*创造性思考。产生思想并看到可能性的能力。测试员只能以能够想象得到的方式进行测试，只能寻找猜想会存在的问题

*批判性思考。评估思想并进行推断的能力。这包括在自己的思考中发现并消除错误的能力，将产品观察与质量准则关联起来的能力，以及针对特定信念或所建议的行动过程构建有说服力的测试用例的能力。

*实用性思考。把想法付诸实施的能力。这种能力包括诸如运用测试工具，并使测试手段和力量与项目范围适应的技能。

6.所有测试都基于模型. 不管模型是什么，测试都主要基于产品模型进行，而不是实际产品

 

>>>如何建模是一个很重要的技能<<<

7.直觉是不错的开始， 但又是糟糕的结束

>>>直觉可以是依据，但不可以是证据。<<<

8.最后，测试员所能得到的只是对产品的印象

不管测试员对产品的质量有什么看法，都是猜想。不管猜想有多么好的支持，也不能肯定自己是对的。因此，任何时候报告产品质量状态时，都应该用有关测试方法和测试过程的已知局限性的细心，对报告进行限定。

>>>根据依据来定论。<<<

9.人们可以做的所有测试都可以在五个方面进行描述：

*测试员。进行测试的人。例如，用户测试是由目标市场的成员、通常使用该产品的人进行的转向测试

*覆盖率。测试了哪些内容。例如，在功能测试中，要测试每个功能

*潜在问题。测试的原因（要测试什么风险）。例如，测试极值错误。

*活动。如何测试。例如探索式测试

*评估。怎样判判定测试通过还是不通过。例如，与已知正确结果的比较。

10.关注测试员的基于人员的测试手段

*用户测试(user testing)

*阿拉法测试

*Beta测试

*强力测试(bug bash). 利用秘书、程序员、市场开发人员和可以找到的任何人所实施的内部测试。强力测试一般持续半天，在软件接近投放市场时进行。

*有关领域的专家测试（subject-matter expert testing)

*成对测试(paired testing)

*自用测试(eat your own dogfood)

11.关注测试内容的基于覆盖率的测试手段

*功能测试

*特性或功能集成测试(feature or function integration testing)

*菜单浏览(menu tour)

*域测试(domain testing)

*等价类分析（equivalence class analysis)

*边界测试(boundary testing)

*最佳代表测试(best representative testing)

*输入字段测试大纲或者矩阵(input field test catalogs or matrices)

*用各种方式映射和测试编辑字段(map and test all the ways to edit a field)

*逻辑测试(logic testing)

*基于状态的测试(state-based testing)

*路径测试（path testing）

*语句与分支覆盖(statement and branch coverage)

*配置覆盖率(configuration coverage)

*基于规格说明的测试(specification-based testing)

*基于需求的测试(requirement-based testing)

*组合测试(combination testing)

12.关注测试原因（针对风险测试）的基于问题的测试手段

>>>对于深层次的问题，这个比较奏效.<<<

13.关注测试方法的基于活动的测试手段

14.关注测试是否通过的基于评估的测试手段

15.努力使错误报告有更高的价值

错误报告的用户：

*报告提示大家注意缺陷，并帮助程序员定位内部问题

*报告提示大家注意规格说明和(取决于公司政策）测试文档、用户文档或开发工具中的问题

*为技术文档编写员提供背景信息，编写员要编写手册或公司网站中的问题定位部分

*报告提示需要通过客户培训解决的问题

*报告为客户售后支付人员提供关键信息，他们会遇到还没有被解决或没有完全解决的问题

*报告向管理层正在开发的产品的状态和质量信息

*报告在开始计划产品下一个版本时，提供初始改进建议

16.清楚的报告问题，但不要试图解决问题。

测试员的工作是报告问题，而不是确定根源，不是奋力争取具体的解决方案

>>>试图解决问题，看起来像是不务正业, 但是现在，能够定位问题却是一位优秀测试人员必备技能<<<

17.如果决定据理力争，就一定要赢。

我们强烈建议读者要遵循的原则是，所要做的每个上诉都必须是有说服力的。即使不能赢得所有上诉（当然不会赢得所有上诉），也应该得到自己的所有上诉理应获得的好名声。

18. 在决定要自动化的内容时，首先设计自己的测试。这样可以避免落入自动化测试的陷阱：易于自动化，但是在找缺陷上很弱。

19. 采用与设计手工测试不同的方法设计自动化测试

自动化测试的力量，很大程度上来自利用计算机完成人所不能做的事。

*没有好的测试设计的自动化可能会产生大量活动，但没有什么价值

*没有很好理解自动化可能性的测试设计，可能会低估一些最有价值的自动化机会

20.测试自动化需要程序设计、测试和项目管理方面的技能。

如果不重视管理，自动化项目就可能不会实际达到最初预想的目标。不要让自动化成为副产品，不要让兼职人员承担。

21.在自动化测试设计上不要吝啬

以下是在设计自动化测试时应该明确考虑的问题：

*保证测试已经被正确的设置

*描述预期结果

*发现潜在错误和副作用

*从潜在测试失效中恢复

*繁殖测试相互干扰

将测试设计形成文档，以便以后使用该测试的人能够从现在的设计思想得到一些启发。

22.避免在测试脚本中使用复杂逻辑

23.数据驱动的自动化测试更便于运行大量测试变种

24.关键词驱动的自动化测试更便于非程序员创建测试

关键词驱动的自动化测试建立在数据驱动手段上

25.可测试性往往是比测试自动化更好的投资

26.在决定要构建的产品之前先分析需求，这一点既适用于软件也同样适用于文档

27.将关注点放在产品上，而不是人上。

28.程序员喜欢谈论自己的工作。应该问他们问题

29.不要尝试建立一种控制文化。

测试员常常收到并给出有关项目应该如何管理的详细建议。我们觉得这些建议在很大程度上太天真。最差和最武断的建立都来自其开发经验值局限于测试（或度量和评估——其他人工作的测试员和顾问。

30.测试经理管理的是提供测试服务的子项目，不是开发项目

有时项目经理会犯错误，有时会受益于测试经理的建议。测试经理要通过各种方式提出建议。要吧自己的想法说出来。但是如何运作项目的决策权在项目经理手中。如果项目经理没有采纳自己的建议，那么接受现实。

如果项目经理和执行经理做出差的决策，有时对测试人员做出不恰当的批评，要求连续加班，要求绝对服从他们。这已经超出项目经理合理的职权范围。作为测试经理，自己工作的一个很重要的部分就是要保护下属人员不被滥用

31.项目涉及功能、可靠性、时间和资金之间的折衷

项目经理的任务就是按时并在预算限度内交付一组合适的功能，达到合适水平的可靠性。这是一种具有挑战性的折衷。

*功能。选择合适的功能集，交付所有项目相关人员所要求的一切功能太昂贵。

*可靠性。使产品能够正常运转，但不能花费无限时间和资金保证在所有能够相像出的环境下都能完美的运行

*时间。尽可能迅速的将产品投入正式使用或销售

*成本。以最低的合理成本构建产品。成本包括资金和机会成本。当把关键资源（特别是技术熟练人员或独特设备）用于项目团队时，其他项目团队就不能使用该资源。

32.了解程序员在交付版本之前会做什么（以及不会做什么）

33.“足够的测试”意味着“有足够的信息可供客户做出好决策”

34.不要只为两轮测试做出预算

>>>第一轮测试后，测试人员可能会调整好的测试，并找出新问题。测试经理采用两轮模型就会在第二轮测试中穿插新测试就会受到很强的抑制。第一轮测试，并不是所有的测试都能运行，有些去缺陷会妨碍一些测试的执行<<<

35.轮换测试员的测试对象

36.尽量成对测试

测试是一种思想生成活动，而不是计划实现活动。测试是一种在一种开放的多维空间中启发式搜索过程，成对测试有利于每个测试员解释思想，并对其做出反应。

我们强烈建议在开始测试之前，每个测试对子要先有个约定。来开计算机，画上10~15分钟时间考虑接下来的一两个小时的工作方向。

37.为项目指派一位问题查找高手

问题查找高手是经验丰富、热心探索的测试员。以下是我们使用问题查找高手的一些方式：

*对有怀疑的部分进行初步探索式测试，形成更细致的跟踪的想法，这可以让经验不足的测试员执行

*探索被认为是风险很低的部分----问题查找高手能够快速找到导致重新评估风险的程序代码吗？

*定位看起来很容易引起不可重现问题的关键部分

*找出关键程序错误，以说服项目经理推迟（不成熟的）发布日期

38.定期状态报告是一种强有力的工具

测试小组的真正力量来自沟通，不是监管

39.如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对改产品的看法

40.在产品最终发布报告中列出没有排除的程序错误

41.阅读自己员工完成的错误报告

42.不要指望别人能够高效处理多个项目

43.积累自己员工的专业领域知识

可以通过多种途径积累真正的专业领域知识：

*阅读面向类似产品客户的杂志和书籍

*参加教授客户如何使用类似本公司正在开发产品的产品学习班

*参加与产品的下层主题有关的学习班

*在客户现场工作

*推销自己公司或竞争对手的软件

*每周利用几个小时回答公司技术支持热线电话

44.积累自己员工相关技术方面的专门知识

45.积极提高技能；浏览技术支持日志

46.帮助新测试员获得成功，让新测试员对照软件核对文档

47.通过正面测试使新测试员熟悉产品

48，让新测试员在测试新程序错误之前，先重新测试老程序错误

*重现现在还没有关闭的程序错误

*重新测试已经解决的程序错误

*重新测试已经解决但还没有关闭的程序错误

49.不要派测试新手参加几乎完成的项目

>>>几乎完成的项目，对于测试新手有一个很大的障碍是不知道如何去使用它。这个时候，需要一些时间编写测试详细步骤提示，供测试新手使用。测试新手的工作一般会浪费大量高级测试员时间<<<

50.员工的士气是一种重要资产

*礼貌的对待员工，尊重员工

*注意他们的工作

*称赞好的工作、热心和诚实努力

*如果员工加班，测试经理也要加班。不一定要每晚，不一定每个周末

*如果可能，为员工指派他们感兴趣的任务和项目。鼓励他们说出自己的兴趣，并给予考虑

*如果测试员任务完成的不够顺利，可指派别人给予帮助、指导，如果有必要还可以接替）让其承担其他任务）

*提供培训机会。表现出测试经历很看重技能和专业发展

*测试经理要公平对待员工，并且要求别人也公平对待他们

*不要对任何一位员工产生误导。如果测试经理不知道问题答案，就实话实说。如果只凭感觉，则应该明确表明自己是在猜测，而不是根据知识

*不要对员工叫喊

*避免公开批评员工

*不要与员工私下评论其他小组内的员工