zoukankan      html  css  js  c++  java
  • 小白成长建议(4) -从头开始-云层

    测试入门

    从这里开始我们正式来谈谈关于具体的测试技术,我先列一下目录,以便大家知道后面几章的内容:

    1.测试基础及测试方法

    2.缺陷管理

    3.用例管理

    4.配置管理

    5.需求管理

    6.单元测试

    7.集成测试

    8.系统测试

    9.自动化测试

    10.性能测试

    这些是我觉得比较基本所需要知道的测试技术,而相关的一些开发、数据库、环境搭建等都应该在这之前基本具备的,我也不专门写点啥来解释了。

    首先我们先来谈一下所谓的测试基础和方法。

    测试基础

    其实一说到测试基础能谈的东西特别多,但是理论性又很强,让我消化了以后再给大家去理解也未必能精简成什么样子。那么我先来谈谈一些基本的基础吧:

    1. 到底测试是什么

    在我看来测试是一个根据某种规则进行校验的工作,这个工作需要:

    a懂业务来设计校验规则

    b懂技术能有效的执行校验规则

    而这个工作的目标只是为了证明软件能够达到一定的质量。

    在这里我想再强调一下,不要总觉得测试应该怎么做,测试的工作就是证明你测试过的内容是正确的,如果你能够做足够好的测试(所谓的覆盖率很高),那么客户能够运行到的非测试点就会少,那么遇到的问题也会少。

    2. 测试的价值是什么

    最大的价值就是预防吧,大家可以这样理解,如果当软件运行的时候出现了错误,它所带来的后果可能会被放的很大。但是这个放大的影响和所对应的业务有关,这也是为啥某些行业的测试工作不太被重视,而某些会被非常重视。

    大家可能会对吃婴儿奶粉,早教有很强的认同感,这其实也是质量预防。但是对于某些东西来说又非常的不重视,这就是现状。

    或者从另一方面来说,测试对于企业的价值,体现在省钱与赚钱上。省钱不言而喻,不论从上线后修复Bug的成本或大型项目回归的人力成本来说,测试技术的引入能够帮公司一定程度上降低这些成本。赚钱上来说么,我觉得现在测试外包的崛起现象,就能很好的诠释这个问题了。

    3. 测试周期

    测试的周期其实又涉及到模型,基本上现在的主流就是敏捷和VV,瀑布也有,简单来说就是瀑布验证太后面,一切都要靠前面做的好后面才有意义,就和造房子一样,你最后检验也没啥事情可以做了,房子都修好了。而VV模型呢是瀑布的改良吧,就是全程监控,设计图纸出来要评审测试,水泥和钢筋需要评审测试,这样做更好点。敏捷的做法就有点自己装修了,真的是做一点看看再做一点。

    总的来说周期包含:

    需求来源->需求分析整理->需求规格说明->研发需求->概要设计详细设计->开发->单元测试->集成测试->系统测试->验收及维护

    大概这样一些阶段,而对于测试来说应该都争取参与并且把关。

    一般测试人员会参与项目启动会议,从那一刻起,测试活动也已经启动了。在前期介入需求的提取工作,比后期根据需求文档熟悉需求要好,同时测试人员可以根据自身对业务及系统的了解程度,对需求及设计提出自身的看法。测试的价值在项目前期也就得到了体现。

    4. 测试要素

    对于测试来说是受人,流程和工具三个要素影响的。人是最关键的要素,一个优秀的人可以设置合理的流程来安排工作,而工具的存在可以提高人的工作效率。

    所以首先不要唯工具论,你掌握一个工具并不代表你怎么厉害,而是要进一步明白工具帮你解决了什么问题。

    通常我们会先通过熟悉工具来接触测试,但对我们真正有用的是,工具带给我们的思想。就像QC 传递的就是测试管理的思想。所以建议大家在熟悉工具的同时,可以想想为什么这么做及有没有更优的做法。

    5. 缺陷与bug

    在这个基本概念中,首先需要明确缺陷的定义。可以从比较广的角度来说一切违反定义的内容都可以称之为缺陷或者bug,但是定义这个东西就是很模糊的东西,因为三维空间并不能完全锁定定义,而在四维空间中有了时间才能锁定定义。也就是说在设计的这个时间点上的对于正确与否的定义,就是判断是否正确的定义。

    在缺陷中首先要分等级,有些缺陷是要立即改的,有些却不用,因为它们所带来的影响是不同的,还有一些缺陷可能是建议。

    对于缺陷的引入有很多种情况,可能是初期的设计也有可能是开发中的疏忽,所以对于一个优秀的测试来说,如果能自己做个软件开发和设计,那么对于理解和把握缺陷的引入及预防会有很大的帮助。

    测试方法

    1. 黑盒、白盒、灰盒

    可以这样的简单总结,黑盒就是不了解被测对象内部情况直接使用的测试方法。白盒是不关心怎么使用,主要针对代码本身的执行、分析的测试方法;而灰盒是介于前两者之间的,从某些角度来说灰盒测试相对来说更好点。

    黑盒测试强调对需求级别的验证,效果好,但是执行代价大,发现问题晚,定位表面。

    通常我们会在系统测试中使用黑盒测试的方法。从系统需求覆盖率去判断系统测试执行的效果。

    白盒强调对代码级别的验证,执行快,发现问题早,定位细节,但是对于大方向的需求验证无法实现。

    通常我们会在单元测试中使用白盒测试的方法。从代码逻辑覆盖率去判断单元测试的效果。

    灰盒测试介于之间,可以达到接近黑盒的执行效果,而定位上又会有一些工具的配合,所以定位就会准很多。

    通常我们会在集成测试中使用灰盒测试,一般集成测试会分为接口联调及业务联调,大多接口测试覆盖率会评判灰盒测试的执行效果。

    2. 静态测试和动态测试

    动态测试主要指通过运行软件来测试的手段,比如执行代码、编译代码等。而静态测试主要就是不运行代码的方式,比如走读,代码扫描类的。

    在这些方面有很多工具可以对代码的格式,文档的格式及内容进行静态测试。也有很多工具可以在动态执行的时候分析代码的情况,帮助发现定位问题。

    3. 手工测试和自动化测试

    使用人工执行的测试我们称之为手工测试,而使用某些工具帮助我们执行测试的就是自动化测试。自动化测试在重复的问题上面可以极大的提高执行效率,而手工测试是自动化的前提。

    手工测试可以更好的发现问题,而自动化测试是在手工测试的基础上提高了执行的效率,进一步通过遍历等方式可以扩展发现一些以前不太好发现的问题。

    自动化测试不能完全替代手工测试,在很多情况下手工测试可能更富有创造性。加上自动化测试的成本问题,很多公司起初对自动化都会有个美好的远景,但实施后大多也就不了了之了。

    上面提到了很多测试的概念,初期的时候可能会迷失在概念中,但是过几年回头来看这不就是经验的总结么,做测试要多想多思考,才能明白为什么我们需要这些方法和概念来指导我们以后的工作。理论永远是实践的基础,就像楼要一层一层盖上去,要造的稳,地基一定要打得扎实。希望大家不要因为理论枯燥而怠慢,它其实很重要。

  • 相关阅读:
    Linux进程管理概述
    【反转单链表】一篇就够了
    线性数据结构
    Linux的su和sudo有什么区别?如何使用?
    关于CentOS切换中文输入法的问题
    MySQL 初识
    MySQL 增-删-改操作
    数据库简介
    MySQL 查询操作
    HANDLER Statement
  • 原文地址:https://www.cnblogs.com/daxiong2014/p/4447925.html
Copyright © 2011-2022 走看看