のは、第二の部分のブックノートセクションを読み続けましょう
ソフトウェアテストの第二部
第5章単位（モジュール）テスト;第6章、より高いレベルの試験には、ケースの設計第4章を含みます
（第7章ユーザビリティテストを含む）試験の第6章より高いレベル
1.なぜテストのより高いレベルの必要がありますか？
答えは、より高いレベルのテストを前に、ソフトウェア製品開発サイクルのモデルを知っている必要がありますどのようなものです、それは7つのステップに要約することができます。
1.要件：エンドユーザーのニーズによって書かれた一連の変換
2.目的：実現可能性を評価し、同じユーザーをコストのために、ユーザは、特定の目標を変換する必要があります
3.製品仕様：対象のエンドユーザーへの変換は、製品の仕様と対話することができます
4.システム設計：システム仕様の設計、及びシステムは、別個の手順、構成要素またはサブシステムに分割されています。
プログラムの構造設計：関数定義モジュール、およびモジュールインタフェースモジュールの階層、プログラム構造の設計
6.モジュールインタフェース仕様：設計仕様は、各モジュールのインターフェイスおよび機能を定義します
7.コード：ソースコード・モジュールに変換モジュールインタフェース仕様
以上の7つのステップコミュニケーション、理解と変換情報が含まの間、エラーやバイアスの2つの段階の間での情報通信と変換すれば、プログラムは、ソフトウェア・エラーに表示されます。このような情報通信および変換に発生するエラーを低減するために、通信及び情報変換で不整合を回避するために、開発サイクルの異なる段階で異なる試験方法（より高いレベルの試験）を必要とします。
含む開発段階において採用異なる試験方法：モジュールテスト、統合テスト、機能テスト、システムテスト、受け入れテスト、インストールテストとユーザビリティテスト。
何を含むテストの2、より高いレベル？
2.1機能テスト
目的：プログラムとその外部仕様の発見プロセスの間に矛盾。
ブラックボックステストは、テスト・ケースの仕様を洗練する機能テスト中に分析する必要があります。、境界値分析、エラー同値分割法によりGonggeng試験方法を推測します。
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