开发者测试

Posted 2022-11-20 liam-ji

• 单元测试是将一个程序员或者一个开发团队所编写的，一个完整的类、子程序或者小程序，从完整的系统中隔离出来进行测试；
• 组件测试是将一个类、包、小程序或者其他编程元素，熊一个更加完整的系统中隔离出来进行测试，这些测试代码涉及到多个程序员或者多个团队；
• 集成测试是对两个或更多的类、包、组件或者子系统进行的联合测试，这些组件由多个程序员或者开发团队所创建。这种测试通常在有了两个可以进行测试的类的时候就应该尽快开始，并且一直持续到整个系统开发完整。
• 回归测试是指重复执行以前的测试用例，以便在原先通过了相同测试集合的软件中查找缺陷；
• 系统测试是在最终的配置下运行整个软件。以便测试安全、性能、资源消耗、时序方面的问题，以及其他无法在低级集成上测试的问题。

开发者测试在软件质量中的角色

• 测试的目标与其他活动背道而驰，测试的目标是找出错误；
• 测试永远不可能彻底证明程序中没有错误；
• 测试本身不能改善软件的质量；
• 测试时要求你假设会在代码中找到错误。

开发者测试的推介方法

• 对每一项相关的需求进行测试，以确保需求都已实现；
• 对每一个相关的设计关注点进行测试，以确保设计已被实现；
• 用基础测试来扩充针对需求和设计的详细测试用例；
• 使用一个检查表，其中记录着你在本项目迄今位置所犯的，以及在过去的项目中所犯的错误类型。

测试先行还是测试后行

• 在开始写代码之前先写测试用例，并不比之后再写要多花功夫，只是调整了一下测试用例编写活动的工作顺序而已；
• 假如你首先编写测试用例，那么你将可以更早发现缺陷，同时也更容易修正它们；
• 首先编写测试用例，将迫使你在开始写代码之前至少思考一下需求和设计，而这往往会催生更高质量的代码；
• 在编写代码之前先编写测试用例，能更早地把需求上的问题暴露出来，因为对于一个糟糕的需求来说，要写出测试用例是一件困难的事情；
• 如果你保存了最初编写的测试用例——这是你应该做的，那么先进性测试并非唯一选择，你仍然可以最后再进行测试。

开发者测试的局限性

• 开发者测试倾向于干净测试；
• 开发者测试对覆盖率有过于乐观的估计；
• 开发者测试往往会忽略一些更复杂的测试覆盖率类型。

测试技巧锦囊

由于进行完全测试实际上是不可能的，因此测试的敲门就在于选择那些最有可能找到错误的测试用例。

结构化测试的思想是，你需要去测试程序中的每一条语句至少一次。

• 结构化的基础测试；
• 数据流测试；
• 等价类划分；
• 猜测错误；
• 边界值分析；
• 几类坏数据；
  • 数据太少；
  • 数据太多；
  • 错误的数据；
  • 长度错误的数据；
  • 未初始化的数据。
• 几类好的数据；
  • 正常的情形；
  • 最小的局面；
  • 最大的局面；
  • 与旧数据的兼容性。
• 采用容易手工检查的测试用例；

典型错误

不完善的构建过程引发错误所占的比例

• 小型项目里面，构件中的缺陷占了所有错误的大多数；
• 无论项目规模如何，构建缺陷至少占了总缺陷的35%；
• 修正构建错误的代价虽然要比修正需求和设计的错误相对低廉，但从绝对值来看仍然是高昂的。

测试本身的错误

你可以通过下列几项工作来减少测试用例当中的错误量：

• 检查你的工作；
• 开发软件的时候要计划好测试用例；
• 保留你的测试用例；
• 将单元测试纳入测试框架；

测试支持工具

• 为测试各个类构造脚手架；
• Diff工具；
• 测试数据生成器；
• 覆盖率监视器；
• 数据记录器/日志记录器；
• 符号调试器；
• 系统干扰器；
• 错误数据库。

改善测试过程

• 有计划的测试；
• 回归测试；
• 自动化测试。

保留测试记录

为了评估整个项目，你需要手机下列集中数据：

• 缺陷的管理方面描述（报告日期、报告人、描述或标题、生成编号以及修正错误的日期等）；
• 问题的完整描述；
• 复现错误所需要的步骤；
• 绕过该问题的建议；
• 相关的缺陷；
• 问题的严重程度——例如致命的、严重的还是表面的；
• 缺陷根源：需求、设计、编码还是测试；
• 对编码缺陷的分类：off-by-one错误、错误赋值、错误数组下标，以及子程序调用错误等；
• 修正错误所改变的类和子程序；
• 缺陷所影响的代码行数；
• 查找该错误所花的时间；
• 修正该错误所花的时间。

一旦你收集到了这些数据，你就可以对其中部分细节细加思考，从而判断项目是想着更健康，还是更糟糕的趋势发展。

• 每一个类中的缺陷数目，从最糟糕的类到最好的类依次列出，如果类的规模不同，可能要对这一数字进行归一化处理；
• 按照同样的方式列出每个子程序中的缺陷数，也可能需要根据子程序的大小归一化处理；
• 发现一个错误平均所需要花费的测试时间；
• 每个测试用例所发现缺陷的平均数；
• 修正一个测试用例的代码覆盖率；
• 在各个严重级别中未处理缺陷的数量。

核对表：测试用例

• [ ] 类和子程序所对应的每一项需求是否都有相应的测试用例？
• [ ] 类和子程序所对应的每一项设计元素是否都有相应的测试用例？
• [ ] 每行代码是否被至少一个测试用例所测试？同是否通过计算测试到每行代码所学的最好测试用例数量来验证这一点？
• [ ] 所有已定义-已使用路径是否至少被一个测试用例测试过了？
• [ ] 是否测试过那些不太可能正确的数据流模式，例如已定义-已定义、已定义-已退出以及已定义-已销毁？
• [ ] 是否有一张常见错误列表，并据此编写测试用例以检测过去经常出现的错误？
• [ ] 所有的简单边界是否都已经测试过了：最大、最小以及off-by-one？
• [ ] 是否测试了组合边界——即，多个输入数据的组合导致输出数据过小或者过大？
• [ ] 测试用例是否检查了数据类型的错误？
• [ ] 是否测试那些中规中矩的典型数值？
• [ ] 是否测试了最小/最大正常形式？
• [ ] 是否检查了与旧数据的兼容性？以及是否对旧硬件、旧操作系统版本以及其他旧版本软件的接口进行了测试？
• [ ] 测试用例是否容易手工检验？

要点

• 开发人员测试时完整测试策略的一个关键部分；
• 同编码之后编写测试用例相比较，编码之前编写测试用例，工作量和花费的时间差不多，但是后者可以缩短缺陷-侦测-调测-修正这一周期；
• 即使考虑到了各种可用的测试手段，测试仍然只是良好软件质量计划的一部分；
• 你可以根据各种不同的思路来产生很多测试用例，这些思路包括基础测试、数据流分析、边界分析、错误数据类型以及正确数据类型等；
• 错误往往集中在少数几个容易出错的类和子程序上；
• 测试数据本身出错的密度往往比测试代码还要高；
• 自动化测试总体来说是很有用的，也是进行回归测试的基础；
• 从长远来看，改善测试过程的最好办法就是将其规范化，并对其进行评估，然后用从评估中获得经验叫徐来改善这个过程。