软测的基础理论和概念

软件测试概述

软件测试的定义

使用人工或者自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足规定的需求，并找出与预期结果之间的差异

软件测试工程师素质

责任心；沟通能力；团队合作精神；耐心、细心和信心；保持怀疑的态度；有缺陷预防的意识；不断学习的能力

测试工程师的职责

测试人员要了解项目需求内容，从用户的角度提出自己的测试看法
测试人员要编写合理的测试计划，并与项目整体计划有机的整合在一起
测试人员要编写覆盖率高的测试用例；测试人员要认真仔细的实施测试工作，并提交测试报告以供项目参考
测试人员要进行缺陷跟踪和分析

软件测试基础软件的概念

基础软件的分类

按照功能划分：
- 系统软件：如操作系统、数据库管理系统，各种驱动软件等
- 应用软件：如office、金山词霸、QQ等
按照技术结构划分：
- 单机版本：如office、画图工具等
- C/S结构软件：如QQ、MSN等
- B/S结构软件：如新浪、谷歌等

软件测试的分类

软件测试常用分类

按开发阶段划分：单元测试、集成测试、系统测试、验收测试
按测试的实施单位划分：开发方测试、用户测试、第三方测试
按测试技术划分：白盒测试、黑盒测试、灰盒测试
单元测试：又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试：又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
系统测试：指将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
黑盒测试：指的是把被测的软件看做一个黑盒子，我们不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出。因此黑盒测试又叫功能测试或数据驱动测试
白盒测试：指的是把盒子打来，去研究里面的源代码和程序结构，对程序所有逻辑路径进行测试。因此白盒测试又叫结构测试或逻辑驱动测试。
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
验收测试（UAT）：也就是用户验收测试，指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试
Alpha测试：指的是由用户，测试人员、开发人员等共同参与的内部测试
Beta测试：指的是内测后的公测，即完全交给最终用户进行的测试
功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
兼容性性测试：测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行，检验被测软件对其他应用软件或者其他系统的兼容性。
安全性测试：安全测试检测系统对非法入侵的防范能力
UI测试：指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等
性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行
回归测试：指对软件的新版本测试时，重复执行上一个版本测试时的用例。
冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

黑盒测试策略

黑盒测试各方法使用场景举例

等价类：把程序的输入域划分成若干部门，然后从每个部分中选取少数代表性数据作为测试用例。应用场景：用户登陆，非法帐号与合法帐号。
边界值：输入、输出范围的边界。应用场景：列表分页；日期校验。
错误推测：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。应用场景：客户做了某个业务撤销或回滚后，又重新发起业务；2个及以上业务模块间，交互的部分。
判定表：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。应用场景：多条件的组合查询；日期校验。
因果图：用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例。通常输入、输出之间存在依赖关系。应用场景：动态按钮，例如根据行记录的状态显示不同的操作按钮，且各按钮要打开各自对应的页面。
正交试验法：用“正交表”来安排和分析多因素试验的一种数理统计方法。应用场景：输入控件较多的新增、修改页面；参数配置。
场景分析法：用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。应用场景：对于业务流清晰的系统。如客户缴费流程。基本流、分支流、异常流、验证流。
功能图法：使用功能图（如：“状态迁移图”、“流程图”、“菜单树”）形象地表示程序的功能说明，并机械地生成功能图的测试用例。应用场景：黑盒意义上的，对功能或系统水平上实现逻辑覆盖和路径测试。

优化测试用例的方法

测试需求完成以后，可以根据测试需求设计测试用例。要保证测试用例能够全面覆盖测试需求，要包含所有的情况。测试用例设计上划分为单功能测试用例和场景测试设计，单功能测试覆盖需求中的功能点，场景测试覆盖需求中的业务逻辑。
在设计测试用例的时候，可以使用多种测试用例设计方法。
- 首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。
- 必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。
- 可以使用错误推测法追加一些测试用例，这需要依靠智慧和经验。
- 对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。
- 如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。
- 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
- 对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。- 当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。
用例设计套路：确定测试目标（其实就是确定测试用例的粒度）——提取测试元素——分类（其实就是一个整体的等价法）——针对各类进行分析（主要还是使用等价和边界）——正交表生成用例（因果图和判定表也是经常使用的方法）——根据实际测试环境情况删除部分case——增加错误推断和性能测试用例——使用场景法验证覆盖率——生成初步测试用例报告——同行评审——归档。