【软件测试】知道了这些，测试人员再也不用背黑锅

“这个问题测试人员为什么没发现？”
作为真测试人员，如果在交付的系统被客户使用时发现新问题，就会听到研发人员脱口而出这句话， 真真是有点委屈~~ 明明系统他们做的，测试用例和测试点也是大家一起认可了的，结果出现新问题时背锅的就先是测试组。我不服气，但是我们测试人员是系统质量保证的关键环节 也是个不争的事实，那么这个锅我们到底要不要自己抗下呢？我没有标准的答案，但看了文章 测试用例的一些“真相”与“事实” 的内容后，给了我很多启发和思路。
下面是我个人的总结与记录，读完本章后，或许对于研发提出的问题，你就知道该如何有理有据的回答“这并不完全是我的问题”，也让其他人能更多的了解到测试这个岗位的工作。
注意：该文不是为了挑起研发与测试人员之间的矛盾，只是讲述了有关测试过程和测试结果可靠性的事实。不要代入过多的情绪，才能更好的进行思考~

依据一、再全面的测试用例也永远无法达到完全测试

只要有测试经验的人都知道，测试过程只能保证尽可能完全的测试，但是永远不可能达到完全的覆盖测试。所以测试的过程一定是不完整的，这主要有以下几个原因：

1. 测试人员能力的差异：软件系统本质是由一层层的依赖组成的。当我们想测试某个功能点时，首先需要假设前提条件是满足的，而这个假设本身是依赖于其他测试用例的组合。不同经验和技术能力的人在判断哪个假设条件的组合是可靠的时 所依据的信息也是不同的，这就增加了测试结果的风险。
2. 研发人员能力的差异：针对同一个需求，不同经验的研发人员实现的方式也会有所不同，从而我们用来验证和评估软件质量的用例集也是不一样的。当我们进行用例评审时，也就无法确定所有场景的用例集已经被包含，导致测试不能完全覆盖。这也是探索性测试的切入点之一。
3. 系统用户的多样性：我们设计全流程覆盖的测试用例时通常是基于系统流程的，很少去考虑“人”的因素。但人的因素是客观存在的，每个人对事物的不同认知是也无法忽略的，哪怕只有一个功能点，我们准备的用例也无法覆盖全部用户的操作特点，所以必然不能完成真正的完全测试。

由上述原因给我们的启示就是再全面的测试用例永远不可能完全覆盖系统。我们只能时刻保持对待测系统出错方式的警惕，以及针对性的进行详尽的测试设计，使系统更健壮。

依据二、总是针对某个功能点进行测试设计

当我们在设计用例时，常常会出现以下情况，就是当我们聚焦于某一个测试点时，我们为了尽可能的将它测试的详尽，就只能选择忽略其他的一些条件或者默认依赖的条件可靠。即使当时不想忽略，但是当我们将所有的测试点都展开，此时信息量的膨胀也会使我们选择妥协从而忽略掉与该功能关联不大的测试点。这就导致我们最终写下的测试用例只是自认为对某一个功能最完整的测试内容，而不是自己设想下的全部内容。
因此一个用例记录下的内容通常并不能反映测试设计人员脑海中全部的信息，我们针对功能点进行测试设计时，其他测试点信息的丢失表现的尤为明显。

依据三、抽象用例使得执行过程仍存在可变因素

什么是抽象用例？
所有的测试用例可以归为两类：抽象用例，实例化用例。简单讲包含抽象测试数据的测试用例就叫做抽象用例，例如常说的“系统用户”其实就只是一个抽象数据的表达，并非指定为当前环境系统中真实存在的某userID，所以我们大多数的测试用例都是抽象用例。
抽象用例若与真实的测试环境进行关联，就可以将抽象用例转化为实例化用例。但根据经验可知，抽象用例因数据&业务变化，常常有转化实例化用例失败的可能性，导致测试人员并不能提前确认好每个实例化用例，因此测试执行过程无法被完全控制，可能出现相同的抽象测试用例在不同的实例化数据下会得到不同的测试结果，导致覆盖系统的期望存在更大的差距。

依据四、测试执行阶段的风险不可忽略

根据以上2.3两点，我们了解到测试人员已完成的测试用例会存在一定程度的信息缺失问题。其实下一阶段的风险也是很难避免的，在测试执行阶段最常发生的事情有以下两个：

1. 测试用例编写与用例执行间隔的时间越长，测试效果越差。这应该不难理解，因为测试用例本身就是测试人员的一个计划，只有基于它与待测系统真正交互后，测试工作才算完成了一个闭环。如果阶段的间隔周期越长，就会导致单位时间内我们通过用例得到的信息越少或者理解的偏差，从而发生更多信息的缺失。然而时间间隔的周期并不仅仅由测试人员控制，因为系统研发人员提测前常需要通过用例评审反思自己功能实现与联调是否符合预期，因此测试用例编写的时间一般在研发开发过程中，测试执行的时间在研发提测后，这也就导致测试用例编写完成后，并不能立马进入测试执行阶段。这个时间的间隔或长或短，但仍会造成测试结果的不可靠性。
2. 测试用例编写与测试执行人员非同一人，导致测试结果更大的风险。如上所说，同一人在不同时间进行测试执行都会造成测试结果不可靠，那么毫无疑问，不同的人在进行用例执行时，一定会引起更多的信息丢失。而比这更严重的时，二人在完成各自工作后都不会有更多的思考，因此会出现他们对各自的工作都比较满意，可是最终映射到产品或系统时，整体的测试效果并不理想。所以如果测试用例编写与测试执行人员非同一人，那么他们无法对软件可能的变化做出及时的反馈和调整，也就会造成更大的损失。

因此测试执行过程并不是简单的用例执行而已，我们仍需要根据软件的变化，不断的进行思考和完善测试用例以及测试过程，才能更好地保证系统的测试质量。我们应尽可能地加快整个测试闭环，才能最大程度的弥补测试用例生命周期中各环节的信息损失。

依据五、一个人的思考是有限的

测试人员通常是基于产品经理整理的需求和场景进行测试设计和执行。我们实施各类分析技术得到用例集，但这通常也是基于产品经理的业务输入和开发的技术选型，实践上会对整个系统存在认识偏差和识别用例优先级排序困难等问题。而这恰恰是客户场景输入的有价值的地方，尤其一些场景是客户自身“痛的领悟”。对一个已经生产运维的系统，客户测试团队的用例集、甚至运维团队的缺陷集都是高价值输入。

依据六、满足用例的前提条件，是需要代价的

我们在真相3中提到，抽象用例包含的三个必要要素是：前提条件、测试步骤、预期结果。这里前提条件在写测试案例时可能不需要太多时间，可是到了实际执行这条用例 尤其手工执行时，我们可能需要花费10分钟去准备这个“前提条件”，然后只用1分钟就能执行完测试步骤，并且测试出的缺陷在记录时是需要找到复现条件的，因此前提的数据准备代价可能是当前用例的主要执行点的数倍，导致测试时间紧张或者来不及全面测试。
这里主要是提醒测试人员，请注意“想得到却做不到”的陷阱。虽然在设计用例时，我们可以基于逻辑写下这个用例，但在测试时发现它的代价非常大，那我们需要立即调整案例执行顺序，将它“前提条件”的案例执行完后，就执行本则案例，这样可以一定程度的节省时间成本。尤其是一些负向的测试，比如网络状态模拟，我们不应该真的去等到网络异常才进行测试。那要怎么去平衡这个代价呢？首先前提条件可以通过以下几种方式得到满足：

1. 用SQL的方式向数据库插入相应状态的数据（但数据不一定合法）
2. 将满足条件的数据多Copy几份，修改唯一键的值后保存
3. 直接通过UI，按照用户真实的流程生成订单并提交（合法但效率不高）
4. 通过API的方式，调用对应的API生成符合预期“前提条件”的数据

上述方法各有优缺点，我们需要根据真实业务场景，以及操作的难易程度进行选择。同时承认用SQL这样非业务方式直接写入是一种执行层面“妥协”非常重要，它会让我们重新思考当前的一些“理所当然”的实践，其出发点、收益、风险，从而改进与提高。

依据七、迭代开发模式中，用例集的回归其实很重要

大家都同意“回归测试很重要”，但是要真正做好回归测试，却并不简单。回归什么、想达到的目的是什么、效率怎样都是回归过程中需要认真对待的问题。
在瀑布流程中，回归测试作为一个单独的阶段而存在，它有自己的资源分配、准入、准出，并且有较充足的时间。然而对于迭代开发模式，一般的Scrum的团队中几乎看不到有回归阶段的存在。那么我们应该在敏捷中怎样来对待回归测试呢？它是一个阶段、还是一个类型？
一般在敏捷团队的实践中，可能会出现两个极端的现象。一方面，有些团队有分层次的测试策略，完备的自动化测试，使得一次回归的代价很很低，回归集在持续维护。在重构、新功能引入等情况下，回归可以随时执行，在几分钟内或不超过1小时就完成一次回归，回归以一种测试类型存在。另一方面，也有团队在重构、新功能引入等情况下对回归这件事就“随缘”了，没有回归目标，回归测试是以天为单位的代价存在，且是在一个相对其它开发和测试活动之外一个明显存在的阶段。
从用例的角度看，回归用例集一定程度是代表“回归什么”。没有这个基础，回归测试将是一种无序的、难以评估的方式进行。持续保持回归用例集有效，添加新用例、剔除无效用例等用例集的维护工作很重要，尤其是探索性测试过程中产生的有价值的新用例怎么加入回归用例集也很重要。

结论

上面这些与测试用例相关的不确定性、甚至不可能性，我在这里写出来，并不是想辩论出现问题时要找谁负主要责；而是想说，不论测试本身还是其他工作者，对待测试不应该盲目乐观和轻视这些问题。测试工作不是很难，但也绝不简单。对于任何一个系统，哪怕只是一个小功能，完全测试几乎不可能存在，我们测试人员能做到的就是尽可能的发散思维去设计，然后争取梳理更全面的用例，而一个好的测试集，必然少不了研发人员基于对自己代码的了解提出的建议，和产品经理基于对系统的要求说出的想法，有了更多人智慧的协助，系统才能得到更好的保障。
另外，当有人发现线上问题时，第一任务应该是快速响应，及时止损，第二任务是问题复盘，避免再犯。如真是因为测试的疏忽出现的问题，我们大方的背锅也没啥，此时能尽快与研发商议应对措施才是正解。
最后希望大家走出追责和背锅的误区，都能走进互信的良性循环。