项目测试管理--如何有效进行项目的测试交付支持部2021年8月内部公开请勿外传是指在项目交付期间，对软件系统进行测试的组织团队，标准流程，标准文档以及技能培训等一系列保证测试有效性进行的管理工作什么是项目测试管理测试管理的整体流程开始测试组织测试计划测试设计执行测试检验测试评估测试项目文档评估报告结束测试准备测试执行测试评估课程内容测试准备测试团队测试计划测试设计测试执行缺陷严重性缺陷优先级缺陷生命周期测试评估测试度量批标测试总结报告测试准备-组建测试团队项目经理测试组开发组实施顾问关键用户最终用户开发顾问测试团队能力评估无能力不具有某种测试技能，例如，不知道用例测试技术，因此无法应用该技术进行测试有能力学习了某种测试技能，但没有充分的实践过这种测试技能完全有能力不仅理解测试技能，而且还使用这种技能测试过多个程序，发现过很多问题需要有一名完全有能力的测试人员主要测试知识体系1.软件测试原则和概念软件测试的基础知识2.创建测试环境有关影响软件测试的所有条件、环境和影响因素，即测试政策、测试过程、测试工具、以及获得管理人员对软件测试的支持3.管理测试项目指软件测试相关的项目计划、人员配备、时间调度和制定预算、指派和监控工作等4.软件测试计划说明测试的目的、策略、资源、进度以及评估软件应用程序的业务风险和技术风险5.执行测试计划设计测试用例、执行测试以及监控测试所需技能6.测试状态、分析和报告如何管理测试的最新状态，并对测试状态进行分析，以及如何编制测试总结报告内部公开请勿外传测试计划是什么•测试计划描述测试活动的范围、方法、资源以及进度。并且确定被测试功能和被测试特征、测试任务、以及每个测试任务的执行人，以及与这个测试计划相关联的风险测试计划的编制周期•测试计划编写从方案阶段开始准备，到技术设计阶段结束时完成测试计划的作用•测试计划是项目管理人员，测试人员以及开发设计人员充分交流沟通的结果，有利于达到有效测试的目的•测试计划规定测试的目的、方法、步骤、进度和风险等内容，可以使测试工作进行得更加顺利•测试计划对测试工作进行了分解，明确任务分工，对测试工作的执行起到监督和控制的作用测试计划内部公开请勿外传测试计划并非只有一个，项目的不同阶段需要制定不同测试计划，根据实施方法论9.0及项目的情况，可能需要制定◼模块测试计划◼集成测试计划◼性能测试计划◼UAT测试计划测试计划的多样性内部公开请勿外传1.目的范围说明本项目测试的目的、预期达到的目标整体上确定本测试计划所涵盖的业务范围2.被测功能模块和系统特性明确本次测试计划所包括具体功能模块，或者系统特性，这些内容要以清单的形式，将作为测试设计工作的源头。3.不被测试的特性对于不再使用功能或特性，也应该在计划中列明，以避免由于沟通问题，而浪费测试资源。4.测试策略（方法）测试的总体方法。为每个主要的功能或特征指定测试方法，以保证进行充分的测试。同时有利于识别主要的测试任务以及估算每个测试的时间。5.测试出口准则定义什么时候可以停止测试。主要内容包括完整性测量、代码、功能或风险的覆盖率6.挂起准则以及重启要求挂起准则是用于暂停所有或部分测试项的测试工作的准则；重启要求是指测试挂起后，要重新开始测试必须重复的测试活动测试计划的内容内部公开请勿外传7.测试交付文档明确测试工作过程中需要准备的文档及要求，比如测试用例、测试问题记录或者测试总结报告8.测试任务识别在准备测试和执行测试必需的一组任务，这些任务通常是较高层任务，在测试设计中要细化这些任务9.环境要求描述测试工作需要测试环境特性，测试环境包括硬件环境和软件环境10.进度安排制定测试工作时间表和里程碑，以保证测试进度是可以预见的11.风险和应对计划识别测试计划中的高风险假设，并制定应变计划。如测试人缺乏经验、软件说明书不全等。测试计划的内容内部公开请勿外传测试计划要形成正式的文档，否则不能保证测试的计划性测试计划的注意事项测试计划的重点在于计划过程；即通过制定测试计划的过程，使项目负责人、开发人员和测试人员理解测试的过程计划过程文档化内部公开请勿外传测试设计是测试计划和测试执行之间的中间环节，核心就是编写测试用例细化测试方法、设计测试案例以及说明测试案例的执行过程，是实现测试的详细步骤测试设计-测试用例内部公开请勿外传避免盲目地测试，提高测试的效率，减少测试的不完整性使测试的重点突出，目的明确估算测试工作量，把握测试时间，管理测试资源和进度为分析软件缺陷和系统质量提供依据方便编写软件测试报告测试用例的主要作用内部公开请勿外传组成元素说明测试用例编号测试项目所测试的功能点所属模块测试标题对测试用例的简要说明，即测试点测试环境要求测试优先级高、中、低预置条件执行当前测试用例的前提条件输入需要输入的外部信息操作步骤执行当前测试所要经过的操作步骤预期输出预期的输出结果，用来与实际结果比较关联的测试用例测试用例一般的组成元素内部公开请勿外传1.测试用例的代表性原则•能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的，以及极限的输入数据、操作和环境设置等2.基于测试需求的原则•按照测试类别的不同要求，设计测试用例。单元测试依据详细设计说明，集成测试依据概要设计说明，系统测试依据软件和用户需求规格说明3.测试执行的可再现性原则•同样的测试用例，系统的执行结果是相同的4.测试用例的全面性原则•应尽可能覆盖程序的各种路径5.测试用例正确性原则•输入界面的数据应与测试文档所记录的数据一致，预期结果应与测试数据发生的业务相吻合测试用例设计的原则内部公开请勿外传6.基于测试方法的原则•为达到不同的测试充分性要求，应采用相应的测试方法，如等价类划分，因果图等方法7.兼顾测试充分性和效率的原则8.测试用例可操作性原则•写清楚测试的操作步骤，以及相应的操作结果9.单个用例覆盖最小化原则•一个用例一个功能点，不能同时覆盖多个功能点10.测试结果的可判定性原则•测试的执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果11.使测试结果分析和调试最简单化原则测试用例设计的原则内部公开请勿外传12.测试用例仿真性原则•人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例13.符合正常业务惯例原则•测试数据应符合用户实际工作业务流程，兼顾各种业务变化的可能测试用例设计的原则测试用例设计的思路寻找软件系统的弱点•测试用例需要确切地反映功能设计中可能存在的各种问题，而不要简单的复制需求规格设计说明书的内容设计正面的测试用例•正面的测试用例用于验证被测单元是否能够执行所要完成的工作•设计正面的测试用例应该根据关联的功能、操作路径等，参照需求规格说明书进行设计•孤立的功能则可直接按功能设计测试用例•基本事件的测试用例应包含所有需要实现的需求功能，覆盖率要达100%设计异常的、负面的测试用例•异常的测试用例用于验证软件是否执行了其不应该完成的工作•设计异常的测试用例依赖于测试设计者的经验判断可能出现问题的位置•设计异常、负面的测试用例，往往可以发现更多的软件缺陷内部公开请勿外传需求目标：功能性和非功能性目标用户环境从用户的角度及用户实际使用的场景来模拟程序的输入，包括用户的操作习惯软件文档包括软件需求分析说明书、产品设计文档，业务蓝图测试方法（白盒测试、黑盒测试）根据不同的测试方法，设计测试用例会有所不同测试对象各种不同形态的测试对象，其测试用例设计的重点不同，移动端和网页端的交互方式不同，需要设计不同的测试用例软件实现技术测试用例设计需要考虑的主要因素内部公开请勿外传1.等价划分2.边界值测试3.决策表4.因果图5.场景或用例测试6.状态转换图常用测试用例编写技术内部公开请勿外传等价划分：根据规格说明，输入域或输出域的一个子域内的任何值都能使组件或系统产生相同的响应结果等价划分的依据◼基于常识（人的年龄，体温等）◼软件需求规则说明书◼计算机内部表达数值的限制（32位最大整数）◼需要特别关注的一些值（0，空，默认值）用例技术1：等价划分内部公开请勿外传边界值测试，又称为边界值分析，基于边界值进行测试用例的设计边界值分析技术通常被认为是等价类划分技术的一种拓展等价划分和边界值分析法，通常只针对单项输入因素进行测试，没有考虑各种输入条件之间的关系和组合情况用例技术2：边界值测试内部公开请勿外传①分析需求规格说明书找到测试项②基于我们的常识、需求规格说明书规定、计算机内部可能的限制以及测试项本身的数据类型确定边界值③选择边界值、最靠近边界的合法值以及刚超过边界的非法值做为测试用例④确定输入的预期输出结果⑤进行测试⑥比较实际输出结果和预期的输出结果⑦确认被测试软件功能的正确性边界值的测试步骤内部公开请勿外传数值型数据对于实数类型的数据，根据合理的精度来确定边界值左右两边的测试输入值。字符串变量需要测试字符串的长度，以及允许的字符范围字符串的长度可以通过软件需求规格说明书来确定，或者按照2的幂次来寻找。不同类型变量的边界测试内部公开请勿外传决策表：是一种利用表格形式表达系统业务规则的工具一组输入组合及与之对应的动作形成了系统要处理的一条业务规则，在决策表中，业务规则是生成测试案例的基础决策表由条件、动作和规则3部分构成◼条件（Condition）代表软件的各种输入条件，条件的顺序与动作无关◼动作（Action）代表依据某种输入条件组合系统采取的行动◼规则（Rules）定义了唯一的条件组合以及由此引发的系统动作，即决策表中的列用例技术3：决策表测试内部公开请勿外传条件规则规则1规则2…规则P条件1条件2…条件m动作动作1动作2动作m决策表的一般形式内部公开请勿外传决策表是表达系统业务规则的良好测试工具，可以通过以下步骤进行决策表测试①通过分析软件需求规格说明书，识别系统中相互关联的输入条件②根据需求规格说明书列举出系统可能采取的各种动作③列举出输入条件的各组组合形式以及在这种组合形式下系统可能采取的行动，绘制决策表④根据决策表写出测试用例决策表测试与边界值等价划分测试进行测试的侧重点不同，决策表是从条件组合上进行测试案例的设计，而边界值分析的方法则侧重于对单个输入条件的详尽测试决策表测试方法内部公开请勿外传因果图是一种利用图解法分析和描述各种输入条件组合情况，从而设计测试用例的方法因果图由4种基本的因果关系构成◼恒等：a是1，则b为1，否则，b是0◼非：a是1，则b为0，否则，b是1◼或：abc是1，则d为1，否则，d是0◼与：a和b和c都是1，则d为1，否则，d是0用例技术4：因果图内部公开请勿外传原因之间的4种约束关系，虚线在原因左边◼互斥（Exclude）a和b和c不同时为1，最多只能有1个原因为1◼包含（Include）a、b和c三个原因中至少有一个为1，不能同时为0◼唯一（Only）：a和b和c中必须有一个，且仅有一个原因为1◼要求（Require）：a为1时，b必须为1结果之间有一种约束关系，虚线在结果的右边◼强制（Manipulate）表示a为1时，b必须为0，而当a为0时，b的值不定因果图-约束关系内部公开请勿外传①将规格说明书分解成小的片断，尽量使输入条件是独立的项②识别出规格说明书中的原因和结果。原因是输入条件，而结果是输出条件，给每一个原因和结果分配一个编号③分析规格说明的语义并将其转换为布尔形式表达的因果图。为了表达上的方便，可以引入中间结果来连接输入条件和输出结果④给因果图的原因和结果加上约束条件⑤跟踪因果图上描述的条件，然后将其转换为有限入口的决策表。⑥把决策表的列转换为测试案例因果图测试方法步骤内部公开请勿外传当输入条件和输出结果变得很多时，因果图将变得复杂，可能并不容易绘制在绘制完因果图后把因果图转换为决策表，以便得到最后的测试案例对于多因素的输入条件组合，可以直接使用决策表来生成测试用便，而不一定绘制因果图因果图测试方法注意事项内部公开请勿外传场景（Scenario）是用户具体使用软件时的一个情景片断用例（UseCase）是面向对象的UML设计中用来表达用户需求的一种手段，可以把用例定义为用户与系统之间的一次交互。实际上，用例也是使用软件的一个场景，只是在特定的设计方法中被称为用例。基于场景的测试方法（TestingBasedonScenario）就是设计各种测试场景来反映软件系统在现实中的典型应用、极端应用等应用情况，从而从实际使用的角度来测试软件场景测试就是要让系统在各种真实的环境下进行试用用例技术5：场景或用例测试内部公开请勿外传场景和用例描述了系统最可能使用的过程流，因此从场景或用例中得到的测试用例，是发现系统实际使用环境中存在缺陷的最有用的方式场景有助于设计用户参与的验收测试，也可以帮助发现由于不同组件之间的相互作用和相互影响而产生的集成缺陷。场景或用例测试重要性内部公开请勿外传每个场景都有测试前提条件，这是测试用例成功执行的必要条件每个场景结束后都存在后续条件，这是在测试用例执行完成后能观察到的结果和系统的最后状态场景测试通常在软件的系统和确认测试阶段进行场景测试用例特点内部公开请勿外传状态图（StatechartDiagram）用来描述一个特定对象基于事件反映的动态行为，显示该对象如何根据当前所处的状态对不同的事件作出反应用例技术6：状态转换图测试内部公开请勿外传序号项目说明1源状态转换所影响的状态，将发生变化的状态；转换只由源状态处理2触发事件能够引起转换发生的事件称为触发器3监护条件一种布尔表达式，在源状态接受到触发器事件后，将对表达式进行求值，如果为真则发生转换，为假不转换4动作可执行的，不可分割的计算过程5目标状态在完成转换后被激活的状态状态转换的五个要素内部公开请勿外传状态转换本身是一个软件的使用场景。利用状态图进行测试用例的生成，需要考虑到系统变换的前提条件和后果，还需要对系统的各种状态变换进行测试，达到更高的覆盖率。状态转换图测试可以看做是一个更加完整的场景测试。状态转换图测试内部公开请勿外传①绘制出系统的状态转换图②访问每个状态③覆盖每个转换④确保没有状态是不可抵达或者不可离开的状态转换图测试步骤测试用例管理编写评审修改版本控制升级维护测试用例评审形式•内部评审•外部评审测试用例评审的要点•覆盖率高•正向全面，反向有创造性•易用性•易读性•易维护性课程内容测试准备测试团队测试计划测试设计测试执行缺陷严重性缺陷优先级缺陷生命周期测试评估测试度量批标测试总结报告测试执行基本流程开始构建测试环境执行测试记录测试过程提交缺陷修复缺陷测试记录结束缺陷？测试用例所有用例通过？内部公开请勿外传软件缺陷的生命周期缺陷的严重性和优先级只有对缺陷进行深入细致的管理，测试的意义才能充分体现出来软件缺陷的属性软件缺陷生命周期序号状态描述1打开测试人员发现软件缺陷并在相应的记录系统中登记了该缺陷。此时国，软件缺陷被告知程序员进行修复2解决程序员修复了软件缺陷并在相应的记录系统中说明了缺陷缺陷修复。此时，软件缺陷被交给测试人员进行重新测试以确认修复3关闭测试人员重新测试确认软件缺陷已经被修复并在记录系统中登记。此时，该缺陷消失，生命结束。4审查这是一个附加状态。是指测试人员打开软件缺陷后，交由缺陷管理委员会决定该缺陷是否应该修复的状态，在确定之前并不交由程序员修改5推迟这是一个附加状态。是指缺陷管理委员会审查后认为该软件缺陷可以在软件的下一个版本中修复，在该版本中不修复的状态软件缺陷生命周期-简单模式VS通用模式开始打开推迟评审解决关闭结束开始打开解决关闭结束内部公开请勿外传序号严重级别描述1致命系统主要功能完全丧失，比如系统崩溃、数据丢失、数据损毁2严重系统主要功能部分丧失，比如操作错误、结果错误、功能遗漏3一般系统次要功能部分丧失，比如错别字、系统布局不合理，罕见故障4轻微不影响系统的正常使用，可能是操作的不方便，改进建议等缺陷的严重性分级内部公开请勿外传序号优先级别描述1紧急立即修复，阻止进一步测试2高在产品发布前必须修复3中如果时间允许修复4低可能会修复，但也可能会放弃修复缺陷的优先级缺陷管理系统【项目缺陷管理系统】以项目为中心，拉通客户、实施、开发、服务，从项目交付开始，提供项目汇报、需求管理、缺陷管理、文档管理等功能，保障项目稳步推进，简化项目运维，推动客户持续经营。【访问路径】https://vip.kingdee.com/school/defect课程内容测试准备测试团队测试计划测试设计测试执行缺陷严重性缺陷优先级缺陷生命周期测试评估测试度量批标测试总结报告内部公开请勿外传基本代码的测试覆盖◼代码测试覆盖率=已测试代码行数/计划测试的代码行数基于需求的测试覆盖◼计划的测试覆盖程度=计划测试用例数/测试需求用例总数◼已实施的测试的覆盖程度=已执行的测试用例数/计划测试用例数◼成功的测试的覆盖程度=测试通过的用例数/计划测试用例数测试评估指标-覆盖评估内部公开请勿外传缺陷发现率（DefectDiscoveryRate)：是指平均每天发现的软件缺陷数与测试时间的关系软件缺陷密度（SoftwareDefectDesity）：是指千行代码量所引入的软件缺陷个数。通常而言，要求每千行代码的缺陷数小于3。分模块的缺陷密度可以用于评价各个模块的质量。另外缺陷严重程度的分布也是评价软件质量的重要度量指标软件缺陷发现、修复和关闭关系图软件缺陷发现速率已经降低到一个很低的水平，保持稳定，并且累积打开的软件缺陷已经基本全部关闭，则说明该软件的测试工作可以结束，软件可以发布了。R1：待修复，整体软件缺陷的累积及消除率是指软件发布前后累积缺陷数，以及发布前缺陷占总缺陷数的比率测试评估指标-质量评估内部公开请勿外传编写目的本测试报告的具体编写目的，指出预期的读者范围项目背景对项目目标和目的进行简要说明。测试环境简要介绍测试环境及其配置测试执行情况与记录描述测试资源消耗情况，可列出简单组织架构，参与测试人员，以及时间跨度和工作量，最好区分开的测试文档和测试活动的时间，个人和整体投入的时间和整体时间软件测试总结报告内部公开请勿外传测试覆盖情况分析从需求覆盖和用例覆盖两个角度统计。需求覆盖可以以表格形式反映。缺陷统计分析对缺陷情况从严重程度、缺陷类型（界面、一致性、功能、算法、接口等）、所属功能模块等不同角度进行分析，可以结合缺陷的饼状图或柱状图残留缺陷与未解决问题列出残留缺陷和未解决问题，并给出对发版的可能会造成什么样的影响测试结论测试目标是否完成，测试执行是否充分，对测试风险的控制措施和成效，测试是否通过，是否可以发版建议就系统上线运行的可能潜在缺陷和后续工作，以及产品开发设计方面提供建议。软件测试总结报告Thanksterimakasih感謝谢谢ありがとうขอบคุณ内部公开请勿外传55没有金蝶软件国际软件集团有限公司的特别许可，任何人不能以任何形式或为任何目的复制或传播本文档的任何部分。本文档中包含的信息如有更改，恕不另行通知。由金蝶软件（中国）有限公司和其分销商所销售的某些软件产品包含有其它软件供应商的软件组件。Microsoft®、WINDOWS®、NT®、EXCEL®、Word®、PowerPoint®和SQLServer®是微软公司的注册商标。IBM®、DB2®、DB2通用数据库、OS/2®、ParallelSysplex®、MVS/ESA、AIX®、S/390®、AS/400®、OS/390®、OS/400®、iSeries、pSeries、xSeries、zSeries、z/OS、AFP、IntelligentMiner、WebSphere®、Netfinity®、Tivoli®、Informix和Informix®动态ServerTM是国际商业机器公司在美国或其他公司的商标。ORACLE®是ORACLE公司的注商标。UNIX®是UNIXINTERNATIONALCO.,LID的注册商标、OSF/1®和Motif®是OpenGroup的注册商标。Citrix®、Citrix徽标、ICA、ProgramNeighborhood®、MetaFrame®、WinFrame®、VideoFrame®、MultiWin®以及此处引用的Citrix产品名是CitrixSystems公司的商标或注册商标。HTML是HATEMOGLUTEKSTILGIYIMSANAYIVETICARETA.S.的注册商标，DHTML、XML和XHTML是W3C®、WorldWideWeb协会、计算机科学实验室的商标或注册商标，PureXML是国际商业机器公司的注册商标。JAVA®是甲骨文美国有限公司的注册商标。JAVASCRIPT®是甲骨文美国有限公司的注册商标，由其技术开发和实施商Netscape许可使用。Apusic®是深圳市金蝶中间件有限公司的注册商标。本文档提到的金蝶®、金蝶KIS®、K/3®、金蝶EAS®、友商网®和其它金蝶产品和服务以及它们各自的徽标是金蝶软件（中国）有限公司在中国和世界其它一些国家的商标或注册商标。本文档提到的所有其它产品和服务名称是它们各自公司的商标。特别申明
