测试
需求分析 ——> 测试计划 ——> 测试设计、测试开发 ——> 测试执行 ——> 测试评估
敏捷开发有很多种，其中scrum是比较流行的一种
V模型
局限性：仅仅把测试作为在编码之后的一个阶段，没有在需要阶段就进入测试
W模型
特点：开发与测试并行进行，有利于尽早的发现问题
测试用例是为了实施测试而向被测试的系统提供的一组集合，集合包括：测试环境、操作步骤、测试数据、预期结果等
需求：超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、大米、衣服
- 输入框长度为1-11，取边界值：0、1、11、12
- 运动员的参赛项目为1-3项，取边界值：0项、1项、3项、4项
- 查询面页面有999行，每50行一页，取边界值：输出0行、1行、50行、51行、999行、1000行
与：
如果两个输入都为真，那么输出就为真
或：
如果输入中有一个为真，那么输出就为真
非：
只有输入为假，输出才为真
案例：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进入优惠”
- 对于本业务规则，首先通过分析所有可能的数据和可能的输出，得到以下结果：
输入：订单已提交、金额大于300、有红包
输出：优惠、不优惠- 进行第二步，找出输入与输出之间的对应关系，通过分析可以看出以下对应关系
(1)订单已提交，订单金额大于300元，有红包，则优惠
(2)订单已提交，订单金额大于300元，无红包，则优惠
(3)订单已提交，订单金额小于等于300元，有红包，则优惠
(4)订单已提交，订单金额小于等于300元，无红包，不优惠
(5)订单未提交，不优惠- 为了方便画出因果图和判定表，需要对所有输入和输出编号
c1：订单已提交
c2：订单金额大于300元
c3：有红包
e1：优惠
e2：不优惠- 画出因果图
- 画判断表：有3个条件，输出有2个值，所以表的列数为2×2×2=8
最终的测试用例
1、2、3、4、5(包含6、7、8)
单元测试
测试阶段：编码后或编码前
测试对象：最小模块
测试方法：白盒测试
测试内容：模块接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试
集成测试
测试阶段：单元测试之后
测试对象：模块间的接口
测试方法：黑盒测试+白盒测试
测试内容：模块之间的数据传输，模块之间的冲突，模块组装功能的正确性，全局数据结构
系统测试
测试阶段：集成测试之后
测试对象：整个系统
测试方式：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试
回归测试指修改了代码后，重新进行测试以确认修改后没有引入新的错误
冒烟测试
一般在开发人员开发完毕后给测试人员进行测试时，测试人员会先进行冒烟测试，冒烟测试就是让产品运行起来，测试能否正常启动
验收测试
最后一个阶段的测试，确保产品准备就绪
测试阶段：系统测试之后
测试对象：整个系统
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性
α测试
α测试是由用户在开发环境下进行的测试
β测试
β测试是由软件的最终用户在一个或多个场所进行测试
α测试和β测试的区别：
手工测试
由手工一个一个去输入测试用例，然后观察结果
优点：思维发散，缺点：执行效率慢
自动化测试
简单说就是以人为驱动的测试行为转化为机器执行的一个过程
自动化测试步骤：
- 完成功能测试，版本基本稳定
- 根据项目特性，选择合适项目的自动化测试工具，并搭建环境
- 提取手工测试的测试用例转化为自动化测试的用例
- 通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
- 生成自动化测试报告
- 持续改进，脚本优化
selenium 1(环境杀伤)：seleniumRC(已被webdriver替代)、seleniumIDE(录制自动化测试脚本)、selenium GRID(分布式)
selenium 2：webdriver(Google)
selenium 3：增加了一些浏览器的原生驱动，safari(苹果)，edge(微软)
原理
浏览器相当于出租车，webdriver相当于司机，脚本相当于乘客
脚本(乘客)把指令传达给webdriver(司机)，webdriver(司机)来根据指令驱动浏览器执行脚本命令(开车)
请回答单元测试、集成测试、系统测试、验收测试、回归测试中哪步最重要
这些测试步骤分别在软件开发的不同阶段对软件测试，自认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行测试，也能够覆盖系统所有联合的部件，能够验证系统全局是否满足需求规格的定义，因此系统测试很重要
回答集成测试和系统测试的区别，以及它们的应用场景
区别：
1、先后设计用例顺序不同：从w模型来讲，一般都是先设计系统测试计划用例，在设计集成测试
2、用例粒度不同：系统测试用例相对接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点设计
3、执行顺序不同：先执行集成测试，待到集成测试出现问题都修复后，再做系统测试应用场景
集成测试：完成单元测试之后，个模块联调测试，集中在个模块间连接的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等，可以是整个产品的集成测试，也可以是组合的大模块的集成测试；集成测试主要针对程序内部结构进行测试，特别是对程序模块之间的接口进行测试，测试方法一般选黑盒、白盒测试相结合
**系统测试：**针对整个产品的全面测试，即包含个模块的验证性测试和功能性测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。做系统测试要严格按照《需求规格说明书》的标准，一般都使用黑盒测试
黑盒测试和白盒测试又哪些方法
黑盒测试方法有：等价类划分，边界值分析，错误推测，因果图法
白盒测试方法有：逻辑覆盖法，程序插桩法，基本路径法，符号测试，错误驱动测试
请说一说黑盒与白盒的测试方法
黑盒测试：
主要着眼于程序外部结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序的所有错误。对于测试用例，不仅要测试所有合法的输入，而且还要对那些不合法但是可能出现的输入情况进行测试。常用的黑盒测试方法：等价类划分法，边界值分析法，因果图法，场景法，正交实验设计法，判定表驱动分析法，错误推测法，功能图分析法
白盒测试：
也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证，白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，仍然有可能存在错误，因为穷举路径测试无法检查出程序本身是否违反了设计规范
白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真与假两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上边界及可操作范围内运行所有循环
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的思维优势，也可以借助软件工具自动进行
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次
2.判定覆盖每个判定的每个分支至少执行一次
3.条件覆盖每个判定的每个条件应取到各种可能的值
4.判断/条件覆盖同时满足判定覆盖条件覆盖
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次
6.路径覆盖使程序中每一条可能的路径至少执行一次
手工测试优点：
1、测试人员具有经验和对错误的猜测能力
2、测试人员具有审美能力和心理体验
3、测试人员具有是非判断和逻辑能力
手工测试缺点：
1、重复的手工回归测试，代价太大，容易出错
2、依赖于软件测试人员的能力
自动化测试优点：
1、对程序的回归测试更方便，这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果更明显。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，大大提高测试效率
2、可以运行更多更繁琐的测试，可以在较短的时间内运行更多的测试
3、可以执行一些手工测试困难或不可能进行的测试。比如，模拟大量用户同时访问操作
4、更好的利用资源，将繁琐的任务自动化，可以提高准确性，也可以让测试人员有更多的精力设计更好的测试用例。
5、自动化测试具有一致性和可重复性，每次测试的结果和执行的内容一致性可以保障
6、测试的复用性，由于自动测试通常采用脚本技术，这样就有可能只需要做少量的修改，实现在不同测试过程中使用相同的用例
自动化测试缺点：
1、不能取代手工测试
2、手工测试比自动化测试发现的缺陷更全面
3、对测试质量的依赖性极大
4、测试自动化不能提高有效性
5、自动化测试可能会制约软件开发，由于自动测试比手动测试更脆弱，所有维护会受到限制，从而制约软件的开发
6、工具本身不具备思维发散能力
搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交bug表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法
常用的边界值
黑盒测试
等价类划分
等价类划分是将系统的输入域划分为若干部分，然后从每部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例时两种都要考虑
边界值分析法
边界值分析法是对等价类划分的一种补充，边界值分析法就是假定大多数错误出现在输入条件的边界上，边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类更有效的进行测试，因此该方法要和等价类划分法结合使用
-正交试验法
正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方式，它是一种基于正交表的高效率、快速、经济的试验设计方法
-状态迁移法
状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖
-流程分析法
流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴来的一种重要方法
-输出域分析法
输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例
-判定表分析法
判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确
-因果图法
因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征建模过程，根据输入输出的因果图可以得到判定表，从而规划处测试用例
-错误猜测法
错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例
-异常分析法
异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发送错误时系统对于错误的处理能力和恢复能力依次设计测试用例
1、内存：内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、中等规格、满规格
空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短
内存测试中存在很多测试子项：
空闲状态下的应用内存消耗，中等规格转态下的应用内存消耗，满规格状态下的应用内存消耗，应用内存峰值，应用内存泄漏，应用是否常驻内存，压力测试后的内存使用
2、CPU：
使用Android提供的view plaincopy在CODE上查看代码片派生到我的代码片adbshell dumpsys CPUinfo | grep packagename >/ address/CPU.txt来获取；使用top命令view plaincopy在CODE上查看代码片派生到我的代码片adbshell top | grep packagename >/ address/CPU.txt来获取。
3、流量：
网络流量测试是针对大部分应用而言的，可能还要部分应用会关注网速、弱网之类的测试
流量测试包括以下测试项：
应用首次启动流量提示；
应用后台连续运行2小时的流量值；
应用高负荷运行的流量峰值；
4、电量
5、启动速度
第一类：首次启动——应用首次启动所花费的时间
第二类：非首次启动——应用非首次启动花费的时间
第三类：应用界面切换——应用界面内切换所花费的时间
6、滑动速度、界面切换速度
7、与服务器交互的网路速度
系统架构方面：
web项目一般都是b/s构架，基于浏览器
app项目则是c/s，必须要有客服端，用户需要安装客户端
web项目只要更新服务端，客服端就会同步更新
app项目则需要客户端和服务端都更新
性能方面：
web页面主要关系响应时间
app则还需要关心流量、电量、CPU、GPU、Memory等等
兼容方面：
web基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向兼容
web不必考虑客户端的安装卸载
app测试则还要看分辨率，屏幕尺寸，还有看设备系统
而app是客户端，则必须测试安装、更新、卸载。除了常规的安装，更新，卸载还要考虑到异常场景，包括安装时的中断、弱网、安装后删除安装文件
主要包括四种类型的测试：
一致性测试：检测协议实现本身与协议规范的符合程度
互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
性能测试：检测协议实现的性能指标，比如数据传输速度、连接时间、执行速度、吞吐量、并发度
健壮性测试：检测协议在现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断
很好奇，就使用rubyonrails自动化单元测试而言，你们正在做什么？您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您？git中的预提交Hook？只是手动调用？我完全理解测试，但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的，并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您？ 最佳答案 不确定您到底想听什么，但是有几个级别的自动代码库控制:在处理某项功能时，您可以使用类似autotest的内容获得关于哪些有效，哪些无效的即时反馈。要确保您的提
我正在编写一个包含C扩展的gem。通常当我写一个gem时，我会遵循TDD的过程，我会写一个失败的规范，然后处理代码直到它通过，等等......在“ext/mygem/mygem.c”中我的C扩展和在gemspec的“扩展”中配置的有效extconf.rb，如何运行我的规范并仍然加载我的C扩展？当我更改C代码时，我需要采取哪些步骤来重新编译代码？这可能是个愚蠢的问题，但是从我的gem的开发源代码树中输入“bundleinstall”不会构建任何native扩展。当我手动运行rubyext/mygem/extconf.rb时，我确实得到了一个Makefile(在整个项目的根目录中)，然后当
我有一个围绕一些对象的包装类，我想将这些对象用作散列中的键。包装对象和解包装对象应映射到相同的键。一个简单的例子是这样的:classAattr_reader:xdefinitialize(inner)@inner=innerenddefx;@inner.x;enddef==(other)@inner.x==other.xendenda=A.new(o)#oisjustanyobjectthatallowso.xb=A.new(o)h={a=>5}ph[a]#5ph[b]#nil,shouldbe5ph[o]#nil,shouldbe5我试过==、===、eq?并散列所有无济于事。
我有一些Ruby代码，如下所示:Something.createdo|x|x.foo=barend我想编写一个测试，它使用double代替block参数x，这样我就可以调用:x_double.should_receive(:foo).with("whatever").这可能吗？ 最佳答案 specify'something'dox=doublex.should_receive(:foo=).with("whatever")Something.should_receive(:create).and_yield(x)#callthere
Sinatra新手；我正在运行一些rspec测试，但在日志中收到了一堆不需要的噪音。如何消除日志中过多的噪音？我仔细检查了环境是否设置为:test，这意味着记录器级别应设置为WARN而不是DEBUG。spec_helper:require"./app"require"sinatra"require"rspec"require"rack/test"require"database_cleaner"require"factory_girl"set:environment,:testFactoryGirl.definition_file_paths=%w{./factories./test/
我遵循MichaelHartl的“RubyonRails教程:学习Web开发”，并创建了检查用户名和电子邮件长度有效性的测试(名称最多50个字符，电子邮件最多255个字符)。test/helpers/application_helper_test.rb的内容是:require'test_helper'classApplicationHelperTest在运行bundleexecraketest时，所有测试都通过了，但我看到以下消息在最后被标记为错误:ERROR["test_full_title_helper",ApplicationHelperTest,1.820016791]test
我正在尝试从Postgresql表(table1)中获取数据，该表由另一个相关表(property)的字段(table2)过滤。在纯SQL中，我会这样编写查询:SELECT*FROMtable1JOINtable2USING(table2_id)WHEREtable2.propertyLIKE'query%'这工作正常:scope:my_scope,->(query){includes(:table2).where("table2.property":query)}但我真正需要的是使用LIKE运算符进行过滤，而不是严格相等。然而，这是行不通的:scope:my_scope,->(que
我已经构建了一些serverspec代码来在多个主机上运行一组测试。问题是当任何测试失败时，测试会在当前主机停止。即使测试失败，我也希望它继续在所有主机上运行。Rakefile:namespace:specdotask:all=>hosts.map{|h|'spec:'+h.split('.')[0]}hosts.eachdo|host|begindesc"Runserverspecto#{host}"RSpec::Core::RakeTask.new(host)do|t|ENV['TARGET_HOST']=hostt.pattern="spec/cfengine3/*_spec.r
我在app/helpers/sessions_helper.rb中有一个帮助程序文件，其中包含一个方法my_preference，它返回当前登录用户的首选项。我想在集成测试中访问该方法。例如，这样我就可以在测试中使用getuser_path(my_preference)。在其他帖子中，我读到这可以通过在测试文件中包含requiresessions_helper来实现，但我仍然收到错误NameError:undefinedlocalvariableormethod'my_preference'.我做错了什么？require'test_helper'require'sessions_hel
只是想确保我理解了事情。据我目前收集到的信息，Cucumber只是一个“包装器”，或者是一种通过将事物分类为功能和步骤来组织测试的好方法，其中实际的单元测试处于步骤阶段。它允许您根据事物的工作方式组织您的测试。对吗？ 最佳答案 有点。它是一种组织测试的方式，但不仅如此。它的行为就像最初的Rails集成测试一样，但更易于使用。这里最大的好处是您的session在整个Scenario中保持透明。关于Cucumber的另一件事是您(应该)从使用您的代码的浏览器或客户端的角度进行测试。如果您愿意，您可以使用步骤来构建对象和设置状态，但通常您
