测试用例留言板怎么写

要根据具体实现的功能需求和设计来写具体的测试用例。一般来说留言板功能分前台显示和后台控制。前台主要是留言内容信息的显示，显示内容是否正确，布局效果，排序方式是否合理等。

一、测试用例留言板

要根据具体实现的功能需求和设计来写具体的测试用例。
一般来说留言板功能分前台显示和后台控制。
前台主要是留言内容信息的显示，显示内容是否正确，布局效果，排序方式是否合理，用户留言是否可正确操作，被屏蔽留言是否不显示。
后台主要是对留言记录的控制，如屏蔽和解除屏蔽，回复留言，已审核或已查看。（这个要根据实际功能实现情况）

二、测试用例编写

1. 某个用例的测试目的是什么

在进行接口测试脚本的编写前，我们应该明确这批脚本的预期目标在哪里，是为了验证什么内容。根据个人的经验，一般会把接口用例分成三类：

单接口验证：以验证接口参数、权限、返回值为主，保证接口“能用”，这类用例一般在接口设计定稿后，配合Mock服务就可以完成用例编写；
场景逻辑验证：以用户场景为基础，验证接口间的参数传递及业务流程能够正常流转，用例复杂度较高，需要非常熟悉业务与接口之间的关系。这是接口测试最核心的价值。
异常验证：主要验证参数异常、逻辑异常等情况下，接口是否能处理并给出友好的错误信息。通常情况下，关注参数异常的场景会比较多，可以用等价类、边界值等方式来处理。需要注意的是多关注下异常的返回信息是什么，信息是否明确，提示是否友好等等。

2. 接口信息的来源

当我们明确好测试目标后，再开始编写测试用例，会有更针对性的去设计测试数据和接口组合。接下来的问题是什么呢？去哪里确认你的接口信息是有效的？基本上有两种路径：

接口文档：开发人员都不喜欢自己写文档，同时也很讨厌别人不写文档。所以测试人员如何获取一份真实有效的接口文档是件比较麻烦的事。般团队内都会有一个统一的接口文档管理工具（如果没有，就找开发多磨麿，让他们弄个，并不难），我们需要关注接口文档的有效性和及时性。现在也有很多的插件或者工具能够帮助研发人员自动生成接口文档，例如Swaager、apidoc等等。
接口抓包：如果什么都没有，那就自力更生，通过Fiddler之类的工具，通过抓包分析的方式来获取接口，这类的场景如果较多的话，可以把Fiddler抓到的接口导出，然后写个小程序，直接转成接口平台可以识别的脚本，效率会更高一些。

在获取到接口信息后，需要与开发人员多交流，明确参数的意义及来源，以便我们针对性的做测试用例设计，这个环节不要过多的自己猜（很多测试人员经常会自己猜想），直接找开发问就好了。在这个接段，还要梳理并区分接口的重要程度和优先级。这样就可以确认哪些接口优先设计用例，哪些接口可以先放放，在有限制的时间内，做最大价值的事。

3. 一些基本原则

拿到接口后，明确了参数说明，结合测试目标，我们就可以开始设计并编写测试用例了。区别于功能测试用例，接口测试用例（脚本）一些原则需要注意：

自动化：好像是废话，所有的用例应该是非交互试，最常见的就是Token之类的生成，需自动处理好（我见过每次执行用例前，需要自己手动生成Token再粘贴进去的脚本，特别是分环境执行的时候）。
独立性：每个用例应该是独立的，没有依赖的。需要在一个用例里处理好前置条件，而不是多个用例相互依赖。
可重复：用例测试可重复执行，所以需要注意参数的生成方式。
可持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。

延伸阅读：