精华内容
下载资源
问答
  • 修改软件功能
    千次阅读
    2019-11-08 10:37:33

    非功能性需求是需求的一个重要组成部分,它影响了系统的架构设计,需要开发人员重点关注。但是在工程实践中,往往客户不会提出非功能性需求,需求人员在描述需求时不知道如何描述,在国际的各种标准中,对非功能性需求有定义,但是比较抽象。因此我整理如下常见的非功能性需求的描述案例,供需求人员进行参考。


    1、性能需求描述案例:

    响应时间:

    在95%的情况下,一般时段响应时间不超过1.5秒,高峰时段不超过4秒。

    定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。

    在网络畅通时,拨号连接GPRS网络所需时间不得超过5秒。

    在网络畅通时,电子地图刷新时间不超过10秒。

    在推荐配置环境下:登录响应时间在2秒内,刷新栏目响应时间在2秒内,刷新条目分页列表响应时间2秒内,打开信息条目响应时间1秒内,刷新部门、人员列表响应时间2秒内。

    在非高峰时间根据编号和名称特定条件进行搜索,可以在3秒内得到搜索结果。

    业务量:

    每日最大成交数3000笔业务。

    平均交易并发数为20,最大交易并发数为50。

    估计用户数为1万人,每天登录用户数为3000左右,网络的带宽为100M带宽。

    系统可以同时满足10,000个用户请求,并为25,000个并发用户提供浏览功能。


    系统容量:

    支持3万用户,支持GB级数据。

    数据库表行数不超过100万行,数据库最大容量不超过1000GB,磁盘空间至少需要40G以上。

    精度:

    定位精度误差不超过80米。

    当通过互联网接入系统的时候,期望在编号和名称搜索时最长查询时间<15秒。

    计算的精确性到小数点后7位。

    资源使用率:

    CPU占用率<=50%。

    内存占用率<=50%。

    2、安全需求描述案例:

    严格权限访问控制,用户在经过身份认证后,只能访问其权限范围内的数据,只能进行其权限范围内的操作。

    不同的用户具有不同的身份和权限,需要在用户身份真实可信的前提下,提供可信的授权管理服务,保护数据不被非法/越权访问和篡改,要确保数据的机密性和完整性。

    提供运行日志管理及安全审计功能,可追踪系统的历史使用情况。

    能经受来自互联网的一般性恶意攻击。如病毒(包括木马)攻击、口令猜测攻击、黑客入侵等。

    至少99%的攻击需要在10秒内检测到。

    3、可靠性需求描述案例:

    对输入有提示,数据有检查,防止数据异常。

    系统健壮性强,应该能处理系统运行过程中出现的各种异常情况,如:人为操作错误、输入非法数据、硬件设备失败等,系统应该能正确的处理,恰当的回避。

    因软件系统的失效而造成不能完成业务的概率要小于5‰。

    要求系统7x24小时运行,全年持续运行故障停运时间累计不能超过10小时。

    系统缺陷率每1,000小时最多发生1次故障。

    在1,000,000次交易中,最多出现1次需要重新启动系统的情况。

    4、兼容性需求描述案例:

    系统应支持IOS,Android , windows操作系统;

    系统应支持Oracle, DB2 数据库系统;

    最多只有5%的系统实现需要具体到特定的操作系统。

    替换关系数据库系统的平均时间不超过2小时,并且保证没有数据丢失。

    5、数据保密需求描述案例:

    网络传递数据应经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密,确保不可破解。

    6、环境需求描述案例:

     

    硬件

    操作系统及其版本

    应用服务器软件及其版本

    应用软件及其部件

    服务器

    IBM RS6000

    AIX 4.3.3

    IBM HTTP Server、Apache、MS IIS5.0等;

    DB2(7.2 EE以上版本)

    WAS(4.0以上版本)、Web Logic(7.0以上版本)等;

    Oracle EE(9i EE以上版本)

    浏览客户端

    PII 800/64M/2G

    Win98及以上

    IE 5.0以上或Netscape同等版本以上

     

    特殊客户端

    PII 2G/64M/2G

    建议配置Win2000及以上

    IE 5.0以上或Netscape同等版本以上

    MicroStrategy7i客户端

    7、易用性需求描述案例:

    在引入该产品的3个月内,60%的用户应该可以在45秒内用它来完成转账的任务,失败率控制在万分之一以内。

    60%的用户在第一次看见该产品的5秒内,就会意识到这是**银行的网银。

    80%的用户在接受一个2小时的系统介绍培训后,可以在5分钟之内成功预订房间。

    8、可用性需求描述案例:

    有些农村地区网络质量差,带宽小。在网络环境差的条件下保证系统的可用性等。

    在95%的故障中,系统最多需要20秒重启。

    提供数据备份和恢复功能,使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时,能够及时恢复和还原数据(由硬件及第三方软件提供此功能)。

    9 、可测试性需求描述案例:

    一个模块的最大圈复杂度不能超过15。

    交付的系统必须通过单元测试,并且是100%覆盖。

    开发活动必须使用回归测试,并允许在12小时内重新进行完整的测试。

    10、可维护性需求描述案例:

    从接到修改请求后,对于普通修改应在1~2天内完成;对于评估后为重大需求或设计修改应在1周内完成。

    90%的BUG修改时间不超过1个工作日,其他不超过2个工作日。

    代码的圈复杂度必须在10以内。

    任何对象的任何方法都不允许超过200行代码。

    安装新版本必须保持所有的数据库内容和所有个人设置不变。

    产品必须提供可跟踪任何数据库字段的工具。
    ————————————————

    更多相关内容
  • 软件开发中的非功能需求类型

    千次阅读 2021-12-10 15:16:05
    软件开发中,很多程序员都将完成需求当作任务目标。但是在验收、代码评审的时候,我们对于程序员来讲,除了能完成外,还有一些其它一些要求条件:例如代码健壮性,可扩展性,性能等等考核指标。 写代码,除了...

     在软件开发中,很多程序员都将完成需求当作任务目标。但是在验收、代码评审的时候,我们对于程序员来讲,除了能完成外,还有一些其它一些要求条件:例如代码健壮性,可扩展性,性能等等考核指标。

    这些其它的条件,其实我们可以理解为非功能性需求。

    非功能性需求,我们一般分为以下几个指标:

     

    观感性

    简单来说,就是页面的观看舒适度。界面舒适度很大的效果上是来自操作者的反馈。

    主要描述了需求外观的期望、情绪和风格。简单点来说就是对页面的视觉感官。

    易接受性:色彩是否和当前系统类型一致,例如蓝色偏商务风等。

    风格统一性:设计风格是否统一,一看就知道是一个系统的内容,主要考虑人们在多个系统之间进行系统切换的时候,怎样打开多页面不迷失的问题。

    易用性

    易用性会提高用户习惯的能力和对使用的期望。主要从消费者的生产效率、容错率等方面来考究。

    易理解:用户在使用该系统的时候,思维方式和常规人或软件的思维方式一样。例如1+1 结果为2(十进制),而不是10(二进制)

    易学习:用户使用该系统所花费的成本是否过高。每个功能是否需要单独学习相关的操作和理解。

    易操作:操作和控制该系统是否方便。例如页面排版上,下拉框数据过多的时候,是否有搜索功能等,可以方便快速找到内容。

    可执行性

    可以理解为执行效率。一般情况下对于可执行性的考核都是从时间维度和空间维度来考量。

    时间维度:主要是看运行功能所需的时间。一般使用时间复杂度T(n)来表示。值越大,说明花费的时间越多。

    空间维度:主要是看运行功能所需的资源(内存)。一般使用空间复杂度O(n)来表示,和上面一样,值越大,说明使用的内存越大。

    可靠性

    在规定的时间和条件下,其稳定运行的能力。主要从以下几个方面考量

    稳定性:无错运行可以拿到几个9。例如99.99%这种。

    容错性:软件在错误的数据和环境下,对于错误的处理能力。

    可恢复性:程序在宕机后,多长时间能恢复。 

    可维护性

    程序在上线后,进行修改和跟踪所需要花费的精力。一般从以下几个方面考量

    分析性:为跟踪确定bug所花费的精力的长短比例。

    扩展性:后续修改代码已有功能所花费的时间的长短比例

    测试性:在修改后,验证功能所花费的时间比例。

    可移植性

    程序从一个环境切换到另外一套环境所需的时间考量

    适应性:程序从一个环境切换到另外一个环境下,所需要准备的成本花费比例。例如从window切换到linux。

    安装性:在不同环境下安装所花费的成本比例。

    替换性:替换其它功能的机会成本

    写代码,除了完成需求规定的功能外,还要综合考量在性能、可用性等

    展开全文
  • 软件测试基础——功能测试

    万次阅读 多人点赞 2021-09-22 15:39:50
    尽早地发现软件程序、系统或产品中所有的问题。 督促和协助开发人员尽快地解决程序中的缺陷。 帮助项目管理人员制定合理的开发和测试计划。 对缺陷进行跟踪、分析和分类总结,以便让项目的管理人员和相关的负责人...

    一、测试项目启动与研读需求文档

    (一) 组建测试团队

    1 测试团队中的角色

    在这里插入图片描述

    2 测试团队的基本责任
    • 尽早地发现软件程序、系统或产品中所有的问题。
    • 督促和协助开发人员尽快地解决程序中的缺陷。
    • 帮助项目管理人员制定合理的开发和测试计划。
    • 对缺陷进行跟踪、分析和分类总结,以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。
    • 帮助改善开发流程、提高产品开发效率。
    • 促进程序编写的规范性、易读性、可维护性等
    3 测试团队与开发团队的 3 种模式
    • (1)以开发为核心,测试只是开发队伍的一部分,也就是开发团队中有测试人员,但 没有形成独立的团队
      在这里插入图片描述
    • (2)以项目经理为核心,开发小组和测试小组并存,隶属于项目经理领导。
      在这里插入图片描述
    • (3)项目经理、开发组长和测试组长“三足鼎立”,测试团队具有独立的、权威的地 位。
      在这里插入图片描述

    (二)软件质量需求

    1 软件质量需求的分类
    • 软件质量需求用于确定测试目标。
    • 测试目标包括:功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
    • 功能以外统称非功能。
    2 功能
    • 软件能做什么?
    • -需要做什么?
    • 怎么做是正确的?
    • 哪些功能要测试、哪些功能不需要测试?
    • 哪些功能重要,哪些不重要?
    • 哪些功能先实现或先测试?
    3 性能
    • 反映软件运行时的效率和占用资源情况的能力。
       时间特性:时间短、速度快、效率高。
       资源特性:占用资源(CPU、内存、硬盘、网络)少。
    4 界面(UI)
    • 布局合理;
    • 控件位置恰当;
    • 文字没有乱码、字体大小合适;
    • 颜色使用恰当;
    • 图片、表格恰当、舒适、美观。
    5 易用性
    • 在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力。
    6 兼容性/可移植性
    • 指软件产品从一种环境迁移到另一个环境的能力,反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力。
       包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。
    7 安全性
    • 指软件产品保护信息和数据的能力。
    8 可用性/可靠性
    • 指系统正常运行的能力或程度,可用性=正常运行时间/(正常运行时间+非正常运行时 间)×100%。
       可用性指标一般要求达到 4 个 9 即 99.99%(全年 52 分钟不正常工作)或 5 个 9 即 99.999%(全年 5 分钟),对一些军事系统,可用性高达 7 个 9(99.99999%(全年 失效时间不超过两秒)。
       一般测试时间不足,可以采用空间换时间的办法,如在高负载情况下进 行为期一周 或一个月的测试,以判断其可靠性。
       关注 MTTF(平均无故障时间)、MTTR(平均恢复时间)、MTBF(平均失效间 隔时间)。
    9 可维护性
    • 指软件产品可被修改的能力。
       修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。
       可维护性的软件应该是易改变的、稳定的、易测试的。
    10 可扩展性/可伸缩性测试
    • 通过很少的改动就能实现整个系统处理能力的增长。
       如在部署两台服务器时测试系统性能(容量,即最大负载),再部署四台、八台服 务器时分别进行系统容量的测试,看其容量是否为上次(两台、四台)实验值的两 倍或接近两倍。如果是,系统就具有良好的可伸缩性。

    (三)研读需求文档

    1 测试需求分析的过程
    • 收集与研读文档,提出并解决问题,整理需求信息
    • 功能拆分、功能描述/需求整理
    • 编写测试点
    • 需求评审
    2 研读需求文档
    2.1 研读文档主要任务
    • 提取有用的需求信息
    • 提出需求中不清晰、不理解、不明白的问题
       和用户、业务人员、产品经理或产品设计人员、开发人员等沟通
    2.2 怎么研读文档
    • 分析思路
       分析软件的用户群,分析用户的实际需要;
       分析软件的开发环境、开发语言、数据类型;
       分析软件架构、软件的运行环境和平台、数据库类型;
       分析软件要实现哪些目标(功能、性能、界面、易用性、兼容性、安全性)以 及具体的要求是什么;
       分析软件有哪些功能,每种功能要完成什么业务,这些业务应该怎么实现,业 务逻辑是什么,业务流程是怎样的,业务规则有何要求;
       分析功能或业务间的联系,哪些业务更关键或重要;
       明确测试周期,测试目标,测试范围。
    • 细节上
       分析每个模块或功能上实现的功能
       设计的开发原理包括数据类型
       从用户使用场景角度分析业务流程
       记录业务规则
    • 实施
       以情景再现的形式写出需求信息。
    2.3 研读需求文档案例
    • 拿到一个项目,怎么入手?
      – 即时贴程序部分需求说明
       便签的数量最多为 50 个
       便签标题字数最多为 40 个字节
       便签的正文文字数量最多为 200 个
       年份只能设置在 1900-2100 之间

    (四)需求评审

    1 意义
    • 对软件需求进行正确性的检查。
    • 保证软件需求的可测试性。
    • 通过产品需求文档的评审,与市场、产品、开发等各部门相关人员沟通,使得大家 认识一致,避免在后期产生不同的理解,引起争吵。
    • 通过产品需求文档的评审,更好地理解产品的功能性和非功能性需求
    • 在需求文档评审通过后,测试的目标和范围就确定了。虽然此后会有需求的变更, 但可以得到有效的控制,这样可降低测试的风险。
    • 评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不 应该只体现在“签字”形式上,更重要的是达到下面的结果。
       所有参与方达成一致。
       已发现的问题被阐述清楚、被修正。
    2 需求评审的质量要求
    • 正确性
    • 完备性
    • 易理解性
    • 一致性
    • 可行性
    • 易修改性
    • 可测试性
    • 可追溯性
    3 需求评审的参加人员
    • 用户代表
    • 需求人员
    • 产品经理
    • 项目经理
    • 开发人员
    • 开发经理
    • 测试人员
    • 测试经理
    • 市场经理
    • 质量保证人员
    4 测试人员参与评审时的注意事项
    • 明确自己的角色和责任。
    • 熟悉评审内容,为评审做好准备,做细做到位。
    • 在评审会上,针对问题阐述观点,而不是针对个人。
    • 可以分别讨论主要的问题和次要的问题。
    • 在会议前或会议后可以就存在的问题提出自己建设性的意见。
    • 提高自己的沟通能力,采取适当的、灵活的表述方式。
    • 对发现的问题跟踪下去。
    • 应该在需求形成的过程中进行分阶段的多次评审,而不是一次评审。
    • 测试人员要善于提问,多思考
       这些需求都是用户提出来的吗?
       有没有画蛇添足的需求?没有漏掉什么需求吗?
       和竞争对手的产品做过比较吗?我们的产品优势体现在哪里?
       是否正确地描述了每个需求?这条描述是否存在二义性的问题?
       我的理解和文档作者的理解一致吗?

    二、测试需求分析与测试用例设计

    (一) 界面中的控件知识

    1 文本框和密码框

    在这里插入图片描述

    2 单选按钮、组合列表框、数码框

    在这里插入图片描述

    3 复选框

    4 列表框

     通常多选;  条目内容要正确(多余/错放项、缺少项);  横向显示完整,纵向显示完整;  条目功能要正确实现。

    5 命令按钮

     实现所需的功能;  出现错误时,给出切当明确的提示信息。

    6 其他界面元素

    在这里插入图片描述

    三、 测试需求分析与测试用例设计方法

    1 场景法

    1.1 测试点/检查点

    • 测试时应该考虑可以测试的诸多方面。

    1.2 场景法概述

    • 场景法模拟用户操作软件时的情景,主要用于测试系统的业务流程。
    • 当拿到一个测试任务时,我们先要关注它的主要功能和业务流程是否正确实现,这 就需要使用场景法来完成测试。

    1.3 场景的定义

    • 场景用来描述软件操作的路径。
    • 基本流
    • 按照正确的业务流程来实现的一条操作路径(模拟正确的操作流程)。
    • 备选流
    • 导致程序出现错误的操作流程(模拟错误的操作流程)。

    1.4 场景法的分析步骤

    • 分析软件需求
    • 从用户使用情景角度,写出业务流程和业务规则
    • 写出基本流场景和备选流场景

    1.5 场景法案例:ATM 机取款

    • 步骤一:分析业务流程(可以绘制流程图)
      在这里插入图片描述
      在这里插入图片描述
      步骤二:描述程序的基本流及备选流

      • 1、基本流(正确的流程)
        (1)插入银行卡:客户将银行卡插入 ATM 机的读卡器
        (2)验证银行卡:ATM 机从银行卡的磁条中读取账户代码,并检查它是 否属于可以接受的银行卡
        (3)输入密码:ATM 机要求客户输入密码
        (4)验证密码:确定该密码是否正确 
        (5)进入 ATM 主界面:ATM 显示在本机中可用的各种选项
        (6)选择取款并输入金额:客户选择“取款”,并选择取款金额
        (7)ATM 机验证:ATM 机进行验证账户余额是否满足以及总取款金额 是否满足要求,验证 ATM 机内现金是否够用
        (8)更新账户余额、出钞:验证成功,更新账户余额,输出现金,提示 用户收取现金
        (9)返回主界面
    • 2、备选流(各种错误情况)
      (1)银行卡无效:提示错误并退卡
      (2)密码错误:提示错误,并判断是否 3 次错误
      (3)密码 3 次错误:吞卡
      (4)账户余额不足:提示错误并退卡
      (5)总取款金额超出当日可取限额:提示错误并退卡
      (6)ATM 机余额不足:提示错误并退卡

    步骤三:根据基本流和备选流生成不同的场景

    在这里插入图片描述

    2 等价类划分

    2.1 案例引入
    测试两位数加法器(学生思考、讨论、陈述)
    在这里插入图片描述
    2.2 等价类划分核心思想

    • 通过需求分析,找出程序的输入域。
    • 将输入域划分成若干类。
    • 每一类中选取代表性数据等价于这一类中的其他值。
      2.3 等价类划分的步骤
    • 需求分析
    • 划分等价类(根据需求,有效等价类、无效等价类)并细化(根据计算机知识)
      2.4 等价类划分案例
    • 步骤 1:需求分析
      • 阅读文档 :
         借助开发知识
         与开发或用户沟通
         了解用户群及行业知识

      • 写出需求:
         -99~99 之间的整数

    • 步骤 2:划分等价类并细化
    • 有效类
       -99 到 99 之中的整数
       细化 :负数、0 、正数
    • 无效类
       超范围 :<-99 或 >99
       非法类型 : 浮点数 、 字符(串)

    2.5等价类划分注意事项

    • 不但要考虑有效等价类,也要考虑无效等价类
    • 两块划成一块(等价类划分过粗),结果?
       遗漏一种测试情况
    • 一块划成两块(等价类划分过细),结果?
       冗余测试
    • 仔细划分,审查划分
       过于粗略可能会漏掉软件缺陷
       积累经验

    3边界值分析

    3.1 边界值分析的思想与步骤

    • 分析需求,找出边界。
    • 写出边界值
       最小值
       小于最小值
       最大值
       大于最大值
      3.2边界值分析案例
    • 两位数加法计算器的边界值 : -99 、-100、99 、100
      3.3 为什么分析边界值
      看看下面的代码有错误吗?
      在这里插入图片描述
       输入或输出的边界最容易产生错误。

    4 决策表

    前面测试两位数加法计算器的测试没有考虑输入组合。

    4.1 决策表的分析步骤
    • 需求分析
      • 分析输入和输出
         用等价类划分分析输入的各种情况、输出的各种情况
    • 画判定表
    • 分析与简化判定表
    4.2 决策表案例
    • 分析输入条件和输出条件

      • 输入
        在这里插入图片描述

      • 输出
         正确计算
         错误提示

    • 原始决策表/判定表
      在这里插入图片描述

    • 优化决策表
      在这里插入图片描述

      • 优化策略
         测试基本功能的保留;
         一个输入错误,另外输入无所谓,可以整合;
         所有输入都要错误过。
    • 最终的决策表
      在这里插入图片描述

    4.3 决策表的局限性与优化策略

    导致测试量爆炸。

    5 错误推测

    5.1 测试若干原则回顾
    • 测试不是验证软件正确,而是攻击软件,发现错误。
    • 测试要时刻保持怀疑的态度,具有缺陷预防意识。
    • 测试要寻求系统设计、功能设计的弱点。
    • 设计负面的、异常的测试,如考虑错误的或者异常的输入,往往可以发现更多的软件缺陷。
    5.2 什么是错误推测

    在测试程序时,人们可以根据经验或直觉推测程序中可能存在的各种错误,从而有针对 性地编写检查这些错误的测试方法。

    • 错误推测分类
       输入数据测试方面
       输出数据测试方面
       数据结构测试方面
       文件系统方面
    5.3 输入数据方面的错误推测

    输入非法数据

    • 一般用于键盘输入数据时。
      • 测试方法
         输入非法类型
         输入非法范围/长度
         输入非法格式
    • 注意
    • 错误信息的检查:需要额外考虑错误提示信息的内容
    • 错误信息和错误要对应一致
    • 错误信息不能为空
    • 错误信息的内容不能只是错误代码,不能包含开发信息
    • 错误信息不能中英文混合
    5.4 错误推测
    • 输入非法类型
    • 输入非法范围(数值)
    • 输入非法长度(个数)
    • 输入非法格式
    • 输入默认值
    • 输入特殊字符
    • 输入合法数据的非法组合
    • 粘贴强制输入
    • 一个输入多个输出不要遗漏
    • 输出结果(含数据库)要正确
    • 上溢、下溢(含结果)
    • 操作数与操作符不符
    • 文件超载
    • 文件权限不足
    • 介质忙或不可用
    • 介质损坏

    输入默认值

    • 适用于有默认值的地方。
    • 测试方法
       接受软件的默认值
       键入空值
       将默认值改为另外一个值
       将默认值改为另外一个值,再变为空值

    输入特殊字符(集)

    • 适用于不能输入有特殊含义的字符时。
    • 测试方法
       根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务 等信息列出表格,进行讨论,标明哪些需要测试,哪些需要剔除。
       了解具体行业知识,具体问题具体分析。
    • 案例
      • 文件命名下列特殊字符(33 个)
         不能使用:\ /<>|“😗?,com0-com9,lpt0-lpt9,prn、aux、nul、 con。
      • 思考
         用户名有哪些特殊字符?
         QQ 昵称、聊天内容有哪些特殊字符?

    输入合法数据的非法组合

    • 适用于输入值之间存在依赖关系时。
    • 测试方法
       输入可能是出现问题的组合值。
    • 案例
      在这里插入图片描述
      输出数据方面的错误推测
      1)同一个输入产生多种输出
    • 案例
      • 输入:一个电话打来
      • 输出:
         状态一:等待接听。
         状态二:占线。
         状态三:停机。
         状态四:无法接通。
         状态五:关机。
         状态六:空号。
    • 测试方法
      • 详细测试每一种输出,不要有遗漏。
      • 熟悉被测软件业务知识,阅读各种程序文档,明确输入可能产生的输出, 列出关于程序输入于输出的一个列表,然后进行测试。

    2)验证输出结果的正确性
    测试方法

    • 不仅测试输入的正确性,还要检查结果的正确性。
    • 测试人员要尽可能多地学习所涉及问题的领域。

    数据结构方面的错误推测

    1)数据结构溢出

    • 适用于程序中存在变量、数组等数据结构时。
    • 测试方法
      • 变量 :
        上溢:值太大
        下溢:值太小
      • 数组
         上溢:数据量太多
         下溢:数据量太少

    2)计算结果溢出
    在这里插入图片描述

    • 测试方法
       输入非法值或很大与很小数据,强制结果产生上溢或下溢。

    3)操作数和操作符不符
    在这里插入图片描述

    • 适用于需要进行数值计算程序和图形操作程序的测试时,如加、减、乘、除等。
    • 测试方法
       找到程序中容易引起操作数和操作符不符的计算、表达式等

    文件系统方面的错误推测

    1)使文件系统超载

    • 适用于数据存储到硬盘中时。
    • 案例
       假设“软件测试工程师管理系统”要保存 10000 个工程师信息,则保存时 engineer.txt文件可能会有20M大小,如果此时磁盘只有10M可用空间了, “软件测试工程师管理系统”会如何动作呢?
    • 测试方法
       创建满容量或近乎满容量的文件系统,然后强制执行各种通过输入或输出 访问文件系统的操作。
       打开足够多的文件,文件打开时会强制创建备份副本,从而占用双倍的存 储空间。
       使用工具 CannedHeat,模拟文件系统超载。

    2)更改文件访问权限

    • 适用于对文件进行读写的应用程序。
    • 测试方法
      • 不同的用户对相同文件具有不同的访问权限,需要考虑登录同一台机器的 多个用户操作相同文件的权限问题。
         打开一个文件,在操作系统中修改该文件的访问权限。有些操作系统 允许权限高的用户控制一般用户已经打开的文件。
      • 两个应用程序打开,关闭同一个文件。
         如把同一应用程序的不同版本安装在同一机器上,在不同版本的应用 程序中打开和关闭同一文件;
         试着在某个应用程序中打开在另一个程序中已打开的文件,这可能会 导致文件访问权限上出现冲突。

    3)使介质忙或不可用

    • 适用于应用程序的运行需要消耗大量内存或运行时需求其他相关软件同时运 行的情况。
       大多数操作系统能同时运行多个应用程序,但相互切换时会有延迟,但是 没有对错误响应。
    • 测试方法
       通过启动大量应用程序,强制它们都打开并保存文件来使文件系统处于忙 的状态;或者同时下载大量文件也可以使后台拥挤。
       使用一些测试工具来模拟磁盘的状况。

    4)介质损坏

    • 使用场合
       损坏的介质可能使操作系统传回错误代码,这些错误代码可能没有在应用 程序中编程处理。
    • 测试方法
       损坏介质的方法使用不很多,只有少数公司采用,大多是开发操作系统、 设备驱动程序以及以安全为主的应用程序的公司会采用这种测试方法。确 定是否使用该方法,主要要考虑数据对用户的重要性。
       该方法可以使用实际损坏了的介质。检查应用程序对错误的处理能力,应 用程序可以对错误进行处理或者将问题告诉用户,并且要确保用户数据文 件不丢失、不损坏。
       也可以通过软件模拟。

    6 编写测试点

    将测试点写入测试需求分析说明书,或者 XMind 等,留存下以供将来编写测试用例使
    用。
    在这里插入图片描述

    四、编写测试用例

    1.编写测试用例(一般公司都有固定模板)

    在这里插入图片描述

    2 测试用例的写作说明

    2.1 用例编号/序号
    简单、唯一。

    2.2 用例说明

    • 也称测试点、检查点、测试概述、用例概述、测试说明;
    • 用一句话对测试用例进行概述;
    • 可以总结测试目的;
    • 可以用疑问句表示;
    • 可以用“检查、验证、测试”等字眼(如验证 QQ 默认安装);
    • 最好看到这句话就能知道如何测试;
    • 尽量唯一(决策表可能会有重复的测试说明);
    • 用例执行多轮时,越往后执行可能越快,如果用例写得好,直接看概述就行。

    2.3 初始条件

    • 也称预置条件、前提条件;
    • 初始条件要是一个状态,而且是静态的,如管理员已登录后台;
    • 初始条件是第一步操作步骤之前的状态,不能太远,不用从头写到尾
    • 很多项目中不写预置条件。

    2.4 操作步骤

    • 若对数据要求高,需要把数据分离出来;
    • 步骤要都有序号;
    • 每一步用分号分开,最后用一个句号;
    • 每一步必须换行;
    • 参数前加冒号(如用户名:admin);
    • 涉及按钮界面用【】、“”等成对符号间隔;
    • 功能的详细用例步骤 4-6 步左右;
    • 最后一步一定是个动作,不能写结果。

    2.5 预期结果

    • 是一个状态;
    • 如果参考文档中有描述,原封不动的抄过来;如果文档中没有具体要求,则点要一 致,可以有几个点,如 QQ 默认安装,应能启动、默认选项匹配等。

    2.6 用例状态

    • 通过、失败、阻塞、未执行、搁置、无效用例…
    • 初始条件达不到时,一般用例状态设置为阻塞。
    • 看如何执行用例,执行完关心什么来定。

    2.7 优先级

    • 用例的执行顺序。
    3.测试用例的评审和管理
    • 保证测试用例质量的方法
       首先,要对用户需求、服务质量要求、产品特性有深刻且全面的理解
       其次,采取正确、恰当的方法进行用例设计;
       再者,按照测试用例的标准格式或规范的模板来书写测试用例;
       最后,对测试用例的检查、评审,也是提高测试用例质量的主要且有效的手段。

    五、提交缺陷报告

    一) 软件缺陷的判定

    1 什么是缺陷
    软件存在着不符合质量需求或违背软件用户、客户、企业意愿的问题,这就是软件缺陷 (Defect),又叫“Bug(臭虫)”。
    2 软件缺陷的判定准则

    • 软件未达到产品说明书标明的功能;
       产品说明书简称为说明(spec)或产品说明(productspec),是软件开发小组 的一个协定。它对开发的产品进行定义,给出产品的细节、如何做、做什么、 不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。
    • 软件出现了产品说明书指明不会出现的错误;
       如金融软件 7*24 工作不能宕机
    • 软件功能超出产品说明书指明范围;
    • 软件未达到产品说明书虽未指出但应达到的目标;
       如软件在断电时的意外处理
    • 软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
       主要体现在易用性方面。
      3 软件缺陷的表现形式
    • 用户要求的功能、特性没有实现或部分实现。
    • 运行出错,包括运行中断、系统崩溃、界面混乱等。
    • 数据结果不正确、精度不够、不完整或格式不统一。
    • 文字显示内容不正确或拼写错误。
    • 系统性能低下、系统资源浪费。
      4 分离和再现软件缺陷
    • 发现缺陷后,应该做好分离和再现,排查发现的“缺陷”是不是软件本身的问题, 然后才能提交。
    • 再现 3 次
       重现
       复现
      5 避免提交缺陷的缺陷和重复缺陷
    • 缺陷的缺陷
       是测试人员提交的不是缺陷的缺陷;
       是一种无效缺陷;
       此类缺陷常使测试人员遭受指责。
      • 怎么办 : 正确理解需求; 做好复现。
    • 重复缺陷
       同一个缺陷 A 测试工程师提交后,B 测试工程师又提交或者自己提交的缺陷 与之前提交的缺陷相同或类似;
       是一种无效缺陷;
      • 怎么办 : 尽量避免两个人同时测试同一模块; 自己提交的缺陷与自己的重复,提交前查找一下,增强开发知识。

    6 处理无法再现的缺陷

    • 首先,对这样的缺陷进行详细的记录,使用不同办法去尝试复现。
    • 其次,要合理地安排时间,要考虑到测试项目的整体进度,对一时难以再现的缺陷 可以暂时搁置,以保证项目的正常进度,并尽快提交给开发人员。
    • 最后,在测试过程中对未再现缺陷予以关注。
      7 处理有争议的缺陷
    • 跟有关人员进行沟通、讨论;
    • 搁置。
    二) 提交缺陷报告

    1 什么是缺陷报告
    缺陷报告是对缺陷进行记录、分类和跟踪的文档。
    2 缺陷报告的读者对象

    • 软件开发人员
       报告缺陷是为了缺陷得到修复。
       希望获得缺陷的本质特征和复现步骤。
    • 质量管理人员、市场人员、技术支持人员
    •  希望获得缺陷的严重程度和分布情况,以及对市场和用户的影响程度。
      3 缺陷报告的写作准则(5C)
    • Correct(准确)
       每个组成部分的描述准确,不会引起误解;
    • Clear(清晰)
       每个组成部分的描述清晰,易于理解;
    • Concise(简洁)
       只包含必不可少的信息,不包括任何多余的内容;
    • Complete(完整)
       包含复现该缺陷的完整步骤和其他本质信息;
    • Consistent(一致)
       按照一致的格式书写全部缺陷报告。
      4 缺陷报告的组织结构
    • 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息
    • 预处理
    • 复现步骤
    • 期望结果
    • 实际结果
    • 缺陷的严重程度
    • 缺陷的优先级
    • 测试的软件和硬件环境
    • 测试的软件版本
    • 缺陷的类型
    • 注释文字和缺陷截图
      5 缺陷报告的写作要求
      5.1 缺陷标题
    • 尽量按缺陷发生的原因与结果的方式书写;
       执行完 A 后,发生 B;
       在什么地方,做了什么事情,出了什么结果;
      使用“在…以后”,“在…时候”或“在…期间”等连结词有助于描 述缺陷的原因和结果。
    • 避免使用模糊不清的词语;
    • 为了方便搜索和查询,尽量使用关键字;
    • 为了便于他人理解,避免使术语、俚语或过分具体的测试细节。
      5.2 复现步骤
    • 提供测试的预备步骤和信息;
    • 步骤完整,准确,简短,没有缺漏任何操作步骤,没有任何多余的步骤;
    • 将常见步骤合并为较少步骤;
    • 简单地一步一步地引导复现该缺陷;
    • 每一个步骤尽量只记录一个操作;
    • 每一个步骤前使用数字对步骤编号;
    • 尽量使用短语和短句,避免复杂句型和句式;
       只记录各个操作步骤是什么,不要包括每个步骤的执行结果。
      5.3 预期结果
       软件应该具有的结果,或者说正确结果应该是什么样子。
      5.4 实际结果
    • 实际结果的描述要列出具体的表现行为,而不是简单的指出“不正确”或“不起作 用”。
    • 如果一个动作产生彼此不同的多个缺陷结果,或者一个动作将产生一个结果,而这 个结果又产生另一个结果。为了易于阅读,这些结果应该使用数字列表分隔开来。 如实际结果:
       1.显示“命令代码行…错误”;
       2.显示“并且终止…服务”。
      5.5 注释/截图
    • 可以包含以下各方面的内容:
       截取缺陷特征图像文件;
       测试过程所使用的测试文件;
       测试附加的打印机驱动程序;
       再次描述重点,避免开发人员将缺陷退回给测试人员补充更多信息;
       再次指明该缺陷是否在前一版本已经存在;
       多个平台之间是否具有不同表现;
       注释包含缺陷的隔离信息,指出缺陷的具体影响范围。
    • 如,缺陷的注释可能包含下面的内容:
       能在 Win2000 和 WinXP 文本框中显示文本内容,但不支持 Win98
       屏幕刷新后,现象会消失。
       使用二进制文件,不存在该错误。
       参见附加的使用说明书和测试文件。
      6 怎么提交高质量的缺陷报告
    • 尽早提交缺陷报告。
    • 清楚地说明此问题对用户价值的危害。  提供尽可能多的技术信息(如包含复现该缺陷需要的环境变量或测试所用的数据文 件),方便程序员调试。
    • 报告的软件缺陷进行了必要的隔离,报告的缺陷信息具体、准确。
    • 易于搜索软件测试报告的缺陷。
    • 一个缺陷报告中只报告了一种缺陷。
    • 缺陷报告中不要提问题。
    • 避免常见的错误
       我(I)、你(You)、他/她(He/She)
       情绪化的语言和强调符号!!!
       似乎(Seems)、看上去可能(Appearstobe)
       认为比较幽默的内容  不确定的测试问题(Issues)/不确定是否是缺陷
    三) 缺陷的分类

    1 缺陷的分类标准
    在这里插入图片描述

    2 根据缺陷类型对缺陷分类

    • 功能缺陷
    • 界面缺陷
    • 文档缺陷
    • 代码缺陷
    • 算法错误
    • 性能缺陷

    3 根据缺陷的等级对缺陷分类

    • A 类—致命缺陷,包括以下各种错误:
       由于程序所引起的死机,非法退出;
       死循环;
       数据库发生死锁;
       因错误操作导致的程序中断;
       功能错误;
       与数据库连接错误;
       数据通讯错误
    • B 类—严重缺陷,包括以下各种错误:
       程序错误;
       程序接口错误;
       数据库的表、业务规则、缺省值未加完整性等约束条件
    • C 类一般缺陷,包括以下各种错误:
       操作界面错误(包括数据窗口内列名定义、含义是否一致);
       打印内容、格式错误;
       简单的输入限制未放在前台进行控制;
       删除操作未给出提示;
       数据库表中有过多的空字段
    • D 类—较小缺陷,包括以下各种错误:
       界面不规范;
       辅助说明描述不清楚;
       输入输出不规范;
       长操作未给用户提示;
       提示窗口文字未采用行业术语;
       可输入区域和只读区域没有明显的区分标志
    • E 类—意见或建议
      4 根据缺陷处理的优先级对缺陷分类
      在这里插入图片描述

    5 根据缺陷状态对缺陷分类

    缺陷状态描述
    Submitted/已提交已提交的缺陷
    Open/打开确认"提交的缺陷",等待处理
    Rejected/已拒绝拒绝"提交的缺陷",不需要修复或不是缺陷
    Resolved/已解决缺陷被修复
    Verified/已验证确认缺陷确实被修正
    Closed/已关闭确认被修复的缺陷,将其关闭
    四、 缺陷报告的处理

    1 缺陷报告的简单处理流程/缺陷的生命周期
    在这里插入图片描述

    • 软件测试人员提交缺陷报告;
    • 测试负责人审核后将缺陷报告分配给相关的开发人员修改;
    • 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测;
    • 返测通过的缺陷报告由负责人关闭,返测未通过的缺陷报告直接返回开发人员重新 修改,缺陷报告直到缺陷被修复以后才关闭;
    • 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开,这些报告一旦被再次打 开应该立即处理。

    2 缺陷报告的标准处理流程

    • 正常缺陷
    • 重复缺陷
    • 无效缺陷
    • 推迟修改
    • 验证不通过
    • 描述不清楚
      在这里插入图片描述

    3 缺陷跟踪管理系统/缺陷管理工具
    3.1 缺陷管理工具的功能

    • 缺陷提交
    • 缺陷跟踪
    • 缺陷分析
       有效的缺陷分析不仅可以评价软件质量,同时可以帮助项目组很好地掌握和评 估软件的研发过程,进而改进研发过程,未对缺陷进行分析就无法对研发流程 进行改进。
       缺陷分析还能为软件新版本的开发提供宝贵的经验,进而在项目开展之前,指 定准确、有效的项目控制计划,为开发高质量的软件产品提供保障。
      3.2 常见缺陷管理工具
    • Bugzilla
    • Bugfree
    • Mantis
    • Jira
    • ZenTao(禅道)
    • QualityCenter/Application Lifecycle Management

    这只是一篇学习笔记,学习源:https://www.bilibili.com/video/BV1EJ41147fN,
    感兴趣的小伙伴们可以去学学,就是讲得有些太详细了

    展开全文
  • 对于一款软件或者程序而言,功能能不能正常使用是人们评估产品最基础标准,所以做好软件功能测试对提升产品质量,建立用户口碑有重要意义。 比如一款手游产品,用户在点击每个功能按钮时是否能正常执行,业务逻辑...

    在这里插入图片描述
    随着信息化进程的推进,各类APP、软件产品已经深入人们的生活住行。对于一款软件或者程序而言,功能能不能正常使用是人们评估产品最基础标准,所以做好软件功能测试对提升产品质量,建立用户口碑有重要意义。

    比如一款手游产品,用户在点击每个功能按钮时是否能正常执行,业务逻辑是否准确,字符是否能正常输入都是需要进行测试的功能测试点。在软件测试过程中,提取测试点是后续工作进展的必经步骤,那么常见的功能测试点有哪些,怎么做好软件功能测试呢?小编对此进行简单整理,供大家参考。

    在这里插入图片描述

    一、功能测试点有哪些?

    1、输入框;基于用户角度考虑,输入字符、数值、日期、重复信息等是否可能会导致系统错误。对于不同的字符命令,系统是否能正常处理。

    2、搜索功能;用户进行查询时,是否能搜索查到。不同查询条件间反复测试。

    3、增添改删功能;用户在进行增添改删时,系统是否会进行提示,页面数据是否有及时更新。

    4、密码功能;需要测试人员反复进行新旧密码测试,产品是否会进行报错提示,新旧密码区分及修改等。

    5、注册登录功能;用户注册成功后是否会跳向指定页面,反复输入不同的用户名,产品是否能正常识别。

    6、文件测试;比如上传图片时,图片大小及文件类型不同,看是否给出提示。

    7、界面测试;界面风格、样式、颜色、格式是否对齐,操作是否符合用户的习惯等。

    8、按钮检查;返回键、回车键等检查,看系统是否报错。

    9、兼容性问题等;不同版本,不同浏览器上运行,各项功能是否兼容。

    二、怎么做好软件功能测试?

    1、完善的测试环境;软件功能测试过程中需要考虑网络环境、软硬件平台环境配置、用户测试等,需要在完善的测试环境下进行。

    2、第三方测试机构;为了全面系统的做好软件功能测试,减少功能点遗漏,建议企业还是通过第三方软件测试机构进行测试。


    最后: 给大家推荐一个 q 群:902061117 里面有许多资料共享!资料都是面试时面试官必问的知识点,也包括了很多测试行业常见知识,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

    如果对你有一点点帮助,各位的「点赞」就是小编创作的最大动力,我们下篇文章见!

    好文推荐

    2021软件测试工程师面试题汇总(内含答案)-看完BATJ面试官对你竖起大拇指!

    什么样的人适合从事软件测试工作?

    软件测试和软件开发哪个发展更好

    那个准点下班的人,比我先升职了…

    在这里插入图片描述

    展开全文
  • 一款非常强大的批量更改文件名软件,可以批量修改文件名,支持各种位置更改,以及更改后缀名等等功能,对于需要批量修改文件名来说,非常方便。
  • 软件功能特性

    千次阅读 2020-03-26 00:03:51
    ( ISO/IEC 9126定义的软件质量特性) 一、功能性(Functionality) 1、适合性(Suitability):解释有没有-提供了相应的功能 2、准确性(accuracy):正确(用户需要的)解释对不对 3、互操作性(Interoperability)...
  • 软件项目报价单模板,可用于任何软件行业项目的报价,包括报价清单,说明,功能列表等
  • 现在基本家家户户都已经有电脑了,很多朋友购买电脑的时候只关注品牌和性能。所有很多朋友不知道电脑其实是有机器码的。机器码可以很好的对电脑中...下面就给大家推荐一款电脑机器码修改软件。电脑机器码序列号修改...
  • 佳博打印机ip修改工具是一款功能强大的打印机IP设置工具,可以轻松修改打印机的IP地址,为打印机的管理使用提供了便利...软件的使用简单便捷,可以轻松解决各种IP地址的问题,满足用户的各种佳博打印机ip修改功能需求。
  • 本人Windows7旗舰版在安装IIS时,总是提示“出现错误,并非所有的功能被成功修改”,试了网上很多方法,没有一个成功的,都是忽悠人的。本文档是我亲自测试的结果,保证成功使用。
  • SPSS是什么?SPSS软件功能有哪些?

    千次阅读 2020-06-15 17:15:23
    随着SPSS产品服务领域的扩大和服务深度的增加,英文名称在2000年正式更改为“统计产品和服务解决方案”。 SPSS的起源和发展历史 SPSS是世界上最早的统计分析软件。它是1968年由美国斯坦福大学的三名研究生Norman H....
  • 功能性需求,一般是我们显性易见的,就是一般实现了什么功能,提供了什么服务,大体我认为问题中提到,或者我们日常所说的:...功能性需求,会因为不同的网站,不同的软件,不同的业务和使用目的,大相径庭,五花八门,
  • 关于软件功能点评估的问题(一)

    千次阅读 2018-07-01 10:24:52
    通过仅两个多月的学习和使用,目前对软件功能点评估有一些初浅的认识,望高人前辈指点。情况一: 在评估过程中,遇到大平台系统中的某些小系统复用某另一平台中的系统,或大部分引用,修改部分功能或添加一些功能;...
  • 有什么办法可以永久解决win10系统控制面板“卸载或更改程序”窗口不显示已安装软件的问题,面对win10系统控制面板“卸载或更改程序”窗口不显示已安装软件的图文步骤非常简单,只需要 1、通过修改注册表,点击开始-...
  • 现在很多的数码产品为了保证安全和防伪都有设置机器码这种东西,但是机器码不是一成不变的,机器码可以根据实际需要进行修改,您只需使用机器码修改软件进行修改就可以了。电脑机器码序列号修改软件virtual...
  • 功能测试指的是在软件测试中,用于检查软件应用程序的的测试,它与功能测试都是软件测试的两大重要组成部分,并影响着用户对产品的体验。非功能测试包括了性能测试、压力测试、负载测试、低资源测试、容量测试和...
  • 若企业ERP系统选择和业务流程优化后,ERP软件和企业的需求差异依然存在,并且不能通过业务流程转换来消除这些差异,ERP...ERP软件修改之前,ERP系统厂商或二次开发合作伙伴应与企业业务部门共同明确企业对ERP软件二次开
  • 软件开发费用评估 功能点估算法

    万次阅读 2020-07-07 16:55:39
    定制软件开发服务费可按照功能点估算法或工作量估算法进行估算,原则上200万元以上项目需按功能点法估算。具体公式如下: 定制软件开发服务费用=功能点数×软件开发生产率基准/人月折算系数×软件开发基准人月费率+...
  • 大家都知道西门子博图软件功能强大,但是它的操作界面对于新手也是比较复杂的,菜单栏、工具栏、右键菜单、对话框等比较多。刚刚开始使用这款软件的新手,基本上都会遇到各种各样操作上的问题,很多人遇到一个红色...
  • exe软件如何更改标题?

    千次阅读 2021-02-12 21:26:57
    由于某些需求,有些朋友可能需要将exe软件标题更改掉,软件图标也更改掉。以下依OBS软件为例,更改exe软件的标题。 OBS为开源的软件,能免费使用。功能为推流,拉流,转播,录播等。 1、下载Hex Editor Neo 2、...
  • 软件系统产品信息安全功能点要求

    万次阅读 2018-10-15 09:35:06
    在需求分析阶段,应明确定义系统必须或可以达到的身份认证功能。 必须的安全要求: 账户管理方式 账户的产生、修改、变更、删除以及身份认证应采用统一的身份认证平台来实现。 认证失败后的处理方式设计,防止...
  • CorelDRAW x8警告您所用的软件疑似非法盗版软件,软件功能3天内将被永久停用,解决方法教程 1:打开控制面板的“添加与删除程序”(卸载或更改程序),找到CorelDRAW X8(CDR X8.cdr x8),卸载再次安装最新版。文章...
  • 软件项目工作量评估方法很多,如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文主要对功能点方法(FPA)简述。 功能点 FPA 方法 (一) 简介 FPA 是从用户角度出发度量软件规模的一种...
  • 软件设计有三个要素:流程、功能方法和数据结构 一 设计流程要点 功能方法考虑性能,流程方法考虑设计模式。 1. 愿景 你需要做个什么东西,要做到什么水平。 2. 边界 你需要干什么,什么你不用干,什么你不能干。 3....
  • win10电脑总是自动安装软件怎么办

    千次阅读 2021-07-28 00:32:38
    3、进入到【服务】功能页面后,我们可以看到很多的计算机应用程序,这时需要找到【Windows Installer】,双击鼠标打开窗口。在【常规】中将【启动类型】更改为【禁用】,最后点击确定就可以了。...
  • 造价人员只需填写一个表(功能点详情表),软件费用、功能点统计全自动计算。 用户也可以根据实际要求,修改表一(费用测算)中的部分参数,例如调整因子、功能点耗时率、行业平均工资等。相关公式已经全部配置完毕...
  • 功能修改电脑机器码序列号工具

    千次阅读 2021-07-06 06:50:24
    相似软件版本说明软件地址多功能修改电脑机器码序列号工具软件介绍电脑机器码序列号修改软件是一款windows下可视化可定制虚拟硬件信息的工具。它并不是真正的修改,而是虚拟修改,您重启计算机后将恢...
  • A卡修改BIOS软件/刷显卡BIOS软件

    千次阅读 2021-01-11 23:39:00
    ·ATI./AMD 显卡BIOS修改软件◆TechPowerUp Radeon Bios Editor(RBE)-修改HD6000系列及以前这款RBE是专门用来修改A卡BIOS的软件,很经典但很久没更新了,支持HD6000系列及以前的A卡。它的功能也是相当全面,显卡的...
  • 涉及注册表操作,无经验者建议先备份注册表①在注册表中定位到HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall在该子文件夹中通过右侧信息进行确认,删除已卸载软件的失效...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,174,433
精华内容 469,773
关键字:

修改软件功能