一、关于测试和探索

软件测试就是与软件或系统进行交互、观察其真实行为与你的预期比较是否一致。

作者认为：在 测试之前一切都只是推测，应该以实验结果作为采取行动的依据。测试不断探索和做实验的过程。

 

1.测试的两面：

作者认为测试应该包括，两个方面：a.检查软件是否满足预期、b.探索风险。

a.检查软件是否满足预期，就是基于传统的测试策略、测试设计与测试执行的过程，投入的人力越多可能网织得越密，测试的完备性会做的越好，然而终究是难以做到“无遗漏”的测试。总会有一些漏网之鱼。

b.在a的基础上进行一些探索性测试，总能发现惊喜，探索性测试hn是在已有系统的基础上设计实验、快速连续的执行实验、并将得到的结论用于下一次的探索，也是一个迭代过程。

2.探索性测试的要求：

1>探索性测试是一种风格:

     他依赖于个体测试人员的能力和经验；强调测试人员持续改进自身工作价值的意识。

2>探索性测试与其他测试的区别：

    常规的ST,CT会先做测试设计后做测试执行。二探索性测试(ET)强调，测试设计、测试执行同时进行，并在这个过程中不断学习被测系统。而每次迭代又依赖于上一次迭代得到知识和经验。

    a.对系统学习不断深入，测试的深度也不断加大。

    b.确保好的测试思路得意固化。

    c.不断更新的测试视角。

    d.以小的时延、时间、发现、应用新的视角。

3.关于ET活动的开展：

 1>测试是有成本的也需要时间管理，如何解决时间管理问题:

     采用，SBTM(基于探测会话的测试管理)    //本章暂时未展开

 2>如何防止测试的随意性？

    确实ET如果管理的不好容易失控，变成了ST人员仅仅为了狩猎EC而采用行为了，出发点可能就走偏了。如何确定探索的范围和方向？是一个问题，本章节提到了一点，ET需要做好测试记录。在不断探索的过程中需要记录好测试思路、问题、风险,收获......可能还无法完全解答这个问题。

4.ET测试可以考虑的几个方向（以前的经验总结）：

    a.利用相近产品，类似领域产品的测试经验进行测试。

    b.利用相同产品以往的测试经验进行测试。

    c.利用以往的缺陷进行测试。

    d.利用体系结构图和用例。（根据产品的设计，分析现有测试设计的不足）

    e.利用错误和异常。

    f.问题和检查单。

5.其他和思考和疑问：

 1>ET适用的范围：

     从第一章的学习和以往对ET的经验来看。ET感觉更多是面向产品评价的，而不是面向开发过程辅助的。似乎更适合传统的ST团队？如何在敏捷开发团队应用？（先作为学习问题，看后续章节是否有解答）

2>ET与其他敏捷实践的配合问题：

    目前开发团队中在推行“实例化需求“工作。个人感觉在敏捷转型过程中，ST团队 ET工作 的开展一定要和开发团队的“实例化需求”等敏捷实践放在一起考虑。目前在“实例化需求说明“的时候是从用户的业务目标中划定范围，输出有限的"关键实例"，而很少去考虑质量属性相关内容。而ET测试关注的重点又是在质量属性这块，个人觉得在相关干系人共同制定实例化需求的时候，可以也把质量属性和ET的内容、策略放进来讨论，也达成一致。

 

 二、为探索制定章程

探索未知地域  VS 软件探索性测试

■相同点： 都需要制定章程。否则探索未知地域容易迷失方向，而ET则会出现很大的随意性难以管理。

■对于ET来说章程的制定，是要根据一定目标的，这个目标就是软件项目相关干系人感兴趣的信息，要对项目有价值，是项目最为关注的风险。

1.章程模版：

a.探索(范围)

    探索的范围，即探索何处？某个需求？某个模块？某个特性？

 b.使用

    使用的工具、资源、数据、技术.....

 c.信息

    系统质量属性的某个方面(性能、安全性、可靠性等...)；协议一致性，设计一致性 等等...

(不要局限于模版的形式，要把更多的精力放在探测会话的意图上。)

 

2.优质的探测章程：

   即是一个提示信号，它指出了灵感之源，又避免了对行动或结果 做出了事无巨细的规定。（粒度合适）

 

    ■探测章程 ≠ 测试用例  （过分暴露细节）

    ■探测章程也不能太泛（无法聚焦、难以分辨探索是否完成）

    每个章程都 应该专注一个单独的区域，比如：探索某种类型的安全漏洞 

 

3.章程的产生：

■达成一致：

   在敏捷实践中，都特写强调干系人的协作，比如《实例化需求》中，相关干系人共同确定关键实例、验收、回归准则。在ET探测章程的制定过程中同样强调协作，达成一致，因为：

 

1>讨论自己的“设想“、”担忧“，多大程度吻合了其他干系人的担忧，以确保这个"设想"又去做探索的价值。

（个人理解是应该避免为了EC而去找EC,避免那些耗费大量精力却对于整个软件产品交付的价值却不大的探索）

 

2>挖掘出这些”设想“的信息却无其他干系人的响应是无价值的。

3>在尚未开始探索前就暴露分歧，缓解你的担忧，也为整个团队提醒，提高整体的意识。

 

■在需求的讨论过程中，得到探索的Idea：

1>在讨论的过程中任何一个不明确、不确定的和依赖关系的存在，都是值得探索的。

2>在讨论的过程中也是发现新需求的机会，和干系人一起评审你的建议。

（和MFQ测试设计 及其敏捷 实践所要求的一样 ,测试不能仅仅作为一个”后端“的行为，在需求阶段就进行测试相关活动，确保 做正确的事）

■隐性需求：

需求分为显性需求和隐性需求（隐性需求往往容易被忽略）发现用户一个值得探索的隐性期待时，把它作为探测章程。

 

■仔细斟酌设计时会是发现有价值的探索，制定章程的好时机 ：

(获取特性足够的 Information,包括设计、实现)

■现有工件：

走查代码，历史缺陷

 

■在不间断的探索中，更新章程：

1>ET要持续开展，并不断更新测试的视角。

2>在探索过程中发现新的Idea，记录，并在 后续的ET中进行探索。

 

4.噩梦头条游戏：

1>设想所交付的软件发生重大灾难（通过一个新闻的形式）。

2>相关干系人共同设想这个新闻可能包括的内容 。（各种各样的视角，获得相关干系人最关注的风险）。

3>选择共同认为的（没有则采用积累投票法产生）最关心噩梦（风险）。

4>头脑风暴找出原因。

5>将原因提炼为探测章程。

 

三、观察细节

这一章作者更像一位有着丰富测试经验的师傅，很接地气的告诉了大家通过关注细节来发现软件缺陷的案例和思路：

1>看见那只熊了吗？

  

“月球漫步熊"的例子说明了一个道理，人越是专注于某一件事物，越容易忽略其他显而易见的事物。

  

  就好比低头玩手机的时候，一个熟人从身边走过甚至给自己打招呼都视而不见....

   作为软件测试，只专注于一个维度的测试时，很容易漏过其他维度所带来的惊喜，比如在关注后台界面的操作时，也应该同时开启Log打印，去关注一些软件工作时的一些细微的变化、信息，并顺藤摸瓜进行探索，往往能够发现一些好的问题。

2>问更有深度的问题：

   不要满足于发现缺陷，提交EC单，要深入了解其原理，才有更多的测试Idea

3>明察秋毫：

    通过”嗡嗡嗡声”，就能发现产品巨大缺陷。望、闻，切，要关注细节,在细节总发现线索。

4>可测试性与不可见变可见。

    这章强调了要关注细节，但是关注细节往往需要一些可测试性手段，采用你能想到的一切办法，工具，让你的测试细节变得可观察。

   （操作系统的监视器、Web测试的浏览器插件，抓包工具......也包括自己编写的一些测试工具）

 

四、找出有意义的变化

不要轻易的满足于当前你分析出的测试要点、测试Idea。卓越的探索者总能够通过表面现象发现软件一些微妙的、深度隐藏的变化。

变量就是会变化的事物：

这里的变量就是指的是在操作软件过程中会直接或或者间接改变的东西。

1.明显的变量：

明显的变量就是对被测软件的数据输入，在普通的功能测试中应该做过详细的覆盖。这里主要利用变量具有的分型性（fractal）的特征，来构造一些变化，从变量的外形着手。

比如，被测软件在处理输入二进制值 011的处理没有问题，可以考虑输入110，看是否会存在问题?

(但是这样的探索对应的计算机的软件或 操作系统的理论依据是什么呢？)

2.微妙的变量：

比如和软件交互时输入的速度、软件重复执行的次数，文件系统中的文件个数，文件长度.......，在某些特定上下文环境中都可能成为微妙变化：

    比如曾经存在这么一个缺陷，在XX被测系统启动过程xx秒--yy秒之间，对设备进行再次掉电重启操作，那么系统会概率出现丢失配置文件的情况，在这个例子中，时间点就是一个非常微妙的变量。

如何识别这些变量：

 

a.可计数的之物：

账户总数、登录次数，记录条数，配置个数 等等。特别要小心这几种情况：

 0,1,多 ,过多，过少 

 

b.相对位置和顺序:

特别关注数据的排列顺序；贴别关注“开头-中间-结尾的”的数据和操作(这个和边界值测试思路有些类似)。

c.格式：

测试数据的格式，可能对测试结果产生影响。

比如,在测试IPv6相关特性的时候，我常会将类似2000:0000:0000:0000:0000:0000:0000:0001 的 IP地址输入写为2000::1这种缩写形式

不时会发生惊喜。

d.时间点、频率和持续时间：

时间点和上面讲述的微妙变量有些类似，时间点本来也可以视作一种微妙的变量。说道频率和持续时间，测试人员经常采用的反复长时间的执行某种操作从而来发现软件一些可靠性问题。

除此之外还可以从：文件和存储、相对位置、大小、深度，输入和导航等等方面去发现和识别软件中存在的变量。

 

五、改变顺序与交互

真实情况，用户并不会如你想象般的守秩序，用户往往并不会按你想象的那样，按你给定的操作方式去操作软件......

几年前当我在华为工作的时候,墙壁上挂的一副标语，甚至是宣扬的一种理念让我至今难忘，上面是这么写的：

 

 “用户想咋用咋用，用户想咋测咋测”

 

这是对良好用户体验的一种最求。是的，用户往往不会像你认为的方式去使用软件，为了良好的用户体验，我们也不应该限定用户只能够以某种特定的方式/步骤去操作软件。

为了满足用户使用软件的这种不确定性，我们在测试中也应该勇于打破测试中的自我惯性，将随机性引入软件测试过程：

1.被测对象相关动词和名词的随机组合：

    

    名词指的是被测系统能够提供的特性/服务，而动词是特性所支持的一些操作。通过名词和动词的随机组合来决定如何使用软件，构造出更多的使用场景，改变系统的交互方式。（这种探索依然聚焦于干系人所关注的风险，关注测试的价值） 

2.随机导航：  

    这个主要是指在进行GUI测试的时候，需要关注要达到同一个目的是否存在多种不同的操作方式，把它们都找出来。比如：

    有哪些方式可以打开/关闭一个窗口？有哪些方式可以实现一个配置的提交/修改/撤销？........可以将这些方式/操作随机的组合来实现一个测试流程。

 

3.角色人物：

    也就是稍微懂点测试的人，最喜欢挂在嘴边说的一句话："站在用户的视角测试"。不同知识背景、期望、个性的人对同一款软件的操作方式会存在差异的。一个不懂计算机技术的人，可能会按部就班的在GUI上用鼠标点击控件来进行软件操作。而一个对软件和操作系统熟悉的人可能会 借助各种快捷键来进行软件操作，而一个开发人员可能会通过编写脚本或辅助程序来操作软件。

    探索性测试就是要像用户那样去思考，了解他们的个性特征、意图。按照他们的习惯、期望、甚至是怪癖来测试软件。

 

六、探索性测试评估结果

当我们开始做探索性测试的时候，如何评估探索测试的结果的正确性？比如在探索极端恶劣的场景，如果评估一个现象是意料之中的事情还是一个缺陷？

     可以通过如下几个方面作为依据：

 

一.识别并利用特性的“绝不”、"始终"。

    什么是特性的“绝不”和“始终”呢？

    

    1>软件的核心功能：

     比如基站产品的核心功能是提供小区信号覆盖、打电话....，任何情况绝不能让基站退服。在做探索性测试的时候，即使你的探索并没有明确在需求和规格中说明，但影响到了软件的核心功能，那应该做为一个缺陷对待。

    

    2>软件的质量属性：

    如果在探索性测试中发现了违背了产品的准确性、可靠性、易用性、可达性、安全性等质量属性要求时，应视为缺陷。

   

    3>干系人所关注的风险：

    每款产品在他所在的领域内都应存在始终不应该触碰的风险。比如，一个财务软件，任何可能威胁到用户钱款的问题都属于风险。

 

    如何获取和识别特性的“绝不"、“始终”呢？

    1>作为测试人员，对于软件所属的领域知识一定要完备。

    2>有时不同人对于软件的核心功能，对于“绝不"、“始终”所应该包含的内容理解不一致，不同的人有着不同的知识背景。

        可以通过问问题的方法多去了解其他干系人的想法，汇聚不同的Idea,比如：

        a.谁，处于什么目的会使用本软件。

        b.有哪些替代产品，为什么别人使用本产品而不是用其他产品。

        c.如果本软件其他功能都无法工作，至少有什么功能必须能够工作。

        （和“噩梦头条”游戏异曲同工，采用巧妙的设问来了解不同干系人担心的风险）

 

二.替代资源：

    

    1>内在一致性：

       比如基站传输质量测量的相关特性，在做IPPD(基于ICMP或UDP的传输时延、丢包率....检查)测试的结果，应该和同基站同一时刻的其他传输测量手段比如TWAMP、SLA的测试结果基本一致，否则至少有一个特性是存在缺陷的。

   

    2>标准：

        一个被测软件在测试前即使没有能够获取到足够的信息，但至少应该准守所属领域的协议个规范。比如传输领域有RFC协议族。无线领域有3GPP等。

       但做为测试人员依然是应该积极的参与到前期的需求和开发环节中，保证需求理解的一致性，因为处理某些原因可能协议并完全遵循。

    3>纵向、横向对比：

    a.相同产品不同软件版本之间的对比:

    相同的特性，不同的软件发布版本应该具有一致性。

    

    b.相同特性，不同产品之间的对比:

    比如，IP路由，基站产品和数通产品(路由器、交换机...)等都是支持的，对于基站产品的软件实现可以做横向对比。

    

    c.在软件产品所属的应用领域总会存在一些用户习惯，或者约定俗成的东西，这些可能不一定会体现在需求中，但我们的软件实现应    该符合这些习惯，习俗。

    举一例，可能不太恰当，在数据通讯领域，可能用户的延续的操作习惯更倾向于命令行方式，所以数据通讯产品,命令行配置界面做的非常规整，用户也习惯命令行操作的方式。而在基站产品，用户的习惯是采用窗口 UI的方式进行配置，如果一个特性的配置不支持UI方式,那么就不满足用户易用性的质量属性要求。 

 

三.特征：

    有些特性很难直接通过软件的响应结果直接判断是否符合正确，这时候可能需要根据 特征来判断。

    

    1>参照范围:

    a.根据领域知识得到被测对象输出的参照范围，根据测试结果和参照范围的对比来得到评估结果:

    

 

    c.有时也可能根据多次测量结果多呈现出的数据特征来判断测试是否正确:

    比如鹅厂有这么一道测试的面试题:提供一个抽奖大转盘的Web 应用:1,2,3等奖的中奖比例应该为2%,3%,5%，你该如何测试？    

 

    2>站在用户体验的角度来分析：

    比如，最近在玩一款名为《中超风云》的足球手游，游戏自动比赛过程（两只球队均由NPC控制）中会出现如下现象：

    NPC 会频繁的采用铲球，为了争夺球权，夸张的时候比赛两队会来回的铲5-6次。作为一个不懂足球的程序员来说，对于软件的实现可能分辨不出任何问题，但懂球的玩家可能会骂人了，这到底是在踢球还是在打群架呢？

 

   3>结果反转:

    假设被测软件实现的功能是f(x)，而实现它的反向功能的可信任软件是g(x)。

    如果  b=f(a);  a' =g(b);  如果 a ！= a'则说明f(x)可能存在缺陷。

    比如，假设现在软件要实现AES加密的模块，而可信的AES解密的模块已存在。如果将密钥和加密后的密文给解密模块不能正确解密出原始明文则说明新实现的AES加密模块可能存在问题。