聊聊测试用例的“可读性”
测试用例的可读性，虽然不是最重要的，但也是非常关键的，为什么这么说呢？第一，好的可读性，可以让测试执行工程师，很快的读懂用例，读出用例要测什么？怎么测试？
第二，提高工作效率，如果一条用例，写的非常长，在执行时，测试工程师还要花费时间去读它，这样也就降低了工作效率。
第三，测试点冗余，有些人，总喜欢执行用例时，将产生的相关结果，都去验证。这样是不对的。例如：添加一个产品，预期结果需要验证，是否提示添加成功，并且在添加列表中能够查看到；在测试添加列表的时候，就不要测试添加产品后，添加列表是否可以显示。如果两个地方都去验证添加产品这个操作，就产生了大量的冗余用例。同时也降低了测试用例的执行效率。也会使用例变的长而难懂。让人不知道这条用例在测什么？ 写测试用例的过程中可以进一步了解测试的产品。理解相关业务。 我们团队现在基本已经抛弃以后那种冗长的测试用例写法了，先用画思维导向图，然后形成用例，只对你用例标题有要求，其他的操作步骤什么的，基本都不用写 Re LZ
大家可以去读一下《测试用例有效性》 <有效的测试用例>之类的书和文章 如果自己写测试用例,同时自己测试的话,那没什么问题;
如果自己写测试用例,但是执行是别人的话,如何写是个大问题,用例中要描述好执行前提,步骤,预期结果,还要很好的体现你的测试策略;
用例的详细程度,我觉得完全会跟谁去执行用例有关,若执行人对业务不熟悉,那不可避免的要冗余,否则可以进行简化; 如果是要长期维护的软件产品，测试用例最好还是用文字表述出来。
最好细化到认为看这个测试用例的是白痴，细化到字段。交叉测试、回归测试时候方便N多
页:
[1]
