没有时间作图了，额外说明，这篇不是原创文章，网络获取的资源。主要是探索式测试的一份检查表，给探索式测试提供多角度，全面的测试设计参考。
——王磊
启发式测试策略模型(主)
1产品元素
1.1结构
1.1.1包括实物产品的一切。
1.1.1.1抵押品:任何超出软件和硬件,也是产品的一部分,如文件,网络链接和内容、包装、许可协议等。
1.1.1.2非可执行文件:多媒体以外的任何文件或程序,像文本文件,样本数据,或者帮助文件。
1.1.1.3硬件:任何硬件组件产品的一部分。
1.1.1.4接口:点子系统之间的连接和通信。
1.1.1.5代码:代码结构组成的产品,从可执行文件到个人的例程。
1.2功能
1.2.1的一切产品。
1.2.1.1可测试性:任何功能提供帮助测试产品,如诊断、日志文件、断言、测试菜单,等等。
1.2.1.2交互:任何相互作用或功能在产品之间的接口。
1.2.1.3错误处理:任何检测和从错误中恢复的功能,包括所有错误消息。
1.2.1.4多媒体:听起来,位图,视频,或任何图形显示嵌入到产品中。
1.2.1.5启动/关闭:每个方法和接口调用初始化以及退出产品。
1.2.1.6时间相关
1.2.1.6.1超时设置
1.2.1.6.2每日或月底报告
1.2.1.6.3夜间批处理作业
1.2.1.6.4时区
1.2.1.6.5业务假期
1.2.1.6.6利息计算
1.2.1.6.7条款和保修时间
1.2.1.6.8计时功能。
1.2.1.7计算:任何算术函数或算术运算嵌入到其他功能。
1.2.1.8用途:任何函数定义和区分产品或满足核心需求。
1.2.1.9转换:修改或变换的函数(例如,设置字体,插入剪贴画,撤回资金账户)。
1.2.1.10系统接口:任何交换数据的功能与其他用户,与其他项目,如硬盘、网络、打印机等。
1.2.1.11用户界面:任何调解的功能与用户的数据交换(例如导航、显示、数据录入)。
1.3数据
1.3.1一切产品的过程。
1.3.1.1输入:任何数据处理的产品。
1.3.1.2输出:任何数据结果处理的产品。
1.3.1.3预设:任何提供的数据作为产品的一部分,或者建立,如预制数据库、默认值等等。
1.3.1.4持久:任何数据存储在内部和预期持续多个操作。
1.3.1.4.1模式或状态的产品
1.3.1.4.2选项设置
1.3.1.4.3视图模式
1.3.1.4.4内容的文件
1.3.1.5序列:任何命令或排列的数据,如词序、排序和分类数据,测试顺序。
1.3.1.6大的、小的:变化的大小和聚合数据。
1.3.1.7噪音:任何数据或无效状态,损坏,或产生不可控或不正确的方式。
1.3.1.8生命周期:转换数据实体的生命周期,因为它被创建时,访问,修改,和删除。
1.4平台
1.4.1一切产品赖以超出您的项目()。
1.4.1.1内部组件:库和其他组件嵌入在生产你的产品,但在您的项目。既然你不能控制他们,你必须决定要做什么,以防他们失败。
1.4.1.2外部软件:软件组件和配置不运送产品的一部分,但需要(或可选)为了使产品工作:操作系统中,并发地执行应用程序,司机、字体等。
1.4.1.3外部硬件:硬件组件和配置不运送产品的一部分,但需要(或可选)为了使产品工作:CPU、内存、键盘、外围板等。
1.5操作
1.5.1将如何使用该产品。
1.5.1.1极端使用:挑战模式和序列的输入符合产品的预期用途。
1.5.1.2财力使用:模式的输入由无知,错误,粗心或恶意使用。
1.5.1.3常用:模式和序列输入产品通常会遇到的。这不同的用户。
1.5.1.4环境:产品运营的物理环境,包括噪音等元素,光,和干扰。
1.5.1.5用户:各种用户的属性。
1.6时间
1.6.1任何产品和时间之间的关系。
1.6.1.1并发:超过一件事发生在一次(多用户、分时、线程、信号量、共享数据)。
1.6.1.2改变利率:加速和减速(峰值、脉冲、挂起瓶颈,中断)。
1.6.1.3快/慢:测试与“快速”或“慢”输入;最快和最慢;快和慢的组合。
1.6.1.4输入/输出:当输入,当创建输出,和任何时间(延迟、时间间隔等)的关系。
2操作标准
2.1功能
2.1.1能执行所需的功能吗?
2.2可靠性
2.2.1会工作得很好,抵制失败在所有必需的情况下?
2.2.1.1数据完整性:系统中的数据不受损失或腐败。
2.2.1.2错误处理:产品拒绝失败的错误,是优雅的失败,恢复。
2.2.1.3安全:产品不会失败等方式危害生命或财产。
2.3可用性
2.3.1有多容易为一个真正的用户使用产品?
2.3.1.1易学性:可以迅速掌握产品的操作目标用户。
2.3.1.2可操作性:产品可以用最小的努力和麻烦操作。
2.3.1.3可访问性:产品符合相关的可访问性标准,和O / S可访问特性。
2.4安全
2.4.1如何产品防止未经授权使用或入侵吗?
2.4.1.1安全漏洞:系统不能执行安全的方式(如社会工程漏洞)
2.4.1.2授权:授予的权利通过身份验证的用户在不同的特权级别。
2.4.1.3认证:系统验证用户的方式是她说她是谁。
2.4.1.4 -隐私:客户或雇员数据的方式是防止未经授权的人。
2.5可伸缩性
2.5.1情况如何产品的部署规模上升或下降?
2.6性能
2.6.1如何快速响应是吗?
2.7 Installability
2.7.1可以轻易地安装到目标平台(s)?
2.7.1.1升级:可以轻松地添加新模块或版本吗?他们尊重现有的配置吗?
2.7.1.2卸载:当产品卸载,删除干净吗?
2.7.1.3配置:系统影响安装的哪些部分?文件和资源存储在哪里?
2.7.1.4系统需求:产品承认如果一些必要的组件缺失或不足?
2.8兼容性
2.8.1发布与外部组件和配置它是如何工作的?
2.8.1.1资源使用:本产品不不必要地占用内存,存储或其他系统资源。
2.8.1.2向后兼容性:与早期版本的产品本身。
2.8.1.3硬件兼容性:产品与特定的硬件组件和配置工作。
2.8.1.4操作系统兼容性:本产品适用于一个特定的操作系统。
2.8.1.5应用程序兼容性:产品与其他软件产品。
3发展标准
3.1可支持性
3.1.1经济会如何为用户提供支持的产品?
3.2可测试性
3.2.1如何有效产品可以测试吗?
3.3可维护性
3.3.1经济是如何构建、修复或提高产品吗?
3.4可移植性
3.4.1经济会如何港口或重用技术在其他地方?
3.5本地化
3.5.1经济会如何适应其他地方的产品吗?
3.5.2规定:?
3.5.3语言:产品适应容易长消息,从右到左,或ideogrammatic脚本?
3.5.4金钱:产品必须能够支持多种货币?货币兑换吗?
3.5.5社会或文化差异:客户可能发现文化引用混淆或侮辱?
4感知质量
5测试技术
5.1功能测试
5.1.1测试它能做什么
5.1.1.1识别产品可以做的事情(函数和sub -功能)。
5.1.1.2确定你会知道一个函数是如何工作的能力。
5.1.1.3测试每个功能,一次一个。
5.1.1.4看到每个函数做它应该做什么,而不是它不应该做什么。
5.2域测试
5.2.1分而治之数据
5.2.1.1寻找任何数据处理的产品。看输出以及输入。
5.2.1.2决定哪些特定数据来测试。
5.2.1.2.1主题
5.2.1.2.2边界值
5.2.1.2.3典型值
5.2.1.2.4方便值
5.2.1.2.5无效值
5.2.1.2.6最好的代表
一起来说考虑组合数据值得一试。
5.3压力测试
5.3.1压倒产品
5.3.1.1寻找子系统和功能很容易被超载或“破”的存在具有挑战性的数据或资源的限制。
5.3.1.2识别子系统和功能有关的数据和资源。
5.3.1.3选择或生成具有挑战性的数据或资源约束条件来测试
5.3.1.3.1大型或复杂的数据结构
5.3.1.3.2高负载
5.3.1.3.3长测试运行
5.3.1.3.4许多测试用例
5.3.1.3.5低内存条件
5.4流测试
5.4.1之前做一件事
5.4.1.1定义测试程序或高水平的情况下,合并多个活动的端到端连接。
5.4.1.2之间不要重置系统测试。
5.4.1.3不同时机和测序,并尝试并行线程。
5.5场景测试
5.5.1测试一个令人信服的故事
5.5.1.1思考周围的一切产品。
5.5.1.2设计测试,涉及到有意义的和复杂的与产品的交互。
5.5.1.3好的场景测试是一个令人信服的故事,重要的人如何做一些重要的产品。
5.6要求测试
5.6.1验证每一个索赔
5.6.1.1识别参考资料,包括关于产品(隐式或显式)。
5.6.1.2分析个人声明,澄清模糊的说法。
5.6.1.3验证每个索赔的产品是正确的。
5.6.1.4如果你从一个明确的规范进行测试,期望它和产品带进对齐。
5.7用户测试
5.7.1涉及用户
5.7.1.1确定类别的用户和角色。
5.7.1.2确定每个类别的用户要做什么(用例),他们会怎么做,他们的价值。
5.7.1.3得到真实的用户数据,或把真实用户测试。
5.7.1.4否则,系统地模拟用户(喝很容易认为你像一个用户即使你不是)。
5.7.1.5强大的用户测试,其中包括各种各样的用户和用户角色,不只是一个。
5.8风险测试
5.8.1想象一个问题,然后寻找它。
该产品可以5.8.1.1什么样的问题?
5.8.1.2什么最重要?关注这些。
5.8.1.3如何检测他们是否有?
5.8.1.4列出特别有趣的问题和设计的测试显示它们。
5.8.1.5它可以帮助咨询专家,设计文档,过去的错误报告,或应用启发式风险。
5.9自动测试
5.9.1运行一百万个不同的测试
5.9.1.1寻找机会自动生成大量的测试。
5.9.1.2开发一个自动化、高速评价机制。
5.9.1.3编写一个程序来生成、执行和评估测试。
6项目环境
6.1客户
但是谁是客户的测试项目。
6.1.1.1你知道你的客户是谁?他的意见重要吗?利益或遭受工作你会怎么做?
6.1.1.2你有与客户联系和沟通吗?也许他们可以帮助你测试。
6.1.1.3也许你客户有强烈的想法关于你应该创建并运行测试。
6.1.1.4也许他们有冲突的预期。你可能需要帮助识别和解决这些。
6.2信息
6.2.1产品或者项目的信息需要测试。
6.2.1.1有工程文件可用吗?用户手册吗?基于web的材料?
6.2.1.2这个产品有历史吗?老问题,固定或延期吗?客户投诉的模式吗?
6.2.1.3你需要多熟悉产品,之前你就会知道如何测试吗?
6.2.1.4目前是你的信息?你通知新的或更改信息吗?
6.2.1.5有任何复杂的或具有挑战性的一部分产品似乎奇怪的是没有信息呢?
6.3开发人员关系
6.3.1如何相处程序员。
6.3.1.1傲慢:开发团队似乎过于自信的任何方面的产品呢?
6.3.1.2防御:有部分产品的开发人员似乎奇怪的不是测试?
6.3.1.3融洽:你和程序员开发了一个友好的工作关系吗?
6.3.1.4反馈循环:你能快速沟通,在需求,与程序员?
6.3.1.5反馈:开发人员认为您的测试策略?
6.4测试团队
6.4.1谁将执行或支持测试。
6.4.1.1你知道谁将测试吗?
6.4.1.2人没有在“测试团队”,可以帮忙吗?
6.4.1.2.1人以前测试类似产品,可能会建议吗?
6.4.1.2.2程序员?
6.4.1.2.3设计师?
6.4.1.2.4用户?
6.4.1.2.5作家吗?
6.4.1.3你有足够多的人有了正确的技能来实现一个合理的测试策略?
6.4.1.4有特定的测试技术,团队有特殊技能或动机来执行?
6.4.1.5是否需要培训?任何可用的吗?
6.5设备和工具
6.5.1硬件、软件或文档需要管理测试。
6.5.1.1硬件:我们有你需要的所有设备执行测试吗?设置和准备好了吗?
6.5.1.2自动化:自动化测试工具需要吗?他们是可用的吗?
6.5.1.3探针:任何工具需要援助的观察产品在测试?
6.5.1.4矩阵和清单:任何文件需要跟踪或记录测试的进展吗?
6.6进度
6.6.1顺序、持续时间和同步的项目活动。
6.6.1.1测试设计:你有多少时间?有测试创建后比早吗?
6.6.1.2测试执行:当测试会执行吗?有一些测试重复执行,用于回归?
6.6.1.3发展:当将构建可用于测试,功能补充说,代码冻结,等。
6.6.1.4文档:用户文档可供审查?
6.7测试项目
6.7.1产品进行测试。
6.7.1.1范围:产品的哪些部分,不是您的测试范围内的责任?
6.7.1.2可用性:你有产品测试吗?
6.7.1.3波动:产品不断变化的吗?什么是需要重新测试?
6.7.1.4新东西:最近更改或添加到产品?
6.7.1.5可测试性:产品功能和足够可靠,可以有效地测试它?
6.7.1.6未来版本:测试的一部分,如果有的话,必须设计适用于未来版本的产品?
6.8交付
6.8.1可见产品的测试项目。
6.8.1.1媒体:你将如何记录和沟通你的报告吗?
6.8.1.2标准:是否有一个特定的测试文档标准你应该遵循?
6.8.1.3目的:你的可交付成果作为产品的一部分提供吗?任何人都有运行你的测试吗?
6.8.1.4内容:什么样的报告需要做吗?你能分享你的工作笔记,还是结果?