关于软件测试的所思所想（更新：2021-10-21）

软件测试定义

所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。
从软件测试定义看，开发、测试人员的角度就很有意思：
开发人员的角度：专注于完成程序该完成的，也就是专注于功能实现；
测试人员的角度：更应该关注程序是否执行了不该有的操作，其次才是程序完成了其应该完成的。

所以，自动化测试的弊端就显而易见：其预置的静态预期结果以及程式化的检测过程，决定了其无法有效覆盖"程序是否做了不改做的"。

软件测试有两种境界

• 尽可能发现bug，做初步分析后提交给开发修改；
• 软件测试的真正价值并不体现在代码中发现多少Bug，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。

软件的特性

软件工业和毒品交易都把他的顾客称为“用户”，而不是客户，因为软件和毒品一样都能让使用它的人上瘾，当用户习惯一种使用习惯后，让他改变操作方式是一种非常难得事情，好比Apple提供的高品质体验，当我们习惯它之后我们再也不会习惯andriod。故，你无法塑造用户习惯，则要依从他的使用习惯。这里体现了软件易用性测试。

《探索式软件测试》笔记与心得

• 大多数伟大想法的背后是一片埋葬着不成熟想法的墓地；当我们有了好点子，一定要去试验，将成功的实现方法附加到想法后面，这样的想法才可能是成功的。
• 用户在购买功能的同时也在忍受缺陷。

软件测试：预防+控制

预防：使用正确的方法构建软件，将可靠性、安全性、高性能作为系统设计的一部分，在开发初期就开始考虑；QA角色的作用就是在质量管理领域，规范整个研发过程。

控制：所有测试活动；也就是QC要做的事情。

论缺陷分析的重要

发现有效缺陷，我们需要去了解缺陷，那么我们必须进行缺陷分析，将缺陷分类定级，分析缺陷出现的原因（是否漏测），分析缺陷分布（不同特性），分析缺陷趋势（多个测试轮次后）；这些会让我们更有效进行QC，对测试对象质量等级更加明确，有利于指定更加有效的预防和控制方法；

多数人认为的缺陷生命周期是这样的：缺陷发现、缺陷提交、缺陷修复、缺陷回归、缺陷关闭。
但是，我认为没有经过缺陷分析，缺陷就没有真正闭环。

软件测试的重要原则

 软件生命周期

原始需求	需求规格说明书/目标	开发规格说明书/外部规格说明	概要设计说明书	详细设计说明书	coding	release
		测试规格说明书	测试项列表	测试用例设计	测试活动
用户要啥	程序要做啥	程序要做啥，进一步转换成设计语言/程序的准确表现	如何构建程序	如何构建程序（更细化）	构建	发布交付

从上面，我们可以看到，软件测试并不仅仅是在coding环节的QC活动；软件测试活动渗透在整个软件生命周期。并且需要做到，原始需求 <=> 需求规格 <=> 测试规格 <=>测试用例 <=>缺陷，它们之间是可以相互追溯的。比如：从测试用例追溯到原始需求，却发现没有对应项，说明我们做了不改做的事。相反，则我们漏做了该做的事。

测试策略 

黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入/输出驱动的测试。

重点：集中放在发现程序不按其规范正确运行的环境条件。

穷举测试是无法达到的：一是我们无法测试一个程序以确保它是无错的，二是软件测试中需要考虑的一个基本问题是软 件测试的经济学。最大限度地提高发现的问题的数量，以取得最好的测试效果。

白盒测试或称逻辑驱动的测试，允许我们检查程序的内部结构。

这种测试策略对程序的逻辑结构迸行检查。