软件测试工作流程(个人版)
测试基本流程
一、测试工程师岗位职责目的软件测试的目的是为了保证产品的最终质量，在软件开发的过程中，对软件产品进行质量控制，提高软件的可靠性。
的是尽可能发现bug并改正被测试软件中的错误，达到期望结果,提高软件开发的可靠性1. 制定测试产品的测试计划、方案；2. 设计并执行测试用例，对产品进行功能，性能，安全等测试；3. 实施高效的测试活动，并对测试结果进行分析，给出专业报告，与其他部门紧密协作，跟踪缺陷及推动及时修复；4. 维护测试环境，进行测试环境的部署与调试；5. 设计并且开发测试工具，对测试方法进行创新；6. 完成测试项目归纳及总结文档。
二、测试在整个项目周期过程中的介入时间和工作内容、重点测试在需求阶段介入一是测试人员通过早期参与，更清楚需求的来源和目的，有利于后期更好的从用户的角度开展测试活动；二是可以为后期设计验收测试用例提供很好的分析依据。
测试模型工作内容：和开发项目产品等沟通测试用例计划测试用例编写执行测试发现系统中的缺陷提交到缺陷管理工具发布测试报告用户需求文档1.bug的等级划分A致命1、由于程序所引起的死机，非法退出2、死循环3、数据库发生死锁4、因错误操作导致的程序中断5、功能错误（需求未实现）6、与数据库连接错误7、数据通讯错误B严重1、程序错误2、程序接口错误3、数据库的表、业务规则、缺省值未加完整性等约束条件主要功能丧失，严重地影响系统要求或基本功能的实现。
（重新安装或重新启动该软件不属于更正办法），须尽快修正C一般性（界面，图片，文字）1、操作界面错误（包括数据窗口内列名定义、含义是否一致）2、打印内容、格式错误3、简单的输入限制未放在前台进行控制4、删除操作未给出提示5、数据库表中有过多的空字段D建议性1、界面不规范2、辅助说明描述不清楚3、输入输出不规范4、长操作未给用户提示5、提示窗口文字未采用行业术语6、可输入区域和只读区域没有明显的区分标志3.bug的状态划分及各状态之间的变换关系Bug的处理流程：发现新建提交修改关闭重新打开4.bug的提交规范Bug模板【版本号】标题：B u g的简要描述。
软件测试流程规范最全
软件测试流程规范整体的流程图1.详细的流程执行1.1 计划与设计阶段整体流程图1.1.1 立项会议由高层主管立项会议，会议主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。
1.1.2 需求评审注：1．需求定义基本完成，此时应在评审会议召开之前发给测试团队，预留时间给测试相关人员熟悉、理解。
2．测试部参与人员由测试部经理指定，主要由测试组长、测试设计等人员组成（还应包括配置管理人员、质量保证人员）。
1.1.3 测试工作启动注：在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。
部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。
测试小组成员可预先熟悉必要的项目（产品）资料。
1.1.4 测试设计阶段1.1.4.1 设计测试计划注：针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。
1.1.4.2 设计测试用例注：在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。
1.1.4.2.1设计测试用例的常用方法a．等价划分法有效等价类:是指对于程序的规格说明来说是合理的有意义的输入数据构成的集合利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能无效等价类:与有效等价类的定义恰巧相反b．边界值法：➢边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
➢通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。
➢相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。
测试流程图
Level 3
工程得到很好地表现和理解，被描述成标准， 规程，关键和方法。 作为3级基础的组织标准过程集已经简历和不 断改进。 2，3级的区别在于标准，过程和规程的范围 3级比2级的描述更具体和更严格
Level 4
使用统计和量化技术进行控制 建立了质量和过程性能的量化目标，作为过程管理 的准则 收集了过程性能的详细度量，进行统计分析 质量和过程性能度量数据组成组织的度量库，来支 持将来的基于事实的决策 3，4级的区别在于过程性能的可预测性。
同行评审
.评审的输入 --待评审的文档，代码 --《XXX评审检查表》 .评审的输出 --《评审报告》 -- 《评审过程检查表》
正确看待文档
.文档是所有事情能够继承的保证 .如果认为不必要，多一分也是多，如果认为 必要，多少都不够 .文档是一个人水平高低的体现 .需要提高每个人的写作能力，练好内功
CMM2： 可重复性 KPA： 软件配置管理
软件质量保证 子合同管理
Level 2
软件项目跟踪和监控 软件项目计划 需求管理
配置管理
1.定义并文档化配置项的功能和物理属性 2.控制这些属性的变更 3.记录和报告变更处理结果和实施状态 4.遵从制定的需求进行验证
同行评审
为什么进行评审？ .促进文档化，提升可读性，易理解性等 .查找错误，收集建议 .扩散知识，产生后备力量 评审什么？ .项目中的一系列计划 .项目各阶段的输出：文档，代码等 谁来评审？ 项目组成员，PPQA，上级领导，客户等
程序执行的路径是：a b d
该测试用例虽然覆盖了可执行语句，但是并不能检查判断逻 辑是否有问题，例如在第一个判断中把&&错误的写成||，上 面的测试用例仍然可以覆盖所有的执行语句。可以说语句覆 盖率是最弱的逻辑覆盖准则
测试工作流程及管理规范
测试工作流程及管理规范2020年12月1.目的 (3)2.说明 (3)3.团队构成 (3)3.1职责 (3)3.2角色划分 (3)4.工作流程及规范 (4)4.1计划与设计阶段 (4)4.1.1召开测试启动会议 (4)4.1.2成立测试团队 (4)4.2测试阶段 (5)4.2.1设计测试用例 (5)4.2.2实施测试用例 (5)4.2.3提交测试报告 (5)4.2.4回归测试 (6)4.3总结阶段 (6)4.3.1编写测试工作总结 (6)4.3.2测试验收 (6)4.3.3缺陷跟踪 (7)4.4培训阶段 (7)5.测试管理规范 (8)6.测试标准文档 (10)7.测试部绩效考核标准 (10)7.2.1奖金分配制度 (11)7.2.2处罚制度 (12)7.2.3绩效奖励时间 (12)7.2.4特殊情况说明 (12)7.2.5举例 (12)1.目的本文档是公司测试部工作人员的日常工作规范，明确软件测试阶段，测试团队应完成的工作标准。
2.说明1、测试部是公司独立的部门，必须按照测试部工作要求开展工作；2、测试部工作人员应按照测试需求文档以及客观事实执行测试，严格坚持原则；3、测试部工作时间及反馈应根据项目总体时间和进度来制定，时间安排受技术总监整体掌控；4、测试验收报告必须由软件部负责人、项目经理、美工部主管、测试部主管、项目测试负责人五方共同签字，并提交总经理助理一份，与总经理共同进行抽查；5、测试完成后出具《测试总结报告》，项目方可正式上线。
3.团队构成3.1职责测试是软件开发过程中的重要组成部分，肩负着如下责任：A、在项目的前景、需求文档确立之前对文档进行测试，从用户体验和测试的角度提出自己的看法。
B、编写合理的测试计划，并与项目整体计划有机地整合在一起。
C、编写覆盖率高的测试用例。
D、针对测试需求进行相关测试技术的研究。
E、认真仔细地实施测试工作，并提交《测试总结报告》以供项目组参考。
F、进行缺陷跟踪与分析。
软件测试经验分享
测试经验分享一、测试的流程和方法：1、一个测试活动的完整流程是：①项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。
项目经理通过综合开发人员、测试人员以及客户的意见，完成项目计划。
②开发人员根据需求文档完成需求分析文档，测试人员参与评审，评审的主要内容包括：是否有遗漏或者双方理解不一致的地方。
测试人员完成测试计划文档。
③测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档和详细设计文档。
这两份文档作为测试人员编写测试用例的补充材料。
④测试用例编写完成后，测试和开发人员需要进行评审⑤测试人员搭建测试环境。
⑥开发人员提交第一个版本，可能存在未完成功能，但需要跟测试人员进行说明。
然后测试人员进行测试，发现bug后提交到缺陷库。
⑦开发提交第二个版本，包括修改的bug以及增加了的部分功能，测试人员进行第二轮测试。
⑧重复上面的工作，一般情况下从3-4个版本后bug数量减少，达到出货的要求。
（如果有客户反馈的问题，需要测试人员协助重现以及回归测试）2、在这里需求分析、测试计划、测试用例编写这块暂时不进行详细说明了，我们重点来讲一下测试过程中测试的方法和注意事项：目前，我们的测试人员在行社这边测试基本都是黑盒测试，也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。
是以用户的角度，从输入数据与输出数据的对应关系来进行测试的。
测试方法包括：等价划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、场景法等等，下面就常用的几种来详细讲解一下。
1、等价划分法：是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。
每一类的代表性数据在测试中的作用等价于这一类的其他值。
划分等价类的原则有以下几种：①在输入条件规定了取值范围或值的个数的情况下，则可以确定一个有效等价类和两个无效等价类，如：输入值是学生成绩，范围在0~100。
软件测试工作流程
软件测试工作流程软件测试是软件开发过程中的一个重要环节，其目的是保证软件的质量和稳定性。
软件测试工作流程包括需求分析、测试计划编制、测试用例设计、测试执行、缺陷管理和测试报告编写。
以下是软件测试工作流程的详细说明：1.需求分析在软件测试工作开始之前，测试人员需要充分了解软件的需求和功能。
测试人员要与开发人员、产品经理等沟通，确保对软件的需求和功能有清晰的认识。
在需求分析过程中，测试人员需要了解用户需求，明确软件的预期效果和目标，以便更好地制定测试计划和用例。
2.测试计划编制测试计划是在测试过程中的指导书，确定了测试的目标、时间安排、测试资源和人员分配等。
在编制测试计划时，测试人员需要与开发人员、项目经理等协商确定测试范围、测试环境、测试策略等。
测试计划还应明确测试的重点和风险点，以便对测试资源进行合理配置和管理。
3.测试用例设计测试用例是测试工作的核心，用于验证软件功能是否符合需求和设计。
在测试用例设计中，测试人员需要根据需求文档或需求描述，制定相应的测试用例。
测试用例应尽可能覆盖软件的所有功能和边界条件，以及常见的异常情况。
测试用例应包括输入数据、操作过程和预期结果等，以便测试人员进行后续的执行和评估。
4.测试执行在测试执行阶段，测试人员按照测试计划和测试用例进行测试。
测试人员需要在测试环境中安装和配置软件，按照测试用例的步骤进行相应的操作和输入数据。
在测试执行过程中，测试人员需要记录测试的过程和结果，包括测试时间、测试步骤、输入数据、实际结果和预期结果等。
同时，测试人员还需要关注和记录任何发现的缺陷或异常情况。
5.缺陷管理测试过程中，测试人员会发现一些软件缺陷或bug。
缺陷管理是指对缺陷进行记录、分类、跟踪和管理的过程。
测试人员需要将发现的缺陷记录在缺陷管理系统中，包括缺陷的详细描述、发现的环境、复现步骤等。
同时，还需要对缺陷进行分类和优先级的评估，以便开发人员能够及时修复和解决。
6.测试报告编写测试报告是对测试工作的总结和评估，向项目经理、开发人员等汇报测试的结果和问题。
软件测试规范
软件测试标准规范1目的为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考2适用范围本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。
3职责项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。
项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。
测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见项目负责人组织测试环境的建立。
项目经理审核负责控制整个项目的时间和质量。
研发人员确认修改测试人员提交的bug。
4工作流程4.1测试依据详细设计是模块测试的依据。
因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。
测试人员必须认真阅读，真正弄懂系统需求和详细设计。
4.2制订《测试方案》在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：测试目的；所需人员及相应培训要求；测试环境、工具和测试软件；测试用例、测试数据和预期的结果。
4.3单元测试项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。
单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。
对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。
单元测试针对程序模块，从程序的内部结构出发设计测试用例。
多个模块可以独立进行单元测试。
单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。
4.4集成测试编码开发完成，项目组内部应进行组装测试。
软件测试基础知识与软件测试基本流程(完整版)
使用软件来控制测试的执行，实际输出和预期输出的对比，测试前提条件的构建，以及其 他测试控制条件和测试报告功能。通常，测试自动化涉及自动化对一个已经使用了正式的测验 流程的手工过程。
显而易见，第二种定义具体，且涵盖了多数情况，特别是只提及软件，而不是一定是“自 动化测试工具”，而且不一定自动化测试步骤才叫自动化测试，很多情况下测试前提条件的自 动化也是很重要而且很值得自动化的。
表面上看两种是有区别的，但现在我们用的多了，在提到是通过工具（程序）来对软件进行测试，一般不需要 人为干预或干预很少。
Automated Testing/Test Automation:
1、Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.
-----------------------------------------
动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健 壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。所谓 软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态 测试也是公司的测试工作的主要方式。
什么是随机测试？TOP [浏览:6 次 ]
在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试 (Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书 执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件测试流程测试基本阶段划分•测试计划阶段•测试设计阶段•测试执行阶段•测试评估阶段•测试验收阶段文档编写人：龙文编写时间：2010-8-3目录1、测试计划阶段 (3)1.1、测试计划考虑的问题 (3)1.2、测试策略 (4)1.3功能列表 (4)1.3.1、其他非功能测试 (6)1.3.2、策略附件要求 (6)2、测试设计阶段 (8)3、测试执行阶段 (8)3.1、执行阶段操作 (9)4、测试评估阶段 (9)5、测试验收阶段 (10)1、测试计划阶段•做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。
这要求我们有一个完善的“测试计划书”。
•测试计划的内容：1、测试范围：描述本次测试中做的测试范围，如：测试软件功能范围、测试种类等2、简单的描述如何搭建测试平台以及测试的潜在的风险。
3、项目信息：说明要测试的项目的相关资料，如：输入输出文档，产品描述，软件主要功能4、人力资源的分配注：计划和设计分开编写，最好安排充分的时间去明确测试需求测试需求：笼统说，就是测试中的所有设计和需求文档。
作为本次测试的依据1.1、测试计划考虑的问题•1、要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性（必须对需求有透彻的理解）。
编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。
说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。
（1）测试内容：对一个软件来说测试计划中会明确本次测试做哪些测试？如：系统测试：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试）（2）测试目的：一般多为保证产品质量是否达到预期的指标。
这个指标也就是在测试中定义的结束标准。
（3）测试标准：需要考虑本次测试需要输入那些文档，该项目结束标准定义、测试结束标准的定义？bug级别定义、优先级定义、bug管理流程定义。
这个都需要在执行测试事明确。
计划中应该包含这些内容。
（4）资源分配：这里分为人力资源、软硬件资源等划分。
一般会把人力资源的利用写入一个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果（难度很大）。
软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具，列出清单。
（5）测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。
（6）软件测试策略一般都是分开来做相关测试方案。
•2、要坚持“5W1H”的原则，明确测试内容与过程。
◇明确测试的范围和内容（WHA T）；◇明确测试的目的（WHY）；◇明确测试的开始和结束日期（WHEN）；◇明确给出测试文档存放位置（WHERE）；◇明确测试人员的任务分配（WHO）；◇明确指出测试的方法和测试工具（HOW）。
1.2、测试策略•这一阶段在于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。
很多公司少这个一个阶段，需要有计划性的分出产品的功能扣出测试的功能点，现阶段大多公司都是直接拿着文档就开始做用例设计。
•对需求进行分析，列出具体的功能列表。
（一般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表单。
然后考虑到使用那些测试方法？工作一旦做到执行阶段，我们可以更好的根据这些功能表一点一点的覆盖。
也能让我们在用例评审时，充分的证实我们的工作是有效的能够保证产品的质量。
）一般在此之前，一些业务培训和需求评审是有必要是听一下的。
这样能够更早更熟练的理解需求，也能保证产品设计中出现的一些误区。
•对于一个个测试该如何进行测试？如下：1、功能测试1.1、功能范围（划分出各自负责的功能模块）1.2、使用测试方法（等价类、边界值等测试方法方法）1.3、测试标准（符合设计、需求和规范文档对该功能的描述）2、界面测试3、兼容性测试…………列举出策略中常用的测试种类功能测试、界面测试、兼容性测试、性能测试、安装卸载测试、数据库测试、文档测试、安全性测试、可靠性测试等等1.3功能列表功能描述：需求：–公告条数上没有限制；–公告有两种显示方式：顺序排列和随机排列，默认显示方式是顺序；–每条公告不超过50个中文字符或100个英文字符；–公告在客户端上以顺序排列方式显示的顺序同运营后台页面上从上到下显示的顺序。
–新增公告文字如需对应宝贝详情链接，则文字内容必须含有对应宝贝的名称，作为公告内的关键字链接。
–新增公告文字如是纯文字公告，不需选择“指定宝贝”。
1、实际中我们可以根据设计图形，可以看出内部的功能点如：删除、修改、新增、排序2、细分到具体的功能表单：（详细设计）如：2.1、结合设计图找出每个测试点（内部表单）2.2、结合测试方法进行细分功能点就是一个个测试集模块名称功能点测试点测试方法测试标准公告管理删除删除无允许正常的操作，错误操作给出提示信息1.3.1、其他非功能测试•界面测试•兼容性测试后台软件分：IE6.0、IE7.0、Firefox浏览器前端手机分：手机系统、手机品牌•安装测试1、文件安装是否完整2、卸载是否干净3、安装时停止，是否删除干净4、安装文件是否散乱…………………………•性能测试性能测试应该另外确定需求指标，按照需求设置具体的场景和性能参数指标1.3.2、策略附件要求•用例模板、缺陷报告模板•测试环境的搭建•缺陷管理流程和缺陷级别定义为下一阶段做好准备缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开中间会有：延期、重复、拒绝等状态缺陷管理流程1、由测试人员发现bug后，新建bug。
Bug的状态为《新建》2、测试人员直接把bug指派到相应的管理者（一般是由测试组长、项目经理等人参与bug分配）（打开）或者是在管理者那里就直接关闭bug状态就直接改为关闭3、Bug经过分配给相应的开发者手中或者是开发组长手中，测试组长能够讲该bug转移给相应的开发人员。
Bug状态不改变。
状态改为《已分配》。
（拒绝修复、延期修复等）4、测试人员在做验证时，主要关注bug状态为已修复的bug 如果bug任然存在或者导致了新的bug。
那么就《重新打开》然后新建新的bug。
如果bug修复未修复，那么就重打开5、Bug修复验证完毕，就直接关闭缺陷等级划分2、测试设计阶段在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。
然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。
每个测试用例必须包括以下几个部分：（1）标题和编号（2）测试的目标和目的（3）输入和使用的数据和操作过程（4）期望的输出结果（5）其他特殊的环境要求、次序要求、时间要求等3、测试执行阶段•当测试用例的设计和测试脚本的开发完成之后，提交测试版本、部署测试环境就开始执行测试。
•手工测试；在合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数据：对系统进行操作，比较实际结果和测试用例的所描述的期望结果，以确定系统是否正常运行或正常表现。
大多公司的测试方法，此阶段需要时间和人力•自动化测试：通过测试工具，运行测试脚本，得到测试结果。
对手工测试的管理相对要复杂得多，在整个测试执行阶段中，管理上会碰到一系列问题，主要有：•·如何确保测试环境满足测试用例所描述的要求?•·如何保证每个测试人员清楚自己的测试任务?•·如何保证每个测试用倒得到百分之百的执行?•·如何保证所报告的bug正确、描述清楚、没有漏掉信息?•·如何跟踪bug处理的进度，严重的bug及时得到解决?3.1、执行阶段操作•这时候开发就会转版本给我们测试部门进行系统测试了。
拿到版本我们首先搭建测试环境•做一个预测试，目的是来评断这个版本是不是可测试的。
如果预测试不通过，打回开发部返工，如果通过了，就开始我们第一轮的系统测试。
•第一轮系统测试我们会执行我们所编写的所有测试用例，做好测试结果的记录，发现缺陷了提交缺陷报告。
当第一轮测试结束后，我们把所有的bug单提交给开发人员，由他们进行修改。
•在他们修复bug期间，我们会对第一轮系统测试做一个测试评估，出一个测试报告。
还要根据实际情况，对我们写的测试用例进行修改和增加。
开发改bug结束，提交一个新的版本给我们，我们重新搭建测试环境开始第二轮系统测试。
首先是回归我们提交的缺陷报告，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题了继续提交缺陷报告，只到缺陷率低于用户要求了，我们就进行最后一轮的回归测试，结束系统测试。
具体测试轮次是根据版本质量和项目复杂度而决定的。
重新搭建测试环境：公司每次的产品都发布。
第二轮测试时，公司不做挑选用例，用例全部执行。
需要时间安排充足•其实预测试在公司内多为开发内部的测试（冒烟）4、测试评估阶段•执行阶段结束了进入测试评估阶段，我们会出一个总的测试报告对我们测试的这个过程和版本的质量做一个详细的评估1、需求需要评审那些？2、用例需要评审那些？3、计划应该评审那些？4、缺陷评审那些？5、bug评估？测试总结报告文档的输出：1、可以让具体的任务负责人对该本次测试中个人负责的模快进行评价，提出相关建议。
给出总体的评估2、整体上的bug按照不同等级统计出来、用例数量、用例执行数量3、对项目中测试人力资源的统计。
（单位：人/天）4、项目中软硬件资源统计。
5、提出软件总体的评价5、测试验收阶段•最后进入验收阶段，我们会出用户手册，操作指引等文档。
我们每一个阶段的输出都有一个严格的评审阶段，以确保我们每一步的输出都是有效的，保证测试的顺利进行。
一般分为alpha测试和beta测试。