Let's continue reading the book notes section of the second part of the
The second part of Software Testing
It includes case design Chapter 4; Chapter 5 units (modules) tests; Chapter 6 higher level test
Chapter 6 higher level of testing (including Chapter 7 usability testing)
1. Why should a higher level of testing?
What is the answer higher-level test before, needs to know the software product development cycle model, it can be summarized in seven steps:
1. Requirements: conversion of a series written by the end user needs
2. Objectives: to assess the feasibility and cost the same user, the user needs to convert a specific goal
3. Product Specifications: Convert to a target end users can interact with the product specifications
4. System Design: The design of the system specification, and the system is divided into separate procedures, components or subsystems.
The program structure Design: function definition module, and a module interface module hierarchy, design of program structure
6. Module Interface Specification: design specification, defines interfaces and functions of each module
7. Code: the module interface specifications converted to the source code module
Between more than seven steps include communication, understanding and conversion information, if the information communication and conversion between the two steps of errors and bias, the program will appear in the software error. In order to reduce errors that occur when such information communication and conversion, requires a different test method (higher level test) at different stages of the development cycle, to avoid inconsistencies in the communication and information transformation.
Different test methods employed in the development phase, comprising: a module test, integration testing, functional testing, system testing, acceptance testing, installation testing and usability testing.
2, higher levels of testing including what?
2.1 Functional Test
Objective: inconsistency between the discovery process of the program and its external specifications.
Black-box testing, need to be analyzed during functional testing to refine the specification of test cases. , Boundary value analysis, error guessing Gonggeng test method by equivalence partitioning method.
2.2 System Test
Objective: The system or program compares its initial target, the process of looking for inconsistencies between the program and its target. (1. System testing is not limited to the system, the program as a whole does not meet its objectives is how the process; 2. products are not written goals, system testing can not be performed)
| classification | Explanation |
| Ability test | Ensure that the program functions to achieve the goal (the ability to target document mentioned) |
| Capacity Test | Procedures to handle large volumes of data anomalies found |
| 强度测试 | 发现在大规模负载、高强度不间断持续的数据处理中的异常（短时间内达到的数量峰值） |
| 可用性测试 | 评估最终用户在使用软件并与软件交互时的可用性问题 |
| 安全性测试 | 试图攻破程序的安全防线 |
| 性能测试 | 评估程序的响应时间以及吞吐量瓶颈 |
| 存储测试 | 确保程序可以正确处理其对存储的要求，包括系统的存储和物理上的存储 |
| 配置测试 | 检擦程序是否能在推荐配置上流畅运行 |
| 兼容性/转换测试 | 评估新版本是否兼容老的版本 |
| 安装测试 | 确保能够在所有支持的平台上安装软件 |
| 可靠性测试 | 评估程序是否能达到规格说明中的运行时长和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