6、功能性测试和探索性测试的区别是什么？你怎么对网站进行测试？

　　功能性测试侧重于检查系统是否符合规格说明所指定的功能性需求。开发者可以根据规格说明，构造相应的测试用例，以检查系统是否实现了指定的特性（feature）。在敏捷团队中，开发者和客户（或商业分析师）一起开发用户故事（user story）。这些故事被实现为端到端的功能性测试（end-to-end functional test），用于驱动开发和验收成果。在敏捷开发中，大部分功能性测试应该是自动化的。

　　探索性测试是语境驱动学派（context driven school）所倡导的测试方法，强调根据当前测试的语境选择最有效的测试策略。测试者选择一个测试目标，一边测试系统，一边学习系统的知识。随着知识的积累，他会不停地调整测试策略，并使用多种方法来测试系统。当测试目标达成，或者他认为出现了更有价值的目标，测试者会改变测试目标，展开新的测试。探索性测试将测试视为一个不停地学习、尝试、反馈的过程，强调测试者的学习、思考、应变的能力。因此，探索性测试只能是手工测试。当然，测试者可以用自动化工具完成一些例行任务，例如安装软件、设置环境、准备数据等；他也可以开发自动化测试用例来复现探索性测试所发现的缺陷。

　　网站测试是一个复杂的问题。如果只考虑功能性测试和探索性测试，可以考虑以下测试活动。

　　1）将网站划分为表现层和业务层。业务层负责业务逻辑，接受表现层的输入，并提供表现层所需要的数据。表现层接受用户的输入，并将业务层的数据以合适的方式展现给用户。

　　2）开发者与商业分析师一起确定用户故事。开发者将其实现为自动化测试用例。与业务相关的功能，应该在业务层编写测试用例。与表现相关的功能，应该在表现层编写测试用例。通常，在业务层实现测试的投入产出比较高，因此应该尽量分离表示逻辑和业务逻辑，使表示层承担的任务尽可能的少。功能性测试用例提供了基本的质量保证，是进一步测试的基础。

　　3）在功能性测试相对稳定之后，可以开展探索性测试。可以用浏览器访问网站，也可以用客户端工具直接访问业务层。可以采纳情景测试（scenario test）的方法，模拟真实用户去完成一个复杂的任务或构建一个真实的应用。例如，如果测试在线文档处理网站，就用它去排版一篇包含多种字体、图形、格式的文档（收集一些博士学位论文可能是一个好主意）。也可以用工具扫描网站，以发掘安全漏洞，然后用具体的测试用例来证实潜在的漏洞是可以被利用的。总之，可以在功能性、易用性、安全性等多个角度探索系统。

　　7、测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？

　　测试计划（test plan）对测试活动进行整体规划。它从以下几个方面辅助测试工作的展开。

　　● 为测试工作进行技术准备。测试计划应该给出测试目标和退出条件。在此基础之上，给出测试策略，以指导具体的测试活动。

　　● 对资源进行分配。测试计划应该给出大致的测试日程，并根据日程分配软硬件资源。

　　● 建立测试协作的基础。测试计划应该制定大致的测试过程（test process）、明确的测试规范（test guideline）和具体的人员职责。

　　● 识别测试风险，进行风险评估，并建立风险监测和预防机制。

　　在我看来，测试计划最重要的功能是提供团队协作的基础，记录团队已经达成的共识。如果这些基础和共识发生了变化，那么测试计划也需要进行相应的修改。

　　测试用例（test case）是一个已文档化的流程（documented process），用于探测软件的缺陷。对于单元测试，一个测试用例最好只检查一项内容，例如一个方法的一个特性，这使得测试用例思路清晰、易维护、易运行。对于系统测试，一个测试用例往往实现了一个复杂的流程，该流程对应于一项用户活动，该活动实现了特定的用户价值。对于性能测试，一个测试用例往往体现为一个应用场景，以及在该场景下对性能指标的要求。可见，不同类型的测试用例有不同的表现形式。通常，它是该类型测试的最小组织单位。

　　测试套件（test suite）是测试用例的集合。测试者根据测试需求将测试用例组织到测试套件中，以便更有效地运行测试、生成测试报表。例如，将一个模块的所有测试组织到一个测试套件中，作为回归测试用例集。如果该模块发生变化，则运行该回归用例集，以捕获可能的回归错误。再例如，将按照功能特性（functional feature）划分测试套件，然后根据测试套件生成测试报表。所得的报表按照特性组织，便于阅读和理解。

　　在实际工作中，我按照如下方式组织自动化测试。

　　1）一个测试方法（test method）只测试一项内容。测试方法的命名规则是test_FeatureName_TestStartegy，例如test_CreateUser_NoneInput，这样可以快速地了解被测试的特性和所使用的测试策略。

　　2）将一个类或特性的所有测试用例都放在一个测试类（test class）中，这样便于按照特性审查、维护、增加测试用例。

　　3）将一个测试夹具（test fixture）的所有测试用例都放在一个测试类中。所谓测试夹具，是指完成测试所必需的被测试对象以及相关的业务对象、伪对象、桩对象等。在一些情况下，需要大量的代码来建立测试夹具。因此，按夹具来组织测试方法，可以复用夹具建立代码，提高测试开发效率。

　　4）将可复用的测试代码组织到测试辅助类（test utility class）或父测试类（super test class）中。

　　5）按照功能特性组织测试套件。将一个特性所有的测试用例都放置在一个测试套件中。将所有的测试套件组成测试用例全集，用于每日测试。此外，我还组织了一个BVT suite，用于每小时一次的rolling test。