《软件测试的艺术》读书笔记二

这次的笔记是继前几天《软件测试的艺术》读书笔记的后续了,也不知道能不能坚持吧《软件测试艺术》这本书的笔记都写完,上一次的《软件测试》第二版的笔记就在半途夭折了!

好了闲话不说了。

测试用例的设计

  • 由于时间和成本的约束,软件测试的最关键问题是:在所有可能的测试用例中,哪个子集最有可能发现最多的错误?
  • 黑盒测试:等价类划分、边界值分析、因果图分析、错误猜测
  • 白盒测试:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖

单元测试

模块测试(或单元测试)是对程序中的单个子程序、子程序或过程进行测试的过程,也就是说,一开始并不是对整个程序进行测试,而是首先将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个。

  1. 首先,由于模块测试的注意力一开始集中在程序的较小单元上,因此它是一种管理组合的测试元素的手段。
  2. 其次,模块测试减轻了调试(准确定位并纠正某个已知错误的过程)的难度,这是因为一旦某个错误被发现出来,我们就知道它在哪个具体的模块中。
  3. 模块测试通过为我们提供同时测试多个模块的可能,将并行工程引入软件测试中。

模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。这里的测试目标不是为了说明模块符合其规格说明,而是为了揭示出模块与其规格说明存在着矛盾。

高级别的测试

  • 功能测试:试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。
  • 系 统测试:最容易被错误理解,也是最困难的测试过程。系统测试并非是测试整个系统或程序功能的过程,因为有了功能测试,这样会显得多余。系统测试有着特定的 目的“将系统与其初始目标进行比较”。给定这个目标之后,隐含两方面的含义:(1)系统测试并不局限于系统。如果产品是一个程序,那么系统测试就是一个试 图说明程序作为一个整体式如何不满足其目标的过程;(2)根据定义,如果产品没有一组书面的、可度量的目标,系统测试也就无法进行。
    设计测试用例时应考虑全部的15种类型:

    1. 能力测试(facility testing):判断目标文档提及的每一项能力是否都确实已经实现。
    2. 容量测试:使程序经受大容量数据的检验。
    3. 强度测试:使程序承受高负载或强度的检验,高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。
    4. 易用性测试:系统测试的另一个重要类型是试图发现人为因素或易用性的问题。
    5. 安全性测试:设计测试用例来突破程序安全检查的过程。
    6. 性能测试:很多软件都有特定的性能或效率目标,描述为在特定负载或配置环境下程序的响应时间和吞吐率。应设计测试用例来说明程序不能满足其性能目标。
    7. 存储测试:证明软件的存储目标没有得到满足。
    8. 配置测试:多种硬件配置或可运行的多种操作系统等。
    9. 兼容性/配置/转换测试:与现有系统的兼容以及从现有系统的转换过程。
    10. 安装测试:测试安装过程。
    11. 可靠性测试:所有类型的测试都是为了提高软件的可靠性,但如果软件的目标中包含了对可靠性的特别描述,就必须设计专门的可靠性测试。可能会有关于“平均故障间隔时间(MTBF)”的目标。
    12. 可恢复性测试:系统如何从程序错误、硬件失效和数据错误中恢复过来的机制。
    13. 适用性测试:适用性或可维护性的目标,可能定义了系统提供的服务辅助功能。
    14. 文档测试:系统测试也需要检查用户文档的正确性。
    15. 过程测试:很多软件都是较大系统的组成部分,这些系统并不完全是自动化的,包含了很多人员操作过程。在系统测试中,必须对所有已规定的人工过程进行测试。
  • 验收测试:将程序与其最初的需求及最终用户当前的需求进行比较的过程。通常是由程序的客户或最终用户来进行,一般不认为是软件开发机构的职责。
  • 安装测试:目的的是为了发现在安装过程中出现的错误。应由生产软件系统的机构来设计,作为软件的一部分来发布,在系统安装完成之后进行。
  • 测试的计划与控制:一个良好的测试计划应该包括“目标、结束准则、进度、责任、测试用例库及标准、工具、计算机时间、硬件配置、集成、跟踪步骤、调试步骤、回归测试”。

《《软件测试的艺术》读书笔记二》有0个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注