软件测试用例的模版

一般的软件测试不是很全面，求标准的软件测试模版（表格版）；当前测试项目是B/S架构的企业经营管理系统

原发布者:xuzikun76

RUP模版------《测试计划》测试计划版本[注：以下提供的模板用于RationalUnifiedProcess。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=BodyText）。][要定制MicrosoftWord中的自动字段（选中时显示灰色背景），请选择File>Properties，然后将Title、Subject和Company等字段替换为此文档的相应信息。关闭该对话框后，通过选择Edit>SelectAll（或Ctrl-A）并按F9，或只是在字段上单击并按F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见Word帮助。]修订历史记录目录1.简介31.1目的31.2背景31.3范围31.4项目标识32.测试需求33.测试策略33.1测试类型33.1.1数据和数据库完整性测试33.1.2功能测试33.1.3业务周期测试33.1.4用户界面测试33.1.5性能评价33.1.6负载测试33.1.7强度测试33.1.8容量测试33.1.9安全性和访问控制测试33.1.10故障转移和恢复测试33.1.11配置测试33.1.12安装测试33.2工具34.资源34.1角色34.2系

我做软件测试4年了，我说几点，供参考 1.测试用例的作用就是方便回归测试以及不同人员的交叉测试，由于每个人的角度不同，所以在设计测试用例的时候，如果时间充足，需要尽可能多的让更多的人看到并修改这份测试用例，使用例的覆盖度达到最高，否则，用例是没有意义的 2.用例需要及时维护和更新，根据需求和实际产品经常要更新用例。 3.编写的时候无非是 六个值原则 “正常值 异常值 “0”值 空值 默认值 边界值” ，把握好这六个值来设计用例。 楼主说到的 功能间的内聚比较高的情况，在设计测试用例时，关联到其他功能的数据可以在操作过程中直接给出取值范围 比如 装备模块 盔甲需要40-60等级的战士才能穿 设计用例的时候直接写出范围就可以

其实没有适用于所有情况的模板，测试用例只要包含关键要素即可，比如编号、优先级、测试目的、步骤、预期结果等，不必拘泥于某一种形式； 测试用例的关键在于其设计，即如何采用合适的测试方法，做到最大覆盖，同时用例数量尽量少，有了这些设计以后，清晰的表达出测试用例即可。

写好一个软件的测试用例的建议有： 1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。 2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。 3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。 4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。 5、测试用例级别要划分清楚，这样在测试执行时有主次之分。 6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。