51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2554|回复: 0
打印 上一主题 下一主题

精准测试之项目案例实战大剖析(上)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2015-12-29 16:37:27 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

精准测试之项目案例实战大剖析(上)
一、     前言
测试是保证产品质量的关键环节,不论是从开发人员开始的单元测试,集成测试,到测试人员的系统测试,产品的需求测试,客户的验收测试,都是为了保证产品能够更健壮的在市场上服务于用户,但是测试的整个工作和过程并不像开发的工作一样有一个产品的产出,所以更大程度上增加了对测试工作质量的考核,也就造成了对产品测试完成后无法有一个可靠的依据去判断是否能够保证产品在市场中稳定运行,测试过程中也必然存在着在各种各样的问题和困难。
在传统的测试中,测试后期往往会出现如下几个问题:
1.  测试范围不足、漏测
经常出现开发改动测试不知道、或者测试范围评估不足以及测试人员对产品没有足够的了解等都会导致测试漏洞风险高,成为线上事故的导火线,并期望能够通过代码覆盖率工具提高覆盖度。
2.  进度、时间赶,上线心里没底
测试:“时间太紧,感觉没测试全就上线啦!再有几天就好了。”时间紧迫,根本无法规划自己的测试思路和范围,感觉自己没有测全,心里没有底儿。如果可以有工具帮助做测试的筛选和统计就好了,通过代码覆盖率判断产品是否能够达到上线标准。
3.  测试回归范围大、成本高
有时候开发给出的回归范围太大,导致测试回归测试成本很高。时间上和人员上都需要大量的资源投入,还是希望能够通过代码覆盖率工具做到精准测试,从而降低不必要资源的投入,提高工作的效率。
4.  测试与开发关系沟通问题
测试和开发在后期交流中因人为交际因素往往产生各种不可预计的状况
如:
友好:
开发修改完代码后,测试人员直接询问开发是否测试过,如果开发自己测试过一遍,测试就认为已经测试完毕。
矛盾:
出现重大问题后,开发和测试相互推卸责任,导致团队开发和测试关系僵化。
下图为2015年某明星互联网产品公司线上事故的范围:
我们可以看到,在整个事故中一大半都是因为开发与测试沟通或测试对业务不了解,遗漏而产生的故障。要避免这样的事故,首先需要把占比高的问题解决,就可以从很大程度上提升产品的质量。
那我们该如何去解决这些问题,我们从下面的九点钟项目案例中讲解对于提高测试的覆盖率,测试开发的沟通,测试的遗漏,测试范围评估错误等如何有效的利用现有资源进行解决。
二、     九点钟项目简介
九点钟酒店控项目是一款酒店垂直细分领域的钟点房预定APP,它可以让用户通过手机端的应用预定上海的合作酒店,方便快捷,通过自动定位选择附近的可预订酒店,以及按照价格和距离等选择合适的酒店进行预定,经济实惠,提前预定,解决外出住宿问题。未来,它还会跟更多的旅游频道合作,发展空间很大。
  
三、     目的
本文描述九点钟项目的安卓APP,在精准化测试平台(星云测试)通过测试得到测试报告以及相关的测试数据分析,通过手工黑盒测试和程序内部的逻辑测试对整个应用的质量把控,降低产品上线后存在的问题。
四、     测试用例的设计
采用常规的边界值分析法,正交分析,因果图,以及等价类划分等多种方法进行测试用例的设计,例如:
1、  对于输入框字符长度有限制的采用限制字符数的边界值进行测试用例设计
2、  对于搜索项进行因果图方法设计测试用例
3、  对于酒店列表筛选进行正交分析法进行测试用例的设计
4、  根据用户的体验习惯进行探索性测试等
五、     测试环境与配置
1、  本地环境(云测试版本,主需要配置本地的客户端使用环境,服务在云端不需配置)
2、  PC端测试网络需要能够连通星云测试服务端的地址即可
3、  手机端的可以使用WIFI,或使用USB连接测试
六、     测试方法和测试工具
测试方法:
采用黑盒手工测试的方法,进行测试
测试工具:
采用星云测试Android云测试版客户端2.1.4版本进行测试,该工具通过手动的黑盒测试驱动,检测和记录程序内部的执行逻辑,快速定位BUG,并且自动捕捉程序崩溃点,测试回归筛选,测试数据整合展示云测试精准报表,对于测试人员、设备以及测试任务执行时间按照天为单位进行统计用图表形式展示整个过程的趋势。并且对整个项目的代码质量重复度,复杂度,可维护性等进行了指标分析和展示。
注意事项:
            下面的分析均有代码表述,如测试人员无查看代码权限,可只使用测试数据和开发人员进行交互分析,开发人员通过星云平台测试数据在本地关联代码进行配合分析。
七、     代码的静态分析



很多项目到了后期都会出现较难维护的情况,主要是因为代码量的增加以及开发人员的变动或代码的编写规范导致对其后续人员对内部逻辑理解困难。
通过静态监测分析我们可以看出九点钟项目在代码中缺少了大量的注释,并引用了大量的重复代码以及违规的代码,重复代码会造成重复部分容易出现缺陷重复等问题,违规代码会造成代码的易读性和维护变得困难,并且还会存在潜藏的代码逻辑BUG以及资源关闭等等代码中容易出现错误的地方,因此要根据一个特定的规则集进行代码的规范,这些虽然在项目生成以及使用上不存在问题,但是考虑到开发人员的交替以及后期的维护缺存在了大量的风险。
通过静态指标可是化查看违规以及重复的代码位置,用此数据报告和开发进行交互并可要求对代码进行改善


分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏2
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 11:53 , Processed in 0.067169 second(s), 23 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表