软件测试的一个新公式引起的思考

          在互联网、大数据时代,我们需要重新思考:什么是软件测试?如何更有效地开展软件测试活动?这是最近一年 和大家分享的一个主题之一,其思路、素材慢慢地也趋于成熟,对大家的测试分析、设计和执行会有很好的指导意义。即使没有指导作用,也会对大家有所启发。

640

搜Javascript,却出现看似和Javascript 完全不相关的图片

.
640-2

仅仅相隔几秒钟,两次搜索结果不一样,哪一种结果是对的?都对?都错?

.
640-3

图片搜索有广告推荐(见上部,黄色框内),有些推荐合理,但有些推荐不合理?整个推荐是否合理?

 

 

640-4

关联性推荐,虽然这看似比较客观,但结果是否正确也需要验证,如何验证?

 

640-5

Google结果是不是最好?Baidu、Bing的搜索是不是以Google的结果为标准?

 

640-6
测试不仅要考虑不同的输入,而且要针对不同的输入判断输出结果是否正确。

 

640-7
在几种不同场合上问测试工程师,听说过“Test Oracle”吗?得到的答案,却出乎意外,不少测试同仁不知道这个术语。如果不知道Test Oracle,如何做测试?糊里糊涂做测试,或者说,不知不觉在用“Test Oracle”,但就是不知其所以然。正像我们有时会吃到某些好吃的东西,会感觉味道不错,但不知道味道为什么这么好,甚至不知道自己吃的是什么。

 

640-8
如果测试人员仔细想想,测试结果的判断其实有很多准则,从清晰的Spec、竞争产品对照到含糊的自我判断,如上概述。

 

640-9
软件属于数字世界,是为了解决现实世界的业务问题,两者是等价的,但是有不同的表现形式,有时其相差甚远。

 

640-10
过去常用Spec 作为测试预言,今天规范的Spec 比较少了,成为稀有之物。更多依赖启发式准则、工程师的综合判断(Human Oracle)

 

640-11
在互联网时代、大数据时代,在快速迭代、快速交付的敏捷开发模式下,Test Oracle问题越来越凸显,人们也越来越关注。

 

640-12
在Test Oracle研究中,引入了机器学习(包括人工神经网络)、蜕变测试、模糊测试/变异测试等,能够解决其中存在的某些问题,其中蜕变测试就是在现有的Test Oracle难以判断结果是否正确时,构建新的输入/输出关系。

 

640-13
在Test Oracle遇到挑战的同时,互联网用户的应用环境&操作等的多样性、大数据的Volume/Velocity/Various等特性,给测试的输入测试也带来巨大的挑战。

 

640-14
左边是一个真实案例,输入空间(组合数)可能高达几十亿、几十万亿,即使采取两两组合、三三组合等方法优化组合,测试输入空间依旧比较大,或者测试覆盖率达不到要求。

 

640-15
过去,认为“软件测试是对软件产品进行检验” 已经不能满足现在软件测试的要求,我们已经无法检验软件是否正确。

 

640-16
过去,也用公式来描述“软件测试”,是有矛盾的。从第2个公式也可以看出,测试带有“抽样试验/检查”的含义。今天尝试用公式来表达测试,虽然不是创举,但会比曾经的公式描述测试更合理、更准确。

 

640-17
这充分利用的中文词汇的解析,使大家容易记住这个公式。第二个公式是对第一个公式的更准确的说明,更具有对测试工作的指导意义。

 

640-18
说明什么情况下,完成“检测已知的”的这部分测试,即在明确的输入/输出的情况下,检测已知的,这时一般会运用相对明确的Test Oracle:如清晰的Spec、竞品参照、一致性准则、确定性模型等。

 

640-20
未知的实验分为两部分:1. 通过工具实验,产生随机、半随机(变异/模糊)的数据,进行变异测试/模糊测试等,这里可以用统计准则,或造成系统异常(如系统崩溃),容易判断,用于安全性测试、稳定性测试等;2. 通过测试人员的试验,不断质疑系统,获得系统的反馈来做出判断,见下一个slide。

 

640-19
当未知因素占主导地位时,什么是软件测试?软件测试就是不断质疑这个系统。在没有实施“TDD/ATDD/BDD”实践的敏捷开发模式中,用户故事给出的信息是有限的,需要不断的探索。敏捷开发模式,也可以认为是“探索式开发”。

 

640-21
结合工具的随机/半随机测试和人的探索,未知的试验进一步提升为人工智能,不断学习、不断进行数据(输入、输出、log等)挖掘,不断构造/完善验证的规则/准则,完成自动的测试,从未知逐步走到已知。

 

640-22
将测试新公式“测试=检测+试验 ”再进一步明确为:

“测试=基于确定性模型/明确测试预言的自动化测试 + 基于人工智能搜索的/基于工具随机/模糊模型的/基于人的探索式测试”。

从测试一开始,即测试需求分析开始,就将测试的范围(测试项)分为两部分:已知的(包括确定性的/稳定的)、未知的(包括不确定的/动态的)。已知的测试项,理论上都可以实现自动化;未知的部分,也可以用工具进行测试(模糊测试/随机测试等),更多地是依赖人的探索式测试。

 

640-23
这里是一个具体的应用,在敏捷开发模式下,最有效的测试策略是:新功能采用探索式测试,上个迭代已实现的特性测试(回归测试)采用自动化测试。在迭代的前期,一面对新功能随时采用探索式测试,一面开发上个迭代已实现的特性测试的自动化脚本(把不写测试用例而节约下来的时间用于脚本开发,而且这时脚本开发/调试效率高),也确实保证了回归测试是自动化的,也只有已知的测试通过自动化实现是有质量保证的,未知的测试靠人测试更有质量保证,靠工具测试是有很大的风险。为什么如此?由于篇幅关系,就不做详细分析,可以在见面时慢慢道来。

 

640-24 
概括起来,未来理想的测试离不开上述测试公式:
测试=检测 + 试验

.
测试=已知的检测 + 未知的试验

 

测试=基于确定性模型/明确测试预言的自动化测试 + 基于人工智能搜索的/基于工具随机/模糊模型的/基于人的探索式测试”。

Save

Save

Save

Save

Save

Save

Save

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com