7.1软件测试执行管理

软件测试执行和报告软件测试执行管理1了解测试执行的主要任务。了解测试执行中的监控要点。学习目标23测试执行的任务测试执行的监控测试执行的结束软件测试执行的任务145测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。测试执行活动是整个测试过程的核心环节，所有测试分析，测试设计，测试计划的结果将在测试执行中得到最终的检验。软件测试执行6测试启动评估：根据测试方案和待测试对象评估此次测试是否达到启动的条件。不同的测试目的其测试启动评估的条件不尽相同,要根据实际情况进行设置，启动条件一般会在测试计划中定义。指定测试用例：根据测试的阶段、任务，选择执行全部或部分测试用例。测试用例分配：将测试用例分配给测试工程师。执行测试：执行测试用例，记录原始数据，及时报告发现的缺陷。状态监控：根据测试执行情况以及缺陷情况，监控测试执行的进度以及遇到的问题，并及时解决测试中阻碍执行进度的相关问题。及时汇报：及时向管理层汇报测试的进度、发现的主要问题等。测试执行的主要任务7测试方案和待测试产品是测试执行的主要输入。核心部分是一个闭环，要根据对测试状态的监控及时调整测试策略更新测试方案。测试执行的输入以及核心环节8重点关注以下三个任务：测试启动评估测试用例分配测试用例执行重点关注的任务9为了确保测试顺利开展，工作量比较大的项目在测试正式启动之前要对能否启动测试进行评估，这是因为：在产品级测试过程中，测试组为了准备一个版本的测试，将投入很大的成本，包括测试环境、测试人力资源等，这种投入将随着产品特性的增加，测试环境的复杂化而不断膨胀；测试启动评估的目的不在于评估开发人员的工作绩效，而是在于控制版本在转测试时的质量，尽量减少前期不成熟的版本对测试资源的浪费；通过牺牲短期的内部控制成本（转测试评估和预测试），可以较好地避免后期浪费大量测试投入的风险。测试启动评估-原因10评估被测对象的完成程度以及质量能否达到测试启动的标准根据给定的版本测试时间及测试用例分配结果，结合测试执行能力，评估本轮测试需达到的覆盖度。根据覆盖度确定本轮应发现缺陷的阶段目标。评估各特性用例分配情况是否合理，是否存在极不均衡现象，是否存在过度测试？是否存在部分特性无法完成测试？评估测试执行计划中时间安排的合理性。测试启动评估-评估的一般内容11某企业某产品系统测试启动标准测试启动评估-样例12实际在开展测试评估时往往没有那么顺利，可能会遇到各种各样的问题：比如评估时的预测试投入不能太大；测试人员可能在预测试中急于投入深层次测试，指望这些问题能够把版本打回开发组；有时即使测试启动评估结果很差，迫于各方面压力仍然转入测试，结果在测试过程中被各类问题困扰，没能按照既定的测试策略做好测试覆盖。测试启动评估-可能遇到的问题13识别此次要执行的测试用例的集合要执行的测试用例一般包括两部分，需要测试的新增特性的用例和需要回归的特性用例。测试的执行往往并不是一次性完成的，一个测试往往包含很多次各种规模的执行，每次执行需要根据本次测试的具体情况识别出要执行的测试用例集合，其中需要回归的特性用例主要是可能受到新特性影响的特性的用例。考虑特性之间的交互关系各个特性之间可能存在组合、依赖关系，由于这些关系的存在，不同特性的用例在执行时可能可以合并、合作。考虑测试用例的优先级考虑被测试用例的优先级，优先安排执行优先级高的测试用例；考虑时间进度，平衡测试进度和测试执行质量。测试用例分配14测试用例的执行中要关注测试执行的质量。测试执行的主要目标是尽可能地发现产品的缺陷，而不是达到测试计划完成率，如果过于关注测试计划完成率，而不重视测试执行的质量，会导致虽然已经完成测试但是仍然不能确保产品质量，即使再进行补救，增加重复测试，不但加大了测试冗余度，还会造成整体测试进度的延迟，更严重的是会遗留掉很多本来应该发现的缺陷。因此测试用例执行过程中除了关注测试进度还要全方位观察测试用例执行结果、加强测试过程的记录、及时确认发现问题、及时更新测试用例、处理好与开发的关系促进缺陷的解决。测试用例的执行-除了效率还要关注质量15等待执行状态：测试用例等待执行。阻塞状态：由于其他原因导致测试用例暂时不能执行，比如某个功能模块不能启动，则该功能模块所有用例被阻塞，管理员账号登录失败则所有管理员权限用例被阻塞。正在执行：测试用例正在执行中。执行通过：测试用例执行通过。执行失败：测试用例执行失败，此时要提交相应的缺陷。免执行：表示本次测试不执行该测试用例。测试用例执行-状态16测试用例执行-状态图17在测试过程中不仅关注测试用例的执行结果，还要注意在测试用例执行过程中出现的各类异常现象，如来自告警、日志、维护系统的异常信息。尽早提交缺陷报告，发现缺陷之后要及时尽早提交缺陷报告，最好是发现之后立即提交，避免在测试结束后才集中提交缺陷报告，确保开发方掌握软件质量情况并能及时解决缺陷，特别是一些可能阻碍测试的缺陷更要第一时间反馈给开发方。避免机械的执行用例，在测试执行中要多思考，如果发现测试用例不合理要及时补充或修改。测试用例的执行-提高执行质量的方法18软件是否有缺陷填写软件缺陷报告确定造成这些缺陷的原因需求、设计是否有缺陷测试环境和测试部件是否有缺陷测试用例设计是否不合理测试用例执行过程关注点软件测试执行的监控21920测试执行过程中要及时分析测试数据，全方位监控各项指标。测试执行的监控21记录和管理测试用例的执行状态根据当前的执行状态，判定测试用例的质量和执行效率根据已发现缺陷的分布，判定结束测试的条件是否成熟根据缺陷的数量、种类等信息评估被测软件的质量根据缺陷的分布、修复缺陷的时间、回归测试发现的缺陷数量等评估开发过程的质量根据计划完成情况、发现缺陷情况等信息评估测试工程师的表现测试执行监控的目的22测试执行监控的五个方面测试执行监控控制进度测试覆盖度研发质量执行效率用例质量23进度监控和控制：监控测试执行的进度与预期的偏差，及时分析原因并进行计划调整。用例质量监控：测试用例的有效性，能否发现关键问题等。测试覆盖度监控：测试是否全面。执行效率监控：测试执行的效率。研发质量监控：被测产品的质量如何。测试执行监控的主要内容24针对测试监控的五个内容，有多个具体的监控指标，测试团队要根据实际情况明确需要重点监控的数据。常见监控指标举例：测试用例执行的进度=已执行的数目/总数目缺陷的存活时间=缺陷从打开到关闭的时间(或者从发现到解决的时间)缺陷的趋势分析，按照测试执行的时间顺序(以月、周、天为时间单位)，发现的缺陷数量的分布缺陷分布密度=某项需求的总缺陷数/该项需求的测试用例总数(或者功能点总数)缺陷修改质量=每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷）测试执行监控的主要指标25测试用例执行的进度=已执行的数目/总数目此数据只表明执行进度，不表示测试的成功率为了得到更精确的进度数据，可计算测试步骤数缺陷的存活时间=缺陷从open到closed的时间表明修改缺陷的效率缺陷的趋势分析---按照测试执行的时间顺序(以月、周、天为时间单位)，发现的缺陷数量的分布如果越来越少，趋近于0，则考虑结束测试执行相反，则说明存在以下的问题：代码修改引发新的缺陷前一版本的测试存在覆盖率的问题，新的测试发现了原先未发现的缺陷必须先修改某些缺陷后才能继续测试，然后才发现其他的缺陷测试监控的指标126缺陷分布密度=某项需求的总缺陷数/该项需求的测试用例总数需要考虑缺陷的优先级和严重程度如果过多的缺陷集中在某项需求上，可能表明以下问题：该项功能需求是否过于复杂？该项的需求设计、实现是否有问题？分配给该项的开发资源是否不足？……缺陷修改质量=每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷）评价开发部门修复缺陷的质量如果修改某项功能后，此数值较高，测试部门应当及时通知开发部门测试监控的指标227全方位观察测试用例执行结果加强测试过程的记录及时确认发现问题及时更新测试用例处理好与开发的关系(沟通问题)……测试执行阶段注意事项软件测试执行的结束32829测试执行的结束测试达到预期目的后，按计划结束受到时间进度、资源的限制，测试被迫结束在测试计划中明确说明测试结束的条件Good-Enough原则？结束条件的判定是在质量和成本之间的折衷测试执行的结束30一般在测试方案中会明确定义测试结束的条件。测试结束条件的判定是在质量和成本之间的折中。测试执行的结束有两种情况：一种是测试达到预期目的后，按计划结束；一种是受到时间进度、资源的限制，测试被迫结束。测试执行结束的两种情况31测试已经达到了覆盖率的要求不同的测试要从不同的方面来评估覆盖率，比如：单元测试：从语句覆盖，代码覆盖方面来评估，例如达到100%语句覆盖。集成测试，从API、API/参数组合来评估。系统测试：从功能、用例、用例场景(Scenario)来评估，例如达到90%用例场景覆盖。指定的时间段内没有发现新的缺陷比如某企业规定测试结束的条件是测试用例执行完毕，连续三天的测试中没有发现严重程度为高或以上的缺陷。测试执行结束可能的条件132基于成本的考虑而结束测试测试执行到一定阶段时，查找未发现的缺陷的成本逐渐增大，如果超过了潜在缺陷所引起的代价，则可以停止测试。此条件不适用于要求高可靠性的软件，如武器、医学设备、财务软件等。