不知道大家有没有这样的感觉。就是那种遇到了一个很垃圾的测试的感觉。笔者饱受这种测试的折磨，已经到了不得不发文吐槽的地步。然而，一味的抱怨不能解决任何问题，最重要的还是要积极的解决问题，为此写一个模板，希望组内的测试能够看到。
1. 测试应该把用例写成这样
1.1. 前端认为，一个好的测试用例应该至少具备以下几个关键要素：
-
明确的测试目标：
- 测试用例应该清晰地指出其测试的目标，例如测试某个特定的功能、性能或者安全特性。
-
可重复的步骤：
- 测试用例中应该包含一系列清晰、具体的步骤，以便任何执行测试的人都能按照这些步骤来重现测试。
-
预期的结果：
- 测试用例应该明确说明在执行了测试步骤后预期会得到什么样的结果。这有助于判断测试是否通过。
-
实际结果的记录：
- 在执行测试后，应记录实际的结果，以便与预期结果进行对比。
-
前置条件和后置条件：
- 测试用例应明确测试执行前需要满足的条件（前置条件），以及在测试执行后应该如何恢复环境（后置条件）。
-
测试数据：
- 如果测试需要特定的数据输入，测试用例应该包含这些数据或者提供获取这些数据的方法。
-
清晰的标识和分类：
- 测试用例应该有唯一的标识符，并且应该根据需要进行分类，如功能测试、性能测试、安全测试等。
-
可读性和可维护性：
- 测试用例应该写得清晰易懂，方便其他测试人员理解和执行。同时，当需求变更时，测试用例应该容易更新和维护。
1.2. 考虑到测试同学的接受能力，这里提供了一份样板供其参考：
测试用例编号：TC-001
测试目标：验证登录页面的用户名和密码输入框功能是否正常。
前置条件：测试环境已搭建完毕，测试数据已准备。
测试步骤：
- 打开登录页面。
- 在用户名输入框中输入有效的用户名。
- 在密码输入框中输入对应的密码。
- 点击“登录”按钮。
预期结果：
- 用户能够成功登录，并跳转到个人主页。
实际结果：（在执行测试后填写）
- 用户成功登录并跳转到个人主页，与预期结果一致。
后置条件：测试结束后，退出登录并清除测试数据。
备注：无
1.3. 考虑到测试的冥顽不灵，这里需要解释一下为什么要这样写
这个测试用例简洁明了，包含了测试目标、清晰的步骤、预期结果和实际结果的记录，以及前置条件和后置条件的说明。这样的测试用例可以确保测试的准确性和可重复性。
2. 测试应该这样提 BUG
2.1. 前端认为测试同学提的 BUG 应该至少包括下面的内容：
当测试用例不能通过时，前端开发者希望测试人员提交的bug报告能够清晰、具体，并提供足够的信息以便快速定位和解决问题。以下是一个bug报告的基本格式和示例：
Bug报告格式：
- Bug标题：简短、明确地描述bug的核心问题。
- 发现人：填写发现此bug的测试人员姓名。
- 发现日期：记录发现bug的日期。
- Bug描述：
- 详细描述bug的现象。
- 说明测试时执行的操作步骤。
- 如果有的话，提供bug出现的频率（偶尔、经常、总是等）。
- 重现步骤：提供能够重现bug的详细步骤。
- 期望结果：描述在正常情况下应该出现的结果。
- 实际结果：描述实际出现的结果。
- 截图/视频：如果可能，附上bug发生时的截图或视频。
- 浏览器/设备信息：提供测试时使用的浏览器版本、操作系统等信息。
- 优先级：根据bug的严重程度和影响范围，给出bug的优先级。
- 指派给：指明这个bug应该由哪位开发人员处理。
2.2. 同样考虑到其接受能力比较差，这里也给一个例子
Bug报告示例：
Bug标题： 登录页面用户名输入框存在显示异常
发现人： 张三
发现日期： 2023-04-15
Bug描述： 在登录页面输入用户名时，如果用户名长度超过10个字符，输入框会出现显示异常，用户名文本会被截断，且没有出现滚动条或提示信息。
重现步骤：
- 打开登录页面。
- 在用户名输入框中输入一个长度超过10个字符的用户名（例如：“abcdefghijklm”）。
- 观察用户名输入框的显示情况。
期望结果： 用户名输入框应该能够正常显示所有输入的字符，或者当字符数超过一定长度时，给出相应的提示信息。
实际结果： 用户名输入框中的文本被截断，且没有滚动条或提示信息出现。
截图/视频： [附加截图或视频文件]
浏览器/设备信息： 浏览器：Chrome 90.0.4430.212 操作系统：Windows 10
优先级： 高
指派给： 李四（前端开发）
这样的bug报告格式清晰明了，包含了足够的信息，有助于前端开发者快速定位和解决问题。
最后希望我们组的测试能够在掘金上看到这篇文章。在现实中碍于团结不好怼，但是还是希望他早日回头，回头是岸呐！
