携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第39天，点击查看活动详情
对于一个人的测试团队，你可以做的事情：
-
确定一个合适的 Bug 工具，跟团队约定好，Bug 提交的边界、Bug 级别定义。
-
Bug 提交的边界：什么样的 Bug 可以不提交
-
跟团队协商准入准出标准（准入标准比较难做，准出标准会好一点）
-
跟进每一个线上 Bug（可以看得出来，Bug 是这里的核心资产）
-
每个版本上线后，一定要去回归测试一遍
-
不用写测试用例，基本上没人看，但可以用 xmind 写测试点让测试思路更清晰
-
不用写测试计划，但是可以整理自己的每一个任务的开始结束时间以及开发责任人
-
报告要写，但不需要写得太详细。甚至可能不用写日报，但建议还是写写。
-
很可能没有用例评审活动
核心原则是：
-
放弃所有的 UI 自动化测试和接口自动化测试
-
放弃繁杂的测试流程，把更多的精力放在业务测试上（用足数据验证功能的正确性）
核心原则上：系统上线后，Bug 尽量少，尽量避免漏测。一些可以省的流程，都可以省去。人少，最第 10 页 / 共 50 页
高效的方式是：线下沟通交流，少做一些文档。
最后衷心建议：一个人的测试团队，熟悉了软件测试的基本过程和业务知识，就可以离开了。
编写高质量的缺陷清单的核心是缺陷的标题、详细描述和截图一定要写好，严重级别和优先级等其他
要素需要进行合适的定义
详细描述：也就是禅道中的重现步骤。编写详细描述的原因是开发可以通过重现步骤去定位和发现问
题所在，让开发可以按照我们的步骤进行重现。编写规范为：重现步骤中除了需要明确写出我们做了什么
操作，还需要写出用了什么测试数据，甚至测试的环境说明以及测试时所用到的账号。
标题：开发和测试人员在查看缺陷的时候，最先看到的是标题。标题的写作规范为：核心的测试过程
+错误说明
截图：要求是每个缺陷都应该有相应的截图，截图的要求是：截大图以方便展示更多信息，其次截图
上要有文字说明。
