软件测试

------------------------------------------我是分割线-为什么开发人员不愿意写测试代码-----------------------------------------

<今天看了《软件测试的艺术》基本上找到了答案，这是心理问题，是对软件测试的定位问题>

1.软件测试是为发现错误而执行程序的过程
2.一个好的测试用例具有较高的发现某个尚未发现的错误可能性
3.一个成功的测试用例能够发现某个尚未发现的错误

这个话题老生长谈了，单元测试代码的用途和重要性不言而喻，但是在日常工作中，程度员总有各式各样的理由来拒绝写单元测试代码。从上个项目的亲身经历看，程序员不乐意写单元测试代码的理由有如下几类：

1、没时间。项目进度太紧张，项目计划里完全没有预留单元测试代码开发的时间；正常代码想搞完时间都很紧张，程序员巴不得把业务代码搞定之后休息、放松一下，单元测试代码再重要，但其开发工作也就自然放在一边了。

2、没必要。老代码一大片，都堆在那里，身经百战，产品应用那么久，如果有Bug早该发现了，现在写单元测试代码不是浪费时间和金钱嘛。

3、不必要。代码功能这么简单，逻辑也不复杂，抽时间代码Review就可以了，何必为其专门开发单元测试代码。

4、工具不足。如缺少打桩工具，模块之间依赖重重或者没有依照面向接口的思想开发，导致静态对象满天飞，程序员手里缺少简单易用的打桩工具，导致各种业务场景无法模拟，异常场景更是不消讲，单元测试的意义大打折扣，程序员没有意愿付出时间开发单元测试代码。

5、程序员自身能力不足。对项目组可用的单元测试工具使用不熟练，开发单元测试代码时间效率低下，或者需要花费很多时间解决单元测试代码中的问题，或者单元测试代码运行结果不稳定，无法起到质量看护的效果，这样也会导致程序员没有兴趣和意愿在项目进行过程中开发单元测试代码。

6、需求不稳定，导致代码变动大，已有的单元测试代码需要投入时间和精力维护，这样也会导致程序员没有兴趣和意愿来写单元测试。

7、老代码结构混乱，可测试性比较低，开发单元测试代码的代价比较高，而这些代码已应用了相当的时间，为了写单元测试代码而做针对性的修改，意义不大，投入和产出不成比例。

。。。。

。。。问题是我开发的时候也讨厌写单元测试代码，现在我做SM，该怎么督促团队做好单元测试。。。纠结

        写完上面的文字，我突然想起来一段课文，勿以善小而不为，单元测试代码就是日常项目开发过程中的善事。所谓前人种树，后人乘凉，当维护代码的后人使用前人写好的代码测试代码来检验重构之后的代码特性是否完备、正确时，相信后人心里是充满感激之情的。

        需求是商务决定的，程序员只能默默接受而不能改变。

工具是外部条件，在不具备的时候，强行做事确实痛苦，这时不搞单元测试情有可原，因此程序员也只能默默接受。

        但能力问题和态度问题是程序员可以搞定的。比如引入新的单元测试工具，或者优先、调整已有代码的结构，使单元测试代码在写作时不那么痛苦，或者学习新的单元测试技术，应用到项目中。我觉得都有希望可以逐步解决上述问题。

------------------------------------------我是分割线-<软件测试的艺术笔记>--------------------------------------------------

1.测试是为发现错误而执行程序的过程。
  一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。
  一个成功的测试用例能够发现某个尚未发现的错误。
2.软件测试的重要原则
-测试用例中一个必需部分是对预期输出或结果进行定义
-程序员应当避免测试自己编定的程序
-编定软件的组织不应当测试自己编定的软件
-应当彻底检查每个测试的执行结果
-测试用例的编定不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
-检查程序是否未做其应该做的仅是测试的一半，测试的另一半是检查程序是否做了其不应该做的
-应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
-计划测试工作时不应默认假定不会出现错误
-程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
-软件测试是一项极富创造性、极具挑战性的工作。
3.代码检查、代码走查、桌面检查
-代码走查中，一组开发人员（3-4最佳）对代码进行审核，参加者当中只有一人是程序编定者，测试用例。
-代码检查，是以组为单位阅读代码，是一系列规程和错误检查技术的集合。（通常4人组成，协调人，编码人员、设计人员、

测试专家）
--用于代码检查的错误列表：数据引用错误、数据声明错误、运算错误、比较错误、控制流程错误、接口错误

、输入/输出错误、其他山穷水尽

 

数据引用错误运算错误1.是否有引用的变量未赋值或未初始化？1.是否存在非算术变量间的运算？2.下标的值是否在范围之内？2.是否存在混合摸式的运算？3.是否存在非整数下标？3.是否存在不同字长变量问的运算？4.是否存在虚调用？4.目标变量的大小是否小于赋值大小？5.当使用别名时属性是否正确？5.中间结果是否上溢或下溢？6.记录和结构的属性是否匹配？6.是否存住被 0 除？7. 是否计算位串的地址？是否传递位串参数7.是否存在二进制的不精确度？8.基础的存储属性是否正确？8.变量的值是否超过了有意义的范围？9.跨过程的结构定义是否匹配？9.操作符的优先顺序是否被正确理解？10.索引或下标操作是否有“仅差一个”的错误10.整数除法是否正确？11.继承需求是否得到满足？　数据声明错误比较错误1.是否所有的变量都已声明？1.是否存在不同类型变量间的比较？2.默认的属性是否被正确理解？2.是否存在混合模式的比较运算？3.数组和字符串的初始化是否正确？3.比较运算符是否正确？4.变量是否赋予了正确的长度，类型和存储类？4.布尔表达式是否正确？5.初始化是否与存储类相一致？5.比较运算是是否与布尔表达式相混合？6.是否有相似的变量名？6.是否存在二进制小数的比较？　7.操作符的优先顺序是否被正确理解？　8.编译器对布尔表达武的计算方式是否被正确理解
-桌面检查可视为单人进行的代码检查或代码走查
-同行评分，6-20参与者选出最好和最差的作品，随机分发后，选出最好和最差的程序各2个
4.测试用例的设计
-白盒测试
--逻辑覆盖测试
---判定/条件覆盖准则：将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一

 

次，将每个入口点都至少调用一次。
等价划分
--确定等价类（有效等价类、无效等价类），生成测试用例
--边界值分析
--因果图
-错误猜测
-测试策略
---合理的测试策略：a.如果包含输入条件组合的情况，应首先使用因果分析方法；b.在任何情况下都应使用边界值分析方法

；c.应为输入和输出确定有效和无效等价类d.使用错误猜测技术增加更多的测试用例e.针对上述测试用例集检查程序的逻辑结

构。
5.模块（单元）测试
-设计测试用例
--需要使用两种类型的信息：模块的规格说明和模块的源代码。总体上是面向白盒测试的，用墨盒测试用例来补充。
-增量测试
--增量测试（将下一步要测试的模块组装到测试完成的模块集合中，再进行测试，又叫集成）、非增量测试（又叫崩溃测试）
--驱动模块是用来将测试用例驱动或传输到被测模块中。桩模块，接受被测模块的控制指令。
--自顶向下的测试，惟一的原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了

测试，另一个要考虑的是采取什么样的形式将测试用例提交给程序。需要使用桩模块。
--自底向上的测试，惟一的原则是所有的从属模块（它调用的模块）都已经事先经过了测试。需要使用驱动模块。
--执行测试
6.更高级别的测试

-功能测试，是一个试图发现程序与其外部规格说明之间存在不一致的过程。等价类划分方法、边界值分析方法、因果图分析

方法和错误猜测方法尤其适合于功能测试。
-系统测试，将系统或程序与其初始目标进行比较。以下是15种系统测试用例类型
--能力测试，判断目标文档提及的每一项能力是否都确实已经实现
--容量测试，为了证明程序不能处理目标文档中规定的数据容量。
--强度测试，使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。
--易用性测试，试图发现人为因素或易用性的问题
--安全性测试，设计测试用例来突破程序安全检查的过程
--性能测试，在特定负载和配置环境下程序的响应时间和吞吐率。
--存储测试，如程序使用的内存和辅存的容量，以及临时文件或溢出文件的大小
--配置测试，在程序面向的所有操作系统环境中对其进行测试（I/O设备、通信线路、存储容量、web浏览器）
--兼容性/配置/转换测试，证明兼容性目标未被满足，转换过程并未生效。
--安装测试，
--可恢复性测试，证明系统从程度错误、硬件失效和数据错误中恢复的恢复机制不能够正确发挥作用
--适用性测试，定义了系统提供的服务辅助功能，包括存储转存程序或诊断程序、调试明显问题的平均时间、维护过程以及内

部业务文档的质量等。
--文档测试，检查用户文档的正确性
--过程测试，必须对所有已规定的人工过程进行测试
--系统测试的执行：a.不能由程序员来进行系统测试，执行系统测试的人必须充分了解最终用户的态度和应用环境，以及程序

的使用方式（理想的系统测试小组应当是几位专业的系统测试卖家、一两位最终用户代表、一位人类工程学工程师及该程序主

要的分析人或设计者组成）。b.在所有的测试阶段中，这是惟一一个明确地不能由负责该程序开发的机构来执行的程序（可以

考虑外包）
-验收测试，是将程序与其最初的需求及最终用户当前的需要进行比较的过程。
-安装测试，发现安装过程中的错误
-测试的计划与控制。
--一个良好的测试计划应包括：目标、结束准则、进度、责任、测试用例库及标准、工具、计算机时间 、硬件配置、集成、

跟踪步骤、调试步骤、回归测试
-测试结束准则
--常用的：用完了安排的测试时间；执行完所有的测试用例后未发现错误
--不是最佳的准则，根据特定的测试用例设计技术
--也许是最有价值的准则，以确切的数量来描述结束测试的条件
--在测试中记录每单位时间内发现的错误数量，通过检查统计曲线的形状做决定
-独立的测试机构
7.调试
-暴力法调试：a.利用内存信息输出来调试b.根据一般的“在程序中插入打印语句”建议来调试c.使用自动化的调试工具进行

调试。
-归纳法调试：

-演绎法调试：

-回溯法调试
-测试法调试（使用测试用例）
-调试的原则
--定位错误的原则a.动脑筋b.如果遇到了僵局，就留到稍后解决c.如果遇到了困境，把问题描述给其他人听d.仅将测试工具做

为第二种手段e.避免使用试验法-仅将其作为最后的手段
--修改错误的原则a.存在一个缺陷的地方，很有可能还存在其他缺陷b.纠正错误本身，而不是其症状c.正确纠正错误的可能性

并非100%。d.正确修改错误的可能性随着程序规模的增加而降低e.应意识改正错误会引入新错误的可能性f.修改错误的过程也

是临时回到设计阶段的过程g.应修改源代码，而不是目标代码
-错误分析
--a.错误出现在什么地方b.谁制造了这个错误c.哪些做得不正确d.如何避免该错误出现e.为什么错误没有早些发现f.该如何更

早地发现错误
8.极限测试，首先创建单元测试和验收测试，然后才创建代码库
-极限编程ExtremeProgramming，采取简单的设计，在开发人员和客户之间建立联系，不断地测试代码库，重构以适应规格说

明的变更，以及寻求用户的反馈。必须首先生成单元测试用例，然后才编定代码通过测试。
--极限编程的12个实践：1.计划与需求分析，2.小规模、递增地发布，3.系统隐喻，4.简要设计，5.连续测试，6.重构，7.结

对编程，8.代码的集体所有权，9.持续集成，10.每周40小时工作，11.客户在现场，12.按标准编码
--进行连续的测试是基于XP的方法取得成功的关键。
-极限测试：概念
--极限单元测试。所有代码模块在编码开始之前必须设计好单元测试用例，在产品发布之前须通过单元测试。
--验收测试。目的是判断应用程序是否满足如功能性和易用性等其他需求。
-极限测试的应用
附录：词汇表

black-box testing（黑盒测试）将程序视为一个整体、且忽略其内部结构的测试方法。 单纯从软件的规格说明中获取测试数据。
bottom-up testing（自底向上的测试）增量模块测试的一种形式，首先测试底层模 块，再测试调用模块等等。
boundary-value analysis（边界值分析），一种黑盒测试方法，重点在于程序输 t 入 区间的边界区域。
branch coverage（分支覆盖）参见“判定覆盖”。
cause-effect graphing（因果图分析）使用简化的数字逻辑电路图（组合逻辑网络） 辅助生成一组高效测试用例的技术。
code inspection（代码检查）一套供小组代码阅读的规程和错误检查枝术，作为检 查错误的测试周期的一部分，通常使用一份常见错误的列表来对照代码。
condition coverage（条件覆盖）白盒测试的一项准则，要求编写足够数量的测试用 例，确保将一个判断中的每个条件的所有可能的结果至少执行一次。
data-driven testing  （数据驱动测试）参见“黑盒测试”。
decision/condition coverage （判定／条件覆盖）自盒测试的一项准则，要求编写足 够数量的测试用例，确保将每个判断中的每个条件的所有可能的结果至少执行 一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用 一次。
decision coverage（判定覆盖）白盒测试的一项准则。要求编写足够数量的测试用 例，确保每一个判断都至少有一个为真和为假的输出结果。
desk checking（桌面检查）一种将代码审查和走查技术结合起来，在用户桌面上执 行程序的技术。
equivalence partitioning（等价类划分）一种黑盒测试技术，其中每个测试用例都必 须体现尽可能多的不同的输入情况，以最大限度地减少全部用例的数量。应该 尽量将程序输入范围划分为等价类，这样类中某个输入数据的测试结果等同于 同类中所有输入数据的测试结果。
exhaustive input testing（穷举输入测试）黑盒测试的一项准则，通过将每个可能的 输入条件都作为测试用例，尽量发现程序中的所有错误。
external specification（外部规格说明）从某个相关系统部件用户的角度对程序功能 的精确描述。
facility testing（能力测试）系统测试的一种类型，判断目标文档提及的每一项能力（或功能）是否都实现了。不要混淆能力测试与功能测试。
function testing（功能测试）发现程序与其外部规格说明之间存在不一致的过程。
incremental testing（增量测试）模块测试的一种形式，将待测模块与已测模块组装 在一起进行测试。
input/output testing（输入／输出测试）参见“，象盒泪 11  试”。
logical-driven testing（逻辑驱动测试）参见“白盒测试”。
multi-condition coverage（多重条件覆盖）白盒测试的一项准则，要求编写足够数 量的测试用例，确保每个判定中的所有可能的条件结果的组合，以及所有的入 口点都至少执行一次。
nonincremental testing（非增量测试）模块测试的一种形式，每个模块单独进行测 试。
performance testing（性能测试）系统测试的一种形式，尽量证明程序不能满足特 定的指标，如在特定负载和配置环境下的响应时间和吞吐率。
random-input testing（随机输入测试）在所有可能的输入值中随机选取一个子集来 对程序进行测试的过程。
security testing（安全性测试）系统测试的一种形式，用以考验程序或系统的安全 保密机制。
stress testing（强度测试）系统测试的一种形式，使程序经受高负载或强度。高强 度是指在很短的时间间隔内达到的数据或操作的数量峰值。因特网应用系统通 常需要进行强度测试，因为会有大量用户并发访问系统。
system testing（系统测试）高级测试的一种形式，将系统或程序与其初始目标进行 比较。为了完成系统测试，需要一套书面的可度量的目标。
testing（测试）为了发现错误而执行程序（或具体的程序单元）的过程。
top-down testing（自顶向下的测试）增量模块测试的一种形式，首先测试初始模块， 再测试下一个子模块等等。
usability testing（易用性测试）系统测试的一种形式，测试程序的人机界面。通常 要检查的部件包括界面布局、界面色彩、输出格式、输入字段、程序流程、拼 写等等。
volume testing（容量测试）系统测试的一种形式，使用大容量的数据检验程序能否 处理目标文档中规定数据容量。容量测试与强度测试并不相同。
walkthrough（走查）一套供小组代码阅读的规程和错误检查技术，作为检查错误 的测试周期的一部分。通常一个小组的人起到“计算机”的作用，执行一个小 的测试用例集。
white-box testing（白盒测试）一种检查程序内部结构的测试类型。

--------------------------------------------我是分割线-------------------------------------------------------------------------------------