软件系统测试方案

软件/信息系统测试方案目录TOC\o"1-5"\h\z\o"CurrentDocument"引言 5\o"CurrentDocument"编写目的 5\o"CurrentDocument"适用范围 5\o"CurrentDocument"参考资料 5\o"CurrentDocument"参加与测试相关的评审 6\o"CurrentDocument"2.1.参加评审的目的 6\o"CurrentDocument"岗位与职责 6\o"CurrentDocument"2.2.1项目经理 6\o"CurrentDocument"2.2.2事业部测试组长 6\o"CurrentDocument"2.2.3项目管理部测试组组长 72.2.4入口、出口条件 7\o"CurrentDocument"2.2.5可测试的特征 7\o"CurrentDocument"制定测试计划 8\o"CurrentDocument"3.1制定测试计划的目的 8\o"CurrentDocument"3.2岗位与职责 8\o"CurrentDocument"3.2.1项目经理 8\o"CurrentDocument"3..2.2事业部测试组长 8\o"CurrentDocument"3.2.3项目管理部测试组组长 8\o"CurrentDocument"3.3入口、出口条件 8\o"CurrentDocument"3.4编写测试计划 9\o"CurrentDocument"3.5编写测试用例 9\o"CurrentDocument"3.6编写测试用例的目的 9\o"CurrentDocument"3.7岗位与职责 9\o"CurrentDocument"3.7.1开发组 9\o"CurrentDocument"3.7.2事业部测试组 9\o"CurrentDocument"3.7.3项目管理部测试组 93.7.4入口与出口条件 9\o"CurrentDocument"3.8如何编写测试用例 103.8.1测试用例覆盖准则 10\o"CurrentDocument"3.8.2测试用例的选择 10\o"CurrentDocument"3.8.3白盒测试案例的设计 113.8.4语句覆盖 113.8.5分支覆盖 113.8.6逻辑覆盖： 11\o"CurrentDocument"3.8.7条件覆盖 113.8.8条件/分支覆盖 11\o"CurrentDocument"3.9获取测试用例的方式 12\o"CurrentDocument"3.9.1.1等价类划分 12\o"CurrentDocument"3.9.1.2边界值分析 13\o"CurrentDocument"3.9.1.3错误推测 13\o"CurrentDocument"3.9.1.4因果图法 13\o"CurrentDocument"3.10评审测试案例 14\o"CurrentDocument"3.11参考内容 14\o"CurrentDocument"4、单元测试 14\o"CurrentDocument"4.1单元测试目的 14\o"CurrentDocument"4.2岗位与职责 14\o"CurrentDocument"4.2.1项目经理 14\o"CurrentDocument"4.2.2单元测试负责人 14\o"CurrentDocument"4.2.3单元测试人员 14\o"CurrentDocument"4.2.4开发小组 144.2.5入口、出口条件 15\o"CurrentDocument"5.3单元测试方法 15\o"CurrentDocument"5.4单元测试检查单 15\o"CurrentDocument"5.5单元测试的流程 15\o"CurrentDocument"6参考内容 16\o"CurrentDocument"7组装测试 16\o"CurrentDocument"7.1组装测试目的 16\o"CurrentDocument"7.2岗位与职责 17\o"CurrentDocument"7.2.1项目经理 17\o"CurrentDocument"组装测试负责人 17\o"CurrentDocument"组装测试人员 17\o"CurrentDocument"开发小组 17入口与出口条件 17\o"CurrentDocument"组装测试方法 18\o"CurrentDocument"一次性组装; 18增量式组装 18\o"CurrentDocument"自顶向下 18\o"CurrentDocument"自底向上; 19组装测试流程： 19\o"CurrentDocument"8验收测试 19\o"CurrentDocument"验收测试的目的 19\o"CurrentDocument"岗位与职责 20\o"CurrentDocument"项目经理 20\o"CurrentDocument"验收测试负责人 208.2.4验收测试人员 20\o"CurrentDocument"开发小组 20入口与出口条件 20\o"CurrentDocument"验收测试步骤 20\o"CurrentDocument"9参考资料 221引言编写目的软件测试是软件生命周期的重要环节，也是软件质量保证的主要活动。测试方案是规范测试流程、指导测试活动的标准。主要针对测试管理人员、测试设计和执行人员及质量保证人员在测试活动时参照执行。适用范围本规程用于朝阳区网格化信息管理系统的所有测试活动。参考资料《软件项目计划规程》《评审规程》软件测试的定义什么是软件测试测试：是通过分析和执行程序发现软件不满足质量要求的缺陷的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。软件测试的目的目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试用例是发现了至今未发现的错误。软件测试的原则应当尽早地和不断地进行软件测试。测试用例应当由测试输入数据和与之对应的预期输出结果这两部分组成。程序员应避免检查自己的程序。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。充分注意测试中的群集现象。严格执行测试计划，排除测试的随意性。应当对每一个测试结果做全面检查。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便测试与软件开发各阶段的关。2参加与测试相关的评审2.1.参加评审的目的1、有利于采用最优的方案和技术。2、避免错误的发生。岗位与职责项目经理指定单元测试的负责人参加《详细设计说明书》的评审事业部测试组长指定集成测试的负责人参加《概要设计说明书》的评审2.2.3项目管理部测试组组长指定系统测试的负责人参加《需求规格说明书》的评审2.2.4入口、出口条件阶段入口条件活动内容出口条件需求设计相关行业知识参加《需求规格说明书》的评审需求中相关可测试性的内容经过评审并得到批准概要设计《需求规格说明书》参加《概要设计说明书》的评审设计中相关可测试性的内容经过评审并得到批准详细设计《需求规格说明书》《软件概要设计说明书》参加《详细设计说明书》的评审设计中相关可测试性的内容经过评审并得到批准2.2.5可测试的特征1） 是否规定了测试标准？根据该标准，能否充分地保证质量？这些标准能否规定具体的测试内容。2） 是否明确设计规格和测试规格之间的对应关系3） 功能的完整性4） 性能;5） 可用性;6） 可靠性,有效性,有用性（适用性）;7） 兼容性（如,代码可容易的从一个平台到另一平台的移植）;8） 可维护性（如,可修复和容易地作较小修改）;9）可扩充性（如，可做出较大地增量补充且不引起主要地重写）；3制定测试计划制定测试计划的目的制订一个合理计划，作为管理和执行软件项目测试的活动的基础岗位与职责项目经理制定《单元测试计划》。评价测试方法和工具。关注各级测试的入口出口准则。3..2.2事业部测试组长制定《组装测试计划》。项目管理部测试组组长制定《验收测试计划》。入口、出口条件阶段入口条件活动内容出口条件需求设计1.《需求规格说明书》经过评审并得到批准；2•项目计划已经完成；制定《验收测试计划》《验收测试计划》经过评审并得到批准；概要设计《概要设计说明书》经过评审并得到批准；制定《组装测试计划》《组装测试计划》经过评审并得到批准；《详细设计说明书》《单元测试计详细设计经过评审并得到批制定《单元测试计划》划》经过评审并准；得到批准；编写测试计划测试计划应依据项目经理在《项目总体计划》和《项目开发计划》中对测试活动给出的时间计划。规定测试活动的任务、测试方法、进度、资源、人员职责等编写测试计划应遵循《测试计划模版》评审测试计划，参考《评审规程》编写测试用例编写测试用例的目的导出有可能发现软件错误的测试集。岗位与职责开发组由执行单元测试的人员负责编写《单元测试案例》。事业部测试组由执行组装测试的人员负责编写《组装测试案例》，与接口有关的案例由设计人员编写。项目管理部测试组由执行验收测试的人员负责编写《验收测试案例》，与结构有关的案例由系统分析人员编写。入口与出口条件阶段入口条件活动内容出口条件

需求设计《需求规格说明书》《验收测试计划》经过评审并得到批准编写《验收测试案例》《验收测试案例》经过评审并得到批准。概要设计《概要设计说明书》《组装测试计划》经过评审并得到批准编写《组装测试案例》《组装测试案例》经过评审并得到批准。详细设计《详细设计说明书》《单元测试计划》经过评审并得到批准编写《单兀测试案例》《单兀测试案例》经过评审并得到批准。如何编写测试用例测试用例覆盖准则测试级别覆盖准则测试方法设计目标单元测试覆盖代码白盒测试语句覆盖、分支覆盖率要达到100%；组装测试覆盖设计白盒、黑盒测试Top-down、bottom-up或outside-in100%执行概要设计说明书驱动的所有接口。验收测试覆盖需求黑盒测试100%执行需求规格说明驱动的所有功能测试用例的选择测试用例的选择应该满足:发现错误可能性大的输入数据或操作被测程序的执行结果应该是可判定的测试的执行过程和结果是可以再现的

白盒测试案例的设计语句覆盖按照设计的测试用例，执行测试，保证每一可执行语句至少执行一次。分支覆盖按照设计的测试用例，执行测试，使得程序中每个判断的取真分支和取假分支至少经历一次。逻辑覆盖：条件覆盖在测试时，设计若干测试用例，运行被测程序，使程序中的每个条件的可能取值至少满足一次。条件/分支覆盖在测试时，设计足够的测试用例，使得判断中每个条件的所有可能取值至少出现一次，并且每个判断本身的判定结果也至少出现一次。如下图所示：所有四条路径可以表示为:Ll(ace)、L2(abd)、L3(abe)、L4(acd)。aa获取测试用例的方式1） 通过非路径分析得到的测试用例；2） 找到尚未测试过的路径并生成相应的测试用例3） 指定特定路径生成相应的测试用例；黑盒测试案例的设计；等价类划分等价类划分法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例，即在输入数据时按合理和不合理划分成若干个等价类，相同的一类数据中选择一个作为测试用例。第一步：从开发部门提交的需求说明书中找出每一个输入条件（通常是一句话或一个短语），然后为每一个输入条件划分出多个等价类，这是测试工作的重要基础。第二步：确定测试用例，将等价类编号，必须覆盖所有等价类，不能出现相同测试用例。经验参考：1）如果输入条件规定了取值范围或值的个数，则可以确立一个有效等价类（即该输入条件的取值范围或值的个数）和两个无效等价类（即大于和小于该范围或该个数的那些取值）。2）如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，这时可确立一个有效等价类。3）如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。4）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，这时可为每个输入值确立一个有效等价类，此外针对所有不允许的输入的集合确立一个无效等价类。5）如果规定了输入数据必须遵守的规定，则可以确立一个有效等价类（符合规则的等价类）和若干无效等价类（从不同角度违反了规则的那些等价类）。如果确知已划分的等价类中各个元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。3.9.1.2边界值分析实践表明往往在处理边界情况时容易发生错误。在等价类之间或其他边缘处设计测试用例并将其编号制表。这是经常使用的高效做法。1） 如果输入条件规定了值的范围，则应选取刚刚达到这个范围的边界值以及刚刚超越这个范围的边界值作为测试输入数据。例如，输入值的范围是-1.0〜1.0,则可选取-1.0、1.0、-1.001和1.001作为输入数据。2） 如果输入条件规定了值的个数，则用最大个数，最小个数，比最大个数多1，比最小个数少1的数作为测试数据。例如，某个文件有1〜255个记录，则可选取1个记录、255个记录、0个记录和256个记录的输入文件作为输入数据。3） 如果程序的规格说明书给出的输入域或输出值域是有序集合（如有序表、顺序文件等），则应选取集合的第一个元素和最后一个元素作为测试用例。4） 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值作为测试用例。例如，在程序中定义的数组下界为0，上界为100，则应选取0和100作为测试用例。3.9.1.3错误推测这是一种需要测试经验和直觉的测试方法，有针对性的设计测试用例。先将可能出现的错误列表，在选择测试用例。例如：在测试医疗MIS时可考虑到1）药库为空。2）同步操作。3）倒序操作。所以要具体情况具体分析。3.9.1.4因果图法1） 分析软件规格说明书中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。2） 分析软件规格说明书中的语义，找出原因与结果之间以及原因与原因之间的对应关系，根据这些关系画出因果图。由于语法或环境的限制，有些原因与结果之间或原因与原因之间的组合情况不可能出现，则可在因果图上用一些记号标明这些约束或限制条件。把因果图转换成判定表。把判定表的每一列所表示的情况生成测试用例。评审测试案例参考《评审规程》参考内容《测试案例模板》4、单元测试单元测试目的单元测试又称模块测试，是针对软件设计的最小单元一一程序模块，目的在于发现各模块内部可能存在的各种差错。岗位与职责项目经理分析测试度量数据，确保测试得以充分执行；关注缺陷的解决过程。单元测试负责人由《单元测试计划》中指定的负责人负责单元测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量方法》产生测试度量数据；单元测试人员由《组装测试计划》中指定的测试人员执行单元测试并记录跟踪测试中发现的问题。开发小组负责解决测试过程中发现的问题；4.2.5入口、出口条件阶段入口条件活动出口条件单元测试《单元测试计划和测试用例》得到批准；模块编码已经完成并通过了代码同行评审按照单元测试计划，交叉执行单兀测试案例。100%代码语句和分支覆盖《单元测试分析报告》完成；《测试问题跟踪记录表》产生与解决；测试通过审核人的批准以及项目经理的签发；5.3单元测试方法单元测试采用白盒测试技术。5.4单元测试检查单执行单元测试时依据此检查单来检查测试的充分性：逻辑和算法：正确实现了逻辑和算法数据结构（全局和局部）：使用了全局数据结构？哪些？如果有，作了哪些关于全局数据的假设？这些假设正确吗？使用了局部数据？在算法执行的所有步骤期间，保持局部数据的完整性了吗？接口：来自调用模块的数据匹配被调用的模块的期望接收的数据？被调用模块的数据匹配调用的模块提供的数据？独立路径：标识了所有穿过模块的独立路径？执行了吗？边界条件：了解边界条件吗？进行了测试确保该模块在其边界条件上的适当的操作了吗？出错处理：所有出错处理路径均执行到了吗？5.5单元测试的流程1）满足以下任何条件的所有的单元、模块、组件都要进行单元测试：>被修改的代码或者新开发的代码，也就是说没有修改的代码不需要做单元测试；>跨多个项目使用的模块，如：对公用的模块进行单元测试以确保其满足多个项目的特殊需求；>测试经理可以对上面的条件进行增加；测试人员依照《单元测试计划》和《单元测试案例》进行单元测试；单元测试负责人确保《单元测试计划》和《单元测试案例》是经过评审并得到批准的；当测试用例的测试结果与预期值存在偏差时，测试者记录下实际结果；测试者使用Bug管理系统记录跟踪所有发现的问题，单元测试负责人每天测试工作后必须备份当天的测试记录。开发组人员对问题进行技术评审，由技术负责人进行确认；如属于程序问题时，开发人员直接进行修改；如属于设计问题，则遵从《变更规程》进行修改；当修改软件以纠正发现的问题时，测试者需要进行回归测试以保证这些修改没有带来新的问题；当《单元测试计划》和《单元测试用例》中定义的出口条件得到满足时，单元测试完成；单元测试阶段完成时，单元测试负责人提交《单元测试总结报告》；参考内容《测试总结报告模版》组装测试7.1组装测试目的组装测试也叫做集成测试或联合测试，组装测试目的试图发现模块间接口缺陷。单元测试后还需要进行组装测试的原因：一个模块可影响其它模块。当结合了子功能后，没导致主要的功能的出现。个别的可接受的不精确的计算被扩大到不可接受的范围。在单元测试未被检查的接口错误可能出现。时间问题（实时系统）在单元测试中不可检查出。单元测试不能检查资源争夺问题。岗位与职责项目经理分析测试度量数据，确保测试得以充分执行；组装测试负责人由《组装测试计划》中指定的负责人负责组装测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量过程》产生测试度量数据；组装测试人员由《组装测试计划》中指定的测试人员执行组装测试并记录跟踪测试中发现的问题。开发小组负责解决测试过程中发现的问题；入口与出口条件阶段入口条件活动出口条件组装测试《组装测试计划和测试用例》得到批准；单元测试通过审核人的批准以及测试经理的签发；100%正确的执行代码语句和分支覆盖按照组装测试计划，交叉执行组装测试案例。《组装测试总结报告》完成；《测试问题跟踪记录表》产生与解决；测试通过审核人的批准以及事业部测试组长的签发；组装测试方法一次性组装;使用一步到位的方法来构造程序，所有模块都预先组装在一起，作为一个整体来测试。增量式组装自顶向下用主控模块作为驱动模块，用所有的模块代替桩模块，直接地从属于主模块。取决于所选的集成方法(先深度或先宽度)，在一次集成中用模块替代次桩。随着集成每个模块来运行测试。在成功的完成了一个测试集的基础上，用一个实际的模块代替另一个桩。执行回归测试确保不会由于新的模块集成产生错误。重复第2步〜第5步，直到整个程序集成完毕。自底向上;从底层模块开始集成，合并到集成clusters或builds执行一个指定的软件子功能。写驱动程序(开发作为桩的控制程序)来协调测试用例的输入和输出。测试这个集成clusters。去掉这个驱动程序且合并这个集成clusters，移到程序结构的上一级组装测试流程：单元测试通过后项目经理提交正式的组装测试申请给事业部测试组长。组装测试负责人确保《组装测试计划》和《组装测试用例》是经过评审并得到批准的；测试人员依照《组装测试计划》和《组装测试用例》，进行系统集成与测试；当测试用例的测试结果与预期值存在偏差时，测试者记录下实际结果；测试者使用Bug管理系统记录所有发现的问题，组装测试负责人在每天测试工作后必须备份当天的测试记录。开发组人员对问题进行技术评审，由技术负责人进行确认；如属于程序问题时，由开发人员进行修改；如属于设计问题，则遵从《变更规程》进行修改；当修改软件以纠正发现的问题时，测试者需要进行回归测试以保证这些修改没有带来新的问题；当《组装测试计划》和《组装测试用例》中定义的出口条件得到满足时，集成测试完成；集成测试阶段完成时，测试负责人提交《集成测试总结报告》；验收测试8.1验收测试的目的在软件开发结束时，评价软件的过程，以确保开发的软件与需求一致。验收测试阶段发现的错误数应不超过前期测试发现的错误总数的20%。岗位与职责8.2.1项目经理分析测试度量数据，确保测试得以充分执行；验收测试负责人由《验收测试计划》中指定的负责人负责验收测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量过程》产生测试度量数据；8.2.4验收测试人员由《验收测试计划》中指定的测试人员执行测试并记录跟踪测试中发现的问题。开发小组负责解决测试过程中发现的问题；入口