1. B/S架构和C/S架构区别
一. B/S和C/S的定义
1.什么是B/S/strong>
B/S结构（Browser/Server）是浏览器服务器这种开发模式，
就是只安装维护一个服务器(Server)，而客户端采用浏览器(Browse)运行软件
2.什么是C/S/strong>
C/S又称Client/Server或客户/服务器模式。需要做客户端服务器端 。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或 SQL Server。客户端需要安装专用的客户端软件。
3.B/S和C/S的区别
-
Client/Server是建立在局域网的基础上的。
-
Browser/Server是建立在广域网的基础上的.
-
C/S响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，；
B/S可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢 -
安全要求不同
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强.一般高度机密的信息系统采用C/S 结构适宜.
可以通过B/S发布部分可公开信息.B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群.
-
对程序架构不同
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.
-
软件重用不同
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子
-
系统维护不同
系统维护是软件生存周期中,开销大, ——-重要
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级.升级难. 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.
-
处理问题不同
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统。 B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小
-
用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.
-
信息流不同
C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低
B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心
二、CS和BS结构各自的优、缺点
1.C/S的优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器。对应的优点就是客户端响应速度快。缺点主要有以下几个：
? 只适用于局域网。而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。
? 客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。特别是有很多分部或专卖店的情况，不是工作量的问题，而是路程的问题。还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。
? 对客户端的操作系统一般也会有限制。可能适应于Win98, 但不能用于Win2000或WindowsXP。或者不适用于微软新的操作系统等等，更不用说Linux、Unix等。
2.B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用，客户端零维护。系统的扩展非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了。甚至可以在线申请，通过公司内部的安全认证（如CA证书）后，不需要人的参与，系统可以自动分配给用户一个账号进入系统。
2. HTTP协议
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是未加密的，明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
3. POST与GET区别
- Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的。
- Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。
- GET请求只能进行url编码，而POST支持多种编码方式。
- Get执行效率却比Post方法好。Get是form提交的默认方法。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制
- GET在浏览器回退时是无害的，而POST会再次提交请求
4. Cookie和Session的区别与联系
- session是存储在服务器端的，cookie是存储在客户端的，所以session的安全性要高于cookie。
- Cookie的安全性一般，他人可通过分析存放在本地的Cookie并进行Cookie欺骗。在安全性第一的前提下，选择Session更优
- 获取的session里的信息是通过存放在会话cookie里的sessionId获取的
- session是存放在服务器里的，所以session里的东西不断增加会增加服务器的负担，我们会把一些重要的东西放在session里，不太重要的放在客户端cookie里
- cookie分为两大类，一个是会话cookie和持久化cookie，他们的生命周期和浏览器是一致的，浏览器关了会话cooki也就消失了，而持久化会存储在客户端硬盘中
- Session 的运行依赖Session ID，而 Session ID 是存在 Cookie 中的，也就是说，如果浏览器禁用了
Cookie，Session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 Session ID）。
5. 测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
注意：
1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如Bev Littlewood发现一个经过测试而正常运行了n个小时的系统有继续正常运行n个小时的概率。
6. 软件测试原则
1）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。
2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。
3）程序员应避免检查自己的程序。
4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5）充分注意测试中的群集现象。
6）严格执行测试计划，排除测试的随意性。
7）应当对每一个测试结果做全面的检查。
8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
7. 软件测试分为哪几个阶段/h4>
软件测试分类
按照阶段
单元测试：是指对软件中的最小可测试单元进行检查和验证
集成测试：集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加
按照是否查看源代码划分
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)
黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
功能测试
**逻辑功能测试:**测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容
易用测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
**安装测试:**安装磁盘空间不足，安装中断(关闭程序，关机，，)下次安装时是否继续上次的安装等。。。
兼容测试:硬件兼容性测试和软件兼容性测试（硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容，软件兼容性测试:比如一款软件在window8和window10上是否兼容）
性能测试
一般性能测试
稳定测试:
负载测试: 让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
其他
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误
8. 单元测试与集成测试的侧重点
单元测试
集成测试
9. 系统测试范围
指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等
10. a测试与?测试的区别
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试
β测试是指在一个或多个用户的场所进行的测试。
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长
11. 验收测试怎么做/h4>
验收测试主要包含两个阶段：二轮测试和冒烟测试。在测试阶段的先后顺序上，二轮测试在一轮测试(需求的系统性测试)之后，在冒烟测试之前。在测试粒度上，按照由细到粗的顺序，依次为二轮测试和冒烟测试;冒烟测试，众所周知是对功能主路径的回归验证，而二轮测试则是执行较冒烟更细粒度的测试，另外也包含了一轮测试阶段中出现bug较多的场景等等。
一轮测试：系统的测试验证需求的阶段，包含全部功能点的验证、兼容性验证、性能验证等等;
二轮测试：作为一轮测试后的整体回归验证阶段，主要侧重验证功能的主流程和一轮测试中问题较多的场景的相关用例
开始标准
一、测试自身
1、一轮测试执行完毕;
2、一轮阶段的待检验bug回归完毕;
3、发起内核代码迁移邮件，确认内核开发要集成到正式发布分支的代码，且均已验证完毕。
二、配合方
1、各配合方均已上线验证完毕;
2、例如：产品配置项、服务端、前端、第三方等;
3、反例：小编最近碰到个问题，由于没有在二轮测试开始前做好上线验证工作，导致在二轮执行阶段遇到多方联调问题，影响项目进度。
4、具体表现：在二轮测试执行阶段，发现已经上线了的服务端和第三方相关功能无法顺利走通，经过定位排查发现是在上线时，服务端和第三方的接口没有联调成功。
5、三方(开发、产品、测试)确认无阻塞二轮测试的bug;
6、代码集成完毕;(视具体项目组而定)
7、新功能或有较大改动模块，产品&交互验收通过并已回复邮件;
8、新功能或有视觉改动模块，视觉走查通过并已回复邮件;
9、备注：当项目发版紧张时，开发评估一轮未结束的模块对其他模块均无影响(如，独立插件的功能模块)，可以先执行其他不受影响的模块的二轮测试
12. 白盒、黑盒和灰盒测试区别
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)
黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能
13. 冒烟测试的目的
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
使用冒烟测试是为了正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug
14. 回归测试怎么做/h4>
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
15. 全部回归与部分回归的区别/h4>
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。
16. 需求分析的目的
1、把用户需求转化为功能需求：
2、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识
17. 测试计划的目的
1、测试的目的是为了bai发现du尽可能多的缺陷，不是为了说zhi明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷
18. 什么时候开始写测试计划
在项目开始后，在前期你需要了解测试的背景，范围和工作量，以及人员的分工，所需的资源，工期等，在这些了解清楚后开始撰写测试计划
19. 由谁来编写测试计划
测试计划一般由资深的测试人员来做， 要对整zhi体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。
20. 测试计划的内容
测试背景 测试目标 测试范围 测试输出文档 测试策略 测试规模工作量分析 测试进程 测试进度及时间安排 测试资源 人力，设备， 风险管理
（1）测试环境：测试环境+生产环境
（2）测试范围：新增需求+全功能回归
（3）测试重点：优先级为high的
（4）注意事项：开发提供修改点
（5）测试级别：常规啥的
（6）测试方法：功能测试能测试
（7）测试文档：测试依据、测试条件、测试用例
（8）计划测试资源：人员以及安排的工作日
（9）是否需要外部支持：是/否
（10）测试出口：发布时间
21. 结束条件(项目上线的条件)
结束条件：
1.测试用例执行比例，一般功能测试用例全部执行完毕，非功能测试用例执行达95%以上
2.测试缺陷修改数量，一般及以上的用例全部修复并验证通过，已修复缺陷占比95%以上
3.测试覆盖需求程度，测试覆盖全部的需求且达到上线的要求或标准
上线条件：
1.编写目的：明确软件测试工作的开始和结束标准。
2.软件测试合格标准：以上比例为错误占总测试模块的比例。
3.缺陷修复率标准
1) A、B、C级错误修复率应达到100%
2) D级错误修复率应达到96%以上
4.覆盖率标准
测试需求执行覆盖率应达到100%（业务测试用例均以执行）。
5.错误级别
A级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩或挂起等导致系统不能继续运行。
B级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。
C级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题
22. 常见的测试风险
D级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题
23. 测试用例的要素
- 测试用例编号
字符和数字组合成的字符串，用例编号应具有唯一性、易识别
系统测试：产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试：产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试：产品编号-UT-单元测试项名-单元测试子项名-XXX - 测试项目
当前测试用例所在测试大类、被测试需求、被测模块、被测单元等
系统测试用例测试项目
软件需求项
集成测试用例测试项目
集成后的模块名或接口名
单元测试用例测试项目
被测函数名 - 测试标题
简单描述，需要用概括的语言描述用例的出发点和关注点，原则上每个用例的标题不能重复 - 重要级别
对基本和普通测试项的区分
高级别
保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
中级别
重要程度介于高和低之间的测试用例
低级别
实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例 - 预置条件
执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到 预期结果 - 输入
7.操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
8.预期输出
当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等
测试用例额外的要素
1.用例设计者
能准确的找到测试用例设计人员，对用例修改时能方便找准人员
2.用例设计日期
方便检查用例设计的进度
3.用例版本号
方便用例设计人员对用例的跟踪
24. 测试用例级别的划分
优先级一般都是和缺陷的严重程度对应的。
一般可以把优先级分为三种：
高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别
25. 怎样保证覆盖用户需求/h4>
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
测试完成应找业务人员进行验收，便于发现非测试角度的问题
26. 写好测试用例的关键 /写好用例要关注的维度
测试用例：测试用例为验证某一特定软件产品准备的一组有编号，输入，预期输出的描述 //记得《软件测试过程与管理》上是这样写的,而我个人觉得应该是有编号，输入，预期输出，测试步骤，测试描述等等一些信息的描述
以下Shared by Mikhail Rakhunov
好的测试用例：一个发现Bug概率很大的用例就是一个好的测试用例
测试用例设计应该具备的以下的特点
Test Case ID:
用来标记测试用例的编号，这个编号必须是唯一的
测试描述:
用来描述你将要进行的测试是怎样实施的
修订历史:
为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史
功能模块:
测试功能模块的名字
测试环境:
用来描述你的测试环境，当然包括硬件环境和软件环境
测试准备:
测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等
测试执行:
用来详细描述你的测试步骤.
期望结果:
The deion of what you expect the to do.
描述该功能所要实现怎样的结果
实际结果:
通过/失败
如果成功——纪录实际运行的过程
如果失败——描述你观察到的现象，这将有利于发现Bug的起源
———-
一个很好的测试所应具有的特征:
发现Bug的几率很大
没有多余
不是太简单也不会太复杂
———-
ps.当你的期望结果有很多的时候，测试用例就会变得很复杂
27. 测试用例的状态
排队（In Queue）：
测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：
该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）
阻塞（Block）：
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
跳过（Skip）：
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
通过（Pass）：
测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告（Warn）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭（Close）：
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
28. 常见的测试用例设计方法
用例编写步骤：
拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级
用例编写特性：
· 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。
· 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。
·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。
·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。
·复用性：主要用例可以被不断的复用，从而减少维护成本
用例设计方法：
1. 等价类与边界值**（重点方法）**
等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。
边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
与等价类区别：
? · 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
? · 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
等价类与边界值的结合使用：
? 例：一个文本框的输入长度为 6-10 个字符
? 分析：有效等价类： >=6个字符，
? 无效等价类：10个字符
? 边界值：5,6,7,9,10,11个字符
2. 场景法**（重点方法）**
定义：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
场景法的运用：
? 例：有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
? · 基本流
? · 备选流： 1) 进入购物网站，选择物品，登录账号，付费，生成订单
? 2）账号不存在
? 3) 账户余额不足
? 更多的备选流。。。。。。
3. 正交排列驱动法
定义：在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
正交表公式：
? Ln（m^k）
? · L（line）行
? n:表示正交表的行数
提示：正交表确定后，n值是固定的，不需要测试人员计算
m：表示正交表中数据的最大值
测试时：m表示每个控件的取值个数
K:表示正交表的列数
测试时：k表示参与组合的控件的个数
与判定表驱动法的区别：正交表一般用于组合较多的场合（一般>20种），判定表一般用于组合较少的情况
判定表示例：https://baike.baidu.com/pic/%E6%AD%A3%E4%BA%A4%E8%A1%A8/948850/0/ac345982b2b7d0a2394108ccc9ef76094a369ad2r=lemma&ct=single#aid=0&pic=ac345982b2b7d0a2394108ccc9ef76094a369ad2
4. 因果图
1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景：
? 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
? 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
3.因果图介绍
-
4种符号分别表示了规格说明中向4种因果关系。
-
因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
-
Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
4. 因果图概念
- 关系
? ①恒等：若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。“与”也可有任意个输入。
- 约束
? 输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
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)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
6. 错误推测法
定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例
29. 判定表用在哪些时候/哪些功能
判定表比较多用在多层条件判断组合的场景，比如嵌套的if语句这种
使用场景：
1：等价类和边界值无法覆盖到控件与控件之间的联系，此时我们需要判定表来覆盖控件与控件之间的影响
什么是判定表：
判定表是分析若干输入条件下，被测试对象根据不同的条件作出不同的响应的工具，适用于业务逻辑关系和多种条件组合情况
判定表的结构：
判定表优点
判定表法主要针对功能需求中的处理过程，处理过程越是复杂，就越有必要使用判定表法。判定表法充分考虑了输入条件间的组合，对组合情况覆盖充分，且可得出每个组合的预期输出。其实，做测试需求分析的目的也就是得出完整的测试用例。重测试需求分析，轻测试执行过程。
判定表缺点
当被测试特性输入较多时，会造成判定表的规模很庞大。当输入条件间的约束条件不能有效区分输入是否需要进行组合测试时，有可能产生冗余。需手工剔除冗余用例。
30. 什么时候用到场景法
- 场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
- 使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
- 基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
- 场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
**Note：**场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
31. 测试环境怎么搭建的/h4>
关于软件测试的测试环境搭建，需要根据实际的需求来进行安装特定的软件，下面就简单介绍下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(初始化命令)；输入net start mysql(启动数据库命令)，如果能够顺利执行这些命令无报错，则数据库安装成功。倘若已经存在旧版本的mysql想将其卸载替换可依次执行net stop mysql和mysqld -remove，然后再进行mysql的安装。
32. 偶然性问题的处理
一、一定要提交!!
1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现!!
三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )
四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现(仅仅出现一次)。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：
程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。
测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。
八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：
关于“无法重现”我看是有这么个问题存在。
首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例(说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了)。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生;全选后点击“取消全选”按钮再办理业务不会发生;全选全消后，先点击人员再办理业务也不会发生。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议!!测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员做的多了，程序员不但不感激，可能反而会反感(好像程序员对测试人员有好印象的不多)。
再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现(但是我不可能遇到问题就拉程序员来看吧)，后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox(必填)再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现(不够成熟呀)，我就放弃了，也没有提交记录(为了避免麻烦)。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。
下面是其它一些人的观点：
doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试!!!我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。
liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG，是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!
ericzhangali(另一个空间)：首先一定要提交bug;其次不要企图RD一定去解这个bug;某些时候还得关闭这个bug。如果RD认为是测试错误，(不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，)那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。(编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试)
liyan_1014(雁子)：我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚;这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。
33. 当我们认为某个地方是bug，但开发认为不是bug，怎么处理/h4>
1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中
34. 产品在上线后用户发现bug，这时测试人员应做哪些工作/h4>
首先测试人员可以做的是重现这个问题并及时反馈给开发人员，找到解决方案进行修复。
如果问题只在线上才出现，测试环境重现不了，那么可能是版本或环境配置的问题；
如果问题不仅线上能重现，测试环境也存在，那么很有可能是测试人员在测试过程中未发现的Bug。
总之，项目组成员需要尽快修复Bug。
开发人员修复Bug之后，测试人员需要反思。
若是由于疏忽造成测试用例执行遗漏，测试人员需要在下次执行测试的过程中避免这样的情况。
若是由于用例评审的不严格、中途需求变更或者某些其他因素造成的测试用例覆盖不全，测试人员需要补全测
来源：喝西北风的小富婆～
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！