软件由数据+程序+文档组成。我们软件测试工程师，就是给执行程序输入数据，得到输出结果，并判断输出结果是否符合需求规格的过程，而文档就是我们工作内容的可视化。而测试用例，就属于文档的一部分。
测试的生命周期：测试计划 --- 测试方案设计 --- 测试开发 --- 测试执行 --- 测试评估，对测试结果的分析和报告。测试用例的编写与执行属于测试开发环节。
测试用例是测试工作的核心，是一组在测试时输入输出的标准，测试用例是软件需求的具体对照
测试用例的作用：检验软件是否满足客户的需求；体现一个测试人员的工作量；展现测试的设计思路，可以通过阅读别人的测试用例学习测试用例的设计方法和思路。
测试用例一般包含：编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。但可以根据实际需要增加、删除、修改部分项，比如：增加分类、子分类等。
这里需要注意，编号并不简单的是1、2、3、4这样子，而是可以通过下划线将一些测试用例的信息包含进去，比如：TV_YUYIN_0001，代表着这条测试用例时测试电视语音相关的；用例名称是用例的名字，这个可以不写；测试背景是说明该测试用例的背景，是测试什么项目、什么内容的，也可以不写，有时候测试背景通过测试编号、测试文件的名字、标题等就可以表达出来；前置条件是测试之前应该满足什么条件才可以进行测试，一般要写，如果没有前置条件写无就可以；优先级和重要级看似差不多，其实关系不大，优先级高并不意味着重要级高；测试数据是指输入的数据；测试步骤是必须的，可以根据实际情况写测试步骤，可以写的粗糙，也可以写的很详细，比如第一步是什么，第二步是什么等；预期结果对应着测试步骤，如果测试步骤写的很详细，那么预期结果也要详细，比如测试步骤有5步，预期结果有2个，别人怎么知道这个结果是哪一步产生的？最好在编号上实现预期结果和操作步骤的统一；实际结果就是在测试过程中的实际情况，如果一样就写通过、OK等就可以了，如果不一样，需要写明实际结果是什么。有时候，我们可以在实际结果中写OK、false，然后将实际结果写在备注里，也没有问题。
测试用例的编写流程：需求分析、提取测试点、编写测试用例、测试用例的评审
需求就是客户需要的东西和客户对其的要求。如果这款产品的用户就是直接面向大众的，那么就需要自己去分析大众用户需要的是什么，怎样的功能才能让用户喜欢用。
一般需求分为业务需求、用户需求、功能需求。
如果没有需求怎么办？直接给你一个软件直接测试怎么搞？我们可以参考市面上同类型的产品；
如果需求模糊怎么办？这个小编就经常遇到，产品经理提出来的需求往往只有几句话概括，这时候我们可以整理好已有的需求，把不明白的地方提出来，和相关的负责人确认，又或者参考同类型的产品实现的情况。也可以拿到产品后，进行探索性测试，去探索相关的功能需求，边测试边学习，验证看是否满足了业务，实在不明确的再进行确认，但这样会有风险，如果你和开发理解的一样，但恰巧你们都理解错了，那么可能做出来的东西就不是产品经理需要的东西了。
测试点是通过需求分析后对得出的需要测试的具体内容
将测试点总结完毕，就可以根据测试点快速的写测试用例，并可以很好的覆盖需求
评审就是对测试用例进行检查，包括同行评审、小组评审、部门评审、三方评审等
同行评审就是测试和测试之间的评审；小组评审组织一个测试小组进行评审；部门评审是整个部门进行评审；三方评审是开发、测试、产品或者用户都会参与进行评审
评审不是一次性的，每次评审完进行测试用例的修改，再评审修改，直到测试用例通过。
原始方式是通过excel表格进行管理，虽然原始但是方便。只不过对于需求进行变更的项目来说，改起来比较痛苦
也可以采用一些项目管理工具，比如禅道，对测试用例及BUG系统进行统一管理，比较的方便