在持续测试不断实施的情况下,测试方法论、测试实践、测试技术都在快速发展和迭代,因此对于每一位测试工程师来说,持续学习就变成一个不得不说的话题。下面将从测试理论基础知识点出发,介绍持续测试下测试工程师的自我修养。
本节从一道面试题开始,面试题目如下。
〓ts〓假设我是北京地铁运营方的业务方,这一年在整理客户留言时发现用户对在北京地铁西单站设立自动饮料售卖机的需求特别强烈,因此我们内部商议后决定在该地铁站的地下刷卡机边放一台自动饮料售卖机。如果让你完成该任务的测试工作,你会如何设计这个测试方案呢?
看完这道题目,其实第一感觉并不难。下面给出了两位面试人员的回答。
小明看到题目中的“自动饮料售卖机”后,就开始绞尽脑汁地在思考怎么买饮品,因此他的回答主要是饮品售价有1元、1.5元、5元等,投入1元、5元、10元、20元、100元等,然后再指出投入的有硬币、纸币等,最后补充了对扫码付款、声波付款、NFC付款等付款方式的测试。
大明在上述题目中看到了业务的场景,首先站在系统的角度思考了自动饮料售卖机的用户,这里面包含了两类用户,一类是购买饮料的用户,另一类是维护者。自动饮料售卖机有很多常规维护流程,这里既包含机器的日常维护也包含货物的补充,这两种维护者都是系统的参与者。因此,站在不同系统参与者的角度,大明的答案既包含小明的内容,又包含站在系统维护者的角度设计的测试用例。
从内容上不难看出大明的回答会更好,但是大明的回答也不合理。大明和小明的答案都仅停留在功能特性上,一名合格的测试工程师在着手设计一个项目的测试时,首先应该站在系统参与者的角度设计功能特性的测试用例,其次应该站在系统的非功能特性的角度给出系统的可靠性、兼容性、性能效率、安全性等方面的测试设计,这样才能给出一个完善的测试方案。
对于上面这道开放的面试题,出题者更加希望得到的回答是一个站在质量特性角度的测试方案,而不是一个站在用户角度的测试方案。因此,我们可以设计一些关于摆放位置和刷卡机的物理位置的一些测试点、与服务连续性相关的测试、机器出现故障后的一些故障回溯方面的测试,并考虑地下这个条件约束的自带照明等外部因素对系统的要求。
虽然面试者在努力思考该面试题,但是面试者对测试的认识还浮于表面,并没有建立一套测试体系。每一个测试工程师都应该建立一套测试体系,该测试体系既要包含测试方法论也要包含测试技术实现。测试体系应该兼有方法和实践——既兼顾测试方法论的理论指导,也兼顾测试技术、实践方法论的落地。
最近几年,测试自动化、测试智能化的发展受到了测试行业的广泛关注。随便找一个测试工程师的招聘岗位描述,我们都会发现有自动化测试、测试技术的要求。这是因为在当前敏捷开发模式之下,手动测试变成了整个交付流程中严重影响工程效率的一个环节。因此,用自动化测试、智能化测试来提高质量效能从而提高工程效能变成了当下的共识。
然而,在手工测试中,人工设计测试步骤和测试数据,人工执行测试步骤验证并测试预期,最后给出测试结论。在自动化测试的实现过程中,人工设计测试脚本和测试数据,机器执行测试步骤,验证测试预期,人工查看测试报告,出具测试结论。在一些成熟度较高的智能化测试框架中,机器设计测试步骤和测试数据,机器执行测试步骤并验证测试预期,机器完成测试结果的收集及测试结论的出具。
因此可以看出,两者的区别仅在于是人还是机器完成了测试,但是完成测试的每一个环境没有变化,这就是测试体系的内容。测试的发展路径如图7-1所示。
图7-1 测试的发展路径
纵观软件测试行业的发展,从手动测试到自动化测试再到敏捷测试。在手动测试时期,测试理论得到了快速发展,各种测试模型、测试设计方法不断更新迭代。随着被测系统规模和复杂度的提升,手动测试的耗时和项目交付工期之间的冲突推动了自动化测试的快速发展。在这个时期,人们提出了分层测试理论并不断优化相关理论,测试框架及相应的自动化测试设计模式也有了一定发展。
现在,项目的快速迭代需求催生的敏捷测试又推动了流水线、探索测试等一系列优秀工程实践的出现。但是这一切发展的最终目的都是更好、更快地完成测试工作,都依托测试体系的各种实践。要建立测试体系,就要有一个体系化的理论依据,而非凭空想象。前面介绍过质量模型的发展,这就是测试体系的理论基础。
GB/T 25000中的八大质量特性如图7-2所示。其中包含功能性、性能效率、兼容性、易用性、可靠性、信息安全性、可维护性以及可移植性,这是验证一个系统或者软件的质量的8个方面。
图7-2 GB/T 25000中的八大质量特性
依托质量特性,总结出一个系统需要满足的具体要求,这就是测试验证的目标。测试体系如图7-3所示。
质量特性之上就是测试方法,这里包含测试用例设计、自动化测试技术、稳定性测试技术、测试环境准备、测试结果分析及故障诊断等。如果需要验证被测系统的质量特性,我们通过测试方法可以知道如何构造验证条件,以及如何正确地验证。
图7-3 测试体系
测试方法之上是测试策略。这里既包含测试方法论、测试体系规范、测试生命周期管理,也包含测试左移、测试右移。测试策略在软件开发生命周期中起作用,约束了在什么阶段用什么手段验证哪一个质量特性,这其实是组织过程知识体系中的内容,但是也是测试体系中不可或缺的一部分。
测试技术伴随着测试需求的不断变化而发展,自动化测试是为了解决一些更难以达到的测试效果而出现的。最早被测试行业认识的自动化测试工具是性能测试工具,典型代表为LoadRunner。
随着行业的不断发展,测试技术逐渐地应用于多个领域,并且逐渐开源化。现在,开源的性能测试工具、自动化接口测试平台、自动化UI测试框架已经广泛存在。这说明测试技术越来越受到行业的重视。
随着DevOps的快速发展,越来越多的公司开始关注工程效能,亚马逊公司一天5000万次部署的神话,就是依靠DevOps的实践创造的。其中,除大家耳熟能详的持续集成、持续交付及持续部署之外,还有隐藏的持续测试。
构建的流水线顺利完成交付后,系统质量保障环节的人工化就变成一个制约工程效能的痛点,这促进了很多自动化测试技术的发展。自动化技术发展到一定的阶段必然会促进测试的平台化,测试的平台化会促进智能化测试的发展,这其实也是测试行业自驱的过程。
虽然测试技术的发展与持续测试的进步是行业自驱的结果,但是并不是每一个测试工程师都是新技术、新方法的贡献者。每一个测试工程师都要努力成为质量保障行业的跟随者。当有新技术、新方向出现时,要先学习,学习新技术是什么,解决了什么问题,如何使用,然后再考虑这个新技术是不是适合应用到当前的工作中,这就是所谓的跟随。
在开始跟随新技术之前,要先知道新技术的出现,获取新技术的最好途径是国内的各大技术论坛、技术微博、公众号等,我们也可以通过一些国外的技术博客获取一些信息。
多参加国内的技术沙龙、会议会非常有帮助,当今国内技术氛围特别浓郁,在这些活动上我们可以学到很多新思路,而每一个新思路对于测试工程师来说都是有价值的。
第一次了解到某一项新技术时,要先看使用文档,了解它能做什么,也就是能解决什么问题。然后尝试按照快速学习手册使用一下该技术,以了解它是如何解决问题的。同时,在实际使用对应的技术后,我们会对这项新技术有更具体的认知。
如果新技术涉及一个开源项目,并不提倡直接查看源代码,因为要理解一个项目的源代码的时间成本非常高。推荐测试工程师通过文档了解他人是如何解决对应问题的,这样就从如何使用的认知阶段迈进原理的认知阶段。根据这些基础知识,我们就可以初步判断这个新技术是不是可以应用到当前的工作中,如果可以,那么就要好好研究一下源代码。
如果一项新技术并不能解决实际工作中的问题,那其解题思路对于测试工程师来说应该会比这个新技术更加有价值。在做技术的跟随者的过程中,我们每一个人其实一直都坐在技术的战车上,当技术的战车不断在赛场上奔驰时,只要已经上车,就不会被远远地甩在后面。
如果最近三年内你有过求职经历或者求职的想法,相信你肯定发现测试技术越来越受到企业招聘者的重视。这其实体现了工程效能快速提高的需求和落后工程生产力之间的矛盾。只有这种矛盾越来越突出,才会有更多团队开始着眼于解决落后的工程生产力的问题。
测试技术属于工程生产力的一部分,是质量保障的重要组成部分之一,因此测试技术才会受到越来越多团队的追捧。既然未来测试职业要求的方向会越来越偏向技术,你就应该作为一个技术跟随者一直紧跟技术的发展。
不要鼓吹自动化测试编码、性能测试技术、框架设计而忽略测试基本功。测试基本功要扎实,例如,对于测试用例设计方法中的等价类划分法、因果图法、场景法、边界值法等,只要知道名称,不知道如何使用,这就如同开发工程师只知道怎么声明变量,怎么写逻辑代码段,但是不懂设计模式、算法。这样做出来的项目最多是一个课程实践,还不能到达实际交付工程的要求。
本文摘自:持续测试
结合代码和工具,系统讲述通过持续测试交付可靠的系统,汇聚测试架构师10年的测试心法,打造属于自己的测试框架。
本书旨在讲述如何通过持续测试交付一个功能完善、质量完美的系统,满足测试人员快速交付、快速迭代的需求。本书首先概述了什么是持续测试,以及持续测试和自动化测试的异同,介绍了如何提升持续测试的效率和效果,然后讨论了如何通过持续测试中的非功能性测试保障软件的可靠性、可用性、可移植性、性能效率等质量特性,如何通过建立质量门禁保障所交付系统的质量,并通过自动化提升质量效能,最后介绍了持续测试技术的发展,讨论了如何通过有效的度量促进质量的成熟,以及持续测试下测试工程师的自我修养。