第二十二章 开发者测试
- 单元测试是将一个程序员或者一个开发团队所编写的，一个完整的类、子程序或者小程序，从完整的系统中隔离出来进行测试；
- 组件测试是将一个类、包、小程序或者其他编程元素，熊一个更加完整的系统中隔离出来进行测试，这些测试代码涉及到多个程序员或者多个团队；
- 集成测试是对两个或更多的类、包、组件或者子系统进行的联合测试，这些组件由多个程序员或者开发团队所创建。这种测试通常在有了两个可以进行测试的类的时候就应该尽快开始，并且一直持续到整个系统开发完整。
- 回归测试是指重复执行以前的测试用例，以便在原先通过了相同测试集合的软件中查找缺陷；
- 系统测试是在最终的配置下运行整个软件。以便测试安全、性能、资源消耗、时序方面的问题，以及其他无法在低级集成上测试的问题。
开发者测试在软件质量中的角色
- 测试的目标与其他活动背道而驰，测试的目标是找出错误；
- 测试永远不可能彻底证明程序中没有错误；
- 测试本身不能改善软件的质量；
- 测试时要求你假设会在代码中找到错误。
开发者测试的推介方法
- 对每一项相关的需求进行测试，以确保需求都已实现；
- 对每一个相关的设计关注点进行测试，以确保设计已被实现；
- 用基础测试来扩充针对需求和设计的详细测试用例；
- 使用一个检查表，其中记录着你在本项目迄今位置所犯的，以及在过去的项目中所犯的错误类型。
测试先行还是测试后行
- 在开始写代码之前先写测试用例，并不比之后再写要多花功夫，只是调整了一下测试用例编写活动的工作顺序而已；
- 假如你首先编写测试用例，那么你将可以更早发现缺陷，同时也更容易修正它们；
- 首先编写测试用例，将迫使你在开始写代码之前至少思考一下需求和设计，而这往往会催生更高质量的代码；
- 在编写代码之前先编写测试用例，能更早地把需求上的问题暴露出来，因为对于一个糟糕的需求来说，要写出测试用例是一件困难的事情；
- 如果你保存了最初编写的测试用例——这是你应该做的，那么先进性测试并非唯一选择，你仍然可以最后再进行测试。
开发者测试的局限性
- 开发者测试倾向于干净测试；
- 开发者测试对覆盖率有过于乐观的估计；
- 开发者测试往往会忽略一些更复杂的测试覆盖率类型。
测试技巧锦囊
由于进行完全测试实际上是不可能的，因此测试的敲门就在于选择那些最有可能找到错误的测试用例。
结构化测试的思想是，你需要去测试程序中的每一条语句至少一次。
- 结构化的基础测试；
- 数据流测试；
- 等价类划分；
- 猜测错误；
- 边界值分析；
- 几类坏数据；
- 数据太少；
- 数据太多；
- 错误的数据；
- 长度错误的数据；
- 未初始化的数据。
- 几类好的数据；
- 正常的情形；
- 最小的局面；
- 最大的局面；
- 与旧数据的兼容性。
- 采用容易手工检查的测试用例；
典型错误
不完善的构建过程引发错误所占的比例
- 小型项目里面，构件中的缺陷占了所有错误的大多数；
- 无论项目规模如何，构建缺陷至少占了总缺陷的35%；
- 修正构建错误的代价虽然要比修正需求和设计的错误相对低廉，但从绝对值来看仍然是高昂的。
测试本身的错误
你可以通过下列几项工作来减少测试用例当中的错误量：
- 检查你的工作；
- 开发软件的时候要计划好测试用例；
- 保留你的测试用例；
- 将单元测试纳入测试框架；
测试支持工具
- 为测试各个类构造脚手架；
- Diff工具；
- 测试数据生成器；
- 覆盖率监视器；
- 数据记录器/日志记录器；
- 符号调试器；
- 系统干扰器；
- 错误数据库。
改善测试过程
- 有计划的测试；
- 回归测试；
- 自动化测试。
保留测试记录
为了评估整个项目，你需要手机下列集中数据：
- 缺陷的管理方面描述（报告日期、报告人、描述或标题、生成编号以及修正错误的日期等）；
- 问题的完整描述；
- 复现错误所需要的步骤；
- 绕过该问题的建议；
- 相关的缺陷；
- 问题的严重程度——例如致命的、严重的还是表面的；
- 缺陷根源：需求、设计、编码还是测试；
- 对编码缺陷的分类：off-by-one错误、错误赋值、错误数组下标，以及子程序调用错误等；
- 修正错误所改变的类和子程序；
- 缺陷所影响的代码行数；
- 查找该错误所花的时间；
- 修正该错误所花的时间。
一旦你收集到了这些数据，你就可以对其中部分细节细加思考，从而判断项目是想着更健康，还是更糟糕的趋势发展。
- 每一个类中的缺陷数目，从最糟糕的类到最好的类依次列出，如果类的规模不同，可能要对这一数字进行归一化处理；
- 按照同样的方式列出每个子程序中的缺陷数，也可能需要根据子程序的大小归一化处理；
- 发现一个错误平均所需要花费的测试时间；
- 每个测试用例所发现缺陷的平均数；
- 修正一个测试用例的代码覆盖率；
- 在各个严重级别中未处理缺陷的数量。
核对表：测试用例
要点
- 开发人员测试时完整测试策略的一个关键部分；
- 同编码之后编写测试用例相比较，编码之前编写测试用例，工作量和花费的时间差不多，但是后者可以缩短缺陷-侦测-调测-修正这一周期；
- 即使考虑到了各种可用的测试手段，测试仍然只是良好软件质量计划的一部分；
- 你可以根据各种不同的思路来产生很多测试用例，这些思路包括基础测试、数据流分析、边界分析、错误数据类型以及正确数据类型等；
- 错误往往集中在少数几个容易出错的类和子程序上；
- 测试数据本身出错的密度往往比测试代码还要高；
- 自动化测试总体来说是很有用的，也是进行回归测试的基础；
- 从长远来看，改善测试过程的最好办法就是将其规范化，并对其进行评估，然后用从评估中获得经验叫徐来改善这个过程。
