软件测试状态设置

❶ 为什么说软件测试的初始状态很重要

程序在初始运行时，需要设定一个初始状态，以便能够运行。这也是测试时需要测试的。如果初始改肆情况就出现问题，以后的运行都是宽盯在错误的基础上的，测试结果不可信。故需要在设计和开发，乃至测试时，对初始状态均需要重点核巧轿对待。

❷ 软件测试的方法有哪些

测试的有2种方法

答：黑盒测试和白盒测试

黑盒：这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

黑盒测试又叫做功能测试或数据驱动测试。

白盒：此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及皮历有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通过在漏戚不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

软件测试按过程分为三个步骤

答：单元测试：单元测试又称模块测试，是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段

系统测试：当应用作为整体运行时的测试执行阶段

软件测试的步骤是什么？

1)测试过程按4个步骤进行，即单元测试（UnitTesting）、集成测试（IntegratedTesting）、确认测试（ValidationTesting）和系统测试（SystemTesting）及发版测试。

2)开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

3)集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。

4)确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

应该考虑进行如何测试的测试方法

黑盒测试(Blackboxtesting)——不考虑内部设计和代码，根据需求和功能进行测试。

白盒测试(Whiteboxtesting)——根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。

功能测试（functionaltesting）——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试燃搜搜人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）

系统测试——针对全部需求说明进行黑盒测试，包括系统中所有的部件。

回归测试(regressiontesting)——每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。

负荷试验(loadtesting)——在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。

压力测试(stresstesting)——经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。

性能测试(performancetesting)——经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试)都应在质量保障和测试计划的文档终予以规定。

可用性测试(usabilitytesting)——是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

安装/卸载测试(install/uninstalltesting)——对安装/卸载进行测试(包括全部、部分、升级操作)。

安全测试(securitytesting)——测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。

兼容性测试(compatabilitytesting)——测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。

α测试(alphatesting)——在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

β测试(betatesting)——当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

❸ 手机软件测试有哪些方法常用的手机软件测试方法

一、等价类分析法

等价类划分方法针对手机状态大致可以归几个大类：

1.按键类（等价法）：有效输入和无效输入（有效输入指UM和菜单指示；无效输入指测试菜单功能此时没有定义的按键和用户动作）；

2.外部中断类（等价法）：常用、不常用及无效

2.1.常用：来电和来消息（短信、彩让做信、push消息）；掀合盖；侧键；耳机＆FM；情景模式；电量不足

2.2.不常用：充电；闹钟＆记事本＆关机时间＆整点报时提示；Icon＆动画显示；Icon＆动画刷新；编辑界面＆pop显示框输入为空或满；坦拆衡编辑界面＆pop显示框状态输入法默认＆字符编码默认；失效SIM卡；大容量等SIM卡兼容；排序；号码识别御侍；

二、边界值分析

例子1：

短消息发送功能的等价类划分方法:.

三、错误猜测法

例子1：

利用手机闹钟重响的例子引入错误猜测法基本概念，讲解错误猜测法的意义

未接来电29通，内存中规划的分区一直分配被占用。即使同一号码也同样占用资源。假设此时第30通电话正好为来电号码不显示，即“来电号码未知”或境外来电号码隐藏时（国外保护个人隐私，自动开启来电号码隐藏功能），可能会出现BUG，实际情况证明，此时会出现Reset问题。

❹ 软件测试——缺陷报告

         测试人员发现缺陷——>记录缺陷，并将缺陷告知开发人员

         缺陷报告是测试人员和开发人员沟通的重要渠道

         1、缺陷编号（defect id）

         2、缺陷标题（summary）

         3、缺陷的发现者（detected by）

         4、发现缺陷的日期（detected on date）

         5、发现缺陷的功能模块（subject）

         6、指派给（assigned to）

         7、发现缺陷的版本（detected in release）

              （1）说明：不仅指最后的发布版本，也指软件开发过程中出现的“临时版本”

              （2）回归测试：在新版本中对原来版本测试过的内容再重新测试一遍

                        原因：1、新功能对原有功能可能有影响

                                   2、缺陷修改后也有可能对原有功能产生影响

                        为了提高回归测试的效率，很多企业使用自动化工具做回归测试

         8、缺陷的状态（status）最常见的考试题**

              （1）说明：指明缺陷当前所需什么处理困派和缺陷当前处于什么处理状况

              （2）缺陷的处理过程：重点

                      步骤1：测试人员将缺陷报告提交给开发经理，

                                   将缺陷报告状态设置成：New（新的缺陷）

                      步骤2：开发经理验证缺陷：

                                   情况1：如果验证是缺陷，将缺陷指派给相应的开发人员，

                                               并将缺陷状态设置成open

                                                open：（打开的缺陷，被开发方汪滚贺承认的缺陷）

                                   情况2：如果验证不是缺陷，开发经理会拒绝此缺陷，将缺陷

                                                状态设置成：rejected。（一般要汇报给测试组长或

                                                测试经理，有时会邀请开发人员参加，开讨论会解决）

                     步骤3：开发人员要修改缺陷，修改完成后，将缺陷状态设置成：fixed

                                  fixed:（修改过的缺陷，即待返测的缺陷）

                     步骤4：测试人员返测开发人员更改过的缺陷

                                情况1：返测通过，将缺陷状态设置成：closed

                                             closed:（关闭的缺陷，可归档）

                                 情况2：返测没通过，将缺陷状态设置成：reopen

                                              reopen:（重新打开的缺陷）

                                              开发人员继续修改缺陷直到缺陷被返测成功为止。

         9、缺陷的严重程度（severity） 【说明缺陷有多糟糕或者对软件的影响有多大】

               严重程度的级别：

                     （1）urgent：造成死机，系统崩溃等致命问题

                     （2）very high：非常严重的问题

                     （3）high：严重的问题

                     （4）medium：中等程度的问题

                     （5）low：小问题

               发现问题：级别定义是泛泛的笼统的，容易引发争议，需要制定详细的标准

               注意：每个级别的含义，不同企业、不同项目组都可能不同，需要在专门的

                          文档中定义好细则，在缺陷报告中作为参考。

         10、缺陷的优先级（priority）

                希望程序员在什么时间内或者在程序的哪个版本中解决该缺陷（Bug）

                优先备颂级的级别：

                      （1）urgent：立即修改，否则会影响开发或测试的进度

                      （2）very high：本版本中解决

                      （3）high： 下一版本中解决

                      （4）medium：发布之前解决

                      （5）low：尽量在发布之前解决

                 注意：对于每个级别的具体定义，不同公司不一定完全相同，

                            实际工作中要注意参考公司的文档。

                 影响优先级的因素：

                       （1）考虑缺陷的严重程度：一般是越严重，优先级别越高

                             （也不是绝对的，有时严重级别低，但优先级高，例如：界面错字）

                       （2）缺陷影响的范围：一般影响范围越大，优先级越高

                       （3）开发组的任务压力：进度压力越小，优先级越高

                       （4）解决缺陷的成本(时间)：成本越低，优先级越高 （例如:改错字）

         11、缺陷的描述（description）

                 描述缺陷产生的操作过程，使程序员能重现缺陷。（缺陷报告不是必须

                 要遵守什么写法和规则，只要程序员能看明白能重现缺陷就可以）

         1、缺陷报告的用途

             （1）记录缺陷（2）跟踪管理缺陷

             （3）可以对缺陷进行分类，并很容易实现对缺陷的总结，统计

         2、怎样识别缺陷？

             （1）参考测试用例的预期结果，如果实际执行结果与预期结果不一致就是缺陷

             （2）参考需求文档-----与需求不符就是bug

             （3）参考缺陷定义的五条

             （4）与开发人员、产品人员、客户沟通确定是否是缺陷

        3、写缺陷报告的注意事项

            （1）一个报告只提交一个缺陷

            （2）缺陷描述清晰、准确、易读，使用最少、必须的步骤，保证缺陷可以再现

            （3）对缺陷的严重性、优先级的划分准确、客观

            （4）在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，

                     而不是因为自己的疏忽或操作不正确早成的“假缺陷”

            （5）不要为了引起开发人员的重视而夸大缺陷

            （6）小的缺陷也要报告

            （7）及时报告缺陷

            （8）对于不可重现的缺陷也要报告

            （9）不做任何评价

         1、什么是随机缺陷：

              不可重现的缺陷也叫随机缺陷，按照指定的步骤执行时有时无。

              随机缺陷在提交时要明确说明这是不可重现的随机缺陷。

              尽量提供关于此缺陷的信息，包括提供截图、错误消息、还有缺陷所在模块

              如果确定不了所在模块，可以建议采用白盒测试确定。

         2、缺陷的严重程度和优先级是不是严格的正比关系？

               答：不一定严格成正比关系。

                       例如：界面错别字，严重级别低，但优先级别高

         3、缺陷的严重程度和优先级确定之后，还可以改吗？

                答：严重程度一般不改；优先级有时会改，一般是拖延处理

         4、是不是所有已发现的缺陷，在发布时都会被修复？

               答：在软件发布之前，不是所有已经发现的缺陷都被修复了；对于

                      不予修复的缺陷，要通过全组的缺陷讨论，权衡解决缺陷的

                      成本和不解决的风险。后期一般通过打补丁或升级的方式解决。

❺ 软件测试的步骤

软件测试的步骤如下：

1、根据项目、产品的需求提炼测试需求。

2、根据测试需求和项目的整体计划，制定测试计划，测试方案等，包括测试的时间节点安排，人力资源安排，测试策略等，并进行评审。

3、根据测试需求以及相关的设计文档，编写测试用例，即明确每个测试点的具体的操作步骤，预期结果等内容，并对用例进行评审。

4、准备测试环境和测试数据，包括测试系统部署的硬件环境和软件环境。

拓展知识：

增强软件使用可靠性纤指御，发现软件存在的不足和差异，提高软件质量。简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。

❻ 在学习软件测试，请帮忙描述一下下面图中的BUG状态流程图。

这个是一个标准的测试缺陷管理流程图：
测试人员【报告错误】--在缺陷管理平台上新建了一个BUG，测试bug状态是【new】,研发人员收到BUG之后，（1）先确认BUG是否【已经报告？】，如果该BUG已经提交过，研发人员会将BUG打回，并提示重复BUG，此时的BUG状态是【Declined Duplicated】，测试人员检查BUG确实重复提交了，关闭该缺陷；（2）如果该BUG无重复提交，研发人员确认是否【是错误？】，如果是设计本就如此，研发会人为该BUG不是错误，将BUG打回，状态是【Declined Not Bug】，测试人员检查后关闭该缺陷；（3）如果该BUG研发确认是错误，研发会打开BUG进行修复，此时BUG状态是【open】;（4）open的BUG修复，研发会检查按照测试步骤是否【可以团稿重现？】，如果无法重现，研发将BUG打回，需要研发人员补充信息，测试状态是【new more info】,测试人员补充BUG信息后，再提交到研发进行修复，直到研发能够复现出该BUG；（5）如果测试步骤可以复现BUG，研发人员可以决定是否【现在修复？】，如果是立即修复，研发会将修改好的BUG设置为已解决，BUG修改后的状态是【fixed】，测试拿到已解决的BUG进行验证，确认是否【通过验证？】，如果验证通过，关闭该BUG，如果验证不通过，重新打开该BUG；（6）如果研发人员决定不立即修复，研发人员决定是否【下版本修复？】，如果是，那么将会在搜蔽下个版本进行修复，状态是【Deferred next build】，如果不是下个版本修复，那么会在下次的主线版本中进行修复，状态是【Deferred next main release】，这2个缺陷的状态都将是挂起，到期研发会自己世或州打开进行修复，修复的处理流程又跟之前的正常流程是一样的了。

❼ 软件测试种测试结果的五种状态

为了保证测试工作科学、精确、全面、有序地进行，应该采取一边开发一边进行软件测试的策略，使得开发工作与测试工作平行进行，这也就是俗话所说的“越早测试越好”的概念。
一套完整的软件测试应该由五个阶段组成：
1、测试计划
首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2、测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
3、测试开发
建立可重复使用的自动测试过程。
4、测试执行
执行测试开发阶段建立的自动测试过程，并对所发现的缺陷盯颂进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5、测试评估
结合量化的测试覆盖域及缺陷唯或跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
显然，软件测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量凯山郑的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。

❽ 软件测试的五个基本原则

软件测试经过了几十年的发展，已经提出了许多基本的测试原则来指导软件测试。制定软件测试的基本原则有助于提高测试工作的效率和质量，使测试人员能够以最少的人力、物力和时间尽快发现软件中的问题。测试人员应在测试原则的指导下开展测试工作。下面是软件测试的五个基本原则。

1.测试应该基于客户需求

所有测试工作都应基于满足客户的要求上，从客户的角度来看，最严掘如重的错误是软件不能满足要求。有时候软件产品的测试结果是完美的，但并不是客户最终想要的产品，所以软件产品的开发是失败的，测试工作没有意义。因此，测试应该根据客户的需求配置环境，并根据客户的使用习惯对结果进行测试和评估。

2.应该尽快进行测试

软件错误存在于软件生命周期的各个阶段，所以测试要尽早进行，软件测试要贯穿软件生命周期的各个阶段，这样测试人员才能尽早发现和预防错误，降低错误修复的成本。尽早进行测试将有助于测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定完善的计划和方案，提高测试效率。

3.详尽的测试是不可能的

由于时间和资源的限制，不可能完全测试(各种输入输出的所有组合)。测试人员可以根据测试的风险和优先级来确定测试的重点，从而控制测试的工作量，在测试成本、风险和收益之间取得平衡。

4.遵循足够好原则

足够好原则是指测试的投入和产出要适当权衡，形成一个充分的质量评价过程，这个过程是以测试成本为基础的。测试不足不能保证软件产品的质量，但是过度的测试投入会造成资源的浪费。随着测试资源的增加，测试产出也随之增加，但当投入达到一定比例后，测试效果并不会明显增强。因此，测试的投入要根据实际需求和产品质量来考虑，最好能让测试的投入和产出达到一个足够好的状态。

5.测试缺陷应符合二八定理

缺陷的二八定理也叫帕累托原理和缺陷聚类效应。一般80%的软件缺陷集中在20%的模块中樱散春，缺陷分布不均匀。所以在测试的时候，要抓住主要矛盾。如果我们发现某些模块比其他模块有更多的缺陷，我们应该投入更多的人力和精力来脊耐测试这些模块，以提高测试效率。

❾ 软件测试是什么

问题一：什么是软件测试？ 软件测试定义是：为了发现程序中的错误而执行程序的过程
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(pleteness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。
软件测试的目标：
(1)测试是为了发现程序中的错误而执行程序的过程；
(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
(3)成功的测试是发现了至今为止尚未发现的错误的测试。
软件测试的内容：
软件测试主要工作内容是验证(verification)和确认( validation )，下面分别给出其概念：
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程；
2.程序正确性的形式证明，即采用形式理论证明程序符号设一计规约规定的过程；
3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)
1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性；
2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
从不同的角度出发，软弯如件测试可以划分为不同的分类：
从是否关心软件内部结构和具体实现的角度划分
A.白盒测试
B.黑盒测试
C.灰盒测试
从是否执行程序的角度
A.静态测试
B.动态测试。
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.验收测试
E.系统测试

问题二：软件测试主要做什么工作? 顾名思义，主要工作就是测试软件，但是测试前的测试需求、编写测试计划、编写测试用例，测试后的编写测试总结报态闹拿告等，也是必须要做的。
测试软件又为手动测试和自动测试，自动测试指用测试工具对软件进行测试。
最后，软件测试的定义是为了找出软件中的bug而运行软件的过程；
说了这些，你明白了吧。

问题三：软件测试这个行业一般做什么？ 以下是软件测试工程师的日常工作：
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事件。

问题四：软件测试的重要性是什么? 保证软件的质量

问题五：什么是软件测试? 简单的说他是软件生产过程中的质量管理者，其不但要对软件产品最后的功能、性能负责，而且从软件的“需求分析”、“结构设计”阶段以及文档规范等诸多方面就开始对软件的质量加以保障，使生产出来的软件的功能达到设计之初的要求，让用户用上高质量的软件。可见软件测试工程师的重要性了，随着我国加入WTO及国内软件企业的日益成熟和壮大，软件测试工程师在业界的地位已经变得越来越重要。

问题六：软件测试的目的是什么 现在很多人都发现了软件测试这个前景待遇都很不错的行业，那么究竟有人多人知道自己每天工作的目的是什么呢？作为一个软件测试员，自己又怎样的价值，自己做的工作为公司甚至为社会会带来怎样的影响和效果呢？这样的问题你有没有认真的思考过呢？从主观的角度上这个问题是很难回答的，所以我们现在列举一下我们经常听到的对这个问题的回答。

软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。
，这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的组织用发现的bug数来衡量测试人员的业绩，其实这就是这种测试目的论在后面作祟，其结果如何呢：其一，有一些不够敬业的测试人员会找来一些无关痛痒的bug来充数，结果许多时间会被浪费在这些无关痛痒的bug上(其实应该修复，何时修复，严重程度是什么，优先级是什么，等等);其二，测试人员会花很大力气设计一些复杂的测试用例去发现一些迄今尚未发现的缺陷，而不关心这些缺陷是否在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的，为什么这么说呢?因为软件里bug的数量是无从估计的，那么如果测试的目的是为了找bug
，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作(因为有些bug在实际的运行过程当中根本不会发生)。

测试的目的就是为了保证软件质量
，这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括：
Understandability、Conciseness、Portability、Consistency、Maintainability、Testability、Usability、Structures、Efficiency、Security等等，所以，软件质量保证和测试其实关注的方向是不同的。
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
所以，简言之，测试的目的应该是验证需求，
bug(预期结果与实际结果之间的差别)是这个过程中的产品而非目标。测试人员应该象工兵一样，在大部队(客户)预期前进的方向上探雷、扫雷(bug)
，而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求(测试工作量)

问题七：软件测试是什么以及目的 软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，这是软件生存期的另一个独立阶段，即测试阶段。软件测试的目的软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。

问题八：软件测试的工作流程是什么？？ 软件测试的测试流程有1、制定测试计划2、编辑测试用例3、执行测试用例4、发现并提交BUG
5、开发组修正BUG6、对已修正BUG进行返测7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活，参考什么是软件测试和软件测试原则note.you/...e=note

问题九：什么是软件测试 软件测试（英语：software testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
它的目的就只有一个，通过在系统上线前通过技术手段，尽可能找到软件在不同维度上存在的缺陷，使开发团队进行修改，以期在上线后，尽可能少的存在缺陷，提升软件、项目的质量。
注：保证质量的手段有很多，而软件测试是其中重要的手段之一。

问题十：软件测试是做什么的？ 软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。
使用人工或者自动手段来运行或测试某个供统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(pleteness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。
Grenford J.Myers曾对软件测试的目的提出过以下观点: (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。
然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!
(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者 发现当前软件开发过程中的缺陷,以便及时改进；
(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；
(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法 软件测试完整分类，参见：软件测试的完整分类
以上的都是官话！其实说白了，软件测试就是在开发人员做出软件投放市场前，尽可能早的找出软件当中所存在的BUG！因为任何软件在理论上来说都是存在问题的，都不是完美的！尽早的找出漏洞，公司的损失也就越低！这也就是软件测试人员越来越受重视的原因！
其实软件测试是一种相当乏味枯燥的工作，一般面公司都比较偏向稍微内向的人，另外测试人员还要具备相当的口才，方便与开发人员还有客户交流！