软件测试管理方法（六）——软件测试执行

0.执行任务

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。测试执行活动是整个测试过程的核心环节，所有测试分析，测试设计，测试计划的结果将在测试执行中得到最终的检验。

1.测试启动评估：根据测试方案和待测试对象评估此次测试是否达到启动的条件。不同的测试目的其测试启动评估的条件不尽相同,要根据实际情况进行设置，启动条件一般会在测试计划中定义。

2.指定测试用例：根据测试的阶段、任务，选择执行全部或部分测试用例。

3.测试用例分配：将测试用例分配给测试工程师。

4.执行测试：执行测试用例，记录原始数据，及时报告发现的缺陷。

5.状态监控：根据测试执行情况以及缺陷情况，监控测试执行的进度以及遇到的问题，并及时解决测试中阻碍执行进度的相关问题。

6.及时汇报：及时向管理层汇报测试的进度、发现的主要问题等。

测试方案和待测试产品是测试执行的主要输入。核心部分是一个闭环，要根据对测试状态的监控及时调整测试策略更新测试方案：

重点关注以下三个任务：测试启动评估、测试用例分配、测试用例执行

为了确保测试顺利开展，工作量比较大的项目在测试正式启动之前要对能否启动测试进行评估，这是因为：在产品级测试过程中，测试组为了准备一个版本的测试，将投入很大的成本，包括测试环境、测试人力资源等，这种投入将随着产品特性的增加，测试环境的复杂化而不断膨胀；测试启动评估的目的不在于评估开发人员的工作绩效，而是在于控制版本在转测试时的质量，尽量减少前期不成熟的版本对测试资源的浪费；通过牺牲短期的内部控制成本（转测试评估和预测试），可以较好地避免后期浪费大量测试投入的风险。

1.评估内容

1.评估被测对象的完成程度以及质量能否达到测试启动的标准

2.根据给定的版本测试时间及测试用例分配结果，结合测试执行能力，评估本轮测试需达到的覆盖度。

3.根据覆盖度确定本轮应发现缺陷的阶段目标。

4.评估各特性用例分配情况是否合理，是否存在极不均衡现象，是否存在过度测试？是否存在部分特性无法完成测试？

5.评估测试执行计划中时间安排的合理性。

实际在开展测试评估时往往没有那么顺利，可能会遇到各种各样的问题：比如评估时的预测试投入不能太大；测试人员可能在预测试中急于投入深层次测试，指望这些问题能够把版本打回开发组；有时即使测试启动评估结果很差，迫于各方面压力仍然转入测试，结果在测试过程中被各类问题困扰，没能按照既定的测试策略做好测试覆盖。

识别此次要执行的测试用例的集合：要执行的测试用例一般包括两部分，需要测试的新增特性的用例和需要回归的特性用例。测试的执行往往并不是一次性完成的，一个测试往往包含很多次各种规模的执行，每次执行需要根据本次测试的具体情况识别出要执行的测试用例集合，其中需要回归的特性用例主要是可能受到新特性影响的特性的用例。

考虑特性之间的交互关系：各个特性之间可能存在组合、依赖关系，由于这些关系的存在，不同特性的用例在执行时可能可以合并、合作。

考虑测试用例的优先级：考虑被测试用例的优先级，优先安排执行优先级高的测试用例；考虑时间进度，平衡测试进度和测试执行质量。

测试用例的执行中要关注测试执行的质量。测试执行的主要目标是尽可能地发现产品的缺陷，而不是达到测试计划完成率，如果过于关注测试计划完成率，而不重视测试执行的质量，会导致虽然已经完成测试但是仍然不能确保产品质量，即使再进行补救，增加重复测试，不但加大了测试冗余度，还会造成整体测试进度的延迟，更严重的是会遗留掉很多本来应该发现的缺陷。因此测试用例执行过程中除了关注测试进度还要全方位观察测试用例执行结果、加强测试过程的记录、及时确认发现问题、及时更新测试用例、处理好与开发的关系促进缺陷的解决。

在测试过程中不仅关注测试用例的执行结果，还要注意在测试用例执行过程中出现的各类异常现象，如来自告警、日志、维护系统的异常信息。尽早提交缺陷报告，发现缺陷之后要及时尽早提交缺陷报告，最好是发现之后立即提交，避免在测试结束后才集中提交缺陷报告，确保开发方掌握软件质量情况并能及时解决缺陷，特别是一些可能阻碍测试的缺陷更要第一时间反馈给开发方。避免机械的执行用例，在测试执行中要多思考，如果发现测试用例不合理要及时补充或修改。

关注点：软件是否有缺陷 ；填写软件缺陷报告 ；确定造成这些缺陷的原因 ；需求、设计是否有缺陷 ；测试环境和测试部件是否有缺陷 ；测试用例设计是否不合理

2.执行监控

测试执行过程中要及时分析测试数据，全方位监控各项指标。

（0）目的

记录和管理测试用例的执行状态；根据当前的执行状态，判定测试用例的质量和执行效率；根据已发现缺陷的分布，判定结束测试的条件是否成熟；根据缺陷的数量、种类等信息评估被测软件的质量；根据缺陷的分布、修复缺陷的时间、回归测试发现的缺陷数量等评估开发过程的质量；根据计划完成情况、发现缺陷情况等信息评估测试工程师的表现

1.进度监控和控制：监控测试执行的进度与预期的偏差，及时分析原因并进行计划调整

2.用例质量监控：测试用例的有效性，能否发现关键问题等。

3.测试覆盖度监控：测试是否全面。

4.执行效率监控：测试执行的效率

5.研发质量监控：被测产品的质量如何。

测试用例执行的进度 = 已执行的数目/总数目；此数据只表明执行进度，不表示测试的成功率、为了得到更精确的进度数据，可计算测试步骤数

缺陷的存活时间 =缺陷从open到closed的时间：表明修改缺陷的效率

缺陷的趋势分析 --- 按照测试执行的时间顺序(以月、周、天为时间单位)，发现的缺陷数量的分布：如果越来越少，趋近于0，则考虑结束测试执行，相反，则说明存在以下的问题：1.代码修改引发新的缺陷 2.前一版本的测试存在覆盖率的问题，新的测试发现了原先未发现的缺陷 3.必须先修改某些缺陷后才能继续测试，然后才发现其他的缺陷

缺陷分布密度 =某项需求的总缺陷数/该项需求的测试用例总数，需要考虑缺陷的优先级和严重程度，如果过多的缺陷集中在某项需求上，可能表明以下问题：该项功能需求是否过于复杂？该项的需求设计、实现是否有问题？分配给该项的开发资源是否不足？

缺陷修改质量 = 每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷）：评价开发部门修复缺陷的质量；l如果修改某项功能后，此数值较高，测试部门应当及时通知开发部门

全方位观察测试用例执行结果、加强测试过程的记录、及时确认发现问题、及时更新测试用例、处理好与开发的关系(沟通问题)

3.执行结束

测试执行的结束：1.测试达到预期目的后，按计划结束 2.受到时间进度、资源的限制，测试被迫结束

在测试计划中明确说明测试结束的条件：Good-Enough原则？结束条件的判定是在质量和成本之间的折衷。一般在测试方案中会明确定义测试结束的条件。测试结束条件的判定是在质量和成本之间的折中。测试执行的结束有两种情况：一种是测试达到预期目的后，按计划结束；另一种是受到时间进度、资源的限制，测试被迫结束。

测试已经达到了覆盖率的要求：不同的测试要从不同的方面来评估覆盖率，比如：单元测试：从语句覆盖，代码覆盖方面来评估，例如达到100%语句覆盖。集成测试，从API、API/参数组合来评估。系统测试：从功能、用例、用例场景(Scenario)来评估，例如达到90%用例场景覆盖。

指定的时间段内没有发现新的缺陷：比如某企业规定测试结束的条件是测试用例执行完毕，连续三天的测试中没有发现严重程度为高或以上的缺陷。

基于成本的考虑而结束测试：测试执行到一定阶段时，查找未发现的缺陷的成本逐渐增大，如果超过了潜在缺陷所引起的代价，则可以停止测试；此条件不适用于要求高可靠性的软件，如武器、医学设备、财务软件等。

项目组达成一致后可以结束测试：基于技术、资金、开销等各种因素，项目组（包括管理层、开发、测试、市场销售）意见一致，认为可以停止测试。

因时间进度、资源的限制必须结束：此条件一般是为了按计划尽快发布软件，抢占市场，这种结束条件存在很大的风险，比如可能存在潜在的严重缺陷或者已知的缺陷可能还未修改。