当前位置: 首页 > 技术与资源 > 技术分享 > 正文

说说航空产品测试那些事

2015-12-10 18:29:57

作者:蒋娟新炬网络高级技术专家。


我接手一个产品的测试一般会先会从大的方向收集产品的相关信息,例如:产品的行业背景、行业规范、这类产品在整个产业链、生态所属的位置、产品的目标客户群体、产品的特点(卖点)等等。这个有点梅长苏知己知彼百战不殆的意思。这些了然于胸后,再根据具体的需求细化到测试方案、测试用例做到有的放矢。首先我们来说一下航空类产品的特点。


航空类产品的特点


航空类产品总的来说范围广、种类多,它有OA类的产品、飞行类的产品、运价类的产品、即时通讯类的产品等等。包含了功能测试、性能测试、APP测试等多种类型的测试。对于航空类产品,它的核心产品是运价类产品和飞行类产品。比如机票预订系统、运价系统等等,同时重点的产品还有OA类的产品,这是内部使用频率最高的产品,关注度高,版本更新也非常快。此外移动端逐渐成为航空公司进行电子商务和营销的首选途径,因此APP类的测试产品越来越多,这是近期的一个趋势,很多PC端的都要求支持手持端(包括手机、平板)。


在了解完产品特点后接下来我们需要对航空类软件测的规范和标准作一些了解。它是我们工作的导航仪。目前航空领域的标准有RTCA DO-178、RTCA DO-178B、RTCA DO-178C等一些国际通用的民用航空机载软件标准以及QJ 3027-19998航天型号软件测试规范。


这些标准和规范它们的制定初衷是为机载系统制定,我们测试的产品虽然是航空公司辅助型业务的产品测试。但是如果学习借鉴这些规范和标准对整个测试工作是有很大帮助的,比如以下几点:


(1)工作更成体系。


(2)对测试本身具有指导性。


(3)有利于和甲方沟通并增强甲方信心。


这里大致摘录一些D0-178B标准和QJ 3027-1998规范我们可以借鉴内容:


Ø  D0-178B标准


DO-178B标准的目的在于为制造机载系统和设备的机载软件提供指导,使其能够提供在满足符合适航要求的安全性水平下完成预期的功能。为了满足该目标,DO-178B给予了以下三方面的指导:


(1)软件生命周期过程的目标;


(2)为满足上述目标要进行的活动;


(3)证明上述目标已经达到的证据,也即软件生命周期数据。


DO-178B的主要内容也就是介绍过程、数据、目标这三个方面的适航要求。这三方面适航要求是辩证统一的关系,即一旦选择了DO-178B标准作为符合性方法,就必须满足该标准所定义的所有适航目标,而满足这些适航目标的途径则是执行该标准所建议的过程和活动,为证明这些适航目标被满足,应按照该标准所定义的软件生命周期数据来组织相关证据。


其中RTCA DO-178C是在RTCA DO-178B上的升级,新增了空中交通管制、地面软件、模型的设计和开发等7个标准。调整了一些开发,验证的活动过程和工具等级定义。1996年DO-178B已等同转化为我国航空行业标准HB 295-96《机载系统和设备合格审定中的软件考虑》。


Ø  QJ 3027-1998规范


QJ3027-98它是航天型号软件测试规范,规定了航天型号软件的单元测试、组装测试(软件部件集成和测试、确认测试 (软件配置项测试)、系统联试及代码审査、回归测试的进入条件、测试流程、通过准则及评估要求。这里我们着重看一下系统测试的技术要求。


技术要求:


1)  可安装性测试:验证安装规程的正确性,包括程序加载及安装结果的正确性检査。


2)  功能测试:对软件研制任务书规定的各项功能进行测试。


3)  性能测试:测试软件研制任务书规定的各项性能,如数据处理精度、响应时间等。


4)  人机交互界面测试:测试所有交互界面,以非常规操作、误操作来检验界面的可靠性。


5)  外部接口测试:检验软件与系统之间接口的正确性和协调性。


6)  安全性测试:检验是否满足研制任务书规定的安全性准则,重点检验软件的容错能力。


7)  性能强度测试:信息值超过额定范围的处理能力。


8)  降级能力强度测试:检査其自计算机硬件失效时自身系统的恢复能力。


在了解完产品、标准和规范后我们真正开始实施测试工作。这里有几个实际工作中的经验点跟大家分享:


规范和标准的应用


以上的规范和标准我们可以实际应用到体系建设和相应规范、流程的制定中去。体系建设我们还需要同时参考国标、国军标、CNAS、CMMI以及航空领域的一些先进航空公司的IT经验,像达美航空。再结合目前航空公司的现状,综合制定出适应国际形势的、适用的流程、规范。


如何选择项目?


航空类产品百花齐放种类繁多。产品所属领域的划分明确比如地服、巡检、空乘等等。不同业务领域的测试规格也不一样。按项目周期分长期、中期、短期项目。按项目类型分自建项目、合作项目、外包项目。通常合作项目和外包项目会有供应商内测完后再提交过来,缺陷相对会少一点。而自建项目基本上是没有经过专业测试人员内测提交过来的,缺陷会比较多。因此我们如何选择适合自己的测试项目尤为重要。来者不拒?做一个算一个?这种选择方式导致的后果是:你死的很惨!我的经验是,首先对目前团队的人员分析,综合考虑大家的能力,可以完成的工作量。其次对项目分析, 选择重点、可扩展、领域覆盖广的项目。最后要考虑风险,预留一定时间给团队处理项目中可能产生的人员流动、请假、前期项目延迟等特殊情况。


快速获取需求


目前国内航空公司的IT发展比国外要慢,流程上也不是太规范。开发提供的需求往往是不完整、不清楚、甚至没有需求。即便如此测试仍然要进行,流程可以逐渐去改进。由于航空类产品有它专业的业务知识,像航班预订、航线选择、价格核算、机务组管理、团体购票、散客订票等等这些业务规则。如果是未接触过的新手如何去快速获取需求呢?我们获取的途径可以通过产品手册、供应商的测试人员、开发人员外加实际操作去了解。另外在流程上我们可以作一些要求,比如跟甲方接口人沟通好,流程上作出控制。开发必须提交测试需求我们才会接收版本进行测试,需求描述不清楚的直接退回。


数据比对要严谨


运价类产品像销售平台、shopping系统、MUFare等类型的产品一定要注意数据正确性的比对,一旦出错会直接导致严重的经济损失。所以勿必慎重!通常我们是以后台数据库表或者是开发指定的官网数据来进行数据校验。


性能测试的技术要求


性能测试在航空类产品中最多的是接口类测试,无论是PC端还是APP端几乎都是接口类的性能压测。如:Java接口、Web Services接口、Restful接口等等。对于这种类型的测试我们必须要了解清楚需求,比如:接口设计的支持并发数、请求是否需要带入参、系统的架构、调用方法等。


不同类型的接口调用方法和技术略有不同,要先对这些基本技术加以了解。选用工具的原则是易于操作、监控信息过程透明、返回结果准确、数据分析清楚的原则。采用较多的工具像LOADRUNNER、SoapUI等。通常像订票系统、查询系统等对系统性能要求会比较高。


UXI测试的注意事项


航空类产品很多是针对特殊领域的,像HCC、巡检、移动乘务等这些,UXI测试通常需要从这些特地群体中抽取人员去进行测试。另外也可以借助一些专用仪器像眼动仪等设备去分析用户的使用习惯。


兼容性测试的策略


我做的航空类APP测试,都会要求做兼容性测试。兼容性测试通常包括主流机型、主流版本、不同手机屏幕分辨率、不同网络等等兼容性测试。以后台数据库获取的TOP10机型表为依据,目前的国产机型占用比呈增长趋势。通常我们在实际测试中不会对TOP10的所有机型进行测试,需要结合实际设备去选择机型。如果开发组没有特别要求的情况下就是iOS系统和Android系统各测试一台主流机型如iphone5、三星 Galaxy S5,另外也会加上iPad。如果开发组有特别要求,根据具体情况增加机型,包括小米、华为、魅族等。这里需要特别注意的是对于一些流程审批类的产品在机型的选择中需要优先考虑审批领导的使用机型,他们是使用产品最多的用户,他们的意见也是相当重要,切不可轻视,后果很严重!


版本控制


航空公司因为是国有企业,会带有一些特定的企业特质,他们的功能开发计划以及版本发布时间相对不是太有计划性,受上级领导影响的因素较多。版本的发布也不会有固定的时间,即使是固定的时间这也是有相对性。所以在接受版本前要跟甲方接口人、开发经理一起确定好发布时间。


最后总结一下:


Ø  有效的沟通


良好的沟通是一切美好的开始。有效的沟通会让局面豁然开朗,无效的沟通会让你步入窘境。


Ø  理解测试的真正意义


我们是帮助开发人员发现问题,而不是为了证明他的出现是个错误。没有人会喜欢被批评,但所有人会喜欢帮助他进步。


Ø  更上层楼


IT行业迅速发展,测试技术日益更新,学习总是不在断进行,斯大林同志曾经说过:落后就要挨打,所以闲来无事就多多学习。


以上是本人对这段时间航空测试的经验总结,希望对即将步入航空类测试的新手们有所帮助。

上一篇:为何你不是客户心中的那棵菜
下一篇:Mysql查询缓存研究