你有没有听过有人说：“我们无法测试这个 - 它超出了我们的范围”？我在一个团队工作了一段时间，经常听到这个。我很高兴听到它，因为它改变了我的职业方向，并给了我一个新的愿景。
确保产品质量是一项共同努力，但测试人员的工作是确保正确完成。当有人说我们使用的方法不能测试某个功能时，它并不能免除我们的测试责任，那仍然是我们的工作。但由于种种原因，测试员们感到有点不专业，这就造成了一系列全新的问题。
我在这里分享的故事是一个类似的案例，由于缺乏技术技能和使用的测试技术，即将推出的应用的一个主要特性没有得到正确的测试。但是，我们没有玩责任游戏，而是向团队引入了一种新的测试技术，使其制度化，并确保产品的最重要功能得到了适当的测试。
超越功能测试
我的公司正在开发一种新的嵌入式产品，它在物联网（IoT）行业中具有革命性，其中最重要的部分是我们设计的算法。
在此之前我们曾经只进行过功能测试，但新产品的算法无法单独通过功能测试进行测试。我们曾经探索过“灰盒子”测试以确定它是否是一种选择，考虑到静态和动态分析是我们过去测试的另一种产品测试的一部分，但它对这个产品线没有用处 - 成本与效益没有相关加起来。
我觉得根本的问题是缺乏通用的测试能力。该公司寄希望于该产品的算法，但测试团队没有现有的机制或技能来测试该部分，那是任务开始的时候。
学习源代码
由于功能测试不是一种选择，我决定了解源代码并了解我们如何测试它。但不幸的是，有时情况下，源代码不能由开发团队以外的任何人直接访问，脱离开发了解代码不是一种选择。
在浏览架构和不同模块的过程中，我意识到调试代码以了解控制流程会使事情变得更快。对于软件产品来说，它相对简单，但对于嵌入式设备来说，并不容易。IDE是在仿真模式下配置的，因此我将调试器连接并配置到实际设备，IDE用于在产品上运行代码。它需要一段时间才能获得，但值得一提：我们能够在完成控制流程的同时在设备上运行代码库，并在此过程中读取和编辑值，这是一个很大的帮助。
开发在可维护性方面很重要，因此代码是可读的。在几天内，控制流程和一般架构都很清晰。我们绕过算法的时间花了一段时间，最后我们做到了。一旦我们知道了所使用的条件，就很容易对算法进行逆向工程。
这时我意识到我们可以使用调试器作为白盒测试工具来检查算法的正确性。我们终于找到了可以使这些测试成为可能的解决方案。
重要的是要记住，你不应该每次都寻找固定的测试模式。我们的目标是用任何必要的手段来测试工作，即使这意味着将错误引入到代码中，也就是所谓的错误注入。
行动中的边界价值分析
根据一堆变量，算法决定了屏幕上显示的内容。所有变量及其截止点都放入电子表格中，清楚地了解每个变量的边界。一旦我们在每个阈值之上和之下进行测试，只需在正确的时间操作代码库中的变量即可。
编写正确的值非常重要，同样重要的是在控制流程中的哪个时间注入测试值。因为我们在代码中运行这些测试，所以我们尽可能地将它们保持在接近实际用户环境的位置。一旦设备检测到并记录了任何变量的读数，代码中的值就会发生变化，从而使过程变得切合实际。即使在业务逻辑层进行测试，最好让它们尽可能接近现实生活场景。
展示测试价值
测试人员在代码库中调试源代码和执行测试的想法并不容易从较大的团队中获得批准。因此，战略是在雷达下进行整个研究。这意味着我们必须完成我们计划的活动以及所有这些研究。最终的游戏是捕捉算法中的问题并证明该过程的有效性。我们认为，一旦结果明显，获得批准将这些测试嵌入测试常规过程将很容易。
这就是我们冒的风险：我们打算在算法中找到实际问题。一旦我们找到了一些，该项目就成了众人瞩目的焦点。它很受欢迎，每个人都看到了它的明显价值。没有什么可以辩论的了，我们的过程立即制度化了。从那时起，它一直是产品测试过程中不可或缺的一部分。
展示而不是告诉是一个强大的概念。有时，为了完成工作，你必须这样做，然后显示结果。
测试人员的工作是测试
确保产品经过充分测试是测试人员的职责。该措施不应考虑我们可以测试的内容，而应考虑必须测试的内容。
当然，我们必须优先考虑我们的测试，将测试中的应用的竞争优势保持为最高优先级，因为这将对客户产生最大的影响。如果该功能不可测试，请不要犹豫，找到一种新方法来测试它。测试技术有助于测试的指导原则，而不是严格遵循的规则。
在测试时确保测试尽可能接近真实的最终用户条件。最后，要切断繁文缛节并加快对新流程的接受，展示好处而不仅仅是陈述它们 - 它会产生重大影响。
由Ruink翻译自 Ali Khalid 的《Fault Injection Testing for an IoT Device》一文。