问题引出
从可见的交付给用户的最上层UI功能来看，待测功能只是一个简单的“启动”—“观察结果”。
但是，我想当测试人员接手这样一个测试项目的时候，恐怕应该是先“惊喜”后“恐慌”吧？！
“惊喜”：这么简单，点一下看一下结果不就测完了？
“恐慌”：这么简单？会不会还有什么测试点我遗漏了，怎么感觉有点惴惴不安呢？！
这样的测试场景，我想几乎每个测试人员在职业生涯中都会遇到。那么，是不是真的就是“点一点”看看结果就行了呢？显然不是。
那么，对于这样类型的待测项目我们应该怎么去设计测试或者进行测试呢，或者有什么测试技巧需要掌握的呢？
我们本文讨论的核心是：从业务层面出发，思考如何进行这类项目的测试，及我们需要借助或抓住的一些测试灵感。
问题思考
问题1：如何确定“点一点”返回的结果是正确的呢？
比如：点一点搜索某个“number=100”的数据有多少个，返回结果有10个。
既然，我们不能确定“点一点”返回给我们的结果是正确的。那么，我们可以模拟数据，以此判定结果的正确性。具体怎么做呢？
例如：确定系统内没有number=200的数据，模拟、输入100个number=200的数据。通过被测系统查询，返回number=200的数据数量。
若返回数量为100个则表明系统正确性，通过测试；
若返回数量不是100个，则表明系统存在错误，测试失败。
以此模拟数据，来判定被测系统的正确性与否。
因此，如何进行外表简单的应用功能测试？需要掌握的第一个测试技巧是：学会模拟测试数据。
问题2：如何丰富测试数据样本呢？
比如：在1中，我们证明了某类测试数据测试场景下，被测系统的正确性。但是，在其他类型测试数据输入情况下，被测系统是否会响应正确呢？
也许，看到这个问题，有的人会说：继续模拟更多类型的测试数据呗，比如string啊、int啊、list啊等等。
不得不说，这的确是一个方法。但是，数据类型多种多样，系统数据边界我们也不得而知（从业务层面出发，我们不知悉代码内部细节），我们如何能够枚举完所有的数据类型和模拟数据边界值呢？！
要解决这个问题，从用户的角度出发，有一个很好的建议：如果可以，尽量使用真实数据进行测试。
如果我们能获得真实数据采样样本，那么可以很好地解决我们模拟数据样本不够丰富和模拟数据与真实数据之间存在差异的问题。而且，真实数据能让我们更接近用户的使用环境。
问题3：对于内部逻辑复杂的应用，最终返回结果正确，但是我还是有点担心内部运算有没有出问题呢？
比如：某个应用，只需web页面点击即可触发，但后台程序涉及多个组件，如何确定运算过程中各个组件的正确性。
解决多个组件联合作业的问题，常用的方法是：阶段性测试，即每次只测试一个组件正确性，最终联合确定整个系统正确性。
但从业务层面出发，有一个简单的技巧就是：如果可以，请随时观察后台程序日志打印。
日志是一个很好的测试媒介，借助日志可以发现许多未曾暴露到前端呈现在用户面前的问题。我们要善于抓住日志中的“error”、“warn”等等信息。
问题4：如何快速地了解被测系统的一些“不为人知“的细节？
比如：观察到日志中某个”可疑“信息，但是无法确定是否是故障，或者系统重启后，表现与预期不一致，无法确定是否是故障。
这个时候，作为场内测试人员，你就需要同开发人员保持良好的伙伴关系。
开发人员对被测系统内部细节的了解程度远胜于测试人员，同开发人员保持良好的伙伴关系，可以在遇到问题的第一时间求助开发人员而得到很好的答疑。并且，在开发人员的指导下，可以帮助我们更快地熟悉被测系统。
问题总结
针对本文的核心问题：如何进行外表简单的应用功能测试？在此给出了4点建议。如下表所示：
我们不谈测试技术，我们谈的是如何思考测试。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
