软件测试详细标准

《软件测试详细标准》由会员分享，可在线阅读，更多相关《软件测试详细标准（9页珍藏版）》请在装配图网上搜索。

1、-软件测试标准前言前一版的?软件测试标准?，在测试工作中发挥了很好的指导作用。本次修改在原标准根底上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。一、 软件测试1、 软件测试的目的软件测试是指为了度量和提高被测试对象的质量、对测试对象进展工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。2、 软件测试相关概念2.1白盒测试指基于程序构造的测试，测试目标是检查程序部逻辑构造和逻辑路径，是代码级的测试。22黑盒测试基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。23测试用例测试方案，包括数据

2、输入和相应的期望输出。依据测试用例来执行具体操作。24预防性测试其原理为：只要测试在生命周期中进展得足够早，就能够提高待测软件的质量。25测试风险分析其目的为：确定测试对象、测试的优先级、测试的深度。2.6软件测试模型公司目前采用V模型，实现测试与软件开发的同步进展。2.7等价类划分将测试对象按*种约定划分为有限个组成局部，提高测试的有效性。2.8边界值分析分析测试对象的所有边界值及边界附近的临界值。二、 测试工作流程三、 开发测试流程说明：1、 新版本提供时间，由程序员与测试员按实际情况协调；2、 BUG审核的围包括对BUG的抽查；对标注为不修改或待讨论BUG的管理；3、 软件涉及到功能性修

3、改时，应该先提供修改设计说明，讨论通过前方可进展修改。四、 测试角色与职责角色职责围管理负责测试全过程组织管理分析负责进展测试分析、编写测试用例执行执行测试任务文档管理负责对测试文档、开发文档管理五、 BUG主要参数1、 当前状态记录BUG的状态，包括已修改、未修改、已验证。2、 严重程度BUG严重程度分为四个级别级别一：死机，数据丧失，主要功能完全丧失，系统悬挂 级别二：主要功能丧失，导致严重的问题，或致命的错误声明 级别三：次要功能丧失， 不太严重，如提示信息不太准确 级别四：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有错别字3、 修改次数指同样BUG重复修改的次数，是衡量开发

4、人员工作效率的重要依据；4、 优先级别：分为四个级别级别一：必须立即修改；级别二：一天修改；级别三：三天修改级别四：短期无须解决或在下一版本中解决说明：严重程度越高，优先级越高，原有错误优先级高于新版本错误。六、 测试文档1、 测试报告详细记录BUG出现过程，可能原因，解决方法或解决意见。测试报告要求书写工整、简明扼要，必须要详细注明BUG发现日期、BUG所属模块等相关信息对于较难发现的BUG，必须提供操作流程及应用数据。测试报告是测试员与开发人员交流的重要文档，也是测试评价的重要依据。注意：A、 如果测试与测试任务单对应，则测试报告中必须要记录任务单编号，以利于测试验收及考核。B、 测试报告

5、中必须注明测试用例编号，如果发现的BUG不在测试用例围，则填写为“其它，为测试用例评估提供依据。C、 程序员在修改BUG时，如果严重级别为一、二级，必须说明修改方法或问题原因，以利于分析。2、 测试用例测试用例是为高效地发现程序中的BUG而精心准备的一组测试数据或操作过程。测试用例不可能穷举软件中的所有情况，所以测试用例的设计必须具有代表性，通过测试用例的使用可以提高工作效率、减少重复劳动、在软件进展改动或升级时，只需对测试用例进展少量的修改即可开展工作。3、 测试方案主要容：方案时间、人员、测试工作安排4、 测试任务书主要容：时间要求、参与人员、验收标准或完毕标志5、 测试总结报告主要容：方

6、案完成情况、BUG修改情况、经历总结、测试对象评分10分为上限6、 软件修改记录主要容：修改对象、修改容、修改原因、问题提出人、关联对象、测试本卷须知7、 讨论记录详细记录所有与测试相关的讨论，参与讨论者须在此记录上手工签名8、 软件升级记录详细记录软件升级情况9、 用户问题记录主要容：用户情况、用户问题、解决方法、解决状态七、 测试阶段划分1、 单元测试对*个相对独立构件的测试，完毕标志为：能满足独立运行要求2、 集成测试将已通过单元测试的模块依次进展组合并测试，完毕标志为：组合后的模块能满足要求；3、 验收测试所有模块均通过集成测试后，软件可以交付使用前的测试，完毕标志为：软件可以交付使用

7、4、 维护测试对软件发布后发现的问题进展的修改与测试，完毕标志为：问题解决、软件运行正常八、 测试类型1、 功能测试对系统功能满足程度与实现程度的测试，此测试只关心测试对象功能方面的需求，而不考虑其它细节；完毕标志：系统功能满足设计需求2、 界面测试在测试对象满足功能需求的前提下进展，此测试必须包括通用控件标准的测试。例如：数据窗口的滚动条。3、 数据处理测试对测试对象的数据处理过程进展测试，包括输入、处理、输出。4、 流程测试包括业务流程、数据流程、逻辑流程、正反流程5、 极限测试对极限值、边界值的测试6、 并发测试主要指系统在网络环境、并发环境、多用户条件下的运行测试；7、 平安测试包括加

8、密、解密、数据备份、恢复、病毒检测等测试；8、 性能测试包括适应性、强健性、可恢复性、以及灾难恢复能力9、 安装测试是软件发布前必须进展的测试，确保发布的软件产品为最新10、 兼容性测试操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性。11、 强度测试包括大容量数据、极限数据、致命错误操作等12、 用户测试用户测试是处于系统测试阶段完毕和系统试运行阶段开场之前的一个相对独立的阶段。测试的主体，由开发技术人员转为最终应用者。用户通过对系统全部功能和工作流程的亲手应用、测试，逐步全面了解系统是否完全实现了需求说明书的要求，从而承受和认可该软件，这是保证系统功能和流程正确性

9、、完整性和实用性的关键。实践证明，只有用户试用，才能提出合理建议，促使软件实用化和产品化。九、 测试停顿标准由于软件测试是一项复杂的工程，在以往的测试工作中，测试人员都是对程序进展反复的，无休止的测试，无谓的消耗了大量的人力、物力和时间。为了能够合理的利用现有资源，提高测试工作效率，制定了BUG走势图、模块覆盖率和测试用例执行情况三项指标，并根据这三项指标制订出软件测试停顿标准。1 指标1.1 BUG走势图该指标以曲线图的形式，反映出每天各种类型BUG的出现情况。图中每种类型的BUG由一条不同颜色的曲线表示。1.2 模块覆盖率该指标表达出一套软件中各个模块的测试用例制定情况，是否各个模块或各个

10、模块下的各个功能是否都有测试用例，各模块的测试用例占所有用例的比例。1.3 测试用例执行情况该指标表达出各个模块的测试用例执行情况，统计测试通过的用例数量和测试未通过的用例数量，计算已测试的用例数量和未测试的用例数量。2 测试停顿标准各个模块或各个模块下的各个功能的测试用例覆盖率为100%；测试用例执行覆盖率为100%，通过测试的测试用例所占比例在90%以上；BUG走势图中，系统错误、功能错误、数据处理错误在连续3个工作日未出现BUG，其他错误在连续3个工作日未出现合计5个以上含5个错误。此时可对软件停顿测试。十、 软件维护规1、 软件维护的容与类型软件维护是软件产品交付使用后，为纠正错误、改

11、善性和其它属性或产品为适应环境的改变而进展修改和维护的活动。软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。l 完善性维护为扩大功能和改善性能而进展的维护和扩大，以满足用户变化了的需求。主要容包括：A、 对新增的功能和增强的性能进展升级和维护；B、 对用户所提的建立性建议和修改方案做好详细的记录，并加以分析，确定是否对其进展修改和维护。l 适应性测试为适应软件运行环境的变化而进展的维护，主要容包括：A、 因法律法规的变化而做的维护；B、 因硬件配置的变化而做的维护如：机型、终端、打印机的变化；C、 因系统软件的变化而做的维护如：操作系统、编译系统或应用程序的变化。l 改正性维护为维

12、持系统操作运行，对在开发过程中产生但测试和验收时没发现的错误而进展的改正及维护，主要容包括：A、 在维护的过程中对发现的错误进展详细记录并提交开发部；B、 在用户使用过程中对发现的错误进展详细记录并提交开发部；2、维护过程软件生存周期中的维护阶段通常起始于软件产品交付给用户使用之时。软件维护活动通常是软件生存周期中多个维护过程的重复。软件维护与软件开发有许多一样之处，但也有其独特之处：A、 维护活动限定在已有系统的框架之完成，维护人员必须在已有的设计和编码构造的约束下对软件进展维护和提出合理的修改方案。B、 通常软件维护阶段的时间比软件开发的时间长得多，但一项具体的软件维护一般比软件的开发时间

13、短得多。C、 软件开发必须从无到有产生所有测试数据，而软件维护通常可以使用现有的数据进展维护。但有时也要产生新的数据，对软件维护及维护后的影响进展必要的测试。下面是对软件维护过程中要处理的事务：A、 对用户进展软件使用的讲解和指导；B、 对用户问题进展处理；C、 记录软件进展中的错误和用户建议；D、 对错误进展分析，确定修改的必要性，提交开发人员处理；E、 对更正或完善的软件进展升级；3、软件维护的控制和改进软件维护必须方案地进展，使整个过程都处于适当的管理和规程之下。除了考虑预算、进度和人员，关键在于要由软件维护主管要做出行之有效的方案和维护安排。一个系统不仅在开发时要考虑到维护，还要在之前

14、维护中考虑到如何减少将来维护的量和困难。l 软件维护的控制A、 软件系统的可维护性常常随着时间的推移而降低，这是许多因素综合影响的结果。其中没有为软件维护制定严格的条例，或贯彻不力，是系统可维护性迅速降低的主要原因。B、 软件维护的目标是保持系统功能和及时、有效地响应用户的请求。C、 软件维护的控制是保持一个有秩序的维护过程，在这个过程中所有的维护请求要正式提出，确认，分配优先级并安排进度。l 确立软件维护的策略A、 软件维护策略确实定是软件维护控制的一个关键步骤。软件维护策略应充分地考虑软件维护组织的责任、权利、职能及操作，它应全面地考虑到软件系统和维护环境的变化。B、 软件维护策略必须包括

15、具体地讲述维护的目的、维护的责任和分配。制订维护软件的方案和具体步骤，使维护过程行之有效的进展。l 分析和确定所有提出的修改请求A、 考虑对其修改的必要程度和它可预见的作用，所有的修改建议都需要有充足的理由；B、 分析修改，以确保与原来的系统设计和用意不冲突，对每个修改都应该仔细考虑其影响；C、 应考虑所建议的修改是增强还是降低系统的性能。l 为维护安排进度A、 为每个维护工程安排一个优先级；B、 遵守安排的进度。l 维护准备为了对维护方案有更好的贯彻和监视，在开场一项新的维护工作之前，软件维护人员应当为维护容作好充分的准备。4、软件维护人员的管理管理是改进软件维护过程的主要因素之一。管理必须指导怎样维护软件，行使对整个过程的控制，并保证使用高效易用的软件维护技术和工具。为确保实现成功的维护，在维护过程中要有效使用良好的管理技术和方法。软件维护机构的主要任务是制订并实施维护策略，控制和管理维护过程，确保软件维护任务的完成。l 软件维护人员的素质对于有效地进展维护是十分重要的，维护与开发同等重要，同样具有难度，因此对维护人员的管理和根本要：A、 维护人员应是业务技能过硬，有责任心的人；B、 树立全心全意为用户效劳的思想；C、 定期对维护人员进展良好的培训；D、 维护经历和技术要经常互相交流、学习；E、 不让一个系统或一个系统的主要局部成为*个人的专有领地。. z