软件测试的艺术(读书笔记4)

下面继续本书第二部分的读书笔记部分

第二部分 软件测试基础

　　包括第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

　　

　　

转载于:https://www.cnblogs.com/chengabc/p/11297967.html