软件测试过程模型或软件测试生命周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。由于测试过程管理牵涉的范围非常广泛，包括过程定义、人力资源管理、风险管理等，我们仅从前面介绍的软件测试过程模型来介绍软件测试过程管理的思想。
现代软件测试过程管理不是仅锁定在测试阶段，软件测试过程管理在各个阶段的具体内容是不同的，但在每个阶段，测试任务的最终完成都要经过从计划、设计、执行到结果分析、总结等一系列相同步骤，这构成软件测试的一个基本过程。通过软件测试过程管理我们要尽量达到测试成本最小化、测试流程和测试内容完备化、测试手段可行化和测试结果实用化的理想目标。
软件测试是软件工程中的一个子过程，为使软件测试工作系统化、工程化，必须合理地进行测试过程管理，包括签订第三方独立测试合同、制订测试计划、组织项目人员、建立项目环境、监控项目进展等等。软件测试过程管理主要集中在软件测试项目启动、测试计划制定、测试用例设计、测试执行、测试结果审查和分析，以及如何开发或使用测试过程管理工具。概括起来包括如下基本内容：
(1) 测试项目启动
首先要确定项目组长，只有把项目组长确定下来，就可以组建整个测试小组，并可以和开发等部门开展工作。接着参加有关项目计划、分析和设计的会议，获得必要的需求分析、系统设计文档，以及相关产品/技术知识的培训和转移。
(2) 制定测试计划
确定测试范围、测试策略和测试方法，以及对风险、日程表、资源等进行分析和估计。
(3) 测试设计和测试开发
制订测试的技术方案、设计测试用例、选择测试工具、写测试脚本等。测试用例设计要事先做好各项准备，才开始进行，最后还要让其他部门审查测试用例。
(4) 测试实施和执行
建立或设置相关的测试环境，准备测试数据，执行测试用例，对发现的软件缺陷进行报告、分析、跟踪等。测试执行没有很高的技术性，但是测试的基础，直接关系到测试的可靠性、客观性和准确性。
(5) 测试结果的审查和分析
当测试执行结束后，对测试结果要进行整体或综合分析，以确定软件产品质量的当前状态，为产品的改进或发布提供数据和依据。从管理来讲，要做好测试结果的审查和分析会议，以及做好测试报告或质量报告写作、审查。
什么是CC攻击？CC攻击就是利用大量代理服务器对目标计算机发起大量连接，导致目标服务器资源枯竭造成拒绝服务。那么如何判断查询CC攻击呢？本文主要介绍了一些Linux下判断CC攻击的命令。
查看所有80端口的连接数
netstat -nat|grep -i "80"|wc -l
对连接的IP按连接数量进行排序
netstat -anp | grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
netstat -ntu | awk '{print $5}' | egrep -o "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" | sort | uniq -c | sort -nr
查看TCP连接状态
netstat -nat |awk '{print $6}'|sort|uniq -c|sort -rn
netstat -n | awk '/^tcp/ {print $NF}'|sort|uniq -c|sort -rn
netstat -n | awk '/^tcp/ {++S[$NF]};END {for(a in S) print a, S[a]}'
netstat -n | awk '/^tcp/ {++state[$NF]}; END {for(key in state) print key,"\t",state[key]}'
netstat -n | awk '/^tcp/ {++arr[$NF]};END {for(k in arr) print k,"\t",arr[k]}'
netstat -ant | awk '{print $NF}' | grep -v '[a-z]' | sort | uniq -c
查看80端口连接数最多的20个IP
cat /www/web_logs/waitalone.cn_access.log|awk '{print $1}'|sort|uniq -c|sort -nr|head -100
tail -n 10000 /www/web_logs/waitalone.cn_access.log|awk '{print $1}'|sort|uniq -c|sort -nr|head -100
cat /www/web_logs/waitalone.cn_access.log|awk '{print $1}'|sort|uniq -c|sort -nr|head -100
netstat -anlp|grep 80|grep tcp|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -nr|head -n20
netstat -ant |awk '/:80/{split($5,ip,":");++A[ip[1]]}END{for(i in A) print A,i}' |sort -rn|head -n20
用tcpdump嗅探80端口的访问看看谁最高
tcpdump -i eth0 -tnn dst port 80 -c 1000 | awk -F"." '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -nr |head -20
查找较多time_wait连接
netstat -n|grep TIME_WAIT|awk '{print $5}'|sort|uniq -c|sort -rn|head -n20
查找较多的SYN连接
netstat -an | grep SYN | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -nr | more
linux下实用iptables封ip段的一些常见命令：
封单个IP的命令是：
iptables -I INPUT -s 211.1.0.0 -j DROP
封IP段的命令是：
iptables -I INPUT -s 211.1.0.0/16 -j DROP
iptables -I INPUT -s 211.2.0.0/16 -j DROP
iptables -I INPUT -s 211.3.0.0/16 -j DROP
封整个段的命令是：
iptables -I INPUT -s 211.0.0.0/8 -j DROP
封几个段的命令是：
iptables -I INPUT -s 61.37.80.0/24 -j DROP
iptables -I INPUT -s 61.37.81.0/24 -j DROP
想在服务器启动自运行的话有三个方法：
1、把它加到/etc/rc.local中
2、iptables-save >/etc/sysconfig/iptables可以把你当前的iptables规则放到/etc/sysconfig/iptables中，系统启动iptables时自动执行。
3、service iptables save 也可以把你当前的iptables规则放/etc/sysconfig/iptables中，系统启动iptables时自动执行。
后两种更好此，一般iptables服务会在network服务之前启来，更安全。
解封的话：
iptables -D INPUT -s IP地址 -j REJECT
iptables -F 全清掉了
一、确认好团队的目标（即该团队未来2-3年或者更长时间内期望发展成什么样）
测试团队的核心任务应该就是保证自己负责项目的质量，并且通过不断的改进来缩短项目的周期吧！
我们可以先想象下2-3年后，期望整个团队的测试模式是怎样的？
比如：一个新的版本开始后（这里指增量版本），我们确认该版本的测试模式是
1、新增模块在版本前期就开始研究测试方法（比如：单元测试、接口测试、自动化测试等），并且能够让开发配合提供一些支持。通过这种方式能够覆盖到70%以上的测试点。然后再通过对该模块以及对整个系统的把握，准确的分析出那些可能还是有风险的，并且进行探索性测试和整体场景的测试
2、关联模块的测试点分析出来后能够很快的实现自动化
3、老模块已经全部实现自动化了
4、测试人员发现的问题基本上都能够自己定位，甚至能够指导研发进行修改。研发修改后能够准确的分析出可能有影响的地方，并补充测试
达到这样的程度（或者达到这样程度的80%以上），相信对于版本的快速迭代以及质量都是很有帮助的，而且对于测试团队以及测试人员的成长来说，也是比较好的。
那么，怎样才能够达到这样的程度呢？
1、整个团队自动化的程度非常高，只要是老模块全部实现自动化了
2、整个团队对于产品内部业务逻辑非常清楚，甚至达到研发的程度（不用到代码的每行），能够对研发的设计提出有效的意见，并能够指导研发进行设计
3、整个团队成员的质量意识非常高，会有应该是自己发现的bug结果没有发现感到羞愧的思想
4、整个团队具备前期测试和缺陷预防的能力，能够更开发一起配合在前期就做好相关工作，比如：前期的缺陷预防，测试方法研究等等！
达到这样的程度后，整个团队至少有部分人应该具备如下技术能力：
1、自动化开发能力：这样的人员越多越好（至少要有1/3以上），这样能够让自动化成为一种常用的改进技术，让自动化成为一种习惯
2、业务能力：对于产品的内部实现和整个业务逻辑都非常熟悉，能够有效的指导该模块的设计，并且发现该模块的问题能够自己定位。至少每个模块都找得到这样的人
3、单元测试和接口测试能力：能够在前期通过对代码或者借口进行测试，尽量在前期就能够保证质量（需要学习相关的开发语言）
4、对于产品的理解比较深，能够有效的指导产品后面的改进方向
5、项目管理能力，对于一个不大的团队来说有2-3个差不多了
二、挑选合适的人员
理想的测试人员应该具备如下几个特点：
1、有激情：这是杰克韦尔奇最认可的一点，笔者深有同感，相信对生活有激情的人，对工作也同样有激情
2、喜欢测试：有探索未知世界的好奇心，能够在测试中找到成就感。
3、热爱技术并且有一定的技术能力：老实说，测试入门是技术门槛相对比较浅的，但是真的要做到很好程度确实需要比较好的技术，比如：上面的几点，都是有一定的技术门槛的，只有热爱技术的人才会愿意去主动去深入学习技术
三、如何实现目标
1、团队的文化和制度：所谓无规矩不成方圆，如果一个团队要健康的发展，团队的文化和制度是非常重要的。当然，我们团队的文化和制度也是为了更好的实现我们的目标而服务的，比如：我们期望大家主动去学习模块的原理知识，那么我们就可以形成这样的文化和制度。并且有了制度后一定要坚决的去执行（但是可以更加的人性化），然后根据大家的意见去不断的完善制度和管理。没有制度的话很难保证团队的执行力，那样目标也很难实现，所以，这个非常重要，也是一个初入管理者很容易出现的问题
2、业务熟悉：对于早期来说，我们的直接学习对象肯定是开发，学习的资料大概就是需求文档和设计文档，这个时候可以让测试人员每个人负责一个模块，先去学习设计文档，并且要求测试人员自己能够画出该模块的整个业务逻辑图，并且跟研发确认是ok的（要求内部培训和讲解，并请研发过来旁听）。然后根据业务逻辑图分析可能存在问题的地方，并结合代码进行详细分析（这个时候可不要求测试人员具备单元测试或接口测试能力），后面测试的过程中发现问题后，自己能够尝试的定位问题，并且完成一份模块的定位问题经验文档（后面随着自己的深入学习来不断的完善）
3、自动化：自动化的起步确实是很难的，刚开始的成本很高，再加上项目的工作本身也比较紧，这样很容易让团队对自动化望而止步。但是，经验证明自动化的工作确实是越早开始研究越好。一个比较好的方法是团队负责人自己先花时间去分析下，目前哪个功能模块的测试是重复率最高的，并且实现难度稍微比较小的（模块的选择很重要），然后思考如何去实现自动化（多关注同类产品，看下别人是怎么做的）。确定好怎么做后，如果自己技术比较好的话就自己尝试去实现（推荐方式，当然也会花费自己的一些额外时间，但是肯定是值得的），如果团队里面有更适合的人的话，则可以自己去承担对方的工作（比如：测试任务），然后让对方投入时间去做这件事情（当然，这个人一定要选好）。等到有效果后（这部分的工作能够节省下来），这个时候就可以利用节省的这部分时间继续做这个工作了（相信上面看到效果后也会提供更多的支持），通过这种方式持续改进应该会比较好
4、接口和单元测试：对于整个模块的业务逻辑比较熟悉后，这里需要的另外一个能力就是我们对于开发使用的语言本身也比较熟悉，至少静态走读开发的代码没有太大问题（当然，可能一个团队这样的人不会很多，我们可以先培养这样的人）。并且随着我们的自动化工作已经有了很大效果后（这个时候大家的代码开发能力实际上也比较好了），就可以专门投入人员做这些事情了。当然，这个需要跟开发的配合，但是前面2者做好后，后面的改进其实就是水到渠成的事情了。而且也最好是先完成前面的2点，再开始第3点，毕竟步子迈大了容易扯着蛋
将以上几点的目标进行细化，具体要做到什么程度？怎么去一步一步去做？每一步的完成时间点是怎样的？如何评估是否达成该目标呢？将这些问题搞清楚后就可以开始做了，定期分析和总结，相信应该是能够达成上面的目标的
PS：一家之言，不一定完全正确，但是目前正在朝这个方向努力。
版权声明：本文出自 pengyongbo 的51Testing软件测试博客：http://www.51testing.com/?181625
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
测试设计重要性
设计是测试的灵魂，质量的龙头。
测试设计面临问题
1、测试对象的逻辑路径和测试输入数据的组合几乎是无穷的，而穷尽的测试是不可能的
2、不同利益相关者对软件或者软件产品的质量要求是不同的
3、测试时间和资源有限
4、测试得到的需求和资源不完整
5、测试设计语言规范
穷尽的测试是不可能的
1、如何有效减少测试用例的数目？
2、如何避免测试用例之间的冗余？
3、如何满足测试覆盖率的要求？
如何有效减少测试用例的数目？
1、等价类
（1）有效等价类
（2）无效等价类
2、边界值
如何避免测试用例之间的冗余？
1、规范测试设计
（1）按照一定的设计思路进行测试用例设计
（2）减少热带风暴
2、可复用的测试用例
特性：通用性、有效性、独立性
如何满足测试覆盖率的要求？
测试覆盖率常用的计算公式：
1、 功能覆盖率
至少被执行一次的测试功能点数/ 测试功能点总数（功能点）
2、 需求覆盖率
被验证到的需求数量 /总的需求数量（需求）
3、覆盖率
至少被执行一次的测试用例数/ 应执行的测试用例总数
4、语句覆盖率
至少被执行一次的语句数量/ 有效的程序代码行数
5、判定覆盖率
判定结果被评价的次数 / 判定结果总数
6、条件覆盖率
条件操作数值至少被评价一次的数量 / 条件操作数值的总数
7、判定条件覆盖率
条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
8、上下文判定覆盖率
上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
9、基于状态的上下文入口覆盖率
累加每个状态内执行到的方法数/(状态数*类内方法总数)
10、分支条件组合覆盖率
被评测到的分支条件组合数/分支条件组合数
11、路径覆盖率
至少被执行一次的路径数/程序总路径数
目前采用覆盖策略
1、基于需求的测试覆盖评估
依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。
2、基于代码的测试覆盖评估
是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
基于代码的测试覆盖评估
1、针对于java的项目采用EMMA工具进行分析
2、针对于delphi项目采用工具还没有定
不同利益相关者对软件质量要求是不同的
1、如何获取利益相关者的不同质量要求？
2、如何设计测试用例以满足不同的质量要求？
3、如何分析和评估最终软件产品的质量？
4、如何提高客户对软件产品的满意度？
测试时间和资源有限
1、如何有效的选择测试重点？
2、如何确定测试优先级？
3、如何有效的配置测试资源？
4、如何分析和评估测试的有效性？
如何有效的选择测试重点
1、软件产品的每个功能模块，对于客户而言并不是是同等重要的；
2、用户实际使用过程中的使用频率的分布
基于风险的测试策略
1、选择测试重点：对测试范围进行优先级的划分，将测试设计和执行放在优先级高的区域。
2、将测试资源分配到高风险的地方，从而更加有效的利用测试资源；
3、确定测试对象在哪些地方容易出现错误，并设计相应的测试用例来发现这些错误；
4、基于风险可以更好的对测试状态和测试结果进行报告，从而更好的对测试过程和测试质量进行监控，并根据实际的测试状态对后续测试进行及时调整。
测试得到的需求和资源不完整
1、如何获取尽量多的显现需求和隐现需求？
2、如何利用已有的经验有效设计测试用例？
3、如何应对需求的不断变更？
如何获取尽量多的需求？
1、 站在用户角度出发
（1）了解用户原始需求
目前公司需求来源于需求人员和项目经理的理解，我们如何得到用户的需要和期望
（2）了解行业隐含需求
（3）需求复用
2、 利用逆向思维方式推测问题
用户当前遇到的问题，是否可以在系统中找到解决方案
如何利用已有的经验有效设计测试用例？
错误推测法
（1）基于代码
（2）基于业务
（3）基于代码的编写者
（4）基于系统框架
如何应对需求的不断变更？
1、变更流程的规范
2、测试流程规范
测试设计语言不清晰导致问题
1、执行者的痛苦
2、测试覆盖率下降
3、测试执行效率下降
4、测试设计的工作成果不被认同
测试用例设计语言规范
1、不要采用一些个性化语言或简称来描述用例
2、用例描述必须含有主谓宾
3、预期结果采用smart原则，必须量化、具体
例如：验证数据正确性
4、涉及类似产品，在产品间描述保持一致
5、同一界面的相同实体描述名称必须一致
6、专业术语必须准确一致
1、准备文件
a）QTP 9.2的注册机，熟悉QTP的朋友应该都知道11之前的都可以一直沿用9.2注册机生成的
lservrc文件。
b)HP官方站上下载QTP11的安装文件
http://www.genilogix.com/downloads/unified-functional-testing/quicktest-professional-11.iso
2、安装QTP11
3、运行注册机mgn-mqt82.exe
如果运行mgn-mqt82.exe 没有反应-,请注意关掉暂时关掉杀毒软件
根据路径"C:\Program Files\Common Files\Mercury Interactive\License Manager\lservrc"
以上方法是网上9.2 的破解方法， 以下是11的破解方法，同时适用QTP10.0，只不过以下方法破解10.0可以无时间限制，而11只能适用15天或者30天 。如果11的License到期了，可以使用此方法再次重新破解，不需要重装，即可再次使用15-30天。
1）找到lservrc文件，将它剪切至桌面，或者是别的文件夹，注意一定是剪切。
2）运行QTP 11
或者
4、点击Install License，选择Seat license，因为QTP10和QTP11都采用了两种license，单机版的和服务器并发的，我们破解的是单机许可。
5、点击下一步
用记事本打开前面注册机生产的lservrc文件，会看到有4个许可密钥，复制任意一条密钥，从开头至#号结束，粘贴至窗口的文本框中，点击下一步，如果提示该密钥已经安装，何以选择另外一条安装，如果仍然提示，请注意检查第三步lservrc文件是否移走了，
点击下一步
6、安装完成，启动QTP
摘要: 华为的面试题 Q1：请你分别划划OSI的七层网络结构图，和TCP/IP的五层结构图？ 答：七层结构从上到下依次是： 7 应用层 ；6 表示层 ；5 会话层 ；4 传输层 ；3 网络层 ；2 数据链路层 ；1 物理层 五层结构是 5 应用层；4 运输层；3 网络层； 2 链路层；1 物理层。 Q2：请你详细的解释一下IP协议的定义，在哪个层上面，主要有什么作用？ TCP与UDP呢？ 答...
阅读全文
软件需求的概念
（1）宽泛地讲，需求来源于用户的一些"需要"，这些"需要"被分析、确认后形成完整的文档，该文档详细地说明了产品"必须或应当"做什么。
（2）是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
（3）期望？！ 一种心理活动、笼统、不细致、不懂过程
需求的重要性
（1）Frederick Brooks在他1987年经典文章"No Silver Bullet"中阐述了需求的重要性：
开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
（2）需求是产品的根源，需求工作的优劣对产品影响最大。
（3）国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。
了解客户、最终用户、间接用户的概念
（1）基本概念
"用户"（user）是一种泛称，它可细分为"客户"（customer）、"最终用户"（the end user）和"间接用户"（或称为关系人）。
掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。
（2）客户是掏钱买软件的人，所以他是"上帝"
（a）某饭店经理在解释"先有鸡还是先有蛋"这个哲学问题时，精辟地阐述了客户的地位：
如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。
（b）"现代营销学之父"菲利普o科特勒所著的《市场营销导论》是这样描述客户的：
客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。
（c）与客户打交道的主要目的是：一是获取需求，二是签合同。
软件需求的层次
（1）原始问题描述：对要解决问题的叙述，它是软件需求的基础
（2）用户需求：用自然语言和图表给出的关于系统需要提供的服务及操作的约束
（3）系统需求：是用户需求的映射。此时可开发一个简单原型以便给用户一个直观印象。
（4）软件设计描述：在系统需求的基础上加入更详细的内容，它是软件详细设计和实现的基础
需求工程的组成
把所有与需求直接相关的活动通称为需求工程。
需求工程的一些感悟
（1）不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。
（2）开发者对待需求工程的态度可分"被动型"、"主动型"和"领先型"三种，只有后两种才有可能开发出成功的产品。
"被动型"是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。
"主动型"是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说"良好的开端是成功的一半"，"主动型"需求工程是开发成功产品的必备条件。
"领先型"是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。
需求开发的主要困难与对策
···知识技能问题
（1）应用域的知识是无边无际的，任何人都不可能是"万事通"。
（2）当需求分析员缺乏应用域知识时，他该怎么办？
（a）首先他要有勇气做事，否则连实践的机会都没有。
（b）其次他应当赶紧补习应用域知识。
···态度问题
（1）相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：
需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。
（2）用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。
（3）软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。
需求获取
需求获取时期的主要工作：
（1）归纳和整理用户提出的各种问题和要求；
（2）弄清用户企图通过软件达到的目的；
（3） 借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。
最终目的弄明白要"做什么"。
获取需求应采用的步骤
（1）确定产品的不同用户类型
（2）确定用户需求的来源
（3）挑选出每一类用户和其他涉众的代表并与他们一起工作
（4）商定谁是项目需求的决策者
获取需求的方法
（1）明确最终用户，与用户交谈，向用户提问题。向用户群体发调查问卷。透过客户所提出的表面需求理解他们的真正需求。
（2）参观用户的工作流程，观察用户的操作。
（3）与同行、专家交谈，听取他们的意见。
（4）界面原型法，是指开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通。
（5）可运行的原型系统法
（6）分析已经存在的同类软件产品，提取需求。
（7）从行业标准、规则中提取需求。
（8）从Internet上搜查相关资料。
切记：
设定用户代言人
如果个别客户不能在需求方面达成一致意见，那么必须由用户代言人作出决策。
需求分析
（1）需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。
（2）分析方法大体有两类："问答分析法"和"建模分析法"。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。
（3）采用方法：绘制关联图、创建用户接口原型、分析可行性、确定需求优先级、编写数据字典等。
编写需求文档
（1）需求文档包括用户需求和详细的系统需求描述。
（2）要求
正确：正确地反映用户的真实意图；
清楚：易读易懂；
无二义性
一致
完备：没有遗漏一些必要的需求；
可实现： "可实现"意味着在技术上是可行的，并且满足时间、费用、质量等约束；
可验证
确定优先级：确定高中低三个级别，将风险降到最低。
阐述"做什么"而不是"怎么做"
需求验证
（1）需求验证是为了确保需求规格说明准确、完整地表达了必要的质量特点。
（2）审查需求文档、依据需求文档编写测试用例、确定产品验收合格的标准。
（3）验证内容：有效性、一致性、完备性、现实性等。
需求管理的重要性
如果对已经建成的大楼不满意，要求设计师把大楼的结构调整一下，别人一定会认为这很荒唐。但在软件项目中，这样的事情很常见。
软件缺陷，发现和修复的越早则成本越低。不幸的是，需求阶段出现的错误往往很难发现，所以需求管理也需要讲究科学。
原则：需求必须分优先级、必须文档化、需求一旦变化就必须对需求变更的影响进行评估。
需求变更存在的必然
大师说："没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。"
变更管理
进行变更管理，首先要建立变更控制委员会，变更管理过程包括变更描述、变更分析和变更实现三个阶段：
变更描述：始于一个被识别的需求问题或一份明确的变更提议
变更分析：评估被提议的变更产生的影响
变更实现：执行变更，需求文档、系统设计和实现都要修改
变更描述阶段，产生需求变更请求表
变更影响分析
需求变更影响分析模板中包括的内容：
变更请求号
标题
描述
分析者
分析日期
优先级评定
相关代价、收益与风险
预计对进度、成本、质量的影响
被影响的其他需求及任务
要更新的计划及文档
变更控制流程
需求状态
定义：某时间点需求的情况反映。
客户需求的四种情况：
客户可以明确且清楚地提出的需求
客户知道需要做什么，但却不能确定的需求
客户提出需求，但需求的业务不明确
客户自己也说不清楚的需求
需求状态：
已建议 已批准 已拒绝
已设计 已实现 已验证
已交付 已删除
需求文档版本控制
对于开发人员来说，最为沮丧的事情莫过于当软件功能实现后，却发现该项功能已被项目经理取消了。原因在于需求文档版本混乱，开发人员没有得到最新的软件需求。
需求跟踪
目的：建立和维护从用户需求到测试的一致性与完整性，确保实现都以客户需求为基础，实现的需求覆盖了预期的需求，并确保输出与用户需求的符合性。
需求跟踪的作用
（1）在需求验证中，便于确保所有需求被应用
（2）有助于变更影响分析
（3）便于需求的维护
（4）便于测试时找出问题所在
（5）便于项目跟踪和减少项目风险
（6）简化了系统再设计，易于软件重用
案例分析：一个项目需求分析和处理的案例
1、 案例背景
当地一家销售电动工具公司的董事会成员正在举行二月份的董事会会议，这家公司是一家专门制造和销售用于木工用的"黑客"牌电动工具的一家小型公司。会议室里在座的，有董事会主席贝斯·史密斯（Beth Smith）和两个董事会成员罗斯玛丽·奥尔森（Rosemary Olsen）和史蒂夫·安德鲁（Steve Andrews）。贝斯首先发言："我们今年以来的销售非常好，打来的订货电话，已经要把我们的电话都要打爆了，但是，我们没有办法能继续招募到熟悉我们的电动工具、同时还了解我们销售过程的小姐。而与我们竞争的其他公司，都已经上了自动客户服务系统（Call Center）。所以，我们也要上这个系统，才能保住我们的市场。"
"我们必须建立一个计算机自动客户服务系统。"罗斯玛丽响应道。
史蒂夫建议："难道我们不能把售后服务转给麦肯罗公司（公司下属的一家子公司，以服务为主）做吗？向他们要求一下，看他们是否能把电动工具的服务也接过去？"
"他们也紧张，听说明年他们甚至可能会削减一些服务项目。"贝斯回答。
"我们需要多少钱才能搞这么一个系统？"罗斯玛丽问道。
"大约10万美元，"贝斯回答，"如果我们不能在两个月后就开始启用这个系统，估计我们的定单可能会减少20%。"
"我们除了钱还需要很多东西。我们需要了解是否有更好的方案、开发这个系统需要多少时间，以及，这个系统是不是真的适合我们！"史蒂夫说。
"哦，我想我们完全可以自己来做这个项目，这将是很有趣的！"罗斯玛丽兴奋地说。
"这个项目不是我们的专长，我们不可能及时完成。"贝斯说道。
罗斯玛丽回答说："我们有几个技术人员，虽然不够，但只要再招聘一二个高手，就可以解决它，并且做好。"
"项目是我们真正需要的吗？我们上了这个项目以后，公司的销售任务就能完成了吗？"史蒂夫问道，"此外，我们正在经历一个困难时期，我们的资金并不宽余。或许我们应当考虑一下，我们怎样能用较少的资金来运作一切。例如，我们用这个系统只处理定单，而并不包括服务，。这样系统是不是就会小一点，也省一点、快一点？"
罗斯玛丽插话说："多妙的主意，我们可以先完成销售定单的处理，等这部分完成投入使用后，再开发服务部分。公司可以在改进销售功能的同时，继续开发服务功能。这样，我们就可以做得更好。"
"好了，"贝斯说，"这些都是好主意，但是我们只有有限的资金和技术人员，并且有一个增长的需求。我们现在需要做的是，确保我们在两个月后不必担心丢失定单。我想，我们都同意必须采取行动，但是不能确定我们的目标是否一致。"
2、案例习题
（1） 项目目标是什么？
（2）已识别的需求是什么？
（3）如果有的话，准备开发的项目应具备什么样的假定条件？
（4）项目牵涉到的风险是什么？
3、案例分析
根据本案例的背景，我们的分析简单描述如下。由于本案例比较简单，而且是自主开发，因此，有些内容可以简略。至少必须描述的内容，用下划线表示：
（1）业务需求
1、背景：一家小型的木工电动工具公司，今年以来的销售形势很好，接受定单的电话很多，已经忙不过来了。因此，需要开发自动客户服务系统。
2、项目机遇：通过自动客户服务系统的开发和投入使用，使公司的销售获得增长。
3、项目目标：开发一套为本公司销售和售后服务使用的计算机自动客户服务系统（Call Center）。
4、市场需求：
5、客户价值：满足公司自身发展的需要。
6、项目风险：项目目标、方案、时间、资金、开发人员等。
（2）方案描述：
1、功能视图：自动接听电话，对客户的定单和售后服务要求做出响应。
2、主要特征：自动处理一些原来由人工完成的工作，有可能增加新的服务功能。
3、假设和依赖：二个月时间内完成，总投资为10万美元，自主开发，自己使用。
（3）范围局限
1、首次发行范围：
2、随后发行范围：
3、局限和专用性：只为自己公司使用。
（4）系统环境：
1、用户概貌：
2、项目优先级：可以先完成定单响应，再完成售后服务功能。
（5）成功因素：
我们现在完成的，实在需求获取阶段中介绍的"项目视图"中的内容。在项目视图中，我们对项目做了初步的描述。在背景和目标分析阶段，我们回答本案例问题的答案是：
1、项目目标是什么？
答：开发一套为本公司销售和售后服务使用的计算机自动客户服务系统（Call Center）。
2、已识别的需求是什么？
答：自动接听电话，对客户的定单和售后服务要求做出响应。
3、如果有的话，准备开发的项目应具备什么样的假定条件？
答：二个月时间内完成，总投资为10万美元，自主开发，自己使用。
4、项目牵涉到的风险是什么？
答：项目目标、方案、时间、资金、开发人员等。
系统的功能包括：
1、从公司的客户方面看，新系统可以自动支持电话、FAX，E_mail、Web等多重通信方式所提供的服务，最大限度的满足客户的需要，最有效地为客户提供快捷方便的服务。
2、从公司方面看，新系统要可以支持接入公司的交换机中继线路（24条中继），自动或智能话务分配、坐席画面与电话同步、自动录音等功能。
3、从提供服务的内容看，可以有：公司产品查询、合同和定单查询、自动处理定单、产品售后服务信息查询、供货信息查询、方案介绍、产品推介、产品报修、故障咨询、投诉等。进一步的购买洽谈，可以转人工处理。
4、整个系统可以与目前公司已经有的客户信息系统、产品信息系统等建立联系，形成综合的服务系统。
Rational Clear Quest:
国外收费软件，价格昂贵（几十万）
难于找到破解版和序列号。
功能强大，主要用于管理变更（需求、缺陷等）与其他Rational 产品集成,特别是ClearCase.
支持的数据库:SQLserver ,Oracle,Access.
产品模式:C/S,B/S结构,web服务器需要另外安装.配置较为复杂.
其他功能强大．
URTracker:
国产软件，价格低/每用户￥50．（试用版１个月，试用版后免费５用户）
容易下载．
系统需求：
Windows2000/xp/2003
IIS5/6
.Net Framework1.1
SQL Server2000 / MSDE 2000
优点：操作简单，界面友好，容易上手．满足缺陷追踪的功能．
缺点：查询功能相对较弱，不能自己订制，报表功能也较弱．
产品模式：B/S 结构
Bugfree:
国产开源软件，免费．
容易下载．
系统需求：MySql+PHP+Apache
优点：流程清晰，能完整的记录Bug解决的流程，可自定义配置。
缺点：熟悉PHP。
产品模式：B/S结构
Bugzilla:
国外开源软件，免费
容易下载
优点：满足缺陷管理功能．比较出名的开源软件。
缺点：Windows平台配置较为复杂，用户界面差．
产品模式：B/S结构．
支持数据库：Mysql
Mantis:
国外开源软件。
轻量级的缺陷跟踪系统
优点：Mantis相对Bugzilla有更好的操作界面。
第二、安装和使用都相对简单一点。但比其他软件稍复杂。
而对于一般的项目，Mantis作缺陷跟踪，已经绰绰有余。
缺点：界面梢差，目前的版本还存在一些问题。
产品模式：B/S
系统需求：PHP+MySql
TestDirector:
国外收费软件，价格昂贵（几十万）
优点：用户界面友好，功能强大,安装简单，与LR,WR集成，有多种主流case工具接口AddIn.
集成了测试需求管理、测试计划和用例管理、测试日程控制、测试执行和缺陷跟踪等功能
强大的统计分析功能
缺点：由于其早期版本不能灵活的对项目管理流程进行配置，又由于其昂贵的价格，因此目前
应用的企业也不是很多。
TD更侧重于测试过程管理
支持数据库：Oracle,SQLserver,Access
产品模式：B/S结构
JIRA
国外收费软件
采用J2EE技术，JIRA 是目前比较流行的基于Java架构的缺陷跟踪系统。
优点：界面友好，JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。
安全性、可扩展性方面发挥到了极致
系统需求：运行于所有的安装了JDK的操作系统上，并能够跟几乎所有的兼容JDBC的数据库一起使用
JIRA更加侧重于缺陷追踪和项目管理
BugZero
5用户版，100条记录免费。
TestTrack Pro:
Seapine公司的
我在百度做软件测试工作的趣味性在于可以接触到很多新IT技术的产品和把新IT技术知识应用到测试中，这些是我在百度最有趣的事。典型的代表就是如何尽可能找出不是bug但影响用户体验的设计问题，在百度被称为效果测试或产品评测。从测试目的而言这类测试不是发现软件编码的错误，而是发现产品设计的不足。应用的技术和方法有：基于大数据思想进行相关性分析自动挖掘数据badcase、众测、百度TIP中的AB testing、产品评测体系。以我所了解的信息来看目前百度很多产品已开展了产品效果评测，如网页搜索、图片搜索、地图搜索、视频搜索、商业搜索、众多的移动APP产品等。QA们在完成产品bug的挖掘后，会继续进行产品validation的工作为提升产品设计的用户体验继续贡献测试人员的价值。
今天我先分享下在百度学到的如何自动进行badcase挖掘的评测方法，因为我觉得这是我在百度遇到的最有趣的一种新测试类型，很好地解答了我内心关于算法效果测试方法的疑惑。先介绍下什么是badcase——“badcase是一个不符合用户心理预期的产品输出结果集”，例如：搜索结果中出现的“文不对图”现象，以及低质量的输出结果排在前面等现象。传统测试方法中并没有对此类问题现成的技术或方法，因此为了从数千万的输入数据中找出那些输出结果集质量不满足用户体验的问题，靠人工的方式对每个输出结果进行人眼判断显然是不行的。因此，百度的QA应用了大数据思想从数据的相关性入手，从大量的badcase中找到A现象与B结果的相关性，当我们得到一个可以达到80%以上相关性的准确率时就可得到一个靠谱的测试模型，当然这个测试模型天生就是自动化的，从而支持我们从海量的数据中自动地挖出海量badcase，而测试人员要做得就是设计这个自动挖掘badcase的测试模型。以前我们应用人工的方式进行相关性测试模型的规则抽取与验证，后来开始应用机器学习的思想和方法，实现先自动训练相关性测试模型达到一定准确性后，再应用这个测试模型自动的进行badcase挖掘。以前此类产品评测的最大困难是靠人工方式进行产品效果评估，一个PM一天能评估的输入数据也就最多几百个，而现在我们可以实现一天评估数十万的输入数据，工作效率提升上千倍。而这一切就是大数据思想和机器学习新技术应用到测试设计中的效果，自动化测试的概念又提高了一个新的层次。也许未来测试人员的工作方式会像我们的工作方式一样：先基于业务专家经验设计一个测试模型的架构和主要因子，然后通过真实数据集自动训练测试模型得到测试模型中每个变量因子合适的取值范围，最终自动得到一个测试结果高准确率的测试模型。未来是大数据时代，我认为利用大数据思想不去追求精准的因果关系，而是追求相关性的准确性，将是未来测试设计师们必须要掌握的一种IT技能。
在过去挖出足够数量的badcase是QA最大的挑战，现在的新挑战则变成了我们如何用最快的速度和最低的成本完成这些大量badcase的分析定位工作。通常第一步会自动地针对挖掘出来的badcase进行影响严重度的评级（依然是使用大数据思想和机器学习的方法），这样可自动选出影响较严重的badcase集。第二步：如果产品形态支持通过构建决策树模型自动地定位分析问题根因，那么将通过设计自动分析定位系统对badcase集进行处理。如果某些产品形态不支持通过构建决策树实现自动分析定位，则会通过百度的众测平台，引入用户资源通过一些众测活动来对badcase再次进行标注，这样也能大大降低工程师分析定位的成本与时间。对百度众测感兴趣的同行可以到平台test.baidu.com上去了解更多相关信息。在此我先简单介绍下：百度众测是国内第一个基于众包思想实现的一种“人工测试云”，它充分发挥公司产品爱好者的资源价值，不仅帮助发现产品bug还可以为产品优化设计体验提供用户数据，例如：通过百度众测用户对badcase的标注可帮助QA收集大量标注数据为改善产品效果贡献价值。目前网页搜索、地图搜索、图片搜索等产品都已通过众测的用户标注活动优化产品的效果设计质量和降低badcase的分析定位成本。
Badcase的自动挖掘和分析工作对于强算法类产品的用户体验改进帮助很大，而对于弱算法类产品如一些应用APP产品而言，百度QA则通过建立各自产品的评测体系的技术活动以量化方式对产品进行用户体验评测，产品经理和开发人员将根据评测结果输出产品改进的story和非功能质量属性的优化方向。
产品评测报告与传统测试报告的区别在于：传统测试报告是测试用例执行结果和bug数据的分析材料是用于分析软件存在的实现错误。而产品评测报告更多是产品在不同用户功能应用场景和非功能属性应用场景的评价数据（例如不同用户场景下的性能响应值和不同用户环境场景下的兼容性表现），以及与同类产品的对比数据，因此对产品设计者（PM）会更有用户体验提升的指导价值，通过更直观的产品用户体验数据支撑产品设计决策。QA则通过设计产品的评测体系对产品价值的贡献不仅在于发现bug，还扩展延伸到直接为产品设计和产品用户体验提升提供有量化数据支撑的改进方向。在百度内部移动APP的评测工作中会对APP在不同网络质量、不同机型、不同软件平台版本下进行产品基础功能、APP响应性能（业务级和系统级）、APP资源消耗性能（耗电量/流量/OS资源等）、UI流畅度等领域进行评测数据收集，QA会在评测数据基础上先进行第一轮的数据分析给出定性的结论，给出改进的建议和技术方案提供给PM或RD参考。为了最大化的提升移动APP的评测效率在内部除了各产品组独立开展的评测活动外、还有支持一键评测的百度评测平台对内部评测技术进行技术共享与重用帮助各产品QA提升评测工作效率。
测试人员要设计出一个靠谱的产品用户体验评测体系，必须先要对所负责产品的主要用户场景（功能和非功能）有充分的了解和理解，以及用户对产品体验的需求有足够完善的整理，才能对产品整体的用户体验进行科学客观地评价。然后评测体系还需要做“横向”同类产品、“纵向”历史版本的对比测试，并根据产品的“设计思想”进行评测验证是否达到预期的设计定位。最后通常一个好的评测体系一定是一个松耦合的产品测试平台，在这个测试平台上无论是自有产品还是其他公司的相似产品都能得到统一标准的测试数据评估，这样能帮助QA/PM/RD对产品用户体验数据的价值进行更好的分析，从而提升产品竞争力。从某种角度看QA要做好产品评测体系就必须拥有至少“半个产品经理”的用户需求场景知识，从这方面来看对QA的要求又提高了，不仅要懂软件技术会挖掘程序错误，还要有丰富的产品领域用户场景的知识（功能的/性能的/兼容性/稳定性等）。虽然对QA的技能要求提高了，但是无论对产品竞争力的提升还是对QA自身价值的提升都是有着很积极地作用。
另外我认为在公司内只有QA最适合做产品评测体系设计这件事，产品经理PM更擅长功能性需求的设计和创新，对如何设计严谨和完善的测试系统并不是很专业（QA出身的PM除外）。RD则更擅长产品架构的设计和实现，擅长从白盒层面来理解产品，对于用户应用行为黑盒层面的理解则相比QA有限。而QA却因为长期从事功能和非功能的黑盒测试活动的经验积累了很多产品在用户体验方面的知识，因此QA相比PM和RD更适合设计一个用户体验层面严谨的产品评测体系，而这也是QA在公司中独特价值之一的体现。
最后我的感慨是大数据思想、机器学习、众包、基于用户体验量化的产品评测这些所谓时髦的名词已不只是虚幻的理论或概念，把这些新的IT技术和理念应用到质量保障工作中为产品用户体验提升提供测试方法论，改变旧有的测试模式是已被实践证明可行的、是有价值的。希望我此次分享的百度QA在用户体验提升领域的实践经验能帮大家更好地提升产品用户体验和测试人员在公司中的产品价值。
版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《我眼中的百度QA》第一篇：百度QA的特点与核心价值
《我眼中的百度QA》第一篇：百度QA的特点与核心价值（下半部分）
第9章 黎明之前最后的冲刺：成品测试
项目结尾时是小艾最能感受到成就感时，总结一段时间以来的项目经验，总会有很多收获。小艾非常享受这种学习与收获的过程。但是，明明测试和开发已经完成了，距离计划发布日还有一段时间，这段时间要做什么呢？
9.1 产品包装成金蛋，手握光碟抓虫子
这两天小艾明显感觉到项目团队的气氛紧张。项目经理凯文和各团队主要负责人每天都神色凝重地在会议室激烈地讨论着什么。这又勾起了小艾的好奇心。
9.1.1 成品测试全体总动员
他问身旁的凯文：“现在我们的各方面测试都基本完成了，不是应该松口气庆祝了吗？怎么领导们看着比以前还紧张，是出什么问题了吗？”
凯文拍了一下小艾的肩膀答道：“知道什么是黎明前的黑暗吗？这就马上到最后的冲刺--GMV测试阶段啦。”
小艾一头雾水地问：“什么是GMV？”
凯文看小艾很迷惑，就放下手头工作，给小艾认真讲解起来。
凯文的话：
GMV是Golden Master Verification Test的简称，也就是我们通常说的成品测试或介质测试。它的测试目的是保证客户拿到的成品没有质量问题。从软件发布的角度来说，就是保障客户顺利安装并使用产品生产部门提供的光盘（CD或DVD）或网上下载的应用程序。
在GMV阶段构建团队会向测试团队提供DVD ISO文件和DVD光盘作为驱动，测试团队则使用这些介质来进行测试。GMV的另外一个测试目的是保证产品在前期缺陷修复过程中不会因为代码改动而产生新问题。
因为GMV测试的重要性及其在进度上的紧迫性，GMV测试阶段需要各个测试团队在已有的测试案例里有针对性地选择重要案例进行重新测试，以保证之前的代码改动不会为最终成品带来新的质量问题。切记不要在此阶段运行新的测试案例，以保证GMV能在合理时间内完成（一般2～4周）并成功交付给客户或投放市场。
小艾听了凯文的简单介绍，对GMV有了初步认识，但是对GMV具体计划和测试策略要点仍旧不甚了解。到底GMV需要怎么进行？而我们应该在GMV中做些什么呢？
小艾星期四刚到公司就接到项目经理发的通知，要求下午2点项目全体人员参加重要会议。
会议准时开始，凯文站在会议室前方扫视了下面一张张熟悉的面孔说：“这个时间召开此次会议的目的，我想在座的老员工都能猜出来吧？”
“不错，经过大约一年各团队的努力，我们已经到了最后的冲刺阶段。前两天和各团队负责人一起详细讨论了目前项目的进展情况。我很高兴地宣布明天将构建第一个成品候选介质！”
随后凯文站在放映机前，详细汇报了各测试团队到目前为止的测试结果。总体来讲，除了性能测试还有一些少量收尾工作，其他测试类别像功能测试、安装测试、产品迁移测试、多国语言测试等都已顺利完成，测试用例都已100%完成，通过率都达到甚至超过质量计划里所保证的百分比。失败的测试案例目前都有了解决方案，并在现有测试驱动上通过了补丁测试，按照计划，第二天下午4点前就能完成所有源代码改动。
会议最后，凯文凝重地说：“接下来两周的成品测试将是关键的一场战役，就像足球场上的临门一脚，关系着我们整个产品发布的成败。希望大家鼓足干劲坚持到最后的胜利！”
9.1.2 协同作战--成品测试特性
小艾听完凯文的讲话，对即将到来的成品测试充满了期待。但他还不是很清楚自己具体应该做些什么。会议结束后凯文找到小艾给他分配测试案例。小艾看了一眼测试案例，不解地问：“以往我们功能测试都是在已装好产品的机器上直接进行测试，这次为什么让我们自己安装产品呢？安装测试不是应该安装团队负责吗？”
凯文回答说：“你这个问题问得很好。由于成品测试的特性，成品测试有其独特的测试策略。它要求各团队协同作战，才能在较短时间完成所有测试任务。”于是凯文给小艾详细讲述了成品测试的特点。
项目经理凯文的话：
成品测试的一个主要目的是测试最终介质和包装有无缺陷，以保障客户拿到最终产品时能顺利安装并使用我们提供的光盘（CD或DVD）或网上下载的应用程序。对于不同操作系统平台或数据库，调用的安装程序和启动的包装有可能不同。这就要求在成品测试阶段，尽可能涵盖所有系统平台和数据库，以保障客户在不同系统上的正常应用。
对于数目繁多的操作系统平台（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等）和数据库类型（DB2，Oracle，Cloudscape等），安装团队是不可能在短时间内涵盖所有的，这就要求各团队协同合作。一般来讲，功能测试团队、构建团队、产品迁移测试团队和多国语言测试团队会用DVD或DVD ISO文件在较常见的操作系统平台上简单安装产品，并进一步进行功能或多国语言测试。安装团队会在此阶段着重测试一些复杂的安装路径和操作系统平台。
小艾听完凯文的解释，明白了成品测试阶段各团队协同作战的必要性。脱口而出道：“是不是人人都要手握光碟来抓虫子啊？”
凯文笑道：“比喻很形象，但我们除了传统物流方式销售给客户CD或DVD光碟，还允许客户通过网络下载我们的应用程序。一般会把DVD ISO文件经过压缩放到网络上供客户直接下载。所以除了测试真正的物理光碟，我们还要测试放到网上的可供客户下载的DVD ISO文件，即常说的电子版光碟。”
小艾点头说：“哦，我明白了。凯文，成品测试阶段测试范围是如何规定的？还有，它的测试策略又都有哪些呢？”
凯文说：“我很高兴看到你对成品测试的求知欲，我现在还要去构建团队安排一下工作。这样吧，我把各测试团队成品测试的计划发给你，那里面详细描述了各测试团队的测试范围和策略。你仔细看一下，有什么问题可以问我。”
9.1.3 取舍之间--测试范围和策略
小艾系统地阅读了凯文发给他的成品测试计划，并且根据各团队计划对成品测试阶段的测试范围和策略做了总体归纳总结。
成品测试范围及策略归纳总结：
成品测试的测试案例必须是以前测试阶段测试过的案例，不应该有新测试案例或对新系统平台设置的测试。
所被挑选的回归测试案例要尽量能够涵盖程序的主要功能，以确保程序的主框架没有由于前期代码改动而产生缺陷。
对于前期测试中发现较多问题并改动代码较多的功能部分，应多挑选一些回归测试案例进行回归测试。
性能测试一般选择最被广泛使用或者大型客户常用的平台。测试用例选择最简单的分支，但是尽量扩大分支覆盖的范围，一般选用可靠性测试（关于可靠性
测试的定义见6.2.4节），测试时间一般在24～72小时。
所有测试都应基于DVD或DVD ISO文件安装的应用程序，严禁再用构建测试环境来安装应用程序并进行测试。
安装应尽量涵盖应用程序支持的所有系统平台（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等），数据库类型（DB2，Oracle，Cloudscape等）和安 装模式（快捷安装，定制安装等）。
由于时间限制，成品测试案例大约占前期测试阶段所有测试案例的5%～10%。
除了各测试团队详细的测试计划，在凯文所提供的材料中，还有一份在测试中要求各测试团队统一检查的清单列表。清单列表里主要需要检查下列内容。
a、DVD布局
应按照产品构建团队提供的DVD布局文件里所列信息核对所测DVD光碟或电子光碟，布局一般包括：
不同系统平台的安装设置文件：setup.exe，setup_aix等。
不同支持语言的说明文件（readme）。
自动调用文件（AutoRun）：autorun.exe，autorun.inf等。
产品版本文件等一些和产品有关的文件。
除了核对布局里应存在的文件名外，还应该核对文件大小以保证文件没有损坏和缺失。整体DVD内容大小也是需要核对的一个数据。
b、产品安装
根据安装说明书和安装测试模式要求进行产品安装。
c、产品许可同意书
在安装过程中，检查产品许可同意书是否正确显示，并阅读上面所列内容是否正确。最重要的是要检查产品许可同意书里产品名称和版本号是否正确。
d、产品主要页面
安装成功后，根据测试的不同产品特性，浏览一下主要网页是否能够正确显示。
e、产品数据核心文件
产品中有些是产品信息核心文件，文件中的数据会被多个子程序引用。例如Product.xml中产品名称及版本号等。应检查这些文件是否安装在正确文件夹里，并打开文件，根据产品情况检查文件里面所列的信息是否正确。
f、产品构建号码
最终提供给客户的产品中一定要有产品构建号码并存储在一个产品文件中，以方便以后查询。这个产品构建号码一般以构建日期来命名。安装成功后，需要打开文件检查产品构建号码是否正确，以确定所测试的驱动版本是正确的。
g、数据库核心数据
一般产品都会有些核心数据存储在数据库里。可以根据情况列一些数据库查询语句在清单列表里，并要求各团队进行查询，以确保核心数据在安装过程中被正确引入到数据库中。
h、产品文档文件
对于每个产品来讲都会有文档文件，其中包括产品使用说明，产品问题帮助等。安装成功后，应检查一下这些文件是否被安装在正确文件夹里以确保能够被程序正确调用。
i、产品卸载
所有测试都结束后，应按照产品卸载说明书卸载产品。
9.1.4 争分夺秒--成品测试周期
GMV测试开始当天小艾很早便来到公司，看到各团队负责人都已在办公室里。凯文递给他一张DVD光碟，说：“这是构建团队周末烧刻的产品光碟，里面是上星期五的驱动。你今天的任务就是用DVD安装产品并完成上星期四分配给你的相应功能测试案例。所有测试必须在第二天下午4点之前完成，有什么问题吗？”
小艾问道：“如果没有发现任何新缺陷，明天上午就应能完成所有案例测试。如果真是这样，我是否就再也不用在新驱动上测试了？”
凯文说：“这需要视情况而定。就像我以前讲的，成品测试是各团队协同作战。一个团队的完成并不代表整体的完成。成品测试一般需要1～2周时间，对于每个驱动，大约需要2天完成。根据以往成品测试经验，大约需要构建3～5个驱动才能最终完成。对不同的驱动，由于周期短，时间有限，每个测试团队根据情况有自己的测试策略。并不是每个驱动都要重新测试所有案例。”
小艾稍后收到凯文的邮件，上面是各测试团队对不同成品测试候选驱动的测试安排。
功能测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品功能测试案例。
在接下来的成品测试候选驱动上，只运行功能测试可接受性案例和由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的成品功能测试案例。
安装测试：
在所有成品测试候选驱动上2天内完成所有被选定的成品安装测试案例（集群环境安装测试案例除外）。
在第一个成品测试候选驱动上，3天内完成集群环境安装测试案例。在以后的成品测试候选驱动上如果没有和集群环境相关的代码改动，就无须重新运行集群环境安装测试案例。
构建测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品构建测试案例。
在接下来的成品测试候选驱动上，如果无Java代码改动，则无须重新运行java API扫描。但需重新运行源代码扫描案例、版权扫描案例及SAR扫描案例。
性能测试：
在第一个成品测试候选驱动上3天内完成所有被选定的成品性能测试案例。
在接下来的成品测试候选驱动上，如果无性能相关的代码改动，则无须重新运行性能测试案例。
在倒数第二个成品测试候选驱动上，重新运行所有被选定的成品性能测试案例。
迁移测试：
在第一个成品测试候选驱动上3天内完成所有被选定的成品迁移测试案例。
在接下来的成品测试候选驱动上，如果无迁移相关的代码改动，则无须重新运行迁移测试案例。
多国语言测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品多国语言测试案例。
在接下来的成品测试候选驱动上，只运行多国语言测试接受案例和由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的成品多国语言测试案例。
定制测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品定制测试案例。
在接下来的成品测试候选驱动上，只运行由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的定制测试案例。
小艾看后挠挠头说：“这么复杂啊，每个测试团队对不同的成品测试候选驱动的安排都不太一样，完成时间也不尽相同，怪不得你要作为总调度来统筹安排。”
凯文笑了笑说：“各个团队对不同成品测试候选驱动的安排是基于测试类别的不同特性，其实解读起来不外乎以下几点。”
凯文对不同成品测试候选驱动测试策略的解读：
各团队必须完全测试第一个驱动，以后的驱动需要审时度势，看编码改动情况来决定测试范围。
由于每个驱动都需要重新构建打包，因此每个驱动都需要进行必要的安装测试和构建测试，以保障没有重要文件的缺失。
项目组决定的最终成品候选驱动，将会是客户最终拿到的产品。各测试团队尽可能在此驱动上重新完成重要测试案例，以防功亏一篑。
迁移测试和个别安装测试（例如集群安装）案例测试周期长，极少受由于其他类别测试缺陷而修改代码的影响。因此在整个成品测试周期一般只需要测试一遍。
由于大部分测试都会在两天内完成，为了有效缩短整个成品测试周期，第二个成品测试候选驱动会在两天后开始构建，而不必等待迁移测试和个别安装测试（如集群安装）案例测试结束。
小艾听了凯文的解读，觉得很有收获，深刻认识到成品测试周期的紧迫性，感觉各团队都是在争分夺秒来完成最后冲刺。于是他匆匆和凯文告辞，拿着DVD赶快到实验室开始执行分配给他的成品测试案例。
（未完待续）
相关链接：
一个软件测试工程师的成长日记（连载一）
一个软件测试工程师的成长日记（连载二）
一个软件测试工程师的成长日记（连载三）
一个软件测试工程师的成长日记（连载四）