一般测试流程：
1.需求分析阶段：只要就是对业务的学习，分析需求点。
2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。
4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。
5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
最佳答案
阶段：编写测试计划，测试用例、测试缺陷报告，并执行测试用例，搭建Windows测试环境，熟练使用Bugzilla提交软件缺陷报告
至于为什么嘛，当然要一步步来的，要有计划才能执行啊，大概是这样吧 ^_^
使用测试技术及工具：白盒测试和黑盒测试 Loadrunner、Winrunner
能够运用边界值、等价类划分法、因果图、状态图、大纲法等测试方法设计高效测试用例
软件测试工作总体流程图：
stage/Studio/Tech/200601/143.htm
详细测试步骤：
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事件。
对我有帮助
8
回答时间：2008-12-28 14:10 | 我来评论
    从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷；从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求。软件测试的原则尚没有标准的说法，大多只是经验之谈，以下可以作为测试的基本原则。
  (1)所有的测试都应追溯到用户需求。 
  软件测试的目标在于揭示错误。从用户角度来看，最严重的错误是那些导致程序无法满足需求的错误。 
  (2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。 
  应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。 
  (3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。 
  当某个功能出问题，其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能(优先级高)的测试会得到完全执行，而低优先级的测试(另外用户不经常用的80%功能)就不是必要的，如果时间或经费不够，就暂时不做或少做。 
  (4)完全测试是不可能的，测试需要终止。 
  测试无法显示软件潜在的缺陷，“测试只能证明软件存在错误而不能证明软件没有错误”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻错误，最后在整个系统中寻错误。在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。 
  (5)应由独立的第三方来构造测试。 
  第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，由于第三方测试机构独立公正的地位，可以对被测试的软件有一个客观公正的评价，帮助用户选择合适、优秀的软件产品。 
  (6)充分注意测试中的集现象。 
  测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。不要在某个程序段中到几个错误就误认为该程序段就没有错误而不再测试，相反应该对错误集的程序段进行重点测试。 
  (7)尽量避免测试的随意性。 
  测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。 
  (8)兼顾合理的输入和不合理的输入数据。 
  (9)程序修改后要回归测试 
  修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 
  (10)应长期保留测试用例，直至系统废弃。 
  妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护等提供方便。
resolved是什么状态
Copyright © beyondtest
本地化测试具有软件测试的一般特征， 而其特有的特征如以下几点：
  （1）本地化测试对语言的要求较高
  不仅要准确理解英文（测试的全部文档，例如测试计划、测试用例、测试管理文档、工作邮件都是英文的），还要使用本地化母语人员进行本地化测试，例如测试简体中文的本地化产品，我们中国大陆人完全胜任。而测试德语本地化软件，需要母语是德语的测试人员才能满足要求。
  （2）本地化测试以手工测试为主，但是经常使用许多定制的专用测试程序
  手工测试是本地化测试的主要方法，为了提高效率，满足特定测试需要，经常使用各种专门的测试工具。一般这些测试工具都是开发英文软件的公司开发人员或测试开发人员开发的。
  （3）本地化测试通常采用外包测试进行
  为了降低成本，保证测试质量，国外大的软件开发公司都把本地化的产品外包给各个不同的专业本地化服务公司，软件公司负责提供测试技术指导和测试进度管理。
  （4）本地化测试的缺陷具有规律性特征
  本地化缺陷主要包括语言质量缺陷、用户界面布局缺陷、本地化功能缺陷等，这些缺陷具有比较明显的特征，采用规范的测试流程，可以发现绝大多数缺陷。
  （5）本地化测试特别强调交流和沟通
  由于实行外包测试，本地化测试公司要经常与位于国外的软件开发公司进行有效交流，以便使测试按照计划和质量完成。有些项目需要每天与客户交流，发送进度报告。更多的是每周报告进度，进行电话会议，等交流。此外，本地化测试公司内部的测试团队成员也经常交流彼此的进度和问题。
  （6）本地化测试属于发展比较迅速的专业测试
  由于中国属于较大的软件消费市场，国外大的软件公司为了在中国获得更多的软件销售利润，越来越多的软件都要进行中文本地化。另一方面，中国成为新兴的软件外包服务提供国，国外公司逐渐把软件外包测试放在中国进行。这样，本地化测试就不断发展起来，目前中国很多大型本地化服务公司的本地化测试业务都呈现稳定增长的态势。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。