软件测试之测试用例编写

大家好，欢迎来到IT知识分享网。

本篇记录本人对测试用例编写等方面理解，如有不对，请指正。
测试用例是为了保证异常场景不出问题，正常场景那是开发应在转测前就需要搞定的事，因此测试用例重点为异常场景测试。
测试用例内容：
测试用例是根基，是整个测试过程中最为重要组成部分，良好的用例能提高测试效率。测试用例内容，用例基本要素不表，在这只想说下内容，用例内容要简洁、易懂、全面。
（1）简洁是指较少字数描述清楚所写场景，比如：
标题：XXX项目-XXX页面（服务）-XXX场景，预期结果。个人很喜欢在测试用例标题中简要列明预期结果，因为测试用例在测试生命周期内可能不仅用于一遍，一轮测试、二轮测试、回归测试、自动化脚本编写都需要用到此次编写测试用例，在多次测试过程中已经对用例特别熟悉，所以可以做到只看标题便知结果，极大提高效率。
预期结果：新增XXX表数据，更新XXX表数据，删除redis:key，同步XXX表。将各个场景的预期结果逐一罗列，避免一锅烩，因为用例写出来是给其他人看的，不是给自己看的。
（2）易懂是指减少用例的二义性，让各个阶段各种角色的相关人员都能看懂。比如标题中有开始时间大于系统时间；此系统一般理解为当前时间，所以选用开始时间大于当前时间能让所有人都理解。
比如预期结果中有操作XXX表数据，操作是指更新还是写入，操作数据的关键字是什么，可以参考写入XXX表，状态（status）为1。
（3）全面是指测试用例覆盖率要高，我们都知道没有穷尽测试，所以测试用例也是无法全面覆盖，因为我们写用例一般是按照等价、边界等手段进行选取样本的方式进行编写用例。这就要求测试人员对项目要有远高于其他人的熟悉度，项目使用框架、开发代码风格、参数类型都会影响到如何编写测试用例。
测试用例编写时机
一般测试用例编写都是位于需求评审之后，但是往往有的时候需求评审进行时机晚或者不进行，所以编写用例可以选取到自己熟悉需求文档阶段，当然此时可以先罗列测试点，不用特别详尽编写完整用例。用例编写完成时机是需求转测之前。不要存在侥幸，先转再补充，或者先测再补充用例，因为写得好才能测的好，写不好肯定测不好，不写肯定测不好，反过来，测得好不一定写得好，测不好一定写不好，所以这个采用等价类一分析，发现只有先写好用例，才能做好测试。还有一点是修改类测试用例编写时机，往往我们很多需求都是在原有需求上改造，原有用例丢失，原有用例不完整，此次时间短，来不及整理原有用例都会影响到测试进度。所以修改类的一定要对原有用例进行标记，划分用例等级，对原有重点用例必须执行。
测试用例编写方式
各个项目要求，有线下excel方式进行，有线上方式进行，有word版，有对外提供版，内部测试版。选取一个最适合自己的，比如项目使用线上，则看看是否支持excel方式导入，如果支持导入，是否出现顺序乱序，缺少字段现象。所有编写都是一个过程，最终用例输出才是结果，找最合适自己的，不一定是项目要求的，但是最终又能满足项目要求即可。个人推荐excel方式，便于编写，便于测试，缺点是不利于维护修改类用例，不利于项目维护用例库。
测试用例使用范围
谁评审需求谁编写用例，谁编写用例谁测试，交叉测试都是依附项目测试管理的。测试用例也要做到随机应变，比如交叉互测时和你对接的是初级测试，是刚刚接触本项目，这些因素都需要参考随时调整用例的完整性。
测试用例补充
在编写用例过程中很多人都会忽略关联影响，比如依据业务划分，充值、扣减、回退、冲正；充值业务是否允许回退，回退后的业务是否允许冲正，冲正后是否允许回退；业务是大融合的，你中有我，我中有你，结合业务强制给自己要求关联测试场景个数要求可以补充流程方面的场景覆盖。
测试用例提升优化
良好的测试用例有自己独特的个人风格，并且此风格被项目成员接受，进而达到在项目推广，形成项目内统一风格。良好测试用例要做到对异常场景、长流程补充，既然无法穷尽测试，那么要根据实际场景，尽可能多的考虑异常，传统正常场景异常场景比例应为1:3。