优秀的测试用例应该有延展性

优秀的测试用例应该有延展性"/>

优秀的测试用例应该有延展性

转载：=MjM5NTU0MDg0MA==&mid=2651233212&idx=2&sn=f96dd18dbd747e3a0fbb2997730eaa3b&chksm=bd04c1bb8a7348ad9cd4dfff6356befe7657851fe6d740be21a9ceec38695b38d37fe7bf3257&mpshare=1&scene=23&srcid=0524zDIQcCOmF8RwyAmongsj#rd

听了公司大神的一个培训，讲的是Shell脚本编程，其实所有的编程语言的思路都是差不多的，语法上可能会有一些小的差别。对于不同的编程人员来讲，差异就在与编程人员自身的编程习惯和思考的是否全面，这些决定了程序的可读性和可重用性。大神说了一句话："一个好的程序不在于功能有多炫，性能有多好，好的程序应该有很好的可读性和可重用性。其实学习知识并不难，难的是对知识的传承。"

　　我们写的测试用例也一样，可读性和可重用性也非常重要。测试的功能多了会发现所有的功能几乎都可以找到原型或者由几个原型组合。那么我们在写测试用例的时候就应该考虑到用例可读和重用两点，对于新的功能就不必每次都要重头设计测试用例，可以在原有用例的基础上修改和新增。复用测试用例可以在很大的程度上减少重复性的工作。

　　对于以上两种特性，我概括总结为延展性，即一个好的测试用例应该支持类似功能的复用，可以作为优化、延展功能的测试用例基础版本，这个体现在测试用例的可复用性。而要保证上述两项的要求，最基础的要保证测试用例可以被任何的测试人员读懂且无歧义，这个体现在测试用力的可读性。

　　那么如何保证测试用例的延展性？在可读性方面，部门内部可以执行一套测试用例的书写标准，有了统一的标准就可以很大程度上的避免由于测试工程师的个人书写习惯和风格导致的测试用例可读性低，例如有的测试工程师在写测试用例的时候喜欢用自己惯用的缩略词，导致其他测试工程师在看的时候不理解测试用例写的是什么。

　　在可复用性方面，建议在写测试用例的时候，着重突出功能的实现而非针对某一个特定的系统需求编写测试用例，这种编写的方法能够很大程度上的保证类似功能的测试用例复用；测试用例的编写思路建议按照业务流程，分不同场景来编写，这种编写方法能够方便在做优化、延展功能需求的时不必重新编写测试用例，将原有测试用例稍作更改增加即可。

　　测试用例之于测试工程师就像代码之于开发工程师，要好好的维护和整理。严谨是测试的生命，分享是最好的学习方法，立即开始实践。附上一个我理解的测试用例的标准：

　　1. 完整性

　　2. 准确性

　　3. 描述清晰无歧义

　　4. 不冗余

　　5. 可读性

　　6. 可复用

转载于:.html