精华内容
下载资源
问答
  • 在我们的工作中,为了提高测试效率或者做出测试团队的业绩来,都不得不很多的自动化,当然这包括测试环境搭建,测试数据构造,测试执行,压力及安全测试等等,但是在各个阶段中,应该怎么样做好自动化满足我们的...

    转自 http://www.oktest.me/p/317.html

    在我们的工作中,为了提高测试效率或者做出测试团队的业绩来,都不得不做很多的自动化,当然这包括测试环境搭建,测试数据构造,测试执行,压力及安全测试等等,但是在各个阶段中,应该怎么样做好自动化满足我们的业务发展需要呢?今天主要谈谈单元和集成测试。
    自动化投入产出比
    一个被简化的公式:
    自动化的收益 = 迭代次数 * 全手动执行成本 – 首次自动化成本 – 维护次数 * 维护成本
    或者如果假设迭代次数和维护次数近视相等,这个在某些情况下可以成立,比如一个比较新的产品:
    自动化的收益 = 迭代次数 * (全手动执行成本 – 维护成本) – 首次自动化成本

    对此公式,我们可以解读一下:

    • 自动化的收益与迭代次数成正比;
    • 自动化收益可能为负,即维护成本和首次自动化成本比全手工执行成本还高的时候;
    • 很多时候首次自动化成本并不比手工测试成本高,但是维护成本很高.

    实际上,这个公式的确被简化了,原因是只是关注了其付出的时间,忽略了带来的效果,比如给项目周期缩短上带来的成效,对于质量保障的成效等等,对于项目周期上的评判则可以用以下公式:
           缩短周期=手工测试时间-自动化测试时间
    而且该周期都是针对同一个已经被自动化的模块评估的.
    此外,很多时候我们关注自动化对于质量的贡献时,都是关注其发现了多少个bug,实际上自动化并不能帮我们发现更多的bug,都只是在原先预先设定好的程序上重复执行,所以根本不可能做到100%的自动化,测试人员的经验,逻辑判断和探索性的测试方法都不能被有效自动化.

    什么样的项目适合做自动化?
    通过上面的公式也可以看出:

    • 一个快速发展,变更频繁的项目不适合做过多的自动化,而处于后期维护阶段,自动化收益会更高;
    • 对于接口类的产品;
    • 手工测试非常费时费力,甚至无法达到测试目的的项目,比如对于大数据量大并发下的压力测试等.

    什么时候介入?
    如果对于早期,开发设计还未稳定,界面还会经常变化,接口还未明确的情况下,是不适合做自动化的,即使做了,也会频繁的修改,这个时候手工测试可能效率更高,能快速发现问题反馈给开发人员.而如果有了稳定的界面,明确的接口设计,明确的数据结构之后,自动化再介入可以自动化收益.
    今天我们重点介绍一下单元测试,集成测试部分.

    谁来写单元测试
    在一个软件工程团队里,的确没有必要明确到底应该谁来写,比较好的做法是依据团队人员配置而定.单元测试普遍采用白盒测试的方法,离不开深入理解被测对象的代码,同时还需要构造驱动模块、桩函数,因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑,开发人员具有一定的优势,其最大的优点是快速,且能更好的实现。

    但是从单元测试效果的角度考虑,保证测试组参与单元测试也有其优势,这是因为:
    首先,从目前国内企业普遍现状来看,测试人员质量意识要高于开发人员,测试人员参与单元测试能够提高测试质量。

    其次,对被测系统越了解,测试才有可能越深入,测试人员参与单元测试,将使得测试人员能够从代码级熟悉被测系统,这对测试组后期集成测试和系统测试活动非常有帮助,可以很快速的评估影响范围,进而可以非常准确的制定回归测试策略,而不用满盘回归.

    测试组以何种方式参与单元测试,应该结合人员配置情况来定。如果软件组织测试资源充分,测试人员对开发人员的比例较高,那么可以由测试人员独立承担部分重要模块的单元测试工作,比如微软这样的公司,开发测试比1:1,那么测试人员就需要进行较为充分的单元测试;如果测试资源不足,测试人员对开发人员的比例较低,那么单元测试的实现和执行由开发人员来完成,但测试组至少应该参与开发组的各相关设计文档评审,以及code review保证质量。

    单元测试的现状
    可以把这种现状结合业务情况来看分为两种:
    1)在业务快速发展迭代频繁的团队,追求高覆盖的单元测试是一件奢侈而且不可取的事情,毕竟把单元测试做好的话可能需要写比开发代码还要多的测试代码,这就需要持续的投入,包括人力和时间上,这也就是为什么微软有那么多测试同学的原因,对于传统软件而言可能值得这样的投入,也就是软件测试工程中的正三角模型。

    2

    2)而互联网时代,短平快是赢得市场的重要理念,为了获得快速的迭代,大家都没有过度的追求单元测试的覆盖率,但是我了解到在百度一些产品线,迭代并不频繁的项目,还是有强制要求对单元测试的覆盖率的,不达到标准是需要打回给开发继续完善单测的,但是我们大多数公司要么是开发一点都不做或者做的不够好,我想这是目前的窘况,这也给我们测试工作量带来了很大的压力,经常会为了项目按期上线加班加点做回归。同时,也有些公司在区分单元测试和集成测试策略和范围时就比较模糊,本应该单元测试解决的放到集成测试了,甚至是单元测试就按照集成测试的思路来做的,包含了很多业务很细的case,那么就成立下面这种情况,而且更多的就是这样的现状:

    1

    单元和集成测试并行开展
    单元测试更侧重于逻辑代码片段,粒度更细,可能不同的开发人员各自写自己那部分的方法,自己做方法的单元测试,若需要调用别人代码或被调用时,就自己写桩或者驱动函数,把对应的内容mock掉。单元测试不应该关注上层侧重业务的case,也就是说每个user story应该只有少量的case用来做集成测试,把更细粒度的case应该放到单元测试中去做,这样可以避免单元测试和集成测试的重复性工作,为了达到这样很好的组合,就需要开发与测试同学密切配合,提前设计好产品并有文档化的设计资料。如果单元测试和集成测试能很好的区分并且履行好各自职责的话,这对于产品的质量一定能带来非常积极的作用。
    那问题来了:
    1)这样会不会延长项目周期呢?
    在前期,框架不完善,大家对项目都不熟悉的情况下,要想做起来,必然会增加一定工期的,但是在各方面都比较成熟之后,特别是自动化case达到一定量之后,就会缩短项目工期。
    2)如果单元测试开展的不够好怎么办?
    我想,在目前大多数互联网公司,甚少有把单元测试做的好的,并且迫于较低的测试开发比,测试人员根本没有精力来做单元测试,那在这种情况下,测试人员要想进一步保证代码质量的话,就只有通过设计评审,静态代码扫描和code reivew来保证方法的质量,而测试人员可以把精力放到集成测试或接口测试上,只不过这个时候集成测试就需要把更多更细的case包含进去。

    面对现实,随机应变
    最后我们不得不无奈的面对现实,如果真的没办法实现正三角形模型的测试架构的话,也不用过于学术化非要按照模型来做,但我们也要竭力避免让系统测试成为我们最大的工作量和包袱。应Google的一句话,大意是当软件产品没有bug的时候,说明它发布的晚了。这也指我们对于产品质量所做的一定妥协,为了业务快速往前,我们何不因此而变呢?

     

    转载于:https://www.cnblogs.com/yuanchunli/articles/5144463.html

    展开全文
  • 在我们的工作中,为了提高测试效率或者做出测试团队的业绩来,都不得不很多的自动化,当然这包括测试环境搭建,测试数据构造,测试执行,压力及安全测试等等,但是在各个阶段中,应该怎么样做好自动化满足我们的...

    在我们的工作中,为了提高测试效率或者做出测试团队的业绩来,都不得不做很多的自动化,当然这包括测试环境搭建,测试数据构造,测试执行,压力及安全测试等等,但是在各个阶段中,应该怎么样做好自动化满足我们的业务发展需要呢?今天主要谈谈单元和集成测试。

    自动化投入产出比

    一个被简化的公式:

    自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

    或者如果假设迭代次数和维护次数近视相等,这个在某些情况下可以成立,比如一个比较新的产品:

    自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本

    对此公式,我们可以解读一下:

    • 自动化的收益与迭代次数成正比;

    • 自动化收益可能为负,即维护成本和首次自动化成本比全手工执行成本还高的时候;

    • 很多时候首次自动化成本并不比手工测试成本高,但是维护成本很高.

    实际上,这个公式的确被简化了,原因是只是关注了其付出的时间,忽略了带来的效果,比如给项目周期缩短上带来的成效,对于质量保障的成效等等,对于项目周期上的评判则可以用以下公式:

    缩短周期=手工测试时间-自动化测试时间

    而且该周期都是针对同一个已经被自动化的模块评估的.

    此外,很多时候我们关注自动化对于质量的贡献时,都是关注其发现了多少个bug,实际上自动化并不能帮我们发现更多的bug,都只是在原先预先设定好的程序上重复执行,所以根本不可能做到100%的自动化,测试人员的经验,逻辑判断和探索性的测试方法都不能被有效自动化.

    什么样的项目适合做自动化?

    通过上面的公式也可以看出:

    • 一个快速发展,变更频繁的项目不适合做过多的自动化,而处于后期维护阶段,自动化收益会更高;

    • 对于接口类的产品;

    • 手工测试非常费时费力,甚至无法达到测试目的的项目,比如对于大数据量大并发下的压力测试等.

    什么时候介入?

    如果对于早期,开发设计还未稳定,界面还会经常变化,接口还未明确的情况下,是不适合做自动化的,即使做了,也会频繁的修改,这个时候手工测试可能效率更高,能快速发现问题反馈给开发人员.而如果有了稳定的界面,明确的接口设计,明确的数据结构之后,自动化再介入可以自动化收益.

    今天我们重点介绍一下单元测试,集成测试部分.

    谁来写单元测试

    在一个软件工程团队里,的确没有必要明确到底应该谁来写,比较好的做法是依据团队人员配置而定.单元测试普遍采用白盒测试的方法,离不开深入理解被测对象的代码,同时还需要构造驱动模块、桩函数,因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑,开发人员具有一定的优势,其最大的优点是快速,且能更好的实现。

    但是从单元测试效果的角度考虑,保证测试组参与单元测试也有其优势,这是因为:

    首先,从目前国内企业普遍现状来看,测试人员质量意识要高于开发人员,测试人员参与单元测试能够提高测试质量。

    其次,对被测系统越了解,测试才有可能越深入,测试人员参与单元测试,将使得测试人员能够从代码级熟悉被测系统,这对测试组后期集成测试和系统测试活动非常有帮助,可以很快速的评估影响范围,进而可以非常准确的制定回归测试策略,而不用满盘回归.

    测试组以何种方式参与单元测试,应该结合人员配置情况来定。如果软件组织测试资源充分,测试人员对开发人员的比例较高,那么可以由测试人员独立承担部分重要模块的单元测试工作,比如微软这样的公司,开发测试比1:1,那么测试人员就需要进行较为充分的单元测试;如果测试资源不足,测试人员对开发人员的比例较低,那么单元测试的实现和执行由开发人员来完成,但测试组至少应该参与开发组的各相关设计文档评审,以及code review保证质量。

    单元测试的现状

    可以把这种现状结合业务情况来看分为两种:

    1)在业务快速发展迭代频繁的团队,追求高覆盖的单元测试是一件奢侈而且不可取的事情,毕竟把单元测试做好的话可能需要写比开发代码还要多的测试代码,这就需要持续的投入,包括人力和时间上,这也就是为什么微软有那么多测试同学的原因,对于传统软件而言可能值得这样的投入,也就是软件测试工程中的正三角模型。


    2)而互联网时代,短平快是赢得市场的重要理念,为了获得快速的迭代,大家都没有过度的追求单元测试的覆盖率,但是我了解到在百度一些产品线,迭代并不频繁的项目,还是有强制要求对单元测试的覆盖率的,不达到标准是需要打回给开发继续完善单测的,但是我们大多数公司要么是开发一点都不做或者做的不够好,我想这是目前的窘况,这也给我们测试工作量带来了很大的压力,经常会为了项目按期上线加班加点做回归。同时,也有些公司在区分单元测试和集成测试策略和范围时就比较模糊,本应该单元测试解决的放到集成测试了,甚至是单元测试就按照集成测试的思路来做的,包含了很多业务很细的case,那么就成立下面这种情况,而且更多的就是这样的现状:


    单元和集成测试并行开展

    单元测试更侧重于逻辑代码片段,粒度更细,可能不同的开发人员各自写自己那部分的方法,自己做方法的单元测试,若需要调用别人代码或被调用时,就自己写桩或者驱动函数,把对应的内容mock掉。单元测试不应该关注上层侧重业务的case,也就是说每个user story应该只有少量的case用来做集成测试,把更细粒度的case应该放到单元测试中去做,这样可以避免单元测试和集成测试的重复性工作,为了达到这样很好的组合,就需要开发与测试同学密切配合,提前设计好产品并有文档化的设计资料。如果单元测试和集成测试能很好的区分并且履行好各自职责的话,这对于产品的质量一定能带来非常积极的作用。

    那问题来了:

    1)这样会不会延长项目周期呢?

    在前期,框架不完善,大家对项目都不熟悉的情况下,要想做起来,必然会增加一定工期的,但是在各方面都比较成熟之后,特别是自动化case达到一定量之后,就会缩短项目工期。

    2)如果单元测试开展的不够好怎么办?

    我想,在目前大多数互联网公司,甚少有把单元测试做的好的,并且迫于较低的测试开发比,测试人员根本没有精力来做单元测试,那在这种情况下,测试人员要想进一步保证代码质量的话,就只有通过设计评审,静态代码扫描和code reivew来保证方法的质量,而测试人员可以把精力放到集成测试或接口测试上,只不过这个时候集成测试就需要把更多更细的case包含进去。

    面对现实,随机应变

    最后我们不得不无奈的面对现实,如果真的没办法实现正三角形模型的测试架构的话,也不用过于学术化非要按照模型来做,但我们也要竭力避免让系统测试成为我们最大的工作量和包袱。应Google的一句话,大意是当软件产品没有bug的时候,说明它发布的晚了。这也指我们对于产品质量所做的一定妥协,为了业务快速往前,我们何不因此而变呢?

    文章同步发布在我的个人博客:www.oktest.me上,可点击进入查看,同时收录全网海量测试相关文章,欢迎阅读。


    展开全文
  • 为了提高重用性开发了面向对象的程序设计语言,如Simlasa等;为了避免产生不正确的需求理解,开发形式化描述语言,如HAL/S等,这使得建立基于自然语言的描述成为可能,人们以形式化语言来描述需求;为了支持大型...
  • 作为第二个请求的参数进行传参,但是有时候为了提高测试效率,尽可能制造少的测试数据,我们需要从上一个请求的响应结果中获取某一组相同类型的值作为参数进行传递,此时,应该怎么做呢?应用场景:步骤一:首先执行...

    前言:大多数情况下,我们会从上一个请求的响应结果中提取某一个值,作为第二个请求的参数进行传参,但是有时候为了提高测试效率,尽可能制造少的测试数据,我们需要从上一个请求的响应结果中获取某一组相同类型的值作为参数进行传递,此时,应该怎么做呢?

    应用场景:

    步骤一:首先执行一个全局查询,查询出所有的值;

    步骤二:提取出来步骤一的所有值的ID值,并作为参数传递给第二个请求,依次查询每一个ID的详细信息。

    解决思路:

    思路一:直接使用正则表达式提取器将提取结果直接传给第二个请求;

    思路二:把提取的值取出来保存为csv,然后对第二个请求参数化,去读取这个csv的值(尚未研究如何保存提取的值);

    思路一解决方案:

    1.首先当然是前提步骤,需要执行第一个请求,并查看所有的响应结果:

    d4270c2e61ff27ee26a67336876599f0.png

    2.因为第二个请求中,我们需要将上述响应结果中的ID值作为参数进行传递,因此此时需要添加正则表达式提取器将结果进行提取

    103c538e7779096a60511c567b25d833.png

    正则表达式进行如下设置:

    4cc1e0dc6357b8ad7f5dd3644e0ae721.png

    此时存在问题:运行完成后,发现第二次请求中参数处取值为null。

    或者他永远只能取到响应结果中的第一个值,不能获取所有的值。

    这显然不是我们想要的结果,通过与飞测小伙伴沟通后,需要添加一个元件,即ForEach控制器,即可有效结果此问题,因此进行如下改进:

    de59d1225b15125df5c434098857b521.png

    5924eb1f2541474f2caefb96ca8b1230.png

    a7611a36621d92f7d03f88af5a32e550.png

    运行后,结果如下:

    6807d092020ea8eaa630bc4e17a53304.png

    至此,完美解决我们上述遇到的问题!

    操作过程遇到的坑:

    坑一:正则匹配有误

    响应结果为:

    42c768e8bc025d71633711218168cb5a.png

    但是正则表达式为:

    3b943e592996d3dcec2ad3c60b594e50.png

    如此就会匹配出来一些我们不需要的值。

    改进:做如下改进,即可获得正确的值:

    6e18d9625bfc92671c69a108f973976e.png

    学习:

    43c3842ce4f14a45768b0ee0f31a166d.png

    坑二:依次读取响应数据,读取失败

    改进:添加ForEach控制器解决。

    学习:

    e7b489bad4ed4716c7cf48d840366ee6.png

    参数:

    Input Variable Prefix:输入变量前缀,本例中为:param

    Output variable name:输出变量名称,提供给其它控件引用

    Start index for loop(exclusive):循环开始的索引(默认从0开始,如果填写是2,实际是从2+1个开始执行)

    End index for loop(inclusive):循环结束的索引(默认从0开始,如果填写是2,实际是从2+1个开始执行)

    Add””before number:输入变量名称中是否使用“”进行间隔。

    展开全文
  • 作为第二个请求的参数进行传参,但是有时候为了提高测试效率,尽可能制造少的测试数据,我们需要从上一个请求的响应结果中获取某一组相同类型的值作为参数进行传递,此时,应该怎么做呢? 应用场景: 步骤一:...

     

    前言:大多数情况下,我们会从上一个请求的响应结果中提取某一个值,作为第二个请求的参数进行传参,但是有时候为了提高测试效率,尽可能制造少的测试数据,我们需要从上一个请求的响应结果中获取某一组相同类型的值作为参数进行传递,此时,应该怎么做呢?

     

    应用场景:

    步骤一:首先执行一个全局查询,查询出所有的值;

    步骤二:提取出来步骤一的所有值的ID值,并作为参数传递给第二个请求,依次查询每一个ID的详细信息。

     

    解决思路:

    思路一:直接使用正则表达式提取器将提取结果直接传给第二个请求;

    思路二:把提取的值取出来保存为csv,然后对第二个请求参数化,去读取这个csv的值(尚未研究如何保存提取的值);

     

    思路一解决方案:

     

    1.首先当然是前提步骤,需要执行第一个请求,并查看所有的响应结果:

     

    2.因为第二个请求中,我们需要将上述响应结果中的ID值作为参数进行传递,因此此时需要添加正则表达式提取器将结果进行提取

     

     

    正则表达式进行如下设置:

     

     

    此时存在问题:运行完成后,发现第二次请求中参数处取值为null。

    或者他永远只能取到响应结果中的第一个值,不能获取所有的值。

     

    这显然不是我们想要的结果,通过与飞测小伙伴沟通后,需要添加一个元件,即ForEach控制器,即可有效结果此问题,因此进行如下改进:

     

     

     

     

    运行后,结果如下:

     

     

    至此,完美解决我们上述遇到的问题!

     

    操作过程遇到的坑:

    坑一:正则匹配有误

    响应结果为:

     

     

    但是正则表达式为:

     

     

    如此就会匹配出来一些我们不需要的值。

    改进:做如下改进,即可获得正确的值:

     

     

     

    学习:

     

     

    坑二:依次读取响应数据,读取失败

    改进:添加ForEach控制器解决。

    学习:

     

     

    参数: 

    Input Variable Prefix:输入变量前缀,本例中为:param

    Output variable name:输出变量名称,提供给其它控件引用 

    Start index for loop(exclusive):循环开始的索引(默认从0开始,如果填写是2,实际是从2+1个开始执行) 

    End index for loop(inclusive):循环结束的索引(默认从0开始,如果填写是2,实际是从2+1个开始执行) 

    Add””before number:输入变量名称中是否使用“”进行间隔。 

    注:原创,转载请说明出处!

    转载于:https://www.cnblogs.com/diqitian/p/7249895.html

    展开全文
  •  第一:XML肯定是未来的发展趋势,不论是网页设计师还是网络程序员,都应该及时学习和了解,等待只会让你失去机会;  第二:新知识肯定会有很多新概念,尝试理解和接受,您才可能提高。不要害怕和逃避,毕竟我们...
  • 记得刚产品的时候,不知道交互规则怎么写,应该写哪些内容,自己输出的交互规则经常会落下一些细节,最后技术开发出来的产品也没有注意到那个地方,测试也没有发现这个问题。在验收产品的时候,才发现这么普遍的...
  • 本人目前就读重庆某软件学院软件测试专业,将于2013年1月底毕业,为了扎实基础,于是有时间就会找一些源码研究,有时候想走走捷径,提高效率,于是开始找一些代码审计的工具,但是目前国内貌似没有发现专业的这类...
  • 测试(发现并改正错误,分为模块测试、集成测试和系统联调三级); ● 运行维护(扩充功能、纠错等)。 习题二答案 一、 选择题 1. 需求分析的主要目的是(B C)。 A) 系统开发的具体方案 B) 进一步确定用户的...
  • 同理,为了提高读取日志的效率,读取的buffer也设置了10k,也需要根据你日志的大小适当调整。 索引的读写设置成了行buffer,每满一行都要flush到磁盘上,防止读到不完整的索引行(其实实践证明,设置了行buffer,...
  • c语言编写单片机技巧

    2009-04-19 12:15:17
    为了保证IC生产的长期且稳定品质,还会产品的可靠性测试,这些测试包括ESD测试,LATCH UP测试,温度循环测试,高温贮存测试,湿度贮存测试等。 成测则是产品封装好后的测试,即PACKAGE测试。即是所有通过...
  • 主要目的是用来信息的展示和传播。这个时候开发一个网页也很容易,主要就是通过 JSP、PHP 等技术写一些动态模板,然后通过 Web Server 将模板解析成一个个 HTML 文件,浏览器只负责渲染这些 ...
  • 另外项目描述中,最好可以体现自己的综合素质,比如你是如何协调项目组成员协同开发的或者在遇到某一个棘手的问题的时候你是如何解决的又或者说你在这个项目用了什么技术实现了什么功能比如:用 redis 缓存提高访问...
  • 3、 了解在嵌套循环结构中,提高程序效率的方法 4、 本实验应在学习了教材第3.3.4进行 [实验内容与步骤] 实验题目:下面是一个循环结构 的C程序。 main() { int i ,j; long sum=0; for(i=1,i,i++) for(j=1;j;j++) ...
  • 小日本视频转换器

    2011-11-07 16:03:30
    裁剑画面:由于电视机播放视频的时候对边缘四周的部分舍弃,所以可以利用这一点只对可见部分进行编码,这样可以加快编码速度,并且因为节省的码率可以利用在未裁剪区域从而提高画面质量。一般来说对上下左右各裁剪...
  • 1、提高鼠标移动运行效率 2、解决PROTEL侧边栏滚轮BUG 3、增加PROTEL99SE原理图右键移动功能 4、支持powerlogic 5、支持BlazeRouter 第二版(2.0)说明: 本软件是部分EDA软件的鼠标增强工具,将EDAHelper.exe和...
  • 1.3.5 怎么能让应用运行得更快 42 1.3.6 DBA与开发人员的关系 44 1.4 小结 45 第2章 体系结构概述 46 2.1 定义数据库和实例 47 2.2 SGA和后台进程 52 2.3 连接Oracle 54 2.3.1 专用服务器 54 2.3.2 共享...
  • 在外地紧急项目住宿也尽量好一些,休息好了,才能干好工作,有时候有个良好的环境,工作起来效率也高,而且有个安静,干净的,网络畅通的办公环境,加班也效率高。 13:电话费就别想省了,我们开发人员总有...
  • 1.3.5 “怎么能让应用运行得更快?” 41 1.3.6 DBA与开发人员的关系 45 1.4 小结 46 第2章 体系结构概述 47 2.1 定义数据库和实例 48 2.2 SGA和后台进程 53 2.3 连接Oracle 56 2.3.1 专用服务器 56 2.3.2 ...
  • (3) cFos/cFosSpeed 执行「clear calibration data」(我灌的是日文版, 英文应该是这样的字, 中文应该是清除校正数据等意思) (4) 纯粹全速下载!! 最好的方法就是找个大档案下载 (千万别用 P2P, 因为会动到大量上传),...
  •  14、裁剑画面:由于电视机播放视频的时候对边缘四周的部分舍弃,所以可以利用这一点只对可见部分进行编码,这样可以加快编码速度,并且因为节省的码率可以利用在未裁剪区域从而提高画面质量。一般来说对上下左右...
  • 为了进行数据库异常测试,于是将数据库内容人为地破坏了。发现在对数据库进行比较操作时,出现程序跑死了现象。 经过跟踪调试发现问题出现在如下一段代码中: 1 for(i=0; i<pSysHead->dbf_count; i++) 2 { 3 ...
  • MySQL索引凭什么让查询效率提高这么多? 你都是如何设计索引的? 数据库自增ID用完了会怎么样? MySQL大表怎么DDL变更 innodb是如何插入数据的? MySQL的索引是怎么加速查询的? 数据库索引 MySql主从复制,从原理到...
  • 《你必须知道的495个C语言问题》

    热门讨论 2010-03-20 16:41:18
    3.14 如果我不使用表达式的值,那我应该用i++还是++i来自增呢? 39 3.15 我要检查一个数是不是在另外两个数之间,为什么if(a b c)不行? 40 3.16 为什么如下的代码不对?int a=1000, b=1000; long int c=a * ...

空空如也

空空如也

1 2 3
收藏数 55
精华内容 22
关键字:

为了提高测试效率应该怎么做