软件测试笔记实践,《探索式测试实践之路》 读书笔记

探索式测试 -- 使用语境驱动测试方法(因地制宜地采用测试方法)：

1.结合广度优先搜索和深度优先搜索。

2.遵循SMART原则

Specific(明确性)、

Measurable(可衡量性)、

Attainable(可达成性)、

Relevant(相关性)、

Time-bound(时限性)

3.具体的实施：

(1)制定测试计划，分析被测试应用，确立若干具体的测试使命，每个使命针对一个可能的产品风险；

(2)将测试使命分解为一系列的测试任务，每个任务具有明确的退出条件和时间限制(SMART原则)；

(3)短暂测试后，根据优先级选择一个任务，在固定的时间窗口(90min左右，即为一个测程)中执行探索式测试。期间，设计测试、执行测试、评估测试，根据获得的知识和发现的疑问再设计用例，扩展测试。

(4)适当休息(5-10min)；

(5)优化测试计划 -- 或增、或删、或改；

(6)开始新一轮的测试

探索式测试 vs 即兴测试：

即兴测试 -- 往往利用 错误猜测、典型风险、常见攻击 来快速试探软件，可在短时间内发现许多软件错误。

探索式测试 -- 强调测试的系统性和完整性，扩展测试的广度和深度，减少测试遗漏的风险。

探索式测试 vs 即兴测试：

探索式测试本质上是敏捷测试

探索式测试的应用范围：

1.采用的测试方式

探索式测试作为一种测试风格，可以应用于各种类型的测试

2.应用的阶段

探索式测试者必须从项目关系人(包括软件用户、项目投资人和开发团队等)的视角考察整个产品，研究显式规格说明和隐式规格说明，从而发现软件在概念、需求、设计、实现等层面上的缺陷。

以下是一些常见的隐式规格说明：

·竞争产品。竞争产品不一定是软件，例如笔记软件的竞争者就包括纸质笔记本和铅笔。

·相关产品。软件套装(如Microsoft Office)中的软件往往相互补充、相互约束。

·同一软件的已发布版本。向前兼容可能是非常重要的约束。

·口头讨论、采访、闲聊。

·电子邮件、会议记录、采访记录。

·用户反馈：电话支持记录、论坛讨论、Beta测试反馈。

·技术反馈：软件提交的崩溃信息、错误消息。

·第三方评论：杂志文章、博客文章、社交网络反馈。

·技术标准：所有软件都建立在一系列技术标准之上，某些标准会对测试产生重要影响。

·法律法规：法律可能对软件有强制性约束。

·领域专著：测试财会软件需要学习相关著作，以掌握财会知识。

·测试人员经验。

探索式测试的评估标准：

测程的可评审结果、简报

如何开发探索式测试的工具：

1.寻找缺陷：发现或收集软件的缺陷。

2.提炼模式：分析出缺陷的根本原因，编写一个模式，用它捕获相似的缺陷。

一个模式是一个结构化的攻击手段，它包含如下内容：

何时实施该攻击？

该攻击会捕获何种错误(Fault)？

利用该攻击如何识别软件失败(Failures)？

如何实施攻击？

样例和分析。

3.开发自动化工具：识别出攻击过程中机械的部分，编写一个工具去自动化模式的应用。此处的测试自动化不是自动地执行测试用例，而是提供计算机辅助功能(替代手工操作)，其目的是让计算机完成高负荷运算，让人专注于富有智力挑战的任务。

探索式测试的思维模型：

Erik Petersen --

CPIE(Collation，Prioritization，Investigation，Experimentation)

1.整理(Collation)：尽最大可能收集关于被测产品的信息，去了解和理解它们。

2.排序(Prioritization)：确定所有测试任务的优先级。

3.调查(Investigation)：对即将执行的测试任务进行仔细的分析并确定测试输入和预期输出。

4.实验(Experimentation)：实际地去测试，验证我们的预测是否正确，检查我们在整理阶段获取到的信息是否正确。根据实验结果，测试人员将收集更多的信息，并调整测试任务的优先级。

James Bach -- 组启发式问题

1.知识(Knowledge)：掌握产品特性、开发技术、测试技术和领域规则等测试需要的知识。

2.分析(Analysis)：分析产品风险、测试覆盖、测试方法、测试先知 和产品缺陷等测试相关因素。

3.实验(Experiment)：配置、操作、观察和评估被测产品。

4.测试故事(Testing

Story)：用测试计划、测试报告和可工作的产品等组成测试报告，以准确地反映测试状态和产品质量。

James Bach的探索式测试的过程：

1.知识

提出有用的问题(目的驱动问题)。

观察什么事情正在发生。

描述自己能够感觉到或看到的东西。

对于自己的所知进行批判性的思考。

组织和管理业务上的规则。

能够提出假设和进行试验验证。

尽管已经了解，但仍然进行深入思考。

分析其他人的思考方式。

根据因果关系进行推导。

2.分析

产品和项目风险。

测试覆盖。

测试先知。

资源和限制。

价值和成本。

已存在的缺陷。

3.试验

①配置

---安装产品

---为测试执行准备测试数据和工具

---确认产品是个足够干净的起始状态

---根据自己的任务准备一个有激发性的问题

②操作

---通过问题对产品进行试探性的输入，来使用这个产品

③观察

---收集关于这个产品是如何工作(正确或错误的输入)的信息，来评价产品是否如此工作

④评估

---应用之前得到的先知来发现bugs

4.测试故事

在测试与学习的过程中，测试人员需要不停地产生新的分支(测试思路)，而不是一条直线走到底。

但凡事都有个度，测试人员需要定期去检查现在测试的模块是否与分配到的测试任务相一致。

【在试验的过程中，测试人员可能遇到令人困惑的问题。这时，他可以考虑使用以下方法来解除疑惑。

(1)简化自己的测试思路。

(2)保留测试现场并寻求帮助。

(3)不断重复执行自己的操作。

(4)返回到一个已确认过的状态。

(5)一次只考虑一个因素，一次只修改一个因素。

(6)做出精确的观察。】？？？

探索式测试的覆盖：

通过几个方面考虑，以提高覆盖率 --

1.产品的内部结构(模块、语句、分支)

2.产品的功能或特性

3.产品处理的数据

4.产品依赖的平台(硬件、软件、网络等环境)

5.对产品的操作(在用户角度分析，考虑复杂的场景、流程)

6.操作产品的时间

利用James Bach的HTSM策略模型 --

发掘测试对象和测试策略[有助于提高测试水平]：

1.测试技术：生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。

功能测试(Function Testing)

域测试(Domain Testing)

压力测试(Stress Testing)

流测试(Flow Testing)

情景测试(Scenario Testing)

声明测试(Claims Testing)

用户测试(User Testing)

风险测试(Risk Testing)

自动测试(Automatic Testing)

2.项目环境：资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队，以往富有成效的方法未必适应当前的项目。有经验的测试人员会根据当前语境(Context)，在约束条件下充分运用资源，以高效地测试。

用户(Customers)：理解产品的用户

信息(Information)：发现测试所需的信息

开发者关系(Developer Relations)：与开发者协作加速开发

测试团队(Test Team)：利用团队的力量支持测试

设备与工具(Equipment & Tools)：可利用的硬件、软件、文档等

进度(Schedule)：项目实施的流程

测试条目(Test Items)：测试范围和重点

交付品(Deliverables)：测试的产出

3.产品元素：需要测试的对象

结构(Structure)：产品的物理(physical)元素(如代码、接口、配置文件、可执行文件等)

功能(Functions)：产品的功能

数据(Data)：产品所操作的数据

平台(Platform)：产品所依赖的外部元素

操作(Operations)：产品将被如何使用

时序(Time)：影响产品的时间因素

4.质量标准之操作性标准(Operational Criteria)：面向用户和运营团队

能力(Capability)

可靠性(Reliability)

可用性(Usability)

安全性(Security)

可伸缩性(Scalability)

性能(Performance)

可安装性(Installability)

兼容性(Compatibility)

5.质量标准之开发标准(Development Criteria)：面向开发团队

可支持性(Supportability)

可测试性(Testability)

可维护性(Maintainability)

可移植性(Portability)

本地化(Localizability)