摘要: 一、缺陷常用字段说明 二、缺陷管理流程图 三、开发人员修改缺陷填写规范 四、项目经理决定延期修改缺陷 一、缺陷常用字段说明 1、摘要 对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称，以及简单说明缺陷情况。 2、描述 详细描述重现该缺陷的步骤，错误现象和期待结果。必要时可以上传附件辅助说明。 3、状态序号缺陷状态英文名称缺陷状态中文名称缺陷状态描述备注1New新建测试中...
阅读全文
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： 软件开发 数据库
说起数据库设计，相信大家都明白怎么回事，但说起数据库设计的重要性，我想大家也只是停留在概念上而已，到底如何重要？怎么重要呢？今天就将我至今为止的理解向大家阐述下。
一个不良的数据库设计，必然会造成很多问题，轻则增减字段，重则系统无法运行。我先来说说数据库设计不合理的表现吧：
1、与需求不符
因为这个原因造成的改动量往往是最大。如果进入编码阶段的话，很可能会直接让你崩溃掉。
2、性能低下
含有大数据量的表之间的关联过多；没有合理的字段设计来用于查询而造成的SQL查询语句很复杂；对于大数据量的表没有采用有效的手段去处理；滥用视图等。
3、数据完整性丧失
含有主外键关系的表之间关联字段的设计方式不合理，造成更新与删除操作后程序容易出错或不完善；使用了已经删除或丢失掉的数据。
4、可扩展性性太差
表设计的与业务绑定的太紧密、单一，造成表的可拓展性、可修改性太差，无法新需求的要求。
5、非必要数据冗余量太大
没用的垃圾数据存储过多，不仅占用资源，还影响查询效率。
6、不利于计算或统计
缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中，造成计算统计的步骤繁琐，甚至无法计算统计。
7、没有详尽的数据记录信息
缺少必要的字段，造成无法跟踪数据变化、用户操作，也无法进行数据分析。
8、表之间的耦合性太大
多张表之间关联的过于紧密，造成一张表发生变化而影响到其他表。
9、字段设计考虑不周
字段长度过短或字段类型过于明确，造成可发挥、可拓展的空间太小。
大多数的程序员对于软件开发的出发点认识不是很明确，总是认为实现功能才是重要的，在简单了解完基本需求后就急忙进入编码阶段，对于数据库设计思考的比较少、比较简单，大多设计都只停留在表面上，这往往是要命的，会为系统留下很多隐患。要么是写代码开发过程中才发现问题，要么就是系统上线运转后没多久就出现问题，还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。
数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！
那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则：
1、数据库设计最起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。
2、数据库设计不仅仅停留于页面demo的表面
页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了
每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。
4、数据库设计时就要考虑到效率和优化问题
一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。
5、添加必要的（冗余）字段
像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。
6、设计合理的表关联
若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。
7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联
这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
8、选择合适的主键生成策略
主键生成策略大致可分：int自增长类型（identity、sequence）、手动增长类型（建立单独一张表来维护）、手动维护类型（如userId）、字符串类型（uuid、guid）。int型的优点是使用简单、效率高，但多表之间数据合并时就很容易出现问题，手动增长类型和字符串类型能很好解决多表数据合并的问题，但同样也都有缺点：前者的缺点是增加了一次数据库访问来获取主键，并且又多维护一张主键表，增加了复杂度；而后者是非常占用存储空间，且表关联查询的效率低下，索引的效率也不高，跟int类型正好相反。
终上所述，我们可见数据库设计在整个软件开发的起到的举足轻重的作用，尤其是我说的设计原则的第一点，数据库与需求是相辅相成的，我经常把软件开发比作汽车制造。汽车制造会经过图纸设计，模型制作，样车制造，小批量试生产，最后是批量生产等步骤。整个过程环环相扣，后一过程是建立在前一过程正确的前提基础之上的。如果在图纸设计阶段发现了一个纰漏，我们可以重新进行图纸设计，如果到了样车制造阶段发现这个错误，那么我们就要把从图纸设计到样车制造的阶段重来，越到后面发现设计上的问题，所付出的代价越大，修改的难度也越大。
数据库设计难度其实要比单纯的技术实现的难很多，他充分体现了一个人的全局设计能力和掌控能力，所以在今后的项目中大家一定要着重培养这方面的能力，这里我将我的经验分享给了大家，希望能对大家有所帮助。
去年底做了一个Android应用的项目，代码总计2万多行，测试周期4个月，项目虽小，但涉及到手机终端适配、网络环境兼容等多个方面。项目阶段一结束后，我们简单总结了一下测试方法有效性的问题。发出来与大家共享。
这个Android应用的主要功能很简单，附加功能较多，基本都属于锦上添花类。测试的实际情况如下：
1、资源投入：持续时长4个月，人力6人+，测试机型30款+
2、测试执行：23轮功能测试，7轮系统测试，8轮健全测试，3轮机型兼容测试，3轮性能测试，1轮MTBF测试，1轮PD/UI验证测试。
但是这其中有很多不足之处，较明显的如下：
1、前期功能测试和健全测试一天一轮，频度太快且测试费时，效果不好。
2、初期的测试用例设计全面，但未精确定义编写粒度，描述过程过细，后期因需求变更导致维护成本较高。
3、因项目流程和过程控制影响，无法明确划分测试阶段，且初期没有找到最佳敏捷测试方法，测试流程冗余僵化，导致大量重复性的工作，灵活性偏低。
在测试进程中我们已发现测试策略的问题，并及时调整，在阶段二开始使用新策略——使用两阶段测试模型：
1、阶段一<自由测试>：按照探索性测试（Exploratory Testing）模式，布置有针对性有重点的自由测试，以“把软件使用坏掉”为目的，尽可能多发现bug。
2、阶段二<覆盖测试>：执行各项测试用例，以“全面测试”为目的
具体的时间安排如下：
1、先期产品开发阶段，即Alpha release之前，做功能测试、健全测试、缺陷验证+自由测试。
2、项目中期，Alpha ~ Beta之间，执行全面的系统测试、兼容性测试、性能测试，并开展自动化脚本开发、环境搭建等工作。
3、Beta release之后，在产品发布前的2~3周，就开始确定稳定版本Release Candidate，在此版本基础上做最后一轮全面测试、重点子模块的健全测试、缺陷主导的ET等，完成最终报告并交由项目组领导、QA审核发布。
本次测试有效性总结我们引入了两个质量来衡量：软件质量指标和测试过程质量指标。
软件质量指标包括：
（一）需求功能点覆盖率：
计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。用例覆盖需求矩阵，一个需求对应多个功能点。
需求覆盖率=∑测试用例数（个）/∑功能点（个）=1055/147=7.18
（二）用例执行覆盖率：
计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。
用例执行覆盖率=∑执行的测试用例个数（个）/∑测试用例个数（个）*100%
功能测试276条，系统测试779条，用例执行覆盖率达到99%。
测试过程质量指标包括：
（一）缺陷探测率：
计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能力。说明：缺陷探测率越高，即内部发现的bug数越多，发布后客户发现的bug数就越少，质量成本就越低。
缺陷探测率=内部发现的缺陷数（个）/（内部发现的缺陷数（个）+用户发现的缺陷数（个））*100%
缺陷数=636（有效），用户发现缺陷数=1（当前）
缺陷探测率=636/637=99.84%
（二）有效缺陷率：
计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。
无效BUG状态包括：问题重复、不是问题、不可复现状态。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高测试质量越高。
注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的BUG为有效BUG
有效缺陷率=测试人员发现的有效缺陷数（个）/测试人员发现的总缺陷数（个）*100%=636/689=92.31%
（三）用例执行效率：
计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率
说明：此指标的统计需要有一定的前提条件：用例的执行步骤相对来说分布较均匀，执行时间在一个较长的时间段内
用例执行效率=∑测试人员执行的用例数（个）/∑执行用例的时间（小时）
（四）缺陷发现率：
计算测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。
缺陷发现率=∑提交缺陷数（个）/∑执行测试的有效时间（小时）
以第18轮功能测试为例：
用例执行效率=10.17
缺陷发现率=36.67%
（五）缺陷覆盖率：
计算缺陷与测试用例的比率，用来衡量测试用例覆盖缺陷的能力。
缺陷覆盖率=∑缺陷个数/∑测试用例条数
版权声明：本文出自 cmriqa 的51Testing软件测试博客：http://www.51testing.com/?489136
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
1）定制终端评测趋势
● 定制终端评测
→ 硬件：射频一致性、协议一致性、无线资源管理、硬件元器件、WLAN是当前硬件测试主要内容
→ 软件：操作系统测试、浏览器测试、移动应用测试、Widget测试当软件测试重点，内容逐渐由功能向非功能演进
● 预装在定制终端的移动应用评测
→ 功能、性能、稳定性、兼容性
→ 用户体验、隐私安全
● 终端和移动应用评测自动化工具越来越成熟
● 终端及其应用的性能、稳定性评测将成为入库重要依据
● 用户体验评测将成为不可或缺的组成部分
2）三大智能终端平台差异
以智能终端操作系统为基础，结合多种基础中间件、业务中间件、通信中间件来实现对应用的支撑。其中应用又可分为本地应用和Web应用两类。本地应用体系以iOS+App Store+NativeApp为代表，Web应用以HTML5/Widget+Web Store+Web App为代表
以iOS/WP7为代表的系统闭源/封闭文件管理系统/接口开放模式
以oPhone OS/WM为代表，系统闭源/开放文件管理系统和接口模式
以Android/Meego/WebOS/WinCE为代表系统开源/开放文件管理系统和接口模式
3）互联网应用测试的复杂因素
传统的测试方法是暴力的、疯狂的、相当麻烦的。
● 全球多达十亿两千万mobile web用户
● 74%的人将无法容忍超过5s的页面加载时间
● Gartner预测，至2014年超过90%企业级应用将支持智能终端版本
● 据统计，智能机上移动应用软件所引发的无线流量是非智能机10倍以上，美、英、德、日运营商都曾出现信令风暴导致的通信网瘫痪
● 截至2011年Q3的统计，Android操作系统出现7个版本，覆盖130个机型，每个机型超过2家硬件参考设计。光从终端适配角度看，若实现完整的测试覆盖，需完成1820次回归测试。倘若无法借鉴自动化测试工具，几乎是无法完成的任务
终端
● 操作系统平台、机型、屏幕分辨率、驱动差异等
网络
● 地域、制式、通信业务、网络优化程度、漫游等差别
自动化测试脚本
● 因平台、菜单风格不同，模拟客户端或自动化脚无法复用
移动应用客户端性能测试面临的困难
● 支持除支持http(s)协议外，普遍存在定制协议
● 整个应用链关联的对象复杂，如web service第三方内容、CDN内容分发
● 缺乏测试过程中数据收集、监控和诊断工具
● 缺乏客户端模拟并发工具，压力/负载测试工具需重新选择
4）测试
从互联网应用软件质量角度看，其主要的质量要求列举如下：
● 功能性：终端上移动应用功能越来越复杂，测试难度、周期和工作量逐步加大，测试成本快速上升
● 稳定性：用户使用移动应用时，与终端的电话、短信、浏览器等背景业务经常产生功能交互，增加了移动应用的不稳定性
● 可维护性：用户越来越关注应用业务的用户体验，在应用上线后需要持续对业务运营质量进行测试和监控
● 性能：终端上移动应用与终端、网络和服务的性能都有关系，性能遭遇瓶颈时，定位需围绕应用关联的整个链路来开展，导致应用业务优化的成本在不断提高
从用户角度看，测试重点列举如下：
测试类型 | 描述 | 测试场景重点 | 判断依据 |
功能测试 | 基本功能测试
新功能测试
重点功能测试
全量测试
网络或业务功能拨测
J2ME、Sybian signed等规范符合性测试 | 菜单路径
功能点
界面与操作流程
（通信）业务功能
角色权限等 | 是否可用 |
性能测试 | 基准性能
性能指标测试/多地域性能拨测
性能对标测试
专项性能测试：时延测试、流量测试、功耗测试、触控测试 | 对被测对象功耗、时延、响应时间、连接成功率、并发用户数等核心性能指标进行测试 | 是否可用，且收集指标值 |
兼容性测试 | mobile apps（手机客户端）实质为终端适配性测试
mobile web（web客户端）实质为浏览器兼容性测试
pc客户端端实质为与主流用户操作系统兼容性测试 | 终端适配：与不同分辨率、不同操作系统平台版本、不同定制终端的兼容性
浏览器兼容：html5兼容；浏览器引擎兼容
pc客户端兼容：主流windows桌面和linux桌面系统兼容性 | 是否兼容 |
稳定性测试 | 极限负荷下稳定性基准，表征为持续无故障时间有多长 | 基本功能反复多次
基本功能长时间持续执行 | 成功率，且收集指标值 |
安全性测试 | 黑盒安全性测试，采用模糊数据对被测对象进行攻击测试的手段 | 访问限制、应用程序签名、恶意程序安全、权限命名机制、协议通信安全和用户数据隐私安全 | 是否安全
|
对于一些数据量较大的系统，面临的问题除了是查询效率低下，还有一个很重要的问题就是插入时间长。我们就有一个业务系统，每天的数据导入需要4-5个钟。这种费时的操作其实是很有风险的，假设程序出了问题，想重跑操作那是一件痛苦的事情。因此，提高大数据量系统的MySQL insert效率是很有必要的。
经过对MySQL的测试，发现一些可以提高insert效率的方法，供大家参考参考。
1、一条SQL语句插入多条数据。
常用的插入语句如：
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0);
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('1', 'userid_1', 'content_1', 1); |
修改成：
| INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0), ('1', 'userid_1', 'content_1', 1); |
修改后的插入操作能够提高程序的插入效率。这里第二种SQL执行效率高的主要原因有两个，一是减少SQL语句解析的操作，只需要解析一次就能进行数据的插入操作，二是SQL语句较短，可以减少网络传输的IO。
这里提供一些测试对比数据，分别是进行单条数据的导入与转化成一条SQL语句进行导入，分别测试1百、1千、1万条数据记录。
2、在事物中进行插入处理。
把插入修改成：
START TRANSACTION;
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0);
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('1', 'userid_1', 'content_1', 1);
...
COMMIT; |
使用事物可以提高数据的插入效率，这是因为进行一个INSERT操作时，MySQL内部会建立一个事物，在事物内进行真正插入处理。通过使用事物可以减少创建事物的消耗，所有插入都在执行后才进行提交操作。
这里也提供了测试对比，分别是不使用事物与使用事物在记录数为1百、1千、1万的情况。
性能测试：
这里提供了同时使用上面两种方法进行INSERT效率优化的测试。即多条数据合并为同一个SQL，并且在事物中进行插入。
从测试结果可以看到，insert的效率大概有50倍的提高，这个一个很客观的数字。
注意事项：
1、SQL语句是有长度限制，在进行数据合并在同一SQL中务必不能超过SQL长度限制，通过max_allowed_packe配置可以修改，默认是1M。
2、事物需要控制大小，事物太大可能会影响执行的效率。MySQL有innodb_log_buffer_size配置项，超过这个值会日志会使用磁盘数据，这时，效率会有所下降。所以比较好的做法是，在事物大小达到配置项数据级前进行事物提交。
在过去25年里，真正伟大的消费技术类公司都有一个共同的特点：他们创造了消费习惯。而正是这一点将优秀企业和普通企业区分开来。例如苹果、 Facebook、亚马逊、Google、微软以及Twitter。它们开发了用户日常使用率很高的产品，具有极大的吸引力，以至于很难想像没有这些产品的生活将会怎样。
不过，创造习惯却是一件说起来容易，做起来一点都不容易的工作。虽然有很多关于行为工程学以及用户行为对互联网未来重要性的文章，但是，有关设计和测算用户行为的资源仍然非常稀少。并不是指这些技术不存在——事实上，对于资深开发者来说，这些技术非常熟悉。但对于新手来说，这些工具很是神秘。
而我则从这些技术中总结出一种方法，并将其称之为 “习惯测试”。这是一种被许多业内优秀公司所采用的方法。一些消费网络公司凭此开发出了许多用户爱不释手的产品。
习惯测试
习惯测试完全适合于创建、测算、学习方法论，并得到了精益创业运动的支持。它主要帮助创业者明确了以下三个问题：
● 你所服务的对象是谁？
● 如果可能的话，你的产品中的哪些部分能变成消费习惯？
● 它们为什么能转变成消费习惯？
习惯测试的一个前提条件是有一种产品出现并运营之中。当然，在推出一款产品之前，一个好的办法是：试行你所设想的商业模式，并找到引发用户消费欲望的方式。
如果你有一个网站或应用上线，你就可以开始收集数据了。习惯测试并不要求收集所有方面的数据——只要合适即可。因此，关键的一点是要使用合适的分析方法。为了让测试达到目的，建议在用户访问网站的时候标记出用户访问路径的时间点。下面，让我们深入了解一些习惯测试的步骤和方法。
步骤一：分辨
建立网站和找到分析方法之后，你需要回答习惯测试的第一个问题是：“哪些用户拥有习惯性的动作？”首先，明确这对于潜在客户的意义何在。问问自己，一个用户要多久“才”会使用网站。这也就是说，假设有一天，所有的 bug 都被清理后，产品也很完美地“随时待命”，你希望有消费习惯的用户间隔多久访问网站？
这需要着眼现实并忠于自己。如果你开发了一个类似于 Foursquare 或 Instagram 的移动社交网络应用，你大概会希望有消费习惯的用户每天都登陆数次。但是，如果是一个电影推荐网站，如Flixster，你大概不会希望用户一周访问多次。因此，不要仅通过计算就得到一个过于乐观的期望。你只要找到一个符合实际的想法，计算出用户访问的频率即可。
一个简单有效的办法也许是：观察你和你的同事平均间隔多久才会使用你的产品。当然，使用次数越多越好。但是，需要注意一点是：你的产品使用的频率越高，用户习惯就越有可能形成。不过，这并不是说无人问津的产品就不是好的产品，它们只是无法使用户养成习惯罢了。因而也就独具特色。但是，即使无法帮助用户形成习惯的产品也有可能变得很受欢迎。因此，想要此方法有可行性，你要经常性地与用户交流，让用户常记于心。
例如，旅游业残酷的斗争让我们不断地访问不同的网站。Expedia、Travelocity等等都频频被用户访问，形成了一种习惯。因此，它们经常性地为争夺用户的注意力而展开竞争。这种方法固然可行，不过，由于这些网站是非习惯形成产品，因而它们总是面临更多的竞争威胁。日常使用的产品会自然而然地在本行业设置障碍。
谁会养成习惯？
既然你已然了解用户“必须”访问网站的频率，就要对数据进行分析，了解有多少用户真正地做到了。这时使用一个统计工具会非常有帮助。不要让工程师放下他们核心的产品开发工作来做这件事，或者甚至是让商务部门的同事来做。你可以可以考虑招一个擅长做数据统计的毕业生来做，计算有多少用户喜欢你的网站。最好的办法是根据数据分析结果，设置一个底线，并以此来衡量未来产品迭代开发问题。
步骤二：整理
至少会有一定量的用户经常性的与你的网站互动，成为你眼中的“爱好者”。不过，爱好者的数量是多少才算足够多呢？我的标准是5%。虽然活跃用户率可能需要更高才能维系你的业务，但是，5%会是开始习惯测试的合适基数。
然而，如果连5%的用户都没有发现那些在产品上承载的使用价值，这就是你的问题了。这时，你要重新开始设计，重塑你的设想。不过，假如你的用户人数超过了这个底线，那么你就可以开始寻找用户习惯，下一步就是整理出用户的访问数据，这样你就能知道让他们迷恋的东西。
每个用户与你的产品互动的方式略有不同。即使有一个标准的用户流程，用户对的参与程度也会创造一种独特的数据轨迹，这能用于分析并发现访问模型。从数据转化到决定是否会出现类似的行为，你可能会希望发现一种“习惯路径”，即一系列大多数忠实用户共有的类似行为。对每一家公司而言，忠实用户的使用行为各有不同，发现“习惯路径”的目的在于，以此找出创造忠实用户的方法。
了解用户的想法
在了解了“习惯路径”之后，一下步就是假设如何通过这个路径让“路过”的用户变成忠实用户。虽然这一步看上去有点儿像是从相关性中找原因。不过，在新产品发布前夕，这是我们能够做到的事情。
在这一阶段，很适合亲自与用户交流，了解他们使用产品的原因以及方式。习惯测试可用于发现这些“道听途说者”的特别之处，发现用以改进产品的东西。
步骤三：调整
将这些新的假设放在心上，回到开发、测算、了解各个环节。将新用户引向忠实用户采用的是相同的“习惯路径”。例如，Twitter现在的流程就是，利用用户的“习惯路径”，来引导新用户在一开始就立即关注其他用户。
习惯测试是一家持续流程企业用于对每一个新功能和产品迭代开发所采用的方式。追踪批量用户，将他们与习惯性用户比较，能引导产品进化、改进以及培养用户使用习惯等。
技术创业者可能经常会发现自己的想法得不到认同，原因是他们没有意识到创造用户习惯的重要性。而不幸的是，如果产品不能创造一种用户习惯，它可能无法生存。使用“习惯测试”来明确产品的最大价值以及习惯形成方式，创业者将能以此更好地为用户服务，增加做出一番伟业的机率。
我第一家公司做过一个项目，我们的软件上线之前，客户已经应用了一套软件长达几年时间，老系统中存在上百万条数据，我们的项目的一部分工作，就是将老的数据迁移到新的系统中，保证新的系统能够正常使用。
这类的数据迁移在现在的软件项目中会经常出现，我现在的公司又一次面对这个问题。
主要的思路就是完整性、正确性可使用性这三方面，下面讲下我们当时所做的测试设计和思路：
在开始之前我们需要一个完整的数据结构的文档，包括老的系统和新的，这样你才能有依据去设计和执行测试。跟迁移组要，他们如果不理解新老系统的数据和数据结构，很难想象他们是怎么迁移的。
1、老的数据是否全部被导入到新系统中，你可能要追踪很多表中的很多数据字段。
如老系统中有100W条数据，导入新系统后，数据条数仍为100w条（有些数据迁移后，新系统有新的存储规则，或业务逻辑变化，比如ID相同合并，条数不是以相同的数量显示，那么我们要知道换算关系，然后进行校验）
对老系统中全部有价值数据字段（对客户有意义的，或者说新系统要用到的），我们要逐一验证，新库中能够找到与之对应的字段。
2、老的数据在新的库中，是以正确的形式存储的。
如果数据在老库中是一个值，我们将他追踪到新的库中，看值是否正确。如果到新库中值需要做相应变化，我们要按照逻辑去校验，是否变化的正确。
有些在老库中是状态位，如老系统中性别字段包括4个，分别是0（男）、1（女），2（未登记），3（不详）；而新系统中性别是男、女、未说明，我们要测试至少4条数据，查看0到新系统中，对应了男，1对应了女，3、4都对应了未说明。
还有一些老数据，到新的库中需要有新的显示模式，比如以前工号只有5位，到新系统中自动升级为10位，我们要跟踪升级是否正确
3、老的数据关联，在新库中是否仍然正确关联
比如个人工资等信息，每个数据都应对应一个人员，到新的系统后，人员信息表发生变更，那么老的工资信息到新库中，是否还能正确对应人员。这种对应关系我们要跟踪几条数据（根据业务逻辑，覆盖可能的全部状态），查看到新系统后，各个数据是否正确对应。
4、关注特殊数据对象
有些数据是比较大的附件，在新的数据库中是否有正确的空间存储，我们需要关注这些大的对象，迁移到新的库中，是否正确被保存和能够继续使用。
5、从业务层面去验证老数据，在新系统中的应用。这个就是用新的系统，用导过来的数据跑下全部功能。
测试的尽早介入，是软件测试提倡的一个基本原则。测试过程中实践测试的尽早介入原则，其主要的优点表现在：提高质量、降低成本、加快进度和过程改进等。
首先，我们将从缺陷的角度来看看测试尽早介入的表现。缺陷是我们测试人员的最主要输出之一，但是它的一些特征说明了测试尽早介入的必要性。
1）缺陷是什么时候引入的
图1 不同阶段缺陷引入的分布
2）缺陷在什么时候发现
图2 缺陷发现的阶段
3）缺陷的雪崩效应
图3 缺陷的雪崩效应
4）缺陷发现与修复的成本放大效应
图4 缺陷发现与修复的成本放大效应
图1缺陷是在什么时候引入的，说明大部分的缺陷都是在需求阶段引入的；而图2说明大部分的缺陷却是在系统测试阶段才被发现；图3说明前期阶段存在的缺陷，会随着开发阶段的开展而不断的放大；而图4说明发现和修复缺陷会随着开发阶段的演进而不断的放大。因此，从这些图表和数据中，我们可以看出测试尽早介入的必要性。尽早测试介入，尽早发现缺陷，开展良好的评审活动就是一个非常好的手段。
其次，我们从测试计划的角度，看看尽早介入的必要性。我们提倡尽早制定测试计划，其主要的目的是：
1）尽早识别测试风险，并采取合适的应对策略。其中风险包括了产品风险与项目风险。
（1）产品风险：可以帮助我们更好的分配测试工作量、选择测试技术、确定测试顺序和选择缺陷修复的优先级。
（2）项目风险：帮助我们计划和管理测试工作，例如：产品培训或者测试工具培训等。
2）尽早估算测试工作量，并以此为基础协调与沟通测试资源，例如：测试仪表、测试人员、测试工具等。
3）根据测试资源情况，尽早安排和搭建测试环境。
第三，测试人员尽早开展对开发工作产品的学习和研究，有助于测试用例的设计与执行，并更好的开展测试活动和完成测试任务。
摘要：软件测试是确保软件质量的可靠手段，是软件开发过程中必不可少的重要环节。本文提出了面向复用的测试用例设计过程，为测试用例复用提供了实现策略。测试用例的复用对于缩短软件开发周期和降低软件开发成本具有极其重要的意义。
关键词：软件测试；测试用例
1、引言
随着软件工程领域的拓展，在软件产业飞速发展的今天，软件测试成为保证软件质量的重要手段。测试用例的选择对于软件测试的成败起着决定性作用，因此如何设计最少的测试用例实现最大的测试覆盖成为自动化测试领域中的主要研究对象。测试用例是确定一组最有可能发现错误的测试数据和流程，实现系统对某个功能的测试。而测试用例的设计与测试人员的个人经验息息相关，不同测试人员的个人经验和书写格式的差异导致了测试的盲目性，以至于产生较高的后期维护费用。测试用例的复用技术一方面是为了解决由测试人员经验不足带来的问题，同时还避免了在设计测试用例中的重复劳动，有效地提高了测试效率。
2、软件测试
2.1 软件测试的定义
软件测试（Software Testing）是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包含输入数据及其预期的输出结果），并用这些测试用例去运行程序，以发现程序错误的过程。
2.2 软件测试的目的
Glenford J.Myers就软件测试的目的提出了以下观点：
2.2.1 测试是程序的执行过程，目的在于发现错误；
2.2.2 一个好的测试用例在于能发现至今为止尚未发现的错误的用例；
2.2.3 一个成功的测试是指揭示了至今为止尚未发现的错误的测试。
测试的目的花费最小的代价找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷来提高软件质量，回避因软件潜在错误和隐患带来的商业风险。
3、软件测试用例的复用
3.1 软件测试用例的复用
软件测试复用可以理解为在两次或多次不同的软件测试过程中重复使用相同或相近的测试资源来组织测试的过程。软件测试的复用主要包括测试流程的复用、测试方法的复用和测试用例的复用。其中测试用例的复用是测试复用中的关键技术。所谓测试用例复用是指对一个软件已执行的测试用例，将其不同程度地应用于该软件新阶段的测试中或其他软件的测试中。可复用的测试用例具有通用性、独立性、有效性、标准化和完整性的特点。
3.2 可复用测试用例的设计
测试用例能否成功被复用很大程度上取决于测试用例的独立性，即能否独立地应用于不同的应用场合和应用环境。在实际应用当中，很多测试用例之间存在着相互的关联。有的测试用例的运行环境要取决于另外测试用例的执行状态，当它所依赖的环境变化或失效时，而与之相关联的其他测试用例的复用属性也可能随之消失。那么如何设计不依靠软件运行环境具有较高独立性、与其他测试用例减少关联且具有统一输入输出接口的可复用的测试用例就成为问题的关键所在。
测试用例是面向不同应用对象的，与被测试软件具有很高的耦合性。为了使得设计的测试用例能够实现成功复用，在测试用例的设计上采取如下步骤。
3.2.1 共性分析
首先应该对被测软件进行共性分析，同一应用领域的软件有相似的需求，分析其诸如工作流程或功能相同等共同特点，并根据他们的共性挖掘可复用因素。
3.2.2 测试用例统一建模
根据可复用因素，设计合适的测试策略，对测试用例的设计做出统一的建模组织，设计统一的结构和输入输出接口。
3.2.3 设计可复用的测试用例
为了尽可能地降低测试用例与被侧软件的相关性，在设计测试用例时应该尽量对其进行通用化处理，同时应保持测试用例的功能单一性。测试用例和被测软件的高耦合性决定了测试用例的复用大多只在同一软件的回归测试或版本升级测试中成功实现，而很难在不同应用领域的软件测试中使用。
3.2.4 测试用例的测评
设计好测试用例之后，组织测试人员和评审专家根据功能需求将测试用例应用于被测软件的测试中，确保测试用例的正确性。改变软件运行环境或测试数据后是否能得出合理的测试结果，分析异常和边界情况的测试结果。
3.2.5 完善测试用例
根据测试结果分析测试用例是否覆盖并测试了全部的共性需求，进一步完善或纠正测试用例。
3.2.6 测试用例入库
将通过测评和完善后的可复用测试用例根据其属性和功能分门别类并按照一定的组织结构放入测试用例数据库中。
3.3 可复用测试用例的管理
测试人员要对用例数据库进行统一有效管理，提供测试用例的功能属性、运行环境、测试方法和项目来源以供测试人员以后的查询和使用。管理人员要及时删除冗余，避免重复用例出现。随着软件技术的发展和测试用例数目的不断增加，对那些不再具备复用价值的测试用例移入其他数据库，以便提高搜索和使用效率。
4、结语
软件测试的复用是目前测试领域研究的热点问题，而设计可复用的测试用例又是实现测试复用技术的关键。本文介绍软件测试用例复用的同时，在理论上给出了可复用测试用例设计的思想和具体方法。在实践中，实际存在的问题往往比我们可以预想到的更多、更复杂，在不同领域和不同功能的软件中实现测试复用的难度更大，需要我们在不停总结经验的基础上还要灵活运用，合理有效管理，才能使测试复用技术进一步发展，提高测试效率，更好地服务于软件产业。
原文地址：http://www.xzbu.com/9/view-962311.htm
摘要：本文描述了软件代码审查的作用、代码审查内容、代码审查过程，并列举一些常见代码审查问题。
关键词：软件测试；代码审查；
一、引言
软件测试常用方法可分为动态测试和静态测试，只有动态测试和静态测试有效结合，才能更好的完成软件测试工作。代码审查是软件静态测试中常用的软件测试方法之一，代码审查时，只要测试人员方法得当、足够细心，往往能够产生意想不到的效果。
二、代码审查的作用
代码审查是在不执行软件的条件下有条理的仔细审查软件代码，从而找出软件缺陷的过程。
代码审查可以找出动态测试难以发现或隔离的软件缺陷。在开发过程初期让测试人员集中精力进行软件代码审查非常有价值：可以提高代码质量；在项目的早期发现缺陷，将损失降至最低；促进团队沟通、促进知识共享、共同提高。
代码审查还可以为动态测试时设计和执行测试用例提供思路。通过代码审查，可以确定有问题或者容易产生软件缺陷的特性范围。
三、代码审查的过程
代码审查过程可分为：代码审查策划阶段、代码审查实施阶段以及代码审查总结阶段。
（一）代码审查策划阶段
1、项目负责人分配代码审查任务；
2、确定代码审查策略：依据软件开发文档，确定软件关键模块，作为代码审查重点；将复杂度高的模块也作为代码审查的重点；
3、项目负责人确定代码审查单，审查内容一般可包括：
（1）可追溯性：
――代码是否遵循详细设计？
――代码是否与需求一致？
（2）逻辑：
――表示优先级的括号用法是否正确？
――代码是否依赖赋值顺序？
――“if…else”和“switch”使用是否正确清晰？
――循环能否结束？
――复合语句是否正确地被花括号括起来？
――case语句是否所有可能出现的情况均已考虑？
――“goto”是否使用？
（3）数据：
――变量在使用前是否已初始化？
――变量的声明是否按组划分为外部的和内部的？
――除最明显的声明外，是否所有声明都有注释？
――每个命名是否仅用于一个用途？
――常量名是否都大写？
――常量是否都是通过“#define”定义的？
――用于多个文件中的常量是否在一个头文件中定义？
――头文件中是否存在可执行的代码？
――定义为指针的变量是否作为指针使用（而不是作为整数）？
――指针是否初始化？
――释放内存后是否将指针立即设置为NULL（或0）？
――传递指针到另一个函数的代码是否首先检查了指针的有效性？
――通过指针写入动态分配内存的代码是否首先检查了指针的有效性？
――宏的命名是否都大写？
――数组是否越界？
（4）接口：
――在所有的函数及过程调用中，参数的个数都正确吗？
――形参与实参类型匹配吗？
――参数顺序正确吗？
――如果访问共享内存，是否具有相同的共享内存结构模式？
（5）文档：
――软件文档是否与代码一致？
（6）注释：
――注释与代码是否一致？
――用于理解代码的注释是否提供了必要的信息？
――是否对数组和变量的作用进行了描述？
（7）异常处理：
――是否所有可能的错误都已加以考虑？
（8）内存：
――在向动态分配的内存写入之前是否检查了内存申请是否成功？
――若采用动态分配内存，内存空间分配是否正确？
――当内存空间不再需要时，是否被明确的释放？
（9）其它：
――是否检查了函数调用返回值？
――所有的输入变量都用到了吗？
――所有的输出变量在输出前都已赋值了吗？
4、确定代码审查进度安排，项目负责人负责安排代码审查的进度。
（二）代码审查实施阶段
1、代码讲解：软件开发人员详细向测试人员讲解如何以及为何这样实现，测试人员提出问题和建议。通过代码讲解，测试人员对被审查的软件有了一个全面的认识，为后续代码审查打下良好的基础。
2、静态分析：一般采用静态分析工具进行，主要分析软件的代码规模、模块数、模块调用关系、扇入、扇出、圈复杂度、注释率等软件质量度量元。静态分析在代码审查时应优先进行，有利于软件测试人员在后续代码审查时对软件建立宏观上认识，在审查中容易做到有的放矢，更易于发现软件代码中的缺陷。
3、规则检查：采用静态分析工具对源程序进行编码规则检查，对于工具报出的问题再由人工进行进一步的分析以确认软件问题，是一种比较有效的方法。
4、正式代码审查：代码审查可分两步进行：独立审查和会议审查。根据情况，这两步可以反复进行多次。
（1）独立审查：测试人员根据项目负责人的工作分配，独自对自己负责的软件模块进行代码审查。测试人员根据代码审查单，对相关代码进行阅读、理解和分析后，记录发现的错误和疑问。
（2）会议审查：项目负责人主持召开会议，测试人员和开发人员参加；测试人员就独立审查发现的问题和疑问与开发人员沟通，并讨论形成一致意见；对发现的问题汇总，填写软件问题报告单，提交开发人员处理。
5、更改确认：开发人员对问题进行处理，代码审查人员对软件的处理情况进行确认，验证更改的正确性，并防止出现新的问题。
（三）代码审查总结阶段
代码审查工作结束后，项目负责人总结代码审查结果；编写测试报告，对软件代码质量进行评估，给出合理建议。
把代码审查提出的所有问题、亮点及最终结论详细的记录下来，供其他软件项目代码审查借鉴。必要时，可建立常见软件代码缺陷数据库，为软件代码审查人员培训和执行代码审查提供数据支持，也可以为软件编码规则制定规范提供实践依据。
四、代码审查中的常见问题
如果软件测试人员熟悉常见的软件代码审查问题，对代码审查效率是很有帮助的。笔者根据自己的应验，列举部分常见软件代码审查问题如下（仅供参考）：
（1）浮点数相等比较：可能造成程序未按设计的路径执行；
（2）因设计原因导致某些代码不能执行：如逻辑表达式永远为真（或假）造成某分支不能执行、代码前面有return语句、某模块从未被调用等；
（3）switch语句没有break语句（有意如此设计时除外）；
（4）数组越界使用：数组越界容易发生在数组下标是计算得到的情况下，而且审查时很难发现这种代码缺陷，应加以重视；
（5）变量未初始化就使用或者是条件赋值就使用；
（6）程序中存在未使用的多余变量；
（7）复合逻辑表达式没有使用括号造成运算顺序错误；
（8）有返回值的函数中return没有带返回值；
（9）逻辑判别的表达式不是逻辑表达式；
（10）动态分配的内存没有及时释放：忘记写内存释放代码或由于其它逻辑缺陷导致内存释放代码未得到执行；
（11）没有对缓冲区溢出进行必要的防护；
（12）访问空指针，即指针未初始化就使用；
（13）指针指向的内存释放后，未将指针置为NULL：其它函数访问该指针时，判断指针不为空，当作有效指针使用，会造成内存访问错误；
（14）注释说明与程序代码实现不一致，甚至相反；
（15）循环存在不能跳出的可能，程序中没有相应的保护机制。
五、结束语
软件代码审查是重要的软件测试方法之一，软件测试单位应建立完善的代码审查规程，规范代码审查过程。代码审查人员应善于使用软件静态分析工具，善于总结代码审查经验。软件代码审查工作做得扎实，可以发现很多软件编码隐含的缺陷，提高软件的可靠性，为后续的动态测试打下良好的基础。
原文地址：http://www.xzbu.com/8/view-1683607.htm