软件产品评审流程要点 1. 立项 l 市场需要（软件为用户解决什么样的问题）
l 国家政策（国家是否有相关政策提出，是否有利于该软件日后的发展）
l 产品定位（软件在行业中的定位）
l 产品功能策划 l 市场上类似产品的功能、特点与优势 l 产品的卖点与优势 l 开发该软件对公司的（战略）意义 l 性能（效率、响应时间、资源占用、稳定性）
l 重要等级（是否直接关系人员生命安全）
l 工程实施复杂度和软件维护复杂度 l 开发的（技术）风险是什么 l 市场或公司允许的研发周期 l 预计成本（人力物力）
l （可验证性）
2. 设计方案 概要设计概要设计与详细设计的区别 概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。
概要设计阶段通常得到软件结构图。
详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等。
：
提交概要设计文档，内容包括如下方面：
l 总体设计（需求规定、运行环境、基本设计概念和处理流程、结构、功能需求与程序的关系、人工处理过程、尚未解决的问题）
l 接口设计（用户接口、外部接口、内部接口）
l 运行设计（运行模块组合、运行控制、运行时间）
l 系统论据结构设计（逻辑结构设计要点、物理结构设计要点、数据结构与程序的关系）
l 系统出错处理设计（出错信息、补救措施、系统维护设计）
详细设计：
提交详细设计文档，内容包括如下方面：
l 术语定义及说明 l 详细设计方法和工具 l 系统详细需求分析（详细需要分析、接口需求分析）
l 总体方案确认（系统总体结构确认、系统详细界面划分（应用系统与支撑系统的详细界面划分、系统内部详细界面划分））
l 系统详细设计（系统结构设计及子系统划分、系统功能模块详细设计、系统界面详细设计（外部、内部以及用户界面设计））
l 数据库系统设计（设计要求、信息模型设计、数据库设计（设计依据、数据库选型、数据库种类及特点、数据库逻辑结构、物理结构设计、数据库安全、数据字典））
l 网络通信系统设计（设计要求、网络结构确认、网络布局设计、网络接口设计）
l 信息编码设计（代码结构设计、代码编制）
l 维护设计（系统的可靠性和安全性、系统及用户维护设计、系统扩充、错误处理（出错类别、出错处理））、系统调整及再次开发问题 l 系统配置（配置原则、硬件配置、软件配置）
l 关键技术（关键技术的提出、关键技术的一般说明、关键技术的实现方案）
l 组织机构及人员配置 l 投资预算概算及资金规划 l 实施计划（限制、实施内容和进度安排、实施条件和措施、系统测试计划（测试策略、测试方案、预期的测试结果、测试进度计划））、验收标准 3. 技术选型 l 版权 l 是否有应用先例，是否为常用技术 l 类似的技术是否在公司内部使用过 l 使用此技术的额外风险是什么（有没有失败的案例，原因是什么，如何避免）
l 此技术是否是过时的技术（技术没有发展前景，或者提供者将来不再提供技术升级等）
l 是否为成熟的技术（应用范围广，大公司或者标准组织提供）
l 能有选择的，尽量不要用定制的技术（其它类似产品或者项目不能复用的技术尽量少用）
4. 界面评审 指导原则：
l 关注用户及其任务，而不是技术 l 首先考虑功能，然后才是表示 l 从用户的视角看问题，使用用户的词汇进行描述，不必向用户暴露实现细节 l 使常用的用户任务简单化，不要让用户解决额外的问题 l 促进学习，保持一致性，引导用户的使用习惯 l 保持显示惯性，传递信息，而不仅仅是数据 l 设计应满足响应需求 颜色：
l 统一色调：采用标准Windows的基本色调，做到与操作系统统一，读取系统标准色表。
l 整个界面色彩尽量少的使用类别不同的颜色。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色 l 同时色调也具有一定的含义，在整个系统中应保持色调含义的一致性，避免同一中颜色在不同的画面中表示不同的意义。
资源：
l 图标资源也需要遵循统一的规则，因为不同的图标代表不同的意义。例如：我们用图标来表示保存，因此我们在整个系统中只要涉及到保存的话，都应该使用同一个图标，不论是用在工具栏上还是在菜单上，还是在按钮上。
l 图标、图像应该很清晰的表达出意思，遵循常用标准，或者用户机器容易联想到的物件，绝对不允许画出莫名其妙的图案。
l 鼠标光标样式统一，使用系统标准。注意：本系统中不采用窗体做进度条，对于按钮后，鼠标变成沙漏形状，执行完成后，鼠标变回。
字体：
l 系统中中文一律采用标准字体“宋体”，英文一律采用标准Microsoft Sans Serif ，除登录界面和图标中的特殊字体用图片实现，原则上不考虑特殊字体（隶书、草书等，特殊情况可以用图片取代），保证每个用户使用起来显示都很正常。
l 字体大小统一规定，MSS字体8磅，字体为10磅，字体颜色一般采用系统默认颜色。
l 所有控件尽量使用大小统一的字体属性，除了特殊提示信息、加强显示等例外情况。
文字表达：
l 使用统一的语言描述，提到同一个概念时，用相同的术语描述。例如一个关闭功能按钮，统一描述为关闭，避免使用返回、退出描述。
l 通常情况下，每个窗口应该有一个唯一的标题，和触发它的菜单或按钮命令相对应。
l 在提示信息中多用“您、请”等礼貌用语，不要用对用户来说晦涩的计算机用语，杜绝错别字。
l 断句、逗号、句号、顿号和分号的用法，提示信息比较多的话，应该分段。
l 错误消息对话框有仅仅指出问题，还要提供解决问题的建议。
控件选择：
l 不要随意使用控件，控件功能要专一，风格统一。如果没有好的控件，则使用标准控件。
l 同一类型的控件操作方式相同，避免出现一个控件双击可以执行某些动作，而同样的控件，双击却没有任何反映。
l 一个控件只做单一功能，尽量不复用。
控件布局，窗口不拥挤，按功能组合控件 l 屏幕不能拥挤，也不能太松散。
l 整个项目，尽量采用统一的控件间距，通过调整窗体大小达到一致，即使在窗体大小不变的情况下，宁可留空部分区域，了不要破坏控件间的行间距。
l 文字和文本框一般采用左对齐方式，如单选文本框前的标签提示，使用左对齐加冒号；
数据列表表头文字和内容，也采用左对齐。文字和文本框中的文字水平中对齐。横排按钮，最右边的一个与上面的控件右对齐。还有内容ppt11页 l 为了使界面不出现跑版或者难看的局面，解决方法是固定窗口的大小，不允许改变尺寸。
5. 数据库评审 设计数据库之前（需要分析阶段）
l 数据库选型的考虑 l 必须对所有的实体关系绘制出关系图及相关说明，创建数据字典和ER图。
表设计 l 标准化和规范化：数据的标准化有助于消除数据库中的数据冗余。第三范式（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。事实上，为了效率的缘故，对表不进行标准化有时也是必要的，但要有充公的理由。
l 数据驱动：采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
字段设计 l 每个表中都应该添加的3 个有用的字段（dRecordCreationDate，在VB下默认是Now()，而在SQL Serve下默认为GETDATE()；
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER；
nRecordVersion，记录的版本标记），有助于准确说明记录中出现null 数据或者丢失数据的原因 l 对地址和电话采用多个字段：描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
l 使用角色实体定义属于某类别的列：在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
l 选择数字类型和文本类型尽量充足：在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
l 加删除标记字段：在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；
最好采用清除数据程序而且要仔细维护索引整体性。
选择键和索引 l 键设计4 原则：为关联字段创建外键、所有的键都必须唯一、避免使用复合键、外键总是关联唯一的键字段。
l 使用系统生成的主键：设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
l 不要用用户的键(不让主键具有可更新性)：在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
l 可选键有时可做主键：把可选键进一步用做主键，可以拥有建立强大索引的能力。
l 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
l 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
l 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
l 不要索引常用的小型表：不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
其它 l 防止数据冗余、防止更新异常、插入异常和删除异常！ l 每个表存在主属性，而且所有的属性都是依赖于主属性！ l 如果表的数据记录少，如不会超过上万条记录，可以考虑不建索引，数据记录多时，必须建索引。特别是上百万或者几千万条记录。
l 如果表的记录总值会超过500万条以上，考虑建分区。数据库文件大于4G时，考虑采用多个文件组，存储在不同的磁盘上，以便于用户对某些数据进行精确备份。
l 10G以上海量数据存储时，考虑对过去的数据采用数据压缩技术。
l 考虑表与表之间的关联最好不要超过三层。
l 对于大数据量的表只允许关联两个相关的小表，小表记录条数不允许超过1万条记录。
l 数据库设计时对于统计数据，要有统计表，避免发生查询时为了获取一个数值对几十万条记录进行统计计算的情况，如年统计、月统计等。
好的数据库设计，必须有一定的数据库知识的人来操作，才会发挥好的性能。操作数据库知识考察的要求：
l 编写SQL语句、视图、存储过程需要考虑不同的语句写CPU、内存的影响，优化使用查询、联接、分组等。
l 对常用的数据链接如left join、Right join、join、union和 union all 的用法熟悉、理解其数学的原理。
l 在编写与数据库相关的操作时，控制并发数、尽可能地不要去查询冗余的数据。
l 大量的操作尽量在程序内完成，易于控制内存或者CPU占用。使用触发器或者游标，要考虑性能。
6. 通讯程序评审 误码低，可靠性高 巡检效率高 占用资源少（CPU、内存及其它资源）
长时间运行稳定好 安全性好，出错可自恢复 接口友好，上层调用方便 易于功能或协议扩展 （可通用）是否应该增加此条内容 7. 用户体验评审 TAB键顺序 l 习惯用法、阅读顺序，从左到右、从上到下 快捷键、加速键 热键--> 应用切换键 加速键-->功能快速调用键 快捷键--> 菜单、工具条键盘选取键 和弹出菜单 l 使用非破坏性缺省按钮，回车、ESC键的正确使用。对于弹出模态窗体，有默认加速键，如回车表示激活当前窗口设置为default的按钮动作，esc表示关闭窗口。同时在调用default按钮动作和关闭动作时候，不应该做有破坏性的操作，避免用户错误操作产生危害程度，例如不能把删除数据等功能的按钮作为缺省按钮。当用户要提交很多数据时，应该屏蔽ESC，或者做退出提示，告诫用户是否保存提交。
l 尽量避免使用右键菜单， 如使用的话尽量在可视化界面上拥有对应的按钮或者菜单选项。因为右键菜单由用户点击鼠标左右键或者别的动作才能调出来显示给用户。无法清晰的显示给用户，所以对应选项应该可以通过别的途径得到的。
用户交互 l 要使一个功能有时允许有时不允许用户使用，则这个控件的不能随便隐藏，应该使用disable属性进行表示，以免用户发现控件失踪后措手无策。
l 窗口弹出位置要明显，点击一个控件，弹出窗口或者菜单，应该给人明显提示。对于弹出窗体,统一要求显示位置在屏幕中央，要求窗体是以模态显示，并且不出现在任务拦上。
l 执行动作要有提示。UI作为人机对话的工具，用户做了任何动作，应该给用户一个视觉或者听觉、触觉提示。而且这个提示应该行明显，但不应提示过长，可以有以下几种方法：弹出交互对话框让用户点击确认；
改变UI中控件参数提示：(处理不用用户确认的提示，有一定延时，或者用户按键后自动清除。)；
改变标题栏字符串，显示“信息：提交成功”,或者专门设置一个状态栏、TLable等用来进行提示。
图形用户界面的一些业界标准 l 关闭应用时应有信息窗提示用户确认：“您确认要退出***吗？”；
l 试图同时打开两次应用时不允许；
(一般而言) l 所有的屏幕都应响应帮助【F1】键且做同样的工作(显示相应的帮助信息)。
l 使用【Tab】键在窗口中移动光标/焦点，使用【Shift】+【Tab】组合键回移；
l 如果一个按钮能产生一个新窗口，则它不应该盖住先前的窗口，并能回到先前的窗口中；
l 一般情况下，窗口中的所有事情应该既能用鼠标又能用键盘来完成 通用界面元素设计 l 单选框用左右键和上下键移动，以及鼠标单击选中。单选框是一种多先一设置，可先数目在2-8之间。当空间不够时，单选框可以用循环按钮、下拉菜单、滚动列表来代替。
l 复选框在框中用鼠标单击，以及空格键来实现在文本上设置/取消设置；
l 复选框按选择几率的高低而先后排列；
l 复选框要有默认选项，并支持【Tab】选择 l 除确定（ok）或取消（Cancel）外，其他的按钮应有一个字符代表，这个字符在按钮上是以下划线表示的，用[ALT]+字符组合键的方式可激活它，保证不重复定义这类字符；
l 命令按钮如果能导出一个新的窗口，使用户能输入或改变内容，刚按钮的文字后面带省略号（3个小点）
l 用[Tab]走到这个按钮后，按【空格】或【Enter】键应能激活；
l 用[Tab]移到其他类型的控制按钮（非命令），则在屏上这个控制钮以加宽黑框表示，这时按Enter应能激活这个控制钮；
l 按[Esc]键应能激活[Cancel]钮。
l 按下拉列表框右边的箭头处，应能得到（打开）选择列表项，列表项可以卷动（当内容多时应有卷动条），其框中应不能输入文本。
l 既要可以输入文字，又要可以在列表中选择，可以用联合框。
l 按一个字符应到以这个字符开头的项（英文时），按【Ctrl】+【F4】组合键应能打开下拉列表框。
l 下拉列表框中的选项应是排好了序的 菜单的设计 l 菜单功能是否正确执行；
l 常用菜单要有命令快捷方式。
l 文本字体、大小和格式是否正确；
l 菜单功能的名字是否具有自解释性; l 右键快捷菜单是否采用与菜单相同的准则；
l 是否适当地列出了所有的菜单功能 l 是否根据系统功能进行合理分类，将选项进行分组（完成相同或相近功能的菜单用横线隔开放在同一位置。）；
l 菜单深度是否控制在3层以内 l 菜单标题是否简洁、有意义；
菜单前的图标能直观的代表要完成的操作，如不能则不要用图标。
l 是否依使用频度排列；
是否依逻辑顺序排列；
是否依使用顺序排列；
l 各级菜单显示格式和操作方式是否一致。
系统响应时间 l 对可能造成等待时间较长的操作最好提供取消功能 l 系统响应为2-10秒，鼠标显示成为沙漏；
10-18秒时，由微帮助来显示处理进度；
18秒以上时，显示处理窗口或显示进度条。
l 对可能造成等待时间较长的操作最好提供取消功能（如果可能的话）
l 当一个长时间的处理完成时应发出一个提示警告声如beep(1)， 这样用户不必总看着屏幕 消息框 l 标题：建议以主窗口的名称作为标题，以变量的形式显示，最好不要写死。（标题是否根据内容显示为“提示”，“警告”）
l 文本：不考虑国际化开发时，可以直接以中文显示，考虑国际化开发时，需要根据字串取本地化文本。请注意提示信息的语气及标点符号。
l 按钮：当有多个按钮时，执行删除操作时，默认按钮应为否（取消）。
l 符号：根据提示的内容，确认图标的显示：关键消息（系统出错）时显示；
警告询问（提问）时显示；
警告消息（用户的错误操作）时显示；
通知消息（一般提示）时显示。
确认正确性 l 输入或操作有问题时，是否给用户一个恰当的信息 l 输入非法值并单击了【确认】按钮后，是否会出现报错信息 l 对于数据域，检查负数是否能输入；
检查最大值、最小值以及中间值是否允许 l 对字符/字母域检查是否有一个特定的限制 l 检查必输域是否需要用户输入 l 必输域对应的数据库表字段是否不能为空 导航测试 l 通过菜单是否可以进入应用屏（窗口）；
l 通过工具条是否可以进入应用屏(窗口)；
l 通过父窗口中的按钮是否可以进入子窗口；
l 当窗口激活时，窗口模式是否正确；
l 同时能打开相同应用窗口的数量是否符合要求 元素易用性测试 l 窗口中下拉表中的项目排序是否正确；
l 测试日期输入的正确格式；
l 窗口中的按钮是否都有适当的快捷键；
l 快捷键的工作是否正常；
l 菜单中的选项是否定义了快捷键；
l 只读域应不在TAB键能达到的序列中；
l 非激活域应不在TAB键能达到的序列中；
l 【重置】和【清空】等按钮不应该对不可编辑的域进行操作 l 用鼠标点出文本框，是否会出现帮助信息；
l 用鼠标单击只读域，是否能进入；
l 当打开窗口时，光标/焦点应位于第一个可输入域；
l 窗口中是否有缺省的按钮定义；
l 缺省按钮的工作是否正常；
l 当错误信息确认时，焦点是否会回到出错的域；
l 使用【Alt】＋【Tab】组合键从一个应用到另一个应用切换时是否有冲突；
l 编辑框域是否指示了字符的长度；
数据完整性测试 l 关闭窗口时数据是否得到了保存；
l 检查域的长度，以保证没有字样被截掉；
l 有的域是通过在数据库中查询一个值作为缺省值，并且用户可以输入一个有效值来取代这个值；
没理解 l 检查能接受负数的数字域能将负数正确的存储；
l 一组单选按钮是否由一组值代表（在数据库中）；
l 数据库对数据的存储是否完整，如字符串是否被截，数值是否被舍入。
只读模式的测试 l 只读模式屏幕和域的颜色设置是否正确；
l 只读模式是否合乎实际（这种情况下，是否应设为只读模式）；
l 字段域和控制按钮是否以只读模式来表示非激活；
l 与正在进行的操作无关的按钮应加以屏蔽（只读模式）
l 从窗口/菜单/工具条的只读模式是否能进入下一级窗口；
l 从只读模式进入的窗口是否有效；
l 只读模式下不能执行或进行“确认”；
通用性测试 l 保证有“帮助”菜单的存在；
l 保证在每个菜单中有适当的命令或选项；
l 保证工具条中的所有按钮对应一个命令；
l 保证每个菜单命令有一个热键方式；
l 在下拉列表中，保证值不被截断；
l 在下接列表中，保证表中的条目能通过适当的键或热键联合来存取；
l 窗口中没有重复定义的热键；
l 保证【Esc】键的正确使用（常用于“取消”），应有类似的提示：“更新的数据将丢失 是否继续？”；
l 保证“取消”按钮的功能同［Esc］键；
l “取消”但不能回退（已作的变化不能回退）时，应相当于“关闭”；
l 保证隐藏于当前屏幕后面的命令按钮不能工作；
l 当一个命令按钮应根据情况来确定是否能使用时，应保证在不能使用时变灰；
l 保证“确认【OK】”键和“取消【Cancel】”键按钮成对，并与其它命令按钮分开；
l 保证命令按钮名字清楚；
l 保证字段域的标签或名字不过于专业性，而是对系统的用户有意义的；
l 保证命令按钮有相似的大小和形状，相同的字体和字体大小；
l 保证每个按钮能通过热键盘方式来访问；
l 保证命令按钮在同一个窗口/会话框中不会重复；
l 保证每个窗口/会话框中元素（命令按钮、其它元素）在按回车键时，有一个清晰的缺省值响应回车；
l 保证对象/按钮的设置对应于窗口/会话框需要的功能；
l 保证可选按钮（包括单选项、复选项、以及选择框）的名字清楚；
l 如果热键用于访问可选键，保证在同一窗口/会话框中，热键不重复；
l 保证选择窗、选择按钮和命令按钮被逻辑地组在一起，形成功能“组”；
l 红色不用于加亮被激活的元素（色盲中最常风的为红-绿色盲）；
l 保证屏幕/窗口中的展现与分布不混乱；
l 在表窗口中【Ctrl】+【F6】组合键打开下一个表；
不明白 l 在表窗口中【Shift】+【Ctrl】+【F6】组合键打开先前的表（回到先前的表）；
l 在当前表的最后域中，用【Tab】键可以打开下一个表；
l 在最后表的最后域中，用【Tab】键可以走到【继续】按钮中；
l 在窗口中间件【Tab】键可走进下一个可编辑框；
l 当列表框中的选项少于8项时，不必用滚动条；
l 当系统“继续”发现错误时，应回到出错的域或表；
l 对表中的域输入正确前，按[继续]按钮不起作用；
l 打开一个表时，焦点落入第一个可编辑域；
l 所有字体一致；
l 【Alt】+【F4】组合键将关闭表窗口，回到主屏幕或先前的屏幕，必要时有提示信息：如“更新的数据将丢失”；
l 对于激活的域和挖掘 有简单的帮助文本；
l 保证所有非激活域是只读模式。
特殊域的测试之日期域 l 保证闰年日期有效正确，不产生错误和计算误差；
l 测试月份是在1和12之间（含），其它数值报错；
l 测试日期在1和31之间（含），最大值与月份相关；
l 对二月的28,29,30日，进行验证；
l 测试日期的周期性计算正确。
特殊域的测试之数字域 l 保证对最低、最高值处理正确；
l 输入无效的数据值被记录和报告；
l 保证有效的值被正确地处理 l 在数字前面带有空格的数字域被正确处理还是报错误；
l 在数字后面带有空格的数字域被正确处理还是报错误；
l 保证正、负值被正确处理；
l 保证除零的事不会发生；
l 数字域范围至少含有一个值 l 数字域范围含最大值和最小值 l 对范围外的值进行测试，保证错误值能被检测出来。
特殊域的测试之字符域 l 测试使用空格和非空格字符；
l 测试最高值和最低值 l 测试非法字符或控制符 l 测试合法字符 l 测试第一个位置是空格的数据或最后一位置是空格的数据。
8. 测试结果评审 所有功能的验证：提交功能性测试报告。
验收测试：根据需求有设计说明书，对需求及设计说明书中的内容进行验证。提交验收测试报告。
极限测试：文件破坏、数据错乱、大数据量、死机、CPU内存耗尽、硬盘写满、不符逻辑、大量错误数据引起的日志文件过大、系统崩溃等等。
9. 中试结果评审 l 是否实现了所有计划的功能 l 是否达到了预定的性能指标 l 界面是否令人满意 l 用户体验是否良好 l 工程实施是否简单、易操作 10. 版本发布 l 版本发布要得到研发中心的认可 l 版本发布的文档包括：
l 编写：安装使用说明书、常见问题解答。
l 整理：开发设计任务书（或者需求说明书）、概要设计（功能细化、数据库设计及说明、UI界面设计）、过程控制文档（代码编写过程中重要的逻辑或者数据说明）、测试文档。
l 版本发布的产品：用户安装的使用光盘、使用说明书。
l 所有与产品相关源代码备份。
l