软件测试详细标准

上传人:回**** 文档编号:120897192 上传时间:2022-07-18 格式:DOC 页数:12 大小:345.50KB
返回 下载 相关 举报
软件测试详细标准_第1页
第1页 / 共12页
软件测试详细标准_第2页
第2页 / 共12页
软件测试详细标准_第3页
第3页 / 共12页
点击查看更多>>
资源描述
软件测试原则前言前一版的软件测试原则,在测试工作中发挥了较好的指引作用。本次修改在原原则基本上,提出了新的测试理念、工作措施、组织方式,使之更贴近实际工作,真正起到大纲的作用。一、 软件测试1、 软件测试的目的软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为:验证软件产品的实现状态以及实现质量。2、 软件测试有关概念2.1白盒测试指基于程序构造的测试,测试目的是检查程序内部逻辑构造和逻辑途径,是代码级的测试。22黑盒测试基于程序功能的测试,根据输入输出的关系推断程序功能的对的性。23测试用例测试方案,涉及数据输入和相应的盼望输出。根据测试用例来执行具体操作。24避免性测试其原理为:只要测试在生命周期中进行得足够早,就可以提高待测软件的质量。25测试风险分析其目的为:拟定测试对象、测试的优先级、测试的深度。2.6软件测试模型公司目前采用V模型,实现测试与软件开发的同步进行。2.7等价类划分将测试对象按某种商定划分为有限个构成部分,提高测试的有效性。2.8边界值分析分析测试对象的所有边界值及边界附近的临界值。二、 测试工作流程 三、 开发测试流程 阐明:1、 新版本提供时间,由程序员与测试员按实际状况协调;2、 BUG审核的范畴涉及对BUG的抽查;对标注为不修改或待讨论BUG的管理;3、 软件波及到功能性修改时,应当先提供修改设计阐明,讨论通过后方可进行修改。四、 测试角色与职责角色职责范畴管理负责测试全过程组织管理分析负责进行测试分析、编写测试用例执行执行测试任务文档管理负责对测试文档、开发文档管理五、 BUG重要参数1、 目前状态记录BUG的状态,涉及已修改、未修改、已验证。2、 严重限度BUG严重限度分为四个级别级别一:死机,数据丢失,重要功能完全丧失,系统悬挂 级别二:重要功能丧失,导致严重的问题,或致命的错误声明 级别三:次要功能丧失, 不太严重,如提示信息不太精确 级别四:微小的问题,对功能几乎没有影响,产品及属性仍可使用,如有错别字3、 修改次数指同样BUG反复修改的次数,是衡量开发人员工作效率的重要根据;4、 优先级别:分为四个级别级别一:必须立即修改;级别二:一天内修改;级别三:三天内修改级别四:短期内不必解决或在下一版本中解决阐明:严重限度越高,优先级越高,原有错误优先级高于新版本错误。六、 测试文档1、 测试报告具体记录BUG浮现过程,也许因素,解决措施或解决意见。测试报告规定书写工整、简要扼要,必须要具体注明BUG发现日期、BUG所属模块等有关信息(对于较难发现的BUG,必须提供操作流程及应用数据)。测试报告是测试员与开发人员交流的重要文档,也是测试评价的重要根据。注意:A、 如果测试与测试任务单相应,则测试报告中必须要记录任务单编号,以利于测实验收及考核。B、 测试报告中必须注明测试用例编号,如果发现的BUG不在测试用例范畴内,则填写为“其他”,为测试用例评估提供根据。C、 程序员在修改BUG时,如果严重级别为一、二级,必须阐明修改措施或问题因素,以利于分析。2、 测试用例测试用例是为高效地发现程序中的BUG而精心准备的一组测试数据或操作过程。测试用例不也许穷举软件中的所有状况,因此测试用例的设计必须具有代表性,通过测试用例的使用可以提高工作效率、减少反复劳动、在软件进行改动或升级时,只需对测试用例进行少量的修改即可开展工作。3、 测试筹划重要内容:筹划时间、人员、测试工作安排4、 测试任务书重要内容:时间规定、参与人员、验收原则或结束标志5、 测试总结报告重要内容:筹划完毕状况、BUG修改状况、经验总结、测试对象评分(10分为上限)6、 软件修改记录重要内容:修改对象、修改内容、修改因素、问题提出人、关联对象、测试注意事项7、 讨论记录具体记录所有与测试有关的讨论,参与讨论者须在此记录上手工签名8、 软件升级记录具体记录软件升级状况9、 顾客问题记录重要内容:顾客状况、顾客问题、解决措施、解决状态七、 测试阶段划分1、 单元测试对某个相对独立构件的测试,结束标志为:能满足独立运营规定2、 集成测试将已通过单元测试的模块依次进行组合并测试,结束标志为:组合后的模块能满足规定;3、 验收测试所有模块均通过集成测试后,软件可以交付使用前的测试,结束标志为:软件可以交付使用4、 维护测试对软件发布后发现的问题进行的修改与测试,结束标志为:问题解决、软件运营正常八、 测试类型1、 功能测试对系统功能满足限度与实现限度的测试,此测试只关怀测试对象功能方面的需求,而不考虑其他细节;结束标志:系统功能满足设计需求2、 界面测试在测试对象满足功能需求的前提下进行,此测试必须涉及通用控件原则的测试。例如:数据窗口的滚动条。3、 数据解决测试对测试对象的数据解决过程进行测试,涉及输入、解决、输出。4、 流程测试涉及业务流程、数据流程、逻辑流程、正反流程5、 极限测试对极限值、边界值的测试6、 并发测试重要指系统在网络环境、并发环境、多顾客条件下的运营测试;7、 安全测试涉及加密、解密、数据备份、恢复、病毒检测等测试;8、 性能测试涉及适应性、强健性、可恢复性、以及劫难恢复能力9、 安装测试是软件发布前必须进行的测试,保证发布的软件产品为最新10、 兼容性测试操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性。11、 强度测试涉及大容量数据、极限数据、致命错误操作等12、 顾客测试顾客测试是处在系统测试阶段结束和系统试运营阶段开始之前的一种相对独立的阶段。测试的主体,由开发技术人员转为最后应用者。顾客通过对系统所有功能和工作流程的亲手应用、测试,逐渐全面理解系统与否完全实现了需求阐明书的规定,从而接受和承认该软件,这是保证系统功能和流程对的性、完整性和实用性的核心。实践证明,只有顾客试用,才干提出合理建议,促使软件实用化和产品化。九、 测试停止原则由于软件测试是一项复杂的工程,在以往的测试工作中,测试人员都是对程序进行反复的,无休止的测试,无谓的消耗了大量的人力、物力和时间。为了可以合理的运用既有资源,提高测试工作效率,制定了BUG走势图、模块覆盖率和测试用例执行状况三项指标,并根据这三项指标制定出软件测试停止原则。1 指标1.1 BUG走势图该指标以曲线图的形式,反映出每天多种类型BUG的浮现状况。图中每种类型的BUG由一条不同颜色的曲线表达。1.2 模块覆盖率该指标体现出一套软件中各个模块的测试用例制定状况,与否各个模块或各个模块下的各个功能与否均有测试用例,各模块的测试用例占所有用例的比例。1.3 测试用例执行状况该指标体现出各个模块的测试用例执行状况,记录测试通过的用例数量和测试未通过的用例数量,计算已测试的用例数量和未测试的用例数量。2 测试停止原则各个模块或各个模块下的各个功能的测试用例覆盖率为100%;测试用例执行覆盖率为100%,通过测试的测试用例所占比例在90%以上;BUG走势图中,系统错误、功能错误、数据解决错误在持续3个工作日内未浮现BUG,其她错误在持续3个工作日内未浮现合计5个以上(含5个)错误。此时可对软件停止测试。十、 软件维护规范1、 软件维护的内容与类型软件维护是软件产品交付使用后,为纠正错误、改善性和其他属性或产品为适应环境的变化而进行修改和维护的活动。软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。l 完善性维护为扩大功能和改善性能而进行的维护和扩大,以满足顾客变化了的需求。重要内容涉及:A、 对新增的功能和增强的性能进行升级和维护;B、 对顾客所提的建设性建议和修改方案做好具体的记录,并加以分析,拟定与否对其进行修改和维护。l 适应性测试为适应软件运营环境的变化而进行的维护,重要内容涉及:A、 因法律法规的变化而做的维护;B、 因硬件配备的变化而做的维护(如:机型、终端、打印机的变化);C、 因系统软件的变化而做的维护(如:操作系统、编译系统或应用程序的变化。)l 改正性维护为维持系统操作运营,对在开发过程中产生但测试和验收时没发现的错误而进行的改正及维护,重要内容涉及:A、 在维护的过程中对发现的错误进行具体记录并提交开发部;B、 在顾客使用过程中对发现的错误进行具体记录并提交开发部;2、维护过程软件生存周期中的维护阶段一般起始于软件产品交付给顾客使用之时。软件维护活动一般是软件生存周期中多种维护过程的反复。软件维护与软件开发有许多相似之处,但也有其独特之处:A、 维护活动限定在已有系统的框架之内完毕,维护人员必须在已有的设计和编码构造的约束下对软件进行维护和提出合理的修改方案。B、 一般软件维护阶段的时间比软件开发的时间长得多,但一项具体的软件维护一般比软件的开发时间短得多。C、 软件开发必须从无到有产生所有测试数据,而软件维护一般可以使用既有的数据进行维护。但有时也要产生新的数据,对软件维护及维护后的影响进行必要的测试。下面是对软件维护过程中要解决的事务:A、 对顾客进行软件使用的解说和指引;B、 对顾客问题进行解决;C、 记录软件进行中的错误和顾客建议;D、 对错误进行分析,拟定修改的必要性,提交开发人员解决;E、 对改正或完善的软件进行升级;3、软件维护的控制和改善软件维护必须筹划地进行,使整个过程都处在合适的管理和规程之下。除了考虑预算、进度和人员,核心在于要由软件维护主管要做出行之有效的筹划和维护安排。一种系统不仅在开发时要考虑到维护,还要在之前维护中考虑到如何减少将来维护的量和困难。l 软件维护的控制A、 软件系统的可维护性常常随着时间的推移而减少,这是许多因素综合影响的成果。其中没有为软件维护制定严格的条例,或贯彻不力,是系统可维护性迅速减少的重要因素。B、 软件维护的目的是保持系统功能和及时、有效地响应顾客的祈求。C、 软件维护的控制是保持一种有秩序的维护过程,在这个过程中所有的维护祈求要正式提出,确认,分派优先级并安排进度。l 确立软件维护的方略A、 软件维护方略的拟定是软件维护控制的一种核心环节。软件维护方略应充足地考虑软件维护组织的责任、权利、职能及操作,它应全面地考虑到软件系统和维护环境的变化。B、 软件维护方略必须涉及具体地讲述维护的目的、维护的责任和分派。制定维护软件的方案和具体环节,使维护过程行之有效的进行。l 分析和拟定所有提出的修改祈求A、 考虑对其修改的必要限度和它可预见的作用,所有的修改建议都需要有充足的理由;B、 分析修改,以保证与本来的系统设计和用意不冲突,对每个修改都应当仔细考虑其影响;C、 应考虑所建议的修改是增强还是减少系统的性能。l 为维护安排进度A、 为每个维护项目安排一种优先级;B、 遵守安排的进度。l 维护准备为了对维护筹划有更好的贯彻和监督,在开始一项新的维护工作之前,软件维护人员应当为维护内容作好充足的准备。4、软件维护人员的管理管理是改善软件维护过程的重要因素之一。管理必须指引如何维护软件,行使对整个过程的控制,并保证使用高效易用的软件维护技术和工具。为保证明现成功的维护,在维护过程中要有效使用良好的管理技术和措施。软件维护机构的重要任务是制定并实行维护方略,控制和管理维护过程,保证软件维护任务的完毕。l 软件维护人员的素质对于有效地进行维护是十分重要的,维护与开发同等重要,同样具有难度,因此对维护人员的管理和基本规定是:A、 维护人员应是业务技能过硬,有责任心的人;B、 树立全心全意为顾客服务的思想;C、 定期对维护人员进行良好的培训;D、 维护经验和技术要常常互相交流、学习;E、 不让一种系统或一种系统的重要部提成为某个人的专有领地。
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 管理文书 > 各类标准


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!