©2020-2024 ioDraw All rights reserved,
Privacy Policy
前几天同事分享了一波作为测试需要具备哪些能力，测试用例需要从哪些方面进行设计，我把他分享的内容拷贝了一波，作为以后在测试过程中的参考。
首先需求评审、技术方案评审、测试用例评审三者的关系
一开始，我每次设计测试用例都是从需求着手，去用测试用例设计的几种常见方法着手：等价类划分法，边界值分析法，错误推测法，判定表法，以及业务流程。从这几个方面去考虑，最后只是对界面上可以看见的功能进行了用例的设计，是最基础的。直到这一次，团队中评审技术方案的时候，我也参与了，然后经过同事分享的，才发现我们在设计用例时，不仅需要从需求维度去考虑，还需要结合开发的设计思路，要知道一些在页面上看不到的功能是如何实现的，通过这些来设计我们的测试用例，并且需要对数据层面进行设计测试用例，而且还需要对页面上无法操作的异常场景，通过接口层面来设计测试用例，这几点是之前我从来都没有考虑到的。
那在需求评审方面，我们需要具备以下几个方面去思考，尽量提出疑问。
在技术方面评审方面，我们需要具备以下几个方面的能力，去思考，去提出疑问
在测试用例评审时，我们需要具备的能力，
其中cheklist的详见测试技巧-《测试用例设计》，就是下文的“测试用例设计的几个方面”
需要掌握的测试技巧
需要具备的测试设计思想
测试用例设计的几个方面
接口测试用例设计的几个方面
定位问题需要具备的知识储备和能力
在测试过程中，我们免不了需要构造数据，在数据构造方面我们需要具备的能力
检查环境的差异性，从下面三个方面进行考虑
下面就是自动化的学习路线了
小小的总结一下：设计测试用例需要从以下几个方面进行考虑
1：需求-及业务功能
2：开发的技术文档
3：数据层面
4：接口层面
并且同事总结了一下当前我设计测试用例，更多的是考虑了界面上展示的功能，一些数据层面、逻辑层面的内容考虑的还是很少，校验数据入库这些都很少，可以说没怎么去考虑。接下来，多往这些方面去考虑，去设计用例。
总结：上面提到很多东西都是我现在不具备的，只有一步一步的去学习了。成长的空间还是挺大的，需要学习的内容也很多。