育才学习网1. 如何编写测试计划
如何编写测试计划呢？测试计划要包括以下四个要点：1、待测试的内容；2、编写测试用例的时间；3、执行测试用例的时间；4、执行回归测试的时间。以上四点，待测试的内容可以需求分析中取得，需求分析中的测试要点就是要测试的内容，而其它3点就不是很容易确定了。因为我们可以从软件的开发进度中获得开始时间，但很难确定测试的结束的时间。下面有一个预估的办法，是大多数测试工程师的经验所得，我们拿到评审后的需求分析可以用下面的方法预估。
1、计算需求分析的页数，得出测试用例的页数，需求分许页数：测试用例页数 ≈ 1:1
2、由测试用例页数计算编写系统测试用例时间：编写系统测试用例时间 ≈ 系统测试用例页数*1小时
3、计算执行测试用例时间：编写测试用例用时：执行系统测试用时 ≈ 1:2
4、计算回归测试包含的时间：系统测试用时：回归测试用时≈ 2:1
以上的方法可能根据测试人员对项目熟悉程度和测试经验的不同而有所差别，大家可以根据自己的经验做出调整。计算出测试用例、执行测试和回归测试的时间后，根据软件项目的开发进度就可以编写出一个软件测试的时间表了。
不过从目前国内软件公司的现状来说，测试时间一般都不够，所以我们只能延长我们的工作时间，提高我们的工作效率。程序员说他们处于最底层，用户说要改什么，他们就要实现什么，没人关心他们的工作难度和工作时间。（发点牢骚，大家就当没看见，呵呵）
2. 软件测试的测试用例怎么写
● 测试用例编号
◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
◇ 约定：
系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX
● 测试项目
◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
◇ 约定：
系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话
集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口
单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)
● 测试标题
规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
● 重要级别
规则
高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
● 预置条件
规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
● 输入
规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
● 操作步骤
规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。
● 预期输出
规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等
3. 怎么写好测试用例
测试用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。以上可以看出测试用例在整个测试工作中的地位和作用，以下编写了关于如何写好测试用例的一些个人建议：
1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。
8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
9、测试用例级别要划分清楚，这样在测试执行时有主次之分。
11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。
12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。
14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。
4. 如何写一份漂亮的测试用例
我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。
回到测试用例中来，我觉得做好以下三点就是一个好的用例。
第一：依据分明
众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。
假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。
第二：目的明确
用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。
第三：便于统计
测试用例对整个测试过程的质量控制和评估有很重要的意义。
一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。
你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。
三，做缺陷分析。用例失败了，就生成一个缺陷。
5. 如何写测试策略
”。
你要在测试策略中很明确的提出你进行测试时所使用的方法和步骤。 我看到过很多公司严格地按照一些测试策略模板来写。
但是，其实不用模板，你也可以并且更高效地写测试策略。下面是一些简单的写测试策略的技巧， 1）在测试策略中要包括产品的背景信息。
在测试策略文档的第一段回答- stakeholder（项目利益相关者）为什么要开发这个产品？回答这个问题会帮助你更好更快地理解项目，并为所做的事情优先级排序。 2）测试环境，它应该包括你在那个操作系统平台上做测试，系统是基于那些补丁和安全更新。
例如，一个测试环境可能必须包含Window XP SP2 3）列出你将要测试的所有重要特征。如果你认为有些特征不属于本次发布的一部分，那么就标注“不会被测试的特征”。
4）写下在此项目测试中将应用到的测试方法。清楚的列出你将以那些类型的测试作为测试引导。
例如：功能测试，用户交互界面测试，集成测试，压力测试，安全测试等等。 5）回答以下问题：你如何进行功能测试？手动还是自动化？测试工具是什么？你将执行在测试管理工具中的所有测试用例吗？ 6）用什么作为测试错误报告跟踪工具？当测试人员发现一个新的bug之后，流程应该是什么？ 7）测试进入和结束的标准分别是什么？ 8）如何去跟踪测试进度？什么度量可以用来记录测试结束？ 9）任务分布 – 定义每个组员的角色和职责，包括测试组长，测试员，项目经理等。
测试战略将由开发人员review，确保测试的覆盖率全面且没有重叠处。测试经理和部门经理都要同意测试策略之后，测试工作才能展开。
测试小组的划分及分工。 10）有哪些风险会阻碍测试的完成？例如，代码的依赖性，测试工具的局限性等等。
要提前想到风险发生的解决办法。 11）测试日程表- 每个测试计划都应该包含一个预估时间来估计完成测试所需要的时间。
这需要几个阶段：一，测试人员必须至少完成一次的执行全部用例。二，如果一个错误被测试人员发现，开发人员将修复此错误。
测试员重新测试此用例，直到其功能正确为止。最后，但很重要的一点是测试员必须对修改过的地方执行回归测试以保证开发人员在修复一个错误的时候没有引入另外的代码错误。
测试日程表要包含每个测试部分涉及的测试人员。时间往往很难估计，因为测试中有很多不确定性的事情发生。
其中一个比较好的办法是参照前一个发布来估计。 12）回归测试的方法- 一个错误被修复后，必须要保证产品功能按用例标准运行。
回归测试是为了在修复一个问题时不引入另外的错误。因此相关的测试用例要在被执行一次，从而确保没有特殊的东西被引进。
在这个阶段，就要定义回归测试的方法。有的公司讲相关模块的单元测试用例全部遍历一遍，从而确保产品的质量。
弄清楚这些问题，你就可以写一个详细的测试策略出来了。
6. 如何写出好的测试用例
一个好的测试用例是每个人都能执行的测试用例，不管你是否是测试人员，不管你是否了解整个软件的工作流程，你都能顺利的执行完测试用例，并对这个测试用例覆盖到的功能点有了大概的了解。
好的测试用例的设计相当了软件开发中的详细概要设计，要写出好的测试用例首先要对所测试的软件很熟悉，熟悉软件的每个功能点和系统的整个业务流程。其次，对整个测试用例有个好的规划，理清主线，功能点的在哪个地方被覆盖都是需要考虑的。
最后，需要良好的心态，写测试用例是个繁琐的过程，测试用例不是随随便便就能写出来的，好的测试用例更需要你在写的过程中不断去理清思路，并把每个功能点都恰当的写进去。 测试用例的规划： 用例的规划非常的重要，它决定整个测试用例的思路、风格、覆盖率。
即对整个测试用例的成败都有直接的响。对测试用例的规划我个人总结出两条思路：一条是用例的线性规划，另一条是功能点覆盖型。
这两条思路的侧重点各不相同，各有优缺点。线性的测试用例的要点是在理清每一条思路，即以业务线和流程线为主，每一条线都是一个流程，然后把功能点穿插到每条线里去。
把每条业务流程比作竖线，功能线比作横线，那么功能点就是横线和竖线的节点，这样整个用例就是一张大网，我们可以随时向网中添加横线或竖线，使得覆盖率不断增加，“漏网之鱼”越来越小。 另一种思路是功能点覆盖型。
在设计之前把要整套软件的功能点理清楚，这当然是非常的难的。但我们可以参考系统设计的功能流程图，软件的需求来进行分析和提取。
还有一点就是测试人员的经验来完善所需要的功能点。这种思路的重点是把每个功能点都要在设计中体现出来，以功能点覆盖为主，不管工作的业务流程。
也就是说是按照各个功能模块进行划分的，分模块进行用例的设计。 两种思路相辅相承，各有各的优点。
在实际的执行过程中，有时以业务流程来编写比较容易，有时以功能模块编写比较容易。一个是以线为主，一个是以块为主。
测试用例的设计： 规划好测试用例的整体思路之后，就是测试用例的具体设计设计了。用例的设计的格式主要由测试环境，准备数据，前置条件，用例ID，预期输入值，期望输出结果，测试执行结果和优先级等几个部分组成。
其余的还有一些统计页，打印输出的模板等。个人认为用excel设计比较简便，excel可以有多个页面，一个页面为统计测试结果和用例维护，一个为测试用例的主页面，还有一个页面可以放一些打印后的模板。
这样的设计有利于用例的维护。 用例的预期输入值和操作步骤是用例设计最重要的部分。
设计好这两个部分对经后测试用例的执行至关重要，特别是操作步骤的描述，要描述清楚每一步的操作步骤，这样才能让测试的执行者准确操作，不会产生歧义。用例所写的每一句话都应该清晰的，没有歧义的，否则就会出现用例维护时，其他测试人员看不懂你写的是什么，测试用例执行的时候，看着很费力，达不到文中刚开始的要求。
测试用例的维护： 每个测试用例都要在经后执行的过程中去维护修改，使得测试用例的覆盖率不断提高。特别的测试用例的第一个版本时，需要维护的量是非常大的。
我们可以边测试边修改测试用例，也可以根据需求添加测试用例。每维护一次测试用例，就必修记录下你修改的内容，以便于经后的阅读和别人的维护。
以上是我近期对于测试用例设计的理解，也是我近期工作的一个总结和体会，测试用例设计是一门高深的技术，也是软件测试的重要组成部分，我们需要经验来不断提升用例的质量，设计出好的测试用例。
7. 如何写测试用例
测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例编写准备
1
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2
根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
测试用例制定的原则
1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
用例覆盖
1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。
6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
7可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
8可移植性：在不同操作系统及硬件配置情况下的运行性。
测试方法
1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
测试用例的填写
1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。