软件测试基础理论2-产品模型

admin管理员组

文章数量:1547452

产品开发模型

1. 瀑布模型

- 需求（分析）

• 设计
  • 测试用例（case）
  • 开发设计（HLD概要设计、LLD详细设计）
• 编码
• 测试
• 上线
• 运维
  （1）缺点：
• 每一阶段都依赖于上一阶段的正确、完整，一旦某个阶段出现问题，需要回到上一阶段推到重来，如果是需求变动或者需求误判，那么所有已完成的工作都要付诸东流，越到后期风险成本越大- 开发过程中的错误，只有等测试时才能发现
• 需求变更，需要重新编码
  （2）特点：
• 简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不支持用户参与，要求预先确定需求。
  （3）适用范围：
• 需求易于完善定义且不易变更的软件系统- 规范化的流程。适合工业生产、军事、效率高、分工明确

2. 增量迭代模型

（1）增量

• 特点： 软件产品是被增量式地一块块开发的，允许开发活动并行和重叠。
• 适用范围： 技术风险较大、用户需求较为稳定的软件系统。
  （2）迭代
• 特点： 不要求一次性地开发出完整的软件系统，将软件开发视为一个逐步获取用广需求、完善软件产品的过程。
• 适用范围： 需求难以确定、不断变更的软件系统

增量迭代是RUP统一过程常采用的软件开发生命周期模型。增量和迭代有区别但两者又经常一起使用。假设现在要开发 A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间
则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的 基础功能都已经完成。RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一 个可以交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需求
->设计
->开发的瀑布过程
迭代周期的长度跟项目的周期和规模有很大的关 系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代
如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的交付和产出

因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决

但迭代模型在这方面更有优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化

业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同时每个增量也可以是独立发布的小版本
由于系统的总体设计 往往对一个系统的架构和可扩展性有重大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统的健壮性和可扩展性

先对迭代、增量有了个感性认识，我们再看一看为什么要用这样的模型。对于一个软件来说，很难做到一步到位，就像吃东西一样，要一口一口的吃，想要把整个东西吞下去就容易噎着。于是，就出现了分阶段进行开发的模型，逐步达到目标，迭代模型、增量模型就是这样的。他们的共同点是，通过若干个阶段的开发，完成整个软件，每阶段完成之后，都有一个新版本发布。这就有一个好处，相对于整个漫长的开发周期来说，每阶段都会见到亮光，有利于鼓舞团队的士气，降低项目的风险。

至于不同点，主要是阶段的划分上不太一样。增量模型是从功能量上来划分的，每阶段完成一定的功能。迭代模型是从深度或细化的程度来划分的，每阶段功能得到完善、增强。增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、不断变更的软件系统。

3. 边做边改模型

• 特点：
• 没有规格说明，没有经过设计，随着客户的需求不断修改
• 开发根据需求生成软件第一个版本，提供给用户使用，如果程序出现错误，或者用户提出新的需求，开发重新修改代码，直到用户满意为止
• 缺点：
  • 缺少规划和设计，忽略需求环节，风险很大
  • 没有考虑测试
  • 软件维护十分困难

4. 快速原型模型

（1）特点- 快速建立原型，客户对原型进行评价，进一步细化需求- 可以明确客户真正需求，开发出客户满意的软件- 克服瀑布模型（瀑布模型需求变更）的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果

• 不要求需求预先完备定义，支持用户参与， 支持需求的渐进式完善和确认，能够适应用户需求的变化**（2）适用范围**
• 需求复杂、难以确定、动态变化的软件系统

• 5. 敏捷开发模型

概念- 敏捷开发，是一种开发思想，有点类似迭代、增量开发思想。

• 核心理念体现出以人为本，快速迭代、循环渐进。

大白话- 就是把一个项目拆分多个子项目，各个子项目相互联系、可独立运行的项目。在此过程中软件是一直可运行的状态。

• 各个子项目的成果都要经过测试。

类型

• 极限编程(XP)
• Scrum

Scrum简介

• 把组织细分成小组、跨功能、自我组织团队。 跨功能团队指的就是前端、后端、测试、UI设计等团队
• 把工作细分成细小、实在的交付成果，交排人员负责需求清单以及根据重要性排优先级别，由团队估算每个项目相对工量。
• 把整个开发时间分成固定时长的短迭代（通常于一至四星期），在每个迭代后演示新增可发布功能。
• 优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
• 优化过程，在每个迭代之后进行回顾### 特点- 敏捷开发并不追求前期完美的设计、完美编码，目的是在很短的周期内开发出产品的核心功能
• 尽快的发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级、完善产品

例子

以微信为例

微信的需求功能，要求3年上线文字聊天
语音聊天
视频聊天
朋友圈
红包
小程序
公众号
第一次迭代先开发文字聊天、语音聊天。3个月上线。目的是先抢占用户量
第二次迭代开发视频聊天、朋友圈。2个月上线。目的是抢占用户量，吸引新的用户
第三次迭代开发红包、小程序、公众号。3月上线。

6. 螺旋模型

（1）特点​ 瀑布模型+快速原型模型+迭代模型。
（2）适用范围​ 需求难以获取和确定、软件开发风险较大的软件系统。

• 兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
• 整个开发过程是迭代和风险驱动。通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险。
• 4个阶段
  （1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
  （2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
  （3）实施工程：实施软件开发和验证；
  （4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

  螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等。因此这是和RUP提倡 的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作。
  

  • 迭代步骤 ​ 1.确定目标，可选项，以及强制条件。 ​ 2. 识别并化解风险。 ​ 3. 评估可选项。 ​ 4. 开发并测试当前阶段。 ​ 5. 规划下一阶段。 ​ 6. 确定进入下一阶段的方法步骤。
  • 常见问题
    | 经常遇到的问题 | 螺旋模型的解决方案 |
    | -------------------------------------- | --------------------------------- |
    | 用户需求不够充分 | 允许并鼓励用户反馈信息 |
    | 沟通不明 | 在项目早期就消除严重的曲解 |
    | 刚性的体系(Overwhelming architectures) | 开发首先关注重要的业务和问题 |
    | 主观臆断 | 通过测试和质量保证,作出客观的评估 |
    | 潜在的不一致 | 在项目早期就发现不一致问题 |
    | 糟糕的测试和质量保证 | 从第一次迭代就开始测试 |
    | 采用瀑布法开发 | 在早期就找出并关注风险 |
  • 优点
    1）设计上的灵活性,可以在项目的各个阶段进行变更。
    2）以小的分段来构建大型系统,使成本计算变得简单容易。
    3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
    4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
    5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
  • 缺点
    很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

产品测试模型

1. V模型

模型图

描述

由于瀑布模型对于软件的需求分析与设计阶段考虑不足，导致可能会出现严重的设计问题，最后交付到客户手里才会被发现，所以V模型就考虑到这点，针对开发的各个过程都会有相应的测试环节，比如用户需求会对应验收测试，需求分析和系统设计会对应确认测试和系统测试等等。但是缺点也是显而易见的，跟瀑布模型一样，测试过程还是放在了最后环节，虽然可以满足客户的需求，但是问题都只能到最后阶段才能被发现，必然会导致上面瀑布模型发生相同情况，也就是成本和时间的增加，所以V模型充其量也只能是瀑布模型的2.0版本。

缺点

• 系统测试
  ​ 一般通过手工测试，系统层次的测试，成品测试，看不到代码
• 测试过晚介入，放在了编码之后

特点可以指导测试人员的测试工作

2. W模型

模型图

描述

W模型是在V模型的基础上演变而来的，一般又称为双V模型。在V模型中，研发活动没有完成、无任何输出物时，测试工程师无法开展测试工作，相对而言，测试活动严重滞后。为了解决V模型的缺点，W模型提出了测试活动与研发活动并行的概念，并且在生产流程演进过程中，增加了验证与确认活动。W模型从用户需求开始，研发团队根据用户需求进行需求分析、概要设计、详细设计、编码开发等活动，测试团队则根据用户需求进行验收测试、系统测试、集成测试及单元测试设计。测试工作与研发活动分离，实现了并行操作。测试活动伴随着整个研发过程，而不仅在研发有成果输出后才参与。W模型强调了测试活动不仅仅包括研发活动所产生的软件源代码，还考虑各种文档，如需求文档、概要设计文档、详细设计文档、代码等。

特点

• W模型要求测试活动从用户需求阶段就介入，有利于尽早地发现问题- 在模型实施过程中，时刻进行确认（validation）、验证（verification）活动。

3. X模型

• 左边多个片段并行，进入右下方经过测试，返回右上方进行集成测试
• 不再接受变化（代码不再变化），版本定下来，封版

4. H模型# 六大测试类型

测试用例从每个类型上考虑2-3个用例

1. 功能性测试（Functionality）

关注点

• 关注功能是否正常（手工、自动化）

概念

• 根据产品的SRS和测试需求列表，验证产品的功能实现是否符合产品的需求规格

例子

• 常见关注点：

1. 是否有不正确或遗漏了的功能
2. 功能实现是否满足用户需求和系统设计的隐藏需求
3. 输入能否正确接受？能否正确输出结果？

• 音频转换通举例：

4. 使用音频通软件进行正常的格式转换
5. 点击“添加文件”按钮进行操作
6. 点击播放按钮进行文件播放

• 其他常见例子：

7. ATM机上取钱上不扣款
8. 输入不正确的日期格式也可以成功提交
9. WEB页面的一个超链接打不开
10. 手机上正在听音乐时来电不提示
11. 地铁公交卡刷卡后扣款不成功
12. 手机APP无法正常启动
13. 手机拨号后无法接通对方手机
14. 2012年广州出租车计价器无法识别2月29日

2. 易用性/可用性测试（Usability）

关注点

• 关注产品是否好用​ 用户学习、操作是否人性化、安装是否简单、使用是否舒适、界面是否友好。总之视为围绕用户体验角度考虑。

概念

• 根据ISO 9241-11的定义，可用性是指在特定环境下，产品为特定用户用于特定目的时所具有的有效性、效率和主观满意度。常见的可用性测试大多都是基于界面的测试，体现在易用、易懂、简捷、美观等方面。

例子

• 常见关注点：

1. 过分复杂的功能或指令
2. 困难的安装过程
3. 错误信息过于简单
4. 用户被迫去记住太多的信息
5. 语法、格式和定义不一致

• 音频转换通举例：

1. 每个按钮的文字描述是否准确，和实际功能是否符合

• 其他常见例子：

1. 手机上应用程序运行太慢
2. 删除一条数据时无二次确认
3. 页面布局很难看
4. 页面字体颜色太刺眼，字体太小
5. 网站经常出现弹窗广告
6. 手机上按钮设置在左上角
7. 网页上的超链接显示不明显
8. 苹果早期手机一直坚持屏幕小于4英寸今天我点名买了个B/S系统，听说只要有浏览器就能用。我最讨厌装客户端了，用浏览器就是方便啊。下面就是我使用这个系统碰到的麻烦事：1. 我登录失败的时候没有任何提示，这没什么，反正提示也只是说失败……
9. 进去后发现颜色变更很强烈刺得我一眨眼，不过多看几次就习惯了。
10. 点击某个链接的时候出现错误页面，刷新后就好了，难道是随机错误？
11. 保存文字的时候没有成功提示，不过能成功保存就算了。
12. 浏览记录的时候竟然出现错误页面，原来我没有选记录就浏览了，我自己操作不规范嘛。
13. 删除记录的时候发现选错了，想取消的时候却提示删除成功，都没有确认提示，只能下次看仔细点了。
14. 查询时字母键被茶杯压住了多输了点字符，竟然出现错误页面，下次把东西整理好。
15. 无聊随便点点几个链接，竟然没有反应，既然不用，那就不要做出来嘛。
16. 看看自己上传的图片效果如何，这个怎么不显示？多试几次发现名字不包含中文就好了，下次注意下。
17. 改改字体字号颜色美化环境嘛，怎么格式那里不显示正确的字体字号呢，将就用吧。
18. 这里的记录条数怎么这么多啊？原来是没有删除按钮，看来下次不能随便加了。
19. 这个结束时间怎么在开始时间前啊？原来没有进行控制，下面的人执行时……还是自己改过来吧。
20. 上次我在这里看见的图片呢？刷新后就出来了，怎么和我玩捉迷藏呢？
21. 多输了点内容，保存时候提示太多了，点确定后发现被清空了，我一个小时的工作啊！
22. 这张图片真不错，但是按钮呢，按钮呢？按钮被挤掉了我怎么编辑啊。
23. 听说F5是刷新点一下看看。怎么好像变成了登录界面？
24. 刚学了怎么用TAB键，确实很方便。TAB一下。跑哪去了，怎么一片空白啊？
25. 玩游戏的人点击速度那么快，我也来试试。怎么一双击就出错了？
26. 我找错别字是很厉害的，这不就发现“同意”写成了“统一”。
27. 这里提示只能输入1－100，我偏要输入9999……保存看看，怎么系统不能用了？
28. 这里一点击就出现IE错误，硬是不弹出我需要的窗口。
29. 这个查询按钮怎么灰掉了？这么多记录让我一页一页翻过去找啊。
30. 上传第二个附件的时候怎么把第一个挤掉了啊，会挤掉也要提示一下嘛。
31. 一个页面上打开的记录太多了，变体都用…省略了，要是鼠标放上去浮动显示完整标题就方便多了。
32. 这几条记录有依存关系，删了一条其他就没了，提示都没有，早知道我就用编辑了……
33. 这条记录怎么好像是昨天的，我记得今天更新了啊？原来编辑后的记录没有传到引用的地方。
34. 最最奇怪的是昨天上传时候正常的图片今天就不能显示了。我记得没有只能显示一天的功能啊？
35. 这里怎么没有任何按钮呢，看手册才知道竟然要用右键进行操作，怎么突然冒出个异类啊？
36. 这里怎么能增加两条相同的记录呢?不控制一下天知道手下那些愣头青会做出什么来。
37. 这里的菜单一层一层又一层，足足有五层，把我头都绕晕了……我记得哪里说过最好不要超过三层的。
38. 这个界面看起来怎么这么别扭啊，是字体太大了，是按钮太小了，还是功能太多了，……
39. 怎么不是管理员登录进来也能管理啊，那我这个管理员的身份不是多此一举吗？
40. 删除的时候提示Error，幸亏我英语水平好，可是你换成中文不行吗？
41. 这条记录不是删除了吗，怎么还能引用啊，到时候出错了怎么办，难道还要我记住删了那些记录？
42. 经过精心编辑，我发了一条通知，怎么用普通用户查看的时候是默认的字体字号啊？
43. 这几个页面上的当前日期怎么是固定不变的啊，这都是去年的日期了，不会是开发时候的吧。

3. 兼容性测试(Comepatibility)

关注点

• 关注产品是否适用于多种平台（使用环境、系统、硬件、分辨率等）
• 软件+硬件
• 操作系统：windows、Mac、Linux、Andriod、ios
• 软件+软件
• 浏览器：Chrome、Firefox、Edge、IE、Safari（苹果系统）
• 调用
• 不同版本之间兼容 APP

概念

• 主要是为了检查软件在不同的软\硬件平台上是否可以正常的运行的一种测试。

例子

• 常见关注点：

1. 兼容不同的OS
2. Web项目兼容不同的浏览器
3. 兼容不同的数据库
4. 兼容不同的分辨率
5. 兼容不同的厂家的硬件设备，耳机、音响等。

• 音频转换通举例：

1. 在windows7、Mac OS上进行音频转换测试

• 其他常见例子：

1. 中国的插座无法在欧美使用
2. 某网页IE和Firefox中显示效果不一样
3. 某App应用程序在某手机上无法安装
4. 针对手机，平板和电脑要单独开发三套界面
5. 在IE中可使用回车键，但是在Firefox上无法使用
6. 某游戏无法运行在IOS系统上
7. 某应用程序在Windows10上经常卡

4. 可靠性测试(Reliability)

关注点

• 关注产品是否稳定可靠 假如程序崩溃，用户未保存的输入是否可以保留

概念

• 为了达到或验证用户对软件的可靠性要求而对软件进行的测试。通过测试发现并纠正软件中的缺陷，提高其可靠性水平，并验证它是否达到了用户的可靠性要求。可靠性测试包含了软件的健壮、稳定、容错、自恢复等方面。

例子

• 常见关注点：

1. 输入异常的数据
2. 操作异常的文件
3. 长时间工作后保持正常
4. 多次打开应用程序
5. 音频转换通举例：
6. 长时间操作使用后音频通后是否会出错
7. 添加文件后，将其物理删除，再进行转换，音频通是否会出错- 其他常见例子：1. 手机使用时间太长容易死机
8. Android，IOS上的闪退
9. Windows上的蓝屏
10. 手机通话时失去信号后无法马上挂断
11. 手机恢复信号后通话无法继续
12. QQ文件传输不支持断点续传
13. 阿里巴巴杭州电缆被挖断时无法立即恢复

5. 安全性测试（Security）

关注点- 关注产品是否有漏洞

• 中间人攻击
• 是否对软件的使用者造成伤害和损失（账号、密码）

概念

• 为验证应用程序的安全等级和识别潜在安全性缺陷的过程。

例子

• 常见关注点：

1. SQL注入
2. 口令认证
3. 加解密技术
4. 权限管理
5. 安全日志

• 音频转换通举例：可以认为音频通软件不存在安全性问题，因为这是一个辅助性的软件任何人都能使用，且转换的音频和视频大多不涉及到严重的危害，所以我们可以不考虑这一点。
• 其他常见例子：

1. 我们经常接到骚扰电话
2. WIFI万能钥匙
3. 某支付宝账户的余额被恶意转走
4. CSDN网站用户600万数据泄漏
5. 手机上的联系人信息被窃取
6. 某网站首页被恶意篡改
7. 某网站被大量非法用户攻击

6. 性能测试(Performance)

关注点- 关注产品是否能够高效运行

• 基准、负载、压力、并发、稳定、容量测试
• peak峰值点测试

• 概念

• 用来测试软件在系统中的运行性能。负载、压力、容量测试等都属于这一范畴。

• 例子

• 常用工具：LoadRunner、WebLoad、jmeter等
• 常见关注点：

1. 系统资源，cpu、内存、io读写
2. 并发用户数
3. 最大数据量
4. 响应时间
5. 处理成功率
6. 音频转换通举例：
7. 批量转换或合并转换1000个10M的文件，耗时是否符合预期
8. 对超大的文件进行转换

• 其他常见例子：

1. 网页半天打不开，反应很慢
2. 应用程序运行太久占用内存很大
3. 2008年北京奥运会门票系统崩溃
4. 2012年伦敦奥运会门票系统崩溃
5. 12306网站春运期间购票难
6. Android手机运行不流畅，经常卡顿

7.界面测试

• 功能模块布局是否合理
• 操作是否友好
• 风格是否和预期一样
• 文字是否有错别字
• 图片是否结合完美
• 页面是否美观

软件质量模型

1.概念

• 关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有 McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO系列模型。ISO系列模型又包括常见的ISO/IEC 9126以及ISO/IEC 25010：2011。
• 一个完整的软件质量模型，包括从产品角度出发的内部、外部质量模型；以及从用户角度出发的使用质量模型。

2.ISO/IEC 91266大特性及27个子特性

功能性软件产品提供明确、隐含要求的能力

1. 适合性。
软件产品为指定的任务和用户提供一组合适的功能的能力（投入运行后，功能是否合适、正确、完整等）
2. 准确性。
软件产品提供具有所需精度的正确或相符的结果或效果的能力（实际与预期的差别）。
3.互操作性。
软件产品与一个或更多的规定系统进行交互的能力（如果与其它软件有定义接口，数据传输的正确程度）。
4.安全保密性。
软件产品保护信息和数据的能力，使未授权的人不能阅读或修改这些信息和数据，而不拒绝授权人员阅读或修改这些信息和数据(访问的可审核性（正常、病毒）、可控制性）。
5.功能性的依从性。
软件产品遵循与功能性相关的标准、约定或法规及类似规定的能力（非法）。

可靠性在指定条件下使用时，软件产品维持规定的性能级别的能力

1. 成熟性。
软件产品为避免由软件内部的故障而导致失效的能力（潜在的故障密度、失效的测试用例数量、故障排除）。
2. 容错性。
在软件出现故障或者违反其指定接口的情况下，软件产品维持规定的性能级别的能力。
3.易恢复性。
在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力（重启能力、重启时间）。
4.可靠性的依从性。
软件产品遵循与可靠性相关的标准、约定或法规的能力（非法）。

易用性在指定条件下使用时，软件产品被理解、学习、使用和在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力

1.易理解性。
软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用条件的能力（文档、功能的初始印象）。
2.易学性。
软件产品使用户能学会其应用的能力（使用者学习满足需求的能力）。
3.易操作性。
软件产品使用户能操作和控制它的能力。
4.吸引性。
软件产品吸引用户的能力。
5.易用性的依从性。
软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力（非法）。

效率在规定条件下，相对于所用资源的数量，软件产品可提在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力

1.时间特性。
在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力（如响应时间）。
2.资源利用性。
在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力（如内存占用）。
3.效率依从性。
软件产品遵循与效率相关的标准或约定的能力（非法）。

可维护性软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应

1.易分析性。
软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
2.易改变性。
软件产品使指定的修改可以被实现的能力（变更难易的程度）。
3.稳定性。
软件产品避免由于软件修改而造成意外结果的能力（由于软件修改而造成的意外）。
4.易测试性。
软件产品修改能被确认的能力。
5.维护性的依从性。
软件产品遵循与维护性相关的标准或约定的能力（非法）。

可移植性软件产品从一种环境迁移到另一种环境的能力

1.适应性。
软件产品毋需采用额外的活动或手段就可适应不同指定环境的能力（屏幕大小）。
2.易安装性。
软件产品在指定环境中被安装的能力（用户在指定环境中被安装的能力，与易操作性互相影响）。
3.共存性。
软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力（共享资源的其它软件）。
4.易替换性。
软件产品在同样环境下，替代另一个相同用途的软件产品的能力（版本迭代、新旧兼容）。
5.可移植性的依从性。
软件产品遵循与可移植性相关的标准或约定的能力（非法）。

3.软件使用质量模型4大特性

使用质量模型是基于用户观点的软件产品用于指定的环境和使用周境时的质量。它测量用户在特定环境中能达到其目标的程度，而不是测量软件自身的属性。基本的软件使用质量模型包括4大特性，如下图：

4.理解特性的定义

功能性

可靠性、易用性

效率、可维护性、可移植性

5.输入法产品实例

当你知道在测试过程中需要关注哪些特性了后，肯定心里面有个疑问，那么接下来，我要怎么做，怎么去进行测试呢 ?其实这个问题，出于对产品不同角度考量，使用软件质量模型的方式也有所不同：如果你只是应用于产品测试，那么就可以围绕着这些度量点进行展开，根据产品的特性设计测试用例，验证具体实现与预期的差别。如果你作为一名项目的有效推动者，想要在项目的生存周期内系统化的评价产品，版本间比较发现问题，那么你可以自定义适合自己产品的内部质量模型，或者通过外部属性定义外部质量模型，或者通过测量使用质量的属性来评价。目标就是使产品在指定的使用周境下具有所需的效用并且效果符合预期。
结合输入法内核的产品特性，输入法内核测试小组对质量模型的一些特性进行筛选，目前正在使用的输入法质量模型的评价方式如下图：

本文标签： 基础理论模型测试产品软件