编写测试用例的一点体会.docx

编写测试用例的一点体会 编写测试用例的一点体会 一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性四是测试用例的清楚性；五是测试用例的可维护性。 测试用例是基于需求的，为了测试程序是否满意需求，个人觉得要想写好测试用例必需对于需求做到完全理解，并能从全局上把握住需求。一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例的过程中进行等价类的划分，最终用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿到需求文档必需进行必要的分析，不能上来就盲目的写用例，新人尤其应当留意。测试用例编写完成后必需明确哪些是核心功能的用例！ （测试用例的有效性）测试用例应当包含清楚的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人依据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，假如和数据库发生了交互，必需包含数据库里精确的验证结果。用例基于数据驱动。 （测试用例的可理解性）测试用例步骤必需描述清楚，不能出现模棱两可以及重复的话语，测试用例应当根据增删改的依次进行支配，这样执行的时候效率比较高，避开不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。 （测试用例的清楚性）测试用例的验证点必需明确清楚重点突出，根据最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议根据流程依次进行用例支配，从第一个验证点到最终一个验证点，组成流程的起先到结束，便利测试执行。测试用例包含前置条件的必需将前置条件描述清晰，包括入口等。 （测试用例的可维护性）我们的用例主要是基于web的，用例存在肯定的变数。 因此在测试用例因为业务需求发生变更的时候，请刚好修改，维护测试用例，做到测试用例的实时性与有效性，同时也便利后来的新人同学刚好学习，不会产生误会与费解。 Ro Collard在”Use Case Testing”一文中说：“测试用例的前10%到15%可以发觉75%到90%的重要缺陷”。假如你在项目或者日常结束后，细致的分析过我们的bug列表，那么你会觉的这句话特别适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。 1用于冒烟测试的用例为最高优先级 2把基本路径以及各模块主功能的测试标注为高优先级别 3把你全部错误和边界值或确认测试标注为中优先级别 4把可用性测试以及入口默认值校验等标注为低优先级别。 5将功能测试用例分为严峻和不严峻两类，对于不严峻的功能测试用例降级为低优先级用例。 几点建议： 1你是否感觉测试的时候思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍？请明确你的需求，是否做到覆盖100%。你的用例优先级是否设置的合理。 2在测试时间紧迫的状况下，你不知道要测什么，或者要先测试那些功能？那么你须要调整自己用例的优先级，顺带回去好好整理整理需求。 3在编写测试用例的时候优先去学习，老人们优秀的做法。在学习别人优秀成果的基础上，编写自己的用例。 构造朴实的测试用例 测试用例这种东西对于刚入行的人来说是一种诱惑，初入测试的人急于驾驭这门学问，所以一起先就会问测试用例怎么写，问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵，任何人没有必要注意形式问题，假如你现在或者将来的公司有套特别完善的文档管理体系，那么你可以参考标准模版，假如没有你们大可跟我一样运用下面的格式： - - ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE - 我认为没有什么问题，ID代表标号（假如你情愿可以用这个ID对应需求文档的ID或者运用具体设计的文档的ID，间接连接需求），ACT代表一种动作，因为测试动作特别困难，假如手动执行或者自动执行，或者或者是一种异样状态都可以占用此位置，但是留意不能运用性能、数据或者平安测试替代，为什么请各位自己考虑。DATA代表数据，许多的测试类书籍中虽然没有干脆讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异样”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我以前曾经说过这里不再细谈，为什么会在一个文档中体现着点，主要是为了以后数据程序化作接口，一个不能将手动测试转为自动测试的人员注定是平凡的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的常常对这两种值的差异感到困惑，是不是“正常”、“异样”、“错误”就看个人的阅历了。T/F的引入是因为有这样的一种状况介入，假如EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着运用权，但确定权在于市场或者高层决策。DATE是一种好习惯，通常记为发觉“PASS”、“ERROR”、“FAIL”的时间，许多人会忽视这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅供应给他们T/F是不够的。 我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，假如你有许多的时间，假如你一年才写一个这样的文档，那么你可以从互联网上下在许多的资源把这份文档修饰的像APPLE一样。 入行的人员会更进一步的发挥测试偏执狂的实力，这时候他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个厉害吧？厉害，我当然说你厉害，你莫非不厉害吗？我记得有个500强的面试题就是你能为LOGIN动作写多少的测试用例？我想了半天我说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说也许我能写5个吧？！当然我自己也没底，我就能写出三个。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，全部的测试用例就是他们的衍生，一种本源的问题。我们接着探讨3000多个测试用例的事 情，有人明眼就会说：这家伙确定是微软的，没错，除了这种大公司有了足够的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟识程度，工作阅历有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。 单元测试、集成测试这些说明的是测试范围，功能测试、性能测试这些说明的是测试的手段，也可以这样说某个功能测试包含了若干个功能测试也内隐含了若干个单元测试的联动，当你起先测试的时候，事实上最终是对代码设定路径的一种验算，假如我们都生活在单线程、无UI的年头你可以更清晰的看到 “PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年头，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，动身点是好的做法是累死人的，假如你情愿你可以为机器码写1亿个测试用例，假如你还是很偏执，你可以为门电路写上1万亿个测试用例，你有命执行吗？ 我通常不情愿写太多的测试用例，许多人认为我工作看法有问题，我认为这更能说明我的看法：我情愿朴实的构造我的测试用例，但是我有原则来保证我的测试用例： 1、接到任务不急于作而在于多思索，首先在纸上构造一个大致的业务流图 2、流图构造好，快速剔除公用的测试用例 3、构造测试用例先写符合主路径的三种“PASS”、“ERROR”、“FAIL” 4、精化测试用例努力为ERROR多构造1-7种假设 5、执行测试用例强化FAIL的标准化失败输出，但是对应削减PASS测试用例 6、进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10假如我还是测试，我将接着我的朴实理论，多出来的平安时间我可以看看蓝天享受享受生活！ 测试用例编写的“侯式标准” 作为软件测试人员，执行测试用例是我们进行测试工作的主要手段，测试用例设计的好坏，干脆影响着测试工作的质量。一个“好”的测试用例能保证测试的质量，规范测试的进程，进而提高我们的测试效率。那什么样的用例才是好的测试用例？这已经是一个老生常谈的问题，大家见仁见智 ，众说云云，不一而足。 而我的TL候风的一句话，让我对用例的有了新的相识。他是这样说的：一个好的测试用例，就是在保证测试质量的前提下，做到以下几点：当一个不熟识业务的人，看到你的用例后，要知道用例的测试目的什么，知道你要做什么，怎么做，为什么这样做，取得了什么什么成果。 做什么？ 做任何事情，都要有的放矢。我们在编写一个测试用例的时候，应当知道我们要的是什么，这也是编写一个用例最基本的前提。 怎么做？ 即详细的如何设计用例。就是要明确用例的执行过程，这样在测试的时候才能有章可循，摸着石头过河 为什么这样做？ 这要求用例编写者要明确设计用例时用到的方法（如边界值，等价类等等），以及用这种方法的好处。取得了什么成果？ 这要求用例编写者明确通过这个测试用例,我们将取得什么效果。比如一个采纳边界值设计的用例，取得的效果是在极端的数据下，软件是否能够正常执行功能。 标准规范中包含的主要元素如下： 1测试名称(Test Name)：测试用例编号和测试用例名称。 2创建日期(Creation Date)：测试用例创建时间，系统自动产生。 3设计人员(Designer)：测试用例设计人员 4状态(Status)：测试用例状态 5描述（Descrption）：测试用例具体描述 6步骤名称（Step Name）：测试步骤名称 7步骤描述（Step Descrption）：测试步骤具体描述。 8预期结果（Expected Result）：测试预期结果 要是根据“候风标准”（暂且这样命名，还没申请侯哥批准），我们要对上面的标准进行规范的优化以及内容的明确 1测试名称 A）用例依据各用例的功能来命名，尽量做到简洁明白。 B）一级书目运用各项目的顶级菜单名称来命名，如功能、业务、查询三大类； C）二级书目运用顶级菜单下的二级菜单名称类命名，用户可依据名字判别该用例是测试哪个模块的。2 描述（Descrption）：测试用例具体描述 要用通俗易懂而又简洁的语言描述描述用例的设计目的，让其他人能够明白我们在什么 3 步骤描述 步骤描述要具体而不臃肿，条理而不凌乱。 同时，在规范上要增加以下几项 1测试目的（Purpose）：编写这个测试用例的目的 2测试方法选择依据（Foundation）：即用这样方法的好处 3测试取得的成果（Achievement）：通过执行用例取得的成果 4用例执行的前提条件（Precondition）：执行用例的须要满意的前提 这样，一个完整的用例包含的元素如下： 1测试名称(Test Name) 2 测试目的（Purpose） 3 测试方法选择依据（Foundation） 4 用例执行的前提条件（Precondition） 5创建日期(Creation Date) 6设计人员(Designer) 7状态(Status) 8描述（Descrption） 9步骤名称（Step Name） 10步骤描述（Step Descrption） 11预期结果（Expected Result） 12 测试取得的成果（Achievement） . 综上所述，测试用例的“侯式标准”的精髓，就是把自己的思维过程尽可能的呈现到用例中，做到即使一个完全不懂业务的人，看到我们的用例后，也能知道业务的需求和流程，知道测试的过程，能够无障碍的执行我们的用例。 以上是我学习用例编写过程中的一些体会，不足之处请大家指责指正。让我们一起沟通共享，共同进步成长。 编写测试用例的一点体会 测试用例的编写总结 编写测试用例和测试安排 编写测试用例方法心得体会 编写测试用例方法心得体会 一点体会 教化实习体会：一点阳光·一点青春·一点爱 读书的一点体会 我的一点体会 家访的一点体会 本文来源：网络收集与整理，如有侵权，请联系作者删除，谢谢！第13页 共13页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页第 13 页 共 13 页