系统测试评测方法论.doc

新中大研发评测方法论杭州新中大软件股份有限公司评测方法论文档作者：新中大研发评测部创建时间:2007年3月1日修改时间： 2007年3月1日当前版本:V1.0目录目录21.前言51.1.目的51.2.文档图标51.3.定义、首字母缩写词和缩略语51.4.参考资料62.组织结构72.1.部门人员结构72.2.项目组人员结构83.组织角色83.1.评测部经理83.2.产品测试经理103.3.评测分析师（测试组长）113.4.评测工程师113.5.系统管理员123.6.评审小组133.7.CCB134.工作流程144.1.测试工作流程144.2.测试准备154.3.测试计划164.4.测试设计174.5.测试执行184.6.计划跟踪194.7.缺陷管理204.8.测试评估214.9.软件发版流程224.9.1.重大和一般升级版流程224.9.2.补丁和过渡版流程234.9.3.发版移盘流程244.10.工作表单模板清单255.评测规范275.1.UI规范275.1.1.以用户为中心的设计原则275.1.2.可用性原则285.1.2.1.发现285.1.2.2.学习285.1.2.3.效率295.1.3.规范性原则295.1.3.1.文字295.1.3.2.对话框、控件、消息框295.1.3.3.鼠标约定305.1.3.4.表单、列表305.1.3.5.滚动条325.1.3.6.标题栏、菜单栏、工具栏、导航栏、状态栏、信息栏325.1.3.7.窗口布局335.1.4.一致性原则335.1.4.1.设计目标345.1.4.2.外观345.1.4.3.交互行为345.1.5.合理性原则345.1.5.1.布局355.1.5.2.配色355.1.5.3.导航习惯355.1.5.4.字体使用365.1.5.5.术语365.1.6.安全性原则365.1.7.美观性原则365.1.7.1.布局375.1.7.2.色彩375.1.7.3.整齐375.1.8.独特性原则375.1.9.其它规范385.1.9.1.查询385.1.9.2.打印规范385.1.9.3.升级规范395.1.9.4.并发规范395.1.9.5.性能规范405.1.9.6.权限规范405.1.9.7.备份恢复405.1.9.8.年月结405.1.9.9.外文415.1.9.10.其它416.评测标准416.1.问题分级规则426.1.1.分级方法及简要说明426.1.2.从软件规范化角度说明426.1.3.从软件功能实现角度说明426.1.4.从软件数据准确性角度说明436.1.5.从软件安全性和严密性角度说明436.2.常见问题分类说明446.2.1.规范化问题446.2.2.常规录入错误466.2.3.流程错误476.2.4.并发问题486.2.5.报表和查询出错506.2.6.打印及打印相关操作错误506.2.7.月结年结错误526.2.8.接口及数据转移中的问题536.2.9.权限及安全问题536.2.10.备份与恢复问题546.2.11.升级问题557.性能测试557.1.1.LoadRunner工具使用557.1.1.1.工具使用手册557.1.1.2.测试报告模板568.自动化测试568.1.1.QTP工具使用568.1.1.1.工具使用手册568.1.1.2.日积月累568.1.2.Robot工具使用561. 前言1.1. 目的为了整合测试资源、明确资源结构和岗位职责、规范测试工作流程，完善考核制度,提高测试效率，从而为提高研发中心整体效率，特编制新中大研发评测方法论。本文档可以作为新中大评测新员工工作流程学习的依据，可以作为新中大研发评测部门各角色日常工作的规范和指导。1.2. 文档图标1.3. 定义、首字母缩写词和缩略语l 1版是针对产品已经达到新功能测试全部通过、不存在重大流程问题的要求发布的版本，一般为“2版”发版前的25天。测试部门可以在该版本的基础上，进行回归测试。l 2版是指预发版前3-5天发布的版本，该版本提供给测试用于最后一次回归测试。l 1版即预发版，对公司内部而言，就是正式发版。这时将全部完成产品研发、市场部门准备和支持部门准备。l 2版是针对预发版试用的反馈情况进行修改的版本。通常在正式发版前15天发布给预发版用户。l 正式发版是指公司生产处可以按订单正式对外做盘。l 首发或重大升级版当公司需要开发新品或产品定位、业务流程、系统结构、技术平台、 开发工具做重大调整时，将为产品制作首发或重大升级版，同时为首发或重大升级版命名版号（事前命名）。l 一般升级版定义根据市场调研和用户反馈，需要对产品进行功能、性能优化升级时,将为产品制作一般升级版，同时为一般升级版命名版号（事前命名）。l 过渡版 当在进行首发、一般或重大升级、补丁过程中，为满足特殊用户的需要而紧急放行的未完成版本称为过渡版。 在决定制作过渡版时， 将为过渡版命名版号（即刻命名）。 当并未启动一般、重大升级或补丁，但为了满足某些特殊用户的要求，而制作的版本，其已具有向未来的一般、重大升级版或补丁版过渡的性质，因此同样也视其版本为过渡版，在确定制作此类版本时，将为其命名版号（事前命名）。l 补丁版当产品出现程序错误、设计错误和流程错误而需要修正产品时，将为产品制作补丁版，同时为补丁版命名版号（事前命名）。1.4. 参考资料 新中大软件股份有限公司产品经理上岗指南 新中大软件股份有限公司软件开发工程师上岗指南 新中大软件股份有限公司系统分析工程师上岗指南 质量记录管理 评审验证和确认 项目管理 变更管理 配置管理 软件度量 规则惯例和约定 软件测试 软件测试通过标准 软件测试大纲 软件测试基本步骤 RUP实施角色和流程准备测试篇 RUP中文教程（Rational公司） 软件UI设计规范 软件测试通过标准2. 组织结构2.1. 部门人员结构2.2. 项目组人员结构3. 组织角色3.1. 评测部经理评测部经理是评测部的业务和行政主管，该职务对评测部的工作负有直接的管理责任，根据现阶段评测部经理职务定位，评测部经理应全面贯彻、执行上级主管下达的各项任务，按时完成产品测试任务。确保公司研发战略和工作计划的推进与实现；公司研发中心各产品的测试工作组织安排；测试规范和流程的发起者；测试资源的部署、人员考核、人员培养；测试活动的协调和跟踪；对公司软件产品负有最终质量责任。职位要求： 熟悉计算机应用 有良好的职业道德、敬业精神，谦虚自律、富有朝气和乐于团队合作 有良好的自我管理和计划能力，工作独立性强、主动性强，有全局观念 沟通能力强，善于交流，有良好的团队合作意识和协调能力, 有良好的研发团队管理或部门管理经验 项目管理经验，善于协调、沟通，能听取涉众意见，并使各方面达成共识 能坚持正确的观点，有独立的思考能力，不容易受权威影响 阅读、学习和理解能力强，能够快速的掌握软件应用（包括数据库、测试工具和其他应用软件） 语言表达、组织和书写能力强，能够清晰明了的编写测试指南等技术文档 工作责任心强、细心、耐心 必须具有良好的、综合的业务领域知识。善于学习、积极进取并不断总结。工作职责：（业务职责） 根据公司产品研发战略、年度研发规划和研发中心计划，统一部署组织测试工作，编制部门月、周的产品测试计划 根据各项目规模、项目性质、所处的开发阶段、工作量、资源配置以及评测员的能力、专长、领域熟悉程度、测试经验、发展方向，组织测试项目小组，进行动态配置与调整 测试部门规范、流程的规划和定义者，负责各种测试文档的定义、模版设计和维护，指导并检查、审核测试计划的编写、测试方案的设计 负责贯彻、执行、维护、发展公司质量保证体系制定的有关规范和标准 负责审核测试报告、测试评估摘要 指导并协助测试组长进行项目管理，协调与研发中心各部门业务关系，协助监控产品版本管理 承担组织测试自动化研究、并应用于测试工作的任务 负责测试部门人员的培养和能力的考核 监控各项目组的测试活动 指导其他测试人员协调编制及整理测试数据 负责测试管理平台的设计、开发，或第三方应用的实施 负责评测部信息化水平的提高 负责总结测试方法和测试管理方法，并编写工作指南文件，供员工培训、考核使用。 负责建立并维护测试知识库，保证测试经验的延续性 负责组织公司研发、市场、服务各部门人员的培训 负责测试部门的人员招聘（行政职责） 定义评测员的职责、任务。 编制和维护各岗位工作流程，明确流程的目的、适用对象、工作责任、工作程序和工作成果 编制和维护各岗位详细的职位说明和上岗指南，明确各职位具体操作的步骤和工作标准 建立和规范部门的管理制度、工作制度，形成有序的部门运转机制 考察、聘任合格的岗位人选，建立一只符合素质要求工作团队 经常性的与员工开展交流、沟通，达成理解、共识，保持团队积极旺盛的工作热情 创造敬业氛围、加强团队合作，提升职业素质，建立勤奋、高效、严谨、耐心的部门作风 建立和完善对员工的绩效考核，做好对员工的综合评估，协助员工实现职业生涯目标 建立和完善培训制度，促进职业素质、工作能力、业务知识的提高 建立新员工岗位业务培训制度，保证新员工到岗后可获得完整的岗位任职资料并迅速进入角色 做好部门年度规划和月、周计划，及时检查计划完成情况，总结经验、发现问题，推动工作开展 建立部门例会制度，及时总结、布置工作，鼓励优秀员工，纠正缺点不足，制定努力目标 侧重培养骨干员工，提高项目管理能力和专业技术能力，形成科学的人力资源构架3.2. 产品测试经理包括平台评测经理，根据现阶段产品评测经理职务定位，产品评测经理是公司各产品测试工作的负责人，负责整个产品计划进度的控制和质量的把握，负责各产品的测试规划和测试方案确定；协助测试组长开展好项目组的测试工作，协调产品之间的测试工作和任务安排；并负责测试分析人员和测试组长测试技能的培养；测试方法的和测试技术技巧的完善，测试技术、测试工具的研究和使用推广,评测工具包的补充和完善。职位要求： 有较丰富的测试经验或软件开发维护经验，能够独立完成测试方案设计 沟通能力强，善于交流，有良好的团队合作意识和协调能力 能坚持正确的观点，有独立的思考能力，不容易受权威影响 有良好的敬业精神，有项目管理的经验 阅读、学习和理解能力强，能够快速的掌握软件应用（包括数据库、测试工具和其他应用软件） 语言表达、组织和书写能力强，能够清晰明了的编写测试指南等技术文档工作职责： 负责规范产品的测试过程，协助改进测试过程规范 负责规划测试组的发展，并提出可行方案 负责发现测试组长人才，并进行培养 规划产品的测试用例库组建，并承担重要功能的用例实现 规划产品自动化进程，维护自动化测试，强化工具在测试组中的推广 组织测试数据、大数据的编制，形成自有数据 形成新员工产品培训的内容组织 在需要时组织产品间的联调测试 与产品相关的各部门及人员进行沟通，及时地了解产品信息，并向部门内传达 跟踪产品测试过程，了解测试过程中存在的问题，并能提出方案加以解决 负责收集用户信息、测试数据等信息，分析用户及数据情况，发现集中使用点，以便于更好地进行测试的组织与安排 收集用户发现缺陷，并每月组织一次产品讨论，分析问题存在的原因，并提供相应解决方案 每月报告产品测试情况，包括项目进展情况，严重影响项目进展的问题，以上任务规划及落实情况，以及月度工作计划 建立测试模型,评估测试有效性 组织测试数据、测试用例、测试指南编制 负有团队组织和协助组织的责任，制定计划或辅助制定计划，并与测试组长协同组织测试工作的开展，组织或协助组织测试评估的责任3.3. 评测分析师（测试组长）根据现阶段评测分析师职务定位，评测分析师是公司各产品各项目组测试资源的核心，负责各产品各项目的测试用例、关键测试点清单、性能测试点清单和测试指南的编写，性能测试、压力测试脚本的编写和使用的推广及指导者，并对测试结果进行分析和测试报告的编写，是项目组重要、复杂、涉及面广的需求验证确认者，是评测工程师业务和测试技术方面的指导者；并负责评测工程师测试技能的培养，测试技术的使用和测试工作的使用推广,评测工具包的补充和完善。职位要求： 熟悉计算机网络及部门级或企业级软件应用 熟悉企业财务、物流、或其他经营活动的流程 有软件测试经验、或者有企业信息管理系统应用经验 善于交流，有良好的团队合作意识和协调能力 能坚持正确的观点，有独立的思考能力，不容易受权威影响工作职责： 参与项目前期工作，如需求分析、详细设计的评审，在评审中发现问题，判断各需求的可测性，对于不可测问题要求其他方面的技术支持 协助测试负责人制定测试计划，并规划测试过程 参与项目前期工作，如需求分析、详细设计的评审，在评审中发现问题，就其可行性进行判断并考虑此类文档的向测试用例的转化能力，是否能够达到可转化目标 依据测试计划分配到的任务执行测试，以及完成测试用例的分析及编写 独立完成模块的测试分析任务 能够与测试人员很好地沟通，完成测试用例的测试执行 维护并运行自动化测试脚本，并跟踪其执行结果 执行测试，维护测试缺陷并跟踪缺陷修改 协助测试负责人培养测试团队 与开发人员就测试结果进行沟通 向测试负责人反馈测试情况，协助测试负责人进行测试评估 负有精化自动化测试责任 （a、自动化工件的全面 b、内容的详实 c、方法的灵活性） 负有有效编制数据的责任 （a、数据反映功能 b、数据针对性 c、数据全面性 d、数据量） 负有评估测试过程的责任 （a、评估的可靠性 b、过程清晰 c、风险明了 d、新观点）3.4. 评测工程师根据现阶段评测员的功能定位，评测员要在软件开发过程中通过对可执行代码输入、输出的验证作应用性检查，检查程序功能是否按照需求规格说明书的规定正常使用，并能根据测试用例的描述，适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性；能够根据评测分析师编写的测试用例，关键测试点清单，性能测试点清单和测试脚本进行功能的验证、集成测试、回归测试和性能测试，并对工件提出合理的改进措施；评测员是公司软件产品功能和性能的检查者，是“模拟”的用户。职位要求： 熟悉计算机应用 具备较好的语言组织能力 对财务、物流、有所了解 具备良好的学习能力 工作责任心强、细致耐心，吃苦耐劳、有坚强的毅力，能够保持长时间注意力集中 善于交流，有良好的团队合作意识和协调能力 能坚持正确的观点，有独立的思考能力，不容易受权威影响工作职责： 协助测试负责人完成测试计划的制定 参与项目前期工作，如需求分析、详细设计的评审，在评审中发现问题 依据测试计划分配到的任务执行测试 完善已有测试用例，并协助制定测试用例 根据测试用例进行测试，并维护测试用例的使用情况 维护并运行自动化测试脚本，并跟踪其执行结果 执行测试，维护测试缺陷并跟踪缺陷修改 与开发人员就测试结果进行沟通 向测试负责人反馈测试情况，协助测试负责人进行测试评估 负有完成测试计划的责任（a、任务执行的准确性 b、测试记录的规范性 c、遵守计划时间） 负有执行测试用例的责任（a、全面理解用例b、全面执行用例 c、及时补充用例） 负有维护自动化测试工件的责任（a、保证测试脚本安全 b、保证测试脚本的可用性） 负有维护可执行代码的责任（a、保证测试对象安全 b、保证文档资料安全） 负有维护软硬件系统安全的责任（a、防止病毒 ）3.5. 系统管理员非评测部门角色，对整个研发部门网络搭建和安全的管理；各种用户帐户，IP地址的分配；计算机领域知识的推广和普及；以及日常问题的诊断和解决。职位要求： 熟悉计算机操作系统的知识 熟悉计算机网络知识 熟悉计算机安全方面的知识和计算机病毒方面的知识 熟悉计算机管理和杀毒工具的应用工作职责： 计算机操作系统、网络知识、安全知识、病毒知识和管理工具和杀毒工具的培训 新员工IP地址、QQ号、CQ用户、RD域用、Lotus帐户的分配 研发部门软件和硬件环境的搭建，安全策略的方案制定 定时下载病毒库，并组织研发部门的杀毒工作 员工机器软件问题的解决，硬件问题的诊断3.6. 评审小组非评测部门角色，没有专门的团队，在软件开发过程中在涉及到文档评审时临时组建，包括研发流程中的多种角色，主要负责对文档编写的各方面提出修改和改进的意见。职位要求： 熟悉计算机应用 具备较好的语言组织能力，善于交流 对财务、物流、有所了解，在某些业务或技术方面的专家 能坚持正确的观点，有独立的思考能力，不容易受权威影响工作职责： 对开发和测试的计划和进度的合理性、完整性进行评审和提出问题 对开发的业务、需求分析文档和测试设计文档正确性和合理性进行评审和提出问题人员组织： 业务专家、技术专家 项目经理、产品经理、业务分析师、系统分析员、测试组长，评测分析师3.7. CCB非评测部门角色，没有专门的团队，在软件开发过程中在涉及到文档评审时临时组建，变更控制委员会（change control board），作用是提供集中的控制机制，以确保妥当地考虑、批准和协调每个变更请求。人员组织： 业务专家、技术专家 项目经理、产品经理、业务分析师、系统分析员、测试组长，相关开发和测试人员职位要求： 熟悉计算机应用 具备较好的语言组织能力，善于交流 对财务、物流、有所了解，在某些业务或技术方面的专家 能坚持正确的观点，有独立的思考能力，不容易受权威影响工作职责： 对有争议的测试缺陷进行评审和裁决 对有项目进行中需求的变更进行评审和裁决4. 工作流程4.1. 测试工作流程4.2. 测试准备4.3. 测试计划4.4. 测试设计4.5. 测试执行4.6. 计划跟踪4.7. 缺陷管理4.8. 测试评估4.9. 软件发版流程4.9.1. 重大和一般升级版流程4.9.2. 补丁和过渡版流程4.9.3. 发版移盘流程第 57 页 共 57 页-4.10. 工作表单模板清单重大和一般升级版补丁和过渡版1发版2发版1发版2发版正式发版正式发版发版过程发版移盘通知书*发版移盘审批表*需求测试关键点清单*集成测试方案*集成环境表*测试未改问题记录表*发版移盘通知书*发版移盘审批表*集成环境表*测试未改问题记录表*发版测试检查点列表*大产品测试任务分解表*发版移盘通知书*发版移盘审批表*集成环境表*测试未改问题记录表*发版测试检查点列表*大产品测试任务分解表*发版移盘通知书*发版移盘审批表*集成环境表*测试未改问题记录表*发版测试检查点列表*大产品测试任务分解表*发版移盘通知书*发版移盘审批表*集成环境表*测试未改问题记录表*发版测试检查点列表*需求测试关键点清单*测试准备版本及环境清单-测试计划测试计划测试进度需求测试关键点清单评审纪要测试方案说明书大产品测试任务分解表*-测试计划测试进度需求测试关键点清单评审纪要测试设计测试用例(Word)测试用例(Excel)关键测试点清单性能测试点清单评审纪要-测试用例(Word)测试用例(Excel)关键测试点清单性能测试点清单评审纪要测试计划参考发版过程计划跟踪任务和缺陷跟踪清单度量指标缺陷管理ClearQuest库维护测试评估-测试评估摘要-注：加*的文档要签字确认5. 评测规范5.1. UI规范用户界面实质是一种交互方式及视觉效果。总的基本原则是综合人体科学、软件设计、美学等相关知识，把人机环境系统作为一个统一的整体考虑，设计恰当的人机交互界面，使人机环境系统相协调，获得系统最高综合效能，主要有一下8大原则：l 以用户为中心的设计原则l 可用性原则l 规范性原则l 一致性原则l 合理性原则l 安全性原则l 美观性原则l 独特性原则5.1.1. 以用户为中心的设计原则用户界面是软件服务于用户的窗口，只有以用户为中心而设计出来的用户界面是符合用户需求的。以用户为中心的设计根据需求的不同，包含的内容不单单是在界面中按照一组原则，对按钮和菜单布置等进行管理。原则在本质上是通用的，必须应用到各种各样不同的情况之中，因此它不能总是针对正在设计的特定的应用程序制订最佳的行动方案。遵守一组合理编写的原则有助于设计出风格一致的界面，但是不能保证它一定是最可用的，除非通过真正的用户对它进行了测试。因此，以用户为中心的设计原则是其它原则的根本，在这个原则的基础上实施其它原则才能设计出出色的用户界面。以用户为中心的设计有以下几个要点：l 及早以用户为中心：在项目的开始阶段需求分析人员及设计人员应当致力于了解用户的需要。 l 中期的用户参与：当设计人员按照了解的需求设计出软件原型时就应该邀请用户来体验设计，检查一下和最初的要求是否相符，也可以得到在最初并没想到需求，防止在软件开发完成后才暴露出问题。 l 迭代式设计：设计人员和开发人员应当在整个软件设计过程中根据用户体验的反馈反复对设计进行修改。 l 明白自己不是用户：设计人员应当认识到他们自己不是普通的用户。与一般的用户相比，他们对正在开发的系统有着更深入的了解。因此，对大多数用户而言不明确或造成混淆的界面，可能对那些从事项目设计工作的人员来说是非常清晰的。某些软件设计人员可以在一定程度上代表普通用户，但他们绝对不能代替实际使用产品的真正用户。5.1.2. 可用性原则优秀的图形用户界面同时也是非常人性化的界面，结构清晰明了，便于操作，易于学习。在设计上要尽量减少冗余的操作步骤，特别是对一些用户可能频繁操作的功能，更要精心设计；按钮名称应该易懂，用词准确，摒弃模棱两可的字眼，要与同一界面上的其他按钮易于区分，最好能望文知意；实时为用户提供操作反馈，引导用户顺利便捷的完成操作；理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作；提供使用指南或帮助，放在醒目的地方，并使用通俗易懂，浅显的语言；尽量降低对操作者的知识能力水平的要求，设计傻瓜式操作，使软件具有更强的亲和力。可用性包含很多方面，但通常这一术语特指发现、学习和效率这三种属性。l 发现：表示用户针对某种特定的需要去寻找并找到产品某一功能所用的时间，以及在整个过程中用户所犯错误多少的指标。l 学习：表示用户弄清楚如何运用所发现的功能来完成现有任务过程的长短，以及在学习该功能期间用户所犯错误多少的指标。l 效率：表示用户“掌握”了某项功能，不再需要进一步学习即可使用，及有经验的用户使用该功能时执行必要步骤所需时间的指标。可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂，导致用户基本上每次使用时都要重新学习；对于这些功能，通常开发了使用向导，在整个使用过程中对用户予以指导。5.1.2.1. 发现 对于要求用户输入的内容，要明确。如要求用户定义某种比例，要明确是要求输入百分比（20%）还是小数的比例（0.20）。 菜单名称、打开窗口的标题栏、权限名称等命名一致。 常用的功能应在工具条中显示，而不是采取下拉菜单的方式。5.1.2.2. 学习 任务栏自动隐藏与不隐藏情况下的显示，整体的界面显示是否正确。 功能的布局和数据输入区域归类合理，条理清晰。 产品中使用的图标应该保持一致，“相同功能使用统一图标”，“同一图标尽量表示一种功能”，“一个界面中不能使用重复的图标”，如：一个图标在一个产品中即表示“导出”又表示“传出”功能。 产品中使用的快捷键应该保持一致，“相同的功能用同一快捷键”，“同一快捷键尽量支持一种功能”，“一个界面中不能重复出现同一快捷键”，如：“i”即表示插入又表示信息。5.1.2.3. 效率 对于用户的自定义项，要求保存在数据库，如打印的自定义套打设置。防止客户端重新安装后，需要重新定义。 一个功能点完成所要点击按钮次数应该尽量的少，如：3次以内。 支持全键盘操作，如：数据录入可以按“回车”到底。5.1.3. 规范性原则我们的产品都是基Windows操作系统开发的应用软件，而Windows提供了一套标准的控件，经常使用计算机的用户可能已十分了解这些标准控件的用途。例如一个多选框在用户用鼠标点击后会改变其状态，当按动滚动条上的箭头时，屏幕将发生滚动；当点击单选框时一般系统不会弹出一个对话框，如果不做诸如点击按钮或选择菜单等类似的操作，系统也不会进入到一个什么新的操作进程等等。用户可能已经对常见操作建立起一些基本概念，当他开始使用一个从未用过的应用软件时，如果觉得该软件与熟悉的Windows操作系统中的某些应用相似就不会觉得束手无策。而这种相似的程度越高用户就越容易掌握对该软件的操作，也就是软件的用户界面设计得越成功。而如何获得这种相似性呢？我们需要做的就是遵循Microsoft（1995）指定的用户界面设计规范及Microsoft Windows User Experience中设计指导。因此每一个程序员都应当意识到规范性原则在软件UI设计中有多么的重要。如果产品是基Windows操作系统开发的应用软件，那么Windows的用户界面设计规范遵循的越多，用户就会感到越方便，尽管他们并不一定能意识到方便的原因所在。可以说：界面遵循规范化的程度越高，则易用性相应的就越好。5.1.3.1. 文字 软件中涉及到的所有文本字体，一律采用宋体9号 颜色：颜色不能太多，一般已白色、灰色、黑色和蓝色为主色，必要地方可以用红色等，宗旨一个界面中不易太多颜色 不能修改的文本使用黑色，底色使用灰色 可以修改的文本使用蓝色，底色使用白色 根据业务情况对不同单据进行着重提示的可以使用红色等颜色标注 特殊：报表和查询列表，虽然不能修改，但是统一用白底蓝字。5.1.3.2. 对话框、控件、消息框 窗口：非弹出式窗口打开时默认全屏显示，弹出式窗口打开时居中显示 控件：放置须整齐、简洁、大方，大小适中、排列整齐，不得随意发挥 显示： 不同环境下要显示美观 不同颜色下的显示，包括真彩32位、增强16色、256色等 不同像素下的显示，800*600、1024*768，各种显示是否正确 不同的操作系统，如Windows XP/2000/ 2003，vista的不同风格下，显示都要美观 不同的语言切换下，包括操作系统不同语言和软件的多国语言的切换，界面显示正常美观5.1.3.3. 鼠标约定 一般正常使用的鼠标形状，和操作系统默认的正常选择鼠标一致，一般是一个箭头 记录多选和连接选择是鼠标形状，和操作系统默认的连接选择鼠标一致，一般是手型 系统忙的鼠标形状，和操作系统默认的后台运行鼠标一致，一般是一个箭头加沙漏5.1.3.4. 表单、列表 表单的界面规范对话框、控件、消息框规范 数据输入区规范： 表头文字居中；列表中，文本类左对齐，数字类右对齐，日期居中 可输入项、不可输入项用不同的字体颜色显示。必输项红字显示 表单的验证规范： 文本类型的测试 包括字母（大小写）、中文、数字、特殊字符（包括&-_$！#￥%*（）；：“”|+/等）。 前后空格的测试，如基础数据中的各种编码、名称，输入时，在前、后加入空格，看能否正常保存，保存时，是否会将空格自动删除。如果不删除，在后面的引用中会不会有问题。 极限值测试，在各项可输入项中，录入允许输入的最大值，看能否正常保存。不仅要测试保存，还要测试保存后的后续操作，如保存后，进行查看、查询、修改、删除、冲红、打印、被其他单据引用、报表查询等所有相关的操作，看能否正常操作。如采购订单的表头备注最长允许输入255个字符，则测试时，输入最长字符，看是否要求的255个；更多的字符能否输入，输入后能否保存。之后在单据查看、审核、审批等界面中，能否全部显示备注信息（可以是鼠标指向时跳出文本注释）；修改时，能否方便地修改备注；打印时，要求能打印全部备注信息；报表、列表等查询条件中，相关的备注栏要求能输入255个字符，能被默认保存、引用；能正确检索出相关的单据；被其他单据引用时，帮助信息中能显示所有的备注信息。 日期的测试：日期帮助控件统一，日期格式一般采用“年.月.日”（2007.07.01） 数字类型的测试： 默认的0，如默认显示为“0.00”，用户输入“1”后，显示值不能为“10.00”、“0.01”，正确的应该是“1.00”。 要考虑不同的小数位数，如用户定义小数位数为4位，测试时，要注意各种单据、报表中相关字段的小数位数显示不能是2位或6位。要测试小数为零及全部值的情况，如“4.0000”，显示不应该是“4”、“4.00”、“4.000000”，“4.5555”显示不应该是“4.56”、“4.555500”。不只是保存后显示，在修改、变更、审核、审批、打印、被其他单据引用、报表查询等后续的操作中，都要注意数字的正确显示。 数字的极限值，包括单张单据的最大值和所有单据的最大值。如某单据中，单行明细金额允许录入的最大值可以是“999,999,999.99”，要测试输入、保存、显示、修改、冲红、作废、删除、报表查询等不同操作；还要测试一张单据多行明细时的小计、合计，多张单据都是最大值时，在月结、过账等操作时，会否能正常通过。 关联数值的正确性，如进销存单据中，数量相关的有辅助数量、非标数量，单据中输入数量值后，还要测试相关的辅助数量、非标数量是否正确。 如果有明细行，要测试小计、合计的测试。 不能有“0.00”显示。 对于百分数的测试，要注意默认值的合理性，如折扣的默认值，是“100%”还是“0%”。测试“100%”、“0%”两者的不同地处理。 单据编号的测试：极限值的测试；单据号是否有唯一性要求，包括单据号是否支持手工录入，是否支持字母（包括大小写字母，如是否允许A001，a001同时存在）。 保存时，各项提示的正确性。可以这样测试，在新增单据时，不输入任何值，直接保存，跳出提示后，进行相应的操作（如提示供应商必须录入，则输入供应商），直到单据保存成功。 有明细行的单据，应该有默认的空白行，可以增加、删除行，保存时，将多余的空白行删除；要测试多于一屏的明细行显示，应该有上下、左右的移动块；明细行为空、多于默认行的情况下，保存是否正确；明细行中有小计、合计的，测试汇总行是否正确，特别注意小数点后的位数。 表单的操作规范： 不可输入项上，光标不能显示，除了不能输入，还要测试Delete、粘贴等操作，也不能改变值。 单据复制：复制时，要注意编号、日期、汇率等特殊信息处理是否正确。如编码不允许重复时，应该根据当前最大编码自动加1；日期应该默认到当前会计期等。 单据修改、变更的测试：对于所有可修改、变更项都要进行测试，包括明细行的增加、删除；在单据新增时的必输项，修改时，测试能否不输入；在生成单据时，对于不可修改、变更的项要考虑不同的输入项。如采购订单变更时，折扣是不允许变更的，在录入采购订单时，对于折扣项，要输入“100%”、“0%”和“55%”等不同折扣，在变更时、变更后，查看折扣项是否正确。 删除、作废的测试：删除、作废时，要给出确认提示；列表中，单据删除后，高亮条要重新定位，方便用户操作；关联性单据的删除、作废，要注意是否已经被其他单据引用；要测试仅有一张单据时，删除是否正确；删除后，某些唯一性的数据是否能再次使用，如单据编号、序列号等。 限额控制的测试：保存时，对限超出限额控制的提示是否明确；复制、修改、变更、删除、作废、冲红时，对有限额的字段进行测试。如采购入库通知单的限额数量是100，单张、多张单据保存时的控制是正确的，还要测试修改时，是否能超出限额数量。对于区分时间段、部门、人员等的限额控制，要测试不同的设置下，限额是否区分进行计算。例如，库存的限额领料设置为分部门限额，A部门限额领料10，现在有单据001，A部门领料6；单据002，B部门领料7，要测试修改单据002，B部门改为A部门能否保存。 单据的变动，在列表中有相应值的，都应该即时刷新。 帮助的规范：这里的帮助是指单据录入时，提供的部门、人员等辅助帮助。一般需要引用基础数据或是其他单据的，都应该提供帮助，方便用户操作。 启用下拉框或弹出窗口，根据帮助的记录数，记录数比较少如20以下可以只采用下拉框，不用提供弹出窗口；记录数在20以上的要求提供弹出窗口。 提供下拉框帮助或是弹出窗口帮助的；弹出窗口帮助的要有相应的按钮显示，并可以通过双击显示。 下拉框的测试：对于可选项不多的单个选项，可以提供下拉框帮助。下拉框大小适中，信息显示完整，注意只有一个选项及有多个选项的不同情况下，下拉框的大小是否合适；有代码、名称的，要同时显示代码、名称；可选项较多的，注意有没有上下移动条。 弹出的帮助窗口，大小适中，位置居中；提供的信息合理；单选的，支持双击选中；可多选的，要支持Ctrl、Shift键，可提供全选、全不选按钮；提供检索、定位按钮。 输入时，除了通过帮助选择，还应该支持代码、名称的直接录入。输入不完整、错误的代码、名称时，应该给用户相应的提示，并可让用户决定是否要提供帮助。5.1.3.5. 滚动条 能有方法处理，尽量采用垂直滚动条而不要采用水平滚动条 尽量不要把这个窗口作为可滚动，增加滚动条，尽量一个窗口显示要的信息 在窗口的数据区域，能一屏显示数据的就不要使用滚动条，滚动条也要做到一屏显示不了时自动出现。5.1.3.6. 标题栏、菜单栏、工具栏、导航栏、状态栏、信息栏 “简单、直观、一致、有效”是菜单设计的原则 菜单的深度不应超过三级，即限于主菜单、一级菜单、二级菜单 菜单项选中后还有二级菜单的，在该菜单项右边加 菜单项包括的内容不单单是菜单标题所描述的时候，在该菜单标题的末尾添加“”（省略号），以视区别 主菜单标题的宽度要接近，字数尽量不要多于四个，每个菜单的字数能相同最好 主菜单有两种方式：传统菜单和树型菜单。 传统菜单：系统功能菜单放在最左边，依次向右排列模块功能菜单 树型菜单：系统功能菜单放在最上边，依次向下排列模块功能菜单 传统菜单每项要有快捷方式： 主菜单的快捷键以ALT+字母；子菜单的快捷键以ALT+1,2,3,9,a,b,c,dx,y,z如：主菜单项，F.系统功能；子菜单项，1.存入2.定位3.排序i.退出 在系统功能菜单下显示已打开的窗口。 弹出式菜单方式：快捷键以ALT+1,2,3,9,a 工具栏原则：符合用户操作习惯、统一界面、尽量保持即有界面风格窗口类型组号左边右边列表窗口1增加、修改、删除、复制定制2审核、取消审核、冲红、作废、执行、终止、关闭、记帐、取消记帐、凭证打印、帮助3导入、导出|查询、排序、定位、刷新退出编辑窗口1首、前、后、尾定制2增行、删行打印、帮助3存入退出报表窗口1查询、排序、定位定制2刷新打印、帮助3退出组号：在工具条上组与组之间用分割线分开 工具栏图标的含义与功能要表示一致性 工具栏上不易太多按钮，如果按钮摆放超出屏幕显示，可以采用下列方法： 多个按钮功能合并到一个按钮中，并采用弹出式菜单来激活功能 工具条上可以增加前后滚动的按钮来显示后面的按钮5.1.3.7. 窗口布局 非特殊窗口，窗口本身应该有标题栏，对该窗口功能的简单描述 非模式窗口的最上是工具条，工具条中展示窗口提供的各个功能 如果有关键信息的显示或多选按钮可以布局在工具条下方，否者工具下方就是数据区 对于数据区，可以是一个数据区，也可以是多个 两个数据区：最好是上下布局，除非不得已，采用左右方式 三个数据区：一般采用左边一个，右边上下两个 四个数据区：一般采用左二右二的布局，左上右上、左下右下水平对齐 模式窗口不采用工具条方式，而是在窗口中直接布局按钮 按钮一律要不采用放在窗口底部或窗口右边 按钮在窗口底部，应布局在右下方；按钮在窗口右边，应布局在右上方5.1.4. 一致性原则由于我们的软件具有自己的特性，Windows用户界面设计规范不可能满足我们所有的要求，因此必定有很多的内容需要我们自己设计。由于设计用户界面的工作是不同的人一起完成的，就有可能出现不一致的界面风格。如果界面风格经常变化，不保持统一，无疑更增加了用户的学习难度，也许会导致用户的厌烦。用户会为了捉摸不清设计师的意图而大光其火。比如，有些设计师考虑到用户方便，在页面上放置了后退的按钮，但是要是不注意保持一致的话，用户也许会糊涂后退、回首页、BACK、上一页这些按钮究竟有什么区别？一致性方面的任何不和谐将使用户迷惑，并且立刻削弱产品的整体功能。因此在界面设计中应该保持界面的一致性。一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、标签风格、颜色、弹出窗口的位置、按钮的窗口的位置、术语、提示用词、显示错误信息等方面确保一致。同时要保持交互方式的一致，如在软件中一个列表的项目上双击后能够弹出对话框，那么应该在任何列表中双击都能弹出对话框。一致的界面风格包括以下三方面的内容：l 设计目标一致：如果追求操作简单，那么就要贯彻始终。l 外观一致：如果追求视觉效果华丽，那么就尽量避免出现朴素的效果。l 行为一致：交互对象在相同的交互方法后产生的交互事件保持一致。5.1.4.1. 设计目标5.1.4.2. 外观 颜色使用注重朴素原则，颜色不易使用太多，尽量和公司颜色体系一致。 产品中使用的图标应该保持一致，“相同功能使用统一图标”，“同一图标尽量表示一种功能”，“一个界面中不能使用重复的图标”，如：一个图标在一个产品中即表示“导出”又表示“传出”功能。 产品中使用的快捷键应该保持一致，“相同的功能用同一快捷键”，“同一快捷键尽量支持一种功能”，“一个界面中不能重复出现同一快捷键”，如：“i”即表示插入又表示信息。5.1.4.3. 交互行为 对于用户在产品使用过程中，在两个不同的入口，中间处理的功能相同，应采用相同的交互界面和相同的处理步骤。5.1.5. 合理性原则软件UI设计一定要合情合理，只有合理的设计用户使用起来才会感觉到舒心。主要表现在以下几个方面：l 一个合理的布局：保证界面的协调性，控件摆放位置要合理、均衡，不要给人们带来“前重后轻、左宽右窄”的不良感觉；控件摆放突出重点，一定要将重要的控件摆放在明显位置，这样才能突出重点，而且一定要符合人们的日常使用习惯；不要界面设计既不能过于拥挤也不能过于松散的，实验结果表明空白的界面比例不能超过40，相反的，内容占据的比例不应超过80；有效分组界面上的内容，逻辑上相关的项目应该在界面上被组合在一起，来表明他们的相关性，相反地没有任何相关的项目应该分离开来，你可以在两个组合之间使用空白来或者在组合周围加框的方式来完成同样的工作。l 使用适当的配色：同一个界面中的颜色数量不能太多，这样会使软件界面看起来花里胡哨用户也很难静下心来使用，建议用柔和的色调，不要用太刺眼的颜色（目前，Windows应用程序基本都是这么做的）；在软件中用色一致，使得你的软件具有统一的色觉和感觉；还要注意颜色的对比度规则，为了使界面具有可读性最好办法是采用对比度规则，在浅色的背景上用深色的文字，以及在深色的背景上用浅色的文字。在白色背景上看蓝色文字很轻松，但在红色背景上看蓝色文字却很费神。问题在于蓝色和红色之间的对比度不够以便于阅读，相反地，蓝色和白色之间对比却很鲜明。l 符合习惯的导航：在同一界面内人们习惯从左到右从上到下的阅读模式，界面设计也应该从左到右从上到下的组织；不同界面之间的导航