软件测试项目介绍 软件测试项目介绍和项目经验怎么写

我本身是做软件行业的，已经做了七八年了，给你一些建议，仅供参考~

① 项目介绍的部分，要介绍清楚项目内容，并突出软件测试在项目各阶段中的位置，例如，项目的开发模式如果是V模型，那么软件测试伴随每个开发阶段，包括设计、编码等等。

② 项目经验这部分需要详细考虑了，分为两个方面，一、测试技术；二、角色职能；

· 测试技术

项目当中使用到的技术一定要简明易懂的提出来，例如是否用到自动化测试，性能测试，以及测试的OS是Linux还是Windows之类的，用到的数据库是MySQL还是Oracle...

· 角色职能

在项目当中，你扮演的角色是什么。如果是测试工程师，那么有没有妥善的完成测试设计和测试执行；如果是高级工程师，有没有做好测试分析工作，有没有很好的理解需求等。

希望对你有所帮助，有疑问的地方欢迎探讨。

软件测试 面试时项目经验怎么介绍?需要从哪几方面说?

1.软件测试面试时，介绍项目经验，应重点突出跟你面试公司相关或者同类型的项目。

比如公司从事的主要是web项目：以前主要是从事web系统的项目，做过不少的项目，也积累了不少的测试经验，能够独立完成产品的测试。

比如公司从事的主要是app项目：以前主要是从事的web与app的项目，最近做的项目主要是app为主，做过不少的项目，也积累了不少的测试经验，能够独立完成产品的测试。

2.软件测试面试时，介绍项目经验的步骤：

先介绍项目的整体规模，设计了多少用例、发现了多少缺陷……再局部介绍：封测的流程、用例设计的方法……你在项目中的角色和职责……自己的特色、那里做的最好、遇到什么困难……总结……

扩展资料：

软件测试 面试时介绍个人的信息，应扬长避短

1、年纪太大与太小，都不需要主动去说明。

比如我年纪只有21岁 例子：面试官您好，我叫***，来自于哪里，从事软件测试工作有几年了。

2、专业不对口也不要过多的去提及（提到了就会增加问你的概率）。

比如你的专业是机械专业，例子：面试官您好，我叫***，来自于哪里，从事软件测试工作有几年了。

参考资料：人民网——面试成功从自我介绍开始

软件测试 项目总结怎么写啊？高手指教下

能表达得有条理就可以了。不必介意格式。总结无非就是总结经验，吸取教训咯,本人什么时候参加了什么项目的测试

这个项目是干什么的

我在项目组中做了什么

遇到了什么困难 如何解决的

通过这个项目我学习到了什么

我要感谢谁谁谁

我以后要在什么方面加强

此致

敬礼

附件一

X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。

从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。

在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。

下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！

一、对项目的认识

进入这个项目是在今年十月底，当时测试经理和C已经把Setting（当时是Admin）部分的测试结束了，所以我直接开始接着D的测试文档继续往下写（当时是从Revenue的Report部分开始，即现在的Report模块）。因为跳过了逻辑部分，所以对整个项目逻辑理解很不够，开始写的测试文档也非常浅显，就是描述了一下页面布局。这里我的感觉是，测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。当时C简单地跟我介绍了一下整个项目，我的感觉是沟通不够，对逻辑理解比较欠缺。

Report部分写完，就直接开始测试——用自己刚写完的文档进行测试，效果显然不够理想。因为测试人员刚进行该模块测试文档的编撰，再让他对该模块进行测试，这样做的一个后果就是，测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。

测试完Report后，紧接着开始进行Expense模块测试文档的撰写。这时我开始接触到一些逻辑，即Expense与Setting部分联系的逻辑。这时遇到的问题最多最杂，随时随地都需要与C，甚至项目经理进行沟通。由于之前对主功能（Setting部分）的不熟悉，这种一边沟通一边撰写的测试文档可以说是漏洞百出。由于项目时间也比较紧，我需要在一周内完成整个Expense模块的测试文档，所以最终完成的文档很不理想。这里我觉得还是之前沟通不到位的问题，应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写，而不是一开始就撰写测试文档。

接着就是根据自己撰写的Expense文档对Expense模块进行测试，效果也不够理想。这里我还有一个建议就是，如果测试人员在初始进入项目时没有得到及时沟通，至少需要给他一周时间先对主功能（即Setting部分）进行完整测试，对照需求手册及主功能发现的BUG，对主功能进行深入理解。

Expense测试完成后，开始对整个项目进行回归测试。在这个过程中，我逐渐理清了整个项目的逻辑，也开始试图修改以前的文档。但由于文档量太大，文档结构不够清晰，时间也比较紧，修改难于进行。大部分原因是我经验不足造成的，之前撰写测试文档时，思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。

回归测试结束后，整个系统逻辑已经比较清晰。这时项目进行新一轮的迭代，用户需求改了很多，其中包括增加、修改大量功能、名称，以及对整个系统结构进行重构。这对测试文档而言改动点非常多（包括结构顺序改变、测试编号订正、功能模块名称修改等），而且需求文档并未因此变化，造成最后测试文档与需求文档的不匹配。这是一个协调的过程，系统迭代后，需求文档应及时随着系统进行修改。

迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。这种连带BUG的产生可以说是防不胜防，让测试人员苦恼不已。到现在我也没想出解决办法，只能说对模块之间的联系及交互逻辑理解仍需加深。

迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。

最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过去提交修正过的所有BUG重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户本人，一个为该用户代理人delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。

在验证过去修正过的BUG时，仍然发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到奇效。

至此，整个项目的测试算是告一段落。用户过来测试后提出一些BUG，经过分析，绝大部分属于用户的一些想法，与测试漏洞无关，整个测试算是圆满结束。

二、经验和教训

这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。

经验主要如下：

1、 学会如何将书中的理论与实践相结合；

2、 学会如何根据项目Demo及需求文档撰写测试文档；

3、 学会如何根据项目变更修改测试文档；

4、 学会如何用英文撰写文档，提交，验证问题；

5、 学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；

6、 学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；

教训如下：

1、 撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；

2、 撰写测试文档时结构不清晰，导致后期难以维护和修改；

3、 测试过程中心态有些浮躁，有些急于求成；

4、 还没有形成测试思维，测试过程思维显得有些混乱；

5、 对BUG轻重缓急界定不够，导致有时测试难以继续进行（对一些影响进度的低级别BUG优先级定得太低）；

三、对未来改进的一些建议

经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：

1、 在测试之前项目经理有必要对测试人员进行项目培训，让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；

2、 在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；

3、 同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；

4、 从一开始就高度重视并发问题，并发问题暴露得越早越易于修改；

5、 项目后期除了不留死角、轮番地扫遍每一个角落（多人协作）外，还需要将过去所有解决的BUG全部验证一遍，会发现不少难以预见的BUG；

6、 对于本项目，目前还有32个延迟（Pending）的BUG，里面大部分为性能和并发问题，还有一些光标、排序及空数据遗留问题，这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在；

跪求软件测试项目经验，请求给我详细介绍一下一个软件的测试流程

规范的测试流程 　

这是虫师的文章，但是总结的我很喜欢，引用过来希望能受益网页链接

放弃上份悠闲的工作，感谢那个带我入行公司，我想了解真正的测试在公作中如何进行的。所以，来到了现在这家公司。我很欣喜的是这测试有自己的团队，专业（对当时的我来说）的流程，以及与开发等同的地位。

现在的测试流程：

需求分析：

需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审：

这里会叫上所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求

开发人员编写排期：

开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期：

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例：

根据详细的需求分档，开始进行用例的编写。

用例评审：

在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

提交基线：

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。

具体测试流程：

开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。

测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

测试通过：

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。（转）

关于测试的交付物，我推荐你看《软件测试实用教程》，里面有个网上书店系统测试。还是很完整的例子。

软件测试流程，在给我一个测试项目的例子

一般的软件测试流程是这样：

1.拿到需求说明书，开始对需求进行测试，找出需求中的问题或者说不可测的地方

2.需求测试通过后，根据需求说明书制定测试计划，包括测试策略、测试方法、测试周期等

3.然后根据软件功能说明书编写测试用例，一般的公司都是根据需求说明书进行编写

4.搭建测试环境，包括软件环境和硬件环境

5.根据测试用例进行测试，提交缺陷

6.回归测试

7.测试完成后，进行测试总结，编写测试报告

至于测试文档，我这倒是有cmmi标准的一些文档，如果你想要的话，可以留下邮箱，我发过去。

好了，都发过去了。

软件测试的具体工作内容是什么？

1.搭建测试环境

2.写测试用例

3.执行测试用例

4.写测试计划、测试报告

5.测试，并提交BUG单

6.跟踪BUG修改情况

7.自动化测试，编写脚本，执行，分析，报告

8.性能测试，编写脚本，执行，分析，调优，报告

大概的是这些。

软件测试项目名称有哪些？

最好是你自己做过的项目，简单的比如学生管理系统，把你怎么设计测试，怎么完成测试写上去就行，面试的时候，会问你具体问题的。

软件测试工程师工作内容是什么？

以下是作为一名测试工程师的日常工作：阶段：编写测试计划，测试用例、测试缺陷报告，并执行测试用例，搭建Windows测试环境，熟练使用Bugzilla提交软件缺陷报告 至于为什么嘛，当然要一步步来的，要有计划才能执行啊，大概是这样吧 ^_^ 使用测试技术及工具：白盒测试和黑盒测试 Loadrunner、Winrunner 能够运用边界值、等价类划分法、因果图、状态图、大纲法等测试方法设计高效测试用例 软件测试工作总体流程图：

详细测试步骤： 1. 书写测试计划 2. 审核测试计划，未通过返回第一步 3. 书写测试用例； 4. 审核测试用例，未通过返回第三步 5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例） 6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW） 7. 集成部经理接到bugzilla发过来的bug 7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）; 7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RESOLVED，决定设置为INVALID）; 7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND） 8. 开发人员接到发过来的bug立刻修改;（bug状态RESOLVED，决定设置为FIXED） 9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）； 10. 如果复测有问题返回第六步（bug状态REOPENED） 11. 否则关闭这项BUG（bug状态CLOSED） 12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务； 13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试； 14. 测试任务结束后书写测试总结报告； 15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件； 16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。

转载请注明出处51数据库 » 软件测试项目介绍 软件测试项目介绍和项目经验怎么写