HTSM测试模型
2024-06-26 10:32:02 0 举报AI智能生成
HTSM
作者其他创作
大纲/内容
谁是客户、谁有话语权、及利益干系人等
客户接触的方式，他们可能帮助你测试
对于进行的测试，客户可能有非常强烈的想法
预想的冲突，解决它
所有这个工程相关的用户
1.用户（理解产品的用户）
可得的文件、用户场景、网站资料等
产品是否是新的、之前的问题、客户抱怨的类型
测试前，是否有更多的产品相关的熟悉信息
你的信息是否是实时的、获取新信息的方式等
产品复杂或有挑战但产品中包含信息较少的部分
发现测试所需信息
2.项目信息
傲慢型：开发对于产品是否自信
防卫型：对于产品的某部分开发建议先不予测试
融洽：与程序员之间有无较好的工作关系
反馈环路：与程序员之间快速、有效的交流
反馈：开发对于测试策略的看法
3.与开发者的关系（协作）
谁将开展测试，人手够吗
测试过类似产品的人
开发人员
设计人员
用户
文档编写者
有不是测试团队成员但也能提供帮助的人吗
是否有足够测试技能的人执行相对合理的测试策略
团队是否有特殊测试技能的人或者需要具备，以执行测试技术
是否需要培训测试人员，是否有培训条件
团队力量支持测试
4.测试团队
硬件：是否有足够的设备去执行测试，设备是否可用
自动工具：是否需要自动化测试工具，是否可用
探测：处于测试时，是否有工具可以检测被测产品的状况，以辅助观察
矩阵或者测试表：是否需要文档来记录和追踪测试过程
硬件、软件、文档等
5.设备与工具
测试设计：你有多少设计时间，是否有一些测试设计的晚一些比较好
测试执行：什么时间开始执行测试，哪些测试需要重复执行，比如说回归测试
开发：哪些构建版本是可以进行测试的、添加新特性的、已封版本的
文档：哪些用户文档可以用来查阅
顺序、持续时间、项目事件的同步性
6.进度安排
测试范围：产品哪些部分是你的范围，哪些不是
测试可用：是否有可测的产品
产品变动：产品是否在不断的变更中，再次测试中哪些需要注意
新功能：产品是否有变化或者新功能添加
可测试性：产品的功能和可靠性是否保证你能有效测试
将来发布的版本：哪些测试用例必须在产品的新特性中执行
测试范围和重点
7.测试项目
交付方式：你怎么样记录结果和交流测试报告
交付标准：是否有测试文档的标准需要去遵守
交付目的：你的交付物是否作为产品的一部分，是否有别人运行你的测试用例
交付内容：如何生成你的报告，你会分享你的工作日志还是只是测试结果
测试的产出
8.交付物
1.项目环境
代码结构：构成产品的代码结构
接口：子系统间连接和通讯的点
硬件结构：对产品必不可少的任何硬件组件
非可执行文件，如多媒体文件、帮助文件等
附属产品，如纸质文档、在线文档、打包文件、许可证书等
产品组成元素（代码、接口、配置文件、可执行文件等）
1.结构
产品的核心功能需求
应用
产品功能的中的算术功能或者操作
计算/算法
超时设定、每日或月末报告、夜晚批处理、时区、工作日节假日、利息计算、项目或权限有效周期、计时功能
时间相关
修改或变更某些东西，例如改变账户余额、修改订单状态等
变化/改变
在请求、初始化以及退出服务时，注意方法和接口的处理
启动和关闭
声音、位图、视频，或者嵌入在产品中的任何图形化的显示等
多媒体
功能对错误的检测、从错误中如何恢复，还有错误的信息提示
错误处理
各服务、接口间的交互通讯，如浏览器、显示界面、数据输入窗口
交互/用户界面
辅助测试的功能，例如诊断功能、日志文件、断言等
可测性
产品的功能，做的事情
2.功能
产品处理的输入数据
输入
产品的处理结构
输出
作为产品的一步的数据或者内置的数据
预置
任何内置的并且会在多个操作持续使用的数据，像记录、样式、状态等
持久配置项
数据的任何顺序或排列，例如：字母顺序、已排序的数据等
顺序/组合
对象的个数或值域，例如取值范围从1到9，有限个枚举，唯一性
基数
数据的变化区间和集合的最大最小值
数据规模
无效或具有破坏性的数据、产生于不受控制的或错误的处理过程的数据
异常数据
必须覆盖数据从生成、读取、修改、删除的生命周期
生命周期
产品所操作的数据，处理的那些事情
3.数据
让用户可以改变数据的元素，例如操作面板、按钮等
用户接口
与其他系统、磁盘、网络等交互的接口
系统接口
可编程的接口或工具
API/SDK接口
可以提供打包数据的功能，导入其他数据的功能
导入/导出
产品可用的通道
4.接口
为了使产品能够提供服务的，非产品本身需要的硬件设备。例如负载均衡器、网络交换器、加密机等
硬件
为了使产品能够提供服务的，非产品本身需要的软件设施。例如操作系统、驱动程序等
软件
库或者组件，被嵌入在你的产品中，是产品提供服务所需但产生于项目外部的
其它元素
产品所依赖的外部元素
5.平台
每类用户使用产品的特征是什么
产品将被使用的物理环境怎样？噪音、灯光、网络情况（APP测试特别需要关注）
环境
产品通常遇到的输入的形式和操作顺序
通常的使用/正常操作
不在意的、错误的、恶意的输入形式和操作顺序
不受欢迎的使用/异常操作
具有挑战性的输入形式和操作顺序
极端的使用
产品将被如何使用
6.操作
什么时候输入，什么时候输出，输入输出间时间关系，如延迟、间隔等等
输入输出
使用“快”和“慢”的输入操作，最快和最慢，慢和快结合起来测试
快和慢
一会快一会慢，例如平缓加快输入、突然加大输入、挂起处理导致瓶颈、中断操作）
改变速率
一次发生超过一个事情，如多用户、时间片、多线程、信号量、共享数据
并发
影响产品的时间因素
7.时序
4.产品元素
识别产品的能力（功能及子功能）
如何验证功能正常且有效
测试每一个功能，一次只测试一个
确保功能做了它该做的，而没有做它不该做的
测试软件的能力
1.功能测试
关注产品的数据处理，包括输入和输出
边界值
典型值
有效值
无效值
最具代表值
决定测试需要哪些特殊的数据
考虑将相关数据组合在一起测试
测试软件所处理的数据
2.领域测试
在过压数据或约束受限的资源下，查看脆弱的子系统或者功能
识别与子系统或者功能相关的数据和资源
大量的或复杂的数据结构
高负载
长时间测试
大量测试用例运行
小内存条件
选择或生成过压的数据，或者在约束受限的资源下进行测试
测试产品的压力
3.压力测试
定义测试流程或者高水平测试点进行端到端的复杂活动测试
测试过程中不要重置系统
变化时间和顺序，并且尝试并发的线程
工作流，业务流，即测试软件的操作顺序
4.流程测试
思考产品周围的所有东西
设计完整和真实的交互作用的产品测试用例
一个好的场景测试用例一定是真实用户和产品交互的故事
测试有说服力的场景
5.场景测试
确认产品声明的各项要求（隐形或者显性）
分析声明条款，澄清模糊的声明
确保产品的每一个声明都是真实的，符合要求的
如果测试一个明确的规范说明，一定确保与产品的一致性
测试需求规格、广告宣传等文档的声明
6.声明测试
定义用户的角色和类别
确定每一类用户应该做什么测试及怎么做，他们的价值关注是什么
获得真实的用户数据，使得真正的用户去测试
模拟用户去测试
有效的用户测试是围绕一定数量的用户和角色，不仅仅是一个
邀请用户测试
7.用户测试
产品包含哪些种类的问题
哪些问题最重要，聚焦它
如果有风险的话，你应该如何识别
制作一个风险问题清单，并去设计用例揭示它
咨询专家、设计文档、过去的BUG报告、应用风险启发，可能有帮助
想象一个问题，然后找出它
8.风险测试
寻找机会自动生成大量测试
开发自动化的、高速的评估产品机制
编写程序来生成、执行和评估测试
运行无数的不同测试
9.自动化测试
生成测试策略
2.测试技术
满足功能
1.1功能性
在合理的条件下，产品持续运行而没有崩溃
健壮性
系统中的数据应受到保护，防止丢失或污染
数据完整性
当发生错误时，产品能防止失败，优雅降级，从错误中恢复
产品应当不会危及人的生命和财产安全
安全性
正常情境下的工作与抵御失效
1.2可靠性
目标用户能够快速学会使用
可学习性
能够以最小的付出完成操作
可操作性
遵循的标准或者特征
可使用性
真实用户使用产品的容易程度
1.3可用性
系统不能保证安全的地方
安全漏洞
已认证的用户所拥被赋予的权限
授权和权限
系统确认用户身份的方式
身份认证
用户数据应受到保护，防止未授权的访问的
数据保密性
非法使用
1.4安全性
产品对感观产生的吸引力
美学
在一定程度上，产品是新颖的或者独特的
独特性
产品拥有用户特别期望的某种能力
必备性
产品能很好地解决某些重要问题
有用性
能使用户着迷、获得乐趣，完全融入其中
粘性
产品投射出用户的某种渴望
想象性
产品有多吸引人
1.5吸引力
计算能力
网络带宽
处理能力
系统上下的一种弹性
1.6可伸缩性
速度和反应能力
1.7性能
是否容易添加新模块或升级新版本？是否会对已有配置造成影响
升级/补丁
当产品被卸载后，是否能移除干净？
卸载
安装是否需要特定的人员角色或时间计划
管理
配置：系统怎么安装配置，文件资源存储位置等
系统要求：当必要的组件或资源丢失或不满足时，产品是否自动能识别
在目标平台安装简洁
1.8可安装性
资源使用率：产品不会独占内存、磁盘和其他系统资源
向后兼容，更早版本的适应性：产品与老版本协同工作
硬件兼容性：产品与特定硬件协同工作
操作系统兼容性：产品与特定操作系统协同工作
应用兼容性：产品与其他软件系统协同工作
与其它组成部分协作
1.9兼容性
面向用户和运营
1.操作标准
合理的提供给用户，为用户提供支持需要花费多少成本
2.1可支持性
有效的测试性，产品是否能有效地被测试
2.2可测试性
合理的建造、强化产品，构建、修复和增强产品需要花费多少成本
2.3可维护性
技术复用，移植或复用技术的成本
2.4可移植性
合理的适应其它环境
关联：不同的需求
语言
货币：支持多种币种，币种汇率
文化差异
2.5本地化能力
面向开发，能否顺畅地进行开发、测试和修改产品
2.开发标准
3.质量标准
HTSM测试模型
0 条评论
回复 删除
下一页
