开源软件测试模型(2)

　　交付性：需要生成何种的报告，是否要共享中间测试结果还是仅提交最终结果?

　　3.3 测试团队

　　指任何将要执行或支持测试的人员。

　　工作负载

　　是否有足够人力按来照期望时间完成所有计划好的测试工作?

　　专家能力

　　否拥有与项目有关的正确知识以很好地完成计划好的测试工作?

　　组织

　　所有测试工作是否得到有效协调并目标一致?

　　3.4 测试工作平台

　　指用于支持和管理测试的软硬件平台。

　　测试平台——是否拥有测试执行所需的全部设备和平台?

　　测试工具——需要那些测试工具?他们是否可用?

　　测试库——是否测试过程中的任意文档和结果均要保存并进行跟踪吗?

　　错误跟踪系统——如何进行错误报告和跟踪?

　　四、产品元素

　　软件产品最终体现为提供给客户的一种操作经历或解决方案，包括支撑平台、软件元素和用户操作，以及相互之间的数据交互，具有多维的特点。为了测试工作取得成效，必须综合考虑这些层面。以下给出软件产品应包含的一些重要的元素类别，如果仅注意测试其中几个类别则可能会遗漏重要错误。这些类别提供了一个起始点，需要在特定环境中细化。

　　4.l 支撑平台

　　指软件产品所依赖的任何事物。

　　外部硬件。用于支撑软件产品工作的硬件元素和配置，不作为产品的组成部分，如CPU、内存、键盘等。

　　外部软件。用于支撑软件产品工作的其他软件元素和配置，不作为产品的组成部分，如操作系统、驱动程序、字体等等。

　　4.2 软件元素

　　结构

　　指组成软件产品的任何事物。

　　代码：组成产品的任何代码结构，从可执行码直至单个例程。

　　接口：子系统之间的连接和通信点。

　　硬件：任何作为为产品组成部分的硬件元素。

　　非执行文件：除程序外的任何文件如文本文件、样本数据、帮助文件等等。

　　其他介质：软件和硬件之外的任何介质，如纸面文档、Web连接和内容、包装、许可证协议等等。

　　功能

　　指产品要完成的任何事情。

　　用户接口：任何协调与用户交换数据的功能。

　　系统接口：任何协调与用户之外的其他实体(如其他程序、硬盘、网络、打印机等等)交换数据的功能。

　　应用：任何用于定义产品、区分产品或完成核心需求的功能。

　　错误处理：任何检测错误和从错误中恢复的功能，包括所有的错误消息。

　　可测试性：任何支持测试该产品的功能如诊断程序、日志文件、声明、测试菜单等等。

　　数据

　　指产品要处理的任何任何事物。

　　输入：产品要处理的任何数据。

　　输出：经产品处理后产生的任何结果数据。

　　预置值：要作为产品的一部分提供给客户、或直接构建在产品内部的任何数据如预制数据库，缺省值等等。

　　固定值：存储在内部、在多个操作中应保持一致的任何数据，包括产品模式或状态如选项设置、视图模式、文档内容等等。

　　时序：数据和时间之间的任何关系，如每秒击键次数、文件的时间戳、或分布式系统的同步。

　　非法：任何能够触发错误处理函数的数据或状态。

　　4.3 操作

　　指产品将被如何使用。

　　使用情景——与时间相关的操作模式，包括产品在相关领域要典型处理的数据模式，随用户而变化。

　　物理环境——产品运行的物理环境，比如噪音、照明等等。

　　五、质量准则

　　当声称一个产品是“高质量”时，意味着“高度”满足了该产品的受益人所定义的质量准则。测试工作常常不得不在质量准则不很明确的情况下进行，以下所给出的准则类别可帮助进行“头脑风暴式”思考或揭示那些需要知道的问题，尤其适合根据实际项目进行定制。建议同时参考ISO 9126质量特性标准或其他相关软件工程标准。

　　5.1 操作准则

　　能力——产品能否执行要求的功能?

　　可靠性—— 在所有要求的情况下产品均能正常工作并抵御失败吗?

原文转自：http://www.uml.org.cn/Test/201106012.asp