iTesting软件测试知识分享

测试往何处去 -- 新时期测试如何面对挑战

本人一向务实,很少务虚,最近参与的讨论比较多,也有一些些感悟,分享给大家。
勉强算原创吧,标题起的比较大,恬不知耻,主要为了吸引更多从业人员参与讨论,请见谅。

软件测试从前些年的懵懂发展,大家摸着石头过河, 到大多高校设立软件测试专业, 再到近几年各种测试培训盛行,可谓学术与工程齐备,理论和实践并发展。
软件测试的进入门槛,也从真正零基础,各行各业拼命涌入,到现在的要求具备专业的计算机专业能力(包括不限于编程能力),软件测试在企业的受重视程度,特别是互联网行业,也从可有可无,到不可或缺。

随着近年来各行各业对软件的强需求,及大数据,云计算,AI的形成,发展, 各种开发模式被不断引进来解决开发中的问题,传统的瀑布模式几乎被淘汰殆尽,敏捷开发已成强弩之末,DevOps思想又从星星点火,到燎原之势。软件开发人员俨然超越了四个现代化,正寄语我们的征途是星辰大海。 但测试人员,还有很多处在石器时代,过着茹毛饮血,敲敲打打(点点点)的日子。

1. 软件测试的过去
远古时代的软件测试人员,严格遵守开发,测试,发布的瀑布流程,他们不知道,也不关心开发如何实现,严格按照需求说明书,来编写测试用例。等到开发把编译完成的版本送到他面前,他才慢条斯理的对着测试用例,一条条执行,看到跟期望结果不一致的地方,一股脑的当bug提上去, 根本不去想bug的出现原因,了不起把重现步骤,测试环境标记清楚。至于一个root cause提多个bug,按bug量论英雄,不在话下。

2. 软件测试的现在
大浪淘沙,现阶段的软件测试人员,大多认识到了测试及早介入的重要性,也有很多接受了敏捷思想,成了敏捷的脑残粉,特别在敏捷开发的项目中,他们大多主动的从需求分析中介入,努力提升软件的可测性,在Grooming大会,Planning大会上,发出测试的声音,让开发一开始就避免掉某些坑。在测试的形式上,不再拘泥于黑盒测试,把白盒测试,接口测试,性能测试,甚至静态代码分析,代码覆盖率测试也纳入测试的版图,测试在组织的话语权也越来越大。

对于有追求的测试来说,不再仅着眼于辅助开发保证软件的质量,他们把目光放到如何提升团队生产率,加快成功发布上,一系列的测试框架,代码build触发自动化测试,为其它测试提供测试工具,眼花缭乱,不胜枚举。
对于测试的先行者来说,他们关注测试人员这个职位存在的必要性,为测试行业摇旗呐喊,在各种开发模式中,布道测试的作用。

3. 软件测试的挑战
直到现在,大部分的测试还具有如下鲜明特点:

  • “提前测试”。 即测试人员在软件发布前测试,软件发布后很少再去测试,Live环境上的测试和监控属于Ops的范畴。
  • 期望结果明确。 即测试人员在一个操作之前,已经提前知道这个操作的结果应该是什么。对于同样的输入,一定会有同样的期望结果。

随着云计算,大数据,人工智能的发展,越来越多的公司把自身业务部署在云上,产品也越来越依赖大数据和人工智能。 加上智能设备的发展,可穿戴设备,甚至裸眼屏幕,将会越来越多,在这个大环境下, 提前测试就不那么适用了。
测试遇到的挑战也会越来越大,软件的复杂度进一步增加,”提前测试” 开始力不从心。 Test in Production 势在必行。

对于复杂的提供service的产品来说,例如搜索引擎, 仅仅依靠测试人员设计的测试用例,肯定只能覆盖真实用户的少部分使用情况, 大部分用户如何使用,测试人员无法设计出来。这个时候就需要Test in Production。
即便是某一个特定的功能点,同样的输入,在不同的时间段,也不能期望实际输出不发生变化。举例来说,你今天输入 “百度 股票价格” 和明天输入 “百度 股票价格”, 得到的结果可能也不同,这个时候,明确的期望结果,也变得不适用。 测试人员就要把检查的重点,从一个固定的结果转化为观察一个 ”模式/趋势“, 就是说,如果你的输出是 百度今天的股票价格, 或者百度股票的趋势,都是可以接受的,但是出来的结果,如果只有百度,没有股票,就是不对的。

还有,如果你们的服务部署在阿里云,腾讯云上,你的测试方法能跟传统的一样吗?如果你的产品基于大数据智能调整哪些功能展现给哪些用户,你的常规测试方法还有用吗?如果你在测试一个人工智能产品,
你还能设计出用户常用的case吗?

4. 软件测试的未来
新形势下,测试应该怎么做呢?

  • 某个功能的输入数据,将从测试人员准备变成直接导入真实用户数据,采取例如A/B Test, 金丝雀发布的方式来进行。
  • 测试的结果, 将不在关注具体的确定值,转为记录观察输出的趋势,或者行为模式,即Pattern。

这客观要求测试紧跟新的开发模式/思想, 以DevOps为例, DevOps天然强调持续集成,自动化部署,急速部署,多次部署,那么测试,就要在这个上面发力,部署自触发的自动化测试就必不可少,这样对测试的要求将会越来越高,测试对系统的介入程度,将会越来越深,最终测试即开发,开发即测试。
未来, 测试应该会

  • Test in Production(紧随DevOps,自动化比重会加大)。
  • 测试的检查重点,也会从期望的Test Results 转变为Observed Data/pattern。这个已发生,随着技术的发展,比重将会越来越大。
  • 生产环境的监控比重将越来越大,甚至变成新常态。

5. 软件测试的机遇
近几年发生在软件开发业内的新思想,新方法,主要以开发人员为主导。那么是不是就意味着其它角色生存空间被压缩呢?我认为也是也不是,被压缩的是精益思想本来就要去掉的,所谓的”减少浪费“的浪费部分,
如那些 “测试人员自主设计的模拟用户行为的测试” 功能测试部分, 还有手工配置测试环境,及”快速交付给客户“过程中因为运维的原因被常常被堵塞的部分。

对于测试人员来说, 困难和机遇并存,新的技术/思想固然层出不穷,但不必戚戚然,一个产品要顺利交付给客户,必不可少要把住质量关,测试人员(我们现在常叫QA,质量保证人员)只需牢记任何思想的演进都是为了快速成功的交付这个原则,测试人员应该通过各种手段,为这个目标增加测试的价值。

测试人员应该牢记,你不仅仅是测试,你是整个产品团队的一部分,你对团队的整体效率负责,你存在的价值是帮助组织快速交付。

测试这个职位有可能会消失,但是每一个组织,每一个客户对软件质量的要求不仅不会消失,还会不断增强,这将会是测试人员最好的时代,是属于我们测试的改革开放,每一个测试人员都应该趁着行业东风,努力做这个伟大时代的弄潮儿!

参考资料:
http://blog.csdn.net/zhubaitian/article/details/50203263
http://www.infoq.com/cn/articles/detail-analysis-of-devops
https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-one
https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-two

🐶 您的支持将鼓励我继续创作 🐶
-------------评论, 吐槽, 学习交流,请关注微信公众号 iTesting-------------
iTesting wechat
扫码关注,跟作者互动