• 0
  • 0
分享
  • 软件测试中软件质量的把控
  • 饭团🍙 2020-08-14 10:56:24 字数 3288 阅读 2164 收藏 0

  质量是什么?

  怎么做好质量把控?

  质量检测需要那些工具,怎么做流程是什么?

  质量由谁来控制

  质量到底什么程度才算好

  质量的最终含义是什么?

  大家如果没有认真思考过我们上面提出的问题之前请大家闭着眼睛跟我们一起思考下,质量在软件测试过程中起到了什么样的关键性作用,质量在软件中的里程碑是什么

  什么是质量:

  如果对于其他行业来说,质量是什么,是不是可以通俗易懂的理解为是这个物品出库的一个基本标本和最高标准,是否满足用户的基本使用过程和一些更高的满足用户的需求产品

  软件测试中的质量:

  软件测试中的质量太多解释,但在这快我想用度量进行讲解,在测试过程中一个产品要满足上线的要求的不的要从不同方面与角度进行度量,有软件的产品质量情况满不满足用户当初,或当前需求,团队是否经过多方面的测试和压力得到的一个最终结果,软件的环境是否满足大背景下的其他用户使用,讲了那么多我想说的一个最主要的问题就是产品质量不单纯只是看质量,如果想做好的产品或说是满足大背景下的用户就要做到从不同的角度去分析和度量一个产品的最终质量,最终达到我们要求满足的高标准验收和交付,这才是软件产品测试中我们想要的,追求的质量。

  软件质量的重要性是不言而喻的,但是当所有人都意识到它的重要性的时候,却很少有人能够清晰的描述出如何才能够提高软件质量。软件质量框架的目的就在于提出一个评价的原型,帮助我们分析一种方法和技术是否能够提高软件质量,下面我们讲进入一个更深入的剖析。

  软件测试质量运行过程中的面临的三大棘手事宜?

  那么这些问题是什么,怎么去做到最终解决这一系类的问题呢,我们要付出的心血和努力到底是否能得到回报,软件测试过程中真的很多问题无法把控得住吗,怎么做好软件测试,做好质量,都是我们在项目过程中无时无刻都在努力和为之付出太多的一个积累。

  我们做过软件,接触到软件行业的人都知道,软件测试是产品的真正试炼场;即使对一项软件开发工程投注了庞大的心血,如果测试不合格(也就是我们所以说到的最终度量的质量不达标,质量不满足交付基本)一切都还是枉然,因为客户要的是合格产品,高质量的产品,而不是你的努力过程,客户也不会太多关注你在这个过程中为此付出过什么,对于客户来说他们想要的就是一个最终的结果,可见的真实的东西的存在,所以测试的重要性应该不必赘述。只不过,「知道」跟「做得到」是两回事,就如同我们都知道应该多吃青菜和一些天然健康的菜品,然而还是有许多人每餐都是大鱼大肉,抽烟喝酒,熬夜通宵玩游戏一样。

  许多人谈到测试,总是有满腹牢骚,因为它似乎是一件「知易行难」的麻烦工作。

  为何测试总是做不好?大致可归类成下述三大原因。

  测试排最后

  目前一般的软件开发工作,大多采用传统的「瀑布式( Waterfall )」流程法,也就是把开发过程分为「需求」、「分析」、「设计与撰写」、「整合」、「测试」等阶段,一个接一个依序进行。

  这种方法很单纯也很慢节奏,最终可能会存在导致「测试总是排在最后才进行」的状况。这种设计会产生多种状况:

  一、是测试人员直到项目案子接近尾声才跟上项目进度,所以往往在尚未了解整个系统架构的情况下,就一头栽进工作。

  二、是这个时间点距离完工期实在太近,如果有什么突发状况,往往导致整个开发项目大乱或失败。

  三、团队合作不协调沟通起来会出现不及时的情况,到时候会存在大量返工或需求实现错误的问题存在

  四、代码最终实现完成,测试最后才跟踪进行测试的话,也有可能会出现需求跟踪丢失的情况等种种不利于项目最终质量的问题存在。

  时间不够 :

  测试做不好的第二个原因是「时间不够」,这是开发团队最常面临的问题。它其实也是上述「瀑布式」流程法把测试排在最后所导致的另一个致命伤。由于许多开发团队把大部分时间分配给前面阶段(特别是程序设计与撰写部分),只留少数时间给测试工作。然而突发状况永远无法预期,如果前面阶段因故导致工作拖延,在出货时间不能延后的情况下,后面阶段的时间就会不断地被牺牲。

  所以我们常常看到,在一个预定进行八个月或者更短的软件项目里,因为前面阶段的状况百出(计算机系统宕机、同事,备份人员生病请假、客户需求更改、开发不顺等),结果前面阶段不断占用后面阶段的时间,最后导致原本排定一个月的测试时间只剩下一周,甚至二、三天而已,根本无法测试。所以常常出现有些产品根本是在未经完整测试的情形下就贸然验收,交付上市,把测试工作留给客户或消费者的情况。

  另外还有一个与「时间不够」刚好相反的现象,就是「时间太长」。有时产品经初步测试之后发现问题丛生,实在无法交差(或是被客户退件),所以开发团队只好回头继续进行大量又重复的「测试 → 修改 → 验证」工作。如此折腾了好一阵子,最后产品终于可以验收。把这段额外时间加总起来,重新计算整体开发时间,这时才突然惊觉:「天啊,测试竟然占了将近一半的时间!」

  风险太高

  第三个问题是「风险太高」,也是流程设计不当所致。如文章开头所言:「测试才是产品的真正试炼场」,也就是一个项目的各种隐藏性风险,往往是透过「测试」才被完整发掘出来。但是「单向瀑布式」流程法却把测试集中在最后进行,所以它的风险容易随着开发流程的推进而越来越高;是一种相当危险的风险控管方式。

  事实上,这也是许多项目在后期才突然出现成本失控或失败的重要原因。因为等

  到风险爆发之时,往往已经无力回天,或必须付出相当大的代价以为因应。

  我们综合上面说到的三大类棘手问题进行一个综合分析,到底在软件测试过程中怎么把控一个度是合适的,这个度应该怎么去权衡它,满足用户的需求。这是最重要的一点,一个软件如果不能够满足用户的需要,设计的再好,采用的技术再先进,也没有任何的意义。所以这一点非常的朴实,但却是软件质量的第一个评判标准。

  其实最终我们不难得出一个结论就是:

  做好软件测试其实是一门学问,不是单纯的一个人或者一个小团队上来直接等领导下命令说一声干工作就能做好的事情,而是需要更多的协调与配合。

  从客户发出原始需求的时候作为软件测试员工的我们就该想到一个问题,这是时候是否跟踪,跟踪的意义这个时候到底大不大,我们回想一个问题,或者看看有经验的测试人员是怎么做的,是不是会发现他们比我们更能去快捷有效的理解和把握客户想要什么,那不是以为他们是老员工,更多的是以为,他们知道怎么去理解,什么时候开始理解客户的需求是最有效的,

  在软件测试过程中有句话是这样说的,测试应该尽早介意更好,我们在做工作的过程中不能忘记一些前辈给出我们的好的建议

  软件测试质量是我们做产品的根本,如果一个产品没有基本的质量和度量怎么保证我们做出来的东西是能被接受的,怎么保证我们的工作不是维持付诸东流

  做好软件测试质量要考虑从客户阶段介于,只能更多的了解理解了客户所想所要才能让我们更多的人去围绕客户为中心的原则把控整体风险,当然这个围绕客户为中心不是完全听从客户,一些无理的要求,或一些暂时技术实现不了的问题大家可以拉出来探讨,看是否可以选择更好的,大家都能够接受的方案进行最终的敲定

  质量对于我们而已就是我们软件人的生命,没有这个生命离魂还怎么做下去,希望这篇问题的能够让更多的人去了解软件测试生命的质量是什么,没有质量我想我们做的一切都可能是无味的,也就失去了最终的意义,希望更多的人能够越来越重视和客户,和团队,尽早介于到测试工作中,保证我们的测试质量,做到完美验收交付,做出让我们的客户和自己都满意的产品。

  质量的把控是一个长期的过程,不能断断续续,只有我们每个人重视起来了,才能看到一个长远的效果。

  随着软件设计技术的发展,越来越多新的实践将会出现,取代旧的实践。因此,以上的实践也会有落伍的时候,但可以肯定的是,以上的实践和具体的技术并没有直接的关系,更侧重于思想,因此他们的生命力会很长。而随着新技术的出现,他们更可能将新的技术融合如自身,呈现出一种崭新的形态。


作者:linda   

来源:51Testing软件测试网采编

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   软件测试人员在测试不同的阶段做不同的事的,总的分为以下几个阶段:  1.项目开始之初,也可以是一次迭代开始之初  这个时候每天都是以熟悉本次项目或本次迭代功能模块需求为主。  方式:一般就是看文档,有时就是看一天文档,或参加不同的评审会,根据不同人理解需求方式的不同,我喜欢用XMIND梳理测试点需求,我不管做什么事都喜欢用笔去整理一番。  这时阶段主要是理解需求,分析功能模块的业务流程,尽可能将测试点梳理得更细,在梳理过程中如果遇到不理解,或需要做的需求与以前的需求逻辑不符时,可以先找产品经理讨论,并确定,方式可以是当面讨论,也可以以邮件的方式确定,推荐以邮件的方式确定。  在这个阶段与团...
            0 0 1270
            分享
          •   目标  以银行的核心系统从旧核心系统更换为新核心系统为基础,对导入到迁移环境的生产数据(已脱敏)进行数据的验证。  数据迁移环境  迁移环境需要A、B两套环境。其中,A环境为新系统环境、B环境为老系统环境。  数据迁移小组  迁移小组:由迁移技术人员、业务人员和测试人员组成。负责迁移规则的验证、数据的静态核对;迁移规则的验证为全部验证,而数据的静态核对,则进行抽验。  数据迁移的验证  迁移规则的验证  迁移过程为源表中间表目标表,技术测试验证源表中间表、中间表目标表之间迁移测试的一致性,确保迁移数据全部符合按照迁移规则,确保老核心系统中需要迁移的数据都能全部迁移到新一代核心系统中。  数...
            8 9 2094
            分享
          •   在平时工作当中会用到漏洞扫描工具,用户只需要输入待检测网址,点击一下按钮就可以等待网站的安全检测报告了。作为刚入门的安全小白,对其工作原理产生了浓厚的兴趣,逐渐深层剥离Web应用漏洞检测的本质是网络爬虫技术与漏洞检测技术的结合,网络爬虫主要爬取网站结构并收集可能存在的攻击面,漏洞检测技术则是在爬虫结果的基础上进行针对性的修改并重放,根据服务器响应进行判断。在本篇文章中,我们将重点介绍爬虫技术方面的知识。  1、应用场景  通常我们看到的网页内容是通过浏览器呈现的,Web站点的页面渲染方式对用户是透明的,然而不同的Web站点渲染方式对爬虫的影响是巨大的。对于Web站点来说,其页面渲染方式主要...
            12 13 2725
            分享
          • 测试工程师等级分为初级,中级,高级,资深,专家等等,软件测试岗位任职资格标准由工作经验、必备知识、技能标准等部分组成。下面来详细介绍下:1. 工作经验资格等级工作经验软件测试助理0~1年软件测试工作经验,了解软件测试相关基础知识。能看懂测试用例,在中级测试工程师指导下,完成部分简单模块测试执行工作。软件测试专员1年以上软件测试工作经验,熟悉软件测试相关基础知识,具备独立处理一般软件测试技术问题的经验。初级测试工程师2年以上软件测试工作经验,具备独立进行系统一般特性测试的经验,参与部分功能测试方案、测试用例、测试平台设计。中级测试工程师3年以上软件测试工作经验,具备产品相关领域知识,可独立设计复...
            1 0 3076
            分享
          •   有一些初始的小测试团队,对BUG单可能会进行重要程度的划分,但并不会进行类型划分,其实,如果不对BUG进行错误类型定义,项目经理或测试经理并不好确认后续质量提升在哪方面进行改进,具体研发的哪个环节更需要进行改进。故此合理的对BUG单进行分类也是提交BUG的前提。以下是我整理的BUG类型分类情况:  进行BUG类型分类仅是第一步,作为WEB类的项目,一般情况下,明面上的二、三类问题,自测时容易发现且会完成修改,留到测试去提出的机率相对会少一点;而其它类问题常常因为开发时间不够或不重视等原因,大量的留给了测试阶段去提出;对于这类现象,负责的项目经理有时候是心有余而力不足;而不太负责的项目经理,...
            15 15 2391
            分享
      • 51testing软件测试圈微信