软件测试要写哪些文档
1、SDV测试计划
2、测试需求分析（可不写，依项目而定）
3、测试方案
4、测试用例
5、测试执行计划（可不写）
6、测试报告
如何判断报告单元 reporting unit
PHPUnit是一个用PHP编程语言开发的开源，是一个单元测试框架。PHPUnit由Sebastian Bergmann创建，源于Kent Beck的SUnit，是xUnit家族的框架之一。本文将探索PHPUnit，特别介绍自动化单元测试的基本用法。你需要掌握PHP编程语言的基本知识才能继续。
介绍
单元测试是对单独的代码对象进行测试的过程，比如对函数、类、方法进行测试。单元测试可以使用任意一段已经写好的测试代码，也可以使用一些已经存在的测试框架，比如JUnit、PHPUnit或者Cantata++，单元测试框架提供了一系列共同、有用的功能来帮助人们编写自动化的检测单元，例如检查一个实际的值是否符合我们期望的值的断言。单元测试框架经常会包含每个测试的报告，以及给出你已经覆盖到的代码覆盖率。
heiing
heiing
翻译于 4年前
5人顶
顶 翻译得不错哦！
安装
PHPUnit 通常以 PEAR 包，Composer bundle 或是 PHAR 文件形式存在。如果你要安装它，你需要先安装 PHP Code Coverage 依赖。在 PEAR 中，你需要天价 phpunit.de 频道，并通过命令行安装两个包：
PHP Unit Testing with PHPUnit
（注意，在输入时，默认的 XAMPP 的 PEAR 安装已经被破坏：你需要在尝试上面代码之前先安装 PEAR PHAR）。
测试一个简单的类
试试只有单一方法的简单类：
class TruthTeller
{
public function() tellTruth
{
return true;
}
}
是的，现在 tellTruth 方法总是返回 TRUE，那么我们应改怎么通过单元测试确保今后它的返回值不变？
K6F
K6F
翻译于 4年前
4人顶
顶 翻译得不错哦！
使用PHPUnit，每组测试是PHPUnit_Framework_TestCase类的一个扩展类，它提供了常用的功能，如判断。下面是一个对上述tellTruth方法的一个基本测试：
require_once ’PHPUnit/Autoload.php’;
require_once ’TruthTeller.class.php’;
class TruthTester extends PHPUnit_Framework_TestCase
{
function testTruthTeller()
{
$tt = new TruthTeller();
$this-》assertTrue($tt-》tellTruth());
}
}
请注意，您需要包括PHPUnit的自动加载器和“被测对象”，在这种情况下的TruthTeller类文件。
我们用剩余的代码要做的就是判断，如果tellTruth方法被调用时，它将返回true。这些判断是PHPUnit的核心 - 它们将决定一个测试是通过还是失败。
Holiday_
Holiday_
翻译于 4年前
2人顶
顶 翻译得不错哦！
如果你启动了命令行提示，切换到你的测试所在目录，运行 phpunit TruthTester （参数是你的测试文件名，去除 .php 扩展名），PHPUnit 将会运行文件中指定的所有它能找到的测试（测试将是名字以 test 开头的所有方法)。
PHP Unit Testing with PHPUnit
如果你回到 TruthTeller 类，并将其方法的返回值改为 FALSE，你讲看到类似下面的信息：
PHP Unit Testing with PHPUnit
这就是单元测试的核心——编写断言并判断是否通过。当先前编写并测试通过的代码开始无法通过时，你就知道有更改的代码对现有代码起了负面影响。
在现实中，你肯定需要处理比上一个更复杂的情况。比如一个常见的测试是检查下面的outputArray方法是否返回了一个特定数据结构的数组。
class ArrayTeller
{
public function outputArray()
{
return array(1,2,3);
}
}
对此方法的一个简单测试可以这样写:
class ArrayTester extends PHPUnit_Framework_TestCase
{
function testArrayTeller()
{
$at = new ArrayTeller();
$result = $at-》outputArray(1);
$this-》assertInternalType(“array“, $result);
$this-》assertCount(3, $result);
$this-》assertEquals(1, $result);
$this-》assertEquals(3, $result);
}
}
如你所见，使用PHPUnit进行单元测试时可以在每一行进行多样化的检查：可以检查ArrayTeller返回的是否是一个数组，而非任何其他数据类型；可以检查数组的长度；可以检查数组中的单个值。除这些外，还有其它一些功能的断言，比如如果你需要更复杂的判断，假设要知道一个返回值是否处于两个整数的区间内，只要你能用一个IF语句的结果来表述，你就可以用断言assertTrue来测试结果。可点击随后链接来访问PHPUnit文档中的所有可用断言列表，。
单元测试片面的讲就是编写覆盖被测方法所有预期行为的测试，最好基于规范文档，不过如果你在编写覆盖现有代码的单元测试，将其视为白盒测试的一种形式更有用。如果你知道一个如下的简单切换方法：
class Switcher
{
public function aOrB($switch, $a, $b)
{
if ($switch == TRUE)
{
return $a;
}
else
{
return $b;
}
}
}
… 你就知道需要编写两个测试，分别针对一种情形。但你开始质疑你是如何知道这些的——如果以后方法变为 True 返回 $a，False 返回 $b，其它情形抛出一个异常，理想情况是规范文档中的某处有提及。无论如何，上面方法的测试如下：
class SwitcherTester extends PHPUnit_Framework_TestCase
{
function testSwitchTrue()
{
$switcher = new Switcher();
$result = $switcher-》aOrB(TRUE, 1, 2);
$this-》assertEquals(1, $result);
}
function testSwitchFalse()
{
$switcher = new Switcher();
$result = $switcher-》aOrB(FALSE, 1, 2);
$this-》assertEquals(2, $result);
}
}
运行两个测试同在命令行运行 phpunit SwitcherTester 一样简单。
K6F
使用 setUp，简化多个测试
当你的测试需要覆盖越来越多的输入组合及数据设置时，使用函数： setUp 将会非常有帮助。setUp 是 PHPUnit_Framework_TestCase 类中你可以覆写以在类中所有及每个测试运行前运行的代码。（注意，还有一个简单的方法，tearDown，它会在所有测试结束后立即运行——这对关闭 socket 及文件指针很有帮助）
下面是如何精简代码的一个简单的例子。尝试一个依赖一些对象数据何输入的方法。
class DataTeller
{
private $data;
public function __construct($data)
{
$this-》data = $data;
}
public function outputData($switch)
{
if ($switch == TRUE)
{
if (!empty($this-》data))
return $this-》data;
else
return FALSE;
}
else
{
return “switch off“;
}
}
}
如果你继续之前幼稚的方法，我们需要编写三个测试，并实例化三个 DataTeller 对象，每个测试一次。然而，通过 setUp，我们可以讲对 DataTellers对象的创建，至少是3个中的两个。只有最后一个测试需要新的 DataTeller 被创建。
class DataTellerTester extends PHPUnit_Framework_TestCase
{
private $dt;
protected $data = “valid data“;
function setUp()
{
$this-》dt = new DataTeller($this-》data);
}
function testOutputArraySwitchOff()
{
$this-》assertEquals(“switch off“, $this-》dt-》outputData(FALSE));
}
function testOutputArraySwitchOn()
{
$this-》assertEquals($this-》data, $this-》dt-》outputData(TRUE));
}
function testOutputArrayEmptySwitchOn()
{
$new_dt = new DataTeller(““);
$this-》assertEquals(FALSE, $new_dt-》outputData(TRUE));
}
}
PHPUnit使用断言来告诉你你所测试的代码是否如你预期那样工作。学到这里，你现在应该已经可以写一些简单的测试来覆盖一些功能相对比较独立的类了。但当要测试一些互相有交互操作的类时，就要面对真正的挑战了。为此，请收听下一次讲解，学习如何为静态类写测试，以及如何使用 mock（模拟对象）和 stubs（存根，桩点）来孤立你要测试的对象与其所在环境中其他代码的联系。
软件测试报告怎么写
以前写的东西 省略着写
XX软件测试报告 共 x 页 拟制 年 月 日审核 年 月 日会签 年 月 日批准 年 月 日
1 范围本文档适用于XX软件的单元/集成测试。1.2 系统概述1.3 文档概述本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。2 引用文档《XX软件需求规格说明》《XX软件设计说明》《XX系统接口协议》3 测试概述3.1被测软件的基本概况使用的编程语言：XXX 汇编语言程序行数：1590子程序个数：11单行注释行数：669注释率：约为42%3.1.1. 测试小结本次测试对XX软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了97处代码变更并提交了V1.01版本进行动态测试。在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。 软件代码1.00与1.01版变更明细表： 编号 1.00版行号 1.01版行号 更改说明 1 19 22 注释变更 2 26 29 注释变更 3 29 32 注释变更 4 95 98 注释变更 5 108行后 113～116 增加新变量 6 171、172 180、181 命令字大小写变更 7 以下略 从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更改一共有14处。上述4类更改一共有78处，这些更改对程序本身的功能没有任何影响，但从软件规范的角度来看提高了程序的可读性和规范性。其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改，消除了原有的软件问题并且确认没有引入新的软件问题。认定V1.02版为可以发行的软件版本。3.1.1.1 静态分析小结静态测试采用人工代码走查的方式进行。参加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是：l 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）；l 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；l 对软件汇编源代码进行编程规范化分析。通过静态测试查找出软件的缺陷18个，其中轻微的缺陷4个，占所有缺陷的22.2％中等的缺陷11个，占所有缺陷的61.1％严重的缺陷：3个，占所有缺陷的16.7％上述软件缺陷见附件《软件问题报告单》3.1.1.2 动态测试小结动态测试使用的测试工具为XXX软件集成开发环境。总共的测试用例数：143个。全部由测试人员人工设计。其中单元测试用例138个，集成测试用例5个。发现的软件缺陷有2个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。在发现的软件缺陷中：中等的缺陷1个，占所有缺陷的50％严重的缺陷1个，占所有缺陷的50％上述软件缺陷见附件《软件问题报告单》动态测试中代码覆盖率：代码行覆盖率 100%分支覆盖率 100%程序单元调用覆盖率 100％3.1.1.3 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。3.1.1.4 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析。1． 静态测试中的缺陷分析： 1） 4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改后程序的效率得到提高。2） 11个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。3） 重点分析3个严重缺陷：第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进，详见改进设计分析3。第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。第三个严重错误是近区/远区子程序判断与进入条件反了，经分析对程序的影响不大，但与设计初衷不一致，修改后问题得到了解决，详见改进设计5。2． 动态测试中的缺陷分析：1） 中等缺陷1个，在程序的注释中出现错误，将近区注释为远区，修改后问题得到了解决，提高了程序的可读性。2） 严重缺陷1个，在XX号无效的判别中，本应判断大于10，但误设计为0，修改后经回归测试问题得到了解决。 3． 改进的设计分析：（因和产品相关，略） 3.1.2 测试记录a 测试时间：2005年8月5日至2005年9月17日。b 地点：（略）。c 硬件配置：P4CPU/2.0G，内存256M，硬盘1Gd 软件配置：Wondows98，e 被测软件版本号：V1.0，V1.01，V1.02f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。4 测试结果在两个阶段测试过程中共发现软件缺陷20个，经软件开发人员确认的缺陷为20个，经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。5 评估和建议5.1 软件评估 5.1.1 软件编码规范化评估经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。5.1.2 软件动态测试评估被测软件单元的总数：11个使用的测试用例个数：143个达到软件测试出口准则的软件单元数为11个，通过率100％通过单元和集成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。5.2 改进建议a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。d. 建议结合系统联试，开展软件的确认和系统测试。附件：软件问题报告单（略）软件更改通知单（略）软件测试记录（略）
-单元测试报告
