软件测试（测试案例）误区知多少

认知是个体对客观世界信息的加工。在个体和环境的相互作用过程中，认知不断发展，并不断完善。软件测试从业者们从入门时建立起对该行业的基础认知，到后续的工作学习中一步步的去增添、去优化，最终浇筑成属于自己的职业大厦。

《软件测试的误区》|为刚入行/即将入行的新人们答疑解惑！

上一期，M讲述了软件测试这个职业相关的事情。这一期，我们来聊一聊软件测试用例的认知误区。

软件测试用例是指对一个特定的软件产品进行测试任务并生成方案，其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。简单来说，测试用例就是为了核实是否满足特定软件的需求，而编写的一组输入、执行和呈现结果的方法集合。

正确认识和设计软件测试用例可以提高软件测试的有效性，也便于测试质量的把控和测试过程的可管理性。

在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，在实际中给软件测试带来了负面影响。

M来对这些认识误区进行列举和分析。

强调测试用例设计得越详细越好

在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量越多越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

但是，以当前国内开发人员和测试人员数量对比，在一个项目里，分配给测试的时间和人力资源是有限的，考虑到质量、时间、成本的平衡，如果花费太多的时间在写测试用例上，那么就没有足够多的时间去执行测试，去发现软件缺陷，测试质量也就无从谈起了。所以，只有通过分析测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，这才能达到“少花时间多办事”的效果。

追求测试用例设计“一步到位”

互联 公司小步试错、快速迭代的思想已经产生有段时间了，可是撰写测试用例上，很多公司依旧是喜欢一次搞定，终生受用的方式。

这样的想法会让设计出来的测试用例缺乏实用型；或者误导测试用例执行人员，误 很多不是“bug”的bug，这样的用例就像不上锁的门，关不关没什么分别，形同虚设。

思想家斯宾塞·约翰逊曾言“唯一不变的是变化本身”，软件的开发永远处于不断变化的过程中，用户对软件提出新的需求，设计规格就要相应的更新，软件代码就会改变，那么软件测试用例就要进行内容调整，数量上要增加减少，增加一些针对新功能的测试用例，删除一些不再适用的测试案例，修改一些需要更新的测试案例，从而做到“与时俱进”。

让测试新人设计测试用例

实习生负责端茶送水，新人来写测试用例。这样的景象想必你也见过。

让新人测试是一件高风险低收益的行为，新手对测试用例怎么还缺少经验，制作出来的测试用例覆盖性不高，编写效率低，重复使用性差。

软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术提高和对被测软件的不断熟悉，积累测试用例的设计经验，从而编写测试用例。

测试用例的误区远不止我提到的这三点，大家可以自己总结，如果有什么问题，大家可以私信M，M会一一解答。

最后，祝愿大家在测试这条路上越走越远，越走越宽。