所谓优秀的测试并不是使用最前沿、最高级的测试技术，而是根据产品和项目的实际情况
选择恰当的测试方法。为了制定出符合项目语境的测试策略，本周将讨论如何从测试视角来研究产品。
7.1
静态分析
对于测试人员而言，阅读代码将帮助他更好地理解产品实现和代码变更，以产生更好的测试想法。本节讨论静态分析在测试活动中的常见应用，并介绍一些基本实践方法。
7.1.1浏览源代码来
理解产品实现
合理的策略是浏览源代码树，了解源代码的目录结构、模块划分、代码分布等基本情况，然后阅读部分源代码来领会编码规范、架构设计、代码实现等技术细节。在今后的工作中，测试人员可以根据具体的测试任务再去阅读相关的代码。
基本方法如下：
阅读前要确定阅读目标，但阅读时不要拘泥于预定的目标；通过目录识别模块；通过模块了解产品的组成结构，知晓各部分代码的功能；借助搜索引擎来了解相关技术；一边阅读，一边记录笔记；
可以使用脚本来分析源代码树，该脚本分析当前目录和子目录下所有的文件、文件名、文件所在目录和文件行数等。代码行数是一种最简单的代码度量，不能提供丰富的语义信息，但是不失为很好的分析切入点。
以上代码度量步骤可以获得如下经验：
1、代码
度量提供了代码某个方面的概况，可以帮助阅读者一览全局。
2、简单的代码度量很容易实现，不使用语法分析，仅利用
文本分析就能提供一些有帮助的信息。
3、用恰当的工具
分析数据，可以快速地计算并展示数据，这提高了数据分析的效率。
4、代码度量只提供了代码阅读的
线索，获得更透彻地理解仍旧需要深入阅读源代码。
由代码阅读过程，不难提取出 一些代码阅读的基本实践：
1、阅读者针对一个
特定的主题进行阅读，
以点带面地推动代码理解。
2、对于一组代码，阅读者需要从外部代码的角度理解他们的
功能和用法，并评估它们对整个产品的
贡献。
3、对于一组代码，阅读者需要理解它们的
实现方法，包括所使用的设计、所采用的技术、所依赖的其他代码等。
4、了解语言特性、惯用设计、命名规范等
基础知识会帮助阅读。
5、代码阅读并没有固定的阅读
顺序。
6、在阅读过程中，阅读者会产生一些
想法，应该将他们记录下来，并阅读更多的代码来验证这些想法，从而获得更深刻的理解。
7.1.2分析源代码来
帮助测试设计
为了有效的测试，测试人员需要阅读代码来理解变更的影响，并激发测试想法。
影响分析是一种常用的代码分析方法，旨在分析目标代码受哪些代码的影响，又会影响到哪些代码。需要注意两个方面：
哪些代码会影响被修改代码？被修改代码的输入数据从何而来？如何构造测试用例让程序执行覆盖被修改代码？如何构造测试用例以测试被修改代码的状态？能否构造测试用例让被修改代码发生错误？
被修改代码会影响带哪些代码？被修改代码的输出数据流向何处？如何观察到被修改代码的输出？如何构造测试用例以全面地测试受影响的代码？能否让被测试代码产生“异常”的输出数据，令受影响的代码发送错误？
为了识别代码之间的影响，测试人员需要在阅读代码的过程中实施控制流分析和数据流分析。
控制流分析检查语句A的执行是否影响语句B的执行；数据流分析检查语句A赋值的数据是否被语句B使用；
全局变量是需要特别关注的对象，它们往往被软件的多个功能读写，会广泛地影响软件的控制流和数据流。
污染传播分析也是一种基于控制流和数据流的代码分析方法。是一些静态代码检查工具的基础。污染传播的核心隐喻是污染和传播，污染是指被污染的数据，源头通常是包含恶意数据的攻击性输入；传播是指软件没能过滤掉被污染的数据，让恶意数据在软件中传播，最终导致软件故障。可以考虑如下阅读方法：标记软件的入口点，即寻找接收外部输入的代码；分析以入口点为源头的数据流，寻找输入的检查代码；标记软件的出口点，即找到发生输出数据的代码；分析以出口为终点的数据流，寻找输出之前清理数据和格式化数据的代码。
根据污染传播的思路，测试人员可以考虑如下代码阅读策略：
阅读同步工具和数据库的代码，并构造测试用例；阅读服务端的代码，并构造测试用例；阅读客户端程序代码，并构造测试用例。
7.1.3黑盒测试并不是基于无知的测试
阅读源代码仍旧是一项重要且必要的测试活动，主要原因有以下几点：
第一，因为软件是高度复杂的，任何方法都不能获得完整的产品信息，所以测试人员应该多角度地研究软件，运用多种手段去调查产品的质量。
第二，源代码是软件产品最重要的文档，提供了许多无可替代的产品信息。
第三，研究产品实现有助于避免测试设计的缺陷。
第四，降低代码阅读的风险并不困难。
阅读代码是一项重要的技术调查方法，可以为测试设计提供想法和反馈，与其他测试技术一起运用，能够帮助测试人员更有效地完成测试任务。
7.2动态分析
动态分析是通过运行软件来研究产品实现的活动。
7.2.1用工具分析产品的行为
合理的使用调试和诊断工具可以提高技术调查的效率。
任务1：列出产品所加载的动态链接库
任务2：列出产品打开的文件
任务3：分析程序之间的协作关系
任务4：分析客户端与服务器之间的通信
任务5：分析产品的性能
7.2.2在调试器中观察软件行为
利用调试器监控软件的运行，将实际执行的控制流、数据流和源代码结合起来，能够更快地理解设计，有事半功倍之效。
7.3业务研究
7.3.1理解关系人
关系人是软件的利益相关者，包括软件产品的购买者、使用者、开发者、维护者、销售者、管理者等。
测试人员从5个方面思考关系人，以产生测试想法。
用户：分析不同类型用户，了解他们期望、需要完成任务、技能水平、软件语境等；
质量特性：需要重点支持的质量特性；
产品恐惧：了解真正担心的事情，将忧虑转换为测试想法；
使用情景：分析产品情景，设计情景测试；
领域信息：关系人的领域信息，包括业务、环境、困难等；
在测试过程中，测试人员需要持续思考这些因素，可以帮助更好的理解产品，并产生多样化的测试想法。以下是实践要点：
在项目之初，测试人员并不深刻地理解产品和项目；随着项目进展，测试人员会逐渐掌握更多的产品知识和业务知识；在软件发布后，测试人员会陆续收到一些来自用户的缺陷报告。
内部使用是一项很有价值的开发实践，可以在许多方面提高开发过程和软件产品的质量。
因为大量员工使用产品，所以内部使用可以发现许多小组测试难以发现的缺陷；因为使用者在利用产品完成实际任务，所以内部使用有助于发现一些真实情景所暴露的缺陷；内部测试让整个研发团队参与到质量反馈过程中，每个人都可以提交缺陷和建议，从而潜移默化地提高了团队的质量意识；内部使用要求员工安装尚未发布的最新版本的软件，潜在要求软件的大部分构建达到可用的标准，不存在频繁崩溃、工作流中断等严重的缺陷；内部使用对软件开发过程提出了更高的要求。
为了弥补内部使用上覆盖率的不足，许多软件团队会发布外部使用的
Beat版本，从而广泛收集产品的信息。
总之，研究关系人是为了更好地理解软件的使命，通过提供质量信息来提高软件对于关系人的价值。
7.3.2评审需求文档
软件需求包括项目团队记录的
显示需求和没有被正式记录的
隐式需求，测试人员需要关注这两种需求。
对于大多数的需求文档，测试人员可以参考如下结果来驱动需求文档评审：
需求文档的缺陷；产品的测试模型；测试想法和值得调查的疑问。
驱动力1：评审需求文档需要发现需求文档的错误或不足
评判性阅读的第一步是了解文档的结构和主旨（只关注一些重点对象，如摘要、章节标题、目标和非目标、图、代码示例）；通过快速阅读，测试人员已经掌握了文档的结构，知晓哪些部分是重点内容。
批判性阅读的第二个阶段，测试人员会仔细阅读重点内容，分析文档的论点、论据和主张。其中，阅读的基本技术是组织和总结。
在批判性阅读的第三个阶段，测试人员评价和批评文档的内容。常见的思考点：
在论证时，文档所提供的证据是否正确？
在论证时，文档所提供的论据是否充分？
在论证时，文档的推理过程正确吗？
文档是否清晰地阐述了用户需求，并明确地描述了软件设计的目标？
文档的所设定的目标、所要解决的问题、所提出的方案是否真正实现了关系人的利益？
驱动力2：测试人员通过批判性阅读建立的
测试模型
功能列表；质量特性列表；Google ACC；启发式测试策略模型；输入输出模型；系统生态图；实体关系模型；状态机模型；
驱动力3：测试人员利用需求文档来建立
技术调查的目标，并激发测试想法
利用文档核对产品的行为。以下是一些常见的测试想法：
设计攻击性的测试用例，尝试让软件行为不符合需求文档的陈述；
利用条件分析设计测试用例，以检查产品在不同情景下的表现；
改变陈述中的参数值，使用不同的数据、配置、情景来测试产品；
测试陈述所隐含的需求；
设计测试用例以测试当前陈述和与之相关的陈述，通过同时覆盖多个模块、功能、情景来发现设计的不一致之处；
设计情景测试，在一个实现用户价值的故事中检查软件是否符合需求文档的陈述。
在需求评审中，测试人员可以根据产品和文档的特点来选择
模板参数的值，以下是一些常用的选择思路：
探索<对象>；使用<资源>；发现<信息>；
7.3.3通过测试来研究
一些常见的测试调研方法：
方法1：
侦察测程；
当测试一款新产品时，会安排几个侦察测程，快速的调查产品情况。
声明测试（包装文字等）；文档评审（产品帮助等）；功能测试（基本功能等）；产品分析（拆卸产品，推测机制等）；情景测试（构思现实场景考验产品等）；可用性测试（把玩产品，体验等）；压力测试（外力捶打等）；
方法2：
结对测试；
结对测试有助于产生多样化的测试想法。业务研究角度，结对测试可以帮助测试人员更快地理解产品。
方法3：
组队测试；
组队测试是一种有益的
集体测试活动，能够弥补测试负责人知识上的不足，发现一两个测试人员难以发现的问题。常见的实施方法如下：功能测试负责人邀请同事参与组队测试会议；测试负责人预订一个会议室，准备好两台计算机和投影仪；在会议中，测试负责人执行测试，另一位测试人员记录测试笔记，其他参与者提供测试用例；组队测试可以提供多样化的测试想法；组队测试有较好的自适应性；在会后，测试负责人和记录员共同整理测试笔记，并提交所发现的缺陷。
方法4：
头脑风暴会议；
与组队测试类似的团队测试活动是头脑风暴会议。不同的是，组队测试需要相对稳定的测试对象，因此通常在项目中后期执行，
头脑风暴会议一般不执行测试，因此往往在
项目前期、测试对象尚未实现时举行。以下是头脑风暴的实施要点：功能的测试负责人邀请同事参加会议；在会议中，测试负责人主持会议，另一位测试人员记录参与者的建议；在测试开始之前，测试负责人介绍被测功能的特性，并鼓励参与者根据自己的知识和思想提供测试想法和潜在风险；为了获得多样化的想法，测试负责人应该确保每个参与者都有发言机会发言；会议后，测试负责人和记录员共同整理测试想法。
7.3.4利用互联网资源
互联网的海量信息提供了软件开发的知识库，搜索引擎是发现知识的重要工具。恰当地利用搜索引擎和网络资源，测试人员可以更好地理解产品并执行测试。以下是一些典型的场景：
情景1：利用搜索引擎查找技术问题的线索；
搜索有辨识度的关键词；当查询失败时，尝试新的关键词组合；使用英文关键词进行搜索；
情景2：通过技术论坛等工具获得用户反馈；
有助于培养全员质量意识；分析用户问题可以获得缺陷的第一手资料；技术支持活动能够帮助测试人员了解用户使用软件的情景。
情景3：多方面地收集用户对产品的评论；
论坛；博客；问答网站；媒体评论；
7.3.5领域研究
首先，测试人员需要掌握基本的领域概念和术语。
在掌握基本概念之后，测试人员需要了解产品所服务的业务目标。
在知晓业务目标之后，测试人员需要学习达成业务目标的技术方法。
领域研究是为了更好的测试，在学习技术方法的同时，测试人员应该从测试角度收集信息，为测试设计提供支持。以下是一些常见的研究成果：约束规则；潜在风险；测试模型；
7.4研究策略
在实践这些方法的过程中，有两个要点值得测试人员注意：第一，测试人员需要
综合运用多种研究方法；第二，产品研究会
贯穿整个项目过程。
7.5小结
静态分析通过阅读产品代码，来理解产品实现和代码变更。
对于复杂产品的理解，静态分析的典型策略是概览源代码树，了解目录结构、模块划分、代码分布等基本情况，然后细读一部分重要代码来以点带面。
影响分析和传播分析是审阅局部代码并产生测试想法的常见技术。
黑盒测试并不是基于无知的测试。
动态分析通过运行软件来研究产品的关键情景和重要设计。
灵活使用包括调试器在内的动态分析工具将显著提高测试效率。
测试人员需要识别重要关系人，理解其目标、使命和任务。
内部使用是一项很有价值的开发实践，但它不能覆盖所有用户类型。
测试人员需要批判性地阅读产品相关文档，典型的文档评审包括：文档缺陷、测试模型、测试想法和需要调查的问题。
软件测试本身就是一种研究产品的方法，侦察测程、结对测试、组队测试、头脑风暴会议能够帮助测试人员更好地了解产品。
软件测试本身就是一种研究产品的方法，侦察测程、结对测试、组队测试、头脑风暴会议能够帮助测试人员更好地了解产品。
互联网提供了海量的测试信息，搜索引擎是发现知识的重要工具。
测试人员需要学习领域概念、业务术语、业务目标和技术方法，以实施更深入的测试。
综合运用多种研究方法，才能全面地理解产品。
测试相关学习、测试设计、测试执行和测试评估是相互支持的并发活动。