转：测试用例的编写方法
上一篇 /
下一篇 2009-01-12 17:48:06
/ 个人分类：测试用例
对于每一个Tester来说都是不可避免的，平时很一部分的工作内容就是编写测试用例，如何写一个好的用例呢？如果你的用例只是用于ISO的审核，那没必要再这里探讨这个问题。好的Case，是Tester的劳动成果，它应该是充满智慧的，具有可复用性，启发性，能充分体现一个Tester的水平。很多人的Case虽然写的很不错，可惜只有他自己才能看懂其中的内容和体会Case的意思，为什么？因为它写的Case描述不清楚，只有他自己看了才明白，一个好的Case必须有良好的书写格式与习惯，能让所有看的人都能理解，也就是说，当你离开这个项目，其他人来接受你的工作时，只要看你的Case就能明白项目的目标与需求。如果做到这一点呢？ 第一步，我想应该是Case格式的确立，拥有好的，清晰的格式，有利于帮助Tester来组织他的Case，会让你事半功倍，反之亦然，一个结构不合理的格式，会让你觉得蹩手蹩脚，影响你
的发挥。如果选择一个良好的结构，要根据具体工作的情况，项目的结构，以及用例的目标（功能测试用例，性能测试用例以及其他）我认为不同的测试手段要使用不同的用例结构。确定好这些因素后，在来谈谈测试用例中涉及到的一些东西，理解Case所需要的东西，我认为这些东西是比不可少的，1：软件版本编号。2：测试用例编号，编号的格式可根据软件版本号+用例号来确定，这样不会应为Case的日积越累或软件版本的不停升级而混乱。3：用例的优先级，在一个时间紧凑的测试环境下，为了跟效率的完成测试用例，我们所能做的是完成那些优先级高的用例，至于优先级如何来确定，可以根据项目需求，或者用户那边的需求来确定，也可以根据实际经验对那些很容易产生缺陷的模块设置为高优先级。4：用例步骤。5：输入数据。 6：实际输出数据。7：期望输出数据。某个步骤下，输入了某条数据，你期望程序会输出什么数据。可以一来可以与实际输出的数据相比较。8：备注。为什么要备注，可能你在思考这个Case的时候有一个好的点子或者思路，可以写在备注里面。或者对这个用例还有一些必要的补充说明等。9：测试环境。10：用例编写人/日期。11：测试执行者/日期。可能根据不同的项目还需要一些补充，可以根据具体情况具体分析。 第二步。设计测试用例，通常情况下在你编写测试用例之前，你必须要有一个测试计划，这里我只讨论测试用例。嗯，开始设计之前还有一些准备工作，必须熟读软件需求说明，一定要清晰的了解每一条需求，明白软件的性能指标，综合考虑测试环境，人员配置，要根据自己的实际能力，测试工具使用状况写出符合自己测试团队的用例。用例的划分有很多种方法，根据测试的类型，比如功能性测试，你可以按照功能模块划分用例，划分科学的模块你可以组织这些用例直接进行集成测试，组合部分模块或者所有模块来测试。性能测试，可以根据性能指标来确定用例划分，对于用例环境的不同来划分用例等等。也可以根据测试工具在组织测试用例，比如那些Case可以在测试工具上完成，那些需要手动去完成，划分的方法很多，但是有一点必须保证，就是测试覆盖率，是否覆盖了所有的需求。写好一个用例，需要工作经验的积累，需要对项目需求的了解，我觉得Tester应该是公司里最了解软件需求与功能的人。测试的技术很多，可以在Case中体现出来，比如说边界值测试，溢出测试，等价类划分测试法，等等。按照这些来编写你的Case也可以提高你的技能。
第二步。审核你的Test Case，怎么样才能完美你的Case呢？最好的办法就是进行同行评审，也就是让你的同事来看你的Case，同时与开发部门负责人进行沟通，讨论你的Case。进行这两步后可能要对你的Case进行一些修改。但并不是这样一个好的Case就产生了，在执行测试用例的过程中，你可能还会发现很多问题，这也是一个Case的完善过程。对于从一个项目中成长起来的Tester，会随着对项目的不停理解与思考而随时修改自己的Case，我是这样理解的。
收藏
举报
TAG:
