测试执行及BUG提交

1、如何执行测试脚本 并提交缺陷 1 测试执行前提及注意事项测试执行前提及注意事项 2 测试执行过程中的问题测试执行过程中的问题 3 测试执行过程及方法测试执行过程及方法 4 测试执行结束的条件测试执行结束的条件 一、如何执行测试脚本一、如何执行测试脚本 什么是测试执行？什么是测试执行？ 测试执行是执行所有或部分选定的测试用例，并 对结果进行分析的过程。 预置条件预置条件 测试用例输入测试用例输入 操作步骤操作步骤 输出输出 测试执行的前提测试执行的前提 进入系统测试执行的要求 1.所有软件实现基本完成。 2.需求设计文档均已批准、定稿。 3.测试计划、用例设计已完成。 测试环境已准备好 4.已经

2、通过BVT测试或Smoke测 试，检查主要功能是否能测试， 表明该软件具备一定的可靠性， 可以开始正式的、全面的测试 1、仔细检查软件测试环境是 否搭建成功。 2、注意测试用例中的前提条 件和特殊规程说明。 3、测试用例要执行全部执行， 每条用例至少执行一遍。 测试执行的注意事项测试执行的注意事项 4、执行测试用例时，要详细 记录软件系统的实际输入输出。 5、不要放过任何偶然想象。 测试执行的注意事项测试执行的注意事项 测试用例执行过程中的问题测试用例执行过程中的问题 1.软件是否有缺陷 2.填写软件缺陷报告 3.确定造成这些缺陷的原因 4.需求、设计是否有缺陷 5.测试环境和测试部件是否有缺

3、陷 6.测试用例设计是否不合理 测试用例执行的方法测试用例执行的方法 一. .测试用例的手动执 行 根据测试用例的要 求人工的进行软件操 作，输入数据，观测 输出结果 二.测试用例的自动执 行 1、使用录制回放工具 2、使用通用脚本 text text text text text 1.根据测试的阶段、任务，选择执行全部或部分测试用例 2.任务分配：将测试用例分配给测试工程师 3.执行测试，记录原始数据，报告发现的缺陷 4.执行某些测试用例时，如果需要先将被测对象置于 某个特定的状态，则应保留测试环境、状态 测试执行的过程测试执行的过程 5,解决测试中阻碍进度的问题 6,向管理层报告测试的进度

4、、发现的主要问题等等 测试执行的过程测试执行的过程 测试用例的状态和生命周期 pass:执行通过 fail:执行失败 Block（阻塞）:这个状态就是该条用例在执行时阻塞，没法执行 下去。 测 试 执 行 结 果 测试开始标准：1、测试计划评审通过； 2、测试用例已编写完成，并已通过评审； 3、存在已提交的可测试的系统； 4、测试环境已搭建完毕。 测试停止标准： 1、近半数以上测试用例无法执行； 2、测试环境与要求不符。 3、开发中需求频繁变动 测试开始执行、停止执行，结束执行的条件测试开始执行、停止执行，结束执行的条件 测试结束标准： 1.达到了覆盖率的要求 例如： 100%语句覆盖 90%

5、用例场景覆盖 2.指定的时间段内没有发现新的缺陷 3,基于成本的考虑 4,项目组达成一致 5,因时间进度、资源的限制必须结束 测试执行完就要提交测试 执行的结果，测试执行的结 果用每一个bug单表示，所以 Bug是与测试用例对应起来的。 下面主要讲下bug的有关问题 1 软件缺陷的定义及分类软件缺陷的定义及分类 2 BugBug的提交流程的提交流程 3 BugBug内容的规范内容的规范 4 特殊特殊bugbug问题的处理规范问题的处理规范 二二. .如何提交缺陷如何提交缺陷 软件缺陷软件缺陷 软件缺陷（Defect），常常又被叫做1Bug。所谓软件 缺陷，即为计算机软件或程序中存在的某种破坏正

6、常 运行能力的问题、错误，或者隐藏的功能缺陷。缺陷 的存在会导致软件产品在某种程度上不能满足用户的 需要。IEEE729-1983对缺陷有一个标准的定义：从产品 内部看，缺陷是软件产品开发或维护过程中存在的错 误、毛病等各种问题；从产品外部看，缺陷是系统所 需要实现的某种功能的失效或违背。 1. 1.严重缺陷严重缺陷 不能执行正常工作功能或重要功能。使系统 崩溃或资源严重不足 例如：1.1、由于程序所引起的死机非法退出 1.2、死循环 1.3、数据库发生死锁 1.4、错误操作导致的程序中断 2. 2.较严重缺陷较严重缺陷 严重地影响系统要求或基本功能的实现，且 没有办法更正。 例如：2.1、功

7、能不符 2.2、程序接口错误 2.3、数据流错误 2.4、轻微数据计算错误 BugBug的分类的分类 3.3.一般性缺陷一般性缺陷 严重地影响系统要求或基本功能的实现，但 存在合理的更正办法 3.1、界面错误 3.2、打印格式错误 3.3、删除操作未给出提示 3.4、数据输入没有边界值限定或不合理 4 4、较小缺陷、较小缺陷 使操作者不方便或遇到麻烦，但它不影响执 行工作或功能实现。 例如：1、辅助说明描述不清楚 2、显示格式不规范 3、系统处理未优化 4、长时间操作未给用户进度提示 5、提示窗口文字未采用行业术语 BugBug的分类的分类 1 1、概要、概要 测试人员在概要输入时，首先要明确

8、是外网还是内 网发生的问题，然后再对问题进行简单的描述。在描 述中，需说明在什么模块出现了什么样的错误。 比较规范的概要输入如：外网-委托方新增联系人 时对固定电话的校验错误 不规范的概要输入如：外网固定电话校验错误 或 委托方新增联系人时对固定电话的校验错误。 2、缺陷发现版本、缺陷发现版本 测试人员在选择缺陷发现版本时，应选择正在测试 的版本 3、状态状态 Bug流程状态请参照Bug提交流程说明。 4 4、模块名称，发现者，缺陷发现日期、模块名称，发现者，缺陷发现日期 测试人员在提交Bug时，应选择Bug出现的模块。 发现者和发现日期。 BugBug内容的规范内容的规范 5 5、严重程度、

9、严重程度 测试人员在提交Bug时，需明确Bug的严重程度，严重 程度的已在前面的bug 分类中做了详细介绍。 6、缺陷描述缺陷描述 测试人员在缺陷描述中，应包括以下几点的描述： 1）Bug出现的模块 2）进行了哪些操作，如新增某条数据或修改某条数 据。注意的是，在描述中，需明确测试数据，有利于研 发人员快速寻找错误原因。 3）Bug现象的描述，应清楚地描述Bug出现的现象， 不得含糊不清。 4）如已找到Bug出现的原因，也应在描述中进行说 明。 5）可根据测试人员对需求的理解，填写认为正确的 修改意见。 BugBug内容的规范内容的规范 7 7、可重现性、可重现性 测试的偶然性，即首次执行会出

10、现Bug,再次执行时， 该Bug消失。 8 8、关闭版本、关闭版本 测试人员在回测过程中，如Bug已经不存在，在关闭此 Bug时，需选择当前回测的版本号。 9 9、关闭日期、关闭日期 测试人员在回测过程中，如Bug已经不存在，在关闭此 Bug时，需选择当前回测通过。 BugBug内容的规范内容的规范 BugBug内容的规范内容的规范 缺陷提交流程缺陷提交流程 1、测试员提交缺陷单给测试组 长（此时状态为new）。 2、测试组长确认缺陷存在并符合 需求时将其提交给研发组负责人 （此时需将状态改变为open），如 果缺陷不存在或不符合需求，则关 闭此缺陷（此时需将状态改变为 closed）。 3、

11、研发组负责人收到此缺陷后， 分配给其它组员进行修改。如 分配给其它组员，则无须修改 状态，如自行修改，则须修改 其状态（此时可选择的状态有 fixed、rejected）。（需说明预 计缺陷关闭版本和预计修改时 限） 4研发其它组员收到研发组负责 人转交过来的缺陷后，则须修改 其状态（此时可选择的状态有 fixed、rejected），然后返还给研 发组负责人。） 6测试组长将其问题返还给测 试人员进行回测（在此过程中， 测试组长是不用改变状态的）。 7、测试人员在回测过程中， 根据回测结果修改其状态 （此时可选择的状态有closed、 reopen）。 5、研发组负责人再将其问题返还 给测试组长。（在此过程中，研发 组负责人是不用改变状态的）。 对于不处理的Bug（即状态为rejected的 Bug），测试人员可根据以下三种情况作 处理： 1，如研发人员明确不修改时，测试人员 可以根据对需求和软件的理解进行