测试用例是必备的吗？

lsekfe

　首先我们先明确测试用例是什么？个人觉得测试用例应该有：标题，测试目的，前提（预设条件），测试步骤，预期结果等。测试人员可以根据测试用例的这些要素，可以执行测试。那么它在软件测试流程中是必需的吗？
　　先分享下个人关于测试用例方面的经历：A公司和B公司。A公司有完备的大型软件开发流程，产品有自己完备的测试用例库和测试用例管理规范，在项目中也有测试用例的输出阶段：功能需求和概要设计出来以后，测试人员就根据这些输入开始着手准备测试用例，接下来还会经历测试用例点的评审和测试用例的定稿阶段，测试人员根据完成的用例执行测试。在项目发布之后，还会预留时间对测试用例进行修改入库。这些入库的测试用例会作为回归测试的全集。公司A的某产品在项目中的测试用例相关活动如下图展示：

项目中测试用例相关活动图
　　B公司和A公司属于同一个行业，所在的产品也有软件开发流程，但是此流程被增删处理了，从测试活动角度而言，关于测试用例的相关活动已经完全删掉。只是在项目结束后会输出一个关于新功能的checklist，产品有一个checklist库。这里解释下checklist和测试用例的区别：checklist可以理解成等同于测试点，没有任何测试步骤和预期。不同的人拿到同样的一条checklist可能测试方法是不一样的；而对测试用例来说，不同的人拿到同样的测试用例测试方法是一样的。
　　A和B两家公司的产品质量应该说都还可以。关于测试用例是否是必备的呢？个人观点跟团队的架构和整个团队的测试经验有很大的关系，如下说明：
　　1、B公司的测试人员经验基本上在五年以上，并且是从相关行业跳槽过来的。可以说相关行业测试经验丰富，可以根据checklist进行测试；
　　2、B公司的测试人员模块分配固定，比如模块A分给测试人员小王，可能会一直分配给他。他对于这个模块的熟悉程度和测试方法的把握会得心应手，所以有没有测试用例没有影响到模块A的质量。
　　不过这样也遗留下了其他问题，如果存在测试人员离职，很可能这些测试方法就从此断档。
　　对于A公司这种完备的测试用例，有一次在项目总结会上，测试团队有人提出来，每次按照测试用例的步骤发现问题的概率不大，应该根据测试用例适度调整测试步骤和方法。当时这个提议是个人也是比较认可的。但是基于当时团队现状并没有公开尝试。主要原因是团队人员新生力量多，测试经验少，对产品的了解不透彻。
　　以上是2个公司关于测试用例情况的案例。测试用例是否必须的，不是一概而论的。以下是自己关于这方面的想法：
　　i)如果是一次性的项目，比如这个项目不会有延续性，做完就结束了，不需要维护了。这种情况个人觉得测试用例可以去掉或者简化测试用例，用checklist的代替应该就可以满足，毕竟是一次性工程。
　　ii)如果团队新生力量多，测试经验少（1-3年），可以在测试用例多下一些功夫，因为在测试用例产出前会有测试分析和测试设计的阶段，这两个阶段会很大的提升员工的测试能力和深化对被测对象的理解。
　　iii)如果团队测试经验丰富，对被测对象也熟悉。可以用其他的方式代替测试用例，比如checklist，避免人员流动带来的影响，可以采用文档的方式记录模块的功能逻辑和使用场景等。
　　整体来看对测试用例的把握可以很灵活，这些测试的输出并不是完全不变的。完全根据团队情况、项目情况等因素，合理把控，用其他方式代替也是可行的。关键在于一点，质量能保证即可。

Miss_love

测试用例是测试工作的基础，现在都玩高大上了，往往忽略了最本质的内容