确定为什么测和测到什么程度

在写任何用例前，先团队内达成以下共识：

定义质量目的：问自己：软件最重要的3个方面是什么？ 是功能完全正确？界面流畅不崩溃？还是数据处理精确？如：

算法研究类：结果精确性和计算性能是重要，界面美观是次要。

应用开发类：重要功能流程和用户界面可用性是重要。

结题演示：演示场景的稳定性和界面交互流畅度是重要。

识别风险：

时间：距离结题/演示还剩多少天？能分配给测试的时间占比多少？（学生项目建议至少预留20-30%时间用于测试和修复）。

人力：谁负责测试？是开发人员交叉测试，还是有专门的测试同学？

技术：团队是不是熟悉自动化测试工具？如果不熟悉，前期优先采用高效的手动测试，后期对重要功能尝试简单自动化。

环境：是不是有独立的测试环境？至少应做到和开发环境分离。

计划创建填写测试计划最小可行框架

1. 测试范围：测什么？不测什么？

确定包含：列出必须测试的重要模块（如：登录注册、数据上传、重要算法计算、结果导出）。

确定排除：写明暂不测试的部分（如：在IE浏览器下的兼容性、每秒上万并发的高负载）。

2. 测试方法：怎么测？

针对每个模块，定义方法：

- 功能测试：主要方法。证实功能是不是按需求工作。

- 性能测试（如涉及）：用工具（如JMeter）测单用户响应时间和负载。

- 兼容性测试：在最常用的1-2种浏览器或系统版本上测试。

3. 资源和进度：谁？用什么？何时？

人员：确定每位成员的测试职责（如：A同学负责后端API测试，B同学负责前端界面测试）。

环境：列出测试所需的软件、硬件、测试账号。

设定几个时间点（如：第一轮功能测试完成日、 Bug修复冻结日、最后回归测试日）。

4. 交付物和通过标准 怎样算完成？

交付物：一份测试用例执行记录、一个Bug清单、一份简单的测试总结报告。

通过标准：团队共同认可即可，如：“所有‘高’优先级Bug已修复，重要功能用例100%通过”。

计划执行让计划活起来

计划是执行和调整。

设计测试用例：

从用户场景出发：不要罗列所有输入组合。思考用户会怎么用，测试典型途径和最可能出错的异常途径。如，测试登录功能，重点测：正确登录、密码错误、网络中断。

利用等价类和边界值：这是最高效的黑盒测试方法。如，测试一个输入1-100分数的字段，测试：-1（非法）、0（边界）、1（边界）、50（典型）、100（边界）、101（非法）。

管理Bug流程：

使用在线协作文档（如腾讯文档、语雀）或看板（如Trello） 建立一个简单的Bug清单。每个Bug记录：标题、重现步骤、严重程度（高/中/低）、修复状态。

每日站会同步：花5分钟同步：我昨天发现了什么Bug？我今天打算测什么？有什么阻塞问题？这能极大提升效率。

保持计划的弹性：

每周回顾一次计划。需求变了吗？进度滞后了吗？测试重点需要调整吗？