l软件测试的提升.docVIP

软件测试的提升 作者：哈哈猪 （本来是想写一些对测试人员提升的方法的，后来写着写着跑题了，大家见谅哈，嘿嘿） 前段时间遇到了一个问题，软件测试如何提升？后来我自己思索了一下，有一些不成熟的想法，在这里给大家分享一下。 总体而言，软件测试是一个比较新的职业，软件测试的发展、提升还没有比较成熟的理论。本篇文档也是个人的一些经验总结，希望可以对软件测试的同事有所帮助和启发。 我将软件测试的提升分为四个主要方向，分别是测试基本技能，自动化测试，测试工具，测试文档。 第一篇 测试基本技能 对一个软件测试工程师而言，测试计划，用例设计，测试执行，测试总结，测试评审这些是基本工作，也是最重要的技能。 1 测试计划 测试计划是对软件测试工程师比较重要的一个技能，主要是考察软件测试工程师的项目规划能力。只要注意到了以下几个方面，就可以做出一份比较成功的测试计划。（此项在公司现有的测试计划模板中有明确指出，这里不再赘述） A 测试目的 B 测试范围 C 测试方法 D 测试资源（人力和仪器） E 测试时间 F 测试风险 2 用例设计 测试用例的设计，是现在整个测试行业绞尽脑汁进行优化，规范化，效率化的地方。公司内部也引进推广过一些业界内部常用的工程方法：错误推测法，因果图法，功能图法，正交分析法，平时使用较多的可能是功能图法和正交分析法，一个比较关注独立功能的模块，一个适用于交互功能的模块。 现在，我们自己设计用例的瓶颈是在扩展思路这一块。我们现在的用例模式，一般都比较侧重于功能的单独实现，用例比较分散，功能实现比较独立。这样的用例，功能点都涉及到了，只针对功能点来说的话，我们的用例是全面的。 但是按照这样的用例进行一次全面测试，我们仍然能发现，从用例测试发现的bug，与用例数量的比例并不能令人满意。也就是说，我们的用例“全面性”只是体现在了表面上，一些复杂的，深入的用例还是没有包括进来，我觉得缺少的用例部分应该是如下这些方面： 第一，关于流程方面的用例没有包含全，有可能单独的功能都是OK的，但是如果两个功能有先后使用关系，就有可能出现问题，例如：压扩扰频两个功能单独使用都是好的，而先开启关闭压扩，再开启扰频，可能就会出现问题。 第二，包含多个测试点的，例如，将带亚音的信道和不带亚音的信道加在一个扫描列表中，有可能就不会再扫描亚音。 第三，功能嵌套类的，例如，在单独工作中启动VOX，是否正常。 第四，特殊使用场景的，例如，在使用中关机。 上述的这些问题，如果是针对修改的话其实也不是没有思路，按照现在已知的用例设计方法分别是：因果图法、功能图法、正交法、错误推测法（说是场景法也可以），就可以进行改进。 但是，个人认为，仅仅是掌握了一些用例设计方法，就想编写出一份高质量的用例，还是不够的。这个从我们现在的用例就可见一斑。我觉得，在现阶段，模板和流程对用例编写所起到的作用也许会更大。 首先，所谓的模板，就是用例的架构需要一个模板，这个模板可以这样分：基本功能，高级功能（本模块内部的交互和流程先后），交互（与其他模块的），场景法设计（使用场景模拟），问题收集（包括TD以前的问题，客户反馈的问题，公司内部反馈的问题）等五个部分。举个简单的例子： 基本功能 alert call 单独功能实现 select call 单独功能实现 高级功能 alert call 优先级（发解码的先后顺序） select call 交互 扫描 扫描中发解码 场景使用 客户使用习惯，是否挨着身体发射 有的机器爱着人体发射，功率会降低一半 问题收集 扫描中解码成功率低 设置优先信道或者将预载波设置长一些可解决问题 如果用例的构架订好了模板，那么用例编写也就订好了模板。 其次，就是流程方面，需要增加两个评审点，第一个就是用例构架完成后，需要对构架进行评审，这时候的评审，需要多注意用例的全面性。第二次的评审，是用例完成后的检视评审，这个过程中需要对用例的可读性，可操作性，可验证性（预期结果写的清楚详尽）进行深入的讨论。 用例编写的过程中，评审是一个保证质量重要的关节点。在一定的时间范围内，用例投入的质量与时间是成正比的，用例编写的一些投入，是必需的。 所以，用例的编写，需要内在和外在两方面的努力，内在就是对功能的熟悉，对用例编写方法的掌握，外在的就是定制模板和流程设计。 3 测试执行 许多的软件测试工程师都有自己的测试技巧，但是不管怎么样，下面三点是必须掌握的。 第一，用例执行时的技巧，多个功能点一次测试完毕。因为我们的用例有许多是一类型的放在一起，这样，我们可以一次多看几条用例，而使用一个写频配置完成多个用例测试。 第二，异常情况敏感，任何一点的异常都有可能揪出一个大bug。 第三，测试灵感或者对场景测试的一些模拟。（没有用例的，一定要记得添加用例） 4 测试