如何用质量管理方法提升测试用例质量

1. 如何用质量管理方法提升测试用例质量

高层次标准是从满足某一个特定的测试目标出发来进行定义，分析一组测试用例的设计思路、设计方法和策略，包括测试用例的层次、结构等。从高层次看，测试用例设计的关键点是：始终从客户需求的角度(出发)想，始终围绕测试的覆盖率和执行效率不断思考，最终通过有效的技术方法完成测试用例的设计。
　　对于一整套的测试用例组(集合)，领测国际定义出了几点质量标准：
　　(1) 测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。
　　(2) 设计思路正确、清晰。例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。
　　(3) 在组织和分类上，测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致，并具有合理的优先级或执行顺序。
　　(4) 测试用例覆盖所有测试点、覆盖所有已知的用户使用场景(User scenario)，也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。
　　(5) 测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。
　　(6) 有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。
　　(7) 没有重复、冗余的测试用例，满足相应的行业标准等。

2. 如何高效的执行测试用例

测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。

测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例编写准备 
1
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2
根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。

测试用例制定的原则 
1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。

用例覆盖
1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。
6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
7可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
8可移植性：在不同操作系统及硬件配置情况下的运行性。

测试方法
1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

测试用例的填写 
1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。

3. 如何提高测试用例的有效性和高效性

首先是合适的测试样本，比如测试某个功能，它是有一些前提已经存在的，可以理解为一些数据限制。举个例子，比如我们测试一个会记录用户历史数据的软件，对于一个全新的样本和有历史数据的样本是不一样的，样本的不同元素条件也决定了他在做一些操作时软件的反馈是不一样的。
    然后是准确的测试路径，理论上最保险的应该是A*B*C*D*E*F*...个路径。一个流程，就是一条路径，但一个流程中包含了几个环节，每个环节有几种测试边界。根据数学的排列组合，最保险的路径数是不是应该把每个边界数相乘？但这个就不高效了。如果能发现其中不同环节之间的出bug的相连性呢。比如知道在A步骤的第三种边界如果出bug，那在C步骤的第二种边界肯定出bug。或者比如知道在B步骤的第二种边界表现是正常的，那在D步骤的第一种边界肯定也是正常的。那是不是就能省掉一些亢余重复的路径了呢？如果你知道两个步骤中的两个数据都读的数据库中的同一个字段，那这两个步骤显然就可以看一个地方的边界就好了。如果你知道两个地方共用的一个控件，那如果控件出问题，那肯定两个地方都会出问题。所以高效点的测试路径，应该精简为A*(B-M)*(C-N)*D*E*F...再然后如果确定E、F步骤跟A、B、C、D生成的数据毫无关系，那可以再精简为A*(B-M)*(C-N)*D+E*F...我们知道如果对于一次修改，往往不是所有的步骤的边界都受影响的，如果确定出某次改动只影响了A、C、E步骤的边界，那测试路径可以再精简为A*1*(C-N)*1+E*1...上面说的这些都是理论上的数学组合分析，而在实际测试过程中，如果对一个系统比较熟悉，我们只要抓住影响的相关性、影响的不相关性、步骤边界的相互限制，就能抓住几条最高效且有效的测试路径，对一个改动带给一个系统的风险进行测试。
    最后说下明确的测试目的。只要是测试用例，都有测试目的，可能是对一个全新的功能进行测试，可能是对一个改动可能带来的风险进行测试，可能是验证现有的一个功能在某种特定条件下的表现。测试目的一定要明确，这就好比你是要去吃一顿丰盛的午餐，还是去喝杯下午茶，还是半夜饿了爬起来吃点夜宵，我想这其中的区别大家还是可以理解的。更多问题可以加群：333782754

4. 如何编写有效测试用例

测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。
  
 设计、书写和执行测试案例是测试活动中重要的组成部分，测试案例通常由测试案例管理系统或工具进行管理。
  
 测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：
  
 特性：
  
 一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：
  
 测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。
  
 测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：
  
 这些信息建议可以由测试案例自动生成。
  
 测试级别进行说明：
  
 6.测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止 测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
   7.预置条件：对测试的特殊条件或配置进行说明
   8.测试步骤：详细描述测试过程，案例的操作步骤建议少于15个。
   9.预期结果：预期的测试结果
  
 例如：假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关，测试用例的设计如下：
   （1）测试用例ID：TC000001
   （2）测试用例名称：中国移动全球通手机用户成功发送短信给中国联通手机用户
   （3）测试功能点：中国移动全球通手机用户成功短信给中国联通手机用户，中国联通网关返回成功的状态报告
   （4）测试目的：
   A、中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信；
   B、中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。
   （5）测试级别：基本功能测试
   （6）测试类型：功能测试
   （7）预置条件：各网关实体按照组网图中的关系连接好，各实体之间的连接和通信正常。
   （8）测试步骤：
   A、中国移动全球通手机用户（13901000001）给中国联通手机用户（13001000001）发送MO短信，内容为“测试”，目的号码填为中国联通手机号码；
   B、中国联通互联短信网关把短信下发给中国联通用户成功后，给中国移动互联短信网关返回一个标识成功的状态报告。
   （9）预期结果：
   A、中国联通手机用户（13001000001）接收到了短信，内容为“测试”，源号码为中国移动全球通的用户号码（13901000001）；
   B、在中国移动互联短信网关上产生SMO话单，其中“短消息发送状态”填0（表示成功），“源手机号码”13001000001，“目的手机号码”为13001000001。
  
 下面是一个完整的测试用例的模版：
  
   
                                            
 
  
 对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例， 这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。在这个时候，因为对产品没有直接的使用感受，书写测试案例要考虑面广而不要太过精细。继 续阅读产品功能定义文档，将所有的功能定义直接对应写相关的测试案例，这个时候，最好能够对程序的本身有一定的接触，加深对程序的了解，以便写出更好，更 全面的测试案例。最后，在实际测试中，还需要不断扩充，修改以前的测试案例，得到完整的基本功能测试案例和详细测试案例。如果对于一个已有一定或大部分案 例的产品来说，不管测试者是否本身熟悉这个产品，其主要的任务就是阅读，检查需求及相关的变更，然后对原有的案例进行理解，扩充和修改。这就是案例的重用 /复用。设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技 术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。
  
 测试用例设计一般包括以下几个步骤：
   1、测试需求分析从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。
  
 测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
   2、业务流程分析软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建 议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流 程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
  
 从业务流程上，应得到以下信息：
  
 A、主流程是什么
   B、条件备选流程是什么
   C、数据流向是什么
   D、关键的判断条件是什么
   3、测试用例设计
   完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边
  
 界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异
  
 常、性能的情况，以便发现更多的隐藏问题。
  
 黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用
  
 例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测
  
 试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设
  
 计：
  
 功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。
  
 适合的技术：由业务需求和设计说明导出的功能测试、等价类划分
  
 边界测试：对某个功能的边界情况进行测试。
  
 适合的技术：边界值划分
  
 异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，
  
 类似这样的情况需要书写相关的异常测试。
  
 适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、
  
 性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
  
 适合的技术：业务需求和设计说明导出的测试
  
 压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
  
 4、测试用例评审
  
 测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
  
 测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。
  
 5、测试用例更新完善
  
 测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例 进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档 上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。

5. 如何编写有效的测试用例

　测试用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。以上可以看出测试用例在整个测试工作中的地位和作用，以下编写了关于如何写好测试用例的一些个人建议：
　　1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
　　2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
　　3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
　　4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
　　5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
　　6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
　　7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。
　　8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
　　9、测试用例级别要划分清楚，这样在测试执行时有主次之分。
　　11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。
　　12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
　　13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。
　　14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
　　总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。

6. 有哪些比较好的测试用例管理工具

1. word，excel：总体来说excel比word效果更好，看起来条理清晰，根据测试进度做标记也比较方便。缺点是不容易维护，要做好了比较花时间，特别是遇到业务性很强的复杂系统或者遇到多人协作的时候。

2. xmind等：思维导图也可以写用例。一般只列出检查的要点和测试过程中需要注意的地方，具体的操作步骤和测试数据不需要写出来。比较适合做探索性测试。缺点跟excel差不多，多人协作方面是短板。不过最近出了在线编辑xmind的工具，一定程度上能解决这个问题。

7. 测试用例

这边有一些测试用例的一些原则：
1.系统页面必须与照设计文档一致.测试时须检查的地方有:各页面的列名,提示信息等文字描述是否存在错别字.列宽长度是否合适,能否完全显示输入信息.(注意:页面如出现有变量,则须对这些变更的正确性进行验证)
2.测试基础信息录入，必填项必须测试数据录入范围，保证所有的信息能够有效的录入系统。可采用临界值测试法
3.测试与业务有关的功能，必须包证输入金额，日期格式正确，金额方向正确,。可采用先做业务，后做查询的方法验证
4.测试查询功能时必须保证录入查询条件即可查出相应的正确结果.
5.流程测试应保证流程流向能按设计的流程图走,如一个流程结束后才能出下个流程,这时应保证上个流程结束后才能出下个流程,而且上个流程的任务必须是结束状态.测试方法可以用列举法,把所有的情况列举出来后逐步测试.
6.对有可能引起纠纷的业务须重点测试,维护中心形象.(如:余额查询,个人明细查询结息等业务)
7.测试系统性能时应该制定性能测试计划,出具性能测试报告.

8. 测试用例

    1.定义：执行测试的案例
  
     2.如何保证高质量的测试用例？
  
               (1).测试用例覆盖所有的用户需求
  
               (2).测试用例要简单明了
  
               (3).各类型的测试用例要齐全
  
               (4).用最少的用例覆盖最多的需求
  
       3.方法：等价类划分法、边界值分析法、场景法、错误推测法、因果图法、正交实验法、判定表法
  
             (1).定义：把所有可能输入的数据划分为若干个区域，在每一个取少量并具有代表性的数据进行测试。
  
             (2).分类：①.有效等价类：符合需求的数据     ②.无效等价类：不符合需求的数据
  
             (3).案例：①.手机号案例   ②.实名认证
  
              1.定义：取稍高于或稍低于边界值得数据
  
              2.取点：①.左上点：边界左点   ②.右上点：边界的有点 
  
                            ③.左离店：开内闭外   ④.右离点：开内闭外 
  
                            ⑤.内点：区间任意一点
  
              3.边界值与等价类划分法去重：内点和有效等价类一个点重复
  
             1.定义：模拟用户场景
  
             2.分类：①.基本流：正确得流程  
  
                           ②.备选流：不正确流程。在基本流的每一个步骤取反。
  
             3.案例：注册
  
             1.定义：因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。原因就是输入，结                            果就是输出。
  
             2.案例：自动售货机
  
             1.定义：经验丰富的测试工程师
  
             2.案例：手机无法拨通
  
             1.定义：设计测试用例时，分析和表达多输入条件下执行不同操作的黑盒测试方法
  
             2.案例：修车
  
              1.定义：使用正交小助手
  
              2.案例：字符设置
  
           用例编号   所属模块   用例标题   优先级   前置条件  
  
           操作步骤    测试数据    预期结果    实际结果   
  
           1.功能：实际功能
  
           2.UI：和设计图做对比，文字大小颜色、边距、排版、图片清晰度拉伸
  
           3.兼容性：(1).App：手机系统、版本、厂商、型号、屏幕分辨率、屏幕类型
  
                             (2).Web：①.trident内核：IE、360兼容模式、搜狗兼容模式
  
                                              ②.Gecko内核：火狐   
  
                                              ③.Blink内核：Chrome、360极速模式、搜狗极速模式
  
                                              ④.webkit内核:Safari
  
           4.接口：(1).接口功能：postman   (2).接口性能：Jmeter、loadrunner   (3).接口自动化：requests
  
           5.易用性：是否好用
  
           6.性能：压力测试、稳定性测试、负载测试、基准测试
  
           7.安全：密码加密、访问权限、SQL注入、XSS攻击、跨站攻击
  
           8.自动化测试：(1).App UI   (2).Web UI   (3).接口自动化
  
 
  
  
         等价类划分法、边界值分析法、因果图、错误推测法、判定表、正交实验法、场景法
   
                                          
     (1)要求：账号为手机号   (2)密码6-10位数字和字母