测试执行及BUG提交

如何执行测试脚本并提交缺陷1测试执行前提及注意事项2测试执行过程中的问题3测试执行过程及方法4测试执行结束的条件一、如何执行测试脚本什么是测试执行？

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。

预置条件>测试用例输入>操作步骤>输出测试执行的前提进入系统测试执行的要求1.所有软件实现基本完成。2.需求设计文档均已批准、定稿。3.测试计划、用例设计已完成。测试环境已准备好4.已经通过BVT测试或Smoke测试，检查主要功能是否能测试，表明该软件具备一定的可靠性，可以开始正式的、全面的测试1、仔细检查软件测试环境是否搭建成功。2、注意测试用例中的前提条件和特殊规程说明。3、测试用例要执行全部执行，每条用例至少执行一遍。测试执行的注意事项4、执行测试用例时，要详细记录软件系统的实际输入输出。5、不要放过任何偶然想象。测试执行的注意事项测试用例执行过程中的问题1.软件是否有缺陷2.填写软件缺陷报告3.确定造成这些缺陷的原因4.需求、设计是否有缺陷5.测试环境和测试部件是否有缺陷6.测试用例设计是否不合理测试用例执行的方法一.测试用例的手动执行根据测试用例的要求人工的进行软件操作，输入数据，观测输出结果二.测试用例的自动执行1、使用录制回放工具2、使用通用脚本texttexttexttexttext1.根据测试的阶段、任务，选择执行全部或部分测试用例2.任务分配：将测试用例分配给测试工程师3.执行测试，记录原始数据，报告发现的缺陷4.执行某些测试用例时，如果需要先将被测对象置于某个特定的状态，则应保留测试环境、状态测试执行的过程5,解决测试中阻碍进度的问题6,向管理层报告测试的进度、发现的主要问题等等测试执行的过程测试用例的状态和生命周期

pass:执行通过

fail:执行失败

Block（阻塞）:这个状态就是该条用例在执行时阻塞，没法执行

下去。测试执行结果测试开始标准：1、测试计划评审通过；

2、测试用例已编写完成，并已通过评审；

3、存在已提交的可测试的系统；

4、测试环境已搭建完毕。测试停止标准：

1、近半数以上测试用例无法执行；

2、测试环境与要求不符。

3、开发中需求频繁变动测试开始执行、停止执行，结束执行的条件测试结束标准：

1.达到了覆盖率的要求例如：100%语句覆盖90%用例场景覆盖

2.指定的时间段内没有发现新的缺陷3,基于成本的考虑4,项目组达成一致5,因时间进度、资源的限制必须结束测试执行完就要提交测试执行的结果，测试执行的结果用每一个bug单表示，所以Bug是与测试用例对应起来的。下面主要讲下bug的有关问题1软件缺陷的定义及分类2Bug的提交流程3Bug内容的规范

4特殊bug问题的处理规范二.如何提交缺陷软件缺陷

软件缺陷（Defect），常常又被叫做[1]

Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。1.严重缺陷不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足例如：1.1、由于程序所引起的死机非法退出

1.2、死循环

1.3、数据库发生死锁

1.4、错误操作导致的程序中断2.较严重缺陷严重地影响系统要求或基本功能的实现，且没有办法更正。例如：2.1、功能不符

2.2、程序接口错误

2.3、数据流错误

2.4、轻微数据计算错误Bug的分类3.一般性缺陷严重地影响系统要求或基本功能的实现，但存在合理的更正办法

3.1、界面错误

3.2、打印格式错误

3.3、删除操作未给出提示

3.4、数据输入没有边界值限定或不合理4、较小缺陷使操作者不方便或遇到麻烦，但它不影响执行工作或功能实现。例如：1、辅助说明描述不清楚

2、显示格式不规范

3、系统处理未优化

4、长时间操作未给用户进度提示．5、提示窗口文字未采用行业术语Bug的分类1、概要测试人员在概要输入时，首先要明确是外网还是内网发生的问题，然后再对问题进行简单的描述。在描述中，需说明在什么模块出现了什么样的错误。比较规范的概要输入如：外网--委托方新增联系人时对固定电话的校验错误不规范的概要输入如：外网—固定电话校验错误或委托方新增联系人时对固定电话的校验错误。2、缺陷发现版本测试人员在选择缺陷发现版本时，应选择正在测试的版本3、状态

Bug流程状态请参照Bug提交流程说明。4、模块名称，发现者，缺陷发现日期测试人员在提交Bug时，应选择Bug出现的模块。发现者和发现日期。Bug内容的规范

5、严重程度测试人员在提交Bug时，需明确Bug的严重程度，严重程度的已在前面的bug分类中做了详细介绍。6、缺陷描述测试人员在缺陷描述中，应包括以下几点的描述：

1）Bug出现的模块

2）进行了哪些操作，如新增某条数据或修改某条数据。注意的是，在描述中，需明确测试数据，有利于研发人员快速寻找错误原因。

3）Bug现象的描述，应清楚地描述Bug出现的现象，不得含糊不清。4）如已找到Bug出现的原因，也应在描述中进行说明。5）可根据测试人员对需求的理解，填写认为正确的修改意见。Bug内容的规范

7、可重现性

测试的偶然性，即首次执行会出现Bug,再次执行时，该Bug消失。8、关闭版本测试人员在回测过程中，如Bug已经不存在，在关闭此Bug时，需选择当前回测的版本号。9、关闭日期测试人员在回测过程中，如Bug已经不存在，在关闭此Bug时，需选择当前回测通过。Bug内容的规范

Bug内容的规范

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