本文将记录关于《Full Stack Testing》这本书中的诸多方法论与测试技巧

手动探索测试

手动探索性测试一般处于开发后进行，探索性测试强调所有三个角度（业务需求，技术实现细节，最终用户需求）结合起来，并从这些所有角度去挑战在过去业务角度，功能开发角度中被认为对的事情。相较于传统手动测试，完成特定测试任务以满足某一需求文档中的验收标注，手动探索测试更为自由，更为全局。手动探索测试在特定的测试环境中随意干预各种应用程序组件，例如数据库，服务或者后台进程。

探索性测试框架

等价类划分

假如有一个正数的输入值x，有x小于500，x在500 与1500之间，大于1500，针对三种情况分别有三个不同的策略。如何进行测试？

可以划分为三个等价类 {0-500，500-1500，1500- },只需要在其区间内各区三个数就可覆盖所有情况。

边界值分析

边界值分析法是等价类的扩展方法。它将类之间模糊不清的边界值也纳入测试，{0，1，500，501，1500，1501}

状态转换

在程序的行为根据历史记录发生变化时可以使用状态转换将状态过程可视化。比如登录三次失败三次账号锁定。

状态转换

决策表

在面对逻辑关系（And&or）时将可能结果列出。类似真值表

因果图

直接画出因果关系。
因果图

成对测试

或许在测试中会遇到多个条件组合需要测试的情况，在复杂情况下如果通过穷举则非常困难。比如目前有三个条件每一个条件都有两种情况 A(1,2), B(1,2), C(1,2)。我们需要测试 2 * 2 * 2 种情况才能完全覆盖。
我们如何测试单因子和双因子错误率？

单错误因子情况下假设 A(1) 为错误因子。我们至少需要 {A(1),B(1),C(1)} & {A(2),B(1),C(1)} ，两组数据就能测出。

双错误因子情况下假设 {A(1),B(1)} 为错误因子。我们至少需要 {A(1),B(1),C(1)} & {A(1),B(1),C(2)} & {A(1),B(2),C(1)} & {A(2),B(1),C(1)} 四组数据才能测出。

而三因子情况下我们需要全部8组数据才能测出。

研究发现单因子和双因子导致错误率在80%左右，而三因子错误率在20%。 所以只需要测试单因子与双因子情况就能基本覆盖错误。同时减少50%的测试量。
成对测试算法工具

采样

随机抽样检查

经验法

根据我的经验，以下是经常出现的几种类型的错误：

  • 缺少对无效/空白输入值的验证，并且缺少指导用户更正输入的适当错误消息

  • 数据验证、技术和业务错误返回的 HTTP 状态代码不明确

  • 特定于域、数据类型、状态等的未处理的边界条件

  • UI 端未处理的技术错误，例如服务器关闭、响应超时等

  • 转换、数据刷新和导航期间的 UI 问题（例如抖动和残留）

  • SQL 关键字_like_和_equals_可以互换使用，完全改变结果

  • 未清除的缓存和未定义的会话超时

  • 当用户单击浏览器中的后退按钮时重新发布请求

  • 从不同操作系统平台上传文件时缺少文件格式验证

探索功能

对一个全新的应用进行测试时，你应该想到哪些测试思路?

功能性用户流程

测试用户完整使用应用的流程，在这个测试可以使用上文所介绍的测试框架。
重复该流程
在完成一次测试后不刷新状态，重新测试。
多用户流程
多用户并发操作时会发生什么？

失败和错误处理

当服务器返回错误的信息，前端UI应该如何处理。

用户界面的观感

不是指用户界面的设计美感，而是关于用户体验方面，比如某一描述性文字是否有足够的空间显示延迟时的等待体验，图片的质量等等方面。

跨职能方面

安全，性能，可访问性，身份验证，授权，隐私，可审查性等等方面。

手动探索测试策略

对于一个陌生的应用可以从一下五个方面思考测试策略。

用户角色

一个应用可能有不同的角色，扮演不同的角色去了解应用。

领域

每一个行业，每一个业务领域都有独特的工作流程，你需要了解应用的领域知识。

业务重点

在复杂业务上，考虑项目的可扩展性与项目整体。

基础设施和配置

了解实际部署应用机器的如构件的各项配置是必要的，它能帮你观察是否出现了异常的情况。

组织架构

组织架构也是测试的切入点。例如，如果架构涉及 Web 服务，您可能需要对 API 执行探索性测试，而不仅仅是探索 UI。同样，如果应用程序涉及事件流，那么探索异步通信的案例就变得很重要。

测试工具

思维导图可能会帮到你

思维导图

Apifox

集接口测试，在线mock，环境变量，脚本于一体的强大测试工具，缺点是强制登录。

测试环境卫生

共享测试环境与专用测试环境

一个团队一个测试环境。

测试数据卫生

测试数据属于权限范围测试人员的行为，他们应该遵循某些实践，以确保他们不会无意中破坏自己的探索。特别是，在同一部署中继续测试新功能时，请注意过时的数据和配置。避免此类复杂情况的建议是，每当开始新的用户故事时，就部署新的构建（假设新的部署将清除旧的数据和配置并将应用程序恢复到新状态）。另一种选择是为每个用户故事（例如新用户）创建一组新的测试数据，而不是探索可能处于不同状态的现有用户。

当有数百个链接表时，测试数据创建可能会很复杂。然后，一个选项是让新部署删除旧数据并将其替换为一组标准测试数据，或者让 SQL 脚本创建适当的新测试数据作为部署的一部分。

自治团队

团队成员可能没有登录凭据或更新配置、查看应用程序日志或设置存根所需的权限；要执行此类操作，他们需要向 DevOps 或系统维护团队请求帮助。这在探索性测试期间尤其令人沮丧，因为测试人员可能需要访问所有应用程序组件。确保团队是自主的并且能够访问所需的一切，这将减少由于外部依赖性而导致的延迟并实现顺利交付。