下面继续本书第二部分的读书笔记部分
第二部分 软件测试基础
包括第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