兼容性测试(Compatibility Testing)。简单来说就是公司的软件要跟自己兄弟产品还有别的产品能和平地在系统上正常运作。下面有一些例子：
1.在网页上剪切一些内容，然后粘贴到文字处理软件里面
2.把一些资料用A工作表软件打开，然后保存以后，在B工作部软件里面打开
3.一个图像处理软件运行在不同版本的操作系统上
在兼容性测试里面需要注意的一些事项：
1.你的软件是被设计到工作在哪些平台上的，需要跟哪些软件进行交互。
2.公司是按照哪些标准和指引来工作的。
3.你的软件用什么类型的数据跟别人软件进行交互。
Continue reading »
配置测试(Configuration Testing)是一个检查我们的软件在不同的硬件环境下能否正常地工作的过程。这当中牵涉到几样东西，电脑本身，电脑配件，外设，接口，选项，存储器和驱动。不同的软件会有不同的针对点，例如对于一个游戏软件，例如QUAKE IV，它最应该关心的是显卡和声卡的测试，一个图像处理软件有可能关注于显示配置和打印机的测试。
怎样准确分离出配置错误(Isolating configuration bugs)。一个简单的方法就是，如果在测试的过程中遇到了bug，在其他一些不同配置的机器上运行同样的操作，看问题是否能重现，从而达到分离出引起这个bug的最根本的原因。
那么遇到了问题应该又谁来负责修复呢，是软件公司呢还是硬件厂商？一个配置错误通常会有一下四种表现形式：
1.软件在一系列的硬件配置条件下都出现错误，例如连上激光打印机就挂了。
2.软件在一个特定的型号的硬件下出现错误，例如只是连接上Magus牌扫描仪才挂！
3.软件只受到某个硬件或者是硬件的驱动程序所影响而出现错误。
4.硬件或者它的驱动程序本身是有问题的，也影响了其他的一些软件，不过我们测试的软件在当前硬件配置下受到的影响特别大。
第七章：Testing the Software with X-Ray Glasses。
Dynamic White-Box Testing（动态白盒测试）-动态，就是软件在运行；白盒，我们能看见里面怎么运行。所以就好像是带了X-光眼镜一样。它还有另外一个名字，就是结构测试(Structural Testing)。动态白盒测试通常包含了四个方面。
1.直接对底层的函数，过程，库~等进行测试。也就是对API的测试
2.站在一个比较高的层次来测试软件，而且是根据你对软件行为的认知的情况下进行，根据code具体的情况设计有针对性的case进行测试
3.验证已经设计好的case是否真的符合了当初设计的初衷。还有就是强行改变一些通过正常途径很难达到的软件的状态。这个例如说，一般软件都有很多错误的提示信息，但是要把全部错误信息通过正常渠道（用这个软件）得到，是比较困难的。不过在白盒测试里面，我们可以直接在debug器里面改相应的flag变量来达到目的
4.根据各种code coverage的结果来对已有test case的增加和修改，以达到更好的测试效果。
个人的一些体会，其实测试就是一个动态的过程，test case需要动态的维护、更新和增加，以达到好的效果。呵呵，动态可不单只是指软件运行~一语双关啊~或者说这个词被重载(Overload)了。
Examining the Code – 检查代码。这章主要讲的是(Static White-Box Testing)静态白盒测试：对设计和代码的检查。
(Static Testing)静态测试，就是对那些不运行的东西进行测试–检查和评审。
(White-Box Testing)白盒测试，指可以看到内部结构并且可以对之进行评审。
(Static White-Box Testing)静态白盒测试，就是在不运行软件的情况下对其设计，架构或者代码进行检查。有时候也叫(structural analysis)结构分析。
(Formal Reviews)正式审查。正式审查是一个严格的正规的活动。如果评审是一个随机的过程，那么所有事情都成了随机，开会时间是随机，发现的bug是随机，效果是随机，回家的时间也是随机的。对于正式审查，有以下4个根本要素
1.(Identify Problems)找出问题。核心我觉得就是一句话，对事不对人。发现了代码或者文档的问题，就只能就这些问题进行批评，而不是去找到谁干的，然后对他劈头盖脸的训斥一顿。
这章标题是：Testing the Software with Blinders On。带上眼罩去测试软件，不是让你瞎测哦。主要讲的内容就是黑盒测试的技术。
动态黑盒测试(Dynamic Black-Box Testing)
也有叫行为测试(behavīoral Testing)，功能测试(Functional Testing)。现在可能国内很多单位就真的是一个瞎子来测试软件，不是说那个测试人员是瞎子，是老板让他们变成了瞎子，为什么呢？因为可能大多数都缺少文档，我们需要的是软件的需求文档-Requirements Document（需求文档）或者是 Product Specification（产品说明书）。
测试用例(Test Case)。
Test cases are the specific inputs that you’ll try and the procedures that you’ll follow when you test the software.我的理解，测试用例就是一组根据相应文档而设计出来的操作步骤，输入数据和输出结果，是对软件产品的进行测试的执行过程。
这章还提到了一个概念–Exploratory Testing（探索性测试）。
Continue reading »
这章主要介绍了静态黑盒测试的一种：对说明书的测试。我觉得跟以前的PEER REVIEW是相同的。之所以是静态的是因为测试的对象是静态的文档而不是运行的软件。黑盒呢就是因为测试员并不需要知道这个说明书是怎么写出来，那些资料来源于哪里，是否准确，怎么利用数据等等……只需要关心说明书的本身就可以了。
这个评审分为两个部分，第一部分是对说明书的概要评审。有三点是要做到的：
1.以用户的角度去看问题。可以先找软件的最终用户去谈谈，了解一下他们的习惯什么的，我觉得这里说的最终用户是End User而不是Customer。在这章里面我觉得比较精辟的句子就是：The definition of QUALITY means “meeting the customer’s needs”。
2.研究现有的标准和指南。不要做出来的软件是标新立异的，有时候个性是好，不过过分的个性通常不会有好的下场啊。
3.对类似的软件进行评审和测试。有句话说的很好，“你想不到的你的敌人会告诉你”。去看一下竞争对手的产品。 Continue reading »
Testing Axioms，做每样事情都是有他的游戏规则，同样软件测试也有一些需要遵守的原则。
1.It’s Impossible to Test a Program Completely
当然啦，要测完岂不是要我命！得出这个结论的理由是，当输入集是很大的，输出集也是很大的，软件的可能路径太多。而且还有一个因素也是最要命的：说明书是很主观的
2.Software Testing Is a Risk-Based Exercise
既然没办法100%全部测试，那怎么办？根据风险来判断什么该测，定义好出口条件
3.Testing Can’t Show That Bugs Don’t Exist
软件测试这份工作很特殊，当你找到问题的时候，证明了软件是有缺陷的；但是当你找不到问题的时候，并不能证明该软件是BugFree的。
Continue reading »
软件开发过程，软件就是一件产品，那么这个产品的生产过程是什么呢？在这个过程中都有些什么中间产物呢？
Customer Requirements（客户需求）
Specifications（说明书），说明书是从需求转化而来，定义了产品是怎么样的，能干什么等等
Schedules（进度表）
Software Design Documents（设计文档）书上说的5种，有些也可能只是某文档的一部份而已。我自己见过比较常见的High-Level Design（概要设计）, Low-Level(Detail) Design（详细设计）。书上说的数据流图，状态转换图等等，有时候就出现在HLD里面了
Test Documents（测试文档）包括了测试计划，测试用例，问题报告，统计报告等……这里我自己讲讲体会，刚到SPSS实习的时候看文档的时候我看到了Test scrīpt这个名词，一开始我以为是自动化脚本，后发现其实就是Test Case，所以说这些所有名词都可以有其他叫法。
以上就是作为一个测试工程师会经常遇到的文档。
Continue reading »
这个读书笔记系列是我在上学实习的时候写的，现在要把它从51TESTING搬过来，顺便梳理一下。
从事软件测试的同学获取曾经都遇到过这样一个问题：应该怎么称呼BUG呢？一个专业的定义是：Software Failure，但是还会有很多各种各样的称呼，例如：
每个公司都有自己的叫法，之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受，不要搞的DEV和QA好像是对立面似的。在埃森哲叫SIR，不是先生的意思，而是System Investigation Report。其实叫啥不重要，就像人的名字，一个符号而已。
Continue reading »
近期评论