2019-09-28 17:40:37 weixin_38742571 阅读数 943

使用Jenkins集成Sonar的原因

开发人员对于检测出有问题的代码可能会出现漏改和忘改的情况,怎么避免这个问题呢?
使用Jenkins集成Sonar
对所有代码进行全量检测
每次项目构建均可进行代码质量的检查
使用Jenkins集成Sonar
为了更好的说明上述问题,这里分享一段Leon老师的课程视频

spring cloud

如何使用Jenkins集成Sonar?

  1. 在Jenkins中安装SonarQube揑件
  2. 生成Sonar Token
  3. 配置Sonar服务地址
  4. 配置SonarQube Scanner
  5. 添加并配置扫描配置文件
  6. 配置检测脚本
    2)配置项目相关的sonar

点相关连的项目,进入配置,Post Steps一栏,增加“Execute SonarQube Scanner”(sonarscanner可以本地安装,也可以在Jenkins中安装,需提前配置),在不集成Jenkins中,需要在分析的项目工程根目录下,自己增加sonar-project.properties文件,并加入配置,但是在Jenkins中集成的时候,就不需要新增这个文件了,但是要在“Analysis properties”一项中增加相应的配置。配置的内容就是需要在sonar-project.properties文件中增加的内容。如下图所示:

其中:sonar.projectKey,sonar.projectName是项目的名称,也可以在项目工程的pom.xml中找

       sonar.projectVersion是pom.xml中的版本信息

       sonar.sources是需要sonar分析的项目工程中的文件路径

3)构建项目时错误信息:Caused by: Not authorized. Please check the properties sonar.login and sonar.password

这个问题就是第1)个问题中说的,jekins中没有配置sonar的login和password选项而导致的

解决办法:在Analysis properties一项中,加入sonar.login和sonar.password的配置,也就是登录sonar时的用户名和密码。

4)构建项目时错误信息:Caused by: Please provide compiled classes of your project with sonar.java.binaries property

这个问题是sonar扫描的项目工程中没有找到相应的class文件

解决办法:在Analysis properties一项中,增加sonar.java.binaries的配置,这个路径是项目工程中,编译的.class文件的路径。

最后,给大家分享一下Leon老师的课程《7周Spring Cloud微服务架构项目实战》,我最近学习过,感觉很不错,所以分享给大家

博文中展示的视频也是节选至leon老师的精品课程《7周Spring Cloud微服务架构项目实战》

Leon老师主攻Java、Android,7年项目开发和教学经验,4年金融上市公司技术Leader,擅长大型软件架构、微服务应用架构设计。笔者对于Leon老师是很崇拜的。

《7周Spring Cloud微服务架构项目实战》课程主要围绕电商项目大觅网的业务场景,基于微服务原则设计电商项目。
学了这个课程会学到:
1.多种诸如Eureka、Feign、Hystrix、Ribbon、Zuul、Config等技术使用方法,另外
2.基于虚拟化技术Docker+Jenkins实现程序自动发布
3.基于Mycat实现第三方支付接入、整个项目的高并发测试等

下面附全部课程的视频链接,希望对您有用:
https://edu.csdn.net/course/detail/9995?utm_source=springcloud_10

扫码加小姐姐微信拉入交流群,可免费听技术讲座+领学习资料+视频课免费看
在这里插入图片描述

2017-11-23 16:27:27 An1090239782 阅读数 2658

软件测试定义:

  • 软件测试是以提高软件质量为目的;
  • 在规定条件下对软件系统进行审核、运行和评估,验证软件系统是否满足需求;

80—20原则

  • 80%的缺陷聚集在20%的模块中,经常出错的模块改错后还会经常出错。

软件测试应该从需求开始;

  • 需求分析–>概要设计—>详细设计—>编码—>单元测试—>集成测试—>系统测试—>验收测试

软件测试需求的分层理解:

  • 用户需求 业务需求 功能需求

测试分析的级别:

  • 普通测试工程师:按照需求点写测试用例
  • 中级测试工程师:按照场景写测试用例
  • 高级测试工程师:分析用户需求

软件测试的对象

  • 软件是由文档、数据以及程序组成的。

  • 测试应该是对文档、数据以及程序进行的测试。

  • 60%以上的软件错误并不是程序错误,而是分析和设计错误。

  • 测试概念扩大化,提倡软件全生命周期测试的理念。


软件测试分类:

  • 白盒测试(开发工程师):关心软件内部设计和程序实现,主要测试依据是设计文档。

  • 黑盒测试(测试工程师):不关心软件内部,只关心输入输出,主要测试依据是需求文档。

白盒测试:

测试规划:根据程序的内部结构,如语句控制结构,模块间的控制结构以及内部数据结构等进行测试。

优点:能够对程序内部的特定部位进行覆盖测试。

缺点:无法检验程序的外部特性。无法对位实现规格说明的程序欠缺部分进行测试。

方法举例:语句覆盖,判定覆盖,条件覆盖,判定-条件覆盖,基本路径覆盖,循环覆盖。

黑盒测试:

测试规划:根据用户的规格说明,即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系,特别是针对功能进行测试。

优点:能站在用户的立场上进行测试。

缺点:不能测试程序内部特定部位。如果规格说明有误,则无法发现。

方法举例:基于图的测试,等价类划分,边值分析,比较测试。


软件测试阶段:

单元测试、集成测试、系统测试、验收测试是“从小到大”、“由内而外”、“循序渐进”的测试过程;

这里写图片描述

  1. 单元测试的粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”。
  2. 集成测试界于单元测试和系统测试之间,起到“桥梁作用”,一般由开发小组采用白盒加黑盒的方式来测试,既要验证“设计”又要验证“需求”。
  3. 系统测试的粒度最大,一般由独立测试小组采用黑盒方式来测试,主要测试系统是否符合“需求规格说明书”。
  4. 验收测试与系统测试非常相似,主要区别是测试人员不同,验收测试由用户执行。

ALPHA和BETA测试

大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。

目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

软件测试阶段对照表

这里写图片描述


如何提高测试效率

  • 减少冗余的测试
  • 减少无价值的测试

测试优先级选择:

测试优先级:

  1. 哪些功能是软件的特色?
  2. 那些功能是用户最常用的?
  3. 如果系统可以分块卖的话,哪些功能块在销售时最昂贵?
  4. 哪些功能出错将导致用户不满或索赔?
  5. 哪些程序是最复杂、最容易出错的?
  6. 哪些程序是相对独立,应当提前测试的?
  7. 哪些程序最容易扩散错误?
  8. 哪些程序是全系统的性能瓶颈所在?
  9. 哪些程序是开发者最没有信心的?

软件测试关注重点:

  • 根据软件的各种属性,将测试重点划分为:

输入 状态 代码路径 用户数据 执行环境

  • 合法输入&非法输入

明确哪些是合法输入、哪些是非法输入。
关注程序对于非常输入的处理、反应。

处理输入的三种方式:

输入筛选器 :用于防止非法的输入值传递给程序。
列表框、下拉框是常用的输入筛选器。
测试关注点: 提供的输入选项本身是否正确;是否可以绕过筛选器的屏蔽而进入系统
输入检查

  • 使用输出来指导输入选择

首先把所有的输出结果罗列出来;
然后确定哪些输入会引发这些输出;
该方法可以保证重要的场景都被测试。

  • 状态
  • -

软件的一个状态就是空间中的一个点,由它所有内部数据结构的取值来唯一确定。
实例:12306网站,首次订票和第二次订同一张票,是完全不同的两个状态,应该视为两个不同的用户从场景,分别设计不同的测试用例。

  • 用户数据
  • -

创建一个含有特定数据的测试环境,含有的数据应该和软件真实使用的数据尽量相似。
常用的方法是取得用户的数据导入到测试环境中。

  • 运行环境
  • -

软件运行的环境本身也是一种输入源,测试人员在产品发布之前应尽量尝试各种各样的用户环境。

2017-10-27 20:54:42 qq_16328677 阅读数 3899

软件测试–配置测试
配置测试是指使用各种硬件来测试软件运行的过程。
1.分离测试缺陷
判断缺陷是配置问题而不仅仅是普通缺陷最可靠的方法是,在另外一台有完全不同配置的计算机上一步步地执行导致问题的相同操作。若没有缺陷产生,就极有可能是特定的配置问题,在独特的硬件配置下才会暴露出来。
2.执行任务
确定测试哪些设备和如何测试的决定过程是相当直观的等价划分工作。在计划配置测试时应该采用的一般过程如下:

  • 确定所需的硬件类型:在选择哪些硬件来测试时容易忽略的一个特性例子就是联机注册。如果软件有联机注册功能,就需要把调制解调器和网络通信考虑在配置测试中。
  • 确定有哪些厂商的硬件、型号和驱动程序可以用。
  • 确定可能的硬件特性、模式和选项
  • 将确定好的硬件配置缩减为可控制的范围
  • 明确与硬件配置有关的软件唯一特性:唯一是指只需测试那些与硬件交互式互不相同(不同等价划分)的特性即可。
  • 设计在每一种配置中执行的测试用例
  • 在每一种配置中执行测试
  • 反复测试直到小组对结果满意为止:配置测试一般不会贯穿整个项目期间

3.获得硬件:对于需要的硬件来说,可以根据实际情况进行解决。
4.明确硬件标准

2018-12-26 21:59:37 qq_32126633 阅读数 4652

花了一个多星期整理上课使用的ppt,书写不易,请大家多多支持

概述

计算机系统的软件可靠性问题

  • 1994年,Intel奔腾芯片缺陷
  • 千年虫问题
  • ”冲击波“计算机病毒
  • 2008年奥运会门票预售叫停
    • 系统访问量超8倍
    • 票务系统抗压测试
    • 性能测试

软件质量

软件质量包括正确性,可靠性,可读性,可移植性和健壮性,主要含义是软件的可靠性

软件可靠性

特定环境下,在给定时间内,无障碍运行的概率

度量

  • 软件中初始故障的数量
  • 软件经过测试后,通过查错,改错,在软件中剩余故障的数量
  • 平均无故障时间
  • 故障间隔的时间长度
  • 故障发生率
  • 经过预测下次故障的发生时间

软件故障

定义

  • 从内部看,软件故障是软件产品开发或维护过程中存在的错误,毛病等各种问题
  • 从外部看,软件故障是系统所需要实现的某种功能的失效或违背

计算机系统或程序存在任何一种破坏正常运行能力的问题,错误,或者隐藏的功能缺陷等
软件故障导致软件产品在某种程度上不能满足用户的需求

  • 硬件故障

    物理性能恶化

  • 软件故障
    设计阶段人为因素造成的
  • 操作故障
    操作人员和维护人员的错误
  • 环境故障
    电源,外界干扰,地震,火灾,病毒等各种外界因素引起的故障

错误

人是会犯错的。过失是人犯下的,是人做一件错事或认为产生的一个不正确的结果

故障

故障时错误的结果

失效

故障引起的结果

软件测试与软件可靠性

  • 软件中都会有故障存在
  • 可以减少故障的引入,但是不可能完全杜绝软件中的故障

软件测试

  • 软件需求分析,设计说明和编码的最终复审
  • 是软件质量保证的关键步骤
  • 是为了发现故障而执行程序的过程

定义:

  1. 是否满足规定的需求
  2. 是否有差别
    测试是为了发现故障而执行程序的过程
  • 谁来执行
  • 测试什么
  • 什么时候测试
  • 怎样进行测试
  • 测试停止的标准
    • 成功采用了具体的测试用例设计方法
    • 每一类覆盖的覆盖率
    • 故障检测率
    • 检测出故障的具体数量或消耗的具体时间

软件生存周期

  • 制定计划
  • 需求分析
  • 设计
  • 程序编码
  • 测试
  • 运行维护

黑盒测试

不考虑内部结构和内部特性,只根据需求规格说明书,设计测试用例,检查程序的功能是否按照规范说明的规定正确的执行

  • 一切实际测试都是不彻底的

测试原则

黑盒测试与白盒测试

黑盒测试

  • 等价类划分
  • 边界值分析
  • 决策表驱动

白盒测试

  • 逻辑覆盖
  • 数据流测试
  • 域测试
  • 符号测试
  • 路径分析
  • 程序变异
  • 程序插装技术

软件测试过程

软件开发是自顶向下,软件测试自底向上

单元测试

又称模块测试,针对程序模块来进行正确性检验的测试工作

  • 模块接口测试
  • 局部数据结构测试
  • 路径测试
  • 错误处理测试
  • 边界测试

静态测试与动态测试

静态测试

不利用计算机运行被测试的程序,通过其他手段达到检测的目的

动态测试

通过运行和使用被测程序,发现软件故障,达到检测目的

回归测试

对程序进行测试已确定是否因修复故障而引入了新的故障

α\alpha测试

由一个用户在开发环境下进行的测试
目的是平价产品的功能,可使用性,可靠性,性能和支持

β\beta测试

软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场

α\alpha测试达到一定的可靠程度时才能进行β\beta测试,它处在整个测试的最后阶段

测试与调试

调试不属于测试
成功的测试发现错误从而引起调试的进行

测试生命周期

  • 测试计划
  • 测试设计
  • 测试开发
  • 测试执行
  • 测试评估

测试工具

测试评估

  • 测试覆盖测试
  • 软件故障评估
  • 测试有效性评估

软件质量评估

检查和评价当前软件开发过程,并设法达到防止软件故障出现

软件过程成熟度

  1. 初始度
  2. 可重复级
  3. 定义明确
  4. 定量管理级
  5. 优化级

第二章

三角形问题

三角形问题之所以复杂,是因为输入与输出之间的关系比较复杂

NextDate函数

  • 讨论输入域的复杂性
  • 确定闰年的规则

股佣金问题

功能性测试(黑盒测试)



优点

  • 功能性测试与软件如何实现无关
  • 测试用例的开发可以和实现并行进行

问题

  • 测试用例之间可能存在严重的冗余
  • 可能有未被测试的软件漏洞

常用测试方法

  • 边界值分析
  • 等价类划分
  • 决策表驱动法

边界值分析

基本原理:故障往往出现在输入变量的边界值附近
基本思想: 利用输入变量的最小值,稍大于最小值,正常值,稍小于最大值,最大值

  • 健壮性测试

    除了取5个边界值,还要采用一个略大于最大值,略小于最小值,看看超过极限时系统会出现什么情况

  • 最坏情况测试

    除了五个边界值,对五个边界值进行笛卡尔乘积运算,生成测试用例

等价类测试

把输入域划分成若干个互不相交的一组子集–等价类

  • 特点

    • 如果等价类中的一个元素作为测试数据进行测试不能发现程序中的故障,那么使用集合中的其他元素进行测试也不能发现故障

    对于揭露程序的故障来说,等价类的每个元素是等效的

  • 步骤

    1. 确定等价类
      
      • 有效等价类
        • 对程序规格说明,是有意义的,合理的输入数据所构成的集合

        具体问题中,有效等价类可以是一个,也可以是多个

      • 无效等价类
        • 对程序来说,是不合理或无意义的输入数据所构成的集合

        无效等价类可以一个,也可以多个

    2. 确定测试用例
      1. 为每个等价类规定一个唯一的编号
      2. 设计一个新的测试用例,尽可能多覆盖尚未被覆盖的有效等价类
      3. 设计一个新的测试用例,覆盖且覆盖一个还没有被覆盖的无效等价类
  • 弱一般等价类测试

    • 测试数据不考虑无效数据值
    • 测试用例使用每个等价类中的一个值
  • 强一般等价类测试

    • 需要将所有的等价类进行笛卡尔乘积,每部分设计一个测试用例
      • 笛卡尔乘积确保了两种意义上的完备性
        • 覆盖了所有等价类
        • 采用了所有可能的输入组合
  • 健壮性等价类测试

    • 遂与有效输入,测试用例使用每个有效类中的一个值
    • 对于无效输入,一个测试用例只拥有一个无效值,其他值都有效

      健壮指的是无效值的考虑
      强指的是多故障的假设

基于决策表的测试

最严格,最有逻辑严格性的测试方法

  • 优点
    • 把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏
  • 决策表

    描述不同条件集合下采取行动的若干组合情况

    • 利用决策表,可以很好的发现冗余和不一致性
    • 适用于
      • if-then-else逻辑很突出
      • 输入变量存在逻辑关系
      • 设计输入变量子集的计算
      • 输入与输出之间存在因果关系
      • 很高圈复杂度的程序

第三章 结构性测试

  • 特点
    • 基于被测试程序的源代码,而不是软件规格说明
    • 更容易发现软件测试故障,常用于单元测试

结构性测试

白盒测试又称结构测试或者基于程序的测试.

  • 该方法将被测对象看做一个打开的盒子,允许内部人员检查其内部结构.测试人员根据程序内部结构特性,设计,选择测试用例,检查程序的每条路径是否都按照预定的要求正确执行.

常见的白盒测试方法有:

  • 逻辑覆盖
  • 数据流测试
  • 域测试
  • 符号测试
  • 路径分析
  • 程序变异
  • 程序插装

逻辑覆盖

使用最广泛

  • 要求对被测试程序逻辑结构有清楚的了解,要能掌握程序的所有细节
  • 要求对被测试程序的结构做到一定程度的覆盖
  • 分为:
    • 语义覆盖

    是比较弱的测试覆盖准则

    • 判定覆盖

    又称之为分支覆盖,使得每个判断的取真分支和取假分支至少执行一次,即判断的真假值均要被检测

    • 条件覆盖

    每个判断的每个条件的可能取值至少被执行一次

    • 判定-条件覆盖

    判断中的每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果也至少被执行一次

    • 路径覆盖

程序控制图

  • 重要性
    明确地描述测试用例和测试用例所执行的程序部分之间的关系.

McCabe的基本路径法

测试观点

强连通图的圈数就是图中线性独立环路的数目

  1. 选择一条基线路径,一般选择有较多判断结点的路径
  2. 回溯基线路径

符号测试

基本思想

  • 允许程序的输入不仅可以是具体的数值数据,而且还可以包括符号值.
  • 执行过程中以符号计算代替了普通执行中的数值计算,所得到的结果自然是符号公式或符号谓词

    普通测试执行的事算数运算,符号测试执行的是代数计算

程序插装

借助于往被测试程序中插入操作来实现测试目的的方法

考虑的方面

  • 探测哪些信息
  • 在程序的什么部位设置探测点
  • 需要设置多少个探测点

用途

  1. 覆盖分析
  2. 监控和断言
  3. 查找数据流异常

指导方针



基本原则

  • 具有高圈复杂度的程序需要更充分的测试
  • 一般选择V(G)=10
  • 如果单元具有更高的复杂度,可以简化单元或计划更充分的测试
  • 简化单元的最好方法是解决非结构化的问题

覆盖指标

  1. 作为一种强制执行的标准
  2. 作为一种机制,指导要求更严格部分的代码有选择地进行测试

数据流测试

数据流是指关注定义点和使用(或引用)点的一种结构测试方法,它和数据流图没有什么联系.
实际上很多数据流测试支持者和研究人员将这种测试方法看作是一种路径测试.
通过分析变量的定义和使用,以查找如引用未定义变量等程序错误,也可以用来查找对以前未曾使用的变量的再次赋值等数据流异常的情况
早期数据流分析常常集中于现在叫定义/引用异常的缺陷:

  • 变量被定义但是从来没有被使用
  • 所使用的变量没有被定义
  • 变量在使用之前被定义了两次

这些异常可以通过程序的索引表发现,可以通过所谓的静态分析发现

  • 将程序中的变量出现分为定义和引用
    • ?语句K执行时改变了程序变量V的值,则称K定义了变量V
    • 若语句k执行时引用了变量V的值,则称K引用了变量V

定义/使用测试

假设V是程序P中的变量的集合,程序P控制流程图用G(P)表示,其中结点代表语句或语句片段,边代表结点序列.G(P)有一个单入口节点和一个单出口节点,并且不允许有某个结点到自身的边

  • 变量V的定义结点,记作DEF(v,n)

    结点n\in G(P)是变量v\inV定义的结点,当且仅当变量V的值由对应结点n的语句或语句片段所定义.

  • 变量v的使用结点n记作USE(v,n)

    结点n\in G(P)是变量v\inV的使用结点,当且仅当变量v的值在对应结点n的语句或语句片段中被引用.

  • 谓词使用,记作P-use

    USE(v,n)是一个谓词使用,当且仅当n是谓词语句,否则,USE(v,n)是计算使用,记作C-use.

  • 定义/使用路径,记作du-path

    如果对某个变量v\inV,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,则称为一条定义/使用路径,结点m称为该定义使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.

  • 定义清晰路径(defination-clear path),记作dc-path

    如果一个变量v\inV,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,并且从m到n的结点序列中没有其他结点对对变量v进行过定义,则从m到n的结点序列称为一条定义清晰路径,结点m称为该定义/使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.

定义/使用路径和定义清晰路径描述了变量从被定义到被引用点数据流向.
不是定义清晰的定义/使用路径,很可能是潜在问题的所在.所以应该特别关注定义/使用路径

定义/使用路径覆盖测试

  • 数据流覆盖测试指标

P是被测程序,G(P)是其控制流图,T是G(P)的路径集合,并假设定义/使用路径都是可执行路径

  • 所有定义/使用路径覆盖准则

    集合T满足程序P的所有定义/使用路径覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v所有使用结点的定义清晰路径.

  • 所有定义覆盖准则

    集合T满足程序P所有定义覆盖准则,当且仅当对所有的变量v\inV,T包含了从变量v的每个定义结点到v的一个使用结点的定义清晰路径.

  • 所有使用覆盖准则

    集合T满足程序P的所有使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v的所有使用结点的定义清晰路径

  • 所有谓词使用/部分计算使用覆盖准则

    集合T满足程序P的所有谓词使用/部分计算使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从v的每个定义结点到v的所有谓词使用结点的定义清晰路径,并且如果v的一个定义没有谓词使用结点,则定义清晰路径至少包含一个计算使用

  • 所有计算使用/部分谓词使用覆盖准则

    集合T满足程序P的所有计算使用/部分谓词使用覆盖准则,当且仅当对所有的变量v\inV,T包含了从每个定义结点v的所有计算使用结点的定义清晰路径,并且如果v的一个定义没有使用计算节点,则定义清晰路径至少包含一个谓词使用.

2017-10-11 19:34:19 ah121210 阅读数 823

软件测试原则:

1.测试显示缺陷的存在

      测试可以显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在为被发现缺陷的可能性,但即使测试没有范县任何缺陷,也不能证明软件或系统是完全正确的。

2.穷尽测试是不可能的

      除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可能的。通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。

3.测试尽早介入

      在软件或系统开发生命周期中,测试活动应该尽可能早的介入,并且应该将关注点放在已经定义的测试目标上。

4.缺陷集群性(80-20原则)

      版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

5.杀虫剂悖论

      采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷。为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。

6.测试活动依赖于测试背景

      针对不同的测试背景,进行的测试活动也是不同的。比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。

7.没有失效不代表系统是可用的

      系统的质量特性不仅仅是功能要求,还包括很多其他方面的要求,比如稳定性,可用性,兼容性等。假如系统无法使用,或者系统不能完成用户的需求和期望,那么此系统的研发是失败的,同时在系统中发现和修改缺陷也是没有任何意义的。



软件测试中的集中测试过程简介

博文 来自: fanxiaobin577328725

软件测试教程

阅读数 1703

没有更多推荐了,返回首页