1 第一个问题,以系统化的视角看待
类似项目管理和系统架构主题,将理论与经验结合,系统化、全方位、立体、整体、全面、由表入里、由浅入深考虑软件测试时,
应该如何构建测试系统以支撑最初的需求和要求?此时,该如何把握测试构建的方向?如何站在全局性的高度看待测试问题。
其实,这里所谓的角度问题还是重点在于如何做这个点上,用于指导如何做这件事。
2 全局视图4W+H。What? Why? Where? Who? How?
Why 为什么要进行软件测试?
构建测试系统的目的是什么?促成软件产品达到设计要求或目标?促成软件产品达到更高性能、更高稳定性、更少资源消耗等质量属性?
这里探讨为什么的问题。先要弄清楚,为什么要测试,测试的目的是什么,然后才能自如的讨论如何做测试。
软件质量属性的要求?可用性、可靠性、性能、安全性、可维护性?--可移植性、可修改性、可扩展性、结构重组。
考虑清楚目的,反过来可以指导方法。
比如要实现可用性,该如何通过测试保证。
比如要实现安全性要求,又该如何通过测试保证。等等。
Where 在哪里进行软件测试?
可能是在开发环境,也可能是在模拟环境,还可能是实际环境。
When 在什么时候进行软件测试?
涉及软件测试的生命周期的问题。
测试开始于需求,与设计同步,与开发同时。
测试驱动开发,先进行单元测试用例的开发,再进行实际功能的开发。
软件维护期测试也是如影随形的,可以说测试的生命周期伴随着软件自身的生命周期。
Who 由那些人进行软件测试?
开发人员
测试人员
特邀试用用户
潜在用户
How 如何做软件测试?
这是重点需要考虑的问题。
从全局出发,对关键节点、状态的信息导出,形成有效跟踪日志信息(比如登录状态、协议点、是否上传下载、编解码状态等),用于指导测试
通过这些日志信息,形成整个产品的骨架信息。
What 软件测试都要做哪些内容?
或者是软件测试都要测试啥?与目的强相关
测试功能,各个具体的功能,功能的可用性
测试性能,满足设计要求?满足需求要求?
测试可靠性,根据影响可靠性的因素,具体展开
测试其他质量属性
3 收集资料,做合适的测试
测试的指导思路:避免为测试而测试,测试要有其目的性,突出重点,还要有高效性,达到事半功倍的效果。
另外也必须认识到测试有其适应性,不同类型的产品、不同的应用场景都有其特殊的测试要求,并不是每种测试方法都适宜,也不是每种测试方法都需要。
测试的手段方法收集。
每种测试方法,其难易程度、复杂程度要有正确的评估。最好是理论结合实际的统计数据来表达。
如果某种测试方法过于复杂,难以实施,而其产生的实际效果又比较有限,则可以做出取舍,放弃该种测试方法。
策略上,可以先易后难,先高效全面后深入细致。力争做到百分之二十的方法完成百分之八十的结果。
在理清上述问题后,再具体挑选方法手段,细化步骤,选择合适的工具,因地制宜的、有针对性的做测试
4 测试方法实践论
测试从大的方面划分,包括黑盒测试和白盒测试
黑盒测试
倾向于功能测试、集成测试、整机系统测试
单元模块测试
集成测试
功能测试
系统测试
预定义测试功能,测试用例
白盒测试
倾向于单元模块测试,自顶向下拆分,从系统拆到单元模块
路径覆盖测试
桩测试
自动脚本测试
模拟器测试
动态测试
静态测试
性能测试
支持工具
Bug系统
自动化测试平台、工具
5 各种方法的收集
参考手机平台:
按键模拟的自动化UI测试
Monkey MonkeyRunner
UI Automator
WEB 性能测试工具 Loadrunner
QTP是Quick Test Professional的简称
Selenium
Appium
Robotium
http://www.spasvo.com/ TestCenter测试管理平台
测试场景--测试用例--测试数据--测试轮次--测试结果,缺陷管理,报告导出
TESSY
CodeTEST
6 实际测试方法使用
UI模拟触摸测试,类似手机的Monkey测试
具体分为随机方式和非随机方式
随机方式不考虑费用损失,为正真的monkey测试
非随机方式,通过解析执行特定的测试脚本,走预订的切换路径进行针对性的测试
对于非随机方式,可以采用预录制方式,将用户操作信息录制保存到脚本文件中,从而简化路径生成。生成的脚本文件可重复执行,这样既方便当前测试,也方便后续回归测试
硬件单元的自动、半自动检测
目的主要是为测试硬件模块的连接通路,用户不参与或者简单参与,参与时也仅做正确与否的判断。这部分甚至可以采用人工智能方法,自动检测分分析画面是否异常。
可采用该测试的硬件模块有
1 串口通信正确性验证,通过收发echo
2 存储卡的检测,通过读写对比
3 按键正确性验证
4 摄像头正常使用验证
5 触摸屏准确性验证
6 显示屏无坏点,色彩正常验证
7 音频采样及频率验证
8 其他模块
构建完善日志系统,支持自动分析,引入大数据分析类似方法,分类别、可视化。
过滤导出关键路径,跟踪关键点信息
使用python语言,对日志数据进行格式化分析处理
关于日志系统构建和获取
可参考类似手机LOGCAT。
可参考Linux的日志系统。程序是否可以利用系统的日志系统?程序是否可以利用重定向将日志送到日志系统?Linux系统自带日志系统,syslog,rsyslog,用于管理系统的各种类型的日志。
另外,可以使用log4plus,开源日志框架,管理程序日志,支持将日志发送到日志服务器。就日志框架本身,大同小异,Android的logcat和log4plus是类似的。
日志数据内容可参考TR069协议,进行标准化格式化,方便对数据分析
日志系统的总体需求就是方便的获取设备的日志信息。进一步的,包括生成方式、获取方式和获取内容。
生成方式上,要简单易用,具有通用性,高效,尽量降低对正常程序逻辑和性能的影响。
获取方式上,可以输出到屏幕跑;输出到日志服务器,并从日志服务器拉取;输出到文件;输出到其他媒介,甚至如浏览器。
获取内容上,可以标准化、格式化,方便统计分析。比如分类、分级别,并进一步包含代码文件、行数、时间、进程号、线程ID等常规辅助信息,方便提取日志和分析。
甚至可以将日志作为数据的一部分,做大数据分析,利用分布式文件系统。
内置单元测试框架
单元测试可以对函数进行正确性和性能验证(可以定义执行次数并获取执行总花费时间)。
单元测试有比较多的现成框架,如Java类的JUNIT,c++也有GoogleTest。特别的,对于嵌入式系统,有一些更高级的测试工具,借助硬件仿真手段,深入介入执行代码,进行测试验证。
这类嵌入式第三方工具多用于工业设备,可靠性要求很高的地方,比如航天航空设备,汽车电子等。大多提供方便的测试用例构建方法,比如通过图形化的手段,降低测试用例编写难度和复杂度。
工具甚至可基于对代码进行分析做特定的测试介入。
这类工具往往也提供对行业标准的支持。提供相关的测试报告和认证服务。
总的来讲,在嵌入式设备上执行单元测试,具有一定局限性、复杂性,这类似在android手机上做单元测试。
单元测试主要通过对被测接口或函数的执行,利用传入特定的参数(正确或故意错误、边界等特点),通过判断返回的结果是否符合预期而做出测试通过与否的界定。显然,该类测试比较方便应用于:
单纯的算法处理类,比如:数学运算(比较、求和等数学运算)、特定算法数据结构的实现(堆、栈、字符串解析)、特定逻辑功能的实现(前面内容也包括在这类,简单增删查改及引申出来的登录、获取、保存等操作)
简单的逻辑流程及交互
其实一些独立的模块,功能性强、内聚性强、依赖少的模块,比较适合做单元测试。
相应的,就有一些不太适应做单元测试的场景,包括:
与硬件的交互,比如打开声卡,播放声音,暂停播放,关闭声卡这一系列操作无法通过代码本身完全判断成功与否,需要人为参与,视频也是类似,是否正常需要肉眼做观察的判断。
任务调度相关的流程,比如启动一个线程、执行特定操作、依赖特定事件触发的逻辑流程等。
无法通过返回值判断操作成功的逻辑流程,比如可视化、语音合成等相关操作,也是需要人为判断的干预。
有依赖的功能,比如对某个接口的测试,依赖一个或多个其他接口,且接口之下还有很多接口依赖。
接口与网络有交互。
操作依赖UI且交互的接口。
上述部分场景可以通过模拟隔离,在一定程度上实现单元测试。比如对数据库的模拟,对依赖模块的模拟,类似打桩,通过对横向(接口函数内调用)和纵向(接口函数内层次调用或者递归)多依赖的接口进行模拟隔离。
模块或功能测试框架,集成测试
UI自动化测试其实就可以改造成一个集成测试框架。
定义功能列表
对每一个功能定义专属操作步骤(涉及到UI操作,可以用控件、位置等其他要素模拟)
对每一个功能定义专属数据(参数+属性+外部数据)
对每一个功能定义检测条件及判断标准,完成与否,时间要求等
对每一个功能完善测试所需其他环境要素
对每一个功能,执行上述模块化(模板化)测试用例
根据执行结果,得到功能集成测试报告
系统测试
主要采用测试用例,预先建立测试用例集,做整体功能覆盖测试
很多时候与功能测试界限并不严格
系统测试可更多关注系统功能之前的其他质量属性,比如性能,可靠性、可修改性(可维护性、可移植性、可扩展性、结构重组)、安全性、可测性、易用性等。
系统测试目标为需求规格说明
可以使用多种方法测试,比如对性能,可以通过虚拟容器模拟用户数、终端数等;对于安全性,可以通过假想攻击模拟进行;对于可靠性,可以通过各种环境高低温拷机等方式测试。