6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试期间测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。

7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显著位置标明为测试版字样。

8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期，否则通过稳定期测试。

9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。

10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测试设计的改动纳入基线。最后，组长整理并在指定地点保存相关测试数据和测试样张。

11、测试部门解散测试小组。

另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机测试、加密检查、说明书检查…)，并要求写入测试方案中。

传统测试流程遇到的挑战和对策——问题发现得越早，解决的代价就越小

（1）自动测试工具和测试理论

由于产品开发模式还不够规范、相关文档不够完备，所以测试工具的应用效果不理想，只能部分应用。如：SQA。

对于测试理论，测试思想/测试理念的灌输工作还是有成效的，但是测试数学模型的研究和建立工作进展不顺利，主要原因也是我们的产品生命周期内部操作不够规范。

目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试设计。

（2）测试分类

根据目前的实际情况(已经由传统的瀑布开发模式、使用结构化设计和实现手段，变为现在的RAD开发模式、使用OOD和OOP)，我们将把测试分为三种：产品测试、项目测试、系统评测。我们的依据是：问题发现得越早，解决的代价就越小。

产品测试的流程基本和上面提到的一样。

项目测试的原则是尽早加入测试，并充分重视和支持用户测试。

系统评测是简化工作流程。

测试中常见问题分析及对策

我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：死机(系统崩溃或挂起)、致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。

我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优先级越高。

但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方便的。

形象类问题：——不专业、用户不信任

1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。

2、不够专业，缺乏基本知识，而又没有高手检查。

3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词

4、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；

5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则…

6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)

7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。

可用性问题：——用户无法使用或不方便使用

"用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。"

下面是一些用户界面错误的例子：

1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果

2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值

下面是一些低效的用户界面的例子：

1、表达不清或过于模糊的信息提示

2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。

3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。

4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。

5、使用不完善的功能且不给用户以恰当的提示。

6、不经用户确认就对系统或数据进行重大修改

稳定性问题：——影响用户正常工作

1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低

2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。

3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。

其他问题

1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。

2、运行时不检查内存、数据库或硬盘空间等

3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的

4、提供的版本带病毒，或根本无法安装，或没有加密

5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本

6、用户现场开发和修改，又没有记录和保留

7、错误反复出现，改动得不彻底、或版本管理出现混乱

8、错误越改越多，改动得不彻底、或改动得不小心

9、版本中部分内容和接口倒退

10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示

11、资源没有和代码分离，不同语言版本间不能平滑转换

12、缺少第三方产品的评估：广告管理系统2000年问题

13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，是面向组织的而不是面向产品或方案的)。

期望项目组关注的一些问题

1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序

2、问题留给测试组去发现的心态——不仔细测试、不小心修改、甚至不全面改(不彻底)

3、自己不会用，不了解产品的用法。

4、更多地从用户使用的角度考虑设计、编码与测试
『引自 软件工程专家网』