一个成功软件测试项目有什么经验？

本文以一个工作流测试项目为例， 总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。

测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。

Wokflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。

下面，我们大概介绍一下这个项目的实施情况： ● 项目规模与测试人员配置： ○ 项目代码行数：5万行 ○ 开发人员配置：开发人员5名、实习生1名 ○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名 ● 项目测试时的系统部署情况： ● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。

发现Bug总数和缺陷密度都达到了要求的标准。

当然，测试周期的实际值比计划值晚了两周，原？因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。

回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。

测试如何尽早介入 基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。

简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。

如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。

但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如： ● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。

● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。

那么，在这个XXX5.2 Wokflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如： ● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。

● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。

● 和项目团队中的集成组和开发组协？商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。

● 开发人员每天下午4:30之前提交所有可编译的代码，每天晚上进行日编译； ● 开发经理根据版本稳定情况，每周提交测试申请单。

● 测试人员根据测试进度需要，提取测试版本。

● 提前准备测试环境，包括数据库环境，操作系统和we应用服务器，以及复杂集群环境。

● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。

根据产品的成熟度调整测试策略开发测试一盘棋。

测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。

在这个XXX5.2 Wokflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。

来源于考试大 产品开发期同情的测试 要忍！要在这个能够发现大批Bug的黄金时段学会做减法。

就现实而言，这个阶段的产品，大多难以满足系统测试的条件。

如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。

另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。

因此，“产品开发期”的测试切忌生硬。

其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员： ● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。

● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。

产品成熟期积极的测试 随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。

此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。

于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。

我来测试一下测试有效,问题发布成功。

第一招 学会利用网络 刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。

当时觉得有了这些 “ 武林秘籍 ” ，成为高手指日可待。

最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。

一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “ 聪明才智 ” 很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。

解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此 Google 成了我的最爱，关键字成了我变化的招数。

在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。

也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 ” ，所以只要你耐心找，答案就在身边。

这里总结一下利用网络搜索引擎的技巧： 组合搜索 每次搜索某个文件，如果只给出一个单词进行搜索，经常会出现成千上百万计的匹配网页。

然而如果再加上一个单词，那么搜索结果会更加切题。

选择表述内容的词组 一般我在网页搜索引擎的时候，选择一些可以表达我要查找内容的关键词组，用来缩小搜索范围，从而找到搜索结果是最好的办法。

运用词组搜索涉可以先先简单地输入一个问题作为词组搜索，如果仍然找不到合适的，那就用多个可以表达要查询内容的关键字进行查询。

急寻软件测试步骤与流程,懂行的给正确答案,加分

百度上都回答的是书面的测试种类，管个屁用。

告诉我们什么是白盒测试，什么是黑盒测试，给一个实际的软件让我们测试，你会用白盒或黑盒给测试吗？都是纸上谈兵。

小弟总结的具体测试方法，希望能帮助到各位初学者。

1、链接的错误（这类最简单，难度1星）：这是一个最普通最普通的测试，就是点啊点的，那个链接报错了，就测出来了。

例如：提交，新建，删除，这类按钮，不能实现其功能。

或，“更多”不能打开链接，连接是否正确。

2、界面样式问题（这类比较细致，繁琐。

难度3星）：在不同浏览器上有不同的表现形式的，主流浏览器有ie,360，火狐，搜狗，等。

某些界面在需要填写数据的时候数字串太长是否会影响界面格式。

所占空间增大可能会占用到其他框架。

3、逻辑的错误（这类比较难，难度5星）：输入框是否要有限制，长度限制，库存限制。

没有登录但是仍然可以购物。

订单的操作包括付款，取消订单。

继续购买。

订单的退款退货信息等。

我知道这些肯定不足够，等大家一起完善。

希望帮助到大家。

...

一直显示＂请输入用户名和密码＂,老无法测试接收发送,成功不了....

新郎邮箱最近正在升级，所以会出现一些异常，你不要做任何的修改，等待几天再说，先使用其他邮箱来工作，等到升级完成后就会一切正常的。

你可以试一试这样操作看看行不行，打开IE选项常规下删除Cookies和临时文件以及历史记录，把安全、隐私、高级选项设置为默认设置，内容选项下的自动完成了面，点击清除表单、密码等，防火墙调整的低一些。

如果你使用第三方浏览器的话，还需要把安全猎手等有关阻止弹出等选项设的低一些，重新启动浏览器就可生效。

橙光游戏手机版制作了游戏后发表测试版本,上面显示发布成功了,...

重新设置邮件收发软件。

以新浪免费邮箱为例 邮件服务器设置 收信（pop3）服务器： 发信（smtp）服务器： 请注意这项：选择smtp服务器要求身份验证选项 不要选择----使用安全密码验证登录 要选择----我的服务器要求身份验证 别忘了用英语输入法输入 谢谢你的提问！ 祝你顺利发送。

软件测试用例实例

随着市场对软件质量的不断提高，软件测试不断受到重视，但是由于总体上，国内软件项目过程不规范，导致重视编码和轻视测试的现象，对于软件测试的重要性、测试方法和流程等还存在很多错误的认识。

根据作者的软件工作经验，本文列举了七种有代表性的软件测试得认识误区，并作了剖析和相应的解释。

希望对软件行业的技术和管理人士，正确认识软件测试起到一定的作用。

作为软件质量保证和可靠性的关键技术手段，软件测试正日益受到重视。

但是，我国不少软件企业的软件开发模式仍然处在无序开发的不规范状态，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于很多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误区，这进一步影响了软件测试活动的开展和真正提高软件测试质量。

误区之一：软件开发完成后进行软件测试 人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。

据此，认为软件测试只是软件编码后的一个过程。

这是不了解软件测试周期的错误认识。

软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。

因此，软件测试贯穿于软件项目的整个生命过程。

在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。

软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。

软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。

如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。

更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。

误区之二：软件发布后如果发现质量问题，那是软件测试人员的错 这种认识很打击软件测试人员的积极性。

软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。

从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。

出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。

应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

误区之三：软件测试要求不高，随便找个人多都行 很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。

这是由于不了解软件测试的具体技术和方法造成的。

随之软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。

软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。

所以，具有编程经验的程序员不一定是一名优秀的测试工程师。

软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。

误区之四：软件自动测试效率高，将取代软件手工测试 近年来，软件测试自动化技术的研究取得了很大进步，市场出现了一些商业化的专用自动测试工具，并且已经成功地应用在某些软件的自动化测试过程中。

自动测试具有测试效率高、人工干涉少、灵活方便等优点。

但是，自动测试技术的仍然处于不断发展中，当前市场上的自动测试工具仍然只能满足某些软件的部分测试特性，应用范围受到限制，需要针对被测软件，单独编写和调试比较复杂的测试脚本，而且自动测试工具价格通常十分昂贵，非一般软件公司可以购买的起。

在当前的软件测试领域，测试工程师的手工测试仍然处于十分重要的地位，目前软件自动测试仅是手工测试的辅助手段。

由于软件自身的复杂性和灵活性，而高度发达的人类思维的优势，决定了无论自动测试技术多么发达，手工测试将不会消失。

误区之五：软件测试是测试人员的事情，与程序员无关 开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。

另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。

对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。

程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。

误区之六：项目进度吃紧时少做些测试，时间富裕时多做测试 这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。

一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。

因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险...