听到有人宣称“这无法测试”是很奇怪的。作为回应，我认为一切都可以测试。然而，人们必须对测试结果感到满意，其中可能包括失败、经济损失或人身伤害。当以这种理解提出索赔时，是否可以检验任何东西?

　　我在不同的背景下听到过这个评论，现在我在测试职位上花了更长的时间，我正在重新考虑它可能意味着什么。我的测试角色，如果没有别的，教会沟通技巧和耐心。当有人接近您并发表此评论时，他们还表达了关于被测产品或他们自己的什么?

　　当您得知某事不可测试时，请深吸一口气并与此人展开讨论。讨论不是关于为什么某些东西不可测试的——至少不是明确的。这是一种对话，可以更好地理解某人正在经历的事情，调查对事实的不同解释，并帮助使不可测试的成为可测试的。

　　这是事实吗?或者只是一个结论

　　我的思考过程始于测试人员发表评论的理由。我想按照这些思路调查他的想法。我不会为产品或其可测试性辩护。相反，我感兴趣的是确定测试人员是在做事实还是在做结论。事实可以作为进一步讨论的平台。它指定了我们在可测试性范围内的起点。“这无法测试”大概是在天平的末端。在这种情况下，我想通过询问他所拥有的产品知识以及他对无法测试的内容的看法来检验这位测试人员的断言。

　　同样，如果他正在形成一个结论，他所依赖的知识是什么?也许他试图评估某些功能，但发现很难得出结果，所以他说，“这无法测试。” 我的目标是探索和理解他的看法。

　　让我们使用以下示例来检查陈述和结论。

　　根本原因：测试条件

　　几年前，我管理了一个全球测试项目，有很多优秀的测试人员参与其中，但我记得有一位特定的测试人员指出了这一点，但并不积极。几乎在给他的任何测试任务中，首先声称的是“我无法测试，因为我没有合适的测试条件”，这让我很好奇，于是我开始通过以下方式探索这个人的测试条件问题：

　　1.你有任何阻碍你的依赖吗?

　　2.测试环境有问题吗?

　　3.你有稳定构建的新代码吗?

　　4.您需要任何帮助来设置特定的测试场景吗?

　　5.您需要任何帮助来设置特定的产品流程吗?

　　6.是否有机会进行阴性检测?

　　根本原因：不是生产环境

　　非生产(测试环境)和生产环境之间的区别经常被认为是不能或不应该测试特定功能的原因。这些区别包括功能测试和非功能测试(负载、耐久性能等)。

　　在生产中，可能存在测试人员必须在测试环境中手动执行的自动化过程。生产数据代表真实的客户和测试环境中可能发生或不发生的真实情况，并且数据可能包含敏感数据。生产硬件专为高性能而设计，通常是集群的。最后，应用程序可能需要单独的凭据才能连接到数据库并从 Internet 获取信息。

　　其中许多区别是开发团队必须意识到的产品风险。要降低这些风险，您必须通过问自己以下问题来最大程度地减少差异：是否可以将一天的手动任务自动化?是否可以挖掘和清理生产数据以用于测试设置，或者是否有必要模拟它?使用与生产环境和集群兼容的基础架构构建测试环境是否有利?为了最大程度地减少重大部署时对应用程序的影响，是否可以评估生产环境中的资源访问?

　　根本原因：嵌入式代码

　　当我们讨论脚手架代码或其他高度嵌入的功能时，我偶尔会发现一个模块很难执行软件测试，因为它嵌入得太深了。对于偶尔的程序(月末处理)或冗长的操作，可能会有同样的说明。深度嵌入的功能可以包括在层次结构中深入多个级别的程序，甚至是汽车引擎上难以触及的组件。

　　在许多情况下，生成操作证据具有挑战性。可能有证据表明该程序已经发生。如果没有证据，我建议你试验一下这个过程是否曾经被执行过(例如，添加日志来证明执行情况)。

　　根本原因：我们不能接受风险，因为测试太危险了

　　我评估了一些在正常使用中存在一些固有风险的产品。很明显，测试火箭引擎与测试游戏应用程序不同，这些方法对测试人员和产品都有一定的危险。即使这些产品不太容易测试，我和我的项目经理也会考虑是否测试它们以及承担多大的风险。换句话说，如果不进行特定测试，使用该产品可能会产生什么结果?让我们来看下面的例子：

　　“我无法测试这个 DELETE 方法，因为它会删除整个数据库。”

　　我质疑我们如何才能降低风险，同时仍然进行能够产生可靠和相关数据的测试。

　　1.我们可以使用工具来模拟交易而不是触发它们吗?

　　2.是否可以使用mock来模拟数据库?

　　3.我们能否开发一个类似的结构并为其提供来自同一数据库中真实表的数据?

　　4.我们可以拦截查询以检查其语法吗?(在我们执行之前)?

　　当您进行此类测试时提醒您的开发团队。他们可以为环境中的异常事件做好准备，预测额外的挑战，甚至参与漏洞搜索。

　　根本原因：太小/太基础无法测试

　　作为一名测试人员，我比作为开发人员更常听到有人说更改太容易测试了。修改对索赔人来说似乎很简单——只需一行代码或配置文件更新。其他直接的调整包括在错误消息中添加短语、修复客户看到的文本的拼写或添加联系信息。简单的调整可能会导致错误。我遇到过错误消息中的文本突然出现拼写问题或更新的联系方式不再有效的情况。在经历了其中的几次之后，拼写和“轻松修改”已成为我评价最高的两个场景。此外，虽然它们可能会通过代码审查，但更好的测试是在实施后检查它们。

　　根本原因：沮丧

　　有一次，一位沮丧的测试人员找到我说，“这无法测试!” 虽然我最初的冲动是协助测试，但我试图先换位思考。“也许它是无法测试的，”我推测道。我讨论了该特定功能的技术困难以及影响可测试性的其他方面。这种检查会减少一个人的挫败感，将他的注意力从手头的工作上转移开，并很容易地让他参与讨论。

　　我开始对正在测试的产品进行协作调查。请记住从简单开始——验证产品是否已部署。有多少次您开始评估某些东西只是为了了解它不包含在以前的构建中?讨论测试的目标以及测试计划如何理解行为和识别问题。方案是否符合产品的业务预期?

　　以此为基准，我讨论了他的经历以及他是如何得出结论的。我们使用应用程序中的数据来验证我们的观察结果(数据库记录、日志文件、屏幕截图等)。我一路上一直在检查，看看是否出现了任何数量的测试，然后朝那个方向前进。当我们的共同努力收效甚微时，我们邀请了一名开发人员参与我们的讨论，并探索提高产品透明度的方法。

　　根本原因：面对具有挑战性的个性

　　还有一次，我和一位开发人员一起参与了一个项目，他虽然很有才华，但并不总是对测试人员友好。这个人曾经联系过我并相当傲慢地宣称他的代码不可测试。他建议我不要花时间在这上面。

　　如果您发现自己处于这种情况，您应该通过询问此人做了什么使产品无法测试来开始对话。不可避免地，必须提出问题以礼貌地暗示如果产品未经测试或测试不足就发布使用，则存在失败的风险(失败的程度取决于产品——我敢肯定我们都可以假设足够大的产品缺陷)以及后果的可能性。如果这种情况可能发生，我的聊天旨在确定此人的舒适程度。

　　或者，讨论可能集中在降低产品可测试性的动机上。虽然降低可测试性似乎是矛盾的，但调查可能会发现安全漏洞、时间限制、自我(检查时要小心)或其他超出个人控制的变量。无论如何，作为测试人员，您可以披露不检查全部或部分产品的风险。

　　根本原因：关于测试和可测性的不同观点

　　在一个项目中，我与开发人员讨论了一些开发活动，并建议她发布代码以便我检查。她回答说没有什么可以测试的。我想知道我们刚刚谈到的发展，以及在我脑海中她在过去一个月里是如何努力工作的。“真的没有什么可以测试那么多的时间和精力吗?” 我质疑。

　　我向我的项目主管表达了我的担忧，我们在没有进行我建议的审查的情况下继续工作。我们在测试代码时发现了错误和缺失的需求。这是一个经常被讲述的悲惨故事，但当我们在事件发生后审视我们的成就和可能性时，我发现了一个新的视角。

　　为了确定她的开发路径，开发人员进行了试验并创建了原型。她一路上的胜利鼓励他们进行进一步的研究。她将自己的工作视为脚手架——可以帮助创建其他代码的代码。她还认为脚手架不值得测试。

　　作为此次讨论的结果，我们与她合作开发了以下版本，以尽早审查脚手架代码。我要求研究代码以更好地理解它是如何合并到最终产品中的。测试团队还就预期功能和用户界面元素的差异提供了意见。我们没有开始公开错误(因为我们正在研究正在进行的开发)，而是提供对产品变化的观察——许多敏捷团队都经历过的迭代想法。

卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价

部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲       电话：4006070568