标签：nbsp 其他 执行 drive 友好 效果 来源 dev 模式
说说《探索性软件测试》这本书吧，阅读之后一些个人理解和思考，纯文字，不感兴趣可忽略。。。
第一章有这么一句话：从设计来说，有些软件的功能本身就存在功能逻辑上的错误或不友好，且产生的效果完全违背我们的初衷。
做软件测试工作，或许第一件要知道的事情就是：没有完美的设计和产品。
也许这也是软件测试这个行业产生以及发展至今的原因吧，即使软件设计、开发、测试流程不断在优化完善，但它依然存在缺陷！
软件缺陷来源于软件开发本身，主要原因是软件工程师没有理解、预见或测试到所有可以运行的环境。
或者换一句话来说：程序永远无法预防用户的各种操作而带来的损失。
软件应用的四个基本功能：接收输入、产生输出、存储数据、运行运算
那么，如何尽可能把缺陷排除在交付用户使用之前？主要有以下两点：
1、缺陷预防
这一点主要从软件开发人员角度来说：编写更好地设计规范、实施代码审核（code review）、代码静态分析、单元测试（unit testing）等等；
①代码审核：开发人员视角：如何实现这个功能——————盲点
测试人员视角：如何攻破这个功能
二者相辅相成，缺一不可
说到这里，想起一种软件研发模式：测试驱动开发（TDD：test-driven-development）
②静态代码分析：不需要实际运行代码程序，其主要包括分析程序源代码（source code）、目标代码（object code）、最终编译生成的二进制文件或程序。
③数据：软件需要IO数据，才能覆盖程序中各个代码路径、程序、功能；软件测试是个动态的过程，在不同环境运行软件，使用合理的测试数据，尝试多次不同的输入。
2、缺陷检测
软件测试工程师的工作，就是尽可能主动暴露、发现缺陷，并配合其他软件工程师解决缺陷；而测试人员的测试形式，一般有两种：利用工具进行自动化测试和手工测试。
①自动化测试
说起自动化测试，常见的类型有UI自动化、接口自动化以及单元自动化；业内对其的评价，也可以说各执己见，它的优点和缺点，都很明显。
优点：编写代码脚本执行测试用例，效率高，省却了大量的时间和人力成本
缺点：代码脚本维护成本较大、前期人力时间需要投入的成本大、需要比较稳定的环境等等，还有，如何确定自动化测试真的完成了应该完成的任务？是否输出了正确的结果？
②手工测试
这种类型的测试人员，可以说占软件测试从业人员的大多数，业内俗称点工（点点点），说来有点嘲讽，很多人觉得点点点没有技术含量，都是自嘲居多（虽然我也偶尔开玩笑
说自己专注点工多年^_^）。不过话说回来，点点点也有很多东西需要学习，如何分析需求、设计覆盖率足够高的用例，如何有效的执行用例发现缺陷、及时跟踪、和开发人员
沟通、定位缺陷、协助解决缺陷，以及足够大的脑洞，比较好的阅读理解以及文档编写能力，这些都很需要时间去钻研练习以及实践。
探索性软件测试
本书主要内容就是探索性测试这个方法，或者说，一种思维逻辑方式、方法论，更合适。
主要有两块内容，局部探索性测试和全局探索性测试。
探索性软件测试核心：强调个人自由与责任的测试方法，让测试人员借由不断学习来改善测试的规划与执行，同时在测试过程中同时改善测试的案例来达到不断互补优化。
大概总结了一下，其主要内容就是以下几个点：
①何时何人采用何种方法测试什么
②对需求的探索、了解、熟悉
③对工作流的不断探索
④测试案例的重用性、简洁有效性
④模块拆分、关注IO上下游、
⑤方法论、探索论、思考总结优化
探索性软件测试的三个目标：
①理解应用程序的工作逻辑和原理，接口，以及实现了哪些功能
②尽量了解熟悉软件的所有功能
③寻找缺陷
最后，在本书的末尾篇章找到如下内容，算是寥有收获。
软件测试十戒律：
1.汝应用大量输入反复锤炼汝之应用程序
2.汝应贪图汝之邻居的应用程序
3.汝应亲自寻找睿智的预言家
4.汝不应崇拜无法重现的失效
5.汝应尊重汝的模型和自动化测试
6.汝应利用开发人员的过错与他们作对
7.汝应醉心于谋杀应用程序（庆祝蓝屏吧）
8.汝应保持安息日（指产品发布时刻）的圣洁
9.汝应贪图开发人员的源代码
具体内容链接：www.howtobreaksoftware.com(PS：需要收费)
相关链接：http://blog.csdn.net/andy572633/article/details/13004731
http://blog.csdn.net/andy572633/article/details/46941753
标签：nbsp 其他 执行 drive 友好 效果 来源 dev 模式
原文地址：http://www.cnblogs.com/imyalost/p/6856783.html
