为什么我们总觉的自己设计的案例不全、不容易看懂

时间：2019-01-13号，上午

对于敏捷项目，每个月一个迭代，一个迭代的改动点，有新增的业务需求，有技术优化的改动点，对于敏捷项目，如果系统庞大，还会涉及到关联系统的改动，导致我们系统的改动的测试。

每个迭代，我们涉及的案例或多或少会遇到以下问题：

1、怀疑自己设计的案例覆盖不全

2、当设计完案例完成时，我们不是特别清楚自己的涉及案例内容 比如：有些场景会被认为没有意义，或者有些场景重复测试了

3、当我们设计完案例的时候，执行人员会看不懂的我们写的案例，或者说，不清楚这条案例的测试目的

 4、因为每一改动点都是以一个故事卡的形式提验收标准，而对于我们，只有在真正开始设计案例或者执行的时候，才去了解这个故事卡的业务需求，实现逻辑。而每个迭代会有很多故事卡，我们每个人不可能每个故事卡都清楚，那我们如何对每个迭代的改动点了然于心，至少不是完全不懂。

5、为什么我们的案例中 ，会描述清楚检查点，检查点的意义是什么，如何清楚简单描述检查点

6、我们常说的测试技能，哪些算作测试技能，是编写代码的能力、写案例的能力？

7、我们接触的测试类型：界面测试和接口测试中，我们该如何更好的进行测试

对于以上问题，我自己整理了一份解释

1、怀疑自己设计的案例覆盖不全

产生这样的疑问，原因可能来自两个：一是，业务不熟悉；二是，没有掌握案例设计的相关方法。

2、当设计完案例完成时，我们不是特别清楚自己的涉及案例内容

比如：有些场景会被认为没有意义，或者有些场景重复测试了

有些场景没有必要测试，原因也是两个：一是，业务不熟悉；二是，设计案例的时候，没有联系到实际的使用场景。有些场景在实际的使用中压根就不会存在的场景，那确实是没有必要进行测试。所以，在设计案例的时候，我们要关注业务需求，也要关注这个功能在实际使用中的场景。

有些场景重复测试，这种在接口测试中会经常出现。为什么，因为不同的场景，它可能就是调用的同一个方法，这时候我们需要做考量，哪些场景是属于重复的场景，这些也要问下开发，这些场景测试必要性。

3、当我们设计完案例的时候，执行人员会看不懂的我们写的案例，或者说，不清楚这条案例的测试目的

这个问题存在的原因有两个：一是，案例设计人员没有把握好案例设计的几大要素；二是，每个人设计案例的思路不一样，在一个团队中，最好统一一下案例标题的命名规则，案例编写的几步曲。

第四点问题暂时无法回答

5、为什么我们的案例中 ，会描述清楚检查点，检查点的意义是什么，如何清楚简单描述检查点

检查点，就是预期结果，案例设计的时候将预期结果描述清楚，案例执行的时候，会不用再考虑是否符合要求，直接看检查点符合即可。

第六、七点，需要再次讨论。

界面测试、接口测试、 覆盖业务场景，覆盖需求、覆盖开发实现逻辑、覆盖用户使用习惯