转载自http://www.51testing.com/html/68/n-3724968.html

一、需求审查方面

　　首先我们从最开始接触的文档开始，那就是测需求文档;需求审查主要是我们对需求文档的理解，并熟透整个系统的每个功能和流程，对后期所有的测试建立思路，后续的工作基本依照需求进行操作，所以需求审查是一个很重要的一步。

　　对于初次进行需求审查，我采用我以前文章的方向方法，看完每一个模块，就将这个模块的功能流程做成流程图。依次扩大，就将整个需求流程了解清楚，每次将流程图多浏览几次，差不多流程就这样熟透！

　　1、 需求变更

　　需求变更让我们测试人员，在其中吃透苦头，每次需求的变更导致我们前期的工作好多都需要重新开始(流程图，测试点的提取，测试用例)。导致后续工作难于开展或经常出现变更。

　　2、 需求不明确

　　对于青少年足球系统而言，需求全来自教育厅，里面同样有很多需求不明确，全过程尽量与教育厅的需求进行延伸，然后结合开发人员实际开发的效果，进行测试过程！

　　二、提取测试需求的过程:

　　测试点提取我们依据每个测试阶段的测试输入的文档(需求分析)结合前面的需求分析的审查，覆盖测试需求和隐藏的业务需求，我们后期的测试，全是建立在提取的测试点之上进行的，可以说测试点提取是后续工作进展必要必经路径。主要步骤就是，将每个模块可能存在的问题全部罗列出来，并对其最初可以输入或者流程路径的不同，将每个测试点细分，写成文档！

　　测试点提取的方法:

　　1、测试需求分析法

　　2、功能点分析法

　　3、业务流程分析法

　　4、节点分析法

　　5、顺序提取法

　　6、流程判断法

　　在测试点提取的过程中，测试人员主要存在的问题是，除了输入框，链接，按钮，文字显示等外，流程测试点是最难提取的(提取此处测试点需要了解整个流程)，我们采取的方式是，多阅读需求书，并且按照我们的思路将流程图做出来，在提取测试点，最终交于指导老师处，一对一的修改，另一方面，就是对那些隐藏的测试点提取，对于初次做项目测试的我们，基本没有择，只能和指导老师一起寻找和编写！

　　●测试点提取不局限于任何一种特定的方法。

　　●很多时候测试点提取需求用到很多测试点提取方法

　　●测试点提取需要根据测试阶段，测试输入文档以及测试对象进行合理的方法选择。

　　●测试点提取完毕后不等于已经测试点提取完毕，还需要我们再次进行测试点的审查，以防有遗漏或者是泛泛的情况

　　●一份好的测试点提取文档不但能够覆盖所有业务分支和功能点，而且能够将相关隐藏需求体现出来

　　三、测试用例设计

　　测试用例是为特定的目的而设计的一组测试输入，执行条件和预期结果，以便测试某个程序路基和核实是否满足某个特定需求！

　　在做功能测试时我们唯一能做的就是保证这个业务逻辑的正确性以及各个功能的尽可能的正确。业务和功能的正确性就要你自己去判断了，我只是简单写下输入、输出方面功能的测试。

　　作为一位功能测试人员，主要的职能就是进行测试用例的设计上，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例提取，也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视,现就对”四川省青少年校园足球信息化管理系统”设计测试用例的流程和思路进行总结:

　　1)首先要对测试用例的组织结构进行划分

　　在进行需求评审的时候，我们就应该根据需求对测试用例的结构进行分类，对于我们现在做的青少年足球系统相对较大型的管理系统，那么测试用例就可以根据功能模块来进行分类

　　对测试用例的组织结构进行划分的思路，主要根据需求文档的测试切入点来进行参考。

　　2)根据功能点细致地设计测试用例

　　进行完需求评审后，我们将会根据需求文档及自己所负责的工作提交自己的设计文档来进行评审，可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例，如果是管理模块，首先可以将增删查改功能作为第一层功能点，然后再根据必填项非空判断、输入格式验证来作为第二层功能点；

　　划分好功能点后，就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例，并且可以进行标注，这样对于后期的测试用例整理相当有帮助。

　　3)执行完一轮测试之后，都要对测试用例进行补充和整理

　　执行完一轮测试之后，都会对所测试的内容有进一步的了解，并且开发人员在实际开发过程中，会对某些功能的细节部分做出一些修改，测试人员应该根据变更和熟悉程度对之前编写的测试用例进行完善，主要是对测试步骤的修改和异常情况的补充，提高测试用例对需求的覆盖率，以便能发现更多的BUG。

4)测试结束之后，根据测试用例整理出测试思路进行总结

　　测试结束之后，测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期，在此期间，再看看被自己不断完善的测试用例，根据用例中的标注，可以将之前的测试思路很条理地整理出来，反思有哪些地方考虑不足，这就是经验积累。

　　做好这些工作之后，在面对领导问你功能测试会测试到哪些功能，会测试哪些情况，执行一轮测试所需的大概时间问题时，测试人员就可以根据自己编写的测试用例进行流利回答。套用郭德刚的一句词：做科学的人都是很严谨的。大家作为都是有身份证的测试人员，只有工作做得细致严谨，自身的水平才能得到提高。

　　A.测试用例该如何设计(总)

　　在软件测试工作中，测试用例设计和编写时最重要的，测试用例是测试工作的指指导，是软件测试的必须遵循的原则，更是软件测试质量稳定的基本保障！

　　1.     测试用例的测试

　　个人认为，简单来说，就是方法+经验，即比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累！

　　设计入手:

　　ü 菜单树

　　ü 需求规格书，模块的详细规格图

　　ü 软件的基本雏形

　　ü 相关标准规格(软件规格书)

　　设计步骤

　　自我认为多看需求文档，多与需求设计人员沟通，至少保证覆盖需求规格说明书和菜单树的各项功能。

　　ü 根据需求规格和菜单树得出基本功能测试用例；

　　a)等价类划分法

　　将输入范围进行划分，测试每个等价类的代表性数据等同于测试该类的其他数据。确定有效和无效等价类，一个等价类，如果有充足理由，可以再划分为多个更小一些的等价类。部分更小一些的等价类，就凭借个人经验和用户角度去考虑取舍。

　　b)功能，路径混合分析法:即实现某功能，从进入功能实现——退出的各种路径的操作组合。

　　进入:如果只有一种进入方式，则就没必要描述了，2种或者2种以上的进入方式，则需要分别描述。常见的进入方式:主菜单进入，链接进入！

　　功能实现:通过主页导航界面进入并实现相关功能

　　退出;为实现和已实现的功能退出

　　ü  边界值测试用例(所谓边界条件，是指输入和输出等价类中那些恰好处于边界，或超出边界，或在边界一下的状态)

　　a)输入值

　　b)输出值

　　c)边界状态

　　在我们的足球管理系统中，对照片的缩放，就用到这一块！

　　d)其他边界

　　ü  容错测试用例(错误猜测主要是一项依赖于直觉的非正式的过程，其基本思想是列举出可可犯的错误或者错误易发生情况的清单)

　　a)0或者空值

　　b)负数

　　c)删除源文件内容

　　我们在赛事测试的过程中，设计上传参赛表明表，在测试过程中，我将部分信息删除，进行测试！

　　ü  并行测试用例(即多个功能同时进行，比如:在青少年足球系统中，我们需要在发布赛事以后，同时进入公示，并且下级报名依然不能给报名)

　　a)并行测试与交叉测试的区别

　　1.交叉测试是当一个功能运行时，另一功能打断了原来事件的执行，属于被动；并行测试不会中断原有程序，是一个主动发起多功能。

　　2.交叉测试发送在一瞬间，并行测试营同时运行一段时间。

　　ü串行测试用例(主要是单个模块内一串深层次路径的测试，采用自顶而下的方法，从程序的顶部一直访问至程序顶部)

　　比如:像我们青少年足球系统，我从首页进入赛事发布成功进入公示页面，然后再往上级返回到网页首页！

　　ü  交叉测试用例（交叉测试，即是中断测试，当一个事件执行时，另一事件中断原有事件的执行。）

　　a)两不写

　　1.操作时间过短，如:我们按下首页的赛事发布管理按钮

　　2.使用概论低的界面，如:我们青少年足球系统中，下面的脚码出的超链接，我们很少点击

　　b)两必写

　　1.操作时间长，如:在我们的青少年足球系统中，登陆账号后，30分钟对网页没有做任何处理，是否有报警触发。

　　ü 极限测试用例(压力测试，就是个软件施加一定的压力，从而找出中的错误)

　　这一块我在整个系统使用的很少，还处于学习阶段！

　　a)测试用例的检查

　　1.检查，写完后自己在重头到尾的检查一遍，然后再拿给我们的小伙伴一起查看

　　2.试用，测试用例写完后应该有一个使用期，在我们使用的过程中发现漏写或者不合适的地方，应及时增加或者更改。

　　b)“期望结果”与”测试方法”混淆，”期望结果”中出现原本该书写在”测试方法”的步奏

b)“期望结果”与”测试方法”混淆，”期望结果”中出现原本该书写在”测试方法”的步奏

　　c) 但是上面是错误的，应该按照下面方法进行设计编写

　　B.再次总结测试用例设计的要点，注意事项

　　测试用例设计是个不断思考的过程，首先要搞清楚自己所测试的软件系统的需求和功能，以及所有能变化的因素，将这些功能点列成一个设计框架，在分别细化各个功能点的测试方法和期望结果，细化过程中，通过等价类划分，正交矩阵等方法来详细各个测试点，保证覆盖的充分性，同时站在用户的角度，考虑用户常用和不常用的操作路径，依次来取舍测试要点，最后考虑设计步奏中的七种测试类型是否需要添加相应用例。

　　测试用例设计也是个不断优化的过程，平时发现的bug，总结经验，积累更多的经验，测试用例也会更全面，软件品质也能得到更好的保障！

　　四、测试报告缺陷的提交和编写

　　A.强调这一块的重要性！

　　下面就是我们在测试过程的满足的条件:

　　精简的：缺陷的描述应该是清晰而简要的。

　　正确的：提交的问题确实是一个缺陷。

　　中立的：对缺陷及其特征进行实事求是的描述，避免夸张、幽默、讽刺的态度，避免在测试缺陷报告中带有个人感情色彩，因为这种感情色彩可能会影响团队之间的合作和沟通。

　　准确的：准确而明白地描述问题，不仅对做了什么进行描述，而应该对发生或者发现了什么进行描述。

　　隔离：尽量寻找简短的步骤复现缺陷，即将缺陷进行隔离。

　　推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等。

　　复现：确定系统是否可以复现这个问题，以及复现该缺陷的步骤。对于能够复现的问题，应该提供简单的步骤和输入

　　证据：如同写测试用例需要测试条件一样，在缺陷报告中，需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距，以及提供测试的依据。

　　评审：在提交缺陷报告之前，最好有一个有经验的测试人员阅读一遍。　 

　　缺陷报告编写的过程:

　　B.缺陷报告的提交

　　缺陷报告的提交，在测试过程中，我们采用了两种方式

　　1、提交给我们的指导老师！接下来的工作就是指导老师与相关开发人员沟通（这种提交的方式是我们前期的提交方式）

　　2、便是跳过我们的指导老师，直接将问题和呈现过程交于开发人员，并且让其快速修复！(这种方式比较快捷，能够快速的解决问题和加快开发的过程)

　　C.如何编写好的(易读)的缺陷报告

　　1、标题(简单明显，不需要含有修饰语)

　　2、执行动作（步骤）

　　3、预期与实际结果

　　D.缺陷报告的返回，检验是否修改！

　　此环节，主要在我们提交缺陷报告后，开发人员将缺陷报告再次返回与我们测试人员，测试人员主要是检查缺陷报告上面的问题是否已经修复，一遍我们能够提交缺陷报告和了解缺陷的修复情况！

　　E.并描述与开发人员的交互过程

　　在我们与开放人员交互的时候：交互过程中存在的问题，当部分子功能模块做出来的时候，我们测试人员开始测试子功能模块的时候，测出问题的时候，我们便直接与开发人员提出此问题，可能是刚开始合作，还有他们对自己写的代码还有强烈的自信感！对我们的问题采用避让的方式，在我们继续的讲述和演示功能的过程，才得以让他们信服。现在这些问题都不存在，都能够在规定的时间完成每个功能的修复！

　　F.过程中的问题如何解决

　　输入框和文字显示在此不做详细说明，我在项目中主要是承担逻辑很强的赛事模块，这块设计的逻辑和流程交互挺多，除此测试这块的时候很难把握流程问题，整个项目在随时改变和需求分析存在一定的差异，所以造成这块测试逻辑流程比较难以实施，为了更好的完成测试，我采用了，进行测试之前，然相关模块开发的人员演示一下流程，让我更好的进程下一步测试！

　　G.最后对测试缺陷报告的综述(好方法，注意事项，怎样才能够做好测试缺陷报告)

　　测试执行过程注意事项：

　　注意前提条件和特殊说明

　　测试用例要全部执行

　　不要忽视任何偶然现象

　　加强测试过程的记录

　　详细预期与实际的不一致等

 

性能测试：

https://blog.csdn.net/zoulonglong/article/details/78696428