软件测试的过程管理
一.软件测试的各个过程（PDCA）
1.测试需求的分析和确定 2.测试计划 3.测试设计 4.测试执行 5.测试记录和缺陷跟踪 6.回归测试 7.测试总结和报告
二.测试需求
1.需求规格说明书的检查要点
正确性：对照原始需求检查需求规格说明书
必要性：不能回溯到出处的需求项可能是多多余的
优先级：恰当划分并标识
明确性：不使用含糊的词汇
可测性：每项需求都是必须可验证的
完整性：不能遗漏必要和必须的信息
一致性：与原始需求一致、内部前后一致
可修改性：良好的组织结构使需求易于修改
三.需求文档的检查步骤
（1）获取最新版本的软件需求规格说明书，同时尽量取得用户原始需求文档
（2) 阅读和尝试理解需求规格说明书中描述的所有需求项
（3）对照需求规格说明书检查列表进行检查并记录
（4）针对检查结果进行讨论、修订需求规格说明书后回到第一步，直到检查列表中的所有项通过
举例：
1. 是否覆盖了用户提出的所有需求项
2.用词是否清晰，语义是否存在有歧义的地方
3. 是否清晰地描述了软件系统需要做描述及不做什么
4.是否描述了软件使用的目标环境，包括软硬件环境
5.是否对需求项进行了合理的编号
6.需求项是否前后一致、彼此不冲突
7.是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系
8.是否清晰描述了软件系统的性能要求
9.需求的优先级是否合理分配
10.是否描述了各种约束条件
四、通过编写测试用例来检查需求
测试人员通过构建并尝试回答设计的黑盒测试主要是为了测试需求的完备性，准确性，明确性以及简明性等需求问题。
五、测试的计划
1.确定测试范围
2.制定测试策略： （1）测试战略：测试的先后次序，测试的优先级，测试的覆盖方法、回归测试的原则等。
（2) 测试战术：采用的技术、架构、协议等。
3.安排好测试资源：通过充分估计测试的难度，测试的时间、工作量等因素，决定测试资源的合理利用。
4.安排好进度：测试的进度需要就结合项目的开发计划。产品的整体计划进行安排，还有考虑测试本身的各项活动进行安排。
5.计划风险：对测试过程可能碰到的风险进行估计，制定出相应的应对策略。
六、测试的设计及测试用例
1.基于需求的测试方法
RBT是基于需求的测试方法，会使得测试更加有效，因为他使测试专注于质量问题产生的根源。
基于需求的测试时一种最根本的软件测试，重点关注以下两大关键问题
（1）验证需求是否正确、完整、无二义性，并且逻辑一致
（2) 要从‘黑盒‘的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
2.等价类划分法
等价类是指某个输入域的集合，在这个集合中每个输入条件都是等效的。
等价类划分法人为，如果使用等价类中的一个条件作为测试数据进行测试不能发现程序的缺陷，那么使用等价类中的其他条件进行测试也不能发现错误。
等价类是典型的黑盒测试方法，不需要考虑程序的内部结构，只需要考虑程序的输入规格即可。
分类两大等价类 ：1.有效等价类：满足条件的，2.无效等价类：不满足条件的
等价类分法虽然简单易用，但是没有对组合去年高考进行充分的考虑，需要结合其他测试用例设计的方法进行补充。
3.边界值分析法
假设大多数的错误发生在各种输入条件的边界上，如果在边界附近的取值不会导致错误，那么其他取值导致出错的可能性也很小。
边界值分析法的优点是简单易用，只需要考虑单个输入的边界附近的值，并且这种方法在很多时候是非常有效的揭露错误的方法。但是他们跟等价类划分的方法一样没有考虑输入直接的组合情况，因此需要进一步结合其他测试用例设计方法。
4.等价值+边界值
通常结合等价类划分和边界值分析法，对软件的相关输入域进行分析，常见的分析域包括整数，实数，字符串和字符，日期，时间，货币等。
5.基本路径分析法
基本路径分析法一般使用在白盒测试中，用于覆盖程序分支路径，但是在一些黑盒测试中也能使用。
基本路径分析法的重点在于覆盖流程，确保让程序体现所有可能的逻辑。但是这种方法也存在一定的缺点，就是基本路径分析法只覆盖一次流程，对于一些存在循环的流程没有考虑。因此还需结合其他的测试用例设计方法进行考虑。例如错误猜测法，场景分析法。
6.因果图法
因果图是一种简化了的逻辑图，能直观地表明程序输入的条件和输出的动作之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
因果图法设计测试用例步骤
1、分析所有可能的输入和可能的输出
2、找出输入与输出之间的对应关系
3、画出因果图。
4、把因果图转化成判定表
5、把判定表对应到每一个测试用例
通过画因果图能更加清楚输入条件之间的逻辑关系，以及输入与输出之间的关系。缺点需要画图和转换成判定表，对于比较复杂的额输入和输出会需要花费大量的时间。
7.场景设计法
现在的软件大部分是由事件触发控制流程的，事件触发时的情景就是所谓的场景。在测试用例设计过程中，通过描述事件触发时的情景，可以有效激发测试人员的设计思维，同时对测试用例的理解和执行也有很大的帮助。
场景设计法需要测试人员充分发挥对用户实际业务场景的想象。
8、错误猜测法
错误猜测法用过基于经验和直觉推测程序中可能发生的各种错误，有针对性地设计测试用例。因为测试本质上并不是一门非常严谨的学科，测试人员的经验和直觉能对这种不严谨性作出很好的补充。
9.正交表
正交表法是一种有效减少测试用例个数的设计方法。
正交表设计测试用例的步骤
（1）确定有哪些因素。例如，姓名，性别，状态，三个因素
(2) 每个因素有哪几个水平。水平是指输入条件的参数，例如上面姓名就有填写与不填写两个水平
（3) 选择一个合适的正交表
举例：即假设有姓名，性别，状态 三个因素， 每个因素分别都有两个水平分别为 填，不填，男，女，激活，未激活
即可以使用正交表L4（2^3） 4表示需要执行四个用例，3表示因素数，2表示水平数
这个正交表如下 0表示一种水平 1表示另外一种水平
0 0 0 ： 第一条用例：填 男 激活
0 1 1 ：第二条 ： 填 女 不激活
1 0 1 ： 第三条 ： 不填 男 不激活
1 1 0 : 第四条 : 不填 女 激活
如果不用正交表 那么则需要执行8条，就不一一写了
应用正交表进行测试的难点是查找合适的正交表。
地址：http://support.sas.com/techsup/technote/ts723_Designs.txt
10、利用均匀实验法设计测试用例
利用均匀实验法设计测试用例与利用正交表法类似，同样需要经过分析输入条件和参数、选择合适的均匀表、影射因素和水平，转换成测试用例等几个步骤。
11.组合覆盖与PICT的使用
组合覆盖法是另外一种有效减少测试用例个数的测试用例设计方法。根据覆盖程度不同，可分为单因素覆盖，成对组合覆盖，三三组合覆盖。成对组合覆盖最常用。
成对组合覆盖要求任意两个因素（输入条件）的所有水平组合至少要被覆盖一次。
PICT就是实现了组合覆盖的算法。
PICT的使用：
PICT接收一个纯文本，然后输出测试用例集合
格式如下
NAME : VALUE1, VALUE2,VALUE3....
通过PICT > PICT "text.txt" > "output.txt' 即可倒出测试用例
12.分类树和TESTONA的使用
通过分类树把测试对象的整个输入域分割成独立的类。
使用分类树方法，对于测试人员来说最重要的信息来源是测试对象的功能规格说明
它把测试用例设计转变成一个组合若干结构化和系统化的测试对象组成部分的过程-使其容易把握，理解，也易于文档化。
步骤：
1、识别出测试对象并分析输入空间
2、对测试对象的输入空间进行分类
3、画出分类树，组合成测试用例
分类树设计测试用例的核心思想就是分类树的构建，而TESTONA就是一个设计分类树的工具。
13.测试用例的粒度
（1）测试用例写的过于复杂或详细，会带来两个问题，一个是效率问题，另一个是维护成本问题
（2）测试用例写的过于简单，则可能失去测试用例的意义。
七、测试的执行
需求的分析和检查、测试的计划、测试用例的准备，都是为了执行测试准备的。
1、测试用例的合理选择
（1）对于第一次执行的测试，一个基本的测试用例选择策略是：先执行基本的测试用例，在执行复杂的测试用例；先执行优先级高的测试用例，再执行优先级低的测试用例。
（2）对于回归测试的测试用例选择复杂一点。
2、测试的分工与资源利用
测试的分工能避免测试人员的思维局限性，同一个用例不同人来执行，可能会发现不同的问题。
3. 测试环境的搭建
（1）徐璈使用大量数据，如容量测试，压力测试
（2）外部硬件设备
（3）多种操作系统
（4）部署多台机器
（5）网络设备、网络环境配置
4.BVT测试与冒烟测试
BVT测试，也叫编译检查测试，主要检查源代码是否能正确编译成一个新的、完整可用的版本。如果BVT测试不通过，则测试人员不能拿到新的版本进行测试。
冒烟测试，就是在一个编译版本出来后，先运行他的最基本的功能，如果醉简单的运行都有错误，那么测试人员就没有必要进行下一步的深入测试。冒烟测试的测试用例应该是随着开发的深入而不断演进的。
BVT测试和冒烟测试的目的是检查程序是否完整，是否实现了最基本的可测试性要求。能减少测试人员不必要的工作量。BVT测试和冒烟测试时所用正式测试执行之前的第一个步骤。
八、测试的记录和跟踪
1.Bug质量衡量：作为一个测试人员，一定要把Bug描述清晰。
2.录入一个合格的bug报告一定要包括以下内容
1.发现问题的版本：有助于开发人员分析和总结问题出现的集中程度
2.问题出现的环境 ：操作系统环境，软件配置环境等等
3. 问题重现步骤 ：尽量把操作步骤缩减到必须要执行才能重新错误的几个步骤
4.预期行为的描述 ：有预期才有错误
5.错误行为的描述
3.Bug报告注意的问题
1、不要有错别字 2、不要把几个Bug录入同一个问题区域中 3.附加必要的截图和文件
4.跟踪一个Bug的生命周期
New: 新发现的Bug，未经评审决定是否指派给开发人员进行修改
Open：确认是bug，并且认为需要进行修改，指派给相应的开发人员
Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
Rejected：认为不是Bug拒绝修改
Delay：暂时不能（不需要）修改，延后修改
Closed，回归验证通过，Bug关闭
Reopen：经验证Bug依旧存在，重新打开。
回归测试
重复执行相同的测试很多遍
基于风险的回归测试
本质是评估系统不同部分蕴含的风险，并专注于测试那些最高风险的地方。这个地方可能让习惯的某些部分缺乏充分的测试，甚至完全不测，但是他保证了这样的风险是最低的。
九、测试总结和报告
1 。缺陷分类报告 可分为
缺陷类型分布报告 ：缺陷的类型分布情况，一般用饼图柱状图。
缺陷区域分布报告 ：不同功能模块出现的情况，饼图，柱状图
缺陷状态分布报告：描述缺陷中各种状态的比例情况，例如open eixed closed分别占了百分之多少
2.缺陷趋势报告
主要描述一段时间内的缺陷情况
3.经典缺陷与bug模式
对缺陷进行总结归纳
经典缺陷满足条件：重复出现，经常出现 ，能代表某种类型的错误 能通过相对固定的测试方法或手段来发现这些错误。
提炼Bug模式
（1）分析缺陷报告，找出经常出现的bug类型
(2）分析bug的根源，找到Bug产生的深层次原因
（3）分析找到Bug的方法，总结如何才能每次都发现这种类型的Bug