问题一：为什么要在一个团队中开展软件测试工作？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。而发现问题的这个过程称之为测试。

问题二：简述你在以前的工作中做过哪些事情，比较熟悉什么。
      此问题每个人都不一样。我自己的答案如下。
我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

问题三：你所了解的的软件测试类型都有哪些，简单介绍一下。
1.
基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check。
2.
功能测试。主要是依据需求或者需求分析文档，对所发布的版本进行测试，看看是否满足需求，是否出现了不必要的功能。
3.
单元测试。是开发人员进行的测试之一，一般是开发人员对很小的模块，比如函数进行测试，一般来说，开发人员还需要开发相应的测试桩来进行此类测试。
4.
集成测试。在大型的开发过程中，软件是模块化进行开发的，将不同的模块揉合在一起的话，需要进行的测试就是集成测试。
5.
系统测试。当软件提交给测试组后，是对整个系统的所有功能进行测试，一般来说，功能测试是系统测试的一个部分。
6.
压力测试。主要是在很大性能的情况下，这个性能已经接近了系统的极限，看看系统运转的情况。
7.
负载测试。主要是用各种不同的性能去检测系统，采集各个数据在这些性能情况下的数据。
8.
黑盒测试。指系统对你来说是完全不透明的，只给你留下了输入和最终输出，这个是功能测试的方法之一。
9.
灰盒测试。指在了解部分系统内部工作机制的情况下，对于系统进行的覆盖性测试。
10.
白盒测试。主要是在单元测试和集成测试的情况下，开发人员已知代码，对这一段的代码进行全路径的覆盖测试。
11.
界面测试。主要是看用户界面的友好性和易用性，是否有文字或者排版错误，是否有输入限制等等。
12.
回归测试。一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能相关的功能进行的测试。
13.
安装和卸载的测试。
14.
恢复测试。主要是一个系统在发生了灾难的情况下，从错误中是否容易恢复。
15.
兼容性测试。一个系统在不同的语言，操作系统下的系统测试。
16.
安全测试。系统在遇到攻击或者类似情况下的表现。
17.
Alpha测试。系统在给最终用户前，测试人员在实验室中模拟最终用户的测试。
18.
Beta测试。由部分最终用户通过使用来进行的测试。
19.
比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
20.
验收测试。一般是最终用户在接受产品前，依据自己所提出的要求进行的测试，很多情况下，验收测试可能委托第三方机构完成。

问题四：测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件。
包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

问题五：你认为做好测试计划工作的关键是什么？
1.
明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2.
坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3.
采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4.
分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

问题六：常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1.         等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2.         边界值分析法

　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3.         错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4.         因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

5.         正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6.         场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。


问题七：您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题


问题八：详细的描述一个测试活动完整的过程。

1.         项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

2.         开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3.         测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4.         测试用例完成后，测试和开发需要进行评审。

5.         测试人员搭建环境

6.         开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

7.         开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

8.         重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

9.         如果有客户反馈的问题，需要测试人员协助重现以及回归测试。


问题九：以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

       曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。

       也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。


问题十：您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

       测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。

       测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。


问题十一：您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

主要是保障在大量用户的情况下，服务能正常使用。


问题十二：在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

1.         在传统的BugZilla中，BUG描述应该包括以下的信息

2.         和BUG产生对应的软件版本

3.         开发的接口人员

4.         BUG的优先级

5.         BUG的严重程度

6.         BUG可能属于的模块，如果不能确认，可以用开发人员来判断

7.         BUG标题，需要清晰的描述现象

8.         BUG描述，需要尽量给出重新Bug的步骤

9.         BUG附件中能给出相关的日志和截图。

       高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

问题十二：BUG管理工具的跟踪过程

       用BugZilla为例子      

测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员

开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配

开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。

如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。

测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。


问题十二：您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

       尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

       一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。


问题十三：在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

       某次性能测试覆盖不足，造成系统崩溃。


问题十四：你对测试最大的兴趣在哪里？为什么？

最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。

刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。

我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。

第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。


问题十五：你的测试职业发展目标是什么？

测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。


问题十六：你自认为测试的优势在哪里？

有韧性

有能力面对挑战

有信心做好每一件事情

有比较好的教育背景

从以前的经理处都得到了很好的评价表明我做的很好


问题十七：当开发人员说不是BUG时，你如何应付？

如果确实是自己理解错误，则承认错误，没什么大不了

如果是需求不明，请项目经理补充清楚

如果双方理解不一致，且都不能互相说服，则请项目经理判断。


问题十八：你为什么想离开目前的职务？


问题十九：你对我们公司了解有多少？


问题二十：你找工作时，最重要的考虑因素为何？

工作的性质和内容是否能让我发挥所长，并不断成长。


问题二十一：为什么我们应该录取你？

您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。


问题二十二：请谈谈你个人的最大特色。

我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。


问题二十三：一个测试工程师应具备那些素质和技能？


问题二十四：集成测试通常都有那些策略？

       自上而下，自下而上，平面集成


问题二十五：测试结束的标准是什么？

       从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。

       如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。


问题二十六：软件验收测试除了alpha,beta测试以外,还有哪一种?

第三方验收测试


问题二十七：为什么选择测试这行？

最开始么，公司安排的，然后么，干一行爱一行，发现测试中间还是有很多东西需要学习的，再就是测试中有很多东西值得改进和研究。


问题二十六：为什么值得他们公司雇用？

      用自己的经验和其他同事一起发现更多的问题，同时不同行业的观点可以互相借鉴。


问题二十七：如果我雇用你，你能给部门带来什么贡献？

      分享我的测试经验和测试技能，提高测试部门技术水平

以前在这里看到一篇文章说，要积累各个常用模块的测试点，然后到需要测试的时候就根据这些测试点设计测试用例，我觉得这是一个好方法，就决定总结一下。我的实际经验不多，根据我在论坛中学到的零散的东西和自己的想象，总结出以下几点，欢迎各位继续补充。
1.        登陆
2.        添加
3.        查询
4.        删除

1.        登陆
①        用户名和密码都符合要求（格式上的要求）
②        用户名和密码都不符合要求（格式上的要求）
③        用户名符合要求，密码不符合要求（格式上的要求）
④        密码符合要求，用户名不符合要求（格式上的要求）
⑤        用户名或密码为空
⑥        数据库中不存在的用户名，不存在的密码
⑦        数据库中存在的用户名，错误的密码
⑧        数据库中不存在的用户名，存在的密码
⑨        输入的数据前存在空格
⑩        输入正确的用户名密码以后按[enter]是否能登陆

2.        添加
①        要添加的数据项均合理，检查数据库中是否添加了相应的数据
②        留出一个必填数据为空
③        按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
④        不符合要求的地方要有错误提示
⑤        是否支持table键
⑥        按enter是否能保存
⑦        若提示不能保存，也要察看数据库里是否多了一条数据

3.        删除
①        删除一个数据库中存在的数据，然后查看数据库中是否删除
②        删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除
③        输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
④        输入的正确数据前加空格，看是否能正确删除数据
⑤        什么也不输入
⑥        是否指出table键
⑦        是否支持enter键

4.        查询
精确查询：
①        输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
②        输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据
③        输入格式或范围不符合要求的数据，看是否有错误提示
④        输入数据库中不存在的数据
⑤        不输入任何数据
⑥        是否支持table键
⑦        是否支持enter键
模糊查询：
在精确查询的基础上加上以下一点
①        输入一些字符，看是否能查出数据库中所有的相关信息
设计功能和界面测试用例

设计功能和界面测试用例

1.1 文本框、按钮等控件测试

1.1.1 文本框的测试

如何对文本框进行测试

　a,输入正常的字母或数字。
　b,输入已存在的文件的名称；
　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　d,输入默认值，空白，空格；
　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
　g,输入特殊字符集，例如，NUL及\n等；
　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

　1,输入非法数据；
　2,输入默认值；
　3,输入特殊字符集；
　4,输入使缓冲区溢出的数据；
　5,输入相同的文件名；
命令按钮控件的测试

测试方法：

　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；
单选按钮控件的测试

测试方法：

　a,一组单选按钮不能同时选中，只能选中一个。
　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；
up－down控件文本框的测试

测试方法：

　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
　c,直接输入超边界值，系统应该提示重新输入；
　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
　e,输入字符。此时系统应提示输入有误。
组合列表框的测试

测试方法：

　a,条目内容正确，其详细条目内容可以根据需求说明确定；
　b,逐一执行列表框中每个条目的功能；
　c,检查能否向组合列表框输入数据；
复选框的测试

测试方法：

　a,多个复选框可以被同时选中；
　b,多个复选框可以被部分选中；
　c,多个复选框可以都不被选中；
　d,逐一执行每个复选框的功能；
列表框控件的测试

测试方法：

　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
　b,列表框的内容较多时要使用滚动条；
　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；
滚动条控件的测试

要注意一下几点：

　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
　c,单击滚动条；
　d,用滚轮控制滚动条；
　e,滚动条的上下按钮。
各种控件在窗体中混和使用时的测试

　a,控件间的相互作用；
　b,tab键的顺序，一般是从上到下，从左到右；
　c,热键的使用，逐一测试；
　d,enter键和esc键的使用；
在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
　案例演示:打开word中的"替换"对话框
　测试本功能有通过测试和失败测试两种情况
　通过测试:

　1,输入内容直接查找,或查找全部
　2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

失败测试:
　1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
　2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

替换测试大体相同.
　关于编辑操作窗口的功能测试的用例:
　1,关闭查找替换窗口.不执行任何操作,直接退出;
　2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
　3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
　4,热键, Tab键.回车键的使用.

插入操作
　1,插入文件
　测试的情况
　a,插入文件;
　b,插入图像;
　c,在文档中插入文档本身;
　d,移除插入的源文件;
　e,更换插入的源文件的内容;

2,链接文件
　测试方法:
　a,插入链接文件;
　b,在文档中链接文档本身;
　c,移除插入的源文件;
　d,更换插入的源文件的内容.

3,插入对象
　要测试的内容
　a,插入程序允许的对象,如,在word中插入excel工作表;
　b,修改所插入对象的内容.插入的对象仍能正确显示;
　c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

编辑操作
　编辑操作包括剪切,复制,粘贴操作.

测试剪切操作的方法
　a,对文本,文本框,图文框进行剪切;
　b,剪切图像
　c,文本图像混合剪切
　复制操作方法与剪切类似.

测试时,主要是对粘贴操作的测试,方法是:
　a,粘贴剪切的文本,文本框及图文框;
　b,粘贴所剪切的图像;
　c,剪切后,在不同的程序中粘贴
　d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
　e,利用粘贴操作强制输入程序所不允许输入的数据.

界面测试用例的设计方法
　1,窗体
　测试窗体的方法:
　a,窗体大小,大小要合适,控件布局合理;
　b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
　c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
　d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
　进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

2,控件
　测试方法:
　a,窗体或控件的字体和大小要一致;
　b,注意全角,半角混合
　c,无中英文混合.

菜单

进行测试时要注意
　a,选择菜单是否可以正常工作,并与实际执行内容一致;
　b,是否有错别字:
　c,快捷键是否重复;
　d,热键是否重复;
　e,快捷键与热键操作是否有效
　f,是否存在中英文混合
　g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
　h,鼠标右键快捷菜单

特殊属性
　1,安装界面应有公司介绍或产品介绍,有公司的图标
　2,主界面及大多数界面最好有公司图标
　3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息
实际中经常用到的几个用例

login
1、链接地址是否正确。
2、产生输入/输出错误时，系统是否进行检测并处理.
3、密码输入框是否按掩码的方式显示。

menu：
1、各模块链接地址是否正确。
2、鼠标无规则点击时是否会产生无法预料的结果。

browse:
1、浏览信息是否存在文字书写错误和语法错误。
2、浏览信息是否和数据库中对应的字段及信息相一致。
3、浏览页面中的链接按钮是否可以正确链接并显示。
4、其他功能按钮按下后，数据是否按既定规约处理。

add，modify：
1、产生输入/输出错误时，系统是否进行检测并处理。
2、列表框是否能够进行选择。
3、单选组内是否有且只有一个单选钮可选。
4、多选组内是否能够进行多数据项选择。
5、多项列表框是否能够进行多数据项选择。
6、控件是否存在默认输入值，若存在，默认值是否得到显示和提交.
7、Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理.
8、Submit之类的按钮按下后，数据是否得到提交或按既定规约处理。
9、其他页面按钮按下后，数据是否按既定规约处理。
10、异常信息表述是否正确。

search：
1、输入信息中是否存在和代码中的字符产生冲突的字符，系统是否进行检测并处理。
2、异常信息表述是否正确。
3、查询的结果是否正确。
4、列表框是否能够进行选择。
5、单选组内是否有且只有一个单选钮可选。
6、多选组内是否能够进行多数据项选择。
7、多项列表框是否能够进行多数据项选择。
8、 Submit之类的按钮按下后，数据是否得到提交或按既定规约处理。

Statistic：
1、产生的文件和数据表的计算结果是否正确。
2、图表结果数据显示是否正确。
3、浏览页面中的链接按钮是否可以正确链接并显示。
4、其他功能按钮按下后，数据是否按既定规约处理。
5、产生输入/输出错误时，系统是否进行检测并处理。
6、列表框是否能够进行选择。
7、单选组内是否有且只有一个单选钮可选。
8、多选组内是否能够进行多数据项选择。
9、多项列表框是否能够进行多数据项选择。

下面是LoadRunner三大组件中的Controller即压力产生器的部分可供分析的结果参数，一般可以在测试过程中可以进行粗略的观察，待测试结束后利用Analyse即分析器进行详细的分析。

Vusers（虚拟用户数）：

提供了生产负载的虚拟用户运行状态的相关信息，可以帮助我们了解负载生成的结果。

Rendezvous（负载过程中集合点下的虚拟用户）：

当设置集合点后会生成相关数据，反映了随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户的变化情况。

Errors（错误统计）：

通过错误信息可以了解错误产生的时间和错误类型，方便定位产生错误的原因。

Errors per Second（每秒错误）：

了解在每个时间点上错误产生的数目，数值越小越好。通过统计数据可以了解错误随负载的变化情况，定为何时系统在负载下开始不稳定甚至出错。

Average Transaction Response Time（平均事务响应时间）：

反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和用户负载生成图合并，就可以发现用户负载增加对系统事务响应时间的影响规律。

Transactions perSecond（每秒事务）：

TPS吞吐量，反映了系统在同一时间内能处理事务的最大能力，这个数据越高，说明系统处理能力越强。

Transactions Summary（事务概要说明）：

统计事物的Pass数和Fail数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务数越小说明系统越可靠。

Transaction performance Summary(事务性能概要)：

事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。柱状图的落差越小说明响应时间的波动小，如果落差很大，说明系统不够稳定。

Transaction Response Time Under Load（用户负载下事务响应时间）：

负载用户增长的过程中响应时间的变化情况，该图的线条越平稳，说明系统越稳定。

Transactions Response time(事务响应时间百分比)：

不同百分比下的事务响应时间范围，可以了解有多少比例的事物发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。

Transaction Response Time（各时间段上的事务数）：

每个时间段上的事务个数，响应时间较小的分类下的是事务越多越好。

Hits per Second（每秒点击）：

当前负载重对系统所产生的点击量记录，每一次点击相当于对服务器发出了一次请求，数据越大越好。

Throughput（吞吐量）：

系统负载下所使用的带宽，该数据越小说明系统的带宽依赖就越小，通过这个数据可以确定是不是网络出现了瓶颈。

HTTP Responses per Second（每秒HTTP响应）：

每秒服务器返回各种状态的数目，一般和每秒点击量相同。点击量是客户端发出的请求数，而HTTP响应数是服务器返回的响应数。如果服务器的响应数小于点击量，那么说明服务器无法应答超出负载的连接请求。

Connections per Second（每秒连接）：

统计终端的连接和新建的连接数，方便了解每秒对服务器产生连接的数量。同时连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止时，说明系统的连接池已满，通常这时候服务器会返回504错误。需要修改服务器的最大连接来解决该问题。

1.LoadRunner录制脚本时为什么不弹出IE浏览器?
　　当一台主机上安装多个浏览器时，LoadRunner录制脚本经常遇到不能打开浏览器的情况，可以用下面的方法来解决。

　　启动浏览器，打开Internet选项对话框，切换到高级标签，去掉“启用第三方浏览器扩展(需要重启动)”的勾选，然后再次运行VuGen即可解决问题

　　提示：通常安装Firefox等浏览器后，都会勾选上面得选项，导致不能正常录制。因此建议运行LoadRunner得主机上保持一个干净的测试环境。

　　2.录制Web脚本时，生成的脚本中存在乱码该如何解决?

　　录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced标签，先勾选“Support charset”，然后选择中支持UTF-8。再次录制，就不会出现中文乱码问题了。

　　3.HTML-based script与URL-based script的脚本有什么区别?

　　使用“HTML-based script”的模式录制脚本，VuGen为用户的每个HTML操作生成单独的步骤，这种脚本看上去比较直观;使用“URL-based script”模式录制脚本时，VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求，然后为用户的每个请求分别生成对应方法。

　　通常，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议，这时使用“URL-based script”模式进行录制。

　　4.为什么脚本中添加了检查方法Web-find，但是脚本回放时却没有执行?

　　由于检查点功能会耗费一定的资源，因此LoadRunner默认关闭了对文本及图像的检查。要想开启检查功能，必须修改运行时的配置Run-time Setting。

　　进入“Run-time Setting”对话框，依次进入“Internet Protocol→Preferences”，勾选Checks下的“Enable Image and text check”选项即可。

　　检查执行结果时推荐使用web_reg_find方法。

　　5.运行时的Pacing设置主要影响什么?

　　Pacing主要用来设置重复迭代脚本的间隔时间。共有三种方法：上次迭代结束后立刻开始、上次迭代结束后等待固定时间、按固定或随机的时间间隔开始执行新的迭代。

　　根据实际需要设置迭代即可。通常，没有时间间隔会产生更大的压力。

　　6.运行时设置Log标签中，如果没有勾选“Enable logging”，则手工消息可以发送吗?

　　Enable logging选项仅影响自动日志记录和通过lr_log_message发送的消息。即使没有勾选，虚拟用户脚本中如果使用lr_message、lr_output_message、lr_error_message,仍然会记录其发出的消息。

　　7.LoadRunner 8.0版本的VuGen在录制Web Services协议的脚本时一切正常，而回放时报出错误提示“Error：serverreturned an incorrectly formatted SOAP response”。这时说明原因引起的?

　　造成这种情况的主要原因是LoadRunner 8.0的VuGen在录制Web Service协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为，因此会有上面的错误提示。

　　解决方法：把“LR80WebservicesFPI_setup.exe”和“lrunner_web_sevices_path_1.exe”两个补丁打上即可解决。
　8.VuGen支持Netscape的客户证书吗?

　　不支持。目前的VuGen 8.0版本中仅支持Internet Explorer的客户端证书。录制脚本时可以先从Netscape中导出所需的证书，然后将其导入到Internet Explorer中，并确保以相同的顺序导出和导入这些证书。而且，在每台将要录制或运行需要证书的Web Vuser脚本的计算机上都要重复执行前面的过程。

　　9.VuGen会修改录制浏览器中的代理服务器设置吗?

　　会修改。在开始录制基于浏览器的Web Vuser脚本时，VuGen首先会启动指定的浏览器。然后，VuGen会指示浏览器访问VuGen代理服务器。为此，VuGen会修改录制浏览器上的代理服务器设置。默认情况下，VuGen会立即将代理服务器设置更改为Localhost:7777。录制之后，VuGen会将原始代理服务器设置还原到该录制浏览器中。因此，在VuGen进行录制的过程中，不可以更改代理服务器设置，否则将无法正常进行。

　　10.在LoadRunner脚本如何输出当前系统时间?

　　LoadRunner提供了char *ctime(const time_t *time)函数，调用参数为一个Long型的整数指针，用于存放返回时间的数值表示。

　　调用语句与返回值如下示例：

　　typedef long time_t;

　　Action()

　　{

　　time_t t;

　　lr_message(“Time in seconds since 1/1/70: %ld ”,time(&t));

　　lr_message(“System time and date: %s”,ctime(&t));

　　}

　　输出结果为：

　　Time in seconds since 1/1/70: 1185329968

　　System time and date:Wed Jul 25 10:19:28 2007

　　11.一些Web虚拟用户脚本录制后立刻回放没有任何问题，但是当设置迭代次数大于1时，如果进行回放则只能成功迭代一次。为什么从第二次迭代开始发生错误?

　　这种现象多是由于在“Run-time Setting”的“Browse Emulation”的设置中，勾选了“Simulate a new user on each iteration”及其下面的选项“Clear cache on each iteration”这两个选项的含义是每次迭代时模拟一个新的用户及每次迭代时清除缓存。

　　由于脚本迭代时，init和end只能执行一次，如果每次迭代都模拟一个新的用户并清除缓存，

则用户登录信息将一并清除，因此迭代时可能会发生错误。

　　12.虚拟客户脚本“Run-time Setting”中的线程和进程运行方式的区别?

　　如果选择“Run Vuser as a process”，则场景运行时会为每一个虚拟用户创建一个进程;选择“Run Vuser as a thread”则将每个虚拟用户作为一个线程来运行，在任务管理器中只看到一个mmdrv.exe，这种方式的运行效率更高，能造成更大的压力，时默认选项。

　　另外，如果启用了IP欺骗功能，则先在Controller中选中Tools菜单下的“Expert Mode”，然后将Tools菜单下的“Options>General”标签页中的IP地址分配方式也设置为与Vuser运行方式一致，同为线程或进程方式。

　　13.在Controller中运行Web相关测试场景时，经常会有很多超时错误提示，如何处理这类问题?

　　这主要有脚本的默认超时设置引起。当回放Web脚本时，有时候由于服务器响应时间较长，会产生超时的错误。这时需要修改脚本的运行时配置。

　　进入“Run-time Setting”对话框后，依次进入“Internet Protocol→Preference”。然后点击“Options…”按钮，进入高级设置对话框，可以修改各类超时设置的默认值。

　　14.为什么Windows系统中的CPU、内存等资源仍然充足，但是模拟的用户数量却上不去?

　　在Windows计算机的标准设置下，操作系统的默认限制只能使用几百个Vuser，这个限制与CPU或内存无关，主要是操作系统本身规定了默认的最大线程数所导致。要想突破Windows这个限制，须修改Windows注册表。以Windows XP Professional为例。

　　(1)打开注册表后，进入注册表项HKEY_LOCAL_MACHINE中的下列关键字：SystemCurrentControlSetControlSession ManagerSubSystems。

　　(2)找到Windows关键字，Windows关键字如下所示：

　　%SystemRoot%system32csrss.exe bjectDirectory=Windows

　　SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

　　ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

　　ProfileControl=Off MaxRequestThreads=16

　　SharedSection=1024,3072,512关键字的格式为xxxx,yyyy,zzz。其中，xxxx定义了系统范围堆的最大值(以KB为单位)，yyyy定义每个桌面堆得大小。

　　(3)将yyyy的设置从3072更改为8192(即8MB)，增加SharedSection参数值。

　　通过对注册表的更改，系统将允许运行更多的线程，

因而可以在计算机上运行更多的Vuser。这意味着能够模拟的最大并发用户数量将不受Windows操作系统的限制，而只受硬件和内部可伸缩性限制的约束。

 

 

功能性：

 

摘要：随着Internet的普及与迅速发展，企业业务量的迅速加大，数据大集中成为一种趋势，IT系统承载的负荷越来越重，系统性能的好坏严重的影响了企业对外提供的服务质量。从而对IT系统的性能进行测试和调优引起企业的重视，进而性能测试工程师成为IT市场的”香悖悖”，并且性能测试有着极高的技术挑战。于是吸引了大量的测试爱好者来学这方面的技术，而一谈到性能测试很多人便会想到鼎鼎大名的LoadRunner这款优秀的性能测试工具，然而到这里问题就产生了？

测试总结

 

1.摆正心态

一个好的测试工程师应具有”测试是为了破坏”的观点,捕获用户观点能力,强烈的质量追求,对细节的关注能力.应用的高风险区的判断能力以便将有限的测试针对重点环节。

 

2. 细致负责

任何BUG其实都是必现的，测试过程中要清楚自己的操作步骤，一旦问题出现，有很清晰的思路找到必现的规律。

接到测试任务不要马上盲目就开始进行测试工作,首先考虑所分配的模块中哪些做了改动，都关联到哪些模块,还有哪些边界的地方可能没有测试到, 再进行有目的,有预期结果性的测试,一旦发现BUG 能很快定位

在测试过程当中应将以前曾经遇到过的类似的错误从记忆深处挖掘出来,这一能力在测试过程中的价值是无法衡量的.因为许多新出现的问题和我们已经发现的问题相差无几.

 

3.  拓展测试思路，尝试各种不同操作

如找边界值：很多的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此,针对各种边界情况进行测试,可以查出更多的错误.

 

   软件测试需要模拟真实用户对软件进行操作和使用，从中查找出软件的缺陷。只有通过各种方式对软件全面测试，才能尽量避免漏测

 

查看论坛和TD中的BUG,查看过程中要注意的问题：

怎样的操作更容易出现问题

别人的测试思路与风格和自己有什么区别

 

4. 不厌其烦
工作要细心认真，具有责任感

善于学习、思考、发现、总结问题

具有耐心与恒心 

及时关注软件的改动情况

每出新版本首先要注意：该版本修改了哪些bug？增加了什么功能？需要着重验证修改bug模块及相关模块。

 

 

 

 

1.1 文本框、按钮等控件测试

1.1.1 文本框的测试

如何对文本框进行测试

　a,输入正常的字母或数字。
　b,输入已存在的文件的名称；
　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　d,输入默认值，空白，空格；
　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
　g,输入特殊字符集，例如，NUL及\n等；
　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

　1,输入非法数据；
　2,输入默认值；
　3,输入特殊字符集；
　4,输入使缓冲区溢出的数据；
　5,输入相同的文件名；

命令按钮控件的测试

测试方法：

　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

　a,一组单选按钮不能同时选中，只能选中一个。
　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
　c,直接输入超边界值，系统应该提示重新输入；
　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
　e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

　a,条目内容正确，其详细条目内容可以根据需求说明确定；
　b,逐一执行列表框中每个条目的功能；
　c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

　a,多个复选框可以被同时选中；
　b,多个复选框可以被部分选中；
　c,多个复选框可以都不被选中；
　d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
　b,列表框的内容较多时要使用滚动条；
　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意一下几点：

　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
　c,单击滚动条；
　d,用滚轮控制滚动条；
　e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

　a,控件间的相互作用；
　b,tab键的顺序，一般是从上到下，从左到右；
　c,热键的使用，逐一测试；
　d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
　案例演示:打开word中的"替换"对话框
查看(842) 评论(3) 收藏 分享 管理

http://www.bjpta.gov.cn/news_z.asp?news_id=705

一、报名时间
　　2009年3月5日至31日
　　台湾居民资格审核时间
　　2009年3月19日至20日
二、网上打印准考证时间
　　2009年5月19日至21日
三、考试时间
　　2009年5月23日

 

 

 

计算机系统基础知识
　　　1.1 计算机系统构成及硬件基础知识
　　　　●计算机系统的构成
　　　　●处理机
　　　　●基本输入输出设备
　　　　●存储系统
　　　1.2 操作系统基础知识
　　　　●操作系统的中断控制、进程管理、线程管理
　　　　●处理机管理、存储管理、设备管理、文件管理、作业管理
　　　　●网络操作系统和嵌入式操作系统基础知识
　　　　●操作系统的配置
　　　1.3 数据库基础知识
　　　　●数据库基本原理
　　　　●数据库管理系统的功能和特征
　　　　●数据库语言与编程
　　　1.4 中间件基础知识
　　　1.5 计算机网络基础知识
　　　　●网络分类、体系结构与网络协议
　　　　●常用网络设备
　　　　●Internet基础知识及其应用
　　　　●网络管理
　　　1.6 程序设计语言知识
　　　　●汇编、编译、解释系统的基础知识
　　　　●程序设计语言的基本成分（数据、运算、控制和传输、过程（函数）调用）
　　　　●面向对象程序设计
　　　　●C语言以及C++（或Java）语言程序设计基础知识
　　2．标准化基础知识
　　　　●标准化的概念（标准化的意义、标准化的发展、标准化机构）
　　　　●标准的层次（国际标准、国家标准、行业标准、企业标准）
　　　　●标准的类别及生命周期
　　3．信息安全知识
　　　　●信息安全基本概念
　　　　●计算机病毒及防范
　　　　●网络入侵手段及防范
　　　　●加密与解密机制
　　4．信息化基础知识
　　　　●信息化相关概念
　　　　●与知识产权相关的法律、法规
　　　　●信息网络系统、信息应用系统、信息资源系统基础知识
　　5．软件工程知识
　　　5.1 软件工程基础
　　　　●软件工程概念
　　　　●需求分析
　　　　●软件系统设计
　　　　●软件组件设计
　　　　●软件编码
　　　　●软件测试
　　　　●软件维护
　　　5.2 软件开发方法及过程
　　　　●结构化开发方法
　　　　●面向对象开发方法
　　　　●瀑布模型
　　　　●快速原型模型
　　　　●螺旋模型
　　　5.3 软件质量管理
　　　　●软件质量及软件质量管理概念
　　　　●软件质量管理体系
　　　　●软件质量管理的目标、内容、方法和技术
　　　5.4 软件过程管理
　　　　●软件过程管理概念
　　　　●软件过程改进
　　　　●软件能力成熟度模型
　　　5.5 软件配置管理
　　　　●软件配置管理的意义
　　　　●软件配置管理的过程、方法和技术
　　　5.6 软件开发风险基础知识
　　　　●风险管理
　　　　●风险防范及应对
　　　5.7 软件工程有关的标准
　　　　●软件工程术语
　　　　●计算机软件开发规范
　　　　●计算机软件产品开发文件编制指南
　　　　●计算机软件需求规范说明编制指南
　　　　●计算机软件测试文件编制规范
　　　　●计算机软件配置管理计划规范
　　　　●计算机软件质量保证计划规范
　　　　●数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定

6．软件测试知识
　　　6.1 软件测试基本概念
　　　　●软件质量与软件测试
　　　　●软件测试定义
　　　　●软件测试目的
　　　　●软件测试原则
　　　　●软件测试对象
　　　6.2 软件测试过程模型
　　　　●V模型
　　　　●W模型
　　　　●H模型
　　　　●测试模型的使用
　　　6.3 软件测试类型
　　　　●单元测试、集成测试、系统测试
　　　　●确认测试、验收测试
　　　　●开发方测试、用户测试、第三方测试
　　　　●动态测试、静态测试
　　　　●白盒测试、黑盒测试、灰盒测试
　　　6.4 软件问题分类
　　　　●软件错误
　　　　●软件缺陷
　　　　●软件故障
　　　　●软件失效
　　　6.5 测试标准
　　　　7.5.1 GB/T 16260.1—2003 软件工程 产品质量 第1部分：质量模型
　　　　7.5.2 GB/T 18905.1—2002 软件工程 产品评价 第1部分：概述
　　　　7.5.3 GB/T 18905.5—2002 软件工程 产品评价 第5部分：评价者用的过程

http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心，研究包括了度量、工具、风险等各个方面
http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载
http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process Office)主页，包括软件工程知识方面的资料
http://www.asq.org/ 是世界上最大的一个质量团体组织之一，有着比较丰富的论文资源，不过是收费的
http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面，属于个人网页，上面有些资源可供下载
http://www.benchmarkresources.com/ 提供有关标杆方面的资料，也有一些其它软件测试方面的资料
http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论，还提供测试方面的资料
http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织，主要从事通过切片技术、测试技术和转换技术来验证和分析系统，对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
http://www.cc.gatech.edu/aristotle/ Aristole研究组织，研究软件系统分析、测试和维护等方面的技术，在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容，该网站有丰富的论文资源可供下载
http://www.computer.org/ IEEE是世界上最悠久，也是在最大的计算机社会团体，它的电子图书馆拥有众多计算机方面的论文资料，是研究计算机方面的一个重要资源参考来源
http://www.cs.colostate.edu/testing/ 可靠性研究网站，有一些可靠性方面的论文资料
http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页，有比较丰富的资料下载，内容涵盖了测试的多个方面，包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心，提供有关软件可靠性研究方面的一些信息和资料，对这方面感兴趣的人可以参考
http://www.dcs.shef.ac.uk/research/groups/vt/ 学校里的一个验证和测试研究机构，有一些相关项目和论文可供参考
http://www.esi.es/en/main/ ESI（欧洲软件组织），提供包括CMM评估方面的各种服务
http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站，有可靠性方面的一些资料提供参考
http://www.fortest.org.uk/ 一个测试研究网站，研究包括了静态测试技术（如模型检查、理论证明）和动态测试（如测试自动化、特定缺陷的检查、测试有效性分析等）
http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站，有一些测试方面的课程和资料供下载
http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
http://www.io.com/~wazmo/ Bret Pettichord的主页，他的一个热点测试页面连接非常有价值，从中可以获得相当大的测试资料，很有价值
http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织，提供包括ISO标准系统方面的各类参考资料
http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载，对这方面感兴趣的读者可以参考该网站，肯定有价值
http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构，该机构提出了软件开发的全面验证和确认，在此可以获得这方面的研究资料
http://www.kaner.com/ 著名的测试专家Cem Kanner的主页，里面有许多关于测试的专题文章，相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆，在这里你可以获得有关计算机方面各类论文资料，内容极其庞大，是研究软件测试不可获取的资料来源之一
http://www.loadtester.com/ 一个性能测试方面的网站，提供有关性能测试、性能监控等方面的资源，包括论文、论坛以及一些相关链接
http://www.mareinig.ch/mt/index.html 关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载，包括了测试方面的内容
http://www.mtsu.ceu/-storm/ 软件测试在线资源，包括提供目前有哪些人在研究测试，测试工具列表连接，测试会议，测试新闻和讨论，软件测试文学（包括各种测试杂志，测试报告），各种测试研究组织等内容
http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站，每年都会举行两次
http://www.qacity.com/front.htm 测试工程师资源网站，包含各种测试技术及相关资料下载
http://www.qaforums.com/ 关于软件质量保证方面的一个论坛，需要注册
http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构，提供各种质量和测试方面证书认证
http://www.qualitytree.com/ 一个测试咨询提供商，有一些测试可供下载，有几篇关于缺陷管理方面的文章值得参考
http://www.rational.com/ IBM Rational的官方网站，可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具，比较全面
http://rexblackconsulting.com/Pages/publicat-ions.htm
Rex Black的个人主页，有一些测试和测试管理方面的资料可供下载
http://www.riceconsulting.com/ 一个测试咨询提供商，有一些测试资料可供下载，但不多
http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文，尤其在启发式测试策略方面值得参考
http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会，主要由测试专家Cem Kanar和James Bach组织，有一些值得下载的资料
http://www.sdmagazine.com/ 软件开发杂志，经常会有一些关于测试方面好的论文资料，同时还包括了项目和过程改进方面的课题，并且定期会有一些关于质量和测试方面的问题讨论
http://www.sei.cmu.edu/ 著名的软件工程组织，承担美国国防部众多软件工程研究项目，在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能，可以快速检索到你想要的论文资料，并且可以免费下载
http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接，包括：专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
http://www.soft.com/News/QTN-Online/ 质量技术时事，提供有关测试质量方面的一些时事介绍信息，对于关心测试和质量发展的人士来说是很有价值的
http://www.softwaredioxide.com/ 包括软件工程（CMM,CMMI,项目管理）软件测试等方面的资源
http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料，各质量/测试网站介绍，各质量/测试工具介绍，各质量/策划书籍介绍以及与测试相关的工作网站介绍
http://www.softwaretestinginstitute.com 一个软件测试机构，提供软件质量/测试方面的调查分析，测试计划模板，测试WWW的技术，如何获得测试证书的指导，测试方面书籍介绍，并且提供了一个测试论坛
http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站，提供咨询和培训服务，并有一些测试人员社团组织，特色内容是缺陷处理方面的技术
http://www.sqe.com/ 一个软件质量工程服务性网站，组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议，并提供一些相关信息资料和课程服务
http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料，论文等资源
http://www.stqemagazine.com/ 软件策划和质量工程杂志，经常有一些好的论文供下载，不过数量较少，更多地需要通过订购获得，内容还是很有价值的
http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站，有过程改进方面的一些资料提供
http://www.tcse.org/ IEEE的一个软件工程技术委员会，提供技术论文下载，并有一个功能强大的分类下载搜索功能，可以搜索到测试类型、测试管理、 测试分析等各方面资料
http://www.testing.com/ 测试技术专家Brain Marick的主页，包含了Marick 研究的一些资料和论文，该网页提供了测试模式方面的资料，值得研究。总之，如果对测试实践感兴趣，该网站一定不能错过
http://www.testingcenter.com/ 有一些测试方面的课程体系，有一些价值
http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站，感兴趣的人一定不能错过
http://www.testingstuff.com/ Kerry Zallar的个人主页，提供一些有关培训、工具、会议、论文方面的参考信息
http://www-sqi.cit.gu.edu.au/ 软件质量机构，有一些技术资料可以供下载，包括软件产品质量模型、再工程、软件质量改进等

缺乏版本控制测试易陷混乱风险

发布时间: 2009-3-04 13:19    作者: 未知    来源: 网络转载

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖

Web 测试的经验

发布时间: 2007-4-14 14:05    作者: 不详    来源: http://www.51testing.com

 

功能测试用例的书写方式

发布时间: 2007-4-14 14:00    作者: 不详    来源: 51cmm.com

功能性测试用例
1. 测试的来源，即测试的需求
测试用例的主要来源有：
1） 需求说明”及相关文档

Bug管理的一般流程

文章出处：本地化测试网 作者：崔启亮 发布时间：2006-03-08

 

     软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，

 

将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证

 

要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确

 

认、修复、验证等的管理过程，这是软件测试的重要环节。

 

错误跟踪管理系统

 

    为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录

 

输入制定的错误跟踪管理系统。

 

    目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、

 

Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能

 

上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes

 

或是ClearQuese开发缺陷跟踪管理软件。

 

    作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的

 

处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事

 

件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附

 

图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

 

正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误

 

不能从数据库中删除。

 

软件错误的状态

 

新信息(New)：测试中新报告的软件缺陷；

 

打开 (Open)：被确认并分配给相关开发人员处理；

 

修正(Fixed)：开发人员已完成修正，等待测试人员验证；

 

拒绝(Declined):拒绝修改缺陷；

 

延期(Deferred): 不在当前版本修复的错误，下一版修复

 

关闭(Closed)：错误已被修复；

 

Bug管理的一般流程

 

    测试人员提交新的Bug入库，错误状态为New。

 

    高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

 

    开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

 

    对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

 

    测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为

 

Closed，如没有解决置状态为Reopen。

 

软件错误流程管理要点

 

    为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

 

    每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。

 

    拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。

 

    错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

 

    加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。 

Bugzilla使用指南
文章出处：不详 作者：不详 发布时间：2005-10-30
	绪言 什么是Bugzilla Bugzilla是一个错误跟踪系统，用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面： 1.         强大的检索功能 2.         用户可配置的通过Email公布Bug变更 3.         历史变更记录 4.         通过跟踪和描述处理Bug 5.         附件管理 6.         完备的产品分类方案和细致的安全策略 7.         安全的审核机制 8.         强大的后端数据库支持 9.         Web，Xml，Email和控制界面 10.     友好的网络用户界面 11.     丰富多样的配置设定 12.     版本间向下兼容 为什么使用Bugzilla Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程，为开发和测试工作以及产品质量的度量提供数据支持，从而有效的保证软件产品的质量。   Bugzilla使用指南 新建一个Bugzilla账号 1.       点击“Open a new Bugzilla account”链接，输入你的Email地址（如：XXX@office）然后点击“Create Account”。 2.       稍候，你会收到一封邮件。邮件中包含你的登录账号（与你的Email相同）和口令，这个口令时Bugzilla系统随机生成的，你可以根据你的需要进行变更。 3.         在页面的黄色页角中点击“Log In”链接，而后输入你的账号和口令。最后点击“Login” 产品和结构（Product and Component） Bug记录按产品分类，每种产品按功能拆分成几类。以Bugzilla产品为例，它由以下几部分构成： l          Administration l          Bugzilla-General l          Creating/Changing Bug l          Documentation l          Email l          Installation l          Query/Buglist l          Reporting/Charting l          User Accounts l          Changing Passwords l          User Interface Bug报告状态分类和Bug处理意见（Status and Resolution）： 1.       Bug报告状态分类（Status） l          待确认的（Unconfirmed） l          新提交的（New） l          已分配的（Assigned） l          问题未解决的（Reopened） l          待返测的（Resolved） l          待归档的（Verified） l          已归档的（Closed） 2.       Bug处理意见（Resolution） l          已修改的（Fixed） l          不是问题（Nvalid） l          无法修改（Wontfix） l          以后版本解决（Later） l          保留（Remind） l          重复（Duplicate） l          无法重现（Worksforme） 指定处理人（Assigned To） l          可以指定一个处理人 l          如不指定处理人，则系统指定管理员为默认处理人 超链接（URL） l          输入超链接地址，引导处理人找到与报告相关联的信息 概述（Summary） l          概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。 l          如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。 硬件平台和操作系统（Platform and OS）(0perating System) l          测试应用的硬件平台（Platform），通常选择“PC” l          测试应用的操作系统平台（OS） 版本（Version） l          产生Bug的软件版本 Bug报告优先级（Priority） l          分五个等级即P1-P5，P1的优先级别最高之后逐级递减 Bug状态（Severity） l          Blocker，阻碍开发和/或测试工作 l          Critical，死机，丢失数据，内存溢出 l          Major，较大的功能缺陷 l          Normal，普通的功能缺陷 l          Minor，较轻的功能缺陷 l          Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等 l          Enhancement，建议或意见 报告人（Reporter） l          Bug报告提交者的账号 邮件抄送列表（CC List） l          Bug报告抄送对象，该项可以不填 l          如需要抄送多人，可将邮件地址用“，”分隔 从属关系（Bug “ID” 查看(646) 评论(0) 收藏 分享 管理 软件错误跟踪处理流程 2007-03-15 12:36:36     UML软件工程组织 火龙果软件工程技术中心 软件错误跟踪处理流程   作者：不详　　来源：网络   大型本地化软件测试需要进行充分的测试准备，需要科学的测试流程管理。为了跟踪和控制测试质量，便于管理测试发现的Bug，需要为每一个测试项目配置一个专用缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证错误。 为了保证发现和报告的错误质量，需要首先由经验丰富的测试人员，在缺陷跟踪数据库中对新发现的错误进行确认，如果确实属于错误，再由错误修复工程师进行修复处理。 1、软件错误的状态 新错误(New)：测试中新报告的软件缺陷。 更多新信息（New More Info）：错误修复工程师认为报告的错误信息不完整，要求错误报告者添加更准确的错误信息。 打开 (Open)：错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined)：拒绝修改缺陷。包括两种情况： 拒绝-不是错误（Declined-Not Bug）：报告的错误不术语错误。 拒绝-重复（Declined-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误标识编号。 修正(Fixed)：错误修复工程师已完成修正，等待测试人员验证。 重新打开（Reopen）：没有正确修复的错误，需要进一步修复。 延期(Deferred)：不在当前版本修复的错误，以后的版本修复。包括两种情况： 延期-下个版本（Deferred –Next Build）：本项目的下一个新版本修复。 延期-下个主要版本（Deferred –Next Main Release）：本项目不修复，本软件下一个项目的版本修复。 关闭(Closed)：错误已被修复。 　 　2、Bug管理的一般流程 测试人员提交新的错误入库，错误状态为New。 高级测试人员验证错误，如果是重复报告的错误，则设置为Declined-Duplicated状态，并指出与哪个已经报个错误重复（注明标识编号ID#）。否则，如果确认是错误，分配给相应的修复工程师，设置状态为Open。如果不是错误，则拒绝，设置为Declined-Not Bug状态。 错误修复工程师查询状态为Open的错误，如果因为错误的信息不完全，没法重现错误，则设置状态为New More Info；如果不是错误，则设置状态为Declined-Not Bug；如果是错误则修复，设置状态为Fixed。对于当前版本不能解决，准备本项目的下一个新版本处理的错误，要留下处理注释，设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决，要留下处理注释，设置错误为Deferred –Next Main Release状态。 对于不能解决和延期解决的错误，不能由软件修复工程师自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员查询状态为Fixed的错误，然后验证错误是否已修复，如果已经修复，设置错误的状态为Closed，如没有解决置状态为Reopen。 下面以一个错误的处理过程为例，给出一般的处理流程图。 　3、软件错误流程管理要点 为了保证错误的正确性，需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误，测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息，包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等。 对错误的拒绝不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定，应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。   版权所有：UML软件工程组织  UML软件工程组织 火龙果软件工程技术中心 软件错误跟踪处理流程   作者：不详　　来源：网络   大型本地化软件测试需要进行充分的测试准备，需要科学的测试流程管理。为了跟踪和控制测试质量，便于管理测试发现的Bug，需要为每一个测试项目配置一个专用缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证错误。 为了保证发现和报告的错误质量，需要首先由经验丰富的测试人员，在缺陷跟踪数据库中对新发现的错误进行确认，如果确实属于错误，再由错误修复工程师进行修复处理。 1、软件错误的状态 新错误(New)：测试中新报告的软件缺陷。 更多新信息（New More Info）：错误修复工程师认为报告的错误信息不完整，要求错误报告者添加更准确的错误信息。 打开 (Open)：错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined)：拒绝修改缺陷。包括两种情况： 拒绝-不是错误（Declined-Not Bug）：报告的错误不术语错误。 拒绝-重复（Declined-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误标识编号。 修正(Fixed)：错误修复工程师已完成修正，等待测试人员验证。 重新打开（Reopen）：没有正确修复的错误，需要进一步修复。 延期(Deferred)：不在当前版本修复的错误，以后的版本修复。包括两种情况： 延期-下个版本（Deferred –Next Build）：本项目的下一个新版本修复。 延期-下个主要版本（Deferred –Next Main Release）：本项目不修复，本软件下一个项目的版本修复。 关闭(Closed)：错误已被修复。 　 　2、Bug管理的一般流程 测试人员提交新的错误入库，错误状态为New。 高级测试人员验证错误，如果是重复报告的错误，则设置为Declined-Duplicated状态，并指出与哪个已经报个错误重复（注明标识编号ID#）。否则，如果确认是错误，分配给相应的修复工程师，设置状态为Open。如果不是错误，则拒绝，设置为Declined-Not Bug状态。 错误修复工程师查询状态为Open的错误，如果因为错误的信息不完全，没法重现错误，则设置状态为New More Info；如果不是错误，则设置状态为Declined-Not Bug；如果是错误则修复，设置状态为Fixed。对于当前版本不能解决，准备本项目的下一个新版本处理的错误，要留下处理注释，设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决，要留下处理注释，设置错误为Deferred –Next Main Release状态。 对于不能解决和延期解决的错误，不能由软件修复工程师自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员查询状态为Fixed的错误，然后验证错误是否已修复，如果已经修复，设置错误的状态为Closed，如没有解决置状态为Reopen。 下面以一个错误的处理过程为例，给出一般的处理流程图。 　3、软件错误流程管理要点 为了保证错误的正确性，需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误，测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息，包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等。 对错误的拒绝不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定，应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。   版权所有：UML软件工程组织 查看(547) 评论(2) 收藏 分享 管理 251/212> lixl99999 用户菜单 给我留言 加入好友 发短消息 我的介绍 论坛资料 空间管理 我的栏目 自我激励 心情 性能测试 转载 情感世界 求职面试 软件测试 标题搜索 我的存档 2012年07月 2012年06月 2012年05月 2012年04月 2012年03月 2012年02月 2012年01月 2011年12月 2011年11月 2011年10月 2011年09月 2011年08月 2011年07月 2011年06月 2011年05月 2011年04月 2011年03月 2011年02月 2011年01月 2010年12月 2010年11月 2010年10月 2010年09月 2010年08月 数据统计 访问量: 156802 日志数: 34 建立时间: 2006-12-28 更新时间: 2012-07-09 RSS订阅 清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间 Powered by 51Testing © 2003-2021 沪ICP备05003035号 Open Toolbar