作为测试人员的两项基本功，编写缺陷报告与设计测试用例。 之前已分享过编写缺陷报告的方法及格式注意事项，这里分享下设计测试用例的设计方法与技能。
首先，做好设计前准备工作
通读整篇测试计划文档，一般情况下测试计划中会包含测试需求及细分的功能点，以及测试策略，设计用例的颗粒度，以及相关测试成员的分工明细等等。
如果是在大型项目中，要先了解自己负责的模块，并重点关注。其他模块也要了解，但知道其核心流程即可。无需扒细节。一方面可以通过了解全局测试需求知道自己的模块处于整体中的哪部分，与其他各模块分别有怎样的依赖关系 ，另一方面集成测试设计场景时可以做到融会贯通，保证需求覆盖率。
如果是独立负责一个小型项目或产品，则需要考虑到软件结构、网站架构等，以及一些开发运维中的技术（一般初入职时都会有老人带领熟悉架构知识，善于总结，快速了解）如容器技术、云计算、云平台技术等等。
通过以上参考文档，再加上从PM、需求人员、项目经理、用户、开发人员以及其他利益相关者的口头转述、聊天中获取到的关于该项目的点点滴滴，汇集成自己的测试草稿或测试想法列表，仅供自己查阅。
此外，之前的新人如何准备黑盒测试中也提到过，初入职时要先了解公司内部的测试文档，其中包括测试用例文档、缺陷报告文档等。用例的格式规范上一定要与公司统一，可以提前准备好工具。
接下来就可以正式进入用例编写阶段了，下面介绍一些注意事项。
用例标题
用例标题要简洁清楚地描述出要验证的目标，不能缺少一些必要文字或含错别字。
前置条件
描述清楚，对于依赖上个功能的用例，可以直接写进入到某个模块 ，不要从头写起。
举例：
前置条件：
账号登录 2.网络正常
或 未开启位置权限
用例步骤
每个步骤用序号标出，清楚描述步骤，不能有歧义。
输入数据一定要保证准确、对于特殊需求的数据，要使用客户提供的数据。另外，如果测试数据为某个范围的值 ，一定要写清楚范围，确定边界值。
在交叉测试阶段会有其他成员参考自己的测试用例文档，所以要说明清楚 。
预期结果
预期结果一定是可判性的，同时理论上每个步骤都应有对应的预期结果，在预期结果中对应标出。
其他项
其他项可以根据公司内部的需要自行完成。
另外，对于集成测试，一般会有相应的集成测试设计者，但在前期设计时可以与其他成员商议好，避免出现冗余的测试用例。设计用例时，要根据不同的测试类型来确定颗粒度，如冒烟测试、界面测试、功能测试、接口测试、场景测试等等。同时能够结合其他同类单竞品应用来深入研究被测产品在技术或功能以及影响用户体验的局限性，这样在前期设计用例时就可以规避一些编码阶段的风险。
