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

淩亂°似流年 2022-10-15 07:59 149阅读 0赞

“这个问题测试人员为什么没发现？”  
作为真测试人员，如果在交付的系统被发现新问题的时候听到研发人员脱口而出说这句话， 还真真是有点委屈~~ 明明系统他们做的，测试案例也是大家看过的，结果出问题了背锅的就只有测试组。我不服气，但是我们测试人员是系统质量保证的关键也是个不争的事实，那么这个锅我们到底要不要背呢？我没有标准的答案，但看了文章 [测试用例的一些“真相”与“事实”][Link 1] 的内容后，给了我很多启发和思路。下面是一些总结与记录，看完这些，或许能让研发人员以及不了解测试工作的人不再对测试有偏见，我们以后也有底气告诉他“这并不完全是我的问题。”

### 理由一：我们不能提前确定所有的测试用例 ###

测试人员只能尽可能完全的测试，但是永远不可能达到完全测试。这几乎是测试领域一个共识的结论。这主要有以下几个原因：

1.  **测试人员能力的差异**：软件系统本质就是一个系统，是由一层层的依赖组成的。而当我们想测试某一个点时，首先需要假设一些前提条件，而这个假设本身又是依赖于其他测试案例的组合，在判断哪个假设条件的组合是可靠的、不需要继续测试的 往往是根据个人经验决定的，而每个测试的个人经验和技术能力是不同的，所以这是有风险的。
2.  **研发人员能力的差异**：我们已经知道，针对同一个需求，不同的研发人员实现的方式可能不同，最后完成的质量也是各不相同，从而我们用来验证和评估软件质量的用例集也应该是不一样的。所以在编写测试案例的阶段（与开发阶段基本并行），我们更无法确定所有场景的用例集已经被包含。这也是探索性测试的切入点之一。
3.  **用户的多样性**：瀑布流程中的测试案例，通常是基于系统流程的，很少考虑“人”的因素。客观规律是，每个人对事物的认知是不同的，所以哪怕我们将测试问题锁定在某一个层次、用例大小确定在某一粒度，我们也无法一次性确定需要的用例集。曾经有一个尝试，让不同的测试专家对三角形测试问题给出用例（即给出的a、b、c的长度能否组成三角形），实际结果是得到的用例数从几十到上百不等。由此看出，人的因素也是不可避免的。

由上述原因，给我们的启示就是测试设计基本不可能“一劳永逸”，那么测试案例也不可能完全覆盖系统功能。我们需要时刻对待测系统出错的方式保持警惕、以及针对性的测试设计，使系统更健壮。

### 理由二：我们不一定能如实的写下所想到的测试用例 ###

想象一下，若我请你给对面楼拍一张最好看的照片，我猜你一定会想方设法的为它找角度和光线，进行最好的构图。所以在你最后的照片中，这栋楼一定是最好看的，细节也是最全面的，而周围的环境在你眼中就只是一个衬托的作用，可能你偶尔会观察到想要“面面俱到”，最后发现实在没有足够的精力全部顾及。  
同理，在我们设计用例的时候，也会有这种情况出现。**当我们聚焦于某一个测试点时，我们为了尽可能的将它测试的详尽，只能选择忽略其他的一些条件**。也许我们当时不想忽略，但是当我们将所有的测试点都展开，此时信息量的膨胀也会使我们妥协甚至放弃。这就导致我们最终写下的用例只是自己全部设想内容中的一部分（自认为对某一个功能最完整的测试内容），所以一个用例记录下的内容通常并不能反映测试设计人员脑海中全部的信息，测试设计的信息丢失在此也是不可避免的。

### 理由三：我们不一定能如实的执行所写下的测试用例 ###

所有的测试用例可以归为两类：抽象用例，实例化用例。  
简单来讲，抽象用例是以抽象的方式描述了前提条件、测试步骤以及预期结果，里面涉及的测试数据是抽象的，比如“用户”就只是一个抽象表达，暂时与某测试环境没有进行关联。实例化用例则是在执行时，将抽象用例里面的数据与实际场景和测试环境发生了关联，比如"用户"其实是在系统中真实存在的某个UUID值。  
但是根据经验知道，**不是所有的抽象用例都可以转化为实例化用例**，例如业务发生的变化，或者真实测试环境的限制等都有可能使转化失败。因此我们最后实际执行的用例集比设计时的用例集更小，导致覆盖系统的期望存在更大的差距。

### 理由四：用例设计人员与执行人员分开，会带来虚假的安全感 ###

根据上面的真相2和3，我们知道，已完成的测试用例存在一定程度的信息缺失问题。而如果设计人员和执行人员不是同一人会发生什么呢？这里一定是信息更多的缺失。而比这更严重的问题是，一方面设计人员认为他已经完成了现阶段最全面的覆盖，并且不再参与后面的执行工作，那么软件可能的变化将得不到及时的反馈，用例集也不能被及时的更新，时间一长，当前设计的测试集就会与产品实际需要的用例集相差更大。另一方面，对执行人员来说，他们需要通过已执行完成的用例百分比来衡量自己的工作量，已经有一个用例集存在，他们的第一要务是执行完，因此他们对当前用例集是否是合适的，是否需要根据实际情况在某方面增加新的用例等思考相对较少。  
从而我们看到，如果用例设计人员、执行人员分开，由于他们评估自己工作的方式不同，将导致的一种可能状况就是，**他们对各自的工作都比较满意，可是最终映射到产品或系统时，整体的测试效果并不理想**。

### 理由五：用例设计与执行的间隔时间越长，测试效果越差 ###

这并不难理解，因为测试用例本身只是测试人员的一个计划、一个意图，只有基于它与待测系统真正交互后，测试工作才算完成了一个闭环。阶段的间隔周期越长，反馈环就越长，从而单位时间内通过用例得到的信息就更少。从上面的讨论中我们还看到，用例从在脑海中构思、到记录、到实际执行，一直都存在着信息损失。所以**尽可能地加快整个测试闭环，才能最大程度的弥补用例生命周期中各环节的信息损失**。

### 理由六：由用户给出的测试场景价值很高 ###

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

### 理由七：满足用例的前提条件，是需要代价的 ###

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

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

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

### 理由八：迭代开发模式中，用例集的回归其实很重要 ###

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

### 结论 ###

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

[Link 1]: https://insights.thoughtworks.cn/testcases-practice/