接口测试用例
接口测试用例案例
接口测试用例案例一、接口名称。
登录接口。
二、接口功能描述。
这个接口就是让用户能够登录到我们超酷的系统里，就像给你一把钥匙打开宝藏大门一样。
三、测试用例。
1. 用例编号：TC 001。
用例名称：正确用户名和密码登录。
测试步骤。
打开登录页面（假装咱能看到这个页面哈）。
在用户名输入框里输入“超级大侠”，这个可是提前注册好的合法用户名哦。
在密码输入框里输入“123456abc”，这也是对应的正确密码。
然后点击登录按钮，就像按下发射火箭的按钮一样期待着登录成功。
预期结果。
页面跳转到用户的个人主页，显示“欢迎回来，超级大侠”，而且在页面的某个角落能看到用户的小头像或者用户名啥的，证明咱真的登录成功啦。
2. 用例编号：TC 002。
用例名称：错误用户名正确密码登录。
测试步骤。
同样先来到登录页面这个“战场”。
在用户名输入框输入“乱编的名字”，这名字系统肯定不认。
在密码输入框输入“123456abc”，密码是对的，但用户名是错的呀。
再点登录按钮，看系统怎么反应。
预期结果。
页面弹出一个提示框，上面写着“用户名不存在，请重新输入”，就像一个小保安把你拦在门外，告诉你走错门啦。
3. 用例编号：TC 003。
用例名称：正确用户名错误密码登录。
测试步骤。
登录页面又出现啦。
在用户名输入框输入“超级大侠”。
在密码输入框输入“完全错误的密码111111”。
最后点击登录按钮，看系统是不是很聪明能发现密码不对。
预期结果。
页面弹出提示框，写着“密码错误，请重新输入”，就好像系统在对你说“你这密码不对呀，再好好想想”。
4. 用例编号：TC 004。
用例名称：空用户名和空密码登录。
测试步骤。
进入登录页面。
啥也不填，直接就去点登录按钮，这就有点耍赖啦。
预期结果。
页面弹出两个提示框，一个在用户名输入框旁边说“请输入用户名”，另一个在密码输入框旁边说“请输入密码”，就像系统在喊“你不能啥都不告诉我就想进来呀”。
服务端测试---接口测试用例设计
服务端测试---接⼝测试⽤例设计服务端测试主要分为三⼤类：web端或app的服务端接⼝测试；对更后端的数据库、缓存系统、中间件等进⾏测试；异常测试、稳定性测试、性能测试等。
app业务接⼝常见有：数据保存、数据查询、数据状态操作接⼝测试更多可以理解为前后端的数据交互是否按所约定的协议进⾏，包括字段以及字段的准确性。
测试⽤例设计参考⽂档：产品需求⽂档、接⼝协议⽂档、数据库表结构设计等。
接⼝测试⽤例设计⽅式⽅法有：针对输⼊:因为输⼊是由客户端提交的，客户端是否按协议提交参数接⼝侧是⽆法控制的，此时针对输⼊测试⽤例需考虑：按照参数类型进⾏设计、⾮法传参的健壮性及稳定性；针对接⼝处理逻辑:依据产品业务定义进⾏⽤例设计针对接⼝输出:针对输出结果（数据操作以及接⼝返回response）进⾏分析设计。
关于输⼊的⽤例设计：接⼝⽂档⼀般都会标明参数类型及长度，是否必选项等异常的参数校验有必要做那么多吗？例如，在购物商城中，客户端和后台的接⼝，需要要做充分的异常测试。
协议通常有加密，但是因为商城有利益可图，总有⼀些⼈去攻击，那么⼀旦攻击成功，就可以绕过客户端直接访问后台接⼝，如果后台逻辑有漏洞，就有利可图了。
还有，⼀些提供给外部使⽤的接⼝，也需要做好异常测试，因为你不清楚调⽤者会怎么使⽤，那么作为⼀个可靠的提供⽅，保证⾃⼰的稳定和健壮是⾮常有必要的。
另外⼀些情况，可能这些异常是外部⽆法触发的，那么这种情况下，异常问题就没有那么⾼的优先级去解决。
测试中，通常需要去权衡测试成本和产品质量，找到⼀个平衡点。
⽤例设计-接⼝逻辑约束条件分析操作对象分析状态转换分析时序分析操作对象分析：测试点针对合法或不合法的对象进⾏设操作如：登录帐号A，查看帐号B的数据，风险：个⼈数据隐私或是安全性。
状态转换分析：业务状态规定流转必须为A>B>C，测试点需关注能否产⽣A>C，或C>A等情况，避免流程漏洞带来利益损失。
（商城订单较常见）时序分析（更多地可以理解为业务流转流程）：主要为某业务涉及多个接⼝，⾮顺序执⾏导致数据异常或正常数据⽆法写⼊的情况⽤例设计-输出针对输出结果成功接⼝response返回字段的准确性；客户端流程是否正常；数据更新操作的准确性（数据库、缓存等）；失败异常错误是否有捕获处理；异常流程是否有明确的状态码返回；如：1001 = 服务异常1001 = w4ParseResult是null接⼝处理时间超时未返回未进⾏超时处理，导致整个流程阻塞；超时错误返回服务端处理超时，但返回处理成功；⽤例设计还需要考虑其他，⽐如：接⼝兼容性（兼容新旧版本app）接⼝字段是否冗余数据保存是否重复，冗余接⼝功能重叠度。
测试用例的颗粒度划分
测试用例的颗粒度划分在软件测试中，测试用例的颗粒度划分是非常重要的，它直接影响到测试的覆盖率和效果。
一个好的测试用例应该能够尽可能地覆盖到软件的各个功能和边界情况，以确保软件的质量和稳定性。
而测试用例的颗粒度划分就是将软件的各个功能和边界情况拆分成一个个小的测试点，以便进行详细的测试。
一、整体功能测试用例的颗粒度划分整体功能测试用例是对软件的整体功能进行测试的，它是测试用例的最高颗粒度。
在整体功能测试用例中，可以包括软件的各个功能模块、功能点和交互操作等。
例如，在一个电商网站的整体功能测试用例中，可以包括用户登录、商品浏览、购物车管理、订单管理、支付功能等。
二、模块功能测试用例的颗粒度划分模块功能测试用例是对软件的各个模块进行测试的，它是测试用例的中等颗粒度。
在模块功能测试用例中，可以包括模块的各个功能点、输入输出和异常情况等。
例如，在一个电商网站的用户登录模块功能测试用例中，可以包括正确的用户名和密码登录、错误的用户名和密码登录、用户名为空登录等。
三、接口测试用例的颗粒度划分接口测试用例是对软件的各个接口进行测试的，它是测试用例的较小颗粒度。
在接口测试用例中，可以包括接口的输入输出、参数验证、异常情况等。
例如，在一个电商网站的支付接口测试用例中，可以包括正常支付、支付金额为空、支付密码错误等。
四、边界测试用例的颗粒度划分边界测试用例是对软件的边界情况进行测试的，它是测试用例的最小颗粒度。
在边界测试用例中，可以包括边界值、边界条件和边界情况等。
例如，在一个电商网站的商品库存管理功能的边界测试用例中，可以包括库存为0、库存为1、库存为最大值等。
五、异常测试用例的颗粒度划分异常测试用例是对软件的异常情况进行测试的，它是测试用例的较小颗粒度。
在异常测试用例中，可以包括各种异常情况和错误处理等。
例如，在一个电商网站的订单管理功能的异常测试用例中，可以包括订单不存在、订单已取消、订单已完成等。
六、性能测试用例的颗粒度划分性能测试用例是对软件的性能进行测试的，它是测试用例的较小颗粒度。
根据接口文档编写测试用例
根据接口文档编写测试用例
摘要：
1.接口文档的重要性
2.编写测试用例的目的
3.接口测试用例的分类
4.编写接口测试用例的步骤
5.实践案例分析
正文：
接口文档是开发和测试人员的重要参考资料，它详细描述了接口的功能、输入输出参数、返回值、异常处理等信息。
编写测试用例的目的是为了保证接口的正确性和稳定性，提高软件质量。
接口测试用例可以根据不同的需求进行分类，如功能测试用例、性能测试用例、安全测试用例等。
功能测试用例关注接口的功能是否正确实现，性能测试用例关注接口的响应速度、吞吐量等性能指标，安全测试用例关注接口的安全性，如输入验证、防止SQL 注入等。
编写接口测试用例的步骤如下：
1.分析接口文档：仔细阅读接口文档，理解接口的功能、输入输出参数、返回值、异常处理等信息，为编写测试用例做好准备。
2.确定测试用例的输入数据：根据接口文档中描述的输入参数，确定测试用例的输入数据。
输入数据可以分为有效数据、无效数据、边界数据等类型，以覆盖不同的测试场景。
3.确定测试用例的预期输出：根据接口文档中描述的返回值和异常处理，确定测试用例的预期输出。
预期输出可以分为正确输出、错误输出、异常输出等类型，以覆盖不同的测试场景。
4.编写测试用例：根据确定的输入数据和预期输出，编写具体的测试用例。
测试用例可以采用等价类、边界值、组合等方法进行设计，以提高测试用例的覆盖率和可读性。
5.执行测试用例：将编写好的测试用例执行，检查实际输出是否与预期输出一致，以验证接口的正确性和稳定性。
通过以上步骤，我们可以编写出有效的接口测试用例，保证软件的质量。
24 软件接口测试用例-GJB438C模板
编号：版本：状态：密级：分发号：XX软件接口测试用例编制/日期：审核/日期：标审/日期：会签/日期：批准/日期：XX科技有限公司20XX年X月文档修订记录目录1范围 (1)1.1标识 (1)1.2系统概述 (1)1.3文档概述 (1)2引用文档 (1)3测试准备 (2)3.1硬件准备 (2)3.2软件准备 (2)3.3其他测试前准备 (2)4测试说明 (3)4.1测试用例编号规则 (3)4.2测试用例列表 (3)4.3测试用例 (3)5需求的可追踪性 (8)6注释 (9)1范围1.1标识【注释：本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
】1.2系统概述【注释：本条应概述本文档所适用的系统和软件的用途。
描述系统与软件的一般特性（如规模、安全性、可靠性、实时性、技术风险等特性）；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构等；标识当前和计划的运行现场；列出其他有关文档。
】1.3文档概述【注释：本条应概述本文档的用途和内容，并描述与它的使用有关的安全保密方面的要求。
】2引用文档【注释：本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应给出不能通过正常渠道得到的文档的来源。
】3测试准备3.1硬件准备【注释：本条应描述测试工作所需的硬件准备规程。
有关这些规程，可以引用已发布的操作手册。
（若适用）应提供以下内容：a）用名称和（若适用）编号标识要使用的特定硬件；b）所有连接硬件所有的开关装置和电缆；c）说明硬件、互联控制和数据路径的一个或多个图示；d）使硬件处于就绪状态的逐步的操作说明。
】3.2软件准备【注释：本条描述准备被测项、相关软件以及数据的必要规程。
有关这些规程，可以引用已经发布的软件手册。
（若适用）应提供下述信息：a）测试中要使用的特定软件；b）被测项的存储介质（如光盘、磁盘）；c）所有相关软件（如模拟器、测试驱动程序、数据库）的存储介质；d）加载软件的说明，包括所需的顺序；e）多个测试用例共用的软件初始化说明。
idea接口测试用例 -回复
idea接口测试用例-回复什么是接口测试用例？在软件开发中，接口测试用例是一种用于验证软件系统接口是否能够正确地传递和处理数据的测试方法。
接口测试是系统测试的一个重要组成部分，它关注的是不同软件模块或系统之间的交互是否符合预期。
接口测试用例通常包括测试输入和输出的数据格式、数据传输的可靠性、异常处理的有效性以及接口性能等方面。
为什么需要接口测试用例？在开发大型软件系统时，不同的模块往往由不同的开发人员或开发团队负责。
这些模块必须能够相互协作，以实现整个系统的功能。
接口测试用例的目的是确保各个模块之间的接口定义和功能是正确和可靠的。
通过接口测试，可以及早发现和修正接口问题，避免在集成测试或系统测试阶段出现严重的错误。
编写接口测试用例的步骤：1. 确定接口测试范围：在编写接口测试用例之前，需要明确接口测试的范围。
这包括确定待测试的接口、需要覆盖的输入输出情况和所需的测试工具等。
确定测试范围的关键是深入理解系统架构和接口定义。
2. 设计测试数据：接口测试用例的有效性依赖于设计合适的测试数据。
测试数据应该包括正常的输入数据、边界值数据和异常数据。
正常的输入数据用于验证接口在正常情况下是否能够正确处理数据。
边界值数据用于验证接口在极限情况下的行为。
异常数据用于测试接口对异常情况的处理是否正确。
3. 编写测试用例：根据接口测试的目标和设计的测试数据，编写相应的测试用例。
每个测试用例应该包括输入数据、预期输出和实际输出等部分。
测试用例应该覆盖所有可能的情况，并且保证测试的全面性和有效性。
4. 执行测试用例：在执行测试用例之前，需要准备好测试环境和工具。
测试环境应当与实际生产环境尽可能接近，以保证测试结果的真实性。
测试工具可以帮助自动化测试用例的执行和结果的分析。
5. 分析测试结果：在执行测试用例后，需要对测试结果进行分析和评估。
对于每个测试用例，需要比较预期输出和实际输出，如果有差异则需要记录下来并进行错误分类和跟踪。
自动生成接口测试用例
自动生成接口测试用例全文共四篇示例，供读者参考第一篇示例：自动生成接口测试用例是指通过自动化工具或脚本来生成接口测试用例，以提高测试效率和覆盖度。
接口测试是软件测试中的一个重要环节，主要是测试系统各个模块之间的数据传输是否正确、接口调用是否符合规范、数据格式是否正常等。
接口测试用例的编写是接口测试工作的核心内容之一，其质量和覆盖度直接影响着接口测试的效果和结果。
在传统的软件测试中，很多测试工作都是依靠人工来完成的，包括编写测试用例、执行测试用例、分析测试结果等。
但是随着软件的规模和复杂性不断提升，人工测试的效率和准确性都面临着挑战，特别是在接口测试中，需要测试大量的接口和数据组合，人工编写和执行测试用例的工作量较大，容易出现疏漏和遗漏。
自动生成接口测试用例成为了一种新的测试方法，能够提高测试效率和质量，缩短测试周期，降低测试成本。
自动生成接口测试用例的主要优势包括：1. 提高测试效率：自动生成接口测试用例可以快速生成大量的测试用例，覆盖接口的各种输入和输出情况，减少人工编写测试用例的时间和工作量。
2. 提高测试覆盖度：自动生成接口测试用例可以对接口的各种情况进行全面覆盖，包括正常输入、异常输入、边界条件等，确保接口测试的全面性和准确性。
4. 提高测试质量：自动生成接口测试用例可以避免人为因素对测试用例的质量产生影响，确保测试用例的完整性、准确性和一致性。
自动生成接口测试用例的实现方法主要有两种：基于规则生成和随机生成。
基于规则生成是指根据接口的规范和要求，通过设定一定的规则和条件，自动生成符合规则的测试用例。
可以根据接口的参数类型、取值范围、数据格式等，来生成各种情况下的测试用例。
随机生成是指通过随机数生成器来随机生成测试数据，模拟各种情况下的输入和输出，以检验接口的稳定性和健壮性。
自动生成接口测试用例的实现工具有很多，包括开源工具和商业工具。
常用的开源工具有Postman、SoapUI、Rest Assured等，这些工具提供了丰富的接口测试功能和插件，可以支持接口测试的各个环节。
软件测试报告接口测试用例与结果
软件测试报告接口测试用例与结果软件测试报告：接口测试用例与结果1. 概述在软件开发过程中，接口测试是非常重要的一环。
本文旨在对接口测试用例与测试结果进行分析与总结，以评估接口的功能完整性、数据传输准确性和稳定性。
2. 测试环境2.1 硬件环境- 操作系统：Windows 10- 处理器：Intel Core i7-8700- 内存：16GB2.2 软件环境- 开发语言：Java- 集成开发工具：Eclipse- 测试工具：Postman3. 接口测试用例设计3.1 用例一：用户登录接口- 功能描述：测试用户登录接口- 输入数据：用户名和密码- 预期结果：返回登录成功信息- 实际结果：登录成功，接口响应时间为500ms3.2 用例二：添加商品接口- 功能描述：测试添加商品接口- 输入数据：商品信息- 预期结果：返回成功添加商品的信息- 实际结果：成功添加商品，接口响应时间为800ms3.3 用例三：获取订单列表接口- 功能描述：测试获取订单列表接口- 输入数据：无- 预期结果：返回订单列表信息- 实际结果：成功获取订单列表，接口响应时间为1s4. 接口测试执行在测试过程中，通过Postman工具对接口进行了测试，按照测试用例进行了多次执行，并记录了每次执行的结果。
4.1 用户登录接口测试结果- 第一次执行：成功登录，接口响应时间为500ms- 第二次执行：成功登录，接口响应时间为450ms- 第三次执行：成功登录，接口响应时间为400ms4.2 添加商品接口测试结果- 第一次执行：成功添加商品，接口响应时间为800ms- 第二次执行：成功添加商品，接口响应时间为700ms- 第三次执行：成功添加商品，接口响应时间为750ms4.3 获取订单列表接口测试结果- 第一次执行：成功获取订单列表，接口响应时间为1s- 第二次执行：成功获取订单列表，接口响应时间为900ms- 第三次执行：成功获取订单列表，接口响应时间为950ms5. 测试结果分析通过对接口的多次执行测试，我们可以得出以下结论：- 用户登录接口的响应时间相对较快，平均为450ms，符合预期；- 添加商品接口的响应时间在700-800ms之间，可以优化接口性能，减少响应时间；- 获取订单列表接口的响应时间在900-1000ms之间，可以进一步优化接口性能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
备注
7.2.2
编制人
薛郝
审定人
时间
用例名称
同步数据
接口名称
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
应用程序能否成功同步数据
接口方法名
getUserByAppCode
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
能够返回正确的新增、撤销、变更组织的信息。成功同步数据。
符合预期结果
通过
4
指定组织下的用户管理
通过接口管理指定组织下的用户，输入所有必填字段。
1.用户信息<user>不为空，不为null；
2.组织信息<org>不为空，不为null。
能够返回正确的开户、销户、更新用户的信息。成功同步数据。
符合预期结果
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
测试通过该接口能否成功更新一个组织
接口方法名
updateOrg
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
备注
9
正确更新一个组织
输入所有必填字段。
1.组织编号<orgCode>不为空，不为null；
时间
用例名称
删除用户
接口名称
urn:userservice
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
测试通过该接口能否成功在指定组织下添加一个用户
接口方法名
deleteOrg
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
4
上级组织编号Biblioteka 空上级组织编<parentOrgCode>为空，为null；其他四项不为空，不为null。
无法返回正确结果。
符合预期结果
通过
5
组织类型为空
组织类型<orgType>为空，为null；其他四项不为空，不为null。
无法返回正确结果。
符合预期结果
通过
6
组织排序位为空
组织排序位<orderNum>为空，为null；其他四项不为空，不为null。
addUser
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
备注
15
正确在指定组织下添加一个用户
输入所有必填字段。
1.用户信息<user>不为空，不为null；
2.组织信息<org>不为空，不为null。
返回正确结果；数据库中更新组织信息正确。
符合预期结果
通过
16
正确在多个指定组织下添加同一个用户
输入所有必填字段。
getGxDate
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
备注
1
正确注册一个构型数据
按照顺序依次输入所有必填字段。所有输入元素不为空，不为null；
返回正确结果；数据库中注册组织信息正确。
符合预期结果
通过
备注
组织编号<orgCode>为空，为null；其他四项不为空，不为null。
无法返回正确结果。
符合预期结果
通过
11
组织名称为空
组织名称<orgName>为空，为null；其他四项不为空，不为null。
无法返回正确结果。
符合预期结果
通过
12
上级组织编号为空
上级组织编<parentOrgCode>为空，为null；其他四项不为空，不为null。
接口测试用例
7.1 总部用户同步接口
编制人
薛郝
审定人
时间
用例名称
添加组织
接口名称
urn:orgservice
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
测试通过该接口能否正确添加一个组织。
接口方法名
addOrg
用例编号
2.组织名称<orgName>不为空，不为null；
3.上级组织编<parentOrgCode>号不为空，不为null；
4.组织类型<orgType>不为空，不为null；
5.组织排序位<orderNum>不为空，不为null。
返回正确结果；数据库中更新组织信息正确。
符合预期结果
通过
10
组织编号为空
无法返回正确结果。
符合预期结果
通过
备注
7.1.3
编制人
薛郝
审定人
时间
用例名称
删除组织
接口名称
urn:orgservice
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
测试通过该接口能否成功删除一个组织
接口方法名
deleteOrg
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
备注
7
删除组织
输入所有必填字段。
组织编号<orgCode>不为空，不为null。
返回正确结果；数据库中正确删除组织信息。
符合预期结果
通过
8
组织编号为空
组织编号<orgCode>为空，为null。
无法返回正确结果。
符合预期结果
通过
备注
7.1.4
编制人
薛郝
审定人
用例编号
步骤名称
输入
预期输出
实际输出
是否通过
备注
2
用户管理
通过接口管理用户，输入所有必填字段。
3.用户信息<user>不为空，不为null。
能够返回正确的开户、销户、更新用户的信息。成功同步数据。
符合预期结果
通过
3
组织管理
通过接口管理组织，输入所有必填字段。
1.组织信息<org>不为空，不为null。
备注
21
删除指定组织下的一个用户
输入所有必填字段。
用户ID<uid>不为空，不为null。
返回正确结果；数据库中更新组织信息正确。
符合预期结果
通过
22
用户ID为空
用户ID<uid>为空，为null。
无法返回正确结果。
符合预期结果
通过
备注
7.1.5
编制人
薛郝
审定人
时间
用例名称
更新组织
接口名称
urn:orgservice
返回正确结果，成功同步数据。
符合预期结果
通过
备注
7.3 构型数据的集成
编制人
薛郝
审定人
时间
用例名称
注册构型数据服务文件
接口名称
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
通过该接口能否成功注册构型数据文件
接口方法名
无法返回正确结果。
符合预期结果
通过
备注
7.2 应用系统同步用户接口
7.2.1
编制人
薛郝
审定人
时间
用例名称
接口名称
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
集成平台能否成功推送数据到应用系统
接口方法名
getSubOrgUserByTim
无法返回正确结果。
符合预期结果
通过
备注
7.1.2
编制人
薛郝
审定人
时间
用例名称
新增用户
接口名称
urn:userservice
项目名称
C919大型客机客户服务应用系统集成平台
编号/版本
参考信息
C919大型客机客户服务应用系统集成平台详细设计V2.1
测试目的
测试通过该接口能否成功在指定组织下添加一个用户
接口方法名
步骤名称
输入
预期输出
实际输出
是否通过
备注
1
正确添加一个组织
输入所有必填字段。
1.组织编号<orgCode>不为空，不为null；
2.组织名称<orgName>不为空，不为null
3.上级组织编<parentOrgCode>号不为空，不为null；
4.组织类型<orgType>不为空，不为null；
5.组织排序位<orderNum>不为空，不为null。
备注
1
成功同步数据
1.应用系统调用ESB上的webservice接口，发起请求；
2. ESB通过访问提供服务的webservice接口，在Web容器上的webservice实现时通过调用TDS或者DB把用户数据查询出来；