去TestBird之前，作为一个测试人员，我一直被灌输的思想正是：测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。
但是我也一直困惑于这点，用例写的太简单，必然增加沟通成本。想尽可能的写详细，个人时间耗费太多，版本更新迭代太快，这样的用例反而很快被更新淘汰。
后来在公司做了很多项目，和许多资深测试学习后，有了不同的想法。其实，我们忽略了一点，我们之所以为了让测试用例尽可能详细，是为了测试目的，为了完善产品。因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就可以。
根据我的经验来说，在测试计划阶段，一般建议测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
但是我也一直困惑于这点，用例写的太简单，必然增加沟通成本。想尽可能的写详细，个人时间耗费太多，版本更新迭代太快，这样的用例反而很快被更新淘汰。
后来在公司做了很多项目，和许多资深测试学习后，有了不同的想法。其实，我们忽略了一点，我们之所以为了让测试用例尽可能详细，是为了测试目的，为了完善产品。因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就可以。
根据我的经验来说，在测试计划阶段，一般建议测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
温馨提示：内容为网友见解，仅供参考
第1个回答 2017-03-08
介绍 这篇文档将会是一篇在「高层面」的怎么用 Robotframework 来编写优秀测试用例的原则。至于如何使用 Robotframework 来与您的待测试系统相作用这样的细节讨论是不包含在这篇文档中的。 最重要的一条原则就是保证测试用例对于不熟悉这个领域...本回答被网友采纳
相似回答
