参加用例评审的一些思考

领导说一份好的用例的标准：

1.新同事来公司，照着你的用例来执行，至少可以进行测试工作，对于他人来说，有参考价值；

2.用例思路清晰，有条理，看用例描述就知道该条用例的测试点；

用例：

1.预置（前置）条件：即用例的入参       预期结果：即用例的出参，尽量写的详细些

2.操作步骤：有些用例是可以合并的，例如用例“合同签订日期小于等于当前日期”，该条用例不用拆分成3个来写，直接写成1个用例即可，如下图所示：

用例编号	模块	级别	用例描述	前置条件	操作步骤	预期结果
XXX_001	XXX模块	中	合同签订日期小于等于当前日期	1.打开页面 2.当前日期是2018/12/27	步骤1：合同签订日期选择小于当前日期 步骤2：合同签订日期选择大于当前日期 步骤3：合同签订日期选择等于当前日期	步骤1结果：选择的日期值填入合同签订日期框 步骤2结果：无法选择 步骤3结果：选择的日期值填入合同签订日期框

3.公司的测试注重业务，所以用例尽量多体现业务逻辑，非业务逻辑的内容可写成公共用例。

4.逆向思维→逆向用例。入门测试很简单，但是要做好测试，覆盖率全，可不是那么容易的。

我们公司的测试重点是业务测试，业务逻辑又复杂。自己一开始写的用例很乱，测试的时候用例几乎是没有参考性的，回归的时候也找不到用例的侧重点，自己也不知道如何划分才能让用例更清晰，为此头疼很久。后来得到领导的指点，将用例分为公共用例和业务用例两部分，公共用例用来写一些基本的校验规则，如文本框的校验、数值的校验、翻页功能等，所有业务的用例写在一起，测试的时候也会有侧重点，领导看起来也清晰。