对照 需求文档、产品设计文档 做接口测试。
但是预期结果需要的字段在需求中无法看到,这个是必须问开发吗?还是又其他解决方法呢?
@Nemo*:
没有实现需求,提交bug
@快乐的凡人721: 我的意思是写接口测试用例时,没有接口文档,如何知道这个接口的预期结果呢,除了问开发,网上说通过抓取数据包,但是抓取的数据包只是接口的实际响应结果,不是预期结果,即没法做比对
@Nemo*:
写测试用例 要根据 接口文档 来吗?
不是根据 需求文档、产品设计稿 弄?
@快乐的凡人721: 你应该说的功能测试,我说的是接口测试,主要是要接口文档,需求文档可以辅助了解业务逻辑
@Nemo*:
接口测试 应该开发人员自己完成,那啥,单元测试UT
在没有接口文档的情况下进行接口测试可能会增加挑战,但仍然有一些方法可以帮助您进行有效的测试:
探索性测试(Exploratory Testing): 使用探索性测试的方法,尝试在没有明确文档或预期结果的情况下发现系统的行为。通过尝试不同的输入值、边界条件和操作序列,以及观察系统的反应来发现潜在的问题。
逆向工程分析: 分析应用程序的前端代码和后端代码,了解它们之间的交互和数据传输方式。虽然这可能比较复杂,并且可能需要一定的技术知识,但它可以帮助您理解应用程序的工作方式,并从中推断出可能的接口行为。
抓包分析: 尽管抓包只能获取请求和响应数据,但您仍然可以通过分析响应数据来了解系统的行为。尝试通过抓包来收集尽可能多的信息,包括请求参数、响应状态码、响应数据结构等,并根据这些信息来进行测试。
与开发人员沟通: 尽可能与开发团队或者系统的维护者进行沟通,了解系统的设计和实现细节。开发人员可能能够提供一些关于接口的信息,或者在测试过程中提供反馈和帮助。
使用模糊测试(Fuzz Testing): 使用模糊测试技术来对接口进行压力测试和边界测试。通过向接口发送大量的随机数据或非预期的输入,来发现系统的异常行为和潜在的安全问题。
记录和整理测试结果: 在测试过程中,及时记录您的测试步骤、发现的问题以及系统的行为。这样可以帮助您整理测试结果,并且在未来的测试中作为参考和依据。
尽管在没有接口文档的情况下进行接口测试可能会更具挑战性,但通过结合多种方法和技术,您仍然可以进行有效的测试并发现潜在的问题。
没有接口文档,要么自己看代码,要么让研发给出你想要的详细信息,例如接口入参、请求头(有些加密)等等。拿到后再做接口测试。
不建议盲猜。
不建议参考上面chatgpt生成的答案。
接口测试中预期结果是根据什么来写的呢?如果我看代码,假设代码有错,任然不知道他的正确预期结果,是这样理解的吗?
@Nemo*: 首先,这个接口实现什么功能,接口返回对应哪些字段应该是详细设计文档或者接口文档规范的,这些就属于我上面说的你需要提前拿到的详细信息之一 ,而不是自己去猜测。
其次,接口测试往往把实际结果和预期结果做对比,预期结果是按照详细设计文档或者接口文档来填写,而实际结果是每次调用接口返回结果。
@ycyzharry: 好的,谢谢