B/S只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，
响应速度较慢C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,
需要针对性的开发,并且维护成本高
2.HTTP协议
3.Cookie和Session的区别与联系
Session和Cookie的主要区别在于：Cookie是把数据保存在浏览器端的内存中Session把数据保存在服务器端的内存中cookie与session的联系：当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。
该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）3）一个好的测试用例在于它发现至今未发现的错误。4）一个成功的测试是发现了至今未发现的错误的测试。
注意：
1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如BevLittlewood发现一个经过测试而正常运行了n个小时的系统有继续正常运行n个小时的概率。
1）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。
2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。
3）程序员应避免检查自己的程序。
4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5）充分注意测试中的群集现象。
6）严格执行测试计划，排除测试的随意性。7）应当对每一个测试结果做全面的检查。
8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
单元测试
是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。集成测试
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。9.系统测试范围指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试β测试是指在一个或多个用户的场所进行的测试。
α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长
验收测试主要包含两个阶段：二轮测试和冒烟测试。在测试阶段的先后顺序上，二轮测试在一轮测试(需求的系统性测试)之后，在冒烟测试之前。在测试粒度上，按照由细到粗的顺序，依次为二轮测试和冒烟测试;冒烟测试，众所周知是对功能主路径的回归验证，而二轮测试则是执行较冒烟更细粒度的测试，另外也包含了一轮测试阶段中出现bug较多的场景等等。一轮测试：系统的测试验证需求的阶段，包含全部功能点的验证、兼容性验证、性能验证等等;
一、测试自身
1、一轮测试执行完毕;
2、一轮阶段的待检验bug回归完毕;
3、发起内核代码迁移邮件，确认内核开发要集成到正式发布分支的代码，且均已验证完毕。二、配合方
1、各配合方均已上线验证完毕;
2、例如：产品配置项、服务端、前端、第三方等;
3、反例：小编最近碰到个问题，由于没有在二轮测试开始前做好上线验证工作，导致在二轮执行阶段遇到多方联调问题，影响项目进度。
5、三方(开发、产品、测试)确认无阻塞二轮测试的bug;
6、代码集成完毕;(视具体项目组而定)
7、新功能或有较大改动模块，产品&交互验收通过并已回复邮件;
8、新功能或有视觉改动模块，视觉走查通过并已回复邮件;
9、备注：当项目发版紧张时，开发评估一轮未结束的模块对其他模块均无影响(如，独立插件的功能模块)，可以先执行其他不受影响的模块的二轮测试
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果灰箱测试或灰盒测试(Gray-boxtesting):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。使用冒烟测试是为了正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。1、在测试策略制定阶段，制定回归测试策略2、确定需要回归测试的版本3、回归测试版本发布,按照回归测试策略执行回归测试4、回归测试通过，关闭缺陷跟踪单（问题单）5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
1、把用户需求转化为功能需求：
，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。17.测试计划的目的1、测试的目的是为了bai发现du尽可能多的缺陷，不是为了说zhi明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷
在项目开始后，在前期你需要了解测试的背景，范围和工作量，以及人员的分工，所需的资源，工期等，在这些了解清楚后开始撰写测试计划
测试计划一般由资深的测试人员来做，要对整zhi体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。
测试计划一般由测试经理来编写。
（1）测试环境：测试环境+生产环境
（2）测试范围：新增需求+全功能回归
（3）测试重点：优先级为high的
（4）注意事项：开发提供修改点
（5）测试级别：常规啥的
（6）测试方法：功能测试？性能测试
（7）测试文档：测试依据、测试条件、测试用例
（8）计划测试资源：人员以及安排的工作日
（9）是否需要外部支持：是/否
结束条件：1.测试用例执行比例，一般功能测试用例全部执行完毕，非功能测试用例执行达95%以上
2.测试缺陷修改数量，一般及以上的用例全部修复并验证通过，已修复缺陷占比95%以上
3.测试覆盖需求程度，测试覆盖全部的需求且达到上线的要求或标准
上线条件：1.编写目的：明确软件测试工作的开始和结束标准。
2.软件测试合格标准：以上比例为错误占总测试模块的比例。
3.缺陷修复率标准
1)A、B、C级错误修复率应达到100%
2)D级错误修复率应达到96%以上
4.覆盖率标准
测试需求执行覆盖率应达到100%（业务测试用例均以执行）。
5.错误级别A级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩或挂起等导致系统不能继续运行。
B级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。
D级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题
测试用例编号字符和数字组合成的字符串，用例编号应具有唯一性、易识别系统测试：产品编号-ST-系统测试项名-系统测试子项名-XXX集成测试：产品编号-IT-集成测试项名-集成测试子项名-XXX单元测试：产品编号-UT-单元测试项名-单元测试子项名-XXX
测试项目当前测试用例所在测试大类、被测试需求、被测模块、被测单元等系统测试用例测试项目软件需求项集成测试用例测试项目集成后的模块名或接口名单元测试用例测试项目被测函数名
重要级别对基本和普通测试项的区分高级别保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例中级别重要程度介于高和低之间的测试用例低级别实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
预置条件执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到预期结果
输入
用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入、文件、数据库记录等7.操作步骤执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行8.预期输出当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等
测试用例额外的要素1.用例设计者能准确的找到测试用例设计人员，对用例修改时能方便找准人员2.用例设计日期方便检查用例设计的进度3.用例版本号方便用例设计人员对用例的跟踪
对应的开发人员出现BUG后能及时找到相应的人员进行修复
优先级一般都是和缺陷的严重程度对应的。一般可以把优先级分为三种：
高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
测试完成应找业务人员进行验收，便于发现非测试角度的问题
测试用例：测试用例为验证某一特定软件产品准备的一组有编号，输入，预期输出的描述//记得《软件测试过程与管理》上是这样写的,而我个人觉得应该是有编号，输入，预期输出，测试步骤，测试描述等等一些信息的描述
以下SharedbyMikhailRakhunov好的测试用例：一个发现Bug概率很大的用例就是一个好的测试用例
测试用例设计应该具备的以下的特点
TestCaseID:用来标记测试用例的编号，这个编号必须是唯一的
测试描述:用来描述你将要进行的测试是怎样实施的
修订历史:为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史
功能模块:测试功能模块的名字
测试环境:用来描述你的测试环境，当然包括硬件环境和软件环境
测试准备:测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等
测试执行:用来详细描述你的测试步骤.
期望结果:Thedeionofwhatyouexpectthetodo.描述该功能所要实现怎样的结果
实际结果:通过/失败如果成功——纪录实际运行的过程如果失败——描述你观察到的现象，这将有利于发现Bug的起源
----------
一个很好的测试所应具有的特征:发现Bug的几率很大没有多余不是太简单也不会太复杂
----------ps.当你的期望结果有很多的时候，测试用例就会变得很复杂
测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
用例编写步骤：
拿到测试需求->分析需求（画思维导图）->编写用例->划分用例优先级
用例编写特性：
·一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。
·覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等。
·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点。
·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。
·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例。
·复用性：主要用例可以被不断的复用，从而减少维护成本
用例设计方法：
1.等价类与边界值**（重点方法）**
等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。
边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
与等价类区别：
·边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
·边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
等价类与边界值的结合使用：
例：一个文本框的输入长度为6-10个字符
分析：有效等价类：>=6个字符，<=10个字符
无效等价类：<6个字符，>10个字符
边界值：5,6,7,9,10,11个字符
2.场景法**（重点方法）**
定义：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
场景法的运用：
·基本流
2）账号不存在
3)账户余额不足
更多的备选流。。。。。。
\3.正交排列驱动法
定义：在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
正交表公式：
Ln（m^k）
·L（line）行
n:表示正交表的行数
提示：正交表确定后，n值是固定的，不需要测试人员计算
m：表示正交表中数据的最大值
测试时：m表示每个控件的取值个数
K:表示正交表的列数
测试时：k表示参与组合的控件的个数
与判定表驱动法的区别：正交表一般用于组合较多的场合（一般>20种），判定表一般用于组合较少的情况
4.因果图
1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
3.因果图介绍
1)4种符号分别表示了规格说明中向4种因果关系。
2)因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
3)Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
\4.因果图概念
1)关系
①恒等：若ci是1，则ei也是1；否则ei为0。
②非：若ci是1，则ei是0；否则ei是1。
③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。
④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。
2)约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如,某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
A.输入条件的约束有以下4类：
①E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
②I约束（或）：a、b和c中至少有一个必须是1，即a、b和c不能同时为0。
③O约束（唯一）；a和b必须有一个，且仅有1个为1。
④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
B.输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
\5.采用因果图法设计测试用例的步骤：
1)分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
2)分析软件规格说明描述中的语义，找出原因与结果之间,原因与原因之间对应的关系，根据这些关系,画出因果图。
3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。
4)把因果图转换为判定表。
5)把判定表的每一列拿出来作为依据,设计测试用例。
5.判定表
定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点
·能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
·在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
判定表通常由四个部分组成如下图所示：
1)条件桩（ConditionStub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（ActionStub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（ConditionEntry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（ActionEntry）：列出在条件项的各种取值情况下应该采取的动作。
6.错误推测法
定义：基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例
判定表比较多用在多层条件判断组合的场景，比如嵌套的if语句这种
条件桩：被测对象所有的输入
动作桩：针对条件桩所有的动作
条件项：被测对象可能输入的真假值TF
动作项：针对条件项的动作TF
使用判定表的步骤
场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
关于软件测试的测试环境搭建，需要根据实际的需求来进行安装特定的软件，下面就简单介绍下java+tomcat+mysql安装方法。
1.java的安装
因为很多程序的代码都是通过java编程语言进行编写的，因此为了测试需要，我们需要安装支持java编程语言的安装包，即jdk。下载好指定的安装包后双击安装包，默认下一步即可。完成这些步骤后需要配置环境变量，右键点击我的电脑-属性-高级系统设置-环境变量-系统变量(s)-选中path-编辑将安装好的java中的bin和jre的路径添加到环境变量中即可。在cmd中输入java-version和javac-version验证是否安装成功。
2.tomcat的安装
在java安装无误的情况下，下载好tomcat安装包，直接点击下一步即可。
3.mysql的安装
下载好安装包，将其解压到想要安装的盘符中；按照1中的方法，将mysql中bin的路径添加到环境变量中；打开cmd，切换到英文，输入mysqld-install(安装命令)；输入mysqld--initialize-insecure(初始化命令)；输入netstartmysql(启动数据库命令)，如果能够顺利执行这些命令无报错，则数据库安装成功。倘若已经存在旧版本的mysql想将其卸载替换可依次执行netstopmysql和mysqld-remove，然后再进行mysql的安装。
一、一定要提交!!
尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
无法重现的问题再次出现后，可以直接叫程序员来看看问题。
对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现!!
三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。:)
四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：
关于“无法重现”我看是有这么个问题存在。
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议!!测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员做的多了，程序员不但不感激，可能反而会反感(好像程序员对测试人员有好印象的不多)。
再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现(但是我不可能遇到问题就拉程序员来看吧)，后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox(必填)再进行Edit的录入，但一次操作我没有选择ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现(不够成熟呀)，我就放弃了，也没有提交记录(为了避免麻烦)。
下面是其它一些人的观点：
liyan_1014(雁子)：我觉得应该是这么处理：
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。
1.找到需求文档或者是原型图进行匹对2.尝试多种测试环境和多种测试方式来确认是否为bug3.整理bug的复现的步骤和出现的频率4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug5.将客户经理测试测试经理和项目经理进行开确认会来判定是否为bug6.测试人员需要将bug整理并写入测试总结中
首先测试人员可以做的是重现这个问题并及时反馈给开发人员，找到解决方案进行修复。
如果问题只在线上才出现，测试环境重现不了，那么可能是版本或环境配置的问题；
如果问题不仅线上能重现，测试环境也存在，那么很有可能是测试人员在测试过程中未发现的Bug。
总之，项目组成员需要尽快修复Bug。
开发人员修复Bug之后，测试人员需要反思。
若是由于疏忽造成测试用例执行遗漏，测试人员需要在下次执行测试的过程中避免这样的情况。
若是由于用例评审的不严格、中途需求变更或者某些其他因素造成的测试用例覆盖不全，测试人员需要补全测试用例。
在测试过程中遇到未发现的Bug，测试人员不要自怨自艾，
也不要像没回事儿一样，需要正确对待“线上Bug”、汲取经验教训、不断提高测试能力。
测试人员需要不断学习，不断扩充，掌握测试工具、提升测试技能，从而设计出更全面的测试场景和测试用例。
在执行用例的过程中发现了跟预期实际不符的情况，就提交缺陷,跟踪缺陷修改，跟踪缺陷流程主要有四个(一个正常的修改结束的流程，三个特殊处理流程)
新建--开启--修改--关闭提交缺陷后开发人员确认修改后回归通过；
新建--拒绝开发人员未确认缺陷拒绝修改，这个时候需要在确认需求理解正确(跟产品确认)和复现步骤(多次复现)的基础上,跟开发人员沟通是否需要修改；
新建--开启--修改--重开修改后提交的版本回归不通过，这是需要重新打开缺陷,为了加快缺陷正确修改，可以跟开发人员沟通，协助开发人员定位缺陷；
新建--开启--延期部分开启的缺陷，由于无法复现,难以修改，进度压力等原因,可能需要延期修改，这个时候，是否延期，是需要多方确认的(测试、产品、开发、领导)。
New（新的）：bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
bug缺陷等级一般划分为四个等级，致命、严重、一般、提示
致命（一级bug）**通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
严重（二级bug）通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1.功能未实现；2.功能存在报错；3.数值轻微的计算错误。
一般（三级bug）**通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
提示（四级bug）通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件
概述：一般会在概述中添加项目背景、需求描述等信息。
测试过程主要包含评审记录、测试范围、测试用例
罗列出是否已按本次测试计划实现功能
包括资源统计、执行情况、问题统计、问题列表、遗留问题
主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。
测试风险没有放在测试总结里，而是单独划分为一个模块，可见其重要性。
1、开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。
3、当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因
4、另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等
1、针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a)从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b)可以和开发人员列举一个之前的类似问题，为开发提供参考
c)产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
3、修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
在立项会中制定需求文档，由UI设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行修改，修改成功后关闭bug，进行回归测试，在上线前进行测试总结。
圆珠笔
能否正常书写
写出来的字遇水是否会消失
是否有笔油泄露
笔帽是否能正常按下弹起来
笔的长短粗细是否顺手
一根笔芯用尽是否方便更换
外形是否美观
笔油是否含有有害物质
笔尖是否容易伤到人
笔油或者墨水保质期多长过期是否产生有害物质
在不同的温度、气压、和重力下能否正常使用在不同的纸质和力度下书写结果如何
笔芯弹出弹回的快慢。
连续按，看弹簧能经受多少次伸缩。
如果以极快的速度按压弹簧，该笔是否会崩溃？
掉在地上是否会坏掉
被踩了后是否容易坏，承受最大压力
笔芯的颜色
是不是可擦掉的笔
图案是否会掉色
笔墨的气味
墨水多久能干
笔杆折断，材质是不是容易刮伤手
误食笔墨是否引起中毒
流畅度
在木板或墙壁上书写，在其他物体上书写
这个笔芯的笔尖/笔壳摔坏了，我换其他的笔芯的尖能不能继续用
高温和低温环境下对笔芯出墨和笔壳的影响
三角形测试用例设计
（参考）
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。
一、等价类划分：三角形三条边A、B、C的数据类型不同
我们再分析一下三角形的等价类：
有效等价类：
输入3个正整数或正小数：
1、两数之和大于第三数，如A 2、两数之和不大于第三数 3、两数相等，如A=B或B=C或C=A 4、三数相等，如A=B=C 5、三数不相等，如A！=B，B！=C，C！=A 无效等价类： 1、空 2、负整数 3、非数字 4、少于三个数 等价类表： 测试用例 接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据 软件生命周期中，需求是整个周期的源头。良好的开端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企业中，并没有对需求引起足够的重视。原因并不是PM们不知道需求的重要性，而是商业竞争中不得不裁剪某些看似不能获得很大利益的步骤。 什么是需求？很多PM和开发人员都未必真正考虑过这个问题。IEEE对需求有以下两种定义的方式。 1.解决用户问题或达到用户目标需要具备的条件或能力 2.遵守合同、协议、规范或其他要求 然后用规范的文档描述出来，就成了我们熟悉的SRS。 我们常说的需求，其实并不是我们认为的SRS。SRS应该叫做需求规格说明书。那需求是什么呢？与需求规格有什么区别？ 需求：对要实现的功能的粗略描 需求规格：对需求的精确定义 除了以上所说的需求，对于测试人员，还必须有测试需求。这个环节，很少有企业会重视。测试需求分为2方面： 需要测试哪些方面 软件是否可测，需要增加哪些开发需求 其中第一条，很多企业都列到了测试计划中，这也可以，没有规定一定要放到哪个文档里。但是对于第二条，可以说几乎没有多少企业去做。 接下来，在没有明确需求，需求规格，测试需求的情况下，我们怎么去做测试呢？现在很多企业，其实就是在这种情况下做项目的。 当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能，背景，架构。于是，马上就会想得到需求文档。但结果往往是失望的，根本没有文档，或者文档根本不具备参考价值。此时不必太失望，因为这种情况实在是太常见啦。这时，请试着从以下几个步骤着手。 也有时，我们的项目是一个行业项目，比如金融项目。我们可以参 考一些行业知识的书籍，文档。这对理解系统也有很大的好处。 实在没有文档，那只好暂时跳过这一步骤了。 试着使用系统，根据经验和常识猜测：既然没有需求，那可以推测，该项目的管理一定是很糟糕的，对测试也不会投入很大的成本。因此，测试人员一般都是在编码完成后才进入项目。这时，应该已经可以看到成型的系统了。在没有需求的情况下，试着先“玩”一下系统吧。在这过程中，你应该对系统有可更深入的认识，在上一阶段中，你可能留下很多疑惑或是猜测，这时应该能排除一部分了。 使用系统的同时，你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识，比如什么是持仓，什么是平仓。那么你如何能真正理解这个系统呢？当你有了业务知识以后，你会进行更深入的思考，来全面测试系统。 你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选，不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。 最后加上你的主观判断，你对系统的整体感觉怎么样？是否越用越厌烦，为什么厌烦。系统的反应速度是否可以容忍，细节处理是否圆滑，等等。 在你认识系统的时候，可以使用一些方法，来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时，你也留下宝贵的文档。当然，这个步骤中，你也要随时注意保留和更新文档，以备后用。 沟通：需求规格不一定非要以文档的形式表现出来。软件既然能做出来，那肯定是有需求的。而最清除需求的，一定是软件的直接制造者，开发人员。开发人员自己知道需求，但一般不会主动和测试人员沟通。因此，测试一定要主动和开发人员沟通。可以安排会议，让开发人员给测试人员介绍系统，并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候，一定会有更多不明确的地方。这时就需要利用自己的行业知识，计算机知识等，猜测一 有时候，会根本找不到可以沟通的人。不要奇怪，确实就是有这种时候。比如： 1.测试一个开源软件 3.软件项目组的部分人员已经联系不上等等 在进行以上步骤的时候，利用良好的工具，能让你事半功倍。我经常在使用的一个工具，就是MindjetMindManager。这是一个很好的，帮助扩展思维的工具。它以分支的形式，来表现你的思维层次。你可以先列出个最基本的系统整体结构，然后逐步细化，增加分支。不要急于一次就将真个系统分析透彻，这是不可能的。你在进行以上步骤的时候，随时会细化这个结构。当项目结束后，看看这个结构图，简直可以当作SRS来参考。 1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。 2、把自己当成是用户，把自己当成用户去使用该软件，比如在试用软件的过程中，思考用户是这样操作的么 3、善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生；别人认为是对的，我却认为是错的。假如一个水平很高的程序员编写的程序，不要有“他写的这个程序应该没有问题吧”这种想法，这样很容以遗漏软件中的Bug。 4、不用让程序开发员“用户不会这样操作”的观点说服自己，遇到这样的情况，你要坚持自己的正确的观点，把这种现象作为一个Bug。 5、在测试的过程中要跟踪一条数据的完整流程，比如“点击商品—收藏商品—加入购物车—订单结算—付款—消费二维码—消费—二维码失效”，如果在测试软件过程中业务流程逻辑都走不通的话，还么这个软件测试与不测试就没有什么区别的。 6、在测试的过程中要跟踪一条数据的完整程，要注意的事项，程序员提交新的版本后，作为测试人员应该立即与程序员沟通这个修改的功能，并了解这个新修改的功能影响那些功能。而被影响的功能，是在回归测试中优先重点测试的地方，而且也是最容易产生Bug的地方。 7、软件的边界值，众所周知软件最容易在边界值上出现问题，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空的情况； 9、学习他人经验：三人行必有我师焉，人外有人，天外有天。 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。 和预期不一致的软件行为。 一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。 和测试员预期不一致的软件行为。和程序员预期不一致的软件行为。和文档预期不一致的软件行为。和管理者预期不一致的软件行为。和客户预期不一致的软件行为。 1.由于保护机制，你一次取钱数额有限，需要多次操作的时候每次现出卡你会觉得麻烦无比。 2.吞卡当然是为了安全，这没有什么争论吧。 3.至今从没见过吞了的卡还能吐出来的，根据后边ATM机的构造，也不可能再退出来，是直接掉在一个小盒子里的。 4.不可能你随时去取吞卡别人就给你取，首先ATM必须双人操作才能进，第二营业厅也必须双人在场，不能一人在营业厅，所以一般都是加钞的时候顺便取出来。 5.现在在任何地方应该都不会有不核实情况直接给人吞卡的，外行卡除外，外行卡被吞，本行毫无办法核实任何信息，只能让你出示身份证信息并登记，确保是被你这个人取走的。 同类型软件在你的操作系统硬件环境上运行，如果一慢一块，则是软件问题 同一软件在别人的操作系统上，如果运行速度加快，则是你的操作系统或硬件的问题 首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。 当BUG解决且上线没有问题之后，我们再看后续的处理。 追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况： 1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。 解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。