2 、 BUG 的跟踪
A) 对自己发现的 BUG 已解决和未解决的问题进行跟踪。
B) 对新版本中仍未解决的问题应另外作 BUG 记录，并可注明“遗留问题”。
3 、测试任务分工
明确每人的测试重点，文件的保存位置，提交 BUG 的方式，所有的 BUG 由测试组长汇总后提交给项目组。
2.4.4. 测试组工作流
1. 项目组 PM 提交测试程序;
要求：包含所有工程文件和执行文件(第一次要求是项目组经过预测试的可运行程序)
2. 测试人员验收;
3. 测试人员将所有文件打进一个包;
4. 提交给项目配置库;
5. 测试执行
说明：测试人员按《测试任务分工》、《业务依赖关系》及相关的《需求文档》 执行测试
6. 填写《测试记录》与《 BUG 列表》
要求：《测试记录》在测试过程中按照要求即时、详尽的填写;《 BUG 列表》每天测试完成后按要求填写
7. 将《测试记录》与《测试 BUG 列表》提交测试组长(不长于 2 天提交一次);
说明：测试人员不长于 2 天完成一轮测试
8. 测试组长统计测试情况并及时将 BUG 列表提交项目组 PM
9. 项目组及时更改程序并跟踪记录 BUG 的解决情况;
要求：项目组不长于 2 天的时间，提交一次软件新版本(以日期定义版本)给测试小组进行测试。新版本软件提交到配置库并及时通知测试组
2.5. 常规问题
2.5.1. 程序人员自测不严
程序人员在有测试人员的情况下，对于编码后的程序常不行全面的测试后就会抛给测试小组进行测试，使测试小组承担过多的责任，解决方式：程序人员进行单元测试，提供单元测试记录，加强程序严谨性;在一定(一天或两天)时间程序进行代码暂时封冻，程序员进行互测，使其了解自己编的程序到底如何或给项目领导进行演示，破坏其自我优越感。
2.5.2. 数据约束的合理性是桌前检查第一步
数据是否是约定条件范围内;对于越界处理是否正常;默认、空白、 null 值、零值的处理是否正常。
3. 软件的测试标准
对于软件的测试从以下几个方面考虑：
1. 用户需求的完整性：
是否根据用户所要求的业务流程，进行了相应的具体系统的实现。
2. 文档的完整性：
是否已经完成合同及约定所明确的所有的文档。
3. 通过测试(含准确性测试)
测试的第一步，测试系统能做什么工作。
4. 条件覆盖测试
测试的第二步，测试系统多方面考虑进行的如何。通过一定的测试数据明确是否进行了足够的条件覆盖，使系统达到足够的质量。
5. 数据约束的合理性：
数据是否是约定条件范围内;对于越界处理是否正常;默认、空白、 null 值、零值的处理是否正常。
6. 状态控制
进行系统和功能在不同状态下的处理，如数据库关机，客户机开机是否可以正常。
7. 软件常规性能及其它：
软件所需的操作环境及易使用性，可移植性、兼容性、错误恢复能力和可维护性等等是否为用户认可。
对于测试的结果有两种可能，一种可能是各种方面(主要是功能和性能指标)满足软件需求说明的要求，用户接受系统;另一种可能是软件不满足软件需求说明的要求，用户无法接受。对于这个阶段才发现的严重错误(一般指重要的业务逻辑)一般很难在预定的时间改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
关于作者：
王辉，具有八年的编程及系统管理经验，所使用的语言为 C 和 Java 编程语言。目前在深圳一家公司做项目经理，使用 C 和 ORACLE 数据库开发应用系统。可通过 ddxxkk@21cn.com 联系。
4. 附录
4.1. 测试计划大纲
摘自 计算机软件产品开发文件编制指南 GB 8567-88
这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。具体的内容要求如下：
17 . 1 引言
17 . 1 . 1 编写目的
17 . 1 . 2 背景
17 . 1 . 3 定义
17 . 1 . 4 参考资料
17 . 2 计划
17 . 2 . 1 软件说明
17 . 2 . 2 测试内容
17 . 2 . 3 测试 1 (标识符)
17 . 2 . 3 . 1 进度安排
17 . 2 . 3 . 2 条件
17 . 2 . 3 . 3 测试资料
17 . 2 . 3 . 4 测试培训
17 . 2 . 4 测试 2 (标识符)
......
17 . 3 测试设计说明
17 . 3 . 1 测试 l (标识符)
17 . 3 . 1 . 1 控制
17 . 3 . 1 . 2 输入
17 . 3 . 1 . 3 输出
17 . 3 . 1 . 4 过程
17 . 3 . 2 测试 2 (标识符)
.......
17 . 4 评价准则
17 . 4 . 1 范围
17 . 4 . 2 数据整理
17 . 4 . 3 尺度
4.2. BUG 列表必要内容
包括错误程序名称及版本，错误主题，错误严重级别，测试过程描述，测试人，测试时间，修改结果，修改人，修改时间。
对于错误严重级别的分类说明如下：
· 严重错误：导致系统无法实现功能目标，使测试无法继续进行。主要包括：程序不能起动、程序非正常终止、程序死机、关键需求未实现、严重的数值计算错误、安全性错误、文档与软件严重不符。
· 中等错误：导致系统无法正常实现功能目标，但知道如何通过其它途径来避免错误发生。主要包括：程序非正常终止但可避免、系统边界值错误、非关键需求理解错误、系统文档错误。
· 轻微错误：导致用户 / 操作员使用不方便，但不影响系统功能目标的实现。主要包括：查询报告格式错误、用户界面不很友好、显示格式错误、轻微的数值计算错误、系统处理未优化、系统文档存在轻微错误等。
· 建议：使系统更加完善的建设性意见等。
4.3. 常用名词定义
白盒测试 ：如果已知产品的内部活动方式，可以测试它的内部活动是否都符合设计要求，这种方法叫白盒测试，检查软件的内部逻辑结构，是以仔细检查过程的细节为基础，通过提供一组指定条件和循环的测试用例，对穿过软件的逻辑路径进行测试，可以在不同点检查程序的状态，以确定实际状态与预期状态是否一致。
黑盒测试 ：着眼于软件的外部特性，而不考虑软件的内部逻辑结构。指在软件的接口上进行测试，即看它能否满足功能要求，输入能否被正确地接收，并正确的输出结果，以及能否保持外部信息(如数据文件)的完整性等等。
单元测试(模块测试) ：相当于分调，即逐个模块考察，是以详细设计描述为指南，对重要的控制路径进行测试，用以发现错误。使用白盒子测试法。
集成测试(组装测试或联合测试) ：相当于联调，主要是考察模块间的接口和各模块间的联系
确认测试(有效性测试) ：是验证软件的功能和性能及其它特点是否与用户的要求一致。功能与用户的需求是否一致。使用黑盒测试。
系统测试(系统联调) ：是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行一系列的组装测试和确认测试。
验收测试： 由用户实施，通过所谓黑盒子测试，来证实软件功能与描述的需求是否一致
回归测试 ：重复以前进行过的部分或全部测试
恢复测试： 是一种系统测试，它以不同的方式强使软件出现故障，用来严整软件能否恰当地完成恢复
安全性测试： 就是试图去验证建立在系统内的预防机制，以防止来自非正常的侵入。
强度测试： 实在要求一个非常数量、频率或容量资源方式下运行一个系统。它实际上是一种叫做敏感性测试技术
性能测试 ：就是测试软件在给组装进系统的环境下运行时的性能。性能测试应覆盖测试过程的每一步
测试用例： 一组最有可能发现某个错误或某类错误的测试数据
4.4. 关于α、β测试
事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。
α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。