√ 性能：它的运行速度和反应如何？
√ 易安装性：在其目标平台上它能够很简易的安装吗？
√ 兼容性：它能够在外部的部件和配置中很好的运行吗？
√ 保障性：对客户提供产品支持的费用是否经济？
√ 易测性：在产品被测试的时候是否易测呢？
√ 可维护性：它构造、安装或者增加功能是否经济呢？
√ 便携性：它携带到港口或者在别处技术重用是否经济呢？
√ 本地化：用其他的语言出版该产品是否经济呢？
我拼凑起来的这个有很多的来源，包括ISO9126标准、惠普的FURPS的列表和其他一些来源。关于这个列表没有什么权威性，只是包括了我在桌面应用程序测试的时候有用的一些部分。我记得这个列表是用缩写CRUPIC STeMPL。为了记住它，大声说缩写和想象它是罗马尼亚一个冰球运动员的名字。稍加练习你将会在任何你需要它的时候在你的脑海里召唤出那个名单。
……………………
查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html
六、组织基于风险的测试三种方法
不论你是使用由外至内、由内至外还是一些交叉的方法进行分析，我可以提出三种不同交流方式的风险，并组织关于这些风险的测试：风险检查表、风险/任务矩阵、或者组件的风险矩阵。
● 风险查看表
这种方法可能是组织基于风险的测试最简单的方法。一个风险查看表仅仅就是一个定期检讨风险，你要问自己的测试是否揭示出这些问题。如果你觉得自己没有足够的关于了解风险产品问题的最新资料，那么就做很多的测试，以收集更多的信息。
● 风险/任务矩阵
风险/任务矩阵是由一个有两列的表格组成。左边是一个风险清单；右边是一个可以减轻和其他风险相关的任务的列表。按照风险的重要性排序，将最重要的风险放在最顶端。像这样思考矩阵中的每一行“如果我们担心风险X，那么我们应该在任务Y上投入更多的时间。”
风险/任务模型用于对测试资源进行交涉时是一个非常有用的工具。我喜欢在下面的情况使用这个技术，管理者不接受比较次等的测试，但也不提供足够测试人员测的工作。矩阵有助于使得管理者的期望符合有限的资源。当你在解释没有足够的资源的影响时，这个方法将会很容易得到测试资源。
这个方法的缺点是一些任务可以减轻不止一个风险。另外，一些减轻的任务成本高或者花费很多的时间，它们实际上在帮助发现问题期间产生的价值，不如对项目造成的问题。尽管如此，它仍然是基于广泛项目基础的揭示风险和测试本质关系比较简单的一种方法。
……
查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
