App的测试，和传统软件测试有哪些区别？

App的测试，和传统软件测试有哪些区别？应该增加哪些方面的测试用例？

随手机对人们生活中的影响越来越大，App测试工作逐渐被众人所知。从一开始的众包到现在的自动化探索，手机测试上的技术发展也是日新月异。

App测试相比以往传统的软甲测试相关要复杂的多且困难的多。

基于工作经验，我将如何做好app的测试归结为如下内容。

(1)   非功能测试

app测试的一个重要方面是app的非功能需求。移动app在推出市场或进行进一步开发前，测试人员有一定的职责做该类需求的跟踪工作。

早期开发阶段要进行的第一个测试应该是实用性测试。通常是由alpha用户或同事进行的。走进一家咖啡馆或餐厅，问问里面的人他们的app使用情况。让他们看看现阶段开发的第一个版本并收集反馈，看看用户是否能很好地使用新功能，以便得出第一印象。

(2)   功能测试

每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。

除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。

(3)   客户端性能测试

一个App做的好不好，不仅仅只反应在功能上。被测的app在中低端机上的性能表现也很重要。比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端机上卡的不行，也不会取得好的口碑。

关于App的性能测试，我们比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。

目前大家可能比较困惑的一个问题，多高的CPU，内存，耗电量，流量，FPS才算是符合发布的值呢？这里可以告诉大家，可以参考精品游戏的一些数值，将自己研发的app与业内精品的app数据做对比。

(4)   适配兼容测试

App在经过功能测试后，也需对其进行适配兼容测试需要检查的项主要有以下几点：

(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常；

(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常；

我们在实际测试中，常常会遇到下列问题：

(a) 在某个平牌某个系统上，app安装不上；

(b) 在某个平牌某个系统上，app无法拉起；

(c) 在某个平牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；

(d) 在某个平牌某个系统上，app无法顺利卸载；

（WeTest腾讯质量开放平台）这个产品可以实现多款热门机型的适配兼容测试。

(5)   弱网络测试

App在使用的过程中，难免会遇到弱网络环境，例如在公车上、在地铁里。在这种情况下，常常会出现网络抖动、上行或下行超时，导致应用中出现丢包。

作为一个测试人员，我们要对app在上线前做一定场景的弱网络环境模型，并查看app在弱网络环境下是否存在某些未知的问题。下面是我们常用的弱网络环境场景：

(a) 3G弱网络信号场景模拟；

(b) 市区低速移动场景模拟；

(c) 郊区高速移动场景模拟；

(d) 请求回应超时_上行超时场景模拟；

(e) 请求回应超时_下行超时场景模拟；

(f) 网络抖动场景模拟；

(6)   耗电量测试

App在手机上的表现，除了功能外，app是否耗电，也是测试过程中重点要关注的一项。手机设备在满电的时候，这个App能玩多久；App每小时的耗电是多少；App在某个场景挂机10分钟耗电量是多少；这些都是我们平时在耗电量测试中比较关注的点。

(7)   协议测试

模拟客户端直接发送协议包给服务器，看看服务器是否有一定的校验，认不认客户端发过来的数据。协议测试，主要是为了处理用户发送恶意协议到服务器，骗过服务器的校验。

(8) 安全测试

App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。

(9) 服务器性能测试

服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。

这个可以在WeTest入口预约。

(10) 服务器容灾测试

服务器容灾测试，主要指某个服务进程奔溃掉后，是否具有自行恢复能力。比如游戏逻辑进程消失后，是否会自动拉起；memcached崩溃时，是否会重新启动，是否会对所有玩家有影响。这些都是app测试过程中需要考虑的因素。

(11) 中断测试

针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前台和后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。测试电话，短信，彩信，微博或其他通知进来时app的反应。

(12) 上线后期的舆情跟踪

新的app上线后，用户对此应用的评价，存在哪些测试期间未察觉的Bug，论坛上对于该应用热门的帖子有哪些，应用商店中该应用的口碑如何等，都是app在上线后，测试人员需要关注的点。若需要测试期间未发现的Bug，需要新测试服进行确认并根据该问题的修复。

App的测试，和传统软件测试有哪些区别

A：相同点
不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识：
1）同样的设计测试用例方法：边界值分析法、等价类划分、错误推测法、场景法等（若想看这些基础课视频，直接点击原文看腾讯课堂的视频，都有，且免费！）；
2）同样的测试方法：黑盒测试，验证业务功能是否正确符合用户或者设计预期；
3）都要检查UI：界面的布局、风格和按钮等是否简洁美观、是否统一等；
4）页面性能检测：测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5）应用的稳定性：测试应用系统的稳定性等，不会闪退卡死等。
B：不同点
相对于web测试，APP测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以APP测试过程中还需要注意如下几个方面特性：
1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。
中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：
a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断
b.短信中断：接收短信、查看短信
c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（系统死机、重启）
2）手机用户对app产品的安装卸载操作：
a.从上一个版本/上两个版本直接升级到最新版本。
b.全新安装新版本
c.新版本覆盖旧版本安装
d.卸载旧版本，安装新版本
e.卸载新版本，安装新版本
3）web自动化测试使用的工具较常用的是QTP，而android手机自动化测试工具比较常用的是monkey、monkeyrunner、appium。

软件测试的方法一共有几种

1、从是否关心内部结构来看

（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2、从是否执行代码看

（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

3、从开发过程级别看

（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。

（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

在系统测试中，对于具体的测试类型有：

（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。

（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。

（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。

（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。

（6）余量测试：对软件是否达到规格说明中要求的余量的测试。

（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，

（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。

（13）容量测试：检验软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。

（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。

4、从执行过程是否需要人工干预来看

（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。

（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）

5、从测试实施组织看

（1）开发测试：开发人员进行的测试

（2）用户测试：用户方进行的测试

（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性

6、从测试所处的环境看

（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试

（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告

扩展资料

软件测试的内容：

1 得到需求、功能设计、内部设计说书和其他必要的文档

2 得到预算和进度要求

3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )

4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制

5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试

6 确定对测试环境的要求 ( 硬件、软件、通信等 )

7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等

8 确定对测试的输入数据的要求

9 分配任务和任务负责人，以及所需的劳动力

10 设立大致的时间表、期限、和里程碑

11 确定输入环境的类别、边界值分析、错误类别

12 准备测试计划文件和对计划进行必要的回顾

13 准备白盒测试案例

14 对测试案例进行必要的回顾 / 调查 / 计划

15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据

16 得到并安装软件版本

17 进行测试

18 评估和报告结果

19 跟踪问题 / 错误，并解决它

20 如果有必要，重新进行测试

21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具

参考资料：百度百科-软件测试

软件性能测试包括哪些

根据百度百科：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
您可试用一些测试平台进行性能测试。
例如优测。优测为企业提供API全生命周期质量解决方案、压力测试、兼容性测试、移动应用自动化测试、WebUI自动化测试等多样化测试产品。

我们动用了十二台手机，为你展现安兔兔V8的全貌

几天前在ROG与腾讯联手发布了那台超旗舰 游戏 手机后，我们三易生活曾一度点出，这种软硬件厂商联合，针对顶级手机制作顶级内容的模式，将会让智能手机的 游戏 生态从此向如今的PC领域靠拢。说得更直白一点，就是“所有的手机都能玩 游戏 ”、“所有的手机玩 游戏 的体验（画面、流畅度）都差不多”的时代即将结束，智能手机在软件体验上的“阶级差异”将会进一步放大。
因为这一次，全新的安兔兔V8正是为那些越级的超旗舰而生。更重要的是，它也进一步昭示了5G时代的智能手机所应该具备的那些，过去我们可能没有重视到的性能细节。
那么首先让我们来看看安兔兔V8版本的软件界面——正如各位所见，这一次安兔兔V8的主界面风格变化幅度远没有当初V6迭代到V7时那样“翻天覆地”，但仔细对比还是不难看出一些改动的。
在V7中，安兔兔的界面设计主打的是“减少滑动操作”，这固然使得软件的首页变得更为简洁，但也造成屏幕坏点测试、多点触控测试等实用的小功能被折叠到了二级菜单中，反而可能造成一些用户的迷惑。而V8则改为所有的测试项目都直观地平铺在了软件开启之后的第一页上，如此一来那些其实很管用的小测试，就能更快地被用户发现，更好地体现它们的价值。
比如说，HTML5测试可以在一台手机上对比不同的浏览器APP的性能，可控区域检测可以查看屏幕边缘是否存在触控失灵，灰阶测试则能够让那些低灰阶位数的屏幕（比如某些6bit屏）原形毕露，也可以用于查看手机屏幕白平衡是否过暗/过亮等。
除此之外，本次安兔兔V8也首次在首页加入了AI测试的链接——之所以说是链接，主要是因为当前的安兔兔AI测试还处于Beta阶段。目前尚未适配所有的手机SoC（比如麒麟980的双核NPU支持就很差，以至于不能运行），也不具备大家喜闻乐见的跑分排行榜，因此其尚未直接集成到安兔兔主程序中，因此有需求的用户可以自行下载安装。

不管是电脑还是手机上的测试软件，其根本的职责都在于能够反映出当下整个行业中，不同定位的产品之间的性能差距，并告知用户自身的设备是否能够支撑起相应的软件体验。
这意味着什么？这意味着测试软件必须要紧跟最新技术趋势，能够针对最先端的处理器架构、设备性能和功能做出优化，并将其以正确的比例反映在最终的评价体系中。

而这也正是此次安兔兔V8最大的改变所在：首先，V8版本几乎完全重写了针对内存的测试部分，增加了针对智能手机剩余内存、剩余存储空间的考察，增加了超大内存和超大存储的得分比重（比如说某12GB+1TB的超旗舰，理论上就会有更大的优势）；同时在存储IO性能的测试中，既会考察闪存的原生性能，也会考察厂商的优化手段（比如磁盘缓存算法之类），以更多地体现系统优化对于日常流畅度的影响。
其次在3D 游戏 性能的测试中，安兔兔V8对测试场景进行了大幅更新，保留了此前的《精炼厂》场景，作为OpenGL 3.2（或3.1+AEP）API下的测试项目。而将早前的《海岸线》场景则升级为Vulkan API，并新增了完全重新开发的超重压力Vulkan测试场景《兵马俑》。

值得一提的是，根据我们从安兔兔方面获得的消息显示，本次V8版本还强化了对90Hz及120Hz在内的高刷新率屏幕的支持，但由于一加7 Pro对于高刷屏采取白名单制度，因此目前在尚未适配的情况下，其安兔兔V8上的成绩并不能发挥出高刷屏的优势。而不采用白名单方式的华硕ROG与努比亚红魔3，则可以在3D测试中得到更高的帧率成绩，得以充分反映出高刷新屏+旗舰SoC的流畅度优势。

为了测试本次的安兔兔V8，我们三易生活也可以说是“下了血本”，足足动用了十二台设备参与测试。其主控型号涵盖高通、三星、华为、联发科四大品牌，基本上包含了当前从千元级到顶级旗舰的几乎所有可能性，内存大小也从6GB一直到12GB，闪存容量则从128GB到512GB都有。当然，就连目前依然少见的高刷新率旗舰我们也基本找齐：华硕ROG 游戏 手机2、内置风扇的努比亚红魔3、还有号称屏幕比肩三星Galaxy S10的一加7 Pro，可以说是应有尽有。
需要说明的是，为了能让各位“选手”发挥出最佳水平，我们尽可能地通过设置提高了它们的性能：其中OPPO、华为、三星手机均开启了性能模式，红魔3和红魔Mars打开了竞技键（黑鲨 游戏 手机2 Pro的SHARK SPACE功能暂时还不支持安兔兔V8），ROG 游戏 手机2则是启用了X Mode并套上了外置风扇。所有的测试手机均置于室温强对流环境下以避免积热。

废话不多说：先上安兔兔V8跑分详表（数据太多，分了两张图）：
看得不清楚？这里还有总分排行榜：
首先，眼尖的朋友可能已经注意到我们给某台机型打了马赛克，这是因为它还没正式发布之故。不过大家可以将它看作是高通骁龙712平台的参考设备，主要考量其与骁龙710之间的性能对比。而至于V8版本的安兔兔跑分结果普遍比V7高了一截，这自然是测试项目和分数比重变更的结果，当然它同时也就意味着，安兔兔V8的得分是不能与V7版本进行对比的。

其次，有心的朋友或许能看出来，V8版本的安兔兔对于手机的存储性能测试做了更为明确的划分，新的测试项目已经非常接近传统PC测试软件的存储性能测试模式了，且包括顺序读写与随机读写的得分，也基本上和对应的闪存类型完全符合。但唯独有一个项目“应用存储速度”是其他评测软件上极为少见的，而且它似乎并不受闪存速度/闪存类型的影响。那么安兔兔V8上新增的这个存储测试，到底反映的是手机的哪一项性能指标呢？
我们将这一项成绩单独提取出来看，答案就呼之欲出了：它是同时考量的手机的闪存读写性能以及可用空间大小。说得更直白一点，它反映的是手机“装了多少应用之后还能不卡”的能力。虽然这样的测试项目在以往的评测软件中从未有过，但很显然，它对于智能手机的使用感受却具有相当大的参考价值。
针对本次安兔兔新增的，面向最高配手机的Vulkan图形测试项目《兵马俑》，我们选取了几款手机，将其得分与知名图形测试软件3DMARK的Sling Shot Extreme场景图形分进行对比。可以看到相比于3DAMRK，安兔兔V8的图型场景测试分数高下之间的差异比例相对来说还是“温和”了一点。
最后值得一提的是，本次的安兔兔V8还在成绩的最后附上了评测前后温度变化的情况。很显然，这也是专门针对某些手机“冰箱大法”或“冷柜大法”跑分的反制措施。通过观察跑分后的温度以及温升情况，就能很方便地判断手机是否处在一个正常的室温环境下，是否采用了特别的冷却措施等等，从而进一步降低了跑分“作弊”的可能性。

其实说到手机“跑分”这个事，它如今的热度自然是不比曾经那个“核战”的年代。特别是随着智能手机从增量市场逐渐转向存量市场，对于许多至今依然使用着几年前的老机型，或者只愿意使用百元机的用户来说，跑分几乎可以说是他们最不会考虑的应用场景，没有之一。
但是有入门级用户，就自然也有顶级的发烧友——无论是因为介意新机的 游戏 性能，还是仅仅只是出于好奇想知道刚入手的新旗舰到底“成色”几何，紧跟技术潮流的最新跑分软件，都能给这些消费电子的中坚用户们以最为客观的回答。

如何加强软件需求管理，提高软件质量

一、什么是质量？ 作为软件产品的销售人员，市场人员或维护人员经常会受到客户这样那样的指责或抱怨，客户说：你们产品的质量太差，不稳定等等。那么什么是质量呢？我们该如何来衡量质量呢？ 质量具有三个维度： ?? 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。 ?? 符合需求。即产品是不是在做让它做的事情。 ?? 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。 ISO 关于质量的定义表示如下： “ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ” 注意，在这个定义中包含明显的需求和隐含的需求。而往往我们会忽略隐含的需求。因此在控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。 另一方面因为我们的产品是为客户提供服务的，因此凡是不满足客户需求的，我们都认为是一个失效（ failure ）。所以我们的产品必须始终围绕着客户的需求进行开发和验证。 这里我们谈到客户，其实在一个软件的需求收集过程中需要关注客户和用户。而我们经常会忽略客户与用户之间的区别。那么谁是客户？谁是用户呢？简单的来说，客户是真正能够决定是否购买你软件的人，而用户是实际使用软件的人。了解了这个区别，对于你在分析需求的重要性的时候就可以进行参考。同时在产品质量验证的时候也可以做出不同的权衡。另一方面我们在考虑我们用户需求的时候，往往只考虑了实际使用软件的人员，而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争，这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。 每个人提到质量的时候，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺【 5 】： ?? 质量需要一个承诺，尤其是高层管理者的承诺。但为了得到质量，高层管理者必须和其雇用的员工进行紧密合作； ?? 许多人相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数是正常并可接受的； ?? 质量经常是和成本紧密联系在一起，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾； ?? 一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析。然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书； ?? 技术人员经常相信规范和标准会束缚他们的创造力，因此就不遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。 二、流程对质量的贡献 好了，既然已经了解了什么是质量，那么怎么才能改进软件产品的质量呢？从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提高工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围要求。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。 无论做什么事情，都有一个循序渐进的过程，从计划到策略再到实现。软件流程就是按照这种思维来定义开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，不同的过程模型适合于不同类型的项目。瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。 螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险【 8 】。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程【 9 】。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图 1 。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。 图1 RUP 工作流程示意图 IPD （ Integrated Product Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图 2 。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。 图2 IPD 流程示意图 三、流程与技术 流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。 需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 —— 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍【 7 】， RUP 中关于需求的指导也是很实用的。 设计是最能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在 RUP 中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。 UML 是国际上比较流行的一种建模语言【 11 】。在嵌入式方面， SDL 也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书【 6 】，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。 现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序员设计的程序使用的算法并不是最优，但却是最不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品最终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成，还需要给以后版本重用和维护。 测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。 四、全面质量管理 自从 Deming 的全面质量管理（ TQM ）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。产业界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和最终的缺陷）数量的 50 ％到 65 ％。根据 IBM 的研究表明，假定在分析阶段发现的错误其改正成本为 1 个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为 6.5 个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为 15 个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为 60 到 100 个货币单位。同样该比例也适用用于发现一个错误需要的时间。我们可以看下面两条曲线图： 图3 缺陷代价曲线 为了提高产品质量，缩短产品开发进度，节约产品开发成本，必须尽早的进行产品质量控制。全面质量控制要求在过程的每个阶段每个步骤上都要进行严格的验证和确认活动。 什么是验证？ 验证 就是要用数据证明我们是不是在正确的制造产品。注意这里强调的是过程的正确行【 12 】。 什么是确认？ 确认 就是要用数据证明我们是不是制造了正确的产品。注意这里强调的是结果的正确性。 IEEE 给出的验证和确认过程可以用下图来表示。验证和确认是一个广泛的概念，感兴趣的读者可以参考 IEEE Std 1012-1998 。
图4 验证和确认模型 五、关注测试 软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的 50 ％左右。 软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试。 一般我们可以把测试分为白盒测试和黑盒测试。 白盒测试 ：顾名思义，白盒测试应当是透明的。的确，该类测试是根据程序代码的内部逻辑结构来设计测试用例进行测试。那么什么是测试用例？ 一个 测试用例 就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 黑盒测试 ：看了白盒测试的解释，我想你很快就能猜出黑盒测试是不考虑程序内部结构情况的。事实上也是这样。黑盒测试是根据规格说明书进行的测试。 规格说明书 记录了用户的需求。比如用户希望在编辑器中增加查找功能，那么我们把该需求写入规格说明书，根据该项要求，直接调用应用程序的该项功能进行测试，而不管其内部是用什么算法实现的。 白盒和黑盒这两类测试是从完全不同的出发点，并且是两个完全对立点，反映了事物的两个极端，两种方法各有侧重，不能替代。但是在现代测试理念中，这两种测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。 常见的白盒测试是单元测试。 单元测试 是测试中最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，桩模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点，循环点，选择分支点等）。 驱动模块 是模拟调用被测函数的函数。 桩函数 是模拟当前测试函数所调用的函数。 常见的黑盒测试包括：集成测试，系统测试。 集成测试 是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 系统测试 的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。系统测试的内容极其广泛，包括功能测试、协议测试、性能测试、压力测试、容量测试等等。有关测试方面的概念可以参考本人已出版的《软件测试技术概论》。 软件测试是产品最终交付到用户之前的最后一道防线，有着举足轻重的地位。然而，做好软件测试却是不容易的，一方面你需要同时掌握软件开发的技能和软件测试方面的技能；另一方面产品必须给予测试充分的独立性和资源保证。 六、成功的铁三角 在一个软件企业中，如果能够良性的发展，必须关注组织，流程和人三者之间的关系。组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；流程对于产品的成功有着关键的作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量，反之则会拖延产品开发进度，并且质量也无法得到保证；对企业来说，人是最宝贵的财富，它们是技术的载体。对于一个软件公司来说，无论是开发人员还是测试人员，都非常关心其今后的发展通道，如果有一条清晰的技术发展线为其指明今后的职业发展方向的话，这可以大大激励员工的士气和工作积极性。另外技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。 总之，组织，流程和人这三者是一个企业成功的铁三角，理想的情况下它们彼此促进，糟糕的情况下它们彼此制约。 七、国际上流行的质量标准 最早进入国内的质量标准是 ISO 系列。在软件方面主要使用 ISO9000 系列标准。 ISO9000 是一个非常完整的标准，并且定义了供应商设计和交付一个有质量产品的能力所需要的所有元素。 ISO9002 涵盖了对供应商控制设计和开发活动所认为重要的质量标准。 ISO9003 用于证明供应商在检视和测试期间检测和控制产品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相关的质量标准，并提供了一个完整的质量查检表。 软件能力成熟度模型是目前国内软件企业中非常受欢迎的一个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框架的指导下： ?? 软件组织可以对其软件开发、维护过程获得控制。 ?? 软件组织可以推进其软件工程更为科学、推进软件过程管理更为卓越。 ?? CMM 通过确定当前软件过程管理的成熟度，通过标识软件的质量和过程改进中关键的、要害的问题，可以指导软件组织选择正确的软件过程改进策略。 ?? CMM 将其焦点，聚焦在一系列具体的软件过程活动上，并以侵略方式（ Aggressively ）达到这些活动。一个软件组织就可以稳定地、持续地改进其整个软件组织过程，使得其软件过程管理能力取得持续地、持久地不断争长提高。 在 CMM 中，把软件工厂分为五个等级：初始级、可重复级、已定义级、管理级和优化级。其中： 初始级 ：软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。 可重复级 ：人们根据多年的经验和教训，总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 已定义级： 要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。 管理级 ：所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。 优化级： 的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 美国国防部规定，重要性级别高的软件应该由质量级别高的企业承担。不同等级的软件公司提交的软件，其软件质量也相差很大，国外的一份统计资料如下： 表 1 、 CMM 级别与软件质量关系表格 每千行软件的缺陷数目
软件过程成熟度等级
软件准时提交的百分比
每人每月生产的程序行数
软件需要返工的百分比
平均软件失效时间（近似）

大于 10
初始级
<=50
Z
>=45
2 到 60 分钟

小于 10
可重复级
90
1.5Z
20
1-160 小时

小于 1
已定义级
99
2.5Z
10
不确定

小于 0.1
管理级
降低开发时间到 1/2
5 Z
5
不确定

小于 0.01
优化级
降低开发时间到 1/4
10Z
<=2
近似完全可靠
对于很多已经推行或者准备推行 CMM 的公司来说， CMM 的起步是很难的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式【 1 】。企业只有开始 CMM 改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。 PSP 能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过 PSP 学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用 PSP ，从而有助于 CMM 目标的实现。 TSP 结合了 CMM 的管理方法和 PSP 的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用 CMM 的原则和 PSP 的技能去生产高质量的产品。 软件的生产过程及其它的许多子过程、软件的开发者和用户、以及系统的使用中存在着巨大的变化和不同，要使一个软件过程对软件生产的改善真正有所帮助，其框架应是由 CMM 、 TSP 和 PSP 组成的一个完整体系，即从组织、群组和个人三个层次进行良好的软件工程和管理实践的指导和支持。总而言之，单纯实施 CMM ，永远不能真正做到能力成熟度的升级，只有将实施 CMM 与实施 PSP 和 TSP 有机地结合起来，才能发挥最大的效力。 八、如何起步？ 质量改进需要花费成本，因此改进的途径需要视不同公司的规模、业务、财务状况、人员技术水平等多方面综合进行考虑。一般建议中型以上的较大的软件公司实施 CMM 体系。而对于一些小型的软件公司可以采取比较实际的，相对成本较少，且容易操作的方面进行，这些方面大致如下： ?? 实施简洁的开发过程体系，根据不同业务特点可以选择瀑布模型，迭代模型等，并在这些模型上进行适当的变化以适应于短平快的产品开发特点。 ?? 提高需求分析和设计方面的技术，例如：原型法技术，分析模式，设计模式，面向对象设计， UML 等； ?? 加强文档化工作。文档是经验的保留，对于一个企业要想获得长期的发展，必须加强文档化工作； ?? 加强编程规范工作； ?? 进行适当的测试工作，建议进行单元测试和系统测试； ?? 实施配置管理工作，加强版本控制； ?? 开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动； ?? 进行简单的度量分析获得；建议实施 PSP 活动；

性能测试包括哪些方面

性能测试包括负载测试和压力测试。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

关于App的测试，和传统软件测试有哪些区别？的介绍就到这里，以上就是小编整理的App的测试，和传统软件测试有哪些区别？全部内容了，欢迎大家留言讨论。访问菁英职教网了解更多相关内容（本文共20673字）