3.5. 操作。产品将会被怎样的使用。

　　? 用户：各种不同的用户的属性。

　　? 环境：产品操作所在的物理环境，包括例如噪音、灯光、和分心的事物这样的元素。

　　? 正常操作(Common Use)：产品输入的模式和顺序可能会与通常的使用习惯冲突。这根据用户的不同而不同。

　　? 异常操作(Disfavored Use)：由不了解、误解、不小心或者恶意的使用产生的输入模式。

　　? 极端操作(Extreme Use)：挑战与产品期望的使用方法一致的输入模式和顺序。

　　3.6. 时间。产品与时间之间的任何关系。

　　? 输入/输出：什么时候提供输入，什么时候创建输出，以及他们之间的时间联系（延迟、间隔，等等）。

　　? 快/慢：用“快速”输入或者“慢速”输入来测试；最快和最慢；快和慢结合起来测试。

　　? 变化率：加速和减慢（峰值、突然爆发、中止、瓶颈、中断）。

　　? 并发：一次发生超过一件事情（多用户，分时，线程、信号、和共享数据）。

　　4.质量标准类别

　　质量标准是一些定义产品应该是什么样的需求。通过对不同种类的标准的观察和思考，你会能够比较好的制定一个快速发现重要问题的测试计划。下面每一个列表中的条目都可以被认为是一个潜在的风险区域。对于下面的每一个条目，判断对于你的项目是否是重要的，然后思考你怎样得出产品是否运行得很好还是很差的结论。

　　4.1. 操作标准（Operational Criteria）。

　　? 能力。是否能完成需要的功能？

　　? 可靠性。是否运行得很好并且在所有需要的情况下都不会失效？

　　出错处理：产品在出错的时候抵制失效，并很快恢复，这在失效时是非常棒的。

　　数据完整性：系统中的数据避免丢失或被破坏。

　　安全：产品失效也不会对生命和财产造成威胁和伤害。

　　? 可用性。对于一个真实用户来使用这个产品到底有多容易？

　　可学习：产品的预期用户能够很快的掌握其操作。

　　可操作：产品操作起来不会很费劲，也不会很麻烦。

　　可接近：产品接近相关的标准，并且与操作系统的相关标准比较接近。

　　? 安全。在保护产品不受到非法的使用或入侵上做得有多好？

　　证明：系统验证用户的确是她所说的那个人的方式。

　　授权：授予被证明的用户不同程度的权限级别的权利。

　　隐私：客户或雇员数据避免受到未授权的人的危害的方式。

　　安全漏洞：系统不能保证安全的方式（例如社会工程的脆弱性）

　　? 可度量。产品按照比例放大或缩小的部署表现得有多好？

　　? 性能。系统有多快的响应速度？

　　? 可安装。产品安装到目标平台上有多容易？

　　系统需求：如果一些必须的组件缺失或者无效，产品是否能够识别？

　　配置：系统的哪一部分会受到安装的影响？这些文件和资源都保存在什么地方？

　　卸载：当产品被卸载时，是否可以干净的移除？

　　升级：新模块或者版本是否能很容易的增加？它们是否不改变已有的配置。

　　? 兼容性。同外部组件和配置一起运行得有多么好？

　　应用兼容性：产品和其它软件产品一起运行。

　　操作系统兼容性：产品运行在特定得操作系统上。

　　硬件兼容性：产品运行在特定的硬件组件和配置上。

　　向后兼容性：产品同自身早期的版本一起运行。

　　资源利用：产品没有使用不必要的大量内存、存储空间，或者其它系统资源。

　　4.2. 开发标准（Development Criteria）

　　? 可支持性。是否可以很经济的为产品的用户提供支持？

　　? 可测试性。产品能够被如何有效的测试？

　　? 可维持性。是否可以很经济的对产品进行打包、修复或者增强？

　　? 可移植性。是否可以很经济在其它地方移植或重用该技术？

　　? 本地化。产品是否可以很经济的适应其它地方？

　　规则：是否有超越州或国家边界的不同的规则或报告的需求？

　　语言：产品能容易适应更长信息,从右到左或者表意字的字体么？

　　货币：产品能够支持多币种么？币种汇率呢？

　　社会或文化差异：顾客可以发现文化参考资料中有令人费解的或者侮辱的吗?