学步园

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个通过分析软件和需求之间的差异，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

问题二：什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

问题三：如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü  对于该项目的用途而言，哪种功能最重要?

ü  哪种功能对用户最明显?

ü  哪种功能对安全影响最大?

ü  哪种功能对用户最有用?

ü  对客户来说，该应用软件的哪个部分最重要?

ü  在开发过程中，该应用软件的哪个部分可以最先测试?

ü 哪一部分代码最复杂，容易导致出现错误?

ü 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü 哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü 需求和设计的那些部分不清楚或不容易读?

ü 开发人员认为在应用软件中哪些部分是高风险的?

ü 哪些问题能造成最差的发行?

ü 哪些问题最能引起用户抱怨?

ü 哪些测试可以容易地覆盖多种功能?

ü 哪些测试在覆盖高风险部分的测试时使用时间最少?

问题四：如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü 好的代码注释和好的文档有助于开发人员作出相应的改变。

ü只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü在项目的时间表中应当留出余量，以应付可能出现的变更。

ü尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变更进行适当的风险分析，以减少回归测试的要求。

ü在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing)上。

测试的几个原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
5. 充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

关于bug

测试的原则---Good Enough

　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

测试的规律----木桶原理和80-20原则

（1）木桶原理

　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

（2）Bug的80-20原则。

　　实践证明。80%的bug往往隐含在20%的软件区域。所以一旦在某处发现了bug，多找找周围。这也是有经验的测试员的一种方式。

   一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

1、为什么要在一个团队中开展软件测试工作？
    因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
2、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
    我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试
3、您所熟悉的软件测试类型都有哪些？
    测试类型有：功能测试，性能测试，界面测试。
4、请试着分别比较不同的测试类型的区别与联系（如功能测试、性能测试……）
    功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
    界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
    区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。

黑盒测试的测试用例设计方法

·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法
·正交实验设计方法
·功能图分析方法

等价类划分方法

含义：
在很多时候，某些数据输入后得到的输出结果是相同或者相似的，而与其他一些数据输入后的到的结果不相近，从而我们可以把输入数据划分成若干个集合，称之为有效等价类。从每一个集合中选取代表性的数据作为测试用例使用数据，从而减少了输入数据量提高了效率。
划分的等价类集合可以分为有效等价类和无效等价类。有效等价类就是将有效的符合逻辑的正确数据进行划分。无效等价类反之。

划分集合的方法有：
1）在限定取值范围或个数时，可以划分一个有效等价类和两个无效等价类；
2）在规定了输入值集合或必须是“XX类型”时，可以划分一个有效等价类和一个无效等价类；
3）在输入值为布尔类型时，可以划分一个有效等价类和一个无效等价类；
4）在输入一组（n个）值且伴有判断情况（m种）时，可划分n或m个有效等价类和一个无效等价类；
5）在输入规定正则表达式时，可以划分一个有效等价类和若干个无效等价类；

设计测试用例：
为每个等价类规定一个唯一的编号；
设计一个新的测试用例，尽最大可能引入未被引入的有效等价类。反复建立新用例，直到所有等价类被使用。
设计一个新的测试用例，仅仅引入一个未被引入的无效等价类。反复建立新用例，直到所有等价类被使用。

边界值分析方法

含义：
边界值分析方法是等价类划分方法的有力补充。由于在后者输入中，我们选择的是一些代表性的数据而不是全部数据进行输入，所以难免会有些会引起错误的特殊数据未被选择。由于这类数据往往集中在各个划分好的等价类的边界值附近，所以称之为边界值分析法。而且，在这种方法中，不单要考虑输入域也要考虑输出域。

选值方法：
一般原则是应当选择刚好等于，稍微大于和小于边界值的值进行测试。
1）当输入域为一个值的范围时，选择范围的边界值和略微超越边界值的值；
2）当输入域规定了值的个数时，选择max，max＋1，min，min－1；
3）当输出域判断为一个值的范围时，使用1）方法；
4）当输出域判断为限定个数的值时，使用2）方法；
5）当输入输出域判断依据一个有序列时，选择有序列的第一个和最后一个元素；
6）当输入输出域判断依据一个内部数据结构时，使用改数据结构的边界值；
7）除了规定的范围，考虑会存在的其他未明示的可能；

设计测试用例：
对每个边界值建立一个新的用例。

错误推测方法

含义：
有些点虽然不是一个主要的输入输出接口，但是很容易出现错误，或者在产品的以前版本中某个点会反复出现错误。针对这些情况，设定一些测试用例来监视这些容易出错的地方，能够有效的提高错误产生点的判断效率。这种方法是一种预推测，一般都是经验的总结。

设计测试用例：
按照会发生错误的情况去书写测试用例，这样就能主动监测那些容易出错的点。

因果图方法

含义：
仅仅将值输入，是不断验证单个数据的情况。有时候，我们需要将各个数据联系在一起考虑，从而引申出多种组合，这时候有些单个数据完好的功能就可能出现错误。组合数据，主要就是根据他们之间的逻辑关系，使用同一组数据搭配不同的线路，来测试不同的路径。

设计测试用例：
第一步，分析软件说明，将输入和输出分别列出，并赋予一个唯一的标志符；
第二步，分析语义和设计，将输入和输出之间的对应关系和各自之间的联系列出来，画出因果图；
第三步，根据逻辑分析，从因果图中将不可能出现的情况移除；添加约束和限定条件；
第四步，将因果图转换为判定表；
第五步，根据判定表的每一列，设计一个新用例。

说明：
从因果图生成测试用例，包括了所有输入数据的取false和取true的情况，生成的测试用例数目达到最少。测试用例的数目是随着输入数据量的增加而增加。

判定表驱动分析方法

含义：
因果图可以生成判定表，但是也可以直接使用判定表。判定表（Decision Table）是列举和分析复合逻辑条件下多个路径的工具。主要是通过一个二维表格一目了然的将负责的逻辑结构和多种条件组合的情况表达出来。

组成：
条件桩（Condition Stub），列出所有条件。通常认为条件的次序是无关的。
动作桩（Action Stub），列出所有可能采取的动作，这些操作是没有次序约束的。
条件项（Condition Entry），列出针对它左列条件的取值。在所有坑能情况下的真假值。
动作项（Action Entry），列出在条件项的各种取值情况下应该采取的动作。

规则：
就是任何一个条件组合的特定取值及其相应要执行的操作。在判定表中，贯穿条件项和动作项的一列就是一条规则。

判定表的建立步骤：
第一步，确定规则的个数，例如：有n个条件，每个条件可取值为0和1，则有2n个规则。
第二步，列出所有的条件桩和动作桩。
第三步，填入条件项。
第四步，填入动作项。得到初始判定表。
第五步，简化合并详细规则。

可以使用判定表的条件：
1）软件说明本身就是以判定表形式给出的。
2）条件的排列顺序步影响执行那些操作。
3）规则的排列顺序不影响执行哪些操作。
4）每当某一规则的条件满足，即可确定要执行操作，不受其他规则影响。
5）如果某一个规则的条件得到满足需要执行多个操作，这些操作的顺序应该是无关的。

①专心：在执行测试任务的时候一定要专心，不可一心二用。高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。

　　②细心：执行测试工作时候要细心，认真执行测试，不可以忽略一些细节，特别是刚接触测试的。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。

　　③责任心：责任心是做好工作必备的素质之一，作为初级测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。在我以前工作过两年的一家外资公司，他们要求测试人员首先必须具备非常强的责任心！

　　④自信心：自信心是现在多数测试工程师都缺少的一项素质，更不用说初级的测试工程师了，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。

　　⑤耐心：测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。

　　⑥恒心：从事软件测试工作，很多测试工程师也迎来了个人的发展瓶颈，很多人从测试工程师做到了测试经理的职位，不知道下一步如何发展；或者每天机械地从事着功能测试工作。测试工程师要想成功，更多的是靠平时的积累。不管是项目的积累，还是平时学习，两者都至关重要。

　　⑦平常心：测试的目的是为了发现缺陷，并确认缺陷得以纠正。在此特别声明：测试人员切勿一发现BUG就嘲笑开发人员技术不行，并进行人格上的攻击，必须保持一颗平常心去对待问题所在。要不然就会引起整个测试工作僵局，不管是开发还是测试人员都会对你有看法。就别想得到什么认可了。当然决定不是叫你圆滑之类，你必须懂得正确地处理好人际关系。毕竟那里是你的根据地。