外表简单内里复杂的功能测试，如何进行？

问题引出不知道大家有没有遇到这样的测试场景一个Web应用待测功能很简单只需要点击按钮启动运行经过一系列内部运算返回给用户一个结果列表。从可见的交付给用户的最上层UI 功能来看待测功能只是一个简单的“启动”—“观察结果”。但是我想当测试人员接手这样一个测试项目 的时候恐怕应该是先“惊喜”后“恐慌”吧“惊喜”这么简单点一下看一下结果不就测完了“恐慌”这么简单会不会还有什么测试点我遗漏了怎么感觉有点惴惴不安呢这样的测试场景我想几乎每个测试人员在职业生涯中都会遇到。那么是不是真的就是“点一点”看看结果就行了呢显然不是。那么对于这样类型的待测项目我们应该怎么去设计测试或者进行测试呢或者有什么测试技巧需要掌握的呢需要说明的是在这里我们不讨论什么先进行单元测试、再进行集成测试、最后系统测试这类的分层测试设计理念也不细致讨论使用什么判定表、等价类等具体的黑盒或白盒测试方法。我们本文讨论的核心是从业务层面出发思考如何进行这类项目的测试及我们需要借助或抓住的一些测试灵感。问题思考问题1如何确定“点一点”返回的结果是正确的呢比如点一点搜索某个“number100”的数据有多少个返回结果有10个。既然我们不能确定“点一点”返回给我们的结果是正确的。那么我们可以模拟数据以此判定结果的正确性。具体怎么做呢例如确定系统内没有number200的数据模拟、输入100个number200的数据。通过被测系统查询返回number200的数据数量。若返回数量为100个则表明系统正确性通过测试若返回数量不是100个则表明系统存在错误测试失败。以此模拟数据来判定被测系统的正确性与否。因此如何进行外表简单的应用功能测试需要掌握的第一个测试技巧是学会模拟测试数据。问题2如何丰富测试数据样本呢比如在1中我们证明了某类测试数据测试场景下被测系统的正确性。但是在其他类型测试数据输入情况下被测系统是否会响应正确呢也许看到这个问题有的人会说继续模拟更多类型的测试数据呗比如string 啊、int啊、list啊等等。不得不说这的确是一个方法。但是数据类型 多种多样系统数据边界我们也不得而知从业务层面出发我们不知悉代码内部细节我们如何能够枚举完所有的数据类型和模拟数据边界值呢要解决这个问题从用户的角度出发有一个很好的建议如果可以尽量使用真实数据进行测试。如果我们能获得真实数据采样样本那么可以很好地解决我们模拟数据样本不够丰富和模拟数据与真实数据之间存在差异的问题。而且真实数据能让我们更接近用户的使用环境。问题3对于内部逻辑复杂的应用最终返回结果正确但是我还是有点担心内部运算有没有出问题呢比如某个应用只需web页面点击即可触发但后台程序涉及多个组件如何确定运算过程中各个组件的正确性。解决多个组件联合作业的问题常用的方法是阶段性测试即每次只测试一个组件正确性最终联合确定整个系统正确性。但从业务层面出发有一个简单的技巧就是如果可以请随时观察后台程序日志打印。日志是一个很好的测试媒介借助日志可以发现许多未曾暴露到前端呈现在用户面前的问题。我们要善于抓住日志中的“error”、“warn”等等信息。问题4如何快速地了解被测系统的一些“不为人知“的细节比如观察到日志中某个”可疑“信息但是无法确定是否是故障或者系统重启后表现与预期不一致无法确定是否是故障。这个时候作为场内测试人员你就需要同开发人员保持良好的伙伴关系。开发人员对被测系统内部细节的了解程度远胜于测试人员同开发人员保持良好的伙伴关系可以在遇到问题的第一时间求助开发人员而得到很好的答疑。并且在开发人员的指导下可以帮助我们更快地熟悉被测系统。问题总结针对本文的核心问题如何进行外表简单的应用功能测试在此给出了4点建议。如下表所示我们不谈测试技术我们谈的是如何思考测试。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。