测试执行及BUG提交

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

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

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

4、lock（阻塞）:这个状态就是该条用例在执行时阻塞，没法执行 下去。测试执行结果测试开始标准：1、测试计划评审通过； 2、测试用例已编写完成，并已通过评审； 3、存在已提交的可测试的系统； 4、测试环境已搭建完毕。测试停止标准： 1、近半数以上测试用例无法执行； 2、测试环境与要求不符。 3、开发中需求频繁变动测试开始执行、停止执行，结束执行的条件测试开始执行、停止执行，结束执行的条件测试结束标准： 1.达到了覆盖率的要求 例如： 100%语句覆盖 90%用例场景覆盖 2.指定的时间段内没有发现新的缺陷 3,基于成本的考虑 4,项目组达成一致 5,因时间进度、资源的限制必须结束 测试执行完就要

5、提交测试执行的结果，测试执行的结果用每一个bug单表示，所以Bug是与测试用例对应起来的。下面主要讲下bug的有关问题1软件缺陷的定义及分类软件缺陷的定义及分类2BugBug的提交流程的提交流程3BugBug内容的规范内容的规范 4特殊特殊bugbug问题的处理规范问题的处理规范二二. .如何提交缺陷如何提交缺陷软件缺陷软件缺陷 软件缺陷（Defect），常常又被叫做1Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是

6、软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。1. 1.严重缺陷严重缺陷 不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足例如：1.1、由于程序所引起的死机非法退出 1.2、死循环 1.3、数据库发生死锁 1.4、错误操作导致的程序中断2. 2.较严重缺陷较严重缺陷 严重地影响系统要求或基本功能的实现，且没有办法更正。例如：2.1、功能不符 2.2、程序接口错误 2.3、数据流错误 2.4、轻微数据计算错误BugBug的分类的分类3.3.一般性缺陷一般性缺陷 严重地影响系统要求或基本功能的实现，但存在合理的更正办法 3.1

7、、界面错误 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、严重程度、严重程度 测试人员在提交Bug时，需明确Bug的严重程度，严重程度的已在前面的bug 分类中做了详细介绍。6、缺陷描述缺陷描述 测试人员在缺陷描述中，应包括以下几点的描述： 1）Bug出现的模块 2）进行了哪些操作，如新增某条

9、数据或修改某条数据。注意的是，在描述中，需明确测试数据，有利于研发人员快速寻找错误原因。 3）Bug现象的描述，应清楚地描述Bug出现的现象，不得含糊不清。 4）如已找到Bug出现的原因，也应在描述中进行说明。 5）可根据测试人员对需求的理解，填写认为正确的修改意见。BugBug内容的规范内容的规范 7 7、可重现性、可重现性 测试的偶然性，即首次执行会出现Bug,再次执行时，该Bug消失。8 8、关闭版本、关闭版本 测试人员在回测过程中，如Bug已经不存在，在关闭此Bug时，需选择当前回测的版本号。9 9、关闭日期、关闭日期 测试人员在回测过程中，如Bug已经不存在，在关闭此Bug时，需选择

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