问题引出你是否遇到过这样的测试场景：一个web应用，被测试的功能很简单，只需要点击一个按钮就可以开始运行，内部经过一系列的计算，结果列表返回给用户。从交付给用户的可见顶层UI功能来看，待测功能只是简单的“启动”——“观察结果”。不过，我想当测试人员接手这样的测试项目时，恐怕应该是先“惊讶”再“恐慌”吧？！《惊奇》：就这么简单，点一下就可以看到结果，这不就是测试结束了吗？《恐慌》：这么简单？会不会有什么考试点漏掉了，为什么我会觉得有点不安？！这样的测试场景，我想几乎每个测试人员在自己的职业生涯中都会遇到。那么，真的只是“点一下”就能看到结果吗？很明显不是。那么，对于这类待测项目，我们应该如何设计或进行测试，或者需要掌握哪些测试技巧呢？需要说明的是：这里，我们不讨论先单元测试，再集成测试，最后系统测试等层次化测试设计概念，也不详细讨论哪些决策表、等价性等具体黑盒要使用的类。盒或白盒测试方法。这篇文章我们讨论的核心是：从业务层面出发，思考如何测试这类项目，以及我们需要依赖或掌握的一些测试启示。思考问题问题一：如何判断“点击一点”返回的结果是否正确？例如：点击搜索某个“number=100”的数据有多少，返回结果有10条。因为，我们无法确定“点一点”返回给我们的结果是否正确。然后，我们可以模拟数据来判断结果的正确性。怎么做？例如：确认系统中没有number=200的数据，模拟输入100条number=200的数据。通过查询被测系统，返回number=200条数据。如果返回的数字是100，说明系统正确，测试通过；如果返回的数字不是100，说明系统有错误，测试失败。使用这个模拟数据来判断被测系统的正确性。那么，如何对一个看起来很简单的应用程序进行功能测试呢？首先要掌握的测试技巧是：学会模拟测试数据。问题二：如何丰富测试数据样本？例如：在1中，我们在一定的测试数据测试场景下证明了被测系统的正确性。但是被测系统会正确响应其他类型的测试数据输入吗？也许，看到这道题，有人会说：继续模拟更多类型的测试数据，比如string、int、list等。不得不说，这确实是一个方法。但是，数据类型繁多，我们不知道系统的数据边界（从业务层面，我们不知道代码的内部细节），如何枚举所有数据类型，模拟数据边界值呢？！要解决这个问题，站在用户的角度，有一个很好的建议：如果可能的话，尽量使用真实数据进行测试。如果能够得到真实的数据采样样本，就可以解决我们的模拟数据样本不够丰富，模拟数据与真实数据存在差异的问题。而且，真实的数据可以让我们更贴近用户的使用环境。问题三：对于内部逻辑复杂的应用，最终返回结果是正确的，但还是有点担心是不是内部运行有问题？例如：一个应用只能通过点击网页来触发，但是后台程序涉及多个组件，如何在计算过程中判断每个组件的正确性。解决多个组件联合运行问题的常用方法是：阶段测试，即一次只测试一个组件的正确性，最后共同判断整个系统的正确性。但从业务层面来说，有一个简单的技巧：如果可能，请随时观察后台程序日志打印。日志是一个很好的测试媒介。借助日志，可以发现很多没有暴露给前端而呈现给用户的问题。我们要善于把握日志中的“错误”、“警告”等信息。问题四：如何快速了解被测系统的一些“未知”细节？例如：观察到日志中的某条“可疑”信息，但无法确定是否是故障，或者系统重启后，性能与预期不符，无法确定是否是故障过错。这个时候，作为现场测试人员，就需要和开发者保持良好的合作关系。开发人员比测试人员更了解被测系统的内部细节，与开发人员保持良好的合作伙伴关系，遇到问题可以向开发人员寻求帮助并得到很好的解答。并且，在开发者的指导下，可以帮助我们更快的熟悉被测系统。问题总结针对本文的核心问题：如何测试外观简单的应用功能？这里有4条建议。如下表所示：我们不谈测试技术，我们谈如何思考测试。
