测试基本概念
测试用例设计白皮书－－测试用例基本概念
测试用例设计白皮书－－等价类划分方法
测试用例设计白皮书－－边界值分析方法
测试用例设计白皮书－－错误推测方法
测试用例设计白皮书－－因果图方法
测试用例设计白皮书－－判定表驱动分析方法
测试用例设计白皮书－－正交实验设计方法
测试用例设计白皮书－－功能图分析方法
测试用例设计白皮书－－场景设计方发
测试用例设计白皮书－－测试用例设计综合策略
白盒测试技术-方法与实践篇
测试者出的APP测试面试题
http://www.jianshu.com/p/d133539b7b5c
给你一个模块，比如注册模块，你会怎么样设计与执行测试？
参考答案：数据——》从哪里来（入口）——》到哪里去（出口）——》数据库（检验数据的正确性）
一些测试题
百度首页的测试
http://www.cnblogs.com/tomato0906/articles/4622422.html
http://www.bdqn.cn/news/201309/11459.shtml
三角形测试：等价类划分
设计功能和界面测试用例一
http://blog.163.com/pengjintaogz@126/blog/static/162299068201031442428744/
设计功能和界面测试用例二
http://blog.163.com/pengjintaogz@126/blog/static/162299068201031442428894/
测试的分类
软件测试分类：
- 1.按结构与内部实现：
http://www.lmwlove.com/ac/id1105
黑盒测试：关心的是输入与输出。
白盒测试：可以访问程序代码，并且通过检查代码来协助测试，测试员根据代码检查结果判断什么样的数据输入可能导致bug的产生，并根据此调整测试程序。
灰盒测试：介于白盒测试与黑盒测试之间。 - 2.按是否执行程序分：
静态测试：测试不运行的部分——知识检查与审阅。
动态测试：运行与使用。 - 3.按过程分：
A.单元测试：集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
B.集成测试：把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试
C.确认测试：检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确
D.系统测试：把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试
E.验收测试：用户对软件产品投入实际应用以前进行的最后一次质量检验活 - 4.按测试类型分：
- A.功能测试
- B.性能测试：
http://www.cnblogs.com/fnng/archive/2012/06/09/2543274.html
负载测试
这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃
压力测试（强度测试）
这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
并发测试
这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
配置测试
这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。
****可靠性测试****
这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。 - C.安全测试
- D.易用性测试
- E.兼容性测试
服务器压力测试
-
吞吐率和压力测试
普遍使用“压力测试”的方法，通过模拟足够多数目的并发用户，分别持续发送一定的HTTP请求，并统计测试持续的总时间，计算出基于这种“压力”下的吞吐率，即为一个平均计算值
1、 并发用户数
并发用户数就是指在某一时刻同时向服务器发送请求的用户总数。
假如100个用户同时向服务器分别进行10次请求，与1个用户向服务器连续进行1000次请求。两个的效果一样么？
一个用户向服务器连续进行1000次请求的过程中，任何时刻服务器的网卡接受缓存区中只有来自该用户的1个请求，而100个用户同时向服务器分别进行10次请求的过程中，服务器网卡接收缓冲区中最多有100个等待处理的请求，显然这时候服务器的压力更大。
-
思路：
服务器端I/O多路复用，epoll
客户端多进程或者多线程模拟多个客户登陆
Paste_Image.png
粗略列一列，大致可以从以下几个层面考虑吧：
1．功能方面，是否能按指定条件查到正确、完整的结果，具体：
1.1录入条件为可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；1.2录入条件为不可查到结果的关键字、词、语句；
1.3录入条件为一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2．性能方面，可利用测试工具或各种测试手段考虑功能在各方面的表现，具体：
2.1压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
2.2负载测试：看极限能承载多大的用户量同时正常使用
2.3稳定性测试：常规压力下能保持多久持续稳定运行
2.4内存测试：有无内存泄漏现象
3．易用性方面，交互界面的设计是否便于、易于使用，具体：
3.1依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；
3.2查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
3.3标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
3.4有否快照等快捷查看方式等人性化设计？
4．兼容性方面，跨平台、多语言等多样性环境组合情况下测试使用的正常性，具体：
4.1WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
4.2IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下的应用
4.3SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
4.4简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
4.5IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
4.6与各相关的监控程序的兼容性测试，如杀毒、监控、防火墙等工具同时使用
5．安全性方面，往往容易被忽视的环节，具体：
5.1被删除、加密、授权的数据，不允许被查出来的，是否有安全控制设计；
5.2录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。
5.3通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
5.4对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；
6．异常性测试，各种破坏性的操作的影响测试，具体：
6.1查询过程中断网、关机
6.2查询过程中强行中断关闭页面
6.3查询过程中强行杀死相关进程等
持续集成Continuos Integration
- CI的优点
-
减少风险
缺陷的检测和修复变得更快，让寻找和修改bug的工作变简单（只修改系统一小部分，无需看太多代码。由于提交后就可以得到反馈，记忆很新鲜，可以进行差异调试。）同时过早的引入集成，使我们能更好的审视各个模块的接口是否满足要求，减少项目中的假定。 -
减少重复过程
由于CI将大量的工作给自动化了，那么可以让人们有时间做更多的需要动脑筋的、更高价值的工作。而且通过对重要过程自动化，克服了项目中某些成员对实现改进的抵制，有利于持续集成的推进。这样就形成了一个良性循环。 -
在任何时间、任何地点生成可部署的软件
对于客户来说，可以部署的软件是最实际的资产。而CI则可以轻松做到这一点。 -
增强项目的可见性
通过对CI服务器的监控，可以随时了解项目的趋势。CI上的红色或绿色表示了当前项目的健康程度。每一个功能的交付都经历了单元测试或集成测试的考验。
对开发团队的软件产品建立起更强大的产品信心
“持续”：我想对CI里“持续”的理解可以从两方面来谈，首先是持续地集成产品，尽早地发现问题；其次，也可以把这里的持续理解为持续改进，正如前面说的，CI里包括很多的实践，我们不可能一下子引入全部，这就要求我们有持续改进的sense，持续地引入新的实践（比如加入代码审查等）、持续地加入新的case、持续地完善CI和process，在改进的同时，CI又很好地保证了已有部分的长期有效，不过像猴子摘西瓜那样，缺少历史的积淀。
部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar *）存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
软件测试模型
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。
己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人
软件测试模型的v模型、w模型、h模型、x模型总结
敏捷开发与瀑布模型
对比：http://www.cnblogs.com/zh2000g/archive/2010/02/22/1671286.html
瀑布模型开发：
严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
敏捷开发：
核心是迭代。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
关于工具(java)
Jenkins是一个开源的持续集成工具，应用Jenkins搭建持续集成环境，可以进行自动构建、自动编译和部署，非常方便。
在服务器比较少的情况下，Jenkins的优势并不明显，但是随着项目发展，服务器数量的增加，Jenkins的优势就会凸显出来，可以很好的提高效率，减少很多人工操作。
现在很多公司的Java项目开发都是使用Git或者SVN管理代码，Maven管理多模块和项目依赖（很多jar包），所以今天尝试学习如何使用Jenkins搭建Github与Maven下的自动构建和部署。
关于git和svn
CMMI软件能力成熟度模型
