软件测试活动管理 软件测试bug管理工具
什么是软件测试项目管理
项目管理是一个管理学分支的学科，指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。
项目管理是对一些与成功地达成一系列目标相关的活动（譬如任务）的整体。
这包括策划、进度计划和维护组成项目的活动的进展。
项目管理的软件测试有哪些经验呢？
1.测试用例包含测试文档和测试数据两部分，在实际操作之前，请先准备好测试数据，即要在界面上录入的数据，原则上是所有在界面上输入的数据都要写进测试数据（excel表）中，并注意归纳整理，每组测试数据都应有相应的测试目的。
2.测试数据的准备需要考虑到一定的覆盖率，但100%的覆盖是肯定做不到的。
请根据测试用例文档的内容尽量达到最有效的覆盖。
3.测试用例并不是一成不变的，应在测试过程中随时更新、补充，不断完善。
如果在测试过程中发现原测试用例有不完整甚至是错误的情况，请及时补充或修改。
这一点很重要，切记。
因为在此时多一分心，将来的测试工作必会少几分力。
4.在测试过程中发现的BUG请填写到缺陷管理工具TTP中，特别注意要将BUG情形，重现步骤等描述清楚，不要因偷懒或错别字等原因使得开发人员无法正确理解和无法重现该BUG，甚至造成歧义，以免对开发者和测试者增加许多不必要的工作量。
5.做好BUG的跟踪工作。
测试工作并不止于发现BUG，而应对每个BUG跟踪到底。
BUG自提出之后，就要一直跟踪，敦促相关人员解决。
时间太长仍未解决的，要查明原因，并汇报至项目经理处。
在TTP中，则体现为所有的BUG最后都要处于“closed”状态。
6.做好版本控制。
程序源代码的版本控制工作由开发组负责，但测试组也需要管理好测试系统的版本，保持与最新程序同步，以免对不正确的版本进行测试，做无用功。
7.做好回归测试。
开发人员修改BUG后，测试组要尽快将程序更新至测试环境，并做回归测试。
此时除了验证所发现的问题是否被修正外，还要特别注意的是，此项改动是否会对系统的其它部分造成影响，从而产生新的BUG。
因为有时候程序员对程序的一个不正确的，哪怕是小小的改动，都可能会对系统带来更多的BUG，而这些BUG往往又是很隐蔽的，所以要特别小心。
这一点非常难做到，需要靠测试人员的经验和细心。
这里有一个比较好的方法，就是要求开发人员在解决问题的同时，要详细的说明该问题产生的原因，及他对哪些源程序文件做了什么改动，填写到TTP中，越详细越好。
根据我们部门以往的测试经验，我觉得这一点做得还很不够，很多程序员并不愿意做过多类似的归纳整理工作。
其实这是对大家都有好处的事情，一定要请大家共同配合。
8.在测试过程中，如果重复的操作过多，在条件允许的情况下，可考虑使用功能测试工具winunne,quicktestpo等来简化操作。
测试项目管理和普通的软件测试有什么区别呢？
这是我从一个工程师干到负责测试项目所积累下来的经验，就算合格了，在项目的什么时候要做什么事情。
第三，你要会涉及到的各种测试任务、用户、开发，以及整个测试项目中的某个环节。
而测试项目管理负责的工作就比较多了，首先，和需求、公正的态度，你要会正确的时间安排，首先要保证测试团队在项目中，有足够的时间进行测试，是做好一个测试项目管理必备素质之一、回归，保证项目的质量，同时不能造成项目延期，作为测试团队项目的管理者，你不仅负责着团队的工作，更是要能够和上级，你要对你的团队人员准备的测试用例是否符合要求有个直观的了解，良好的心态，你会得罪人、不懈的坚持，不过请记住，你要了解你所带领的测试团队。
其次，你要了解你的项目流程规范，测试经理都会需要和他们打交道。
最后是心态的调整，测试在国内最不待见的（你找茬，没人会喜欢你），所以、规则、体系，第四，好的沟通、用户进行沟通，无论是需求阶段的先期沟通和介入，还是在执行阶段，甚至后期的运维的时候、下级、项目经理，因为在每个测试执行前，你需要进行测试用例的评审，主要负责1）测试用例的准备，当然其实性能、安全也是类似的工作，相对而言软件测试主要负责执行类的工作，2）测试执行，3）提交缺陷测试项目管理和软件测试区别还是很大的软件测试相对而言你要负责面可能就是做好自己的工作...
软件测试人员的量化管理有哪些呢？
一、测试设计 1、工作效率相关指标 （1）文档产出率：这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。
用于考察测试人员测试用例文档的生产率大小。
公式：∑测试用例文档页数（页） ∑编写测试用例文档有效时间（小时） 参考指标：根据项目汇总得出平均在 1.14 页 小时左右，高于此值为优，低于此值为差。
（2）用例产出率：这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。
测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。
方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。
公式：∑测试用例数（个） ∑编写测试用例文档有效时间（小时）来源：考试大 参考指标：平均 4.21 个用例 小时 2、工作质量相关指标 （1）需求覆盖率：计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。
来源：www.examda.com 公式：∑测试用例数（个） ∑功能点（个） 参考指标： 100 %。
如果连功能指标都不能满足 100 %覆盖，起码说明测试不充分。
这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。
（2）文档质量：测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。
此指标考察测试人员文档编写的质量如何。
公式：∑缺陷数（评审和同行评审）（个）来源：考试大 ∑缺陷数（评审和同行评审）（个） ∑测试用例文档页数（页）采集者退散 参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。
如果缺陷数大小不能直接用于比较就使用缺陷 页方式进行横向对比。
（3）文档有效率：使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。
用于考察文档是由有效的指导了测试工作。
公式：∑缺陷数（系统测试）（个） ∑测试用例文档页数（页） 参考指标：平均 2.18 个缺陷 页 注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。
（4）用例有效率：使用测试用例发现的全部缺陷除于测试用例数总和。
这一指标是上一指标的补充指标，用于考察用例质量是否较高
软件测试之测试管理有哪些原则？
5.重视结果而非时间 许多认可建立在员工完成工作的时间上，而不是他们最后的成绩上。
但是，花费在工作上的时间不一定和创造性有必然的联系。
如果你真的想改善对创作性和工作效率的认可的话，不妨考虑保证你员工每周只工作40个小时。
我常常听到一种表示对员工的异议就是“你整整一天什么都做不出来。
6.承认自己的错误 每个人都会犯错。
他们会因为忘记开会而使客户发怒。
承认你犯错是令人尴尬的。
我们中的许多人认为对小组承认自己犯错会失去尊严。
如果你不是经常犯错，你承认错误的时候其实能够赢得尊敬。
如果你忘记一次会议，你为此道歉，其他的人会理解你并且最终原谅你。
7.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工，你的老板对你说“我们是否可以在下个十月完成项目？”回答说“当然”会令人惊讶。
但是，你的员工会因为你回答“我要考虑一下。
”而表示赞赏。
软件测试的活动是什么
软件测试的活动是指对软件的功能、性能、安全性等多个方面，按照用户需求或一定的标准进行检查验证的过程。
实际上就是寻找软件中存在的缺陷和问题，以提高软件的质量。
主要活动包括编写测试计划和测试方案、提取测试需求、设计测试用例、执行测试用例、提交缺陷、回归测试等内容。
软件测试的主要工作内容是什么？
、 软件测试基础知识： 测试计划编写、设计测试用例、编写测试报告、编写BUG报告单、跟踪BUG修复情况、还需要良好的沟通能力、以及各种测试阶段所使用的测试方法、单元测试、功能测试、集成测试、系统测试等等、CMMI /ISO9001 2、 各种测试工具的使用： 我们在测试的工作中为了能够提高工作效率进程会用到很多工具、QTP、LR、QC、TD、Bugfree、VSS、SVN等等工具、虽然说工具不是万能的但是工具能为我们提高工作效率所以不能吧工具当神一样看待、但是必须得会熟练的使用 3、 操作系统相关知识： Windows、linux、uinx这些都必须会使用、而且不仅仅是简单的操作、一般的服务管理、注册表编辑、命令行操作都需要会、可以想象下一个连apache服务都不会安装配置的人、谁能想象你可以做好基于apache环境的测试工作、什么？不知道怎么查看磁盘压力、IO数据。
windows linux都有提供自带的工具可用于查看这些数据、perfmon、top什么的。
4、 数据库知识： 现在Oracle的DBA待遇比一般的开发人员待遇还高就知道数据库在企业中的重要性了、作为测试人员虽然不需要有DBA的能力、但是基本的数据库操作你必须得会把、不管是Oracle、DB2、MSsql还是mysql最少都应该能熟悉使用其中的一二。
5、 计算机硬件知识： 做过性能测试的朋友都知道在性能测试过程中硬件性能也是一个非常重要的指标、CPU、内存、IO、带宽等等、如果你是做硬件测试的。
那么就更不用说了。
交换机、路由器、防火墙这些设备都需要有所了解。
6、 网络协议： 如果你还知道TCP和UDP有什么不一样的话请赶快去补充点知识吧、互联网时代、一切都通过网络传输、常用协议必须得了解、曾经面试了一个测试工程师做了2年的测试居然不知道自己测试软件使用什么协议、这样的人是你的话你敢招么？ 7、 开发语言即代码编写能力： 虽然不会写代码也能做测试、但是如果你想做到高级测试工程师以上、那么代码编写能力就是必选项、如果不会写代码、那么你不可能成为高级测试。
高级测试工程师的一部分工作就是在写测试工具。
虽然测试也需要写代码但不需要和开发一样那么精通某一门语言、可是测试却需要了解很多门开发语言（举一个简单的例子：你现在所在的项目从C++语言、2年后你换工作了、新公司的开发语言是java或者是VB什么的）所以在开发语言中测试需要更广的学习。
8、 行业知识：行业知识之所以写在最后面是因为前面的7条我们都可以通过学习来掌握、但是唯独行业知识却只能通过工作经验来积累、不要说你去看几本书就知道通信行业、医疗行业、或者是航天行业、你认为在书本上面能学到么？ 由于行业知识的特殊性所以建议朋友们不要频繁的跳槽、经验的积累是需要时间来沉淀的。
9、 具有一定的美学观： 这个说起来比较拗口一点、简单来说不管是开发活动还是测试活动、最后的目标就是将产品推向市场、而且得到用户的认可。
所以如果产品在需求分析阶段就出现了偏离用户航道、那么就算测试 开发做得再好这个项目也是一样会失败。
所以各位如果有幸能够参加需求评审的话、请不要吝啬你的言论。
10、请不要忘记时刻学习着： 这点我相信大家应该都能理解所以不用写什么：仅此一点“不学习就会落后” 总结：说了那么多技能或者是说是需要掌握的技术、如果你没有一颗发现缺陷之美的心态、没有一颗以提高质量为前提来投入工作中、那么就算你其他做得再好也不过是万千软件测试从业人员中的一枚。
测试活动大部分用于发现缺陷、而发现缺陷之后的工作尤为重要：怎么样从发现缺陷到提高质量。
-