软件测试标准和测试用例汇总.pdf

. １ / 18 软件测试标准 前言 前一版的《软件测试标准》 ，在测试工作中发挥了很好的指导作用本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程软件测试的目的为：验证软件产品的实现状态以与实现质量 2、软件测试相关概念 2.1 白盒测试 指基于程序结构的测试，测试目标是检查程序部逻辑结构和逻辑路径，是代码级的测试 2．2 黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性 2．3 测试用例 测试方案，包括数据输入和相应的期望输出依据测试用例来执行具体操作 2．4 预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量 2．5 测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度 2.6 软件测试模型 公司目前采用 V 模型，实现测试与软件开发的同步进行 . . ２ / 18 2.7 等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。

2.8 边界值分析 分析测试对象的所有边界值与边界附近的临界值 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比概要设计审核概要设计，从用户角度提出问题编写集成测试用例详细设计审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划审核测试用例执行测试测试总结集成测试阶段验收测试阶段补充测试用例资料归档修改测试审核修改计划程序员提供修改清单编写测试用例执行测试测试总结复测测试报告复测测试用例复测 三、开发—测试流程 . . ３ / 18 程序员测试员BUG管理关闭BUG得到BUG修改BUG版本更新新的开发任务得到新版本提交新BUG验证BUG执行新的测试任务BUG审核定期检查、审核BUG定期编译说明： 1、新版本提供时间，由程序员与测试员按实际情况协调； 2、BUG 审核的围包括对 BUG 的抽查；对标注为不修改或待讨论 BUG 的管理； 3、软件涉与到功能性修改时，应该先提供修改设计说明，讨论通过后方可进行修改。

四、测试角色与职责 角色 职责围 管理 负责测试全过程组织管理 分析 负责进行测试分析、编写测试用例 执行 执行测试任务 文档管理 负责对测试文档、开发文档管理 五、BUG 主要参数 1、当前状态 记录 BUG 的状态，包括已修改、未修改、已验证 2、严重程度 . . ４ / 18 BUG 严重程度分为四个级别 级别一：死机，数据丢失，主要功能完全丧失，系统悬挂 级别二：主要功能丧失，导致严重的问题，或致命的错误声明 级别三：次要功能丧失， 不太严重，如提示信息不太准确 级别四：微小的问题，对功能几乎没有影响，产品与属性仍可使用，如有错别字 3、修改次数 指同样 BUG 重复修改的次数，是衡量开发人员工作效率的重要依据； 4、优先级别： 分为四个级别 级别一：必须立即修改； 级别二：一天修改； 级别三：三天修改 级别四：短期无须解决或在下一版本中解决 说明：严重程度越高，优先级越高，原有错误优先级高于新版本错误 六、测试文档 1、测试报告 详细记录 BUG 出现过程，可能原因，解决方法或解决意见测试报告要求书写工整、简明扼要，必须要详细注明 BUG 发现日期、BUG 所属模块等相关信息（对于较难发现的 BUG，必须提供操作流程与应用数据） 。

测试报告是测试员与开发人员交流的重要文档，也是测试评价的重要依据 注意： A、如果测试与测试任务单对应，则测试报告中必须要记录任务单编号，以利于测试验收与考核 B、 测试报告中必须注明测试用例编号，如果发现的 BUG 不在测试用例围，则填写为“其它” ，为测试用例评估提供依据 C、程序员在修改 BUG 时，如果严重级别为一、二级，必须说明修改方法或问题原因，以利于分析 2、测试用例 测试用例是为高效地发现程序中的 BUG 而精心准备的一组测试数据或操作过程测试用例不可能穷举软件中的所有情况，所以测试用例的设计. . ５ / 18 必须具有代表性，通过测试用例的使用可以提高工作效率、减少重复劳动、在软件进行改动或升级时，只需对测试用例进行少量的修改即可开展工作 3、测试计划 主要容：计划时间、人员、测试工作安排 4、测试任务书 主要容：时间要求、参与人员、验收标准或完毕标志 5、测试总结报告 主要容：计划完成情况、BUG 修改情况、经验总结、测试对象评分（10分为上限） 6、软件修改记录 主要容：修改对象、修改容、修改原因、问题提出人、关联对象、测试须知 7、讨论记录 详细记录所有与测试相关的讨论，参与讨论者须在此记录上手工签名 8、软件升级记录 详细记录软件升级情况 9、用户问题记录 主要容：用户情况、用户问题、解决方法、解决状态 七、测试阶段划分 1、单元测试 对某个相对独立构件的测试，完毕标志为：能满足独立运行要求 2、集成测试 将已通过单元测试的模块依次进行组合并测试，完毕标志为：组合后的模块能满足要求； 3、验收测试 所有模块均通过集成测试后，软件可以交付使用前的测试，完毕标志为：软件可以交付使用 4、维护测试 对软件发布后发现的问题进行的修改与测试，完毕标志为：问题解决、软件运行正常 八、测试类型 . . ６ / 18 1、功能测试 对系统功能满足程度与实现程度的测试，此测试只关心测试对象功能方面的需求，而不考虑其它细节； 完毕标志：系统功能满足设计需求 2、界面测试 在测试对象满足功能需求的前提下进行，此测试必须包括通用控件标准的测试。

例如：数据窗口的滚动条 3、数据处理测试 对测试对象的数据处理过程进行测试，包括输入、处理、输出 4、流程测试 包括业务流程、数据流程、逻辑流程、正反流程 5、极限测试 对极限值、边界值的测试 6、并发测试 主要指系统在网络环境、并发环境、多用户条件下的运行测试； 7、安全测试 包括加密、解密、数据备份、恢复、病毒检测等测试； 8、性能测试 包括适应性、健壮性、可恢复性、以与灾难恢复能力 9、 安装测试 是软件发布前必须进行的测试，确保发布的软件产品为最新 10、 兼容性测试 操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性 11、 强度测试 包括大容量数据、极限数据、致命错误操作等 12、 用户测试 用户测试是处于系统测试阶段完毕和系统试运行阶段开始之前的一个相对独立的阶段测试的主体，由开发技术人员转为最终应用者用户通过对系统全部功能和工作流程的亲手应用、测试，逐步全面了解系统是否完全实现了需求说明书的要求，从而承受和认可该软件，这是保证系统功能和流程正确性、完整性和实用性的关键实践证明，只有用户试. . ７ / 18 用，才能提出合理建议，促使软件实用化和产品化。

九、测试停止标准 由于软件测试是一项复杂的工程，在以往的测试工作中，测试人员都是对程序进行反复的， 无休止的测试，无谓的消耗了大量的人力、物力和时间 为了能够合理的利用现有资源，提高测试工作效率， 制定了 BUG 走势图、模块覆盖率和测试用例执行情况三项指标， 并根据这三项指标制订出软件测试停止标准 1 指标 1.1BUG 走势图 该指标以曲线图的形式，反映出每天各种类型 BUG 的出现情况图中每种类型的 BUG 由一条不同颜色的曲线表示 1.2模块覆盖率 该指标表达出一套软件中各个模块的测试用例制定情况，是否各个模块或各个模块下的各个功能是否都有测试用例，各模块的测试用例占所有用例的比例 1.3测试用例执行情况 该指标表达出各个模块的测试用例执行情况，统计测试通过的用例数量和测试未通过的用例数量， 计算已测试的用例数量和未测试的用例数量 2 测试停止标准 各个模块或各个模块下的各个功能的测试用例覆盖率为100%；测试用例执行覆盖率为 100%，通过测试的测试用例所占比例在 90%以上；BUG 走势图中，系统错误、功能错误、数据处理错误在连续 3 个工作日未出现BUG，其他错误在连续 3 个工作日未出现合计 5 个以上（含 5 个）错误。

此时可对软件停止测试 十、软件维护规 1、软件维护的容与类型 . . ８ / 18 软件维护是软件产品交付使用后，为纠正错误、改善性和其它属性或产品为适应环境的改变而进行修改和维护的活动软件维护一般分为完善性维护、适应性维护和改正性维护三种类型  完善性维护 为扩充功能和改善性能而进行的维护和扩充，以满足用户变化了的需求主要容包括： A、对新增的功能和增强的性能进行升级和维护； B、对用户所提的建设性建议和修改方案做好详细的记录， 并加以分析，确定是否对其进行修改和维护  适应性测试 为适应软件运行环境的变化而进行的维护，主要容包括： A、因法律法规的变化而做的维护； B、因硬件配置的变化而做的维护 （如： 机型、 终端、 打印机的变化） ； C、因系统软件的变化而做的维护（如：操作系统、编译系统或应用程序的变化  改正性维护 为维持系统操作运行，对在开发过程中产生但测试和验收时没发现的错误而进行的改正与维护，主要容包括： A、在维护的过程中对发现的错误进行详细记录并提交开发部； B、在用户使用过程中对发现的错误进行详细记录并提交开发部； 2、维护过程 软件生存周期中的维护阶段通常起始于软件产品交付给用户使用之时。

软件维护活动通常是软件生存周期中多个维护过程的重复软件维护与软件开发有许多相同之处，但也有其独特之处： A、维护活动限定在已有系统的框架之完成， 维护人员必须在已有的设计和编码结构的约束下对软件进行维护和提出合理的修改方案 B、通常软件维护阶段的时间比软件开发的时间长得多， 但一项具体的软件维护一般比软件的开发时间短得多 C、软件开发必须从无到有产生所有测试数据， 而软件维护通常可以使用现有的数据进行维护但有时也要产生新的数据，对软件维护与维护后的影响进行必要的测试 下面是对软件维护过程中要处理的事务： A、对用户进行软件使用的讲解和指导； B、对用户问题进行处理； C、记录软件进行中的错误和用户建议； D、对错误进行分析，确定修改的必要性，提交开发人员处理； E、对更正或完善的软件进行升级； 3、软件维护的控制和改进 . . ９ / 18 软件维护必须计划地进行，使整个过程都处于适当的管理和规程之下除了考虑预算、进度和人员，关键在于要由软件维护主管要做出行之有效的计划和维护安排一个系统不仅在开发时要考虑到维护，还要在之前维护中考虑到如何减少将来维护的量和困难。

 软件维护的控制 A、软件系统的可维护性常常随着时间的推移而降低， 这是许多因素综合影响的结果其中没有为软件维护制定严格的条例，或贯彻不力，是系统可维护性迅速降低的主要原因 B、软件维护的目标是保持系统功能和与时、有效地响应用户的请求 C、软件维护的控制是保持一个有秩序的维护过程，在这个过程中所有的维护请求要正式提出，确认，分配优先级并安排进度  确立软件维护的策略 A、软件维护策略的确定是软件维护控制的一个关键步骤软件维护策略应充分地考虑软件维护组织的责任、权利、职能与操作，它应全面地考虑到软件系统和维护环境的变化 B、软件维护策略必须包括具体地讲述维护的目的、维护的责任和分配制订维护软件的方案和具体步骤，使维护过程行之有效的进行  分析和确定所有提出的修改请求 A、考虑对其修改的必要程度和它可预见的作用，所有的修改建议都需要有充足的理由； B、分析修改，以确保与原来的系统设计和用意不冲突，对每个修改都应该仔细考虑其影响； C、应考虑所建议的修改是增强还是降低系统的性能  为维护安排进度 A、为每个维护项目安排一个优先级； B、遵守安排的进度  维护准备 为了对维护计划有更好的贯彻和监督，在开始一项新的维护工作之前，软件维护人员应当为维护容作好充分的准备。

4、软件维护人员的管理 管理是改进软件维护过程的主要因素之一 管理必须指导怎样维护软件，行使对整个过程的控制，并保证使用高效易用的软件维护技术和工具为确保实现成功的维护，在维护过程中要有效使用良好的管理技术和方法软件维护机构的主要任务是制订并实施维护策略，控制和管理维护过程，确保软件维护任务的完成  软件维护人员的素质对于有效地进行维护是十分重要的，维护与开. . １０ / 18 发同等重要，同样具有难度，因此对维护人员的管理和基本要： A、维护人员应是业务技能过硬，有责任心的人； B、树立全心全意为用户服务的思想； C、定期对维护人员进行良好的培训； D、维护经验和技术要经常互相交流、学习； E、不让一个系统或一个系统的主要部分成为某个人的专有领地 . . １１ / 18 常见的一些功能测试用例有哪些 一登陆、添加、删除、查询模块的测试点 1. 登陆 2. 添加 3. 查询 4. 删除 1. 登陆① 用户名和密码都符合要求 （格式上的要求） ② 用户名和密码都不符合要求（格式上的要求） ③ 用户名符合要求，密码不符合要求（格式上的要求） ④ 密码符合要求，用户名不符合要求（格式上的要求） ⑤ 用户名或密码为空 ⑥ 数据库中不存在的用户名，不存在的密码 ⑦ 数据库中存在的用户名，错误的密码 ⑧ 数据库中不存在的用户名，存在的密码 ⑨ 输入的数据前存在空格 ⑩ 输入正确的用户名密码以后按[enter]是否能登陆 2. 添加① 要添加的数据项均合理， 检查数据库中是否添加了相应的数据 ② 留出一个必填数据为空 ③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④ 不符合要求的地方要有错误提示 ⑤ 是否支持 table 键 ⑥ 按 enter 是否能保存 ⑦ 若提示不能保存，也要察看数据库里是否多了一条数据 3. 删除① 删除一个数据库中存在的数据， 然后查看数据库中是否删除 ② 删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除 ③ 输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。

④ 输入的正确数据前加空格，看是否能正确删除数据 ⑤ 什么也不输入 ⑥ 是否支持 table 键 ⑦ 是否支持 enter 键 4. 查询 . . １２ / 18 精确查询： ① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据 ② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据 ③ 输入格式或围不符合要求的数据，看是否有错误提示 ④ 输入数据库中不存在的数据 ⑤ 不输入任何数据 ⑥ 是否支持 table 键 ⑦ 是否支持 enter 键 模糊查询： 在精确查询的基础上加上以下一点 ① 输入一些字符，看是否能查出数据库中所有的相关信息 二设计功能和界面测试用例 1.1 文本框、按钮等控件测试 1.1.1 文本框的测试 如何对文本框进行测试 a,输入正常的字母或数字。

b,输入已存在的文件的名称； c,输入超长字符例如在“名称”框中输入超过允许边界个数的字符，假设最多 255个字符，尝试输入 256 个字符，检查程序能否正确处理； d,输入默认值，空白，空格； e,若只允许输入字母，尝试输入数字；反之；尝试输入字母； f,利用复制，粘贴等操作强制输入程序不允许的输入数据； g,输入特殊字符集，例如，NUL 与\n 等； h,输入超过文本框长度的字符或文本，检查所输入的容是否正常显示； i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入 yyyy/mm/dd，程序应该给出错误提示 在测试过程中所用到的测试方法： 1,输入非法数据； . . １３ / 18 2,输入默认值； 3,输入特殊字符集； 4,输入使缓冲区溢出的数据； 5,输入相同的文件名； 命令按钮控件的测试 测试方法： a,点击按钮正确响应操作如，单击确定，正确执行操作；单击取消，退出窗口； b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为 32 时，单击”确定“后系统应提示:天数不能大于 31； c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会； 单项选择按钮控件的测试 测试方法： a,一组单项选择按钮不能同时选中，只能选中一个。

b,逐一执行每个单项选择按钮的功能分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”； c,一组执行同一功能的单项选择按钮在初始状态时必须有一个被默认选中，不能同时为空； up－down 控件文本框的测试 测试方法： a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入 10，或者单击向上的箭头，使数目变为 10； b,利用上下箭头控制数字的自动循环，如，当最多数字为 253 时，单击向上箭头，数目自动变为 1；反之亦适用； c,直接输入超边界值，系统应该提示重新输入； d,输入默认值，空白如，“插入”数目为默认值，点击“确定”；或，删除默认值，使容为空，单击“确定”进行测试； e,输入字符此时系统应提示输入有误 组合列表框的测试 测试方法： a,条目容正确，其详细条目容可以根据需求说明确定； b,逐一执行列表框中每个条目的功能； c,检查能否向组合列表框输入数据； 复选框的测试 测试方法： . . １４ / 18 a,多个复选框可以被同时选中； b,多个复选框可以被部分选中； c,多个复选框可以都不被选中； d,逐一执行每个复选框的功能； 列表框控件的测试 测试方法： a,条目容正确；同组合列表框类似，根据需求说明书确定列表的各项容正确，没有丢失或错误； b,列表框的容较多时要使用滚动条； c,列表框允许多项选择时， 要分别检查 shift 选中条目， 按 ctrl 选中条目和直接用鼠标选中多项条目的情况； 滚动条控件的测试 要注意一下几点： a,滚动条的长度根据显示信息的长度或宽度与时变换，这样有利于用户了解显示信息的位置和百分比，如，word 中浏览 100 页文档，浏览到 50 页时，滚动条位置应处于中间； b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码； c,单击滚动条； d,用滚轮控制滚动条； e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试 a,控件间的相互作用； b,tab 键的顺序，一般是从上到下，从左到右； c,热键的使用，逐一测试； d,enter 键和 esc 键的使用； 在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试 ps:密码输入框测试时要特别注意进行字母大写输入的测试 查找替换操作 案例演示:打开 word 中的"替换"对话框 测试本功能有通过测试和失败测试两种情况 通过测试: 1,输入容直接查找,或查找全部 2,在组合框中寻找已经查找过的容,再次查找并确认文档的容正确,如,已经查找过"测试用例",再次进入不用重新输入查找容,直接在文档中搜寻就可以. 失败测试: 1,输入过长或过短的查询字符串.如,假设查询的字符串长度为 1 到 255,那么输入0,1,2,256,255 和 254 进行测试; 2,输入特殊字符集,如,在 word 中.^g 代表图片,^代表分栏符,可以输入这类特殊字符. . １５ / 18 测试; 替换测试大体相同. 关于编辑操作窗口的功能测试的用例: 1,关闭查找替换窗口.不执行任何操作,直接退出; 2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试; 3,控件间的相互作用.如,搜寻容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色. 4,热键, Tab 键.回车键的使用. 插入操作 1,插入文件 测试的情况 a,插入文件; b,插入图像; c,在文档中插入文档本身; d,移除插入的源文件; e,更换插入的源文件的容; 2,文件 测试方法: a,插入文件; b,在文档中文档本身; c,移除插入的源文件; d,更换插入的源文件的容. 3,插入对象 要测试的容 a,插入程序允许的对象,如,在 word 中插入 excel 工作表; b,修改所插入对象的容.插入的对象仍能正确显示; . . １６ / 18 UI测试最常见BUG情况汇总 录入界面 1.输入字段要完整，且要与列表字段相符合（参照数据库进行检查） 2.必填项一律在后面用*表示 （必填项为空在处理之前要有相关的提示信息） 3.字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息 (1)长度校验 (2)数字、字母、日期等等的校验 (3)围的校验 4.录入字段的排序按照流程或使用习惯， 字段特别多的时候需要进行分组显示 5.下拉框不选值的时候应该提供默认值 6.相同字段的录入方式应该统一（手动输入、点选、下拉选择、参照） 7.录入后自动计算的字段要随着别的字段修改更新 （如单价变后， 金额也变） 8.日期参照应该既能输入，又能从文本框选择 界面格式 1.字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性 2.文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性 3.所有新增、修改、查看页面加上页面说明（如：##X新增、##X编辑、##X查看等说明字样），（弹出的）界面要有标题，标题与容要一致 . . １７ / 18 4.不同界面显示相同字段的一致性（如列表界面和编辑界面） 5.界面按钮显示要求（查询、新增、删除顺序） 6.列表的顺序排列应该统一（按照某些特定条件排序） 7.下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定 8.所有弹出窗口居中显示或者最大化显示 9.信息列表中如果某个字段显示过长用“…”或者分行显示 10.人员、时间的缺省值一般取当前登录人员和时间 11.对于带有单位的字段，需要字段的标签后面添加如下容：“（单位）” 功能问题 1.按钮功能的实现（如返回按钮能否返回） 2.信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示 3.所有有提交按钮的页面都要有保存按钮（每个界面风格一致） 4.凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮 5.没有选择记录点击删除/修改按钮要提示“请先选择记录” 6.选择记录后点击删除按钮要提示“确实要删除吗？” 7.需要考虑删除的关联性，即删除某一个容需要同时删除其关联的某些容 8.界面只读的时候（查询、统计、导入）等，应该不能编辑 查询问题 1.查询条件缺少一些可以查询的字段 2.有些查询条件需要支持模糊查询 . . １８ / 18 3.需要考虑有些查询条件本身的关联性 （即某个查询条件的取值围是依赖于其它查询条件的取值） 4.查询条件名称与信息列表与信息编辑页面相应的字段名称完全统一 5.不同模块相同字段的查询方式应该统一（手动输入、点选、下拉选择） 6.出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么 7.对于围的查询采用全闭的形式 。