软件测试

0.认识需求 1. 业务需求：组织或客户的高层次目标、 描述为什么要开发系统 (Why)，希望达到什么样的目标、 一般 2-5 条，记录在 《 软件愿景和范围 》 文档中。 2. 用户需求： 从 用户角度 ，描述 用户使用产品必须要完成什么任务； 用户能使用系统来做什么(What)；通过用户访谈、调查、对用户使用场景进行整理等方法获取。 3. 功能需求： 描述 开发 人员 在产品中实现的软件功能， 描述开发 人员如何设计具体的解决方案来实现这些 需求 ( how )， 数量 往往比用户需求高一个数量级， 属于 《 软件需求规格说明书 》 的一部分。 <0>软件需求规格说明书 其包括： 功能需求： 1. 用户需求 2. 系统需求： 用于描述包含多个子系统的产品 ( 即系统 ) 的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。 3. 业务规则： 业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 非功能需求： 1. 质量属性：产品 必须具备的属性或品质

软件当中为什么会引入缺陷？ 只要是人，都会犯错。即使是一个优秀的程序员，也会犯低级性的错误，根据数据统计，即便是优秀的程序员，开发的软件产品中，如果未经过测试，代码中遗留的缺陷至少在每千行代码6个以上。 常见的导致软件中存有缺陷的根源有： 1、缺乏有效的沟通，或者没有进行沟通 2、软件复杂度 3、编程错误 4、不断变更的需求 5、时间的压力 6、缺乏文档的代码 7、软件开发工具 8、人员的自大 缺陷的类型及严重级别 软件错误（software error） 软件缺陷（software defect） 软件故障（software fault） 软件失效（software failure） 软件失效机理可描述为：软件错误->软件缺陷->软件故障->软件失效 软件错误：在整个软件生存周期的每个阶段，都贯穿着人的直接或间接地干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的认为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。 软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号，多一个语句等，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。 软件故障：软件故障是指软件运行过程中出现的一种不希望或不接受的内部状态。比如

　　读《构建之法》这本书就像读故事书那样，耐人寻味，又很多故事和经验都是源自作者本身，读起来很有趣，并不会像其他书那样的枯燥乏味。 　　这本书的第一章——概论，为我们解释什么是软件，什么是软件工程，读完这章对这些概念有一定的认识这章让我明白，代码不能盲目的敲，好的软件并非两三天内就能赶出来的。在编写程序之前，需要做一系列的分析、设计，要满足客户的需求，后续还要对软件进行测试、维护等。在这之前，我一直觉得能把程序运行，能有正确的结果，那就完成任务了，可这只是整个软件流程的一部分而已。 　　问题:目前软件工程的影响力如何？日后的发展趋势又如何？ 　　第二章——个人技术和流程，这章引入了“单元测试”的知识，单元测试对一个好的软件起着重要的作用，单元测试应该是准确、快速地保证程序基本模块的准确性，单元测试也有一系列的标准验证其好坏。单元测试必须由最熟悉代码的人(即程序的作者)来写，最好是在设计的时候就写好单元测试，这样会减少程序问题的出现。单元测试是用VSTS来写的。 　　问题：还不理解单元测试的原理，怎么写单元测试? 　　第三章——软件工程师的成长，这章主要是讲个人能力的衡量和以及软件工程师的职业发展。成为软件工程师，首先要学习和积累软件开发相关的知识，不断学习，不断积累，提升技术技能，理解通用的软件设计思想和软件工程思想。学好专业技能以外，还要有一定的自我管理能力、与人合作能力等。 　

Software Test Plan for a mobile application http://developer.nokia.com/community/wiki/Software_Test_Plan_for_a_mobile_application 关于软件测试的几点反思 - 测试是必需的吗？ http://blog.csdn.net/superqa/article/details/21406611 关于软件测试的几点反思 - 测试工作的三个阶段 http://blog.csdn.net/superqa/article/details/21485737 关于软件测试的几点反思 - 关于测试团队的组织 http://blog.csdn.net/superqa/article/details/21966881 让我们重拾一个沉重的话题：提问的艺术 / 技巧 http://testerhome.com/topics/587 软件测试工作中的不靠谱行为 http://www.testwo.com/article/83 来源： https://www.cnblogs.com/oscarxie/p/3595853.html

第十三章（软件测试） 要知道为什么有软件测试，首先需要知道软件开发，软件开发者一般都很难检查出自己的错误，所以才需要另外一个人测试，所以软件测试就诞生了。 书本介绍了很多测试方法，各有各的优缺点，至于目的，就是测试者尽最大的努力找出软件中的错误和缺陷。 当测试时发现好多Bug该高兴还是该忧愁？ 并不是说测试出Bug后该软件就是不好的软件，因为测试就是为了证明程序有错，而不是证明程序无错误。 一个成功的测试是发现了至今未发现的错误的测试。 第十四章（质量保障） 从第一章我们可以总结出：软件 质量 = 程序 质量 + 软件工程 质量 ， 由此可以看出“程序的质量”和“软件工程的质量”影响软件的质量很大。 我们 男神女神配 的项目中，可能很多人都问我们的项目进展得怎么样了？能不能演示？。。。而我们这边的回答：“嗯，不知道，可能到了项目的最后一天才能看。。。”虽然我们组员都知道这样并不好，但是我们队真的想把最好的作品展示在大家面前才会没有那么快就把半成品拿出来。。。 但是，我们也同时知道，我们当把每个人的模块都整理好后也不算是一个成品，因为每一个项目在制作完成后都是由用户体验来感知这个软件到底是不是一个好软件。 第十五章（稳定和发布阶段） 我觉得我们团队现阶段的情况就像书本上说的那样： 缺乏对用户、行业、软件开发的洞察能力，对于“高质量”并没有具体的定义。 没有具体的招数让软件达到所谓的

11. 单元测试 本章节我们来讲讲django工程中如何实现单元测试，单元测试如何编写以及在可持续项目中单元测试的重要性。 下面是单元测试的定义： 单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。 1. 它是一种验证行为 程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西，它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。 2. 它是一种设计行为 编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。什么时候测试？单元测试越早越好，早到什么程度？极限编程(Extreme Programming,或简称XP)讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。 不过在实际的编码过程中，我们不必过分强调先干什么后写什么，重要的是高效和个人感觉舒适。从笔者的经验来看，根据设计或需求先编写某个功能函数的框架，然后就着手编写测试函数，针对产品的功能编写测试用例，最后编写函数的实现代码，每完成一个功能点都运行单元测试，随时补充完善测试用例。这种 测试同行 代码编写模式，会对函数的构思有很大的帮助

软件测试环境是进行软件测试所必需的工作平台和前提条件，包括硬件环境和软件环境，硬件环境指进行测试所必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境则指被测软件运行时的操作系统、数据库及其他应用软件等构成的环境。本文主要阐述在构建测试的软件环境中所用到的一些“复用”技术。 　　软件测试环境就象是一个舞台，可让所有的被测软件在这个舞台上各显其能，尽情“表演”，而我们的测试工程师们就像是一个个评委，对每个被测软件的“表演”打分、评判。因而，软件测试环境构建的是否合理、稳定和具有代表性，将直接影响到软件测试结果的真实性、可靠性和正确性，所以千万不可小窥了软件测试环境的搭建工作，它是测试实施的一个重要阶段和环节，其重要性是不言而喻的；另一方面，不同（版本）的操作系统、不同（版本）的数据库，不同（版本）的网络服务器、应用服务器，再加上不同的系统架构等的组合，使得要构建的软件测试环境多种多样、不胜枚举；而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要，使得构建软件测试环境的工作变得较为复杂和频繁，如果我们再按照以前那种按部就班地来搭建测试环境的方法，可真有点落伍了，不仅效率低下，而且灵活性、可复用性也较差。那么出路何在呢？ 　　在软件的开发过程中，创建可复用的软件构件库的技术

第六章——软件测试的度量 1.什么是软件测试的度量？ 软件度量是一种度量技术，这种技术用来支撑过程、产品和服务中心工程和管理信息，以及支持过程、产品及服务的信息上的改进，从而量化地评定测试过程的能力和性能，提高测试过程的可视性，帮助软件组织管理及改进软件测试过程。 2.软件测试度量出于什么原因才进行的？不可或缺吗？ 目的： （1）判断测试的有效性； （2）判断测试的完整性; （3）判断工作产品的质量； （4）分析和改进测试过程。 重要性： （1）度量可以用来提高质量、产品生产力、以及服务，从而提高客户满意度； （2）对于管理组织很容易分析数据并且深入下去； （3）对过程不受控时有不同的度量方式作为监控者； （4）度量提供当前过程改进。 3.软件测试对工作人员有什么要求？对测试人员的工作如何进行评价？ 软件测试对测试人员有素质要求和技术要求。 4.软件测试的度量有什么现实的应用？ （1）评价测试人员工作能力 5.bug综合评价模型包括哪6个方面？ （1）测试过程 （2）数量 （3）定量 （4）质量 （5）定性 （6）测试人员 6.代码覆盖率如何计算？功能覆盖率？数据库覆盖率呢？ 代码行覆盖率=（已执行测试的代码行/总的代码行）*100% 功能覆盖率=（已执行测试的功能模块数/总的功能模块数）*100% 数据库覆盖率=（sql中出现的数据库的对象数/数据库总的对象数）*100% 7

单元测试或是最好的项目文档。 很早之前在学习使用Java做测试的时候，得到过一个神秘大佬的帮助，在一起聊过单元测试，基本结论就是：单元测试大概率没啥鸟用。 众所周知，自动化测试相比手动测试一个比较明显的特点就是见效慢，需要积累一定的时间所产生的的价值才能超过手动测试，这还是在比较理想的情况下。某些时候可能永远也超不过。而单元测试更甚，据大佬和吹牛逼的群聊中判断：好的单元测试代码大概是被测代码的2-3倍，这种工作量对于开发人员来讲是不可接受的。单元测试见效比自动化测试更慢，这一点也是大家的共识，甚至到不了见效的时候就黄了。 之前对单元测试进行过一些尝试，写过一点文章： Maven和Gradle中配置单元测试框架Spock Groovy单元测试框架spock基础功能Demo Groovy单元测试框架spock数据驱动Demo 人生苦短？试试Groovy进行单元测试 使用WireMock进行更好的集成测试 如何测试这个方法--功能篇 如何测试这个方法--性能篇 单元测试用例 JUnit 5和Selenium基础（一） JUnit 5和Selenium基础（二） JUnit 5和Selenium基础（三） 近几日一直在对之前的性能测试框架进行优化，在这个过程中，我之前利用Groovy单元测试框架spock写过的两个性能测试框架的单元用例起到了非常大的帮助

1 初识自动化测试 如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘，但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。 例如， Windows操作系统的控制面板中，有一项功能： 任务计划向导 。 DOS批处理文件，直到今天的Windows Vista还在使用它。它更接近自动化测试。 上述的自动化处理过程还不是测试，因为 测试的重要一点是须要验证 ，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。 2 自动化测试和手工测试有什么不同 亲手做过自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉： 　　l 机器人从来就不会感觉累 　　l 自动化测试的速度，是手工测试无法比的 　　l 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。 　　l 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。 从这里就可以初步体会到自动化测试的优越性―― 高效率、准确可靠 和 复用性 。同时，自动化测试也有不利的一面，即在 创造性、发现新缺陷 等方面能力不足。 有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以 自动化测试更适合于负载测试、性能测试和回归测试 。 概括起来