我们相关行业在实际做产品的过程中,不可能每一次都说“我选择用户使用最多的一些功能”。它可能只占20%的功能,实际上是业务场景80%以上需求的时候,不能完全使用业务场景的方式来测试,我们用什么场景?同时进行着需求级测试,需求级测试是大部分企业或者合作单位用的最多的,是从需求的,比如案例设计、和概要设计的对称、对接,中间完成一些测试的构建,比如,包含单元集成、功能、自动化、性能稳定性测试,还有相关的安全测试等,这个就比较多了。
还有一条线是我们遇到大部分的情况,我们是要把产品交给用户的,而用户实际上他所需要的东西,就是我们一开始和用户、甲方谈出来的,他的验收测试的内容。一开始是要把验收测试评定出来的,而这时候在有个验收标尺的时候,把验收测试里面的功能性能项解决掉,就达到了验收执行流程。而整个三个方面是在模型提出来到现在试用过程当中有几个大的企业,在使用过程当中确实是把测试的质量、覆盖率已经提高到一定档次了,因为它是一种方法论,它是和V模型、W模型相等平的,这套模型在2015年中科院某所和发改委等这几个单位做过发表,还有在国际上做了一些学术的论文,大家可以了解一下。
这套模型解决的问题:
1、提高了测试人员的使命感和荣誉感,在这个过程中让他们认同我们作为测试工程师、测试负责人,我们从项目一开始就应该切入了,我们的荣誉感、使命感这个时候是最强的。
2、减少过程的冗余,尽早的不断地进行软件测试和以测试者引导开发等等。这是这些模型解决的问题。
刚才把模型介绍了一下,没有实际的方法是纸上谈兵,所以今天我把实际的方法给大家摘出来一些,主要介绍这几个部分:
1、对于提前准备测试环境、数据的工作的方式方法。
2、在自动化测试平台搭建的方式方法上。
3、专项测试的设计方法;
4、基于业务、风险、探索的测试设计方法和框架的整合。
5、测试数据资料的完备性与可追溯性设计与体系的挂钩。
这里讲了基于场景自动化的设计,着重说一下思维导图的。口头聊一下思维导图的设计,因为上一次分享聊完之后,很多朋友特别关注基于思维导图如何进行用例或者测试方案的设计和分析。
首先给大家解释一下我们会把思维导图分成两大部分,一个是用例分析的模块,另一块是我们需求分析的模块。而需求分析它是分为三步的,第一步是我们的明确需求分析;第二是继承需求;第三是一些隐含的需求。
明确需求大家都理解,我们在设计测试方案或者相关项目方案的时候,明确需求是很容易获取到的,它包含一些和甲方的项目开发合同,也包含一些产品的使用说明书、需求说明书,这是我们可以看到的明确需求相关的内容。
继承需求是什么,我们在设计用例、方案的时候,这套产品不是平白无故过来的,一定会有一个对标的产品或者对标的项目,我们就要学会把它的对标的项目拿过来,比如,同版本的或者是不同版本的,然后相同行业软件的,但是不是我们公司自己软件的时候,我们把他们的需求给提取过来,然后去做一些测试需求的提取;
第三个隐含的,行业内部或者我们的经验值,像军工行业、安全行业测试的时候有一些国际标准的,国标体系、国家强制标准、行标,而这里面的内容其实是很多的,但是我们作为测试人员去设计的时候,往往会忽略掉这块,因为我们的甲方/客户可能不懂,或者我们的产品经理也不明白,比如,我们的安全系统或者所有的系统、特种装备设备,它的性能要求到底是怎么样,高低温要求到底是什么状态,甚至我们进行一些动态的探索、探测渗透的时候达到什么情况才能满足这个要求,有些东西是国标、行业标准甚至国际标准,是完全已经规定好了,但是我们设计的时候没有想到的话,就一定会漏测或者测的准确度是不高的,这是我说的思维导图需求分析的左半部分。
右半部分是用例分析的模块方案设计。它主要包含六大模块,第一是功能性测试,第二是性能测试,第三是兼容性测试,第四是稳定性测试,第五是安全性测试,还有一个是安装性测试。这六个测试的用例或者方案设计的大体模型把我们整个测试的场景已经完全给涵盖进去了,这是用例分析。后面还有一些分级的问题,我们设计相关的思维导图的时候分三个等级,因为大家没法形象的看这个事情,大体聊一下。第一级就是分为安装性、功能、性能、稳定性、兼容性、安全性这样几块;第二级是我们对它进行的不同的功能细节的划分,比如像安全性测试一样,我们划分成平台安全性、数据安全性、业务安全性,这么三个大块,不同得大块代表的含义大家也都大体理解一些,我们测试的时候不可能只测试我们的数据安全,大部分人都说,安全性测试用AppScanner就可以了,这个也是很难的,它有些测试不全,因为我们还有平台安全,包含对于内存或者操作系统,尤其国家现在对于国产化的要求,我们会用中标麒麟或者达梦数据库,金蝶或者WPS。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!