那些“硬控”程序员的经典笑话，测试用例

下面是网上流行的关于测试的笑话，其主要核心思想是——你永远无法把所有问题都充分测试。

正文一

        一个测试工程师走进一家酒吧，要了一杯啤酒；

        一个测试工程师走进一家酒吧，要了一杯咖啡；

        一个测试工程师走进一家酒吧，要了0.7杯啤酒；

        一个测试工程师走进一家酒吧，要了-1杯啤酒；

        一个测试工程师走进一家酒吧，要了2^32杯啤酒；

        一个测试工程师走进一家酒吧，要了一杯洗脚水；

        一个测试工程师走进一家酒吧，要了一杯蜥蜴；

        一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@；

        一个测试工程师走进一家酒吧，什么也没要；

        一个测试工程师走进家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；

        一个测试工程师走进家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；

        一个测试工程师走进一；

        一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；

        一个测试工程师走进一家酒吧，要了NaN杯Null；

        一个测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶；

        一个测试工程师把酒吧拆了；

        一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒，并且不付钱；

        一万个测试工程师在酒吧外呼啸而过；

        一个测试工程师走进一家酒吧，要了一杯啤酒‘;DROPTABLE酒吧；

        测试工程师们满意地离开了酒吧；

        然后一名顾客点了一份炒饭，酒吧炸了。

正文二

        你去饭店，坐下来。

        “服务员，给我来份宫保鸡丁！”

        “好嘞！”

        ——————这叫原始需求

        大厨做到一半。

        餐厅：

        “服务员，菜里不要放肉。”

        “不放肉怎么做啊？”

        “不放肉就行了，其它正常做。”

        “好的您稍等”

        ——————中途需求变更

        厨房：

        大厨：“我肉都回锅了。”

        服务员：“顾客非要要求的嘛，你把肉挑出来不就行了吗？”

        大厨：“行什么行！”

        然而还是一点点挑出来了

        ——————改动太大，部分重构

        餐厅：

        “服务员，菜里能给我加点腐竹吗？”

        “行，这个应该简单。”

        ——————低估改动成本

        厨房：

        大厨：“你！不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就等半天。”

        服务员：“啊，你怎么不早说？”

        大厨：“早说？！我怎么知道他要往宫保鸡丁里放腐竹？”

        然而还是去泡腐竹了

        ——————新需求引入了新研发成本

        餐厅：

        “服务员，还是把肉加回去吧。”

        “您不是刚说不要肉吗？”

        “现在又想要了。”

        ”...好的您稍等。”

        ——————某一功能点摇摆不定

        厨房：

        大厨：“菜都炒过火了你让我放肉？还好肉我没扔！”

        服务员：“客户提的要求嘛。”

        大厨：“你就不能拒绝他啊？啊？”

        服务员：“人家是客户嘛。”

        ——————甲方是大爷

        餐厅：

        “服务员！服务员！”

        “来了来了，你好？”

        “怎么这么半天啊？”

        “稍等我给您催催啊。”

        ——————改动开始导致工期延误

        厨房：

        大厨：“催什么催，腐竹没泡好，我还得重新放油”

        ——————开发者请求重新排期

        餐厅：

        服务员：“抱歉，加腐竹的话得多等半天，您别着急哈。”

        “要等多久？我现在就要吃，你们能快点吗？再不端上来就撤单。”

        “行...您稍等。”

        ——————甲方催活

        厨房：

        大厨：“这改来改去的，逗我玩呢？”

        服务员：“那我问问，要不让他们换个菜？

        大厨：“再换我就死了。”

        ——————开发者开始和中间人PK

        餐厅：

        “服务员，这样吧，腐竹不要了，换成蒜毫能快点吗？对了，顺便加点番茄酱。”

        ——————因工期过长再次改动需求

        厨房：

        大厨：“你不知道蒜毫也得焯水啊？还有你让我怎么往热菜里放番茄酱啊？？”

        服务员：“焯水也比等腐竹强吧，番茄酱往里一倒不就行了吗？很难吗？”

        大厨：“腐竹我还得接着泡，万一这孙子一会又想要了呢。”

        ——————频繁改动开始导致大量冗余

        餐厅：

        “服务员，菜里加茄丁了没有？我去其它饭店吃可都是有茄丁的”

        “好好好，您稍等您稍等”

        ——————奇葩需求

        厨房：

        大厨：“他吃的是村西头瞎子老王炒的宫保鸡丁吗？宫保鸡丁里放茄丁？？”

        服务员：“茄丁炒好了扔里边不就行了吗？”

        大厨：“那还能叫菜吗？哪个系的？”

        服务员：“客户要，你就给炒了吧。”

        大厨：“你顺道问问他腐竹还要不要，这盆腐竹还占着地方，不要我可扔了”

        ——————奇葩你也得做

        餐厅：

        “服务员，还要多久能好啊”

        “很快，很快。”

        “再给我来杯西瓜汁。”

        “好。”

        “我再等10分钟，还不好我就走了，反正还没给钱。”

        “很快，很快...”

        ——————黑暗前的最后黎明

        10分钟后

        “咦，我上次吃的不是这个味啊？”

        大厨从厨房杀出来：“此处省略N字”

        ——————最终决战

        你=客户

        服务员=客户经理+产品经理

        大厨=程序员

测试描述

        在软件工程中，测试是极其重要的一环，比重通常可以与编码相同，甚至大大超过。那么在 前端开发 里，怎么样把测试写好，写正确？

        在前端开发中，编写高质量的测试是确保代码可靠性和维护性的重要步骤。以下是一些关键方法，可以帮助你编写出色的前端测试：

1. 选择合适的测试工具和框架：

   • 使用适合项目的测试框架，比如Jest、Mocha、Cypress等。
   • 对于组件测试，React Testing Library或Enzyme常用于React项目。

2. 明确测试类型：

   • 单元测试：验证单个组件或函数的正确性。
   • 集成测试：测试多个组件或模块之间的交互。
   • 端到端测试：模拟用户在应用中的行为，确保从前端到后端的全流程正常。

3. 测试覆盖率：

   • 确保测试覆盖率达到预期，但不要仅仅为了覆盖率而编写无意义的测试。
   • 覆盖常见工具和路径，包括边界条件和异常情况。

4. 可维护性：

   • 使用清晰、可读的测试代码，避免复杂的逻辑。
   • 对重复的测试逻辑进行抽象和重用，提高测试代码的可维护性。

5. 隔离测试环境：

   • 使用mocking和stubbing技术隔离外部依赖，确保测试仅关注其测试目标。
   • 使用工具如Sinon.js来模拟和控制外部依赖。

6. 自动化测试：

   • 集成CI/CD平台，自动化测试过程，确保每次代码更改后都能及时进行测试。

7. 关注用户体验：

   • 编写测试时，模拟用户真实的操作场景，确保UI和交互符合预期。

8. 持续更新测试：

   • 随着功能的增加和修改，定期更新测试，确保其始终与当前版本保持一致。

        通过这些实践，可以大幅提升前端代码的质量和稳定性，为用户提供更佳的使用体验。同时，也降低了后续维护和新功能开发的成本。

白盒测试、黑盒测试

        白盒测试和黑盒测试是软件测试中的两种基本类型，各自有不同的目的和方法：

白盒测试

        定义：白盒测试，也称为结构化测试或透明测试，是一种测试方法，测试者在了解内部结构以及代码实现的基础上，对软件进行测试。此类测试主要关注软件内部的逻辑结构和代码实现。

        特点：

• 访问性：测试者需要了解程序的源代码。
• 测试目的：检查代码的每条语句、分支和路径，以确保所有逻辑运算正确执行。
• 应用场景：常用于单元测试和集成测试阶段。
• 技术：包括路径覆盖、分支覆盖、条件覆盖等。

        优点：

• 能够发现隐藏的错误和边界条件问题。
• 提供对代码内部逻辑更深的理解。

        缺点：

• 需要较高的技术知识和代码访问权限。
• 难以发现缺失的功能（即未定义的功能）。

黑盒测试

        定义：黑盒测试，也称为功能测试或行为测试，是一种测试方法，测试者无需了解内部代码实现，通过测试输入和输出结果来检验软件是否符合功能要求。

        特点：

• 访问性：不需要了解程序的源代码，测试者关注功能性和用户接口。
• 测试目的：验证软件功能是否按预期工作，确保输入正确产生期望的输出。
• 应用场景：通常用于系统测试、验收测试和回归测试。
• 技术：包括等价类划分、边界值分析、决策表测试、场景测试等。

        优点：

• 测试用例与软件内部实现解耦，测试者不必了解具体实现。
• 有助于从用户的角度确保软件的功能性和易用性。

        缺点：

• 可能会遗漏由于内部代码错误导致的潜在问题。
• 测试覆盖率受限于测试用例的设计质量。

总结

        白盒测试和黑盒测试各有其适用的阶段和目的。在软件开发过程中，通常会结合两者进行全面的测试，以确保软件的质量和可靠性。白盒测试适合用于检查代码的正确性和性能，而黑盒测试则确保软件从用户角度看是符合需求的。通过整合这两种测试方法，可以有效提高软件的整体质量和用户满意度。

单元测试、集成测试、回归测试

        单元测试、集成测试和回归测试是软件测试过程中不同阶段的三种重要类型，每种类型都有其特定的目的和方法。

单元测试

        定义：单元测试是对软件开发中的最小可测试部件（通常是函数或方法）进行的测试。其目的是验证每个单元的功能是否正确。

        特点：

• 范围：关注单个功能模块，通常是单个函数、方法或类。
• 工具：常用的工具和框架包括Jest、JUnit、NUnit、PyTest等。
• 执行者：通常由开发人员在开发过程中编写和执行。
• 自动化：单元测试容易自动化，且执行迅速。

        优点：

• 帮助开发者在早期发现和修复错误。
• 提高代码质量和模块化程度。
• 易于隔离问题，迅速反馈。

        缺点：

• 仅限于验证单个组件，而不涉及组件之间的交互。

集成测试

        定义：集成测试是在单元测试之后进行的，它测试多个软件模块之间的接口和交互，以确保它们能够协同工作。

        特点：

• 范围：关注模块或系统间的交互。
• 工具：可使用TestNG、JUnit（用于Java集成测试）或其他工具。
• 执行者：通常由开发人员或测试工程师进行。
• 自动化：可以自动化，但比单元测试复杂。

        优点：

• 发现模块间接口问题或集成缺陷。
• 验证模块组合的正确性和性能。

        缺点：

• 需要更多的资源和时间来设置和执行。
• 可能需要复杂的环境来模拟集成场景。

回归测试

        定义：回归测试的主要目的是在软件代码发生变更后，确保现有功能没有被新更新破坏。它是对软件进行重复测试，以发现由于更改或新增功能而引入的新缺陷。

        特点：

• 范围：全面覆盖软件的现有功能。
• 工具：可以使用Selenium、QTP、TestComplete等工具。
• 执行者：通常由测试工程师进行。
• 自动化：因为需要频繁执行，通常会自动化。

        优点：

• 确保新修改未对软件现有功能产生负面影响。
• 提高软件的稳定性和可靠性。

        缺点：

• 随着功能增加和变更，测试套件可能变得庞大和冗长。
• 维护回归测试用例可能需要大量的时间和资源。

总结

        单元测试、集成测试和回归测试在软件开发生命周期中扮演着互补的角色。单元测试帮助确认每个模块的功能正确性，集成测试确保模块间的交互正常，而回归测试则保证新代码没有破坏现有功能。一个全面的测试策略应综合使用这些测试方法，以确保软件质量和稳定性。