产品开发模型

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

2. 增量迭代模型

（1）增量

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

3. 边做边改模型

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

4. 快速原型模型

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

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

• 5. 敏捷开发模型

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

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

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

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

类型

• 极限编程(XP)
• Scrum

Scrum简介

• 优化发布以及跟客户一起更新优先级别，基于每个迭代后发布的观察。
• 优化过程，在每个迭代之后进行回顾### 特点- 敏捷开发并不追求前期完美的设计、完美编码，目的是在很短的周期内开发出产品的核心功能
• 尽快的发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级、完善产品

例子

以微信为例

6. 螺旋模型

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

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

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

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

1. 功能性测试（Functionality）

关注点

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

概念

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

例子

• 常见关注点：

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

• 音频转换通举例：

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. 点击某个链接的时候出现错误页面，刷新后就好了，难道是随机错误li>
11. 保存文字的时候没有成功提示，不过能成功保存就算了。
12. 浏览记录的时候竟然出现错误页面，原来我没有选记录就浏览了，我自己操作不规范嘛。
13. 删除记录的时候发现选错了，想取消的时候却提示删除成功，都没有确认提示，只能下次看仔细点了。
14. 查询时字母键被茶杯压住了多输了点字符，竟然出现错误页面，下次把东西整理好。
15. 无聊随便点点几个链接，竟然没有反应，既然不用，那就不要做出来嘛。
16. 看看自己上传的图片效果如何，这个怎么不显示几次发现名字不包含中文就好了，下次注意下。
17. 改改字体字 颜色美化环境嘛，怎么格式那里不显示正确的字体字 呢，将就用吧。
18. 这里的记录条数怎么这么多啊是没有删除按钮，看来下次不能随便加了。
19. 这个结束时间怎么在开始时间前啊没有进行控制，下面的人执行时……还是自己改过来吧。
20. 上次我在这里看见的图片呢后就出来了，怎么和我玩捉迷藏呢li>
21. 多输了点内容，保存时候提示太多了，点确定后发现被清空了，我一个小时的工作啊！
22. 听说F5是刷新点一下看看。怎么好像变成了登录界面li>
23. 刚学了怎么用TAB键，确实很方便。TAB一下。跑哪去了，怎么一片空白啊li>
24. 玩游戏的人点击速度那么快，我也来试试。怎么一双击就出错了li>
25. 我找错别字是很厉害的，这不就发现“同意”写成了“统一”。
26. 这里提示只能输入1－100，我偏要输入9999……保存看看，怎么系统不能用了li>
27. 这里一点击就出现IE错误，硬是不弹出我需要的窗口。
28. 这个查询按钮怎么灰掉了多记录让我一页一页翻过去找啊。
29. 上传第二个附件的时候怎么把第一个挤掉了啊，会挤掉也要提示一下嘛。
30. 一个页面上打开的记录太多了，变体都用…省略了，要是鼠标放上去浮动显示完整标题就方便多了。
31. 最最奇怪的是昨天上传时候正常的图片今天就不能显示了。我记得没有只能显示一天的功能啊li>
32. 这里怎么没有任何按钮呢，看手册才知道竟然要用右键进行操作，怎么突然冒出个异类啊li>
33. 这里怎么能增加两条相同的记录呢制一下天知道手下那些愣头青会做出什么来。
34. 这里的菜单一层一层又一层，足足有五层，把我头都绕晕了……我记得哪里说过最好不要超过三层的。
35. 这个界面看起来怎么这么别扭啊，是字体太大了，是按钮太小了，还是功能太多了，……
36. 怎么不是管理员登录进来也能管理啊，那我这个管理员的身份不是多此一举吗li>
37. 删除的时候提示Error，幸亏我英语水平好，可是你换成中文不行吗li>
38. 这条记录不是删除了吗，怎么还能引用啊，到时候出错了怎么办，难道还要我记住删了那些记录li>
39. 这几个页面上的当前日期怎么是固定不变的啊，这都是去年的日期了，不会是开发时候的吧。

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。

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

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

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.输入法产品实例

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