测试是为发现错误而执行程序的过程。
破坏性过程。心理学和经济学。
软件测试的对象包括：程序、数据、文档。目标程序和源程序都属于程序。
软件测试的原则
- 测试用例中一个必需部分是对预期输出或结果的定义。
- 对程序的输入数据的描述。
- 对程序在上述输入数据下的正确输出结果的精确描述。
防止某个似是而非而实际错误的结果被解释成正确结论。
- 程序员应当避免测试自己编写的程序。
- 编写软件的组织不应当测试自己编写的软件。
- 应当彻底检查每个测试的执行结果。
- 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
- 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
- 应当避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
- 交互式系统测试时较为常见。
- 保留测试用例，当程序其他部件发生更动后重新执行，即“回归测试”。
- 计划测试工作时不应默许假定不会发现错误。
- 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
- 错误总是倾向于聚集存在。
- 软件测试是一项极富创造性、极具智力挑战性的工作。
代码检查、走查与评审
人工测试方法：代码检查、走查以及可用性测试。
- 利用错误列表进行代码检查。
- 小组代码走查。
- 桌面检查。
- 通话评审。
同行评审
依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。
软件测试计划评审会需要有 项目经理、客户(可选)、配置管理员、测试经理、开发组长等人的参加。
测试用例的设计
最关键问题：在所有可能的测试用例中，哪个子集最有可能发现最多的错误？
测试用例是测试程序正确性与否的关键。
白盒测试
逻辑驱动的测试。白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。完全的白盒测试是将程序中的每条路径都执行到，然而对带有循环的程序来说，并不现实。
逻辑覆盖测试
- 语句覆盖：可执行语句至少被执行一次；
必要条件，最弱的准则。语句原本的写法有误，无法检测？ - 判定覆盖或分支覆盖：每个判断的取真分支和取假分支至少经历一次；每条分支路径都必须至少遍历一次；每个入口点都必须被至少调用一次。
可以满足语句覆盖。 - 条件覆盖：每个条件的取值至少满足一次；
- 判定/条件覆盖：判断和条件都满足；将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能结果至少执行一次，将每个入口点都至少调用一次。
- 条件组合覆盖（多重条件覆盖）：每个条件的所有可能都至少出现一次，并且判定结果至少出现一次 ；
与条件覆盖的区别：不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次； - 路径测试：执行所有可能的执行路径；
- 基本路径测试：路径测试执行了每个路径，每个判定的结果肯定经历过一次。
黑盒测试
数据驱动测试，输入/输出驱动的测试，不需要了解程序内部的结构。
- 等价划分
- 边界值分析
边界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值，记为：min、min+、nom、max-、max。考虑到健壮性测试，还可以加一个略大于最大值max+，以及一个略小于最小值min-的值。 - 因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
边界值法既可以用于黑盒测试用例，也可以用于白盒测试用例。
错误猜测
模块（单元）测试
系统集成测试主要包括以下过程：1. 构建的确认过程。 2. 补丁的确认过程。 3. 系统集成测试测试组提交过程。 4. 测试用例设计过程。 5. 测试代码编写过程。 6. Bug的报告过程。 7. 每周/每两周的构建过程。 8. 点对点的测试过程。 9. 组内培训过程。
更高级别的测试
软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式。由于这个原因，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。
软件开发周期模型：
最终用户->需求->目标->外部规格说明->系统设计->程序结构设计->模块接口规格说明->代码。
可以在每个阶段结束时引入独立的验证过程，以防止一些错误。
开发过程与测试过程一对一的联系：
验收测试->系统测试->功能测试->集成测试->模块测试。
这种结构避免了没有效果的多余测试。
测试顺序不一定是严格的时间顺序。
更高级别的测试最适用于软件产品，而对没有正规需求和目标的程序，功能测试可能是唯一更高级别的测试。
功能测试
试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户角度对程序行为的精确描述。
通常为黑盒操作。（等价类划分、边界值分析法、因果图法、错误猜测法）
系统测试
将系统或程序与其初始目标进行比较。
最难进行的测试。
- 系统测试并不局限于系统。如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。
- 根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。
测试用例设计依据：程序的用户文档或书面材料。
系统测试用例
- 能力测试：确保程序的目标功能实现
- 容量测试：发现处理大容量数据时的程序异常
- 强度测试：发现在大规模负载、高强度不间断持续的数据处理中的异常
- 可用性测试：评估最终用户在使用软件并与软件交互时的可用性问题
- 安全性测试：试图攻破程序的安全防线
- 性能测试： 评估程序的响应时间以及吞吐量瓶颈
- 存储测试： 确保程序可以证券处理其对存储的要求，包括系统的存储和物理上存储
- 配置测试： 检查程序是否能在推荐配置上流畅运行
- 兼容性/转换测试： 评估新版本是否能兼容老的版本
- 安装测试： 确保能够在所有支持的平台上安装软件
- 可靠性测试：评估程序是否能达到规格说明中的运行时常和MTBF（平均故障间隔时间）要求
- 可恢复性测试：测试系统恢复相关的功能是否按设计要求实现
- 服务/可维护性测试：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需
- 文档测试： 检验所有的用户文档是否准确
- 过程测试： 对软件系统操作或维护所需涉及的流程进行评估和确定
验收测试
将程序与其最初的需求及最终用户当前的需要进行比较的过程。
原则上由程序的客户或最终用户来进行。
软件验收测试分为三类：
正式验收测试；
非正式验收测试：α测试（由用户、测试人员、开发人员共同参与的内部测试。） ，β测试（内测后的公测，即完全交给最终用户测试。）。
安装测试
测试结束的准则
- 用完了安排的测试时间后，测试便结束。
- 当执行完所有测试用例都未发现错误，测试便结束。
以上两种都是不可取的。
三类较为有用的结束准则
- 根据特定的测试用例设计技术。
模块测试结束准则：
测试用例来源于（1）满足多重条件覆盖准则，（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。
功能测试结束准则：
测试用例来源于（1）因果图分析，（2）边界值分析，（3）错误猜测，产生的所有测试用例最终都是不成功的。
以上方法问题在于：对没有特定方法的测试阶段，如系统测试阶段仍不起作用。依赖于主观度量。没有设定目标。 - 以确切的数量来描述结束测试的条件。
- 在测试过程中记录每单位时间内发现的错误数量。通过检查统计曲线的形状，决定继续进行测试还是终止测试。
可用性（或用户体验）测试
基本上属于黑盒测试。
可用性测试流程
- 测试用户的选择
- 需要多少用户测试
- 数据采集方法
- 可用性调查问卷
- 何时手工，还是多多益善
调试
- 确定程序中可疑错误的准确性质和位置；
- 修改错误。
暴力法调试
- 利用内存信息输出来调试。
- 根据一般的“在程序中插入打印语句”建议来调试。
- 使用自动化的调试工具进行调试。
归纳法调试
演绎法调试
敏捷开发模式下的测试
围绕以用户为中心，以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备。
客户是敏捷的关键环节。
特征：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
敏捷开发方法：
敏捷建模
敏捷统一过程
动态系统开发方法
核心统一过程（EssUP）
极限编程（eXtreme Programming，XP）
功能驱动开发（FDD）
开放统一过程
Scrum进度跟踪
一些补充
- 针对手机应用软件的系统测试，我们通常从如下几个角度开展：功能模块测试，交叉事件测试，压力测试，容量测试，兼容性测试，易用性/用户体验测试等。
对手机可以施加的压力测试类型主要有：存储压力、边界压力、 响应能力压力、网络流量压力。 - 测试的分类：
- 人工测试：如个人复查，抽查和会审等；机器自动测试；
- 按照否关软件内部结构具体实现角度：A.白盒测试B.黑盒测试 C.灰盒测试
- 按照软件发程按阶段：A.单元测试 B.集测试 C.确认测试 D.系统测试 E.验收测试
- 做好文档测试需要注意的点有哪些?
仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例；
检查文档的编写是否满足文档编写的目的；
内容是否齐全，正确，完善；
标记是否正确。 - 缺陷分两种：
- 完全影响软件的正常运行或者影响客户的正常体验。
这种当然不能予以通过。 - 不影响产品运行及客户正常体验且此软件急于使用。
以公司利益为出发，应予以通过。但在时间不紧急的情况下应不予通过。
一个好的测试人员应该有很好的情况分析能力，并且要有担当。
- 单元测试能发现约80%的软件缺陷。
- 常用工具总结。
LoadRunner-负载压力测试：预测系统性能。预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制。
功能测试： 通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。QTP(quicktest professional):自动测试工具。
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试），针对代码测试。
测试管理工具：对测试需求、计划、用例、实施进行管理。
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备。
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN
网友评论