下面继续本书第二部分的读书笔记部分
第二部分 软件测试基础
包括第4章 测试用例设计；第5章 单元（模块）测试；第6章 更高级别的测试
第6章 更高级别的测试（包括第7章 可用性测试）
1、为什么要进行更高级别的测试？
回答更高级别测试是什么之前，需要知道软件产品开发周期模型，可以归纳为7个步骤：
1.需求：由最终用户转换的一系列书面的需求
2.目标：通过同用户评估可行性和成本，将用户需求转换为具体的目标
3.产品规格说明：将目标转换为一个可以与最终用户交互的产品规格说明
4.系统设计：将规格说明进行系统设计，并将系统分割为单独的程序、部件或子系统。
5.程序结构设计：定义模块功能，模块层次结构及模块间接口，对程序结构进行设计
6.模块接口规格说明：设计规格说明，定义每个模块的接口和功能
7.代码：将模块接口规格说明转换为模块的源码
以上7个步骤之间，都包括信息的沟通、理解和转换，如果两个步骤之间的信息沟通和转换发生错误和偏差，程序中都会出现软件错误。而为了减少这种信息沟通和转换时发生的错误，需要在开发周期的不同阶段采用不同的测试方法（更高级别的测试），避免沟通和信息转换的不一致现象的发生。
在这些开发阶段采用的不同的测试方法，包括：模块测试、集成测试、功能测试、系统测试、验收测试、安装测试和可用性测试等。
2、更高级别的测试包括什么？
2.1 功能测试
目的：发现程序与其外部规格说明之间存在不一致的过程。
功能测试时黑盒测试，需要对规格说明进行分析以提炼测试用例。可以通过等价类划分方法、边界值分析方法、错误猜测方法进行躬耕测试。
2.2 系统测试
目的：将系统或程序与其初始目标进行比较，寻找程序与其目标之间的不一致的过程。（1.系统测试不局限于系统，程序作为一个整体是如何不满足其目标过程；2.产品没有书面的目标，系统测试无法进行）
| 分类 | 说明 |
| 能力测试 | 确保程序的目标功能实现（目标文档提及的能力） |
| 容量测试 | 发现处理大容量数据时的程序异常 |
| 强度测试 | 发现在大规模负载、高强度不间断持续的数据处理中的异常（短时间内达到的数量峰值） |
| 可用性测试 | 评估最终用户在使用软件并与软件交互时的可用性问题 |
| 安全性测试 | 试图攻破程序的安全防线 |
| 性能测试 | 评估程序的响应时间以及吞吐量瓶颈 |
| 存储测试 | 确保程序可以正确处理其对存储的要求，包括系统的存储和物理上的存储 |
| 配置测试 | 检擦程序是否能在推荐配置上流畅运行 |
| 兼容性/转换测试 | 评估新版本是否兼容老的版本 |
| 安装测试 | 确保能够在所有支持的平台上安装软件 |
| 可靠性测试 | 评估程序是否能达到规格说明中的运行时长和MTBF（平均故障间隔时间）要求 |
| 可恢复性测试 | 测试系统恢复相关的功能是否按设计要求实现（系统如何从程序错误、硬件失效和数据错误中恢复过来） |
| 服务/可维护性测试 | 评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需 |
| 文档测试 | 校验所有的用户文档是否准确 |
| 过程测试 | 对软件系统操作或维护所涉及的流程进行评估和确定 |
2.3 验收测试
目的：设计测试用例，证明程序没有满足合同要求。
由程序的客户或最终用户进行测试。
2.4 安装测试
目的：发现安装过程中出现的错误。
2.5 独立的测试机构
目的：开发程序机构难以客观地测试同一程序，需要雇佣第三方的软件公司进行软件测试。
2.7 可用性（或用户体验）测试
1）为什么要进行可用性测试？
1.因为越来越多的基于用户界面的程序的出现
2.在用户体验上花费时间和费用可以换来更好的市场和经济回报
如果由于软件设计不够优美、交互界面繁琐难用、规格缺失或被忽视的原因，导致用户感觉很差，基本已经宣告项目开发失败。下面列出了一些可用性测试的测试灵感。
| 序号 | 测试要素 |
| 1 | 交互设计是否考虑到用户理解力、教育背景及环境压力 |
| 2 | 程序输出是否有意义，意义是否模糊不清，没有侮辱性词语， |
| 3 | 程序错误提示是否直白易懂 |
| 4 | 系统是否包含太多选项，这些选项是否会被用到，是否符合人的思维逻辑和直觉 |
| 5 | 来自用户的输入，系统是否能及时做出反应 |
| 6 | 程序操作是否容易上手 |
| 7 | 用户操作是否可以重复进行 |
| 8 | 菜单来回切换是否会发生意外 |
| 9 | 软件功能是否达到设计规格要求 |
2）怎么进行可用性测试？
可用性测试之前需要进行周密计划，保证测试完整性。首先，根据软件的使用场景设计，设计不同的操作场景；然后，根据不同的场景，应为用户提供详细的操作说明，方便用户进行测试；接着，在测试过程中，应记录每一步的用户体验；最后，测试完成后，应和当事人进行沟通。在可用性测试用例设计方面，有几个方面需要着重考虑。
- 测试用户的选择
可用性设计方案需要一组用户或不同组用户完成多个测试。为什么呢？不同水平的用户对完成软件操作的时间不同，所以需要找不同水平的用户进行测试。对于特定行业软件需要找经验丰富专家进行测试；而对于使用范围较广的软件，应随机选择测试用户。
- 需要多少用户进行测试
进行可用性测试之前，需要考虑所需的测试人员。Nielsen研究发现，测试中可用性测试人员数量可用数学公式：
E=100x(1-(1-L)^n)
其中：
E=找到错误的比例
n=测试人数
L=单个测试人员发现的可用性问题比例
如果L=31%，得出如下的趋势图，纵轴代表错误发现比例，横轴代表测试人数。5个人可以发现83%的错误，这种发现错误的比例其实不是很准确，这只是基于经济因素进行考虑的；如果对安全性有要求的系统需要更多的测试用户。
- 数据采集的方法
1）录制用户的测试过程，并让用户发表感受，并在测试完成后找到用户进行沟通
2）远程用户测试，将软件产品安装在远端真实模拟环境测试（开发可通过第三方工具记录测试时间和操作流程）
3）“眼球追踪”，记录测试人员在什么视觉元素上暂停时间长，由此确定有效的外观
- 可用性调查问卷
测试完成后，需要设计可用性的调查问卷，通过调查问卷可以引导用户发表一些自己的看法，开发人员可以根据这些用户看法或建议，了解软件优化方向。
三种形式的问题：
1）是/否问题
2）真/假问题
3）某种程度的同意/反对
- 何时结束可用性测试
可用性测试如何设计才能在合理预算内达到全面测试的效果？具体问题具体分析，视被测系统或部件的复杂度而定。在预算和时间充裕的情况下，根据开发进度分阶段进行测试（迭代测试）。
1）不多的测试人员已经能发现很多可用性测试问题，可以结束，让开发人员设计交互界面；
2）测试人员对分配的测试任务执行起来很流畅，没发现任何错误或故障。两种可能：a) 测试范围太小；b) 测试人员只是在验证规格书中的功能项，即程序做了“其应该做的”，对于测试的另一半“做了其不应该做的”，需要做更多测试；
3）对测试人员的测试结果应仔细分析和总结，看看是否到达测试要求，如果不行，则还需要进行更多的测试；
参考文献：
[1].函数图像绘制工具.https://zh.numberempire.com/graphingcalculator.php