下载文档原格式
SugarCRM_ST_Dashboard_RELATION-CONTACTS-01 SugarCRM_ST_Dashboard_RELATION-CONTACTS-02 SugarCRM_ST_Dashboard_RELATION-ACCOUNTS_01 SugarCRM_ST_Dashboard_RELATION-ACCOUNTS_02 SugarCRM_ST_Dashboard_RELATION-LEADS_01 SugarCRM_ST_Dashboard_RELATION-LEADS-02 SugarCRM_ST_Dashboard_RELATION-OPPORTUNITY_01 SugarCRM_ST_Dashboard_RELATION-OPPORTUNITY_02 SugarCRM_ST_Dashboard_RELATION-CASES_01 SugarCRM_ST_Dashboard_RELATION-CASES_02 SugarCRM_ST_Dashboard_RELATION-BUG TRACKER_01 SugarCRM_ST_Dashboard_RELATION-BUG TRACKER_02 SugarCRM_ST_My Portal_ADD_01测试Dashboard模块的关联联系人功能关联联系人，跳转到联系人模块测试Dashboard模块的关联联系人功能关联联系人，跳转到联系人模块测试Dashboard模块的关联客户功能关联客户，跳转到客户模块测试Dashboard模块的关联客户功能关联客户，跳转到客户模块测试Dashboard模块的关联潜在客户功能关联潜在客户，跳转到潜在客户模块测试Dashboard模块的关联潜在客户功能关联潜在客户，跳转到潜在客户模块测试Dashboard模块的关联商业机会功能关联商业机会，跳转到商业机会模块测试Dashboard模块的关联商业机会功能关联商业机会，跳转到商业机会模块测试Dashboard模块的关联客户反馈功能关联客户反馈，跳转到客户反馈模块测试Dashboard模块的关联客户反馈功能关联客户反馈，跳转到客户反馈模块测试Dashboard模块的关联缺陷跟跟踪功能关联缺陷跟踪，跳转到缺陷跟踪模块测试Dashboard模块的关联缺陷跟跟踪功能关联缺陷跟踪，跳转到缺陷跟踪模块测试My Portal模块的新增站点功能新增网站信息高能正常运行无到Contacts模块，对联系人进行创建高Dashboard模块能正常运行无1、点击【Create Conta】，跳转到非Contacts模块，跳转错误高Dashboard模块能正常运行无1、点击【Create Account】，成功跳转到Accounts模块，对客户进行创建高Dashboard模块能正常运行无1、点击【Create Account】，跳转到非Accounts模块，跳转错误高Dashboard模块能正常运行无1、点击【Create Lead】，成功跳转到Leads模块，对潜在客户进行创建高Dashboard模块能正常运行无1、点击【Create Lead】，跳转到非Leads模块，跳转错误高Dashboard模块能正常运行无1、点击【Create Opportunity】，成功跳转到Opportunitys模块，对商业机会进行创建高Dashboard模块能正常运行无1、点击【Create Opportunity】，跳转到非Opportunitys模块，跳转错误高Dashboard模块能正常运行无1、点击【Create Case】，成功跳转到Cases模块，对客户反馈进行创建高Dashboard模块能正常运行无点击【Create Case】，跳转到非Cases模块，跳转错误高Dashboard模块能正常运行无1、点击【Report Bug】，成功跳转到Bug Tracker模块，对缺陷进行创建高Dashboard模块能正常运行无1、点击【Report Bug】，跳转到非BugTracker模块，跳转错误高成功跳转到Contacts模块成功跳转到Contacts模块成功跳转到Accounts模块成功跳转到Accounts模块成功跳转到Leads模块成功跳转到Leads模块成功跳转到Opportunitys模块成功跳转到Opportunitys模块成功跳转到Cases模块成功跳转到Cases模块成功跳转到Bug Tracker模块成功跳转到Bug Tracker模块。
模块接口测试
外部输入输出
检查局部数据结构路径测试和循环测试
判断与控制流
单元测试
1 输入的实际参数与形式参数的个数是否相同；
2 输入的实际参数与形式参数的属性是否匹配；
3 输入的实际参数与形式参数的量纲是否一致；
4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
7 调用预定义函数时所用参数的个数、属性和次序是否正确；
8 是否存在与当前入口点无关的参数引用；
9 是否修改了只读型参数；
10 对全程变量的定义各模块是否一致；
11是否把某些约束作为参数传递。
1 文件属性是否正确；
2 OPEN/CLOSE语句是否正确；
3 格式说明与输入输出语句是否匹配；
4缓冲区大小与记录长度是否匹配；
5文件使用前是否已经打开；
6是否处理了文件尾；
7是否处理了输入/输出错误；
8输出信息中是否有文字性错误；
1 不合适或不相容的类型说明；
2变量无初值；
3变量初始化或省缺值有错；
4不正确的变量名（拼错或不正确地截断）；
5出现上溢、下溢和地址异常。
1 误解或用错了算符优先级；
2混合类型运算；
3变量初值错；
4精度不够；
5表达式符号错。
1不同数据类型的对象之间进行比较；
2错误地使用逻辑运算符或优先级；
3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；4比较运算或变量出错；
5循环终止条件或不可能出现；
6迭代发散时不能退出；
7错误地修改了循环变量。
测试用例模板（Test Case Template）┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃用例编号│┃┠──────┼───────────────────────────┨┃测试优先级│┃┠──────┼───────────────────────────┨┃用例摘要│┃┠──────┼───────────────────────────┨┃测试类型│┃┠──────┼───────────────────────────┨┃用例类型│┃┠──────┼───────────────────────────┨┃用例设计者│┃┠──────┼───────────────────────────┨┃设计日期│┃┠──────┼───────────────────────────┨┃对应需求编号│┃┠──────┼───────────────────────────┨┃对应UI│┃┠──────┼───────────────────────────┨┃对应UC│┃┠──────┼───────────────────────────┨┃版本号│┃┠──────┼───────────────────────────┨┃对应开发人员│┃┠──────┼───────────────────────────┨┃前置条件│┃┠──────┼───────────────────────────┨┃测试方法│┃┠──────┼───────────────────────────┨┃输入数据│┃┠──────┼───────────────────────────┨┃执行步骤│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┠──────┼───────────────────────────┨┃预期输出│┃┠──────┼───────────────────────────┨┃实际结果│┃┠──────┼───────────────────────────┨┃测试日期│┃┠──────┼───────────────────────────┨┃结论│┃┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛sample┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃用例编号│BOSS_ FS_ MARKETING_NEW_01P┃┠──────┼───────────────────────────┨┃测试优先级│高（还有“较高、中、较低、低”几个等级）┃┠──────┼───────────────────────────┨┃用例摘要│新增营销记录┃┠──────┼───────────────────────────┨┃测试类型│功能性测试（对应还有“安全性测试”等）┃┠──────┼───────────────────────────┨┃用例类型│基本事件（对应还有“备选事件”、“异常事件”）┃┠──────┼───────────────────────────┨┃用例设计者│songfun┃┠──────┼───────────────────────────┨┃设计日期│2005-04-25┃┠──────┼───────────────────────────┨┃对应需求编号│REQ_ MARKETING_NEW_01┃┠──────┼───────────────────────────┨┃对应UI│Marketing.htm┃┠──────┼───────────────────────────┨┃对应UC│UC_ MARKETING_NEW_01┃┠──────┼───────────────────────────┨┃版本号│Build v0.1┃┠──────┼───────────────────────────┨┃对应开发人员│Frank┃┠──────┼───────────────────────────┨┃前置条件│操作员登录营销管理系统┃┠──────┼───────────────────────────┨┃测试方法│等价类划分（对应还有“错误猜测法”、“边界值分析”等）┃┠──────┼───────────────────────────┨┃输入数据│用户名：testing 性别：男金额：10元描述：aaaaaaa┃┠──────┼───────────────────────────┨┃执行步骤│①.进入【营销下发】页面；┃┃│②.点击『增加』按钮；┃┃│③.输入相应数据；┃┃│④.点击『确定』按钮；┃┃│⑤.在后台数据库(test/test@testDB)输入查询语句验证：┃┃│select * from MarketingTab where ID='1001'┃┃│┃┠──────┼───────────────────────────┨┃预期输出│㈠.执行步骤④后，页面弹出添加成功提示信息框；┃┃│㈡.执行步骤⑤后查询数据库，记录确实添加成功且数据无误┃┃│┃┠──────┼───────────────────────────┨┃实际结果│符合预期┃┠──────┼───────────────────────────┨┃测试日期│2005-05-01┃┠──────┼───────────────────────────┨┃结论│┃┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛。
测试检查表checklist输入、编辑功能的验证检查点：1. 必输项是否有红星标记，如果不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致；2. 输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’ <>,./?;3. Form下拉菜单的值是否正确，下拉菜单的值通过维护后是否正确显示并可用；下拉菜单比如是机构编码，要到机构编码的维护界面查询一下是否Form列出的与其一致；4. 涉及到下拉菜单的编辑修改Form，要检查在编辑和修改From中，下拉菜单是否能正确显示当前值；5. Form提交后，要逐项检查输入的内容跟通过查询的结果一致；6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确；7. 备注字段的超长检查；8. 提交保存后能否转到合适的页面；9. 编辑Form显示的数据是否跟该记录的实际数据一致；10. 编辑权限的检查，比如：user1的数据user2不能编辑等；11. 可编辑数据项的检查，比如：数据在正式提交之前所有的属性都可以编辑，在提交之后，编号、状态等不能编辑，要根据业务来检查是否符合需求；12. 对于保存有事务Transaction提交，比如一次提交对多表插入操作，要检查事务Transaction的处理，保证数据的完整和一致；13. 其他的合法性校验。
查询功能检查点：1. 查询输入Form是否正常工作，不输入数据是否查询到全部记录；2. 当查询的数据非常多的时候，性能有无问题；3. 查询的下拉菜单列出的数据是否正确；4. 查询结果是否正确；对于复杂的查询要通过SQL来检查结果；5. 如输入%*?等通配符是否会导致查询错误；6. 查询结果列表分页是否正确，在点击下一页上一页时，查询条件是否能带过去，不能点击翻页时又重新查询；7. 对于数据量比较大的表查询时，不容许无条件查询，避免性能问题的出现；8. 对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等；9. 分页的统计数字是否正确，共X页，第N页，共X条记录等；10. 对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确；11. 查询结果有超链接的情况要检查超链接是否正确；12. 查询权限的检查，比如：user1不能查询到user2的数据等；删除功能检查点：1. 必须有“确认删除”的提示；2. 根据需求检查是软删除还是硬删除，来检查数据库中是否还存在该条记录；3. 是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成；4. 是否有删除约束，如果有删除约束，要检查该记录是否被约束，如果被约束该记录不能被删除；5. 如果是软删除，用查询、统计界面检查该条记录能否被查询出来，数据是否被统计进去；6. 检查因为业务约束不能删除的数据能否被保护不能手工删除，比如：流程中已经审批的文件不能被删除；7. 跟删除相关的权限问题，比如：需求要求只有管理员和该记录的创建人能够删除该记录，那就以不同的用户和角色登录进去，执行删除操作，检查是否与需求匹配；上传附件检查点：1. 检查是否能正确上传附件文件；2. 检查上传的文件是否能正确下载并打开；3. 至少检查下列大小的文件能正确上传，0k,100k,1M,2M,4M,10M,20M等；4. 如果没有指定类型的限制，至少上传以下几种类型的文件能否正确上传并正确打开，类型有：.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等；5. 如果有文件类型的限制还要检查能上传的文件的类型；6. 上传同名的文件，在打开的时候是否出错；7. 有中文文件名的文件能否正确上传；影响操作性能的检查点：（不能代替系统的性能测试和压力测试，主要看系统在正常操作情况下的响应和处理能力）1. 对数据记录条数比较多的表的查询操作，避免全表查询，比如对银行用户账号的查询就不能缺省全部查出，必须让用户输入查询条件；2. 菜单树，测试大量数据时菜单树的响应情况；3. 有日志的查询或者统计，要注意查询的效率；4. 大报表的处理或者批处理的操作，要关注效率，比如：银行对帐、财务年终结算、财务年报表、系统初始化等；5. 大报表的排序sort、组函数的使用等；6. 大数据量的处理，如导入、导出、系统备份、文件传输等。
目的:
规程简要说明:
2）在项目测试用例评审时，评审人员参考该检查表内容对测试用例进行评审，以发现测试用例的问题。
3）对《项目测试记录》文档的测试用例Review时，参考测试记录检查表。
对《项目测试用例》文档中的测试用例评审时测试用例检查表。
本文件的目的是提供测试用例评审使用该文件发现测试用例不足的地方，帮助评审人员
描1）确认并定制适用的检查项。
如果该检查表中通用检查项不足，测试人员可根据项目实际需要，在检查内容中定义补充
行评审，以发现测试用例的问题。
表。
对《项目测试用例》文档中的测试用例评审时，使用
审人员更有效的执行评审活动。
人员可根据项目实际需要，在检查内容中定义补充检查项。
由于格式的限制，这里给一个列表。
1. 是否涵盖了需求文档上的每个功能点2. 是否涵盖了需求文档上的每条业务规则说明3. 是否覆盖了输入条件的各种有意义组合4. 是否覆盖了业务操作的基本路径和异常路径5. 是否考虑了重要表单字段的数据合法性检查6. 是否考虑了其他的测试类型(对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面)7. 是否考虑了对其他模块/功能的影响8. 是否使用了项目组的标准用例模板9. 用例是否覆盖了测试设计中定义的所有场景10.用例编号是否统一、规范11.用例名称是否简洁、明了12.目的字段是否准确地描述了对应场景的测试输入的特征(不同数据，操作，配置等)13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例14.对应的需求编号字段是否填写正确15.用例粒度、预估出的执行时间是否适当16.同组用例中，仅数据不同的，是否实现了测试步骤的重用17.某个功能点的第一个用例是否是基本流的18.操作步骤的描述，是否清晰、易懂19.操作步骤是否充分和必要，并具有可操作性20.测试用例的检查点是否明确、充分和可操作21.单个用例步骤或检查点中是否不再存在分支22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值23.文字、语法是否准确;布局、格式是否统一测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例(Test Case)目前没有经典的定义。
比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
领测国际认为不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
测试用例评审表序号评审项1用例是否按照本部门规定的模板编写，如命名、类型、优先级、内容描述。
2测试步骤应与描述相一致3测试步骤和期望结果应完整、一致、清晰4操作步骤应仅包含与被测项相关的内容5期望结果应是确定的、唯一的6每个软件测试用例的操作步骤<=157对于由系统自动生成的输出项应注明生成规则8对于查询和表格，应设计产生数据的用例9测试用例本身描述是否清晰，是否存在二义性，与需求目标一致10软件测试用例应包含对中间和后台数据的检查11场景测试用例应覆盖最复杂的业务流程12场景测试用例的执行顺序应符合实际的业务流程13可重用（对被测项的当前版本和后续版本）14可跟踪性（与软件测试需求相对应）15如果存在不可测需求，应列出并进行说明16软件测试用例应确保所有的软件测试需求被覆盖以上为必须通过的测试项17软件测试用例执行后是应将软件测试环境恢复到执行前的状态18应包含相关的配置信息：环境、数据、前置测试用例、用户授权等19用词规范、准确、一致20场景测试用例中应包含每个业务流程环节的中止和回退相关的设计和组合21用例设计是否包含了正面、反面的用例评审结果：序号评审项1 是否按照测试计划完成用例编写2《需求规格说明书》是否评审并建立了基线3需求新增和变更是否进行相应地调整4测试用例是否包含边界值、等价类分析、因果图、错误推测等测试用例设计方法5是否针对需求的不同部分设计使用不同设计方法6用例覆盖率是否达到相应质量指标评审结果：1 2每个模块的评审结果分为通过、基本通过、不通过，其中基本通过和不通过必须填写说明：评审结果分为通过、不通过。
当必须通过的评审项通过时其评审结果为通过。
初审模块1模块2模块3评审人：评审日期：二审模块1模块2模块3试用例设计方法评审人：评审日期：过必须说明原因，并附上哪些用例不通过的编号或说明。
过。
总模块总模块。
