测试员的角色

经验一：作用

什么时候测试人员都要了解项目的进度和问题，找到信息，知道项目进行的大概方向，正确的引导项目组一步步到达目的地（类似前灯一样的作用）

经验二：使命

快速找出重要软件问题

对产品质量提出总体评估

确认产品达到某种具体标准

帮助客户改进产品质量和可测试性

保证测试过程能够达到可分清责任的标准

就测试和与测试员协作方式培训客户

采用特定的方法集或遵循特定的规则集

帮助预测和控制成本

帮助客户改进其过程

以最小成本、时间或尽可能减少副作用的方式，完成自己的工作

为满足特定客户要求，完成所有必要的工作

测试员必须明确原因：

测试员不知道自己该做什么的时候，可以凭此找出自己的核心问题。

测试员知道自己该做什么的时候，重新考虑使命可以使自己不会过于偏重某一个测试问题而忽略其他问题。

明确自己下一步要做什么。

可为自己工作辩护，简单描述，向他人解释自己的角色。

而且在紧急时刻，因为某些原因不能完成自己的使命，则需立即汇报给管理层。

经验三：服务角色

1.项目经理

迅速报告重要问题，不要成为项目瓶颈

测试员的责任就是告诉项目经理自己能做什么，不能做什么，有关项目的决策和条件会对测试产生什么影响

2.程序员

迅速的提供有质量的错误报告，提供自己技能了解产品更好的定位错误。这样能更好的协助程序员，同时赢得信任，获取支持和影响。

3.技术文档编写员

可帮助技术文档编写理解产品怎样发挥效能，指出文档中的错误。当技术文档编写研究产品是也会了解到一些测试员不知道的信息，这样测试员如果和技术关系好也能了解到一些产品新特征，新用法，计划中的漏洞和他们所发现的软件问题。

4．技术支持员

遗留在产品中的任何问题都会为技术支持员带来担忧。

测试员通过告诉技术支持远可能会给用户带来的麻烦的产品问题，向其提供服务。

技术人员在测试过程中帮助测试员找出应该更正的问题，测试员通过现场测试发现的难题，为技术支持员提供帮助。

5．市场开发员

市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。

程序中的小问题，可能是用户较难完成的某种重要任务，所以对市场开发员来说就至关重要了。通过评审市场开发计划文档或描述，测试员可以帮助市场开发员对产品能力有更精确的认识。

6.管理层和项目相关人员

测试员服务公司业务。测试员必须小心，不要像个质量狂，而不是通情达理的人。特别是到了项目要结束的时候，测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要以明确，简洁的词汇编写测试状态和报告，以便执行经理能够感到有做抉择的依据。

7．用户

在测试员的心中，要想着将要使用该产品的人。用户的满意是项目的最高利益。但是要考虑主要用户对项目团队的特殊要求。

经验四：测试发现的信息会“打扰”客户

测试团队的使命包括根据客户对价值的定义，通知客户有关威胁产品价值的任何信息。如果发现产品能按照意图运行，但是达不到所要求价值，则测试员有责任报告，如果忽视报告，那是他们的权力。

经验五：迅速找出重要问题

先测试变更部分，在测试没有变化部分。

先测试核心部分，再测试辅助功能，测试关键常用功能，再测试基本任务的功能。

先测试能力，再测试可靠性。先测试每个功能是否完全能用，然后在深入检查每个功能在很多不同条件下表现如何。

首先测试常见情况，然后测试少见情况，使用常用的数据和使用场景。

首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。

首先测试影响大的问题，然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。

首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。

经验六：跟着程序员走

迅速回归问题，迅速找出问题。最理想情况是，程序员为了修改测试员找出的程序问题忙得团团转，是程序员，而不是测试员，成为项目的瓶颈。

经验七：询问一切，但不一定外露

不问问题当然可以测试，但是不可能测试得好。不过很直白的问题会刺激别人，常常使人产生顾虑。

问题是一剂猛药，最好是采用低剂量，或者与饭一起吃（结合其他沟通形式）

经验十：当心“完备的”测试

完备测试可能的定义

完全发现了产品中每个问题

完全检查了产品的每个部分

完成了自认为是有用、经济的测试

尽自己所能，完全达到了项目团队制定的目标

完成了约定的测试

完成了在一定条件下人所能够测试的所有内容

完成了自己知道如何测试的所有内容

完成了自己所承担的测试部分，不考虑其他人的工作

完成了对产品很广，但是不深的测试

完成了对产品的一种测试

用完了分配给测试的时间

解决完备测试普通沟通问题，可让客户详细了解测试过程。

总结自己实施的测试，以及为什么值得实施这些测试，并告诉客户自己没有做的其他值得做的测试，以及为什么没有做这些测试。

经验十一：通过测试不能保证质量

质量来源于构建产品的人，有时这对他们来说是要背负的沉重负担。测试员使命中的一大部分，就是帮助他们更有效地对付真正的负担。

测试员不应该是唯一关心交付好产品的人

经验十二：永远别做看门人

产品发布否决权如果有测试人员来行使，那么团队其他成员会为此放松一点，甚至是大大的放松。如果问题逃过测试和项目团队，他们团队其他成员也会责备测试员。另外延误发布，会被严厉追究责任的。

如果一定要一个人来承担，最好要由控制项目，条件最好的人承担发布产品的责任。大多数非常有效的团队，都采取某种方式的集体决定是否发布产品。要坚持与项目团队的其他角色一起分担这种权力。

经验十三：当心测试中不关我事理论

产品规格说明太模糊；程序员交付代码太慢；测试问题不被重视，被认为是测试人员主观臆想等外在原因，可能会使测试员不得不放狠话说出了问题不关我事，当然情况严重或许这样做不错。但是首先应该考虑下自己的期望是否符合实际情况，是否有其他方式能够得到自己所需的条件。

如果测试员摆正心态，认为自己的工作就是付出合理的努力去适应和灵活应对各种情况。则程序员或更愿意与测试人员打交道，不会心理上排斥测试人员，反过来促使他们把帮助测试人员当做是自己的事。

经验十四：当心成为过程改进小组

希望能通过不需要测试的方式达到质量过关，因而去要求其他团队该如何如何做。只会适得其反，让其他团队绕过测试，让测试变的无能。

经验二十三：测试员不只是游客

测试员把精力放在评估产品上，而不是见证产品

姿态：如果问题存在就会有相应的行为。由此来说服改进问题。

经验二十四：所有测试都试图回答某些问题

执行的测试都是要回答有关现实的产品和应该得到的产品之间关系的某个问题。

在任何测试活动中，都要问自己什么样的问题应该推动自己评估测试策略，否则就会更像游客，而不是测试员。

经验二十六：直觉是不错的开始，但又是槽糕的结束

当有问题时，测试员以此处有问题，我直觉认为这是问题。可考虑换中方式，用事实依据说明问题与某需求冲突，直接关系到客户很看重的需求。

如果只是用直觉来说话，大家都有直觉，很可能测试员的工作建议不会被采纳。

经验三十二：通过会议、推导和参照发现需求

需求文档或多或少是不完整、不准确、没有提供信息或没有帮助的。

测试员把项目文档，看作是唯一需求来源会影响测试过程。

需求信息达到测试员主要有三种途径：

》会议。

》推导。通过已知项目和产品其他信息，确定什么需求最重要。

》参照。既发现显式，也发现隐式规格说明。

很多优秀的测试员所使用的大多需求来自推导或隐式规格说明。 

显示说明来自客户权威确认，隐式说明来自其内容的说服力和可信性，而不是客户的批准。

隐式规格说明形式：

>竞争对手的产品

>相关产品

>同一产品老版本

>项目团队之间的电子邮件讨论

>顾客意见

>杂志文章（例如，老版本的综述）

>相关主题的教科书（会计书籍适应于会计应用程序）

>图形用户界面风格指南

>操作系统兼容性需求

>测试员自己的丰富经验

经验三十五：不要将实验与测试混淆起来

测试至少包括的四种活动：

>配置。准备要测试的产品，都要将其置于正确的起始状态，否则测试结果会受到不良变量的影响

>运行。向产品输入数据，向产品发命令，以某种方式与产品交互。否则，产品只是放在那里，测试员能够做的只是评审，而不是测试。

>观察。最终知道问题所在

>评估。得到问题存在的机制（构造和原理），否则要么不提交问题，要么值提供数据，由客户自己进行评估。

经验三十七：当测试复杂产品时：陷入与退出

遇到复杂问题时，先试着冷静研究产品一段时间，如果过了1个小时还是没有任何结果，则停下来干点别的，等其他问题都解决了再来研究。

经验三十八：运用试探法快速产生测试思路

常用试探法：

测试边界

测试所有错误信息

测试与程序员的配置不同的配置

运行比较难设置的测试

避免冗余测试

试探法没有智慧，智慧来自测试员。试探法只是为测试员的思考提出建议

经验三十九：测试员不能避免偏向，但是可以管理偏向

测试员是有偏向的，有时编辑一个很长的字段，测试员会输入11111111，而不是23875019460，因为输入字符重复的字符串，要比0-9的随机数字容易。这是种很小的偏向，但仍是一种偏向。

更糟糕的偏向是，大多数测试员倾向于测试最可视的功能，而不是最重要的功能。

倾向于考虑认为与自己类似的客户。

倾向于十余非常简单、非常荒谬的输入，而不是具有中等复杂度的现实输入。

常见偏向：

同化偏向。把测试结果解释为自己对产品的看法。

证实偏向。更关注会证明自己对产品看法的测试结果。

可用性偏向。更容易认为自己想到的操作方式常出现。

最初印象偏见。更信任所做的第一次观察。

更新印象偏见。更信任所做的最近一次观察。

框架效应。一个问题相似表达却导致了不同的决策判断。程序员对错误报告的反应与错误本身的表达和措辞有很大的关系。不管错误真正的含义如何。

知名偏向。把碰巧认识的用户意见放在更重要的位置

表达偏向。期望较小的问题也许有较小的原因，而严重问题会有大原因。

测试员不能避免这些偏向，因为这些偏向已经很大程度固话在头脑中。

解决方案：

通过研究偏向在实践中注意，则可以更好的补偿。

多样化也可以抵御过强的测试偏向。如测试员集体讨论问题，可以将一个测试员的偏向降到最低限度。

经验四十：如果自己知道自己不聪明，就更难被愚弄

测试是需要时刻谨慎的，不能疏忽大意。要常记教训。

经验四十一：如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果

出现遗漏问题先不要过分自责，最需要的是带着解决问题的思路，检查问题是如何出现的。

自己是否忠实的执行了策略？是特定情况意外发生？如果是第二种则趁此计划改善策略。

经验四十二：困惑是一种测试工具

当测试员感到困惑时，这可能是某种重要提示。

规格不清楚吗？掩盖了重要分歧

产品不清楚吗？产品有严重问题      

策略不清楚吗？策略不够详细或者逻辑有问题

流程复杂吗？导致部门间配合沟通困难

经验四十三：清新的眼光会发现失效

初次接触产品时，需特别注意困惑的地方，这也许就是用户使用时感到困惑之处。

工作时，可观察同事对产品的反应，从中了解自己的不足和盲点

警惕陷入测试惯性。测试完毕后，回归和多轮测试最好是交替测试，警防以越来越窄的方式测试。

经验四十四：测试员要避免遵循过程，除非过程遵循自己

？不懂，后期参阅相关书籍

经验四十五：在创建测试过程时，避免“1287”

测试员按照具体的测试过程小心的输入1287个字符

过于详细没有什么好处。

在编写测试过程中，要避免与测试概念无关的细化。包含所有必要的信息和设计与解释测试所需的细节，但是要让未来的测试员有创造行和判断力的执行，让未来测试员引入变化以使现在所编写的测试过程新鲜、高效

经验四十六：测试过程是一个重要成果：是更好、更聪明的测试员

评估测试过程，首要要看项目测试员的素质，要看他们是怎么思考的，以及这种思考怎么对其行为产生影响。只有掌握的这些信息，才能更好的评估他们的工作产品。

经验四十八：关注测试员、覆盖率、潜在问题、活动（如何测试。如探索式测试）和评估的组合测试手段

测试员：进行测试的人。不同的测试阶段需要不同的人来进行测试。如，内部测试则需要专业的测试人员，α测试是内部其他成员进行测试，β测试则需要真正的用户进行测试，市场运营代表。

覆盖率：测试的范围，测试的功能点。

潜在问题：测试的原因，不测试会有什么风险。

活动：是否通过测试，怎样判断是否通过测试。

经验五十：关注测试内容的基于覆盖率的测试手段

功能测试

特性或功能集成测试

菜单浏览

域测试

等价类分析

边界测试

最佳代表测试

输入字段测试大纲或矩阵

用各种方式映射和测试编辑字段

逻辑测试

基于状态测试：让程序完成能做的事，尝试不能做的事，每做一件事程序都会有其对应的状态。

路径测试：主要路径和子路径测试

语句与分支覆盖

配置覆盖率

基于规格说明的测试

基于需求的测试

组合测试

经验五十一：关注测试原因原因基于问题的测试手段

输入约束

输出约束

计算约束

数据（存储）约束：输入、输出、计算均没有问题，产生数据文件太大，程序不能处理

经验五十二：关注测试方法基于活动的测试手段

回归测试：其目标是为了证明变更使得原来没有问题的程序现在变得有问题了。

共有三种回归测试

1.      程序错误得到更正后，再针对性的测试

2.      老程序错误回归：回归的bug还是没有更正好

3.      副作用回归又叫稳定性回归：看程序没有的问题的地方是不是现在变得有问题了

脚本测试：低级程序员运行已经录制好的脚本测试

冒烟测试：新版本发布前，确认基本功能是否实现。或者是更新版本确认修改后的问题是否修复。或者是进行性能测试前，进行基本功能确认的测试。

探索式测试：测试员在不断了解产品和增长知识的前提下，不断创新测试。

游击式测试：有经验的测试员在有限的时间内，对软件进行重点、有目的、有攻击性行的测试。

场景测试：

场景包含四个属性：

1.      反应真实情况的场景；

2.      一般是多种复杂情况的组合，包含多个功能，但是不需要穷尽测试；

3.      能比较快速的得出结；

4.      没有通过测试则需要求立即修改，否则不能通过上线。

安装测试：不同系统上安装，或者磁盘上修改某个文件测试。

负载测试：通过不断加载的方式，查看系统在超负载的情况下是否能正常运行。

压力测试：在高负载的前提下，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

压力测试可以说是负载测试的一种，即高负载的负载测试。

长序列测试（或叫持久测试、可靠测试、耐力测试）

性能测试

经验五十三：关注测试是否通过的基于评估的测试手段

比较权威的数据范围，校验数据

与规格说明或者其他权威文档比较

与已经保存的结果进行比较

基于理论的测试

经验五十七：使自己的错误报告成为一种有效的推销工具

陈述种种好处，说明潜在的用户需要

说明预期问题，并反驳他们的不愿意修改的理由

经验六十：引用别人的报告要小心

不要修改别人的报告，补充时需注明时间和姓名

经验七十二：小缺陷也值得报告和修改

四小时不包括测试时间内能修改好的bug,称之为低成本修改。这样的修改能杜绝用户后续抱怨，低成本修改可避免产品一半以上的技术支持电话。

任何程序都会有些小缺陷，但是随着小缺陷的增加会使客户信心下降。

用户的满意度，会直接增加产品的市场份额。

经验七十三：失效是错误征兆，不是错误本身

小问题可能是程序结构或者内部指针失效等严重错误导致。需要重视，并且有相应的后续测试。

不可重现的错误

1.任何时候尽力重现，没有重现的错误都需要报告，这样的错误可能是时间炸弹。

测试员不能重新的错误，程序员可以通过对程序的了解程度，定位到问题，或者后期再出现时测试人员也可以根据报告和现有信息重新问题。

2.不可重现的错误是可重现的。

可能是操作顺序