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)“期望结果”与”测试方法”混淆，”期望结果”中出现原本该书写在”测试方法”的步奏
c) 但是上面是错误的，应该按照下面方法进行设计编写
B.再次总结测试用例设计的要点，注意事项
测试用例设计是个不断思考的过程，首先要搞清楚自己所测试的软件系统的需求和功能，以及所有能变化的因素，将这些功能点列成一个设计框架，在分别细化各个功能点的测试方法和期望结果，细化过程中，通过等价类划分，正交矩阵等方法来详细各个测试点，保证覆盖的充分性，同时站在用户的角度，考虑用户常用和不常用的操作路径，依次来取舍测试要点，最后考虑设计步奏中的七种测试类型是否需要添加相应用例。
测试用例设计也是个不断优化的过程，平时发现的bug，总结经验，积累更多的经验，测试用例也会更全面，软件品质也能得到更好的保障！
四、测试报告缺陷的提交和编写
A.强调这一块的重要性！
下面就是我们在测试过程的满足的条件:
精简的：缺陷的描述应该是清晰而简要的。
正确的：提交的问题确实是一个缺陷。
中立的：对缺陷及其特征进行实事求是的描述，避免夸张、幽默、讽刺的态度，避免在测试缺陷报告中带有个人感情色彩，因为这种感情色彩可能会影响团队之间的合作和沟通。
准确的：准确而明白地描述问题，不仅对做了什么进行描述，而应该对发生或者发现了什么进行描述。
隔离：尽量寻找简短的步骤复现缺陷，即将缺陷进行隔离。
推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等。
复现：确定系统是否可以复现这个问题，以及复现该缺陷的步骤。对于能够复现的问题，应该提供简单的步骤和输入
证据：如同写测试用例需要测试条件一样，在缺陷报告中，需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距，以及提供测试的依据。
评审：在提交缺陷报告之前，最好有一个有经验的测试人员阅读一遍。
缺陷报告编写的过程:
B.缺陷报告的提交
缺陷报告的提交，在测试过程中，我们采用了两种方式
1、提交给我们的指导老师！接下来的工作就是指导老师与相关开发人员沟通（这种提交的方式是我们前期的提交方式）
2、便是跳过我们的指导老师，直接将问题和呈现过程交于开发人员，并且让其快速修复！(这种方式比较快捷，能够快速的解决问题和加快开发的过程)
C.如何编写好的(易读)的缺陷报告
1、标题(简单明显，不需要含有修饰语)
2、执行动作（步骤）
3、预期与实际结果
D.缺陷报告的返回，检验是否修改！
此环节，主要在我们提交缺陷报告后，开发人员将缺陷报告再次返回与我们测试人员，测试人员主要是检查缺陷报告上面的问题是否已经修复，一遍我们能够提交缺陷报告和了解缺陷的修复情况！
E.并描述与开发人员的交互过程
在我们与开放人员交互的时候：交互过程中存在的问题，当部分子功能模块做出来的时候，我们测试人员开始测试子功能模块的时候，测出问题的时候，我们便直接与开发人员提出此问题，可能是刚开始合作，还有他们对自己写的代码还有强烈的自信感！对我们的问题采用避让的方式，在我们继续的讲述和演示功能的过程，才得以让他们信服。现在这些问题都不存在，都能够在规定的时间完成每个功能的修复！
F.过程中的问题如何解决
输入框和文字显示在此不做详细说明，我在项目中主要是承担逻辑很强的赛事模块，这块设计的逻辑和流程交互挺多，除此测试这块的时候很难把握流程问题，整个项目在随时改变和需求分析存在一定的差异，所以造成这块测试逻辑流程比较难以实施，为了更好的完成测试，我采用了，进行测试之前，然相关模块开发的人员演示一下流程，让我更好的进程下一步测试！
G.最后对测试缺陷报告的综述(好方法，注意事项，怎样才能够做好测试缺陷报告)
测试执行过程注意事项：
注意前提条件和特殊说明
测试用例要全部执行
不要忽视任何偶然现象
加强测试过程的记录
详细预期与实际的不一致等
