定制软件开发的测试用例，可以由服务商测试人员牵头编写，需求人员和开发人员补充规则与技术边界，企业业务人员参与评审，指定负责人确认业务预期和验收要求。
具体分工可以根据团队规模调整。小型项目不一定设置独立测试岗位，但需要明确由谁编写、谁复核、谁执行和谁批准验收。企业参与确认，并不意味着企业需要承担全部测试工作。
测试用例的作用，是把已经确认的需求转化为可重复执行的检查方法。编写责任应与项目交付责任一起明确，避免开发完成后才临时讨论怎样证明功能已经做好。
把编写责任落实到具体人员
如果合同中只写"完成系统测试"，却没有负责人、输出材料和确认方式，实际执行时容易出现遗漏。
服务商可以指定测试负责人整理功能与流程用例，需求人员核对规则，开发人员提供接口、异常处理和技术限制。企业则安排业务代表确认场景和预期结果。
这些角色可以由不同人员承担，也可以在小团队中适当兼任。但编写用例、执行测试和批准验收是不同职责，不能仅凭一个人的口头说明全部完成。
对于共同编写的材料，也应指定统一维护人，管理版本、问题和评审记录。企业无需了解所有技术细节，但应知道本项目有哪些测试任务、由谁完成，以及最终提交什么证据。
业务规则需要企业与需求人员共同确认
测试用例写得是否正确，取决于预期结果有没有依据。
需求人员可以根据流程、原型和规则整理用例，但企业业务人员需要确认这些内容是否符合实际。例如，哪种申请需要增加审核、退回后能否修改、人员离职后任务由谁接收，都涉及企业管理决定。
如果规则尚未明确，应先列为待确认事项。测试人员不宜自行设定答案，再据此判断系统正确；企业也不宜在验收时才提出此前没有确认的新要求。
开发人员则应补充实现中可能出现的边界，例如重复请求、接口失败、异常数据和状态冲突。
评审时可以沿着一条完整业务逐步检查，让各岗位说明自己何时操作、看到什么数据、得到什么结果。这样更容易发现单个页面用例中遗漏的流程问题。
一条验收用例应让其他人能够复现
一条可执行的用例，通常需要说明对应需求、测试环境与版本、前置条件、账号角色、输入数据、操作步骤和预期结果。执行后再补充实际结果、证据和结论。
以一个假设的费用报销项目为例，企业确认的规则是：报销金额超过3000元时，部门负责人审核后还需要财务复核，申请人不能审批本人单据。
用例应先准备普通员工、部门负责人和财务三个角色，以及一笔金额为3500元的样例申请，并注明在约定的测试环境和版本中执行。
操作过程包括员工提交、负责人审核、财务复核。预期结果需要说明申请依次进入哪些状态、由哪个角色处理，以及财务复核前不能显示为最终通过。
执行时记录实际流转结果，保存单据编号、必要截图或日志，再判断本条是否通过。
还应补充正好3000元、低于门槛、退回修改和无权限审批等场景。这些用例共同验证规则，不能只用一笔顺利完成的申请代替全部测试。
专项测试按技术要求安排
企业业务人员适合验证流程、数据含义和实际操作，但部分检查需要具备相应能力的技术人员承担。
数据测试需要核对计算、关联和汇总，涉及迁移时还要比较前后结果。接口测试需要检查字段映射、异常重试和数据一致性，并取得必要的联调环境。
性能测试应使用约定的用户量、数据规模和资源条件；安全与权限测试需要验证未经授权的访问是否被限制；兼容性测试则要覆盖约定设备、浏览器和操作系统。
备份恢复应验证数据能否按要求恢复，重要操作可以在隔离环境中演练。交付资产检查则需要核对源码版本、部署资料、数据库及账号权限是否完整可用。
这些任务可以由服务商技术、测试人员或约定的专项团队负责，企业管理员和业务负责人配合确认。测试指标应来自项目要求，不能临时套用一个与业务无关的数字。
需求确认时建立用例，变更后同步更新
合同或需求确认阶段，应先约定验收范围、职责、测试条件和通过要求。详细用例可以随着流程、原型和技术方案逐步完善。
例如，原型评审时可以准备主要操作与权限用例，接口方案明确后补充联调用例，发布前再确认部署、备份和交付检查。
每条关键用例应能够追溯到相应需求，便于发现某项需求没有测试，或者测试内容已经超出约定范围。
需求发生变化后，用例、数据和预期结果也要更新。如果审批层级已经调整，测试材料仍使用旧流程，得到的结论就可能失去参考价值。
发布新版本时，还应确定需要重复验证的原有功能。只检查新增页面，容易遗漏修改对权限、报表或接口的影响。
执行、修复和复测分别留痕
用例准备好后，还要明确谁执行。服务商可以完成内部测试，企业使用人员参与业务验收测试，专项人员负责相应技术检查。
执行人应按照步骤记录实际结果，发现问题时说明环境、版本、数据、操作和影响。不能只写"功能有问题"，否则其他人员可能无法复现。
开发人员负责定位和修复，测试负责人安排复测。涉及业务规则的问题，还需要相关业务人员确认修复后的结果。
缺陷等级用于表达影响程度和处理优先级。例如，核心流程中断、重要数据错误或严重越权问题，通常需要优先处理。具体分级和验收影响应提前约定。
缺陷等级不能代替用例结论。问题修复后仍要重新执行相关检查，必要时回归其他受影响功能，并保留复测结果。
用测试结果支持验收决定
单条用例通过，只能说明该项检查符合预期。整个项目能否验收，还要结合范围覆盖、缺陷状态、专项结果和资料交付判断。
双方可以事先明确哪些关键用例必须通过，哪些缺陷需要关闭，以及一般遗留问题可以在什么条件下继续处理。不能只根据演示顺利或页面能够打开作出决定。
验收材料可以汇总用例版本、执行范围、通过情况、缺陷清单、复测记录和未解决事项。服务商说明交付结果，企业指定负责人依据证据确认。
企业业务代表、管理员和技术人员可以分别确认自己负责的部分，再由授权负责人形成验收意见。测试用例作者可以参与说明，但不必同时承担最终批准职责。
这些材料也应进入项目交接。后续维护或版本更新时，可以继续复用关键场景，并随着真实流程、角色、数据和接口变化持续调整。
常见问题
小项目没有专职测试人员，谁来写用例？
可以指定需求、开发或其他具备能力的人员承担，但要明确复核与执行责任，并由企业确认关键业务预期。
企业需要自己写完整测试用例吗？
不一定。企业主要提供真实业务、例外情况和样例数据，参与规则与验收确认；具体编写和技术测试应按项目分工落实。
用例由服务商编写，验收会不会失去独立性？
编写人与验收确认人可以不同。企业应评审关键场景和预期结果，并通过实际操作与证据确认，不能只接受服务商的自测结论。
需求变更后，测试用例需要重新写吗？
需要评估并更新相关用例，同时补充新增场景和回归范围。未受影响的内容可以复用，不必每次全部重写。