软件测试分析报告应该包括哪些内容

测试分析报告
1 引言
11编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
12背景
说明：
a 被测试软件系统的名称；
b 该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
13定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
14参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
31测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
32测试2（标识符）
用类似本报告31条的方式给出第 2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
41功能1（标识符）
411能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
412限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
42功能2（标识符）
用类似本报告4l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
51能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
52缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
53建议
对每项缺陷提出改进建议，如：
a． 各项修改可采用的修改方法；
b． 各项修改的紧迫程度；
c． 各项修改预计的工作量；
d． 各项修改的负责人。
54评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

  一个想要留住用户的APP，不仅要内容输出新颖，功能也要齐全，但有一个必要的前提是APP在使用过程中不卡顿或加载缓慢在这种情况下，这会导致更差的用户体验，直接使用或不使用该应用程序。在这种情况下，需要进行应用程序性能测试。

    想要做好app性能测试，还需要遵守相关程序，才能万无一失。那么app性能测试的流程是怎样的，你对app性能测试了解多少呢？下面我来告诉你。

一、APP性能测试是什么意思？

    APP性能测试通常分为服务端性能测试和移动端性能测试。通过各种测试工具，对APP性能进行测试评估，发现存在的缺陷，保证软件安装安装后的正常使用。

二、APP性能测试的重点是什么？

    1资源消耗；分别测试空闲状态、中等规格和满状态下的资源消耗。

    2内存：一般APP应用不会占用太多手机内存资源。可以测试不同强度下应用内存和系统内存的变化，以及应用的整体流畅度等。

    3、电量使用：首先了解手机在正常情况下的电池使用时间。关闭所有应用后，再启动待测APP，看看耗电增加了多少，取差值。

    4、网络流量消耗；测试第一次启动时的流量值和运行一段时间后的流量值。

    5响应速度/时间；分别测试APP首次/非首次启动、有网/无网的加载时间。

    6兼容性测试；不同手机版本的兼容性测试。

三、常见APP性能测试方法

    APP性能测试的方法有很多种。有些指标可以人工计算，有些性能测试必须借助软件测试工具进行。测试人员一方面可以使用手机内置的测试工具进行应用测试，另一方面可以使用Jmeter等自动化测试工具进行测试。

四、如何做好APP性能测试？

    APP性能测试也是APP测试的一部分。测试人员需要具备良好的测试技术能力。同时，测试环境、网络带宽等硬件条件也是做好APP性能测试的基础。为了做好APP性能测试，建议企业可以通过第三方测试机构进行APP测试。

测试数据测试项总数 0 PASS 0 PASS率 #DIV/0! FAIL 0 FAIL率 #DIV/0! 严重度——高 0 其中：高-- #DIV/0! 严重度——中 0 中-- #DIV/0! 严重度——低 0 低-- #DIV/0! 测试项编号 测试项 通过与否 问题描述 问题严重度注： 问题严重度的界定：高——导致系统死机或后续部分测试项功能不能实现；中——影响该部分的测试功能的完整性且急需解决；低——仅属于系统中的小bug，或根据测试过程发现的需要调整的部分，但并非急需解决。

给你看个范例：

测试环境：
       DELL 24G memory 512M
       RH90 MySQL 32354
测试使用的是mysql缺省参数，用mysql提供的API用C编写测试程序
测试程序共启动40个线程进行数据库 *** 作，查找、插入、修改、删除各10个，每个线程独立与Sql Server连接。
数据库结构，单表，表结构如下：
       toheader         100byte 主键
       contactheader 100byte
       called       50byte
       cseq        100byte
       hashval      int
       timestamp       int  次键
对主次键分别建了索引。分别在5万、10万、50万用户环境做测试，结果如下：
 
   
查找100次
   
插入100次
   
修改100次
   
删除100次
   
5万
   
100－300ms
   
100－300ms
   
100－300ms
   
100－300ms
   
10万
   
500ms-1s
   
500ms-1s
   
500ms-1s
   
500ms-1s
   
50万
   
3s-5s
   
3s-5s
   
3s-5s
   
3s-5s
   
从此数据看性能是很不错的，因为mysql能保证每个 *** 作是原子的，所以不用考虑线程间的同步。
 
但有一个问题：即mysql的每个 *** 作是原子的，所以做每个 *** 作时，其它线程是阻塞的，在大数据量查询时，花的时间较长，会对其它线程有影响。我在保持其它线程工作不变的情况下，将每个查找线程改为做一次对所有记录的查询，在5万和10万记录时表现不错，分别为250ms和450ms，但在50万记录时，这个数值达到了22秒。而且在50万用户时，通过条件查找部分数据也很慢，如查询结果为10万记录时用11秒。
怀疑是sql server的参数影响，按数据库说明修改了几个缓冲区的参数，但没有效果。
由于首次同步发生的频率很低，象250ms和450ms这样的数据还是可以接受的，但22秒太离谱了。支持50万用户在线，需要考虑一个解决办法，现在有一个办法是建一个备份表，写备份表的请求放到一个队列里由一个单独线程处理，这样阻塞不会影响正常业务处理了。但这个线程的缓冲区要足够容纳30秒内发生的 *** 作。
 
本来担心数据量大了mysql的缓冲区不够会出错或丢数据，但测试发现，一次查询最多读了50M数据，没有出现问题，经测算我们首次同步的数据不会超过10M。
 
在MySQL中启动了innoDB引擎后，可以实现真正的行级锁，select和update *** 作可以并发，这样在全表查询进行中间可以进行其它的select和update *** 作，但insert和delete不行。
性能也有很大提高，50万记录时100次 *** 作300ms，全表查询11秒多
 
 
常用参数 [options] 详细说明：--auto-generate-sql, 
-a 自动生成测试表和数据，表示用mysqlslap工具自己生成的SQL脚本来测试并发压力。
--auto-generate-sql-load-type=type 测试语句的类型。代表要测试的环境是读 *** 作还是写 *** 作还是两者混合的。取值包括：read，key，write，update和mixed(默认)。
--auto-generate-sql-add-auto-increment 代表对生成的表自动添加auto_increment列，从5118版本开始支持。--number-char-cols=N, 
-x N 自动生成的测试表中包含多少个字符类型的列，默认1--number-int-cols=N, -y N 自动生成的测试表中包含多少个数字类型的列，默认1--number-of-queries=N 总的测试查询次数(并发客户数×每客户查询次数)
--query=name,-q 使用自定义脚本执行测试，例如可以调用自定义的一个存储过程或者sql语句来执行测试。--create-schema 代表自定义的测试库名称，测试的schema，MySQL中schema也就是database。--commint=N 多少条DML后提交一次。
--compress, -C 如果服务器和客户端支持都压缩，则压缩信息传递。--concurrency=N, -c N 表示并发量，也就是模拟多少个客户端同时执行select。可指定多个值，以逗号或者--delimiter参数指定的值做为分隔符。例如：
--concurrency=100,200,500。
--engine=engine_name, -e engine_name 代表要测试的引擎，可以有多个，用分隔符隔开。例如：--engines=myisam,innodb。--iterations=N, -i N 测试执行的迭代次数，代表要在不同并发环境下，各自运行测试多少次。
--only-print 只打印测试语句而不实际执行。--detach=N 执行N条语句后断开重连。--debug-info, -T 打印内存和CPU的相关信息。说明：测试的过程需要生成测试表，插入测试数据，这个mysqlslap可以自动生成，默认生成一个mysqlslap的schema，如果已经存在则先删除。可以用--only-print来打印实际的测试过程，整个测试完成后不会在数据库中留下痕迹。各种测试参数实例（-p后面跟的是mysql的root密码）：单线程测试。测试做了什么。
# mysqlslap -a -uroot -p123456多线程测试。使用–concurrency来模拟并发连接。# mysqlslap -a -c 100 -uroot -p123456迭代测试。用于需要多次执行测试得到平均值。# mysqlslap -a -i 10 -uroot -p123456# mysqlslap ---auto-generate-sql-add-autoincrement -a -uroot -p123456# mysqlslap -a --auto-generate-sql-load-type=read -uroot -p123456# mysqlslap -a --auto-generate-secondary-indexes=3 -uroot -p123456# mysqlslap -a --auto-generate-sql-write-number=1000 -uroot -p123456# mysqlslap --create-schema world -q "select count() from City" -uroot -p123456# mysqlslap -a -e innodb -uroot -p123456# mysqlslap -a --number-of-queries=10 -uroot -p123456测试同时不同的存储引擎的性能进行对比：# mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info -uroot -p123456执行一次测试，分别50和100个并发，执行1000次总查询：# mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info -uroot -p12345650和100个并发分别得到一次测试结果(Benchmark)，并发数越多，执行完所有查询的时间越长。为了准确起见，可以多迭代测试几次:# mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --debug-info -uroot -p123456

。就当练习了。。大家看了不要喷我。。现在很多测试人员做移动端测试，可能主要还是关注功能和自动化测试。性能测试可能大多是按照每个人的体验来做报告，是不是比较快，或者比较慢。当然也不乏有很多的测试人员会回复我说，性能测试都是服务器的，移动端根本就不需要性能测试。我实在觉得可笑。 不过我毕竟一直在创业公司，而且就我一个人，所以了解可能有限，我这里就说下我之前碰见的，所知道的，目的只是抛砖引玉。 另外，我这里也不去说什么MAT，instruments了，这种固有查找内存的工具大家自己google吧。 客户端的性能从系统层面，电量消耗，网络流量，内存泄漏等都是被关注，或者说用户最最关注的点。 实例一，3rd 应用的性能测试。应用本身的响应时间可以通过call 应用intent来查看，设备纯环境，设备低内存等各种情况下进行同样此数的call，进行对比。或者与同行业同性质的应用进行对比测试。我相信很快就能够有结论了。除了应用本身，还需要对于应用本身某些特别的功能进行响应测试。比如测试一个list，测试的方法为onkeydown之后查看这个listindex（0）是否高亮，是否正常的界面跳转了，那么分别进行计时（精确ms）。同样的，我们在空list以及有几百条list的情况进行这样的case test，那么就会有一个性能的结果出来。 实例二，假设你测试微薄客户端，那么你肯定是需要进行一个list上下滑动的性能测试。我们需要使用脚本语言shell或者python去call server api来仿造数据反馈到移动设备上，否则你不可能自己手动去发几百条weibo然后再测试。测试的时候需要关注两个问题，一个是list在各种情况下是否滑动流畅，一个是当list中有很多的的时候load的速度也是一个很大的测试点。这个load可以直接检查imageview什么时候load出来pic，什么时候显示在界面上，计算时间。这里其实很多应用是webview，或者数据是存在服务器端的，这个时候无论是平时的测试还是压力，还是性能，数据的修改，其实还是多使用脚本ping api比较好，能够很好的去辅助达到性能测试的效果。 实例三，比如要测试一个优酷的视频软件，那么视频的播放的时候，首先保证网络的情况下，各种分辨率各种码率的视频接入时间是需要关注。然后在播放，也就是和网络不停的通信的同时，那么需要通过tcp dump和wireshark工具来检查网络访问是否正确，视频的卡顿，视频的花屏等除了硬件兼容之外，可以通过抓包来判断其性能。如果丢包率高那么自然视频卡，体验不好，性能也就不会好。 其实以上只是一些很基础，现在很多公司也已经在这个基础上改良测试了。不过也是一些思路，让更多的企业和测试关注移动客户端的性能。不要一提到性能脑中只有LR等这些Server测试。

评测的主要内容：
1 *** 作性评测：即画面的质理，鼠标键盘的 *** 作等方面
2功能性评测：即是否达到游戏运营商所宣传的功能，
如:人物飞天功能，需测试人物飞天功能在何时3能触发，
飞行的感觉及飞行时的辅带情况。
3性能评测：即游戏的运行速度及测试机型－每秒FPS，
CPU占用率，内存使用率等。
4游戏特点：即列出所评测游戏的具体特点，适合的年龄
层次、性别、公会进驻的优劣。
5其它：如网游的BUG，自己在游戏中的经验（可省）
具体测试工具，如测每秒帧数可直接在网上搜索即得。
一篇测评文章需要对各类评测内容进行评分，而评分的方式多种多样，但老K在这里也希望有一个评分规定，这需要各位能仔细思考下做一个综合评定标准。可能适合DW公会这一块占比例较大，其它各占其中。

---