编写测试用例有哪些方法
当自己接受到一个设计测试用例的任务时，如何对一个庞大的模块进行设计测试用例呢
这时候测试用例的划分就显的尤为重要。
我总结的测试用例的划分有三种： 1）按照功能划分 2）按照路径（业务流程）划分 3）按照功能和路径（业务流程）划分 目前我用的方法是第三种。
第一种按照功能划分，优点是最简捷，但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。
如果没有严密的逻辑分析，很容易产生遗漏。
第二种纯粹按照路径划分也容易造成对功能点的遗漏。
所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。
如何写好测试用例的设计心得
我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。
回到测试用例中来，我觉得做好以下三点就是一个好的用例。
求帮忙 如何编写一个好的测试用例
我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。
回到测试用例中来，我觉得做好以下三点就是一个好的用例。
第一：依据分明 众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。
所以写测试用例的依据就是需求。
这么说太笼统，举一个例子。
一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。
这也是需求必须可测的一个体现。
假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。
那么 ok，我们就要写5000个测试用例。
还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。
这样做的目的在统计中讲。
第二：目的明确 用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。
前面无论多少步骤，都是为了找到这个目的途径。
功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢
等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。
换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。
就是这样。
第三：便于统计 测试用例对整个测试过程的质量控制和评估有很重要的意义。
如何编写测试用例
随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。
从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。
测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。
我们公司一直使用日事清来完成软件测试的编写、执行等工作。
通过日事清看板按照项目、部门、时间等维度组织团队工作清单，梳理团队任务，创建团队工作计划，让团队工作可视化。
建立在看板的任务会落实到人，这些任务会自动分解至团队相关成员的个人日程中去，让个人的日程和团队的工作安排打通，实时跟进。
通过这样的方式，使团队有计划、有反馈、有总结、有调整，基于此就形成一个完整的“戴明环”，保证了测试团队的效率和质量。
软件测试的重要性是毋庸置疑的。
但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。
每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。
因为有些因素是客观存在的，无法避免。
有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。
如何保障软件测试质量的稳定
有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。
可以把人为因素的影响减少到最小。
即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
因此测试用例的设计和编制是软件测试活动中最重要的。
测试用例是测试工作的指导，是软件测试的必须遵守的准则。
更是软件测试质量稳定的根本保障。
测试需求来源于测试用例,是对测试用例的总结
测试用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
以上可以看出测试用例在整个测试工作中的地位和作用，以下编写了关于如何写好测试用例的一些个人建议：\\r 1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。
只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
\\r 2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
\\r 3、尽量多参加项目组内的会议。
比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
\\r 4、要善于沟通，多和客户、开发、测试人员进行沟通。
遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。
这样才能提前解决需求理解偏差等。
\\r 5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。
用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
\\r 6、预置条件要明确，包括测试环境、测试数据、测试场景。
因为许多BUG只有在特定的环境、特定的场景下才可以重现。
没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
\\r 7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。
比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。
步骤写的明确时就利于提高用例的可操作性。
\\r 8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
\\r 9、测试用例级别要划分清楚，这样在测试执行时有主次之分。
\\r 11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。
评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。
\\r 12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。
这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
\\r 13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。
\\r 14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。
并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
\\r 总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。
写出好的测试用例没有简单的公式或规定可以遵循。
即使是多年以来在测试方面感兴趣的人也很难做到这一点。
如何确保测试用例是执行过的
是测试过程中很重要的一部分内容，用例的编写也是一项很考验测试人员对业务知识的理解和分析能力的工作，所以编写用例的水平也能一定程度上反映出测试人员的测试水平，而很多测试人员特别是刚进入测试行业的测试人员，往往都忽视了测试执行的重要性，不屑于做测试的执行工作，觉得测试执行没什么技术含量。
我在之前的两家公司，因为人员结构或者测试组织方面的原因，没执行过别人写的用例，都是自己写好了自己执行。
来到现在公司后，由于项目已经进入了尾声，用例也已经比较完整了，所以就安排我先做用例的执行工作。
一方面在不熟悉业务的情况下，执行用例相对编写用例会简单点，另一方面也可以通过执行用例来熟悉业务。
我执行的用例是我们部门主管写的用例，所以也算是用例交叉执行的一个过程。
在用例的执行过程中，一方面是对我业务理解能力的检验，另一方面也是对用例编写者所编写的用例的检验。
用例的执行环境、前提条件、操作步骤、和预期结果都会影响到用例能否顺利的执行，这些如果都写的清晰了，用例执行的效率也就更高，对业务的理解也就更容易。
对于业务逻辑简单的用例，对着用例的输入步骤和预期结果就可以较顺利的执行，对于业务逻辑比较复杂的，加上一些前提条件可能也没有在用例中说的很完整，就需要通过用例编写人员给予业务逻辑的讲解才能理解，而讲解业务的过程，又是对业务更进一步理解的过程。
我现在参与的项目是OA系统，执行用例过程中，发现在执行多部门协调性要求比较强的业务的用例时，往往需要频繁的登录和退出系统，在用户多的时候，可能容易出错，也不太好保持测试的连贯性。
通过一段时间的用例执行工作，也总结了点经验，和大家分享。
编写优秀的测试报告需要我们做什么
对于第二个问题，除非你是测试主管或者测试经理，否则你还真没有决定权，领导定的模板也是方便部门内部的统一管理。
但是同一套模板每次写的的内容一样么
我们想过没有，第一个问题是不是很大程度上是第二个问题带来的
那么 一、测试功底： 熟练编写测试报告是一个测试工程师的必修课，马虎不得。
老手们可能看几眼你的报告就知道你的水品处在什么层次。
最先展示的地方是你的内功，你“行走江湖”最大的资本，也是最能体现你能力的地方。
对于一份功能测试的报告，应该包括本次测试的目的，结果的概述、总结、分析，用例的执行结果，缺陷结果及分析（收敛趋势等），最后附加一些环境信息（DB，OS、浏览器等），虽然各自的报告可能迥然不同，但是这些共同点还是都需要包括的。
而对这些共同点的概括总结和分析，则是分内之事了。
对于这种“熟练工种”，没有什么特别好的办法，熟能生巧，多写多看多总结，提高自己对测试结果的敏感度，相信量变一定会引发质变的。
二、语言外功： 测试报告是一个文档程度很强的东西，所以编写这玩意很能考察大家的文字功底。
相信各位都有在撰写报告的时候对一些词、一些语句斟酌很久的场景。
的确，我们不仅要实事求是的反应本次测试的结果和问题情况，而且还要让这篇文章的阅读对象接受我们的措词。
同一句话不同的表达方式换回来的结果完全不同，所以测试报告对测试工程师的语言组织功底则是一次摸底考察，看来这方面平时不积累不行啊。
三、面向对象： 在编写报告实际操作过程中，我们要根据这份报告的潜在阅读者来调整，即所谓的面向对象“写报告”，每份报告的模板在固定后，第一眼看上去每份报告基本上一样，那我们怎么来提高这份报告的推广程度
我们可以调整每个模块的顺序和写作偏重点。
如果对象是项目管理者，他可能更关注版本的整体情况以及对整个系统的总结；开发人员可能更关心缺陷的修复情况和收敛趋势；而团队老大则可能要重点查看分析结果等。
我们可以根据不同的“用户”调整我们的侧重点，面向多个对象则要找好这个平衡点了。
四、总结： 测试报告虽然是文档，却体现着编写者的测试和语言功底，因此，不是每个测试人员都可以叫做测试工程师，更别谈熟练了。
不过也没什么，今天不是不代表明天不是。
多看、多写、多总结对于一个测试人员来说是一项重要的“革命”工作。
如何编写测试分析报告
通过分析BUG的数量、性质、分布情况，评价软件的能力和限制。
同时总结软件测试计划的执行情况，作为同类项目测试计划和测试用例的编写参考依据。
\\r1. 测试负责人从BUG管理工具中统计分析BUG的数量、性质、分布情况，提取相关数据，并形成图表。
如：每个测试工作日产生的BUG、关闭的BUG、延迟的BUG；总的BUG数量；BUG模块分布；测试人员发现的BUG数量；开发人员出现的BUG数量；BUG的严重等级分类；模块的千行出错率；被测系统的千行出错率等数据。
\\r2. 具体可参考度量汇总表的有关统计项；\\r3. 测试负责人评价软件能力，包括缺陷和限制；\\r4. 测试负责人评价测试过程本身。
通过和测试计划的比较，对进度、工作量、测试需求和测试范围、测试用例的设计进行评价。
