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

时间:2019-08-10
本文章向大家介绍软件测试的艺术(读书笔记4),主要包括软件测试的艺术(读书笔记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