测试用例资料.doc

,即测试的需求测试用例的主要来源有:1)需求说明”及相关文档2)相关的设计说明(概要设计,详细设计等)3)与开发组交流对需求理解的记录(可以是开发人员的一个解释)4)已经基本成型的UI(可以有针对性地补充一些用例)简而言之,所有你能得到的项目文档,都尽量拿到。从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。,原则上,只要方便管理和跟踪,怎么组织都可以的。用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组织在一起。文档来自于网络搜索在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未执行”的用例的状态,共3种状态。即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通过”。将同一状态的用例组织在一起。文档来自于网络搜索至于用例文件格式,(如果有专门的测试用例管理工具另当别论)。,即如何解决用例跟踪的问题测试用例面临的比较大的风险有:需求的变更、设计的修改、需求的错误和遗漏等等。由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的变更势必引起测试用例的变更。文档来自于网络搜索如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功能点和测试用例间的关联关系。这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增加了新的功能点。,即用例中应当包含的信息一个优秀的测试用例,应该包含以下信息:1)软件或项目的名称2)软件或项目的版本(内部版本号)3)功能模块名4)测试用例的简单描述,即该用例执行的目的或方法5)测试用例的参考信息(便于跟踪和参考)6)本测试用例与其他测试用例间的依赖关系7)本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO9)步骤号、操作步骤描述、测试数据描述10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)11)开发人员(必须有)和测试人员(可有可无)12),该范例已经包含一个测试用例的模板 备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有“user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证)等等。文档来自于网络搜索界面设计与测试规则界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。文档来自于网络搜索1、易用性:按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。    易用性细则:    1)完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。    2)完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。    3)按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。    4)界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。    5)界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。    6)同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。    7)分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab    8)默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。    9)可写控件检测到非法输入后应给出说明并能自动获得焦点。    10)Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。    11)复选框和选项框按选择几率的高底而先后排列。