全国咨询热线：136-9172-9932
金三银四，到了跳槽求职的高峰季节，很多测试工程师都在为面试新工作做准备。但是有些测试人员对软件测试用例的编写原则还是不清楚的，所以本文整理了一些高效的软件测试的基本工作流程和测试用例编写方法,内容如下，希望可以帮助到大家。
如何写好测试用例，作为测试人员需了解业务，分析需求点
为什么测试人员要参加需求分析?也就是进行测试需求分析的目的是什么?
第1、把用户需求转化为功能需求
1)对测试范围进度量
2)对处理分支进行度量
3)对需求业务的场景进行度量
4)明确其功能对应的输入、处理和输出
5)把隐式需求转变为明确
第2、明确测试活动的五个要素
测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境、测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
如何写好测试用例，那么怎么进行测试需求分析呢?
首先、确认功能
(业务功能、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束)
1、业务功能：与用户实际业务直接相关的功能或者细节;
2、辅助功能：辅助完成业务功能的一些功能或者细节，例如：设置过滤条件;
3、数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等;
4、易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，例如：快捷键等;
5、编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等;
6、参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节;
7、权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限;
8、性能约束：功能的细节，执行功能时，必须满足的性能需求;
其次、场景分析
1、考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程(一般和外部有交互的业务出错率比较大，需要重点关注)。
2、考虑系统内部各个场景之间的联系：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图。
再次、挖掘隐性需求
这需要测试工程师的经验积累：
1)常用的或者规定的业务流程
2)各个业务流程分支的遍历
3)明确规定不可使用的业务流程
4)没有明确规定但是应该不可使用的业务流程
5)其他异常或者不符合规定的操作
好了，以上讲了需求分析，那么如何编写一个好的测试计划，下文正式开始阐述测试用例设计那些事。
如何进行测试用例的设计?
编写测试用例之前，我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
步骤
1)测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
2)业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点做业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：
A、主流程是什么?
B、条件备选流程是什么?
C、数据流向是什么?
D、关键的判断条件是什么?
3)测试用例设计：
完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：
等价类 → 边界值 → 因果图 → 判定表 → 状态迁移 → 正交实验 → 场景法 → 错误推断(注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类)
4)编写完成后自我检查以及部门内部评审：
①测试用例本身的描述是否清晰，语言准确;是否存在歧义性;
②测试用例内容是否完整，是否清晰的包含输入和预期输出的结果;测试步骤是否清晰;
③测试用例中使用的测试数据是否恰当，准确;
④测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维;
⑤是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同;或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下;
⑦画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性;
⑧测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。
5)测试用例更新完善：
测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
好了，测试用例写完后，就要开始测试用例的执行。测试用例的执行过程如下：
首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：
①测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。
②测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。
③未执行用例、标志为删除或者无效的用例，需注明原因。
④执行过程中有疑问的测试用例(场景、操作步骤、检查点等)需找测试设计人员澄清。
⑤测试执行需对用例描述的检查点逐一检查，避免遗漏。
⑥重视不易重现的缺陷场景，可能是一个bug。
⑦执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
⑧建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现在。如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。已确认问题需及时按照问题单提单要求(规范和缺陷定级)提单。
⑨跟踪问题单修复情况并回归验证问题单。每轮次测试结束，find一下是否有core文件产生。测试结束，将最终测试用例文档上传到归档目录，实现用例重用。
以上是大致的软件测试基本流程及高效的测试用例编写原则，如果是自动化或者性能测试的话，还需要根据测试用例进行脚本编写，运行脚本等，希望对大家有用!
