迄今为止,软件测试的发展一共经历了五个重要时期:
- 1957****年之前-调试为主(Debugging Oriented)
- 1957–1978****-证明为主(Demonstration Oriented)
- 1979–1982****-破坏为主(Destruction Oriented)
- 1983–1987****-评估为主(Evaluation Oriented)
- 1988–****至今-预防为主(Prevention Oriented)
调试为主
20世纪50年代,计算机刚诞生不久,只有科学家级别的人才会去编程,需求和程序本身也远远没有现在这么复杂多变,相当于开发人员一人承担需求分析,设计,开发,测试等所有工作,当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开始思考 “怎么知道程序满足了需求?”这类问题了。
证明为主
1957年,Charles Baker在他的一本书中对调试和测试进行了区分:
- 调试(Debug):确保程序做了程序员想它做的事情
- 测试(Testing):确保程序解决了它该解决的问题
这是软件测试史上一个重要的里程碑,它标志测试终于自立门户师出有名了。 当时计算机应用的数量,成本和复杂性都大幅度提升,随之而来的经济风险也大大增加,测试就显得很有必要了,这个时期测试的主要目就是确认软件是满足需求的,也就是我们常说的“做了该做的事情”。
破坏为主
1979年,《软件测试的艺术》 (The Art of Software Testing)第一版问世,这本书是测试界的经典之作。书中给出了软件测试的经典定义:
The process of executing a program with the intent of finding errors. 测试是为发现错误而执行程序的过程。
这个观点较之前证明为主的思路,是一个很大的进步。我们不仅要证明软件做了该做的事情,也要保证它没做不该做的事情,这会使测试更加全面,更容易发现问题。
评估为主
1983年,美国国家标准局(National Bureau of Standards)发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”,也就是我们常说的VV&T。VV&T提出了测试界很有名的两个名词:验证(Verification)和确认(Validation)
- Verification: Are we building the product right?
- Validation: Are we building the right product?
人们提出了在软件生命周期中使用分析,评审,测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展:
- 出现测试经理(test manager),测试分析师(test analyst)等职称
- 开展正式的国际性测试会议和活动
- 发表大量测试刊物
- 发布相关国际标准 以上种种都预示着:软件测试正作为一门独立的,专业的,具有影响力的工程学发展起来了。
预防为主
预防为主是当下软件测试的主流思想之一。STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型,STEP认为测试与开发是并行的,整个测试的生命周期也是由计划,分析,设计,开发,执行和维护组成,也就是说,测试不是在编码完成后才开始介入,而是贯穿于整个软件生命周期。我们都知道,没有100%完美的软件,零缺陷是不可能的,所以我们要做的是:尽量早的介入,尽量早的发现这些明显的或隐藏的bug,发现得越早,修复起来的成本越低,产生的风险也越小。
虽然每一个发展阶段对软件测试的认识都有其局限性,但是前辈们一直在思考和总结前人的经验,创造性地提出新的理论和方向,这种精神非常值得尊敬和学习。所谓以铜为镜,可正衣冠;以史为镜,可明得失。知道了从哪里来,方能更好的明白该到哪里去。
2****,软件测试国外现状
软件测试在软件公司尤其是大型公司受重视。
软件测试在很多高校和研究机构作为一个单独的学科去研究。
测试工具比较发达,测试自动化水平高。
3****,软件测试国内发展及现状
1,国家、高校和公司越来越关注软件测试理论的研究和测试人员的培养。很多学校的本科和专科教学中尝试性的开设软件测试课程。
2010年12月16日,国内知名测试专业网站51testing与郑州轻工业学院软件学院人才培养实训基地签署协议,共同培养软件测试人才;(http://www.51testing.com/html/00/n-210000.html)
2、 目前,国内多间高校已专设有本科段软件测试方向的专业,如广州华软软件学院,电子科技大学成都学院,北京民族大学信息工程学院等学校;
3、 2011年11月12日~13日,由国家教育部软件工程专业教学指导分委主办的“2011年高等学校软件测试课程教学论坛”,在上海同济大学召开,无疑对国内软件测试人才的培养,及测试领域的全面发展起到积极推动的作用。这里要特别感谢软件测试领域知名专家朱少民老师的分享,下面是来自兴浪微博关于此事的截图。
[[图片上传失败...(image-821e5c-1530169661486)]](javascript:;)
现状
一、是软件测试的地位还不高,在很多公司还是一种可有可无的东西,大多只停留在软件单元测试、集成测试和功能测试上。
二,是软件测试标准化和规范化不够。
三,是软件测试从业人员的数量同实际需求有不小差距,国内软件企业中开发人员与测试人员数量一般为5:1,国外一般为 2:1或1:1,而最近有资料显示微软已把此比例调整为1:2。
四,是国内缺乏完全商业化的操作机构,一般只是政府部门的下属机构在做一些产品的验收测试工作,实质意义不大,软件测试产业化还有待开发和深掘。
五,专业的测试机构以及主做软件测试业务的公司不断壮大。
六,各种测试职业培训机构涌现,为软件测试行业培养了大量的人才。比较权威的是51test培训,51testing论坛是一个比较好的测试交流平台。
七,TesterHome社区
中国移动测试开发大会邀请国家机构,大学教授和BAT的总监们来一起参与
4****,对测试工作的误解
测试和调试工作类似
对软件可以进行穷举测试
软件有缺陷,是测试人员的失职
关注测试执行而忽视测试用例设计
测试比编程容易得多。
测试是编码之后进行的工作,开发完了再做测试
测试自动化是万能的。
自动化测试就是让计算机代替人进行测试。
软件测试是一种破坏性的工作
测试的目的在于证明软件的正确性
5****,测试的质量管理
持续集成、持续交付、DevOps
质量监控
敏捷落地
过程改进、质量体系建设、团队管理
6****,测试的领域
互联网测试:接口测试、白盒测试
移动互联网测试:通用app测试、小程序测试
物联网(IOT):车联网、智能家居、智能穿戴、机器人、机顶盒、工业app
互联网金融测试
视频与语音测试
游戏测试
新方向测试、大数据测试、人工智能(AI)、区块链
7****,测试技术
自动化测试:接口测试、UI自动测试、自动探索性测试
移动端专题测试:性能测试、耗电量测试、弱网测试、卡顿测试、sdk测试
服务端测试:压力测试、性能调优
安全测试:应用安全测试、服务端安全测试、物联网安全
白盒测试:静态分析、代码审计、Android Hook技术、iOS Hook技术、字节码插桩技术
质量监控与质量数据分析
8,大数据测试策略
大数据应用程序的测试更多的是去验证其数据处理而不是验证其单一的功能特色。
当然在大数据测试时,功能测试和性能测试是同样很关键的。
对于大数据测试工程师而言,如何高效正确的验证经过大数据工具/框架成功处理过的至少百万兆字节的数据将会是一个巨大的挑战。
因为大数据高效的处理测试速度,它要求测软件工程师具备高水平的测试技术才能应对大数据测试。
我们来看下大数据处理的三个特性:
· 大批量
· 实时性
· 可交互
另外,数据质量也同样是大数据测试的一个重要维度。
因此在进行应用程序测试之前,必须确保数据质量,并且考虑把数据质量作为数据库测试的一部分。涉及数据的各种特性的检验,例如一致性、准确性、重复性、连贯性、有效性及完整性等等。
大数据应用测试步骤
下面我们一起看看大数据应用的测试过程是怎么样的。
[图片上传失败...(image-606fbc-1530169661487)]
整体而言,大数据测试大体可以分为三大步骤:
· 步骤一,数据预处理验证 在进行大数据测试时,首先要预hadoop前验证数据的准确性等等。
我们数据来源可能是关系数据库、日志系统、社交网络等等,所以我们应该确保数据能正确的加载到系统中
我们要验证加载的数据和源数据是一致的
我们 要确保正确的提取和加载数据至hdfs中
· 步骤二,Map Reduce验证 在进行大数据测试时,第二个关键步骤是“Map Reduce”验证。在本阶段,我们主要验证每一个处理节点的业务逻辑是否正确,并验证在多个运行后,确保:
Map Reduce过程工作正常
数据聚合、分离规则已经实现
数据key-value关系已正确生成
验证经过map reduce后数据的准确性等特性
· 步骤三,结果验证 在本阶段主要验证在经过大数据工具/框架处理后,生成的最终数据的成果。
主要验证:
验证数据转换规则是否正确应用
验证数据的完整性和是否成功持久化到目标系统
验证无数据损坏
架构测试
Hadoop处理海量数据是非常的消耗资源的,良好的架构是确保大数据项目成功的基础。糟糕的涉及会导致性能急剧的下降,进而使得系统无法满足我们的需要,因此我们需要,或是说至少在Hadoop环境下进行性能测试、故障恢复测试,以应改进效率和应对可能的最糟糕的情况。
性能测试是一个复杂的工作,它贯穿整个测试周期,需要关注内存、CPU、网络等等指标。
故障恢复测试则是验证数据处理过程中可能出现的故障,为做好意外的恢复做好相应的应对措施。
性能测试
大数据性能测试主要包含以下几个部分:
· 数据提取、存储效率
在本阶段,我们主要验证大数据应用从源数据中提取、加载数据的效率。
一是验证单位时间内数据的提取、加 载效率。
二是验证数据持久化至mongodb等库的效率等等
· 数据处理
在本阶段,我们验证map reduce任务的执行效率,重点关注的是数据处理的效率。当然这个过程可能也会涉及到数据的持久化相关指标,例如存储至HDFS读写效率等等,同样也会涉及在内存中处理效率,即我们的处理算法效率等等
· 子组件性能
大数据处理,一般都会需要综合利用各种组件来辅助处理,所以我们也是需要关注这些辅助组件的性能
性能测试策略
大数据应用性能测试涉及海量的结构化和非结构化的数据,与我们平时所面对的业务系统有所不同,所以我们需要针对大数据应用制定特定的测试策略,以应对海量的数据。
[图片上传失败...(image-fd8fb9-1530169661487)]
根据上图性能测试执行过程一般是这样的:
在性能测试前需要先初始化大数据集群环境
梳理和设计大数据性能测试场景
准备大数据性能测试脚本
执行并分析测试结果(如果指标异常,则调优相应的组件并重新测试)
优化配置
性能测试基础准备
在大数据性能测试时,需要准备相关的基础工作,如下:
· 数据准备,我们需要在不同的节点准备什么量级数据?
· 日志预估,在测试过程中,可能会生成多大的日志,日志的可能增量是什么样的?
· 并发,在测试时,可能会有多少线程并发读和写?
· 超时设置,应对设置怎样的连接超时?查询超时?写超时等等?
· JVM参数,如何设置最优的jvm参数,heap size、GC机制等等
· Map Reduce,我们应该选择什么样的sort、merge等算法?
· 消息队列,消息队列长度会怎么样?等等
必备的测试环境
大数据测试不同于常规的应用测试,你应该具备以下一些基础环境:
· 拥有足够的存储设备来存储和处理大数据
· 拥有集群来做分布式节点和数据处理
· 至少拥有足够的cpu、内存来确保有高性能的处理基础
大数据测试的挑战
对于从事大数据测试的软件测试工程师而言,与传统的测试工作相对比,我们可能面临的以下几个可能的挑战:
· 自动化 自动化测试是从事大数据测试必备的技术,但自动化测试工具可能并不具备处理测试过程所引发的异常的能力,意味着现有工具可能并不适用,编程能力将是更好的一种技能。
· 虚拟化 当前业内大规模使用虚拟化技术,但虚拟机的延迟有可能造成大数据实时测试处理的异常。
对大数据而言,管理影像信息也将是一个巨大的问题。
· 海量数据集
需要验证的数据量巨大,而且需要更快的处理速度
需要有效的自动化测试手段
需要尽可能的跨平台
大数据性能测试的挑战
对于从是大数据性能测试,与传统性能测试相比较,我们要面临是样的挑战呢,可能有以下几个方面:
· 技术的多样化,复杂化,面对不同的大数据解决方案,我们可能需要掌握不同的技术和定制不同的测试解决方案
· 无通用的工具,目前业界暂无通用的标准的大数据性能测试工具,这意味着我们需要根据大数据应用解决方案技术,要自行开发或整合多种相关工具才可能解决问题
· 测试环境复杂化,因为海量的数据,我们所需要测试环境亦会更加复杂,所消耗的基础成本会更高
· 监控解决方案,目前有的监控解决方案有限,但通过整合不同的监控工具,大致可能拥有一套相对可行的监控解决方案
· 诊断方案,由于大数据应用所涉及的技术、环境复杂性,对于问题的诊断调优,我们需要根据实际情况来进行开发定制
从上面几个方面来看,从事大数据性能测试所要面临的问题是相对复杂的,尤其对当下国内的测试工程师而言,要走的路还很长,很艰难。
小结
· 随着大数据工程和数据分析逐步的进入新的阶段,大数据测试将成为必然,也必定成为未来的一个热门的职业方向
· 大数据处理必须是批量的,实时的、可交互的
· 大数据应用测试的三大阶段:
数据验证
Map Reduce 验证
数据处理结果验证
· 架构测试也是非常重要的一个测试类型,糟糕的架构可能直接导致您的大数据项目的失败
· 性能测试三大节点:
数据提取、存储效率
数据处理效率
子组件工作效率
· 大数据测试不同于传统的测试,不仅仅是类型、策略的不同,工具等具体技术都会有区别
· 大数据因其复杂性,其测试所面临的挑战也会不同于传统的测试
· 大数据性能测试将会是软件测试工程师进一步艰难攻克的目标之一