《软件测试》（Rom Patton）读书笔记：什么是软件测试？

Administrator #工作 #编程

一、软件测试综述

左边是原文，右边是个人理解

a.软件测试的背景

软件缺陷的定义：

  • 软件未实现产品说明书要求的功能

  • 软件出现了产品说明书指明不应该出现的错误

  • 软件实现了产品说明书未提到的功能

  • 软件未实现产品说明书虽未明确提及但应该实现的目标

  • 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好

  • 可以说是核心定义，软件若未完成基本功能，后面发现再多的bug也是一样的结果

  • 一份好的产品文档会明确好边界值的

  • 一个新功能的出现往往意味着多一份出现新bug的风险

  • 自家项目产品可以去参考现有市场上相对成熟同类型产品的功能

  • 简单理解就是用户体验

软件测试的目标：

软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复

测试工程师的目标是在有限时间内确保软件质量符合预期结果

b.软件开发的过程

软件开发生命周期模式：

  • 大瀑布模式

  • 边写边改模式

  • 瀑布模式

  • 螺旋模式

  • 简单，仅有开发软件和编写代码的过程，但测试工程师尽量避开这种模式下的测试，容易吵架

  • 项目初期只有粗略的想法，接着进行简单设计，然后来回编写、测试、修改缺陷的漫长过程直到产品发布

  • 过程是线性的，每个步骤独立，且无法回溯，一步接着一步进行

  • 从小开始，定义重要功能，努力实现功能，接受用户反馈，然后进入下一阶段，重复上述过程，直至得到最终产品

敏捷软件开发是一种思想/价值观，不是技术

传统模式（如瀑布）（左）与敏捷模式（右）的区别

  • 抵抗变化，前期把需求定死，导致后期改动成本变高

  • 交付方式是马拉松式的，憋到最后一次性交付，产品的风险变高了

  • 用户参与度仅在两头参与，开始的需求讨论，结尾的验收，中间过程是一个黑盒

  • 重视文档，即“文档就是产品”

  • 拥抱变化，假设市场、需求会变化，设计出低成本应对变化的流程

  • 交付方式是接力赛式的，可工作的产品版本，给出去的版本可能功能不全，但是是经过测试，可以使用的版本

  • 用户参与度是全程参与的，产品负责人每天和开发团队一起，随时确认细节，每轮版本迭代当场验收成果

  • 重视沟通，虽然有文档，但是更推崇可以工作的软件胜过详尽的文档，团队更多的是面对面沟通，把更多精力用于写代码和让软件跑起来

c.软件测试的实质

软件测试的原则

  1. 完全测试程序是不可能的，例如：计算器软件1+1、1+2······

  2. 软件测试是有风险的行为。每个软件项目都有一个最优的测试量

  3. 测试无法显示潜伏的软件缺陷，任何情况下都不能保证缺陷没有了，唯一的办法是继续测试，可能还会找到一些

  4. 找到的软件缺陷越多，就说明软件缺陷越多，原因有很多，l例如：程序员那天心情不好、程序员的习惯错误、软件设计出现了基本问题······

  5. 软件测试越多，软件对测试的免疫力越强。反复使用相同的方式测试软件，最后软件具有抵抗力了

  6. 并非所有的软件缺陷都要修复，原因有几个：没有足够的时间、不算真正的软件缺陷、修复的风险大、不值得修复

  7. 当遇到难以说清的缺陷，应该回顾下上面的缺陷定义规则，有时候会出现一种情况，就是A觉得是缺陷，B觉得不是缺陷，彼此各抒己见

  8. 产品说明书从来没有最终版本，在软件迎合市场的环境下，需求文档可能时刻都在变化，软件测试员编写的测试用例也是可能需要不断做调整的

  9. 基于测试的工作目标，可以推测一下，软件测试员在产品小组中可能是不受欢迎的，毕竟是挑刺。所以找到保持跟项目小组和睦相处的方式也是很重要的：尽可能早点找出缺陷、控制情绪、不要总是报告坏消息

  10. 软件测试是一个讲究条理的技术职业。随着时代发展，软件测试成为了一个职业选择——需要训练和规范，而且有发展空间

  1. 测试条件重复性高的、无必要的测试用例可以剔除，采用不完全测试

  2. 测试工程师在合理且有限时间里面有效地控制测试量（最优测试量），等于也是在控制风险

  3. 优秀的测试工程师是细心的并且没法保证软件是零缺陷的，只能说是尽可能多找到缺陷

  4. 有时是这样的，软件测试过程中很长时间没找到缺陷，突然找到一个后，很快接二连三地找到更多缺陷了

  5. 身为测试工程师，针对新一轮测试，尽可能地编写不同的测试用例，对软件的不同部分进行测试，以便更容易找出软件测试。亦或者，负责A模块的测试和负责B模块的测试，可以交换本身的模块进行测试，有利于缺陷的发现

  6. 有时候测试时间被缩短，一些缺陷可能就没办法第一时间修复；需求理解错误被定义的缺陷就不需要修复了；修复风险大的缺陷导致其他软件缺陷出现，倘若在紧凑的产品发布进度下，只能选择暂不修复了；不容易出现的缺陷亦或者复现步骤繁琐的缺陷有时候是直接放过的

  7. 遇到这种情况，一般是请教直系领导的意见最稳妥了

  8. 根据项目情况灵活制定测试计划也是很重要的

  9. 早点找到缺陷，有利于问题的影响程度变小，容易让人接受；发现难以发现的大缺陷的时候控制好情绪，别兴冲冲地找开发聊天，他大概是不会高兴的；如果测试确认基本功能没问题时，可以跟开发聊聊天解解闷，毕竟工作并不是生活的全部，别只有发现缺陷才跟开发聊天，那样人家对你就会唯恐避之不及

  10. 随着时代发展，就拿目前最火的AI来说，AI也是依赖软件基础设施的，一名优秀的软件测试工程师，对于好企业来说也是香饽饽的人才

软件测试的术语与定义

  • 精确（precision）和准确（accuracy）

精确是指正确性；准确是指稳定性

example-1.png
精确与准确的例子

  • 确认（verification）和验证（validation）

确认是保证软件符合产品说明书的过程；验证是保证软件满足用户需求的过程

example-2.png
确认与验证的区别

  • 质量（quality）和可靠性（reliability）

可靠性仅仅是质量的一个方面

摘抄原文：

软件使用者心目中的质量可能包括：软件功能的多少、在自己的PC上运行的能力、软件公司的服务电话好不好以及软件的价格。

至于产品的可靠性或者产品多长时间崩溃的问题也许重要，但常常不被考虑到。

  • 测试（testing）和质量保证（QA）

软件测试员的目标是尽可能地找到软件缺陷，并确保缺陷得以修复

软件质量保证人员的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法

二、测试基础

a.检查产品说明书

（1）开始测试

  • 黑盒测试（black-box test）和白盒测试（white-box test）

  • 静态测试（static test）和动态测试（dynamic test）

    • 静态测试是指测试不运行的部分——只是检查和审核

    • 动态测试是指通常意义上的测试——使用和运行软件

  • 静态黑盒测试——测试产品说明书

    • 个人看法：静态黑盒测试确实可以结合AI使用，一般来说项目不小的情况下，测试人员基本是一个人负责某模块的测试，让AI检查下对应模块功能的产品文档是否存在缺陷，若没有的话，自己手动检查一遍，这样测试起来会更有保障

    • 倘若项目没有产品需求文档的话，也会有人知晓产品是什么样的，对于这种情况下，测试人员可以先收集好产品信息，反复斟酌得到更多细节，编写和完善好自己的测试用例，在准备测试前可以给开发人员看下测试用例，先不管他看不看，如果看了的话，这样有助于开发在测试期间提前发现产品不足补充细节

（2）对产品说明书进行高级审查

  • 假设自己是客户，毕竟产品的最终目标就是满足客户需求

    • 当第一次拿到需求文档，可以假设自己是产品的目标客户。自己研究一下客户会是什么人；和市场人员或者销售人员聊聊天，了解他们对最终用户的认识；如果产品是内部使用的软件项目，可以找到使用它的人谈一下

    • 了解用户所想很重要，质量的定义是满足客户要求

  • 研究现有的标准和规范，测试人员要做的是检查文档采用的标准是否正确，是否遗漏

    • 公司惯用语和约定

    • 行业要求

    • 政府标准

    • 图形用户界面（GUI）

    • 安全标准

  • 审查和测试类似软件

    • 了解软件最终结果的最佳方法就是研究类似软件，但软件通常不会完全一样

（3）产品说明书的低层次测试技术

  • 产品说明书属性检查清单

    • 完整

    • 准确

    • 精确、不含糊、清晰

    • 一致

    • 贴切

    • 合理

    • 代码无关

    • 可测试性

  • 产品说明书用语检查清单

    • 总是、每一种、所有、没有、从不

    • 当然、因此、明显、显然、必然

    • 某些、有时、常常、通常、惯常、经常、大多、几乎

    • 等等、诸如此类、以此类推、例如

    • 良好、迅速、廉价、高效、小、稳定

    • 处理、进行、拒绝、跳过、排除

    • 如果······那么······（没有否则）

评论