总结用例图的重要作用，讨论并指出哪些场合下可以使用用例图
校园一卡通顾名思义，使用一张卡完成校园所有电子业务的应用。
当前学校电子业务应用主要分为两类：消费和身份识别。
1、消费：包括餐厅吃饭消费、澡堂洗浴消费、超市消费、医务室、体育场馆收费等。
2、身份识别类：新生注册（数字迎新）、图书借阅、寝室和教学楼的门禁和考勤识别等。
而使用的校园卡多为mifare卡，根据卡中存放信息分为ic卡和id卡： 1、IC卡是集成电路卡，通过卡里的集成电路存储信息，此类卡存放的有各种人员信息和账户信息，与应用终端（消费机、考勤机）交互后需要上传到数据库人员信息表中，使得数据库与卡片同步，与数据库交互不够及时，批量上传数据。
2、ID卡是身份识别卡，卡中只存放一条帐号信息，每次与应用终端交互都需要与数据库交互，此类卡的应用终端必须实时联网，写校园一卡通设计的话推荐此种卡片。
数据库建一组相互关联的表，使得能存放完整的人员信息，人员信息主要字段自少包括：姓名、学号、班级信息、卡号、账户金额（消费金额）、消费各种状态信息（）、权限类别（考勤的权限、食堂消费权限、洗浴消费权限、门禁刷卡权限）等，消费记录表包括交易流水、交易时间、交易地点、交易金额等。
卡与消费终端交互流程： 1、鉴权：根据应用终端的类别，交互数据库取出该账户权限类别，判断是否有资格。
2、如鉴权通过，上传消费终端上输入的消费金额，平台根据上传金额与数据库提取出来的账户余额对比，判断金额是否合理。
3、平台自动操作数据库更改消费后的账户余额及相关信息。
注：一卡通的充值流程同消费流程，纯手工敲的，欢迎采纳，一卡通业务方面问题可以powerliu@163.com。
软件测试评审报告咋写，画完用例图后老师让写评审报告，不知道咋写。
评审过程的规范性：1、评审的准入；2、评审的准出；3、评审这个过程的一些要求：如哪些评审员参加
计划性如何
使用检查单
预审情况
缺陷发现情况
缺陷修复情况
总结分析情况及评审结论
4、识别一些改进机会，记录NC自己整理吧 下面是模板2楼 性能测试目标中应对响应时间和处理能力指标进行明确的定义 性能测试模型评审完成 性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明 测试场景中应具备明确的虚拟用户名称、数量\\\/百分比、思考时间（ThinkTime）、检查点、测试数据说明 测试场景应具备明确的测试环境说明，包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息 测试场景应具备明确的被测应用系统基础数据信息，包括基础数据量、类型（模拟数据\\\/生产数据） 性能测试过程评审完成 性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务 每项测试任务应具备明确的测试方法说明 每项测试任务应具备明确的状态（完成\\\/未完成） 若某项测试任务未完成，则该项测试任务应具备明确的未完成原因以及解决方法说明 性能测试单项任务数据分析评审完成 每个单项任务应具备明确的测试目的 每个单项任务应具备明确的测试数据分析 性能测试结论评审完成 每个性能测试目标应具备至少一条结论 每条结论应针对一个具体的性能测试目标 性能测试缺陷评审完成 所有已发现缺陷都具备确的状态（已解决\\\/未解决） 所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人） 性能测试分析报告评审完成 若有一项评审结果为“不通过”，则此项为“不通过” 所有与会各方人员签字认可评审结果 若有一方人员未到场，此次评审视为无效。
评审会议结束后，将会议记录与会议结论发送给缺席方人员进行离线评审。
获得缺席方离线评审意见后，修订评审结果，此次评审方可视为有效。
3.3.3模版名称：《性能测试分析报告评审报告》内容： 项目（群）组名称 会议召集时间 会议地点 与会人员、角色及部门名称 主持人员、角色及部门名称 记录人员、角色及部门名称 性能测试背景评审结果：通过\\\/不通过 性能测试需求评审结果：通过\\\/不通过 性能测试目标评审结果：通过\\\/不通过 性能测试模型评审结果：通过\\\/不通过 性能测试过程评审结果：通过\\\/不通过 性能测试单项任务数据分析评审结果：通过\\\/不通过 性能测试结论评审结果：通过\\\/不通过 性能测试缺陷评审结果：通过\\\/不通过 性能测试分析报告评审结果：通过\\\/不通过 性能测试评审会议有效性：有效\\\/无效 参与各方人员签字3.4 活动：评审结果的发布3.4.1准入标准 性能测试评审会议有效性：有效 性能测试分析报告：通过3.4.2准出标准 性能测试分析报告评审报告已经发送给所有相关各方，应包括：项目实施管理条线、业务IT管理条线、相关业务部门、数据中心、项目（群）组、测试管理部、技术测试部、业务测试部等 性能测试分析报告评审报告由技术测试部备案3.4.3模版N\\\/A3.5 活动：评审结果的跟踪3.5.1准入标准性能测试分析报告中的所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）
软件测试评审报告咋写，画完用例图后老师让写评审报告，不知道咋写。
给你一个模版XXX公司文档编号项目版本密级XXX项目共13页XXX项目系统测试报告拟制：日期：yyyy\\\/mm\\\/dd审核：日期：yyyy\\\/mm\\\/dd批准：日期：yyyy\\\/mm\\\/dd修订记录日期修订版本描述作者目 录第一章节:概述5第二章节:测试时间、地点及人员5第三章节:环境描述5第四章节:总结和评价64.1测试过程统计64.1.1 用例数统计64.1.2用例对需求的覆盖度64.1.3用例的稳定性64.1.4用例的有效性64.1.5测试执行工作量统计74.1.6测试执行的效率74.1.7版本缺陷统计74.1.8测试过程综合评价74.2被测系统质量评估74.2.2缺陷个数74.2.3缺陷严重等级评估84.2.4缺陷原因分布84.2.5测试用例的通过率84.2.6软件质量评价84.3测试总结和改进建议8第五章节: 遗留问题报告9第六章节: 附件91.1交付的测试工作产品9关键词： 摘 要： 缩略语清单： 缩略语 英文全名 中文解释第一章节:概述项目的一些概述第二章节:测试时间、地点及人员版本名称测试时间测试人员测试地点起始时间结束时间第三章节:环境描述硬件环境软件环境名称型号大小个数名称版本号 CPU操作系统 内存应用软件 硬盘数据库第四章节:总结和评价4.1测试过程统计4.1.1 用例数统计模块规模(KLOC)用例数用例数\\\/KLOC合计4.1.2用例对需求的覆盖度需求id用例数合计4.1.3用例的稳定性模块\\\/特性用例数变更用例数变更用例数\\\/用例数％合计4.1.4用例的有效性 模块特性用例数发现的缺陷数缺陷数\\\/用例数合计4.1.5测试执行工作量统计模块特性规模投入人时投入人时\\\/KLOC合计4.1.6测试执行的效率模块特性执行用例数发现缺陷数人时执行用例数\\\/人时发现缺陷数\\\/人时合计4.1.7版本缺陷统计模块特性版本1(缺陷个数)合计(缺陷个数)合计4.1.8测试过程分析（这里主要根据以上的统计数据和日常小组的工作情况，对测试过程中的异常情况，如测试延期，测试质量不高等问题进行说明，并适当分析原因，给出改进的建议。
）4.2被测系统质量评估4.2.2缺陷个数模块规模(KLOC)缺陷数缺陷数\\\/KLOC合计4.2.3缺陷严重等级评估模块特性致命严重一般提示合计合计4.2.4缺陷引入阶段分布缺陷原因致命严重一般提示合计需求设计编码合计4.2.5测试用例的通过率模块特性OK项NOK项BLOCK项NA项合计用例通过率％合计4.2.6软件质量评价测试对象的整体质量：B备注：A：质量稳定，适合大规模使用。
B：存在少数非严重问题，但有规避措施，可以局部使用。
C：基本功能可用，但严重问题较多，不能发布。
D：基本功能不可用4.3测试总结和改进建议（这里主要根据以上的数据从测试过程，软件质量，以及各个团队在该项目中的协作进行整体的总结和评价，暴露项目中出现的问题，并积极提出改进的建议）第五章节: 遗留问题报告表1 遗留问题统计表问题总数致命问题严重问题一般问题提示问题其他统计项数目百分比 遗留问题详细信息参见《XXX项目遗留问题表》第六章节: 附件交付的测试工作产品1.测试用例2.测试日报3.测试报告4.测试记录5.缺陷报告
为什么需要用例图或者活动场景图来以对现有流程进行分析和评估
面向对象的程序1.需求分析2．总体设计3．详细设计阶段4．实现阶段一、需求分析阶段：以用例图为主，到类分析图为止。
类图是源码的来源。
用例的主功能用序列图表示。
用例的状态可以用状态图标识， 注意活动图要细化到与序列图相同程度。
按照不同用户画出不同用例图。
按照不同物理位置画出部署图；按照不同类型用户对程序进行分类，得到组件图。
从序列图得到协作图，并且进行简单类分析，得到类分析图。
序列图的消息变成操作，消息中的信息变成属性。
二、总体设计 为用户所见的系统计算机层面，包括界面。
每一个用例的完整序列图，包括主功能，备用功能，异常事件，错误输入与错误处理等序列图集，每一个分支一个序列图。
用一个活动图归并全部序列图，遇到分支用菱形框，得到用例的完整功能。
细化用例图，比较每一个用例的活动图，得到相同的部分，分解成包含用例；对于复杂功能的用例，分解成多个包含用例。
对有些功能进行模块化扩展，称为扩展用例。
对用户与用例可以用继承关系。
从序列图得到协作图，进行简单类分析，特别是实体类。
增加类：界面类，事务管理类。
画出系统状态图（有活动表达式），对重要的类画出类的状态图，从中得到新的属性与操作。
对增加的类重新画序列图，活动图与协作图。
分析类图。
细化状态图。
状态图为主，应用类图是重心，画出全部用户的细化用例图，说明与其它系统的接口。
画出系统总体设计图，根据应用类图与顺序活动图。
建立UML总体模型。
三、详细设计阶段 程序的内部结构与实现方案的详细类图为主，重点是增加控制类。
从类图得到程序的结构，从顺序活动图得到程序的过程（C++）．重画有控制类的序列图、协作图、活动图。
.用协作图将操作函数化，用返回值将属性变量化.给出类状态图的活动表达式。
状态图的事件是序列图的消息，是类的操作，活动表达式是转换事件的实现，因此是类的操作的实现。
分解活动图，根据某一个操作。
与活动表达式不同。
将应用类图变成设计类图，用具体的语言，子系统的划分：类图，活动图（模块图），组件图，部署图。
将类align到组件中，将组件到部署图中。
建立程序设计的完整模型。
四、实现阶段建立并发视图。
组件图：可执行文件，配置文件。
部署图：进程，设置硬件，例如打印机软件测试 产品阶段
使用rose创建用例图的步骤有哪些
常见的测试用计方法哪些
请分别以具体的例子来说明这法在测试用例工作中的应用。
1.等价类划分 常见的软件测试面试题划分等价类:等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2.边界值分析法 边界值分析方法是对等价类划分方法的补充。
测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3.错误推测法基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结。
还有,
什么是 用例 usercase
下面逐一说明用例图中各种符号的意义： 小人： 对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢
会一下子列出很多功能
比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么
对于前台，她是不是要做一些考勤的统计
而财务是不是要根据考勤情况来调整员工的薪金
这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈： 圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子： “一般员工打卡” “一般员工查看自己的考勤情况” 大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框： 在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。
线条： 线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。
无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。
